Оптимизация загрузки транспорта: где ломается планирование
Пока рейсов десять, диспетчер держит в голове окна доставки, вес партий и порядок объезда. На тридцати маршрутах ручное планирование рейсов превращается в перебор: каждая новая заявка меняет уже собранные цепочки, а решение принимается по утренней картине, хотя к обеду она уже другая.
Первым ломается расписание окон. Клиенты с узкими интервалами приёма конкурируют за одни и те же часы, машина встаёт в очередь, и простой у рампы съедает смену водителя ещё до выезда. Чем плотнее график, тем дороже ошибка в порядке объезда: опоздание в одну точку сдвигает весь маршрут и срывает следующие окна.
Второе — кузов. Сборные рейсы собирают «по совести», и недогруз кузова на четверть выглядит нормой, пока не сравнишь с фактической потребностью точек. Рядом живёт порожний пробег: обратный путь машина проходит пустой, потому что подходящую попутную заявку вручную уже никто не ищет — она осталась в таблице, но не в маршруте.
В сумме задача перестаёт быть линейной. Число допустимых сочетаний «заявка — машина — окно» растёт быстрее, чем парк, и оптимизация загрузки транспорта упирается в предел человека: проверить все варианты, которые дали бы и полный кузов, и короткий порожний пробег, он физически не успевает. Разбираем, как это закрывается.
Что даёт ИИ-планирование рейсов и маршрутов
Планировщик на ИИ-планировании рейсов считает не отдельный маршрут, а всю матрицу заказов за смену: окна доставки, режим работы водителей, совместимость груза и кузова. Задача решается на решателе класса OR-Tools, поэтому эффект виден не на одном рейсе, а на утилизации парка целиком.
Порожний пробег падает за счёт обратной загрузки
К каждому рейсу «туда» планировщик ищет пару из обратных заявок и склеивает их в один маршрут, если совпадают окна и тип кузова. Доля порожних пробегов снижается с 30–35% до 12–15%, а оставшиеся перегоны становятся короткими подъездами к следующей точке вместо возврата в базу.
Средняя загрузка кузова и утилизация парка растут
Вместо ручного «кто свободен — того и грузим» алгоритм балансирует загрузку между машинами и добивает недогруженные рейсы попутными заявками. Средняя загрузка кузова выравнивается по парку: разброс, когда часть фургонов идёт вполовину объёма, а часть перегружена, уходит.
В один рейс влезает больше точек
Маршрут собирается по реальной геометрии проездов и времени на разгрузку, а не по средним нормативам. Число точек в рейсе растёт на 15–25% без нарушения окон доставки — рейсы, которые раньше делили на два, едут одним.
Уходит класс отказов планирования
Исчезают срывы из-за конфликтов в расписании водителей, перегруза по массе и двойного назначения машины на две заявки. Диспетчер видит причину, по которой заявка не встала в план, вместо ручной правки маршрутов.
Режимы планирования транспорта: правила, эвристики, модель
Режим планирования выбирают не по «умности» алгоритма, а по тому, какие данные есть у перевозчика и насколько жёсткие ограничения нужно удержать в плане. Чем больше неформализуемых исключений в смене, тем дороже ошибка планировщика — и тем важнее, чтобы режим ей соответствовал.
Ниже — четыре варианта, между которыми реально выбирают, когда строят оптимизацию загрузки транспорта. Они не заменяют друг друга: правила задают границы, эвристики дают скорость, модель — качество плана.
Три режима и их границы
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Жёсткие правила | Парк и плечи стабильны, регламенты зафиксированы, нужен объяснимый план на смену | Не находит неочевидных уплотнений: загрузка растёт только пересмотром самих правил |
| Эвристики планирования | Нужен быстрый план на день, условия меняются частично | Решение близко к ручному, качество зависит от набора правил, на сложных маршрутах уступает оптимизации |
| Модель на исторических данных | Есть путевые листы и телеметрия за сезон, спрос колеблется | Чувствительна к качеству данных и редким событиям, готовый план нужно проверять |
| Смешанное планирование | Нужно одновременно выжать загрузку и уложиться в режим труда и отдыха водителя | Требует прозрачных логов: без объяснения плана диспетчер перестаёт доверять системе |
Смешанное планирование обычно и становится рабочим: модель предлагает маршруты, правила отсекают недопустимые, а ограничения режима работы водителя держатся отдельным слоем проверок. Дальше выбор — за вашей операционной реальностью.
Как проходит внедрение: от аудита данных до передачи
Внедрение начинается не с модели, а с данных. Пока не ясно, какие выгрузки о рейсах есть у заказчика и в каком они состоянии, любая оптимизация загрузки транспорта остаётся теорией — поэтому первые недели уходят на разбор фактических данных и согласование того, что система считает хорошим планом.
- Аудит данных о рейсах. Разбираем выгрузки из учётных систем, данные телематики и логистические таблицы: полнота записей, дубли, расхождения по времени и весу, пропуски в точках маршрута. Результат — карта источников и перечень того, что восстанавливаем, а что исключаем из расчёта.
- Постановка целевой функции. Фиксируем, что именно оптимизируем: общий пробег, долю порожних прогонов, соблюдение окон доставки или их комбинацию с весами. Ограничения — грузоподъёмность, режим работы водителя, совместимость грузов — согласуем письменно, это база для приёмки.
- Пилот на исторических рейсах. Прогоняем систему на прошлых рейсах и сравниваем её план с фактическим: где удалось сократить пробег, а где предложенный маршрут невыполним. Логику проверяем до того, как она коснётся живых перевозок.
- Настройка на рабочем контуре. Подключаем систему к текущим источникам, настраиваем обмен и права доступа, договариваемся о том, как диспетчер принимает или отклоняет предложенный план.
- Промышленный запуск. Переводим планирование в ежедневный режим, следим за метриками загрузки и стабильностью расчёта, дообучаем правила на новых данных.
- Передача системы. Отдаём конфигурации, схемы обмена, регламенты и инструкции, проводим обучение диспетчеров и сопровождаем команду заказчика первые циклы планирования.
Что остаётся у заказчика: конфигурации, схемы, регламенты
Материальный результат внедрения — не отчёт и не демонстрация, а работающий контур, который ваша команда может сопровождать и развивать без нас. Поэтому передаём настроенную систему, её описание и правила эксплуатации: всё, что нужно, чтобы планирование оставалось управляемым при смене объёмов, маршрутов и людей.
- Конфигурация планировщика: приоритеты клиентов и типов груза, ограничения по вместимости, окнам доставки и совместимости грузов в одном рейсе; параметры собраны в редактируемый набор — менять их можно без правки кода.
- Схема интеграции с учётными системами: какие справочники и события откуда поступают, с какой периодичностью, что происходит при недоступности источника, где проходит граница ответственности между системами.
- Регламент перепланирования: в каких случаях пересчёт запускается автоматически (новый заказ, отмена, срыв окна), а где решение остаётся за диспетчером; окно заморозки плана перед выездом машин.
- Документация на систему: описание логики распределения, справочник параметров с допустимыми диапазонами, инструкции для диспетчера и администратора.
- Матрица ответственности: кто владеет справочниками, кто утверждает изменения правил, кто разбирает расхождения между планом и фактом.
- Журнал решений: сохранение причин, по которым заказ попал к конкретной машине, — для разбора спорных ситуаций без восстановления логики задним числом.
- Проверочные сценарии: эталонные дни с известным результатом, на которых видно, что после правок конфигурации решение не деградировало.
Кейс: утилизация парка и порожние пробеги до и после
Автоколонна из 140 машин планировала рейсы вручную в учётной системе 1С:УАТ: диспетчер собирал плечи по опыту и телефонным договорённостям, а обратную загрузку искал уже после выгрузки. Машина уходила с неполным кузовом, обратный пробег часто шёл порожняком, и утилизация парка держалась на авралах в конце месяца. Срывы окон доставки копились там, где новый рейс ставили сразу за предыдущим, без запаса на разгрузку.
Мы сняли метрики до и после на сопоставимых периодах, а планирование перевели в режим подсказки: система предлагает вариант загрузки под кузов и жёсткие окна доставки, диспетчер подтверждает или отклоняет.
| Метрика | До | После |
|---|---|---|
| Доля порожних пробегов | 36% | 17% |
| Средняя загрузка кузова | 62% | 85% |
| Срывы окон доставки | 8% рейсов | 2% рейсов |
| Простой у рампы | 45 мин | 22 мин |
| Время диспетчера на план смены | 3,5 ч | 25 мин |
Важна не пиковая цифра, а воспроизводимость. Ограничения по клиентам, типу кузова и времени у рампы закреплены правилами, поэтому результат не зависит от того, кто сидит на смене. Кейс оптимизации рейсов дал и побочный эффект: освободившееся время диспетчер тратит на нестандартные рейсы и разбор отклонений, а не на рутинный перебор вариантов.
Что делать, если часть рейсов уже планируется вручную
Частичная автоматизация — это штатный режим, а не промежуточный этап, который нужно поскорее перерасти. Планировщик подключается к тому, что уже есть: реестр заявок в таблицах, справочник адресов и временных окон, ограничения по кузову, тоннажу и режиму труда водителей. На выходе диспетчер получает не пустой лист, а готовый черновик маршрутов, который остаётся проверить и при необходимости поправить.
Переход с ручных графиков идёт по одному участку за раз. Сначала в расчёт берут направление или группу машин, где данные уже ведутся аккуратно, и сверяют машинный план с тем, что диспетчер строил руками. Когда расхождение по пробегу и времени выезда становится объяснимым, участок переводят на автоматический расчёт, а следующий подключают после того, как первый отработал полный цикл.
Внеплановые заявки обрабатываются отдельным правилом. Срочный заказ либо достраивается в уже сформированный маршрут, если попадает в коридор по времени и загрузке, либо получает отдельную машину с приоритетом по окну доставки. Диспетчер в любой момент может снять автоматику и перепланировать вручную — система предлагает вариант, а не блокирует решения.
Смысл поэтапного внедрения в том, что текущий процесс не останавливается ни на день. Параллельно с новым контуром продолжает жить привычный график, данные из таблиц поступают в систему на каждом шаге, а доля рейсов, которые считаются без правок, растёт от недели к неделе. Если результат расходится с ожиданиями, участок возвращается к ручному планированию без потери наработок.
Частые технические вопросы о данных и точности модели
Сомнения на этом этапе обычно одинаковые: хватит ли данных, не разойдётся ли расчёт с реальностью и что делать, когда заявка приходит вне плана. Ниже — четыре вопроса, которые чаще всего поднимает команда заказчика до старта.
Оптимизация загрузки транспорта начинается не с модели, а с инвентаризации источников: справочника точек, ограничений по кузову, истории фактических выездов.
Данные лежат в Excel и трёх системах — этого хватит?
Для старта достаточно истории рейсов и справочника точек с окнами доставки. Мы сводим источники в один слой, помечаем пробелы и задаём правила заполнения; где истории нет, ограничения вводятся явно и согласуются с диспетчером.
Как проверить, что план выполним, а не только «оптимален»?
Каждый маршрут проходит проверку ограничений: тоннаж и объём, режим труда водителя, окна доставки, доступность транспорта. Невыполнимые варианты отсекаются до выдачи — расчёт идёт на решателе OR-Tools, а точность сверяем по факту: доля рейсов без ручных правок и сорванных окон доставки.
Что происходит со срочной заявкой в середине дня?
Пересчёт идёт на текущем состоянии парка: свободные машины, уже начатые рейсы, ближайшие окна. Заявка встраивается в маршрут с минимальным отклонением по пробегу, изменения уходят диспетчеру и водителю.
Что будет после запуска — поддерживать всё самим?
Нет. Передаём конфигурацию, правила проверки и документацию, обучаем диспетчеров. Сопровождение — по договорённости: следим за качеством данных и точностью модели, пересматриваем ограничения при изменении парка и появлении новых точек.
Обсудим задачу: какие данные прислать для оценки
Чтобы вернуться с оценкой и планом работ, а не с общими словами, нам достаточно одного набора вводных. Ниже — минимальный комплект данных для оценки: он собирается силами вашей учётной системы за пару часов и не требует остановки процессов. Если части пунктов нет — это не блокирует обсуждение задачи, отсутствие данных тоже входит в состав работ.
- Выгрузка рейсов за характерный период: дата, направление, транспорт, фактическое время выхода и возвращения.
- Данные по заявкам: адреса точек, временные окна доставки, вес и объём груза, тип кузова.
- Справочник транспорта и водителей: вместимость, ограничения по тоннажу, доступное время смен.
- История простоев: время ожидания под погрузкой и разгрузкой, причины срывов по факту, а не по регламенту.
- Действующие правила распределения: кто и по какой логике сейчас закрепляет машину за рейсами.
- Ограничения: рабочие часы складов, зоны обслуживания, приоритеты клиентов, ночные выезды.
- Целевые показатели: что считаем улучшением — доля загрузки, число рейсов, повторные выезды.
Формат не важен: подходят выгрузки из учётной системы, файлы таблиц или набор отчётов — приведём к единому виду на своей стороне. Опишите задачу в свободной форме и приложите то, что уже есть: вернёмся с оценкой объёма, составом работ и сроками по этапам. Если данных пока недостаточно, предложим минимальный срез, который закроет вопрос загрузки транспорта.
