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