Чому AI-оптимізація маршрутів доставки ламається на реальних даних
Класичний збій: алгоритм видає гарний план на 40 машин, а до обіду диспетчер вручну перетасовує половину рейсів.
Причина в тому, що планування рейсів рахується за статичним графом доріг, тоді як факт залежить від перекриттів, сезонного трафіку й погоди, яких у моделі на вході просто немає.
Розрив між розрахунковим часом у дорозі та спостережуваним — зазвичай найбільше джерело помилки, і він тягне за собою все інше.
Якість вхідних даних дає другу порцію розбіжностей. Різні написання адрес, координати за центроїдом будівлі, відсутність поверху й під'їзду — і точка на карті стоїть там, де машина не стане.
Нормалізація адресного довідника, прив'язка до входів і окремий шар історичних замірів часу розвантаження дають більше приросту, ніж будь-яке ускладнення самого розв'язувача.
Обмеження за вантажем і вікнами доставки додають жорсткості, яку не можна порушити.
Вага й габарит кузова, сумісність товарних груп, робота холодильника, режим роботи точки та закриті інтервали приймання — кожна така зв'язка робить задачу не «знайти найкоротший шлях», а «вкластися в допустиму множину».
Тут же спливають вузькі місця диспетчеризації: той самий автомобіль потрібен двом клієнтам із несумісними вікнами, і рішення доводиться шукати з відкатом.
Ручні правки диспетчера — не саботаж, а сигнал. Він бачить контекст, якого немає в даних: клієнт просить приїхати раніше, у водія закінчується зміна, на об'єкті сьогодні розвантаження до полудня.
Якщо правки не повертаються в модель, оптимізація маршрутів доставки деградує: план усе точніший на папері й усе далі від двору. Далі розбираємо, як це закривається.
Що змінюється після впровадження: ефект у вимірюваних метриках
Ефект оптимізації маршрутів рахується не за відчуттями, а за метриками, які знімаються на історичних даних до старту й повторюються на тому самому обсязі замовлень після запуску. Нижче — набір, який ми фіксуємо у звіті за кожним контуром доставки.
- Скорочення пробігу — сумарний кілометраж на зіставній кількості точок падає на 8–15%: маршрутизатор збирає ланцюжки за часом і геометрією, а не в порядку надходження заявок.
- Порожні рейси — частка перегонів без вантажу йде вниз, бо зворотне завантаження планується в тому самому проході, а не окремим дзвінком диспетчера.
- Частка запізнень за вікнами доставки — рахується за фактом в'їзду на точку; жорсткі вікна й пріоритети клієнтів задані обмеженнями, тому план не розсипається на першій же пробці.
- Навантаження диспетчера — час на ручні правки скорочується з годин до хвилин: система перебудовує день у разі зриву вікна, а людина підтверджує зміни.
- Рівномірність завантаження — розкид кількості точок і ваги по машинах зменшується, крайні перевантаження рейсів ідуть.
Метрики збираються автоматично, тому ефект видно в динаміці по тижнях, а не один раз на презентації. Рахує план розрахункове ядро на Google OR-Tools — воно перебирає варіанти під задані обмеження й повертає кілька рівноцінних рішень на вибір.
Режими роботи: онлайн-перерахунок, пакетний розрахунок, гібрид
Режим планування вибирають не за смаком, а за двома величинами: як часто в системі з'являються нові замовлення й наскільки дорого змінювати вже узгоджений рейс.
Перерахунок маршруту в момент надходження замовлення дає мінімальний пробіг, але кожну зміну доводиться підтверджувати з водієм і клієнтом. Рідкісний пакетний розрахунок дешевший у супроводі, зате гірше реагує на сплески навантаження в середині дня.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Онлайн-перерахунок маршрутів | Замовлення йдуть потоком увесь день, вікна доставки короткі, склад точок змінюється динамічно | Потрібен швидкий розв'язувач і постійний канал до водія; надто часті правки плану збивають виконавців |
| Пакетний розрахунок рейсів | Замовлення збираються заздалегідь, доставка на наступний день, рівний парк машин | Плану немає до моменту запуску; термінове замовлення в середині дня ламає вже зібрані рейси |
| Гібридне планування | Основний обсяг плановий, але регулярно з'являються термінові врізки | Складніше в налаштуванні: потрібні правила, що саме дозволено перебудовувати і як часто |
На практиці вибір режиму оптимізації зводиться до частоти перерахунку.
Ми заміряємо, скільки замовлень надходить після старту зміни, який відсоток відмов від уже призначених точок прийнятний для диспетчерської і з якою швидкістю водій підтверджує нове завдання — за цими цифрами режим або закріплюється, або змінюється.
Гібридне планування майже завжди будується на розділенні рейсу: жорсткий каркас з адресами та часовими вікнами фіксується, а вільна частина — неповні слоти, попутні точки — перераховується за подією.
Частота перерахунку стає налаштовуваним параметром: раз на годину для планового контуру, миттєво для термінових замовлень, із забороною чіпати рейси, де водій уже в дорозі.
Етапи впровадження: від аудиту даних до передачі в експлуатацію
Впровадження розбивається на короткі етапи з перевірюваним результатом після кожного.
Порядок не випадковий: правила планування не можна налаштовувати раніше, ніж зрозуміло, які обмеження взагалі є в даних, а перевіряти якість плану безглуздо до того, як диспетчери погодилися з логікою розрахунку.
- Аудит даних про доставку. Вивантажуємо історію рейсів, адреси точок, часові вікна одержувачів, вагу й габарити вантажу, режим праці водіїв. Рахуємо частку адрес без точної геоприв'язки, замовлень без вікна й дубльованих точок — саме ці прогалини дають нереалістичні строки в розрахунку.
- Схема рішення. Визначаємо, що рахує система, а що залишається за людиною: жорсткі обмеження (вантажопідйомність, час зміни, заборони проїзду) і м'які переваги (постійні клієнти, рівномірне завантаження машин). Фіксуємо, що саме оптимізуємо — пробіг, кількість машин чи дотримання вікон.
- Налаштування правил планування. Правила, які диспетчер тримає в голові, переводимо у формальні обмеження й ваги. Кожне перевіряємо на конфлікт з іншими, спірні пари розводимо за пріоритетами, щоб розрахунок не «зависав» на взаємовиключних умовах.
- Перевірка на історичних рейсах. Проганяємо план на закритих періодах і порівнюємо з фактом: пробіг, запізнення, кількість задіяних машин, частка ручних правок. Розбіжності розбираємо разом із диспетчерами, уточнюємо правила й повторюємо цикл, поки відхилення не стануть зрозумілими.
- Пробний запуск на одній ділянці. Один філіал або зміна працює в системі паралельно зі звичним плануванням: звіряємо результат у реальному часі, знімаємо заперечення диспетчерів до того, як змінювати процес цілком.
- Передача в експлуатацію. Передаємо конфігурацію, регламенти й порядок ручних правок, навчаємо диспетчерів на їхніх же маршрутах, фіксуємо ролі й права доступу. Далі — супровід і доналаштування правил за фактичними даними.
Що передаємо на руки: конфігурації, схеми та регламенти
Віддаємо не «чорну скриньку», а систему, яку ваша команда може розвивати й обслуговувати самостійно. Правила планування винесені в конфігурацію, доступи описані ролями, поведінка при збоях зафіксована в регламентах — рутинні зміни не потребують звернення до розробників.
- Конфігурація правил планування: пріоритети клієнтів, часові вікна, вантажопідйомність і сумісність транспорту, штрафи за порушення вікна — правляться в окремому файлі без перезбирання системи.
- Схема потоків даних: шлях заявки від облікової системи через перевірку адрес і розрахунок матриці відстаней до готового маршруту в інтерфейсі диспетчера — з точками відмови й повторами за недоступності зовнішніх сервісів.
- Політики доступу до системи: ролі диспетчера, логіста, аналітика й адміністратора, видимість за філіалами, журнал дій і порядок видачі прав.
- Документація рішення: обмеження алгоритму, довідник параметрів, порядок оновлення карт і тарифних зон.
- Регламент роботи диспетчера: приймання перерахованого маршруту, розбір нерозпізнаних адрес, умови переведення замовлення на ручне планування.
- Набір перевірок і метрик: тестові сценарії на історичних днях, звіт за часткою автоматично побудованих маршрутів і відхиленнями від плану.
Комплект передаємо разом з навчанням ваших фахівців: розбираємо конфігурацію, проганяємо типові збої, фіксуємо, до кого йти з питаннями за кожним блоком.
Кейс: парк доставки після переходу на AI-планування рейсів
Кейс: дистриб'ютор із власним парком і двома складами
Точка відліку
Планування трималося на диспетчері: він збирав заявки, розкидав точки по машинах у таблиці й вручну розрулював перетини вікон доставки. Лише на ранкові правки йшло близько трьох годин, а до обіду з'являлися термінові замовлення — і частину рейсів перекроювали на ходу.
Машини їхали через усе місто, пробіг зростав, доставка в строк трималася близько 87%, частину точок водії проходили не по дорозі.
Що змінили і що отримали
Модель побудували на історії рейсів, фактичних часів у дорозі й простоїв на розвантаженні, додали обмеження: вікна доставки, вантажопідйомність, режим праці водіїв, пріоритети клієнтів.
План рахується на кілька днів уперед і повністю перераховується, коли надходить термінове замовлення — диспетчер бачить не весь розклад, а лише точки, які його зламали. Ручні коригування залишилися для нестандартних випадків, але стали точковими, а не щоденними.
- Пробіг на маршрут скоротився на 18% за того самого обсягу замовлень.
- Кількість рейсів зменшилася на 12%: частину точок об'єднали в один виїзд.
- Доставка в строк зросла з 87% до 98%, запізнення з вини планування майже зникли.
- Час диспетчера на ручне коригування — з трьох годин до півгодини за зміну.
- Відмови через зсунуті вікна доставки скоротилися вдвічі.
Такий розрив між «до» і «після» дає не окрема формула, а зв'язка моделі з обмеженнями реального парку й зрозумілим процесом перерахунку плану.
Чим потокова оптимізація відрізняється від пакетного перерахунку
Пакетний перерахунок маршрутів працює вікнами: заявки вивантажуються з облікової системи, розв'язувач рахує матрицю часу в дорозі за всім пулом і повертає готовий план цілком.
План виходить стійким і зрозумілим, але всередині вікна система не бачить ні нового замовлення, ні скасування — усе чекає наступного запуску.
Потокова оптимізація тримає маршрут живим: заявка або збій потрапляють у чергу, перераховується лише зачеплена ділянка, оновлення йде водієві за секунди. Швидкість реакції на збій зростає, але режим вимагає дисципліни щодо стабільності видаваного маршруту.
| Критерій | Пакетний перерахунок | Потокова оптимізація |
|---|---|---|
| Швидкість реакції на збій | до наступного вікна плану | секунди, перерахунок зачепленої ділянки |
| Обсяг даних за цикл | повне вивантаження заявок і матриці | лише дельта: нова заявка, зміна статусу |
| Стабільність маршруту | висока, план не змінюється всередині вікна | задається порогами зсуву |
| Обмін з обліковою системою | пакетний обмін за розкладом | події та зворотний запис статусів |
Стабільність — головний компроміс. У потоковому режимі ми фіксуємо вже відвантажені точки, обмежуємо кількість перестановок на маршрут і задаємо поріг зсуву: поки виграш за часом у дорозі нижчий за поріг, план не чіпаємо. Інакше водій отримує новий маршрут кожні кілька хвилин і перестає йому довіряти.
Обмін з обліковою системою йде в обидва боки, різниться лише частота. Пакет підходить, коли замовлення надходять хвилями; потік — коли важлива реакція на збій у моменті. Частіше збирають гібрид: нічне вікно будує базовий план, денні коригування вносять точкові правки.
Технічні сумніви: дані, інтеграції та контроль диспетчера
Перед запуском замовники ставлять ті самі питання: що робити з неповними даними про дорожню обстановку, як вбудуватися у вже розгорнуту систему планування і чи залишиться ручне підтвердження маршруту в диспетчера.
Що робити, якщо дані про дорожню обстановку неповні?
Ми не будуємо план на одному джерелі. Розклади рейсів і обмеження беремо з облікової системи, дорожній граф — з відкритих карт, наприклад OpenStreetMap, а фактичний час проїзду накопичуємо з історії виконаних замовлень.
Там, де даних немає, система рахує не «середнє по місту», а діапазон: план будується за консервативною оцінкою, а факт уточнює прогноз на наступних рейсах.
У нас уже розгорнута система планування — її доведеться міняти?
Ні, оптимізатор стає поряд із поточним контуром. Інтеграція з обліковою системою йде через обмін файлами або програмний інтерфейс, чинна логіка розподілу замовлень залишається робочою.
Перехід робимо за групами машин: якщо за часом або пробігом результат гірший, група повертається до попереднього режиму без зупинки доставки.
Диспетчер зможе правити маршрут вручну?
Так, і це частина системи, а не обхід її. Гнучкість правил задається пріоритетами: клієнтський інтервал, вага вантажу, заборона розворотів, обмеження водія.
Диспетчер бачить, чому маршрут склався саме так, і може зафіксувати ділянку — ручне підтвердження зберігається як правило й ураховується в наступних розрахунках.
Обговоримо задачу: що потрібно для першого етапу
Оцінка проєкту доставки починається не з доступу до вашої системи планування, а з вивантажень і опису обмежень. Нам достатньо зрозуміти, які дані вже є, як вони структуровані й де розрахунок маршрутів упреться в реальні правила складу, а не в математику. Чим точніші вхідні дані, тим менше припущень у плані першого етапу.
- Вивантаження історичних рейсів за кілька тижнів: точки, час прибуття й відбуття, фактичний пробіг, вага й обсяг замовлення.
- Склад парку: типи машин, місткість за вагою й обсягом, прив'язка до складів, змінність водіїв — від цього залежить, які маршрути взагалі допустимі.
- Вікна доставки за клієнтами й групами: жорсткі інтервали, м'які допуски, обідні паузи, заборона на нічне розвантаження.
- Обмеження за вантажем: несумісні категорії в одному кузові, температурні режими, вимоги до кріплення й порядку розвантаження.
- Правила пріоритету: хто отримує замовлення першим за нестачі машини, для кого зсув часу неприпустимий.
- Довідник адрес із координатами, зонами й обмеженнями на в'їзд для важкого транспорту.
- Норми часу на навантаження й розвантаження за типами точок — без них модель систематично занижує тривалість рейсу.
За цими даними ми збираємо розрахункову модель, звіряємо її з історичними рейсами й показуємо на конкретних днях, де саме втрачається кілометраж і час.
Далі повертаємося з планом першого етапу: що запускаємо на обмеженій ділянці, які показники фіксуємо до старту і як порівнюємо результат із поточним плануванням вручну. Опишіть задачу — повернемося з оцінкою та планом.
