AI-оптимизация маршрутов: где уходит пробег и срываются окна
Смена начинается с сотен адресов, из которых нужно собрать рейсы под окна доставки, тоннаж, габариты и режим труда водителя. Ручное планирование идёт последовательно: диспетчер раскладывает точки по зонам и набивает машину, пока не упрётся в лимит, — поэтому соседние адреса уезжают разными рейсами. При 40–60 остановках на маршрут перебор вариантов вручную уже невозможен: допустимых комбинаций на порядки больше, чем диспетчер успевает проверить за смену, и лишний пробег транспорта растёт вместе с числом точек.
Узкое место в маршрутизации — не нехватка машин, а конфликт ограничений. Жёсткие интервалы доставки, вес, объём, время на разгрузку, перерывы и запреты на проезд грузового транспорта нельзя оптимизировать по очереди: улучшение одного показателя ломает другой. Правила планирования, зашитые годами ранее — фиксированные районы, «каждая машина по своему направлению», — расходятся с реальной картой спроса. Данные о точках тоже разрозненны: адреса без координат, окна в свободном тексте комментария, время в пути из усреднённых справочников вместо фактических замеров по часам и дням недели.
Отсюда систематический перерасход, а не разовая ошибка диспетчера: пробег выше оптимального, срывы окон доставки на части рейсов, ручные правки прямо в дороге. Разбираем, как это закрывается: как ограничения выносятся в явную модель, откуда берутся фактические времена в пути и почему задача решается перебором с отсечением недопустимых вариантов, а не эвристикой «по зонам» — для этого используют решатели класса задач маршрутизации парка, например Google OR-Tools.
Эффект внедрения: пробег, загрузка транспорта, срывы окон
Эффект считаем не от идеальной математики, а от базовой линии: две-три недели телеметрии до внедрения, та же номенклатура заказов, те же окна и тот же парк. Такое сравнение показывает вклад планировщика в результат, а не сезонные колебания спроса — иначе цифры невозможно защитить перед руководством.
| Метрика | Как измеряем | Что меняется |
|---|---|---|
| Пробег | Сумма по трекам за смену | Уходят лишние переезды между зонами |
| Загрузка транспорта | Занятый вес и объём к доступному | Соседние точки собираются в один рейс |
| Порожние рейсы | Доля пути без груза | Обратная загрузка ищется в том же окне |
| Окна доставки | Доля доставок внутри интервала | Время прибытия пересчитывается на ходу |
| Ручные правки | Число правок диспетчера за смену | Переносы и возвраты становятся правилами |
Отдельный результат — устранённый класс отказов, где опоздание на одну точку ломает весь маршрут: водитель доезжает до клиента вне окна, тот переносит приёмку, остальные адреса сдвигаются каскадом. Планировщик держит ограничения по времени и вместимости одновременно, поэтому такие цепочки просто не собираются, а срывы окон перестают быть массовым явлением.
Граф дорог и ограничения строим на открытых данных OpenStreetMap с поправкой на фактические треки и запреты по подъезду, поэтому оценка прибытия не расходится с реальностью. Замеры ведём на той же телеметрии, по которой потом принимается результат.
Предсказуемость окон важнее абсолютного минимума пробега: маршрут, который стабильно укладывается в интервалы, снимает ручной контроль. Диспетчер занимается исключениями, а не пересборкой смены.
Форматы оптимизации: онлайн-пересчёт, ночной пакет, гибрид
Режим расчёта выбирают не по «мощности» алгоритма, а по ритму смены и качеству входных данных. Если заказы приходят в течение дня, а адреса и объёмы меняются на ходу — нужен онлайн-пересчёт; если маршрут фиксируется на сутки и данные подтверждены заранее, устойчивее пакет. Ниже — сравнение подходов к маршрутизации по применимости и ограничениям.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Онлайн-пересчёт маршрутов | Заказы и статусы идут потоком: городская доставка, срочные заявки | Нужен постоянный канал связи и свежие статусы; без лимита на правки план «дрожит» и теряет доверие водителей |
| Пакетный расчёт рейсов | Маршрут фиксируется на смену, окна и объёмы подтверждены: межгород, регулярные рейсы | Не реагирует на события внутри дня; сход с линии или задержка — ручная перестройка у диспетчера |
| Гибридный режим планирования | Ночью строится базовый план, днём — точечные правки по отклонению | Нужны правила: порог отклонения, лимит правок на рейс, версии плана — иначе правки копятся хаотично |
Границы между режимами задаёт не логика расчёта, а допуски на изменения: сколько правок за смену выдержат диспетчер, водитель и клиент. Гибрид берут там, где онлайн-контур нужен, но постоянная перестройка мешает — порог отклонения и лимит правок на рейс оставляют план предсказуемым. Если поток статусов неполный или приходит с задержкой, онлайн-контур отдаёт мусорные маршруты: сначала налаживают сбор данных, потом включают пересчёт.
Как строится внедрение: от аудита данных до передачи в работу
Этапы выстраиваем так, чтобы каждый заканчивался артефактом, который можно проверить до перехода к следующему. Начинаем не с алгоритма, а с данных и правил: если в выгрузках нет фактических времён прибытия на точки или разъехались часовые пояса филиалов, маршрутизация выдаст расписание, которое диспетчер отменит на второй день.
Этапы внедрения маршрутизации
- Аудит логистических данных. Собираем выгрузки из учётной системы, телематики и путевых листов, сверяем полноту по периодам, ищем дубли, разрывы по геозонам и поездки без закрытия.
- Формализация ограничений. Окна доставки, тип и вместимость кузова, режим труда водителей, приоритеты клиентов — сводим в единую схему и согласуем её с диспетчерами, а не с их представлением о процессе.
- Подготовка геоданных. Нормализуем адреса, привязываем точки к карте, чиним битые координаты, собираем справочник складов и транспорта.
- Настройка целевой функции. Определяем, что оптимизируем — пробег, время в пути или равномерность загрузки — и задаём веса штрафов за нарушение окон.
- Проверка на исторических данных. Прогоняем решение на прошлых рейсах и сравниваем план с фактом: где расхождение объяснимо, а где указывает на дыру в правилах.
- Передача в работу. Диспетчеры получают рабочее место с ручной корректировкой, регламент разбора отклонений и метрики, по которым видно качество планирования день ко дню.
Документация и передача: конфигурации, схемы, регламенты
Сдаём не работающий сервис, а комплект, с которым ваша команда дальше работает сама. Конфигурации храним текстом в системе контроля версий, схемы описываем словами, а не оставляем в головах инженеров. Ниже — что именно остаётся у заказчика.
- Конфигурация маршрутизации: матрица ограничений — окна доставки, тоннаж и габариты, температурный режим, запретные участки, приоритеты клиентов.
- Схемы маршрутизации: как заказы раскладываются по рейсам и где граница между решением диспетчера и автоматическим расчётом.
- Роли доступа диспетчеров: кто меняет ограничения, кто только подтверждает, кто вправе переопределить маршрут вручную и как это фиксируется.
- Регламенты обновления правил: инициатор правки, проверка на истории прошлых дней, безопасный откат к предыдущей версии конфигурации.
- Документация по маршрутам: описание полей, справочников, форматов обмена с учётной и складской системами, включая разбор расхождений.
- Журнал переопределений: что диспетчеры меняли, где и почему — основа для следующего пересмотра правил.
- Инструкция по эксплуатации: типовые отказы, что проверять первым, к кому идти.
Перед сдачей разбираем каждый пункт вместе с диспетчерами и вашим инженером: они сами меняют ограничение и видят результат. Если правку нельзя внести без нас — передача не закрыта.
Разбор внедрения: пробег и срывы окон до и после
Точка старта
Маршруты собирались в таблице по фиксированным зонам: диспетчер вручную добивал заказы в уже сформированные листы, а порядок точек задавал опыт водителя. При плотной загрузке первые адреса уезжали за окно, и весь лист дальше шёл с опозданием на час-полтора.
На входе перепробег относительно расчётного минимума держался на 9-12%, срывы окон — 7-8% доставок. План на день верстался 3-4 часа и правился в течение смены, поэтому подтвердить окна заранее было нельзя.
Что изменили
Собрали модель ограничений: временные окна, тоннаж и объём кузова, режим труда водителей, запреты проезда для грузового транспорта. Время на переезды считали не по средней скорости, а по историческим данным телематики поверх дорожного графа из Яндекс.Карты — с учётом часовых пиков.
Маршруты пересчитываются вечером на факте прошедшего дня: отмены, новые адреса и фактическое время стоянок попадают в модель сразу. Диспетчер видит отклонение в момент его появления, а не утром следующего дня.
Что получилось
Через восемь недель постоянной работы: перепробег 3%, срывы окон 2%, верстка плана — 25 минут вместо половины смены. Результат удержался за счёт того, что правила и веса живут в настройках рядом с диспетчером, а не в коде: новый район или изменившийся режим точки вносится в тот же день.
Ограничение осталось одно: окна по 15 минут алгоритм закрывает, только если рядом есть второй заказ. Такие адреса выводим отдельным списком — диспетчер планирует их вручную.
Чем онлайн-пересчёт отличается от ночного пакетного расчёта
Отличие режимов маршрутизации — в горизонте, на котором считается план. Пакетный расчёт запускается по расписанию, видит весь накопленный объём заказов и ищет глобальный оптимум: минимум пробега, ровную загрузку машин, выполнимые окна доставки. Онлайн-режим работает не по расписанию, а по событиям — пришёл заказ, отменился, машина вышла из строя, график поехал. Он трогает не весь план, а участок, который ещё можно сдвинуть без вреда.
Соблазн гонять полный пересчёт на каждое событие понятен, но план начинает дрожать: водитель получает новый маршрут на середине смены, а рейс, который уже ушёл со склада, в расчёте вообще нельзя переиграть. Пересчёт во время смены поэтому строится на жёсткой границе — начатые рейсы замораживаются и участвуют только как ограничение: занятая машина, груз на борту, время возврата.
Выбор режима расчёта привязывают к событию и цене изменения. Пока сдвиг локальный, достаточно онлайн-режима; когда изменений накапливается больше порога — по доле гибких заказов или по числу затронутых машин, — решение уходит в пакетный расчёт и пересобирается целиком.
Чтобы план не переизобретался каждые несколько минут, в целевую функцию добавляют штраф за изменение уже обещанного маршрута и лимит на число трогаемых рейсов. Водитель видит одну последовательность точек, при этом критичные события отрабатываются сразу.
Так пакетный расчёт и онлайн-режим не конфликтуют: ночь задаёт базовый план и глобальный оптимум, смена — точечный ремонт внутри подвижной зоны. По мере смены подвижная зона сужается, а всё, что осталось гибким, уходит в следующую ночную пересборку.
Сомнения и ограничения: качество данных, интеграции, откат
Качество маршрута на выходе ровно такое, какое качество у справочника точек: дубли адресов, устаревшие временные окна, точки без координат и адреса вида «склад у кольца» превращают формально оптимальный маршрут в невыполнимый. Поэтому первый шаг — не расчёт, а разбор справочника: нормализация адресов, сведение дублей по координатам, проверка ограничений по массе, габаритам и времени разгрузки.
С учётной системой решение работает как надстройка, а не замена: заказы, контрагенты и статусы остаются в ней, оптимизатор читает их и возвращает план объезда и порядок точек. Обмен идёт по расписанию и по ключам заказов, поэтому повторная выгрузка не создаёт дублей и не ломает уже начатую доставку; если связи нет, маршрут считается по последней успешной выгрузке.
Справочник точек в беспорядке — с чего начинать?
Сначала разбираем данные: нормализуем адреса, сводим дубли по координатам и контрагенту, помечаем точки без временных окон и с нестандартной разгрузкой. Затем запускаем пилот на одном направлении и сверяем расчёт с фактическими рейсами — видно, где ошибаются данные, а где правила расчёта.
Диспетчер знает маршрут лучше — что тогда?
Расчёт — предложение, а не приказ. Диспетчер может закрепить точку, сдвинуть окно, оставить привычный порядок объезда; система запоминает такие правки как правила и учитывает их в следующих расчётах. Спорные точки выносим отдельным списком и разбираем вместе со службой доставки.
Как откатить изменения в правилах?
Правила версионируются: базовый набор, приоритеты, исключения по точкам и типам транспорта. Возврат к предыдущей версии не останавливает доставку — переключаем набор правил и пересчитываем маршруты на следующий день, прежний порядок объезда остаётся рабочим.
Обсудим задачу и вернёмся с оценкой и планом
Чтобы оценка опиралась на данные, а не на догадки, нужно несколько входных материалов. Достаточно выгрузок в том виде, в каком они есть сейчас — чистка и приведение к единому формату наша часть работы.
- Список точек доставки или обслуживания: адреса, окна приёма, ограничения по доступу и разгрузке.
- История рейсов за 2-3 месяца: фактические маршруты, время в пути, простои, отклонения от плана.
- Парк и режимы работы: типы машин, грузоподъёмность, смены водителей, обязательные перерывы.
- Правила, которые нельзя нарушать: приоритеты клиентов, запрет определённых улиц для крупного транспорта, регламенты по опасным грузам.
- Текущий процесс планирования: кто и в чём строит маршруты сегодня, где они правятся вручную.
- Что считаем результатом: сокращение пробега, число машин на линии, соблюдение временных окон.
Разбор идёт в два прохода. Сначала мы смотрим данные и текущий процесс: где план расходится с фактом, какие ограничения вообще не учитываются, сколько ручных правок приходится на день. Затем считаем, что даст автоматизация на вашем объёме — по каким участкам пробег падает, какие рейсы можно объединить, где узкое место не в маршрутах, а в расписании склада.
В оценку и план внедрения попадают: целевая схема расчёта маршрутов, перечень данных и ответственных за их выгрузку, этапы работ с проверяемым результатом на каждом, способ сравнения «до и после» по пробегу и времени, требования к интеграции с учётной системой и порядок запуска без остановки текущей логистики. Опишите задачу — вернёмся с оценкой и планом.
