Розробка AI-системи прогнозування збоїв у ланцюгу поставок

AI-прогнозування збоїв: де розривається ланцюг поставок

Планування запасів досі тримається на середніх: страховий залишок рахують за минулими періодами, очікувані витрати — за ковзним середнім, а відхилення за конкретним постачальником і артикулом списують на шум. Поки поставки йдуть рівно, схема витримує.

Розрив ланцюга поставок проявляється інакше — партія не прийшла, лінія працює на останньому залишку, і рішення ухвалюється в режимі «що встигнемо привезти».

Ручне планування запасів додає затримку в один-два тижні: фахівець із постачання дізнається про зрив відвантаження з листа чи дзвінка, далі листування, погодження заміни, іноді термінова доставка.

Простій виробництва через поставки рідко спричинений однією великою аварією — частіше це накопичення дрібних відхилень за десятками позицій, які окремо ризиком не вважаються, а разом з’їдають буфер.

Дефіцит комплектувальних теж неоднорідний: критична позиція з довгим строком виготовлення зупиняє ділянку, а заміна витратного матеріалу коштує лише зсуву партії.

Модель, яка не розрізняє ці випадки, піднімає однаковий рівень тривоги на весь перелік і швидко знецінює сигнал — планувальник повертається до ручної перевірки.

AI-прогнозування збоїв закриває це з іншого боку: модель навчається на історії затримок, фактичних строках доставки, сезонному завантаженні маршрутів і поведінці постачальника, і видає ймовірність зриву за кожною позицією за два-три тижні до факту.

Цього достатньо, щоб перевести замовлення на альтернативного постачальника, перерозподілити запас між складами або зсунути план виробництва без зупинки. Розбираємо, як це вбудовується в контур планування.

Що змінюється, коли збій видно до настання

Раннє попередження будується на потоці операційних даних: статуси замовлень і відвантажень, фактичні транзитні строки за маршрутами, залишки та швидкість витрат на складах, історія зривів за кожним постачальником.

Модель перераховує ймовірність затримки за кожною позицією та маршрутом на горизонті кількох тижнів, спираючись на дані з облікових систем класу SAP і складських контурів, а не на ручні звіти.

Різниця проявляється у швидкості реакції на відхилення. Без прогнозу зрив виявляється в день поставки — лінія вже стоїть, залишається аварійна закупівля та переплата за терміновість.

Із попередженням сигнал надходить за 5-14 днів: інженер бачить не факт, а ймовірність і причину — зсув транзиту, падіння темпу відвантажень у постачальника, сплеск попиту.

Цього достатньо, щоб перевести замовлення на альтернативного постачальника, перерозподілити партію між складами або підняти пріоритет відвантаження.

Другий ефект — страховий запас складу перестає бути єдиним нормативом на всі позиції. Він рахується від прогнозної невизначеності: за стабільними групами запас знижується, за ризикованими залишається або зростає точково.

Обсяг заморожених запасів скорочується на 20-30% за того самого рівня сервісу, а частка відвернених зупинок лінії зростає — частина збоїв гаситься до того, як він доходить до виробництва.

Точність прогнозу поставок вимірюємо не однією загальною цифрою, а за горизонтами: частка здійснених попереджень, пропущені зриви, хибні тривоги. Поріг спрацювання налаштовується під ціну помилки конкретної ділянки — де простій дорожчий, модель реагує раніше і з більшим запасом.

Підходи до побудови: правила, статистика, моделі

Вибір підходу до прогнозування визначається не складністю методу, а обсягом накопиченої історії за поставками, транзитами та затримками. Порогові правила оповіщення працюють там, де збій видно безпосередньо: прострочений строк, переповнений склад, непідтверджене відвантаження.

Схема зрозуміла й передбачувана, але реагує на вже те, що сталося, і дає хибні спрацювання на сезонних піках.

Статистична модель прогнозу описує норму — сезонність, розкид строків за напрямком, поведінку запасу — і ловить відхилення до того, як воно стало аварією. Самонавчальна модель пов’язує десятки слабких сигналів між собою і знаходить ризики, які правилами не описати.

Робочий варіант — гібридна схема прогнозу: правила дають миттєву реакцію, статистика — горизонт у кілька тижнів, модель — складні поєднання факторів.

Шари ми нарощуємо за підтвердженим ефектом: спочатку правила, потім статистика, потім модель. Поріг спрацювання та горизонт налаштовуємо за фактичною точністю — прогноз залишається керованим і зрозумілим для служби логістики.

Етапи впровадження: від аудиту даних до передачі

Збій у ланцюзі поставок майже завжди залишає слід у даних задовго до факту — питання в тому, чи зведені ці дані в один контур.

Закупівлі, склад, логістика й виробництво живуть у різних системах зі своїми довідниками та різною частотою оновлення, тому робота йде не від алгоритму до даних, а навпаки: спочатку аудит і метрика, потім збірка та перевірка.

1. Аудит даних за поставками. Інвентаризуємо джерела: замовлення, відвантаження, фактичні строки в дорозі, залишки, події за постачальниками. На виході — карта джерел із частотою оновлення, зонами відповідальності та переліком прогалин, які закриваються до початку збірки.
2. Цільова метрика прогнозу. Домовляємося, що вважаємо збоєм і на якому горизонті: затримка партії, недопоставка, зрив вікна відвантаження. Метрика фіксується числом і правилом розмітки — щоб результат можна було перевірити, а не обговорювати.
3. Збірка схеми прогнозування. З’єднуємо історію замовлень з ознаками постачальника, маршруту, сезонності та завантаження складу; обробляємо пропуски, сплески та зміну довідників; налаштовуємо регулярне перенавчання.
4. Перевірка моделі на історії. Проганяємо закриті періоди з емуляцією реального часу: навчання лише на даних, доступних на той момент. Окремо дивимося частку впійманих збоїв і частку хибних спрацювань за категоріями поставок.
5. Приймання системи прогнозування. Навантажувальні прогони, поведінка за неповних даних і затримки джерела, регламент ручного підтвердження сигналу. Фіксуємо пороги, нижче яких система чесно утримується від прогнозу.
6. Передача системи замовнику. Доступи, конфігурація, документація щодо перенавчання, навчання команди та передача чергування. Далі — супровід за узгодженим циклом контролю якості прогнозу.

Кожен етап закривається артефактом, який можна подивитися й оспорити, — без цього наступний не починається. Опишіть задачу: повернемося з оцінкою та планом за вашими джерелами даних.

Комплект постачання: моделі, регламенти, моніторинг

Комплект постачання — це не лише робоча модель, а й усе, що дає службі постачання змогу користуватися нею без нас. Вихідні коди, конфігурації, доступи та документацію передаємо у ваш контур, без закритих частин. Нижче — що саме залишається в замовника після запуску системи прогнозування збоїв.

• Налаштовані моделі за кожною товарною групою — навчені на вашій історії поставок, із зафіксованими метриками якості та робочим порогом спрацювання.
• Опис ознак моделі — який показник на що впливає, звідки береться, як часто оновлюється і що робити за пропуску даних у джерелі.
• Документація щодо моделі прогнозу — схема навчання, порядок перенавчання на нових даних, критерії деградації та правила виведення нової версії в роботу.
• Оповіщення про відхилення — умови спрацювання, канали доставки відповідальним, пріоритети та захист від хибних сигналів.
• Регламент реакції на сигнал — хто отримує оповіщення, за який час підтверджує, які дії вживає і як фіксує результат.
• Інструкція для служби постачання — сценарії на типові ситуації: зрив поставки, затримка на маршруті, стрибок попиту, вихід постачальника.
• Панель моніторингу — якість прогнозу за тижнями, частка сигналів, що спрацювали, і список поточних ризиків за ланцюжком.
• Журнал зворотного зв’язку — позначки про підтверджені та хибні сигнали, на яких модель доучується.

Кейс: як скоротили простої на складі готової продукції

У виробника пакувальної продукції простої на складі готової продукції вважалися нормою: закупівлі планувалися за середніми продажами за минулі періоди, а сплески попиту та затримки постачальників у цю картину не потрапляли.

Підсумок — 30-35 годин простою лінії на місяць, позапланові закупівлі за завищеною ціною та зриви відвантажень у пікові тижні.

Розбір даних за кілька років показав, що понад половина збоїв були передбачуваними. Значущими виявилися затримки за конкретними постачальниками та партіями, транзитний час, сезонність за групами товарів і завантаження лінії.

Із кількох десятків сигналів у модель прогнозування увійшли дванадцять — решта давали шум і хибні спрацювання.

Що змінилося після запуску

Система прогнозування дефіциту сировини, яку на стороні замовника назвали Прогноз-склад, перераховує ймовірність дефіциту за кожною позицією на горизонті двох-чотирьох тижнів і віддає відділу закупівель список із пріоритетом. Страховий запас підняли лише за позиціями з високою ймовірністю, а не за всім складом.

Простої скоротилися з 30-35 до 6-8 годин на місяць, частка позапланових закупівель — з 28% до 6%. Точність прогнозу на двотижневому горизонті тримається близько 0,8, хибних тривог — одиниці на сотню перевірок, тому диспетчери не перестали довіряти оповіщенням.

В експлуатації модель доучується на нових поставках, а при падінні якості автоматично повертається попереднє правило закупівлі. Пороги, версії прогнозу та журнал спрацювань лежать поруч із документацією — команда замовника сама змінює чутливість, не чекаючи на нас.

Чим відрізняється раннє попередження від прогнозу попиту?

Це дві різні задачі з різними цільовими змінними. Прогноз попиту відповідає на питання «скільки одиниць потрібно», раннє попередження — «чим і коли ми ризикуємо».

Їх змішування в одному контурі — часта причина, чому система прогнозування збоїв виглядає точною у звітах, але не змінює жодного рішення в закупівлі.

Різниця задач прогнозування проявляється в горизонті та в моменті, коли результат ще можна використати. Прогноз обсягу закупівлі будується за тижні до закупівельної сесії: він визначає розмір замовлення, розподіл між постачальниками та завантаження складу.

Сигнал про ризик поставки виникає в іншому вікні — за лічені дні до очікуваного відвантаження, і працює лише за умови, що реакція на нього вже передбачена регламентом.

Сигнал про ризик поставки — це подія, а не число. Модель оцінює ймовірність зриву за конкретною партією: прострочення підтвердження замовлення, зростання часу обробки на перевантажувальному вузлі, розбіжність заявленого та фактичного строку. На виході — не «скільки закуповувати», а «яку партію і чим підстрахувати».

Дані на вході теж різні. Для планування обсягів закупівлі потрібні історія продажів, сезонність, акції та ціни; для раннього попередження — статуси замовлень, строки в дорозі, поведінка постачальника в минулих зривах.

І якість вимірюється по-різному: у першому випадку відхиленням від факту, у другому — часткою пропущених зривів за прийнятного рівня хибних тривог.

Практична зв’язка в тому, що попередження коригує прогноз. Якщо за групою зростає попит, а за ключовим постачальником висить ризик, план закупівлі перераховується: частина обсягу йде на альтернативне джерело, частина — у страховий запас.

Стійкість ланцюга поставок тримається не одним точним числом, а двома контурами на різних горизонтах — один планує, другий захищає план.

Сумніви щодо даних, строків і якості прогнозу

Навіть пристойна на вигляд історія поставок майже завжди містить перекоси: сплески закупівель під акції, дубльовані позиції номенклатури, розриви в прийманні та зміну правил обліку.

Починаємо з аудиту — скільки періодів реально покрито даними, де пропуски і як вони розподілені за сезоном.

Якщо глибина історії менша за два річні цикли, модель навчаємо на короткому вікні й заздалегідь фіксуємо, на яких групах товарів прогноз буде слабшим — краще знати це до запуску.

Строки зазвичай визначає не навчання, а підготовка даних і погодження інтеграції з обліковою системою. Вивантаження йде за розкладом, а не разово: модель, навчена на знімку місячної давнини, розвалюється на першій же зміні довідників.

Тому перенавчання закладаємо в регламент — за накопиченням нових підтверджених випадків і за появою розбіжностей між прогнозом і фактом.

Рідкісні збої майже не трапляються в історії — модель їх узагалі побачить?

Побачить як рідкісний клас, але не за рахунок самих фактів збою, а за рахунок провісників: зростання строків підтвердження замовлення, відхилення фактичного часу в дорозі від планового, зміна маршруту, сплеск часткових відвантажень. Поріг спрацювання підбираємо так, щоб не потонути в хибних тривогах на спокійних періодах.

Хто відповідає за дані і як влаштована інтеграція?

Межу фіксуємо письмово: наша сторона — схема обміну, вивантаження, контроль якості та логіка перенавчання; ваша — доступність облікової системи та коректність довідників.

Обмін налаштовуємо через штатні вивантаження та програмні інтерфейси, без ручних файлів — інакше перший же збій у ручній операції тихо зупинить прогноз.

Обговоримо ваш ланцюг поставок і повернемося з планом

Точна оцінка проєкту прогнозування тримається не на описі задачі словами, а на даних. Обговорити задачу прогнозування можна й без вивантажень, але тоді ми повернемося з широкою вилкою за строками замість плану впровадження системи. Нижче — що надіслати, щоб перша розмова з інженерами була предметною.

• вивантаження замовлень, поставок і відвантажень за кілька повних циклів — за нею видно сезонність і повторювані збої;
• довідники номенклатури, постачальників, маршрутів і складів у тому вигляді, у якому вони живуть зараз;
• журнал збоїв і відхилень: що саме ламалося, коли і чим це закінчувалося;
• поточні правила реагування — хто і на якому сигналі починає діяти;
• перелік систем обліку, де лежать ці дані, і спосіб отримати регулярні зрізи;
• приклади рішень, які вже ухвалювалися вручну і виявилися вдалими.

Розмова з інженерами — не презентація: ми дивимося дані, уточнюємо горизонт прогнозу, набір передбачуваних подій і допустиму частку хибних спрацювань.

Далі збираємо план впровадження за етапами, де якість перевіряється на вашій історії до того, як система почне впливати на рішення.

Опишіть задачу й надішліть те, що є, — повернемося з оцінкою та планом.