INTEBRIX Optimization Platform

Материалы • Dispatching • Time windows

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

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

10–12 минут VRPTW SLA Service time Hard/Soft Penalties Replanning
Термины из статьи в глоссарии: VRPTW, SLA, Service time, Dwell time, Hard/Soft windows, Penalties, Waiting, Trip/Route, Empty miles.

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

В классическом VRP (Vehicle Routing Problem) маршрут “лучше”, если он короче и дешевле. Но как только появляются временные окна, задача становится VRPTW: теперь важна не только география, но и возможность обслужить каждую точку в нужный момент. Любое несоответствие по времени даёт либо ожидание, либо нарушение SLA.

Временные окна
Интервалы, в которые точка может быть обслужена. Узкие окна повышают стоимость и уменьшают плотность маршрутов. См. VRPTW и Time windows.
Service time и простои
Время на точке (разгрузка, оформление, ожидание) сдвигает расписание и создаёт каскадные опоздания. См. Service time и Dwell time.
Смена и ограничения исполнения
Ограничения по сменам, возврату на базу, типам ТС, совместимости грузов и доступности водителей. См. Fleet и Trip/Route.
Управленческая формулировка VRPTW: “построить исполнимый план рейсов с заданным уровнем сервиса, минимизируя стоимость транспорта, ожидания и штрафы за нарушения”.

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

В практической модели важно различать: где окно является физическим запретом, а где — договорным ожиданием. Это определяет, будет ли оптимизатор искать решения “любой ценой” или управлять компромиссами через штрафы.

Hard windows (жёсткие)
Нарушение запрещено. Пример: склад принимает строго до 16:00; после — отказ/штраф/перенос на сутки. В модели это жёсткое ограничение: если не укладываемся, маршрут нельзя считать исполнимым.
Soft windows (мягкие)
Нарушение допустимо, но имеет цену. Пример: доставка “желательно 10:00–12:00”, но можно с опозданием с ухудшением SLA и компенсацией. В модели это penalty cost.
Практическое правило
Если объявить все окна жёсткими — вы быстро получите “невыполнимо” и постоянное ручное диспетчирование. Если объявить все окна мягкими — получите “выполнимо” на бумаге и деградацию сервиса в реальности. Нужна матрица: какие точки hard, какие soft, и какая цена отклонений.

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

Когда окна добавлены, возникает “стоимость времени”. Она проявляется в ожиданиях, простоях и росте числа рейсов/машин для соблюдения SLA. Это не всегда видно в метрике “километры”, но напрямую влияет на cost-to-serve.

Waiting (ожидание окна)
Машина приезжает раньше — ждёт. Ожидание может быть правильным решением, но его нужно учитывать как стоимость. См. Waiting.
Dwell time (очереди/разгрузка)
Если dwell time занижен в данных, оптимизация строит “идеальные” планы, которые разваливаются в исполнении. См. Dwell time.
Empty miles (пустые пробеги)
Появляются, когда окна и парк не совпадают со спросом. Часто лечится изменением fleet mix или правил консолидации. См. Empty miles.
Для управленческого контроля удобно сравнивать сценарии по формуле: transport cost + waiting cost + penalty cost. Тогда оптимизация не “хакнет” KPI, а будет отражать реальную цену сервиса.

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

“Исполнимость” — это не факт существования маршрута, а способность выполнить все визиты с учётом окон, service time, смен, ограничений парка и правил загрузки. Ниже — минимальный набор метрик, которые стоит поставить в регулярный мониторинг.

Service level / SLA
Доля визитов в окно, доля поздних/ранних визитов, 95-перцентиль опозданий. См. Service level.
Время на точках
Среднее и распределение service time + dwell time; точки-“пожиратели смены” почти всегда дают каскад проблем.
План-факт
Сопоставление плана и факта с причинами отклонений: пробки, очереди, переносы, отсутствующие данные. См. Plan-fact.
Типовые ошибки в данных
  • Окна указаны “идеальные”, а не реальные (исключения/обеды/закрытия не учтены).
  • Service time задан константой, хотя зависит от объёма, паллет, типа клиента.
  • Время в пути не соответствует реальности (нет городской/межгородской поправки).
  • Парк не описан: ограничения по вместимости/типу кузова/температуре игнорируются.
Как понять, где “узкое место”
  • Если много ожиданий — окна слишком узкие или порядок визитов не учитывает расписание.
  • Если много поздних визитов — не хватает буфера/парка или занижено service/dwell time.
  • Если растут пустые пробеги — проблема fleet mix или ограничений по совместимости/консолидации.
  • Если всё “невыполнимо” — слишком много hard-ограничений без возможности компромисса.

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

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

Триггеры
События, которые запускают пересчёт: поздний визит, срыв окна, изменение объёма, снятие/добавление точки. См. Triggers.
Soft-компромиссы
Перепланирование почти всегда про компромисс: “кого опоздать на 10 минут”, чтобы не опоздать остальных на час. Это и есть управляемые penalties.
Explainability
Пользователь должен понимать “почему так”: какие ограничения/штрафы привели к решению. См. Explainability.
Практическая цель replanning
Не “идеальный” маршрут, а устойчивое исполнение: минимизировать каскад срывов, удержать SLA и прозрачно показать цену компромисса (штрафы/ожидания/дополнительные рейсы).

Источники и публичные эффекты

Мы не заявляем “проценты эффективности” для всех сценариев — эффекты зависят от данных и ограничений. Ниже — публичные ориентиры из открытых материалов, которые показывают, что оптимизация маршрутов и управление временем действительно дают измеримые результаты на масштабе.

Если хотите “цифры под себя”: на пилоте фиксируем baseline (план-факт), затем считаем сценарии: cost-to-serve, SLA, ожидания, пустые пробеги, потребность в ТС/сменах. Дальше — регламент replanning.
Хотите проверить VRPTW-постановку на ваших ограничениях?
Достаточно мини-брифа на 10 минут: типы точек, окна, парк, правила загрузки, SLA/штрафы. Мы покажем, как строится исполнимое расписание рейсов и как система перепланирует при событиях.