AI у логістиці: де ламається прогноз і зростають витрати
Прогноз попиту рідко розходиться з фактом через слабку модель. Частіше він ламається на стику даних: склад рахує залишки за своїми документами, транспорт — за своїми, а план збирають у зведеній таблиці, куди частину цифр вносять вручну.
На момент, коли розходження стає помітним, партія вже відвантажена не туди, де виник дефіцит. Точність планування при цьому падає не на відсотки, а в рази — за окремими групами позицій розходження плану й факту сягає третини.
Друге джерело помилки — припущення, які ніхто не перевіряє. Сезонність беруть за попереднім періодом, термін постачання — за договірним, а не за фактичним часом у дорозі, сплески від промо закладають «на око».
Кожне таке припущення зсуває план, і дефіцит на складі виникає рівно там, де прогноз обіцяв надлишок. Розбирати це постфактум безглуздо: причина губиться між версіями файлу.
Третій — швидкість реакції. Сплеск попиту видно в даних фактичних відвантажень майже одразу, але рішення про дозамовлення ухвалюють на тижневій нараді.
Поки узгоджують обсяги, зриви постачань стають фактом, а ручне планування перетворюється на безперервну боротьбу з наслідками замість роботи з причиною.
Нижче розбираємо, як це закривається: де ставити контроль розходжень між складами й транспортом, які сигнали брати з фактичних відвантажень замість припущень і як перевести план із ручного режиму в режим, що перераховується — із зрозумілим часом реакції на відхилення.
Що дає прогнозна модель: вимірюваний ефект на потоці
Ефект починається з точності прогнозу, а не зі звітності. Перший замір — помилка прогнозу за позицією на день на тому горизонті, який потрібен плануванню: від доби для поповнення складу до кварталу для закупівлі.
Рахуємо її на історичних даних із тією ж сезонністю й промо-календарем, що й поточна базова лінія, — інакше покращення залишиться у звіті й не дійде до запасу.
Далі помилка перетворюється на запас. Страховий запас перераховується від фактичної помилки й часу поповнення, а не «на око», тому оборотність запасів зростає за того самого рівня сервісу.
Ефект тут не в урізанні складу, а в перерозподілі: неліквід іде, критичні позиції перестають провалюватися в дефіцит.
На транспорті зв’язка інша.
Горизонт прогнозу за відвантаженнями дозволяє консолідувати замовлення в рейс і заздалегідь планувати вікна, тому зростає завантаження транспорту й скорочуються порожні пробіги: машина не повертається порожньою, коли наступне замовлення відоме до виходу з точки.
Показники рівня сервісу й оборотності рахуємо за SCOR — так цифри зіставні з галузевими й не залежать від того, хто і як їх рахував.
Автоматизація планування вимірюється часткою ручних правок плану: скільки рядків планувальник переписує після того, як модель видала свій варіант. Падіння цієї частки — найчесніша ознака, що прогноз вбудувався в процес, а не йде окремим файлом. Людині залишаються винятки: великі клієнти, промо, нові позиції без історії.
Порівнюємо до й після на одному періоді та одній номенклатурі — тоді видно, яка частина ефекту прийшла від моделі, а яка від сезонності. Модель дає корисний результат, коли її метрики прив’язані до цих показників потоку, а не живуть окремо від плану.
Варіанти побудови: готова модель, доопрацювання, власна система
Вибір режиму визначається не бажанням «зробити по-своєму», а зрілістю даних і унікальністю процесу. Якщо історія подій зібрана за кілька сезонів, атрибути замовлень заповнені, а оновлення надходять регулярно, можна рухатися до донавчання або власної моделі.
Якщо журнал фрагментарний, а рішення ухвалюються за кількома типовими маршрутами, готова модель дасть результат швидше й без ризику.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готова модель | Типові задачі: прогноз попиту, часу прибуття, маршрутизація за стандартними правилами. Власної історії поки мало для навчання. | Слабке налаштування під нестандартні тарифи, пріоритети клієнтів і внутрішні регламенти. |
| Доопрацювання під процес | Є особливості: власні правила пріоритетів, кілька складів, змішаний парк. Накопичені розмічені дані за минулі періоди. | Потрібні регулярне перенавчання, контроль дрейфу й власник моделі на боці замовника. |
| Власна розробка | Логіка унікальна й є конкурентною перевагою; обсяги й вимоги до швидкості відповіді не покриваються готовими сервісами. | Тривалий цикл, власна інфраструктура, моніторинг якості й команда супроводу. |
Впровадження прогнозування рідко починається з власної моделі — зазвичай це поступовий перехід: старт на готовому рішенні, накопичення розмічених даних за фактом виконання, потім доопрацювання під процес.
Перед вибором ми оцінюємо зрілість даних: глибину історії, повноту полів, частоту оновлень і наявність зворотного зв’язку за фактичними результатами.
Впровадження AI у логістиці: етапи інженерної роботи
Логістика — процес, де помилка прогнозу коштує дорожче, ніж сама модель. Тому впровадження ми будуємо як послідовність інженерних кроків, кожен з яких можна зупинити й оцінити результат до переходу до наступного.
- Аудит даних. Розбираємо, що є насправді: історія відвантажень, залишки, терміни постачання, скасування, ручні правки диспетчерів. Перевіряємо повноту за періодами й частоту оновлення — слабкі місця тут визначають стелю точності.
- Схема рішення. Визначаємо, куди модель вбудовується в процес: прогноз попиту за складами, пріоритизація рейсів, оцінка ризику прострочення. Фіксуємо входи, виходи й те, хто ухвалює фінальне рішення.
- Підготовка й налаштування. Приводимо довідники номенклатури й адрес до єдиного вигляду, прибираємо дублі й розриви в історії — інакше модель вчиться на шумі, а не на закономірностях.
- Пілотний запуск. Один напрямок або група складів, обмежений горизонт планування: ефект видно на живому процесі, а зона впливу помилки залишається вузькою.
- Перевірка точності. Порівнюємо прогноз із фактичними відвантаженнями й із попереднім плануванням: частка влучень, середня помилка, кількість помилок у критичний бік.
- Передача моделі й навчання команди. Віддаємо схему рішення, регламент перенавчання, контури контролю якості прогнозу й розбираємо з вашими фахівцями, як читати метрики.
Далі нові напрямки підключаються за вже відпрацьованим контуром — без повторного аудиту з нуля.
Що замовник отримує на руки: моделі, схеми, регламенти
Передача рішення — це не архів із кодом, а комплект документів, за яким ваша команда веде систему сама: перенавчає моделі, розбирає інциденти й пояснює рішення бізнесу. Нижче — обов’язковий мінімум, який передається на руки разом із робочим контуром.
- Опис моделей і правил — цільова метрика, горизонт прогнозу, значущі ознаки й межі застосовності: де модель деградує (нетипові маршрути, нові типи вантажу, збої в джерелі телеметрії).
- Схема потоків даних — від облікової системи й телеметрії через шар збагачення до сховища історії, з позначками, де дані губляться й як це відстежується.
- Регламент перенавчання — тригери (дрейф вхідних розподілів, зміна сезонності, накопичена помилка), порядок запуску, перевірка на відкладеному періоді й відкат на попередню версію моделі.
- Інструкції для диспетчерів і планувальників — як читати прогноз з інтервалом, у яких випадках рішення перевизначається вручну й як фіксується причина відхилення.
- Матриця ролей — власник моделі, власник даних, відповідальний за інциденти й точка ескалації: без неї через пару місяців незрозуміло, хто лагодить збій.
- Регламенти супроводу — що моніториться, за яких відхилень спрацьовує оповіщення, як ведеться журнал рішень.
- Документація рішення — карта сервісів, точки інтеграції з обліковими системами, формати обміну, порядок розгортання в чистому середовищі.
Розробляємо так, щоб цей комплект був повним із першого дня, а не збирався заднім числом під час передачі.
Розбір проєкту: прогноз проти порожніх пробігів і дефіциту
Планування трималося на середніх значеннях за минулі періоди й ручному зведенні: менеджер зіставляв заявки, залишки на складах і доступний парк.
Збій постачання або сплеск попиту ламав план за добу — частина напрямків ішла порожняком, а за критичними позиціями вмикалися авральні дозакупівлі.
Що було і що зробили
Зібрали єдиний шар даних: історія відвантажень, сезонність, терміни постачальників, обмеження за складами й маршрутами. Поверх — прогноз попиту за кожною парою «склад — товар» і оптимізатор рейсів, який зводить напрямки з урахуванням зворотного завантаження.
Планувальник залишився в контурі: система пропонує план, він підтверджує або править, і кожна правка повертається в модель як сигнал. Проєкт для «ТрансЛайн» йшов ітераціями: спочатку прогноз на вузькій групі позицій, потім оптимізація рейсів, далі розширення на весь парк.
Що зрушилося
Точність прогнозу за ключовими групами зросла з 68% до 89% на двотижневому горизонті. Порожній пробіг скоротився на третину, дефіцит критичних позицій — майже вдвічі.
Частка ручних правок у плані впала з більшості рядків до однієї шостої: час планувальника йде на нестандартні ситуації, а не на перерахунок базового плану.
Модель перенавчаємо за розкладом, і якщо якість прогнозу на перевірочному періоді просідає, схема автоматично повертається до консервативного плану — дефіцит не виникає через те, що модель «поїхала».
Чим прогнозування попиту відрізняється від оптимізації маршрутів?
Прогнозування попиту відповідає на питання «скільки», оптимізація маршрутів — на питання «як везти».
Горизонти в них різні: прогноз живе тижнями й місяцями та агрегується за товарними позиціями, точками й каналами, а маршрут перезбирається раз на добу під конкретні замовлення, вікна доставки й завантаження транспорту.
Дані теж різні. Прогнозу потрібна історія відвантажень, календар акцій, сезонність і зовнішні фактори; маршрутизації — граф доріг, обмеження за часом роботи водія, місткість машин і режим роботи точок. Перетинаються обидва контури в плануванні запасів.
| Задача | Які дані потрібні | Що вирішує | Де перетинається |
|---|---|---|---|
| Прогнозування попиту | Історія продажів, акції, сезонність | Обсяг попиту на горизонті тижнів | Задає обмеження за запасом |
| Планування запасів | Прогноз, терміни постачання, страховий запас | Скільки й коли дозамовляти | Пов’язує попит із завантаженням транспорту |
| Оптимізація маршрутів | Замовлення, вікна, місткість, граф доріг | Порядок об’їзду, розподіл за машинами | Отримує обсяги з плану поповнення |
Помилка прогнозу не залишається у звіті — вона перетворюється на порожні рейси або термінові довивезення, які ламають уже зібраний маршрут. Задачу маршрутизації вирішуємо розв’язувачем класу OR-Tools: він тримає обмеження за вікнами й місткістю одночасно.
Єдиний контур планування — це послідовність: прогноз попиту → план поповнення → розподіл за складами → маршрут → фактичні відвантаження, що повертаються в модель. Корекція прогнозу тоді автоматично перераховує і запас, і рейси, а не живе окремою таблицею.
Технічні сумніви: дані, точність, інтеграції
Прогноз ламається не на навчанні, а на стику з реальністю: зміни в обліковій системі закривають за фактом, аномальні сплески йдуть в історію як норма, а після зміни номенклатури ознаки починають значити не те, що раніше. Нижче — короткі відповіді на питання, які найчастіше піднімають на технічному розборі.
Що робити, якщо історія замовлень «брудна»?
Починаємо з профілювання: частка пропусків, дублі, від’ємні залишки, розриви рядів, зміщені часові пояси. Правила очищення узгоджуємо з вашою командою й фіксуємо письмово, а не правимо на око: спірні записи не видаляємо, а позначаємо. Модель вчиться на агрегатах, а джерела з низькою довірою йдуть окремими ознаками з вагою.
Як модель поводиться за аномалій — різкого сплеску або провалу попиту?
Аномалія — це сигнал, а не сміття: промо, скасування рейсу, збій постачальника враховуються окремою подією, інакше модель запам’ятає викид як норму.
Поверх ставимо запобіжники — пороги за залишками, ліміти зростання замовлення, ручне підтвердження великих відхилень, — тому одиничний викид не перетворюється на закупівлю «в нікуди».
Як розумієте, що модель не перенавчена?
Перевіряємо за часом: навчання на старому періоді, перевірка на майбутньому, без випадкового перемішування рядків. Якість порівнюємо з простим орієнтиром і з поточним плануванням, а метрику дивимося окремо за горизонтами — день, тиждень, місяць.
Якщо результат тримається і на відкладеному періоді, і на нових точках, це робоча модель, а не підгонка.
Як стикуєтеся з обліковими системами і що із супроводом?
Обмін іде за узгодженим контуром: вивантаження за розкладом і подієві оновлення, повторне завантаження не дублює дані, кожне повідомлення логується й відкочується. На старті працюємо тільки на читання.
Далі — супровід: стежимо за якістю прогнозу й дрейфом даних, перенавчаємо за відхиленням метрик, а не за календарем, зберігаємо версії моделей і можемо повернути попередню.
Обговоримо вашу задачу й повернемося з планом робіт
Перша розмова — це збір вхідних, а не презентація. Щоб повернутися з планом етапів і оцінкою рішення, а не із загальними словами, потрібен мінімум за даними, обмеженнями й поточним процесом. Нижче — що уточнюємо й які матеріали просимо показати.
- Задача й метрика успіху: частка прогнозів у межах допуску, час реакції на відхилення, частка рішень, які система пропонує без ручного втручання.
- Вихідні дані: вивантаження із систем управління транспортом і складом, історія замовлень, телеметрія, довідники маршрутів і тарифів — за який період зберігаються й у якому вигляді лежать зараз.
- Якість даних: пропуски, дублі, розходження між довідниками, різні одиниці вимірювання й часові пояси — від цього залежить обсяг підготовчого етапу.
- Замкнутий контур: де дозволено обробляти дані, які зовнішні сервіси недоступні, хто видає доступи й у які терміни.
- Точки стикування: з якою системою рішення обмінюється даними, у якому форматі й з якою періодичністю, хто приймає дані на вашому боці.
- Вбудовування в процес: хто й на якому кроці дивиться прогноз, що робить за відхилення, чи потрібен режим підтвердження людиною.
Повертаємося документом: склад етапів, що робимо на кожному, які вихідні дані потрібні від вас на вході й який результат показуємо на виході. Поруч — оцінка рішення: трудовитрати, терміни, ключові ризики й умови, за яких оцінка переглядається. Опишіть задачу — повернемося з цією картиною й планом робіт.
