Маршрутизация с временными окнами (VRPTW): SLA, штрафы и исполнимость

В реальной доставке «оптимальный» маршрут часто разваливается на первом же отклонении — не из-за километров, а из-за времени: окон приёма, времени обслуживания, смен, ожиданий, ограничений парка и договорного SLA. В этой статье разбираем VRPTW как управленческую постановку: как задать окна, как считать штрафы, как проверять исполнимость и как переходить от планирования к исполнению.

1) VRPTW: почему время важнее километров

В классическом VRP маршрут «лучше», если он короче и дешевле. Но как только появляются временные окна, задача становится VRPTW: теперь важна не только география, но и возможность обслужить каждую точку в нужный момент.

• Временные окна. Интервалы, в которые точка может быть обслужена. Узкие окна повышают стоимость и уменьшают плотность маршрутов.
• Service time и простои. Время на точке сдвигает расписание и создаёт каскадные опоздания. См.: dwell time.
• Смена и ограничения исполнения. Ограничения по сменам, возврату на базу, типам ТС, совместимости грузов и доступности водителей.

2) Hard vs Soft: постановка SLA без самообмана

В практической модели важно различать: где окно является физическим запретом, а где — договорным ожиданием.

• Hard windows (жёсткие). Нарушение запрещено. Пример: склад принимает строго до 16:00; после — отказ.
• Soft windows (мягкие). Нарушение допустимо, но имеет цену (penalty cost).

Практическое правило. Если все окна жёсткие — получите «невыполнимо» и ручное диспетчирование. Если все мягкие — «выполнимо» на бумаге и деградация сервиса в реальности. Нужна матрица: какие точки hard, какие soft, и какая цена отклонений.

3) Стоимость времени: ожидание, простои, пустые пробеги

• Waiting (ожидание окна). Машина приезжает раньше — ждёт. Нужно учитывать как стоимость.
• Dwell time (очереди/разгрузка). Если dwell time занижен, оптимизация строит «идеальные» планы, которые разваливаются.
• Empty miles (пустые пробеги). Появляются, когда окна и парк не совпадают со спросом.

Для управленческого контроля удобно сравнивать сценарии по формуле: transport cost + waiting cost + penalty cost.

4) Исполнимость: метрики и проверка качества

• Service level / SLA. Доля визитов в окно, доля поздних/ранних визитов, 95-перцентиль опозданий.
• Время на точках. Среднее и распределение service time + dwell time; точки-«пожиратели смены» дают каскад проблем.
• Plan-fact. Сопоставление плана и факта с причинами отклонений: пробки, очереди, переносы.

Типовые ошибки в данных

• Окна указаны «идеальные», а не реальные (обеды/закрытия не учтены)
• Service time задан константой, хотя зависит от объёма и типа клиента
• Время в пути не соответствует реальности
• Парк не описан: ограничения по вместимости/типу/температуре игнорируются

5) Replanning: план vs исполнение

В доставке план живёт в мире событий: задержка, пробка, поломка ТС, отказ клиента, срочный заказ. Диспетчеризация — это цикл: план → факт → триггер → перепланирование.

• Триггеры. События, запускающие пересчёт: поздний визит, срыв окна, изменение объёма.
• Soft-компромиссы. Перепланирование почти всегда про «кого опоздать на 10 минут, чтобы не опоздать остальных на час».
• Explainability. Пользователь должен понимать, почему принято конкретное решение.

Пошаговая инструкция: настройка временных окон для реальной доставки

Практический план для логистической компании, которая хочет перейти от ручного диспетчирования к автоматической маршрутизации с учётом временных окон.

Шаг 1: аудит текущих данных о точках доставки

Соберите справочник точек доставки с реальными (не договорными) окнами приёма. Для каждой точки зафиксируйте: время начала приёма, время окончания приёма, перерывы (обед, пересменка), тип разгрузки (рампа, ручная, с пандусом), среднее время разгрузки (service time). Источники: договоры, диспетчерские журналы, данные TMS, опрос водителей. Критически важно отличать «официальное» окно (по договору) от «реального» (когда склад фактически принимает). Разница может составлять 1-2 часа. Например, договор говорит «до 18:00», но после 16:30 приёмка закрыта на инвентаризацию.

Шаг 2: классификация окон (hard vs soft)

Пройдитесь по каждой точке и определите тип окна. Hard window — физический запрет: склад закрыт, ворота заблокированы, охрана не пропустит. Soft window — договорное ожидание: штраф за опоздание, снижение уровня сервиса, но доставка возможна. Типичное распределение: 20-30% точек имеют hard windows (крупные сети, регулируемые склады), 70-80% — soft windows. Для soft windows определите стоимость нарушения: штраф по договору, потеря лояльности клиента, стоимость повторного рейса. Эта стоимость станет penalty cost в целевой функции оптимизатора.

Шаг 3: калибровка service time и времени в пути

Service time (время на точке) — самый недооценённый параметр. Если он занижен, оптимизатор строит «идеальные» маршруты, которые разваливаются на первой точке. Соберите фактические данные за 2-4 недели: время прибытия на точку, время убытия. Рассчитайте медиану и 90-й перцентиль. Для планирования используйте 75-й перцентиль — это даёт буфер без чрезмерного «раздувания» маршрутов. Аналогично — время в пути: используйте данные навигатора с поправкой на время суток (утренний час пик, вечерний час пик, дневное «окно»). Константное время в пути — гарантированные опоздания.

Шаг 4: пилотный запуск и корректировка

Запустите оптимизатор на реальных данных одного дня. Сравните результат с фактическим маршрутом диспетчера: количество обслуженных точек, время возврата на базу, количество нарушений окон. Типичный результат первого прогона: оптимизатор обслуживает на 10-15% больше точек в окно, но 5-10% точек «не помещаются» (в ручном режиме диспетчер нарушал окна, не фиксируя это). Это нормально — корректируйте окна и service time по результатам первой недели. Через 2-3 итерации модель стабилизируется.

Совет. Не верьте данным о service time из договоров. Договор говорит «разгрузка 30 минут», а факт — 45-60 минут (очередь на рампу, оформление документов, пересчёт). Используйте только фактические данные из TMS или GPS-трекеров.

Типичные ошибки при работе с временными окнами

Ошибки в настройке окон и параметров приводят к тому, что оптимизатор выдаёт формально «оптимальные», но практически невыполнимые маршруты.

Ошибка 1: все окна — hard

Если все окна жёсткие, оптимизатор часто возвращает «невыполнимо» или строит маршруты с большим количеством необслуженных точек. Диспетчер возвращается к ручному режиму — «оптимизатор не работает». В реальности 70-80% окон — soft: клиент предпочитает доставку в окно, но примет и с небольшим опозданием. Решение: используйте soft windows с penalty cost. Жёсткие окна — только для точек, где нарушение физически невозможно (закрытый склад, регуляторные ограничения).

Ошибка 2: игнорировать ожидание (waiting cost)

Машина приехала на 40 минут раньше открытия окна — стоит и ждёт. Если waiting cost = 0, оптимизатор считает ожидание «бесплатным» и строит маршруты с систематическими ранними прибытиями. Водитель простаивает, загрузка флота падает. Решение: задайте waiting cost (стоимость 1 минуты ожидания). Обычно это стоимость часа работы водителя + амортизация ТС. Оптимизатор начнёт балансировать: иногда выгоднее объехать другую точку и вернуться, чем ждать 40 минут.

Ошибка 3: не обновлять окна после изменений у клиентов

Клиент поменял график работы склада, но в справочнике — старые окна. Оптимизатор строит маршрут по устаревшим данным, водитель приезжает к закрытому складу. Повторный рейс на следующий день — двойные затраты. Решение: ежеквартальная верификация справочника окон. Автоматическое выявление расхождений: если plan-fact показывает, что на точке систематически (3+ раза в месяц) происходит ожидание > 30 минут или отказ в приёме — это сигнал к обновлению окна в справочнике.

Чек-лист внедрения VRPTW

Используйте для контроля прогресса при переходе на автоматическую маршрутизацию с временными окнами.

• Справочник точек: для каждой точки зафиксированы реальные (не договорные) окна приёма; определён тип окна (hard / soft); задан service time по фактическим данным (медиана или 75-й перцентиль); указаны ограничения (тип разгрузки, вместимость рампы).
• Параметры модели: заданы penalty costs для soft windows (стоимость минуты опоздания); задан waiting cost (стоимость минуты ожидания); время в пути учитывает время суток (пиковые / непиковые часы); парк описан (вместимость, тип, ограничения).
• Пилотный запуск: проведён прогон на реальных данных 1 дня; результат сравнён с фактическим маршрутом диспетчера; откалиброваны service time и окна по результатам первой недели; зафиксирован baseline (OTIF, количество нарушений окон, пустые пробеги).
• Эксплуатация: настроен plan-fact мониторинг (план vs факт по каждому маршруту); определены триггеры для replanning (опоздание > X минут, отмена точки, срочный заказ); справочник окон обновляется не реже раза в квартал; водители обучены работе с новым процессом.

Совет. Начните с одного региона или одной базы. Полный запуск VRPTW на всех маршрутах одновременно — рецепт хаоса. Пилот на одном регионе позволяет откалибровать параметры и набрать доверие диспетчеров. Масштабирование — после 2-4 недель стабильной работы.

FAQ

Источники

• Desaulniers et al. (2014): Column generation for VRPTW. Ссылка
• Braysy & Gendreau (2005): VRP with Time Windows, Survey. Ссылка