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