Чому AI-управління запасами сировини ламається на реальних даних
Рідкісні сплески попиту ламають модель першими. Навчена на усередненій історії, вона вважає такий пік шумом і згладжує його — закупівля потрапляє в план раніше, ніж алгоритм встигає перебудувати сезонність під конкретну номенклатуру.
Друга точка розриву — ручні правила точки замовлення. Поріг повторного замовлення, зашитий у SAP давно і без перегляду, не знає ні фактичного терміну поставки за кожним постачальником, ні розміру партії, ні кратності упаковки. Правило спрацьовує за календарем, а не за станом складу.
Третя причина — розрізнені дані про рух сировини й комплектуючих. Приймання живе в обліковій системі, брак і повернення — у журналі цеху, фактичні терміни поставки — у листуванні фахівців із постачання.
Поки події не зведені за партією, датою і складом, будь-яка модель бачить викривлену картину і вчиться на ній.
Ціна цих розривів вимірюється простоями. Дефіцит комплектуючих зупиняє лінію на дні, надлишки сировини на складі заморожують обігові кошти і йдуть у списання за терміном придатності.
Точність прогнозу попиту падає до «середнього по цеху», а зрив термінів поставки перестає бути винятком.
Далі розбираємо, як це закривається: які дані зводяться в єдиний контур руху сировини, як налаштовується точка замовлення за кожним постачальником і що перевіряється до запуску у виробництво.
Що змінюється після впровадження прогнозної системи
Перші два-три тижні система рахує прогноз за групами номенклатури і звіряє його з фактичною витратою, не торкаючись закупівель.
За ходовими позиціями зі сталим попитом точність прогнозу виходить на 85–90% на горизонті терміну поставки; розріджені й нові позиції ми відразу позначаємо як зону ручного контролю, щоб не віддавати їх алгоритму наосліп.
Далі закупівлі йдуть від прогнозу з урахуванням терміну поставки і кратності упаковки.
Страховий запас перестає бути фіксованим числом у картці позиції і рахується від розкиду попиту та надійності постачальника: за сталими групами він знімається приблизно на третину, за нестабільними залишається високим усвідомлено.
Частка термінових закупівель знижується раніше за інші показники. Поки заявка народжувалася від точки повторного замовлення, дефіцит виявлявся за фактом, і позицію везли аварійно.
З прогнозом нестача видна на термін поставки вперед, тому аварійний режим перестає бути регулярним сценарієм для ходових позицій.
Перепланування змінює масштаб часу. Раніше перезбирання плану закупівель у таблицях займало дні й робилося раз на один-два тижні, через що зрив поставки або сплеск попиту приїжджав у план із затримкою.
Перерахунок за всіма групами номенклатури триває хвилини: планувальник запускає його за подією і бачить, які позиції зсунулися, замість перебору всього списку.
До третього місяця змінюється оборотність запасів. Запас перестає бути рівномірно розмазаним по складу і концентрується там, де попит підтверджений даними, а не там, де історично звикли тримати.
Окремо зникає клас відмов, який раніше вважався нормою, — простій через відсутність ходової комплектуючої. Він залишається можливим лише як наслідок зовнішнього зриву, у постачальника або на логістиці, але перестає бути регулярним.
Який режим планування вибрати: порівняння підходів
Режим планування — не питання вподобань, а функція від передбачуваності попиту й обсягу накопиченої історії. Поки номенклатура вузька й споживання рівне, ручні min-max правила працюють без помилок і не потребують даних.
Щойно з'являється сезонність, промо або перебої в постачальника, ті самі правила починають або заморожувати обіговий капітал, або давати простій на лінії.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручні min-max правила | Однорідна номенклатура, рівне споживання, історії менше одного циклу сезонності | Не тримає сезонність і тренд, правиться вручну, реагує на дефіцит постфактум |
| Статистичний прогноз | Є історія за один-два цикли, виражений тренд, десятки-сотні позицій | Ламається на промо, зміні постачальника і нових позиціях без історії |
| Модель машинного навчання для прогнозу | Тисячі позицій, різнорідні чинники: терміни поставки, розмір партії, ціни на сировину | Потрібен контроль дрейфу і регулярне перенавчання, холодний старт за новими позиціями |
| Гібридний режим з експертною корекцією | Висока ціна помилки, у фахівців із постачання накопичений досвід за конкретними групами | Правки потрібно фіксувати, інакше зворотний зв'язок губиться і модель деградує |
Перехід робимо за групами номенклатури, а не відразу по всій системі: точка замовлення перераховується зі страхового запасу, терміну поставки і розкиду попиту, тому для частини позицій статистика залишається точнішою за модель.
Гібридний режим планування вмикаємо там, де прогноз помиляється дорого: модель дає базову величину, фахівець із постачання вносить корекцію, і обидві версії зберігаються — за розбіжностями видно, яких чинників у даних бракує.
Етапи впровадження: від аудиту даних до передачі системи
Порядок робіт фіксуємо до старту: для складу сировини і для комплектуючих він однаковий, змінюється лише склад джерел. Кожен етап закінчується артефактом, який можна перевірити, тому результат не залежить від того, хто веде проєкт.
- Аудит даних про запаси. Збираємо історію руху, залишків, закупівель і фактичних термінів поставки, звіряємо одиниці вимірювання й пакувальні кратності. На виході — перелік позицій, де даних достатньо для розрахунку, і окремо ті, де спочатку потрібно поправити облік.
- Схема розрахунку потреби та ознак. Узгоджуємо горизонт планування, цільовий рівень сервісу, правила страхового запасу й округлення до партії. У розрахунок вводимо сезонність, графік постачальників, тривалість виробництва та історію зривів.
- Налаштування і навчання на підготовлених даних. Визначаємо, як система реагує на різкі сплески попиту, і де планувальник може перевизначити рекомендацію вручну.
- Перевірка на історичних періодах. Прогонимо розрахунок за закритими інтервалами і порівнюємо з фактичними закупівлями: скільки виникало дефіциту, скільки осідало надлишком, як часто рішення системи розходилося з рішенням служби постачання.
- Пілот на вузькій групі номенклатури. Виводимо в роботу одну категорію, щоб оцінити поведінку системи на живому потоці й обмежити ризик для решти складу.
- Передача системи й навчання команди. Передаємо регламенти перерахунку, правила ручних правок, доступи й порядок супроводу — далі команда замовника веде розрахунок сама, а ми залишаємося на підтримці змін.
Комплект конфігурацій, регламентів і документації
Система прогнозування попиту й планування поставок живе не в презентації, а в наборі артефактів, якими закупівлі користуються щодня. Ми передаємо їх у ваш репозиторій і розбираємо разом зі фахівцями — після здачі не залишається рішень, які здатен підтримувати лише підрядник.
- Налаштування розрахунку: горизонти планування, цільовий рівень сервісу за групами номенклатури, сезонні профілі, правила згладжування викидів і обробки нульового попиту.
- Політика страхових запасів: формули й коефіцієнти за класами важливості та стабільності споживання, окремі умови для дефіцитних, довгоциклових та імпортних позицій.
- Регламент поповнення запасів: точки замовлення, кратність і розмір партії, мінімальний залишок, календар закупівельних циклів і порядок погодження позапланових заявок.
- Правила винятків: що робити при зриві поставки, стрибку попиту або виході постачальника, як оформлюється ручна правка прогнозу і хто її підтверджує.
- Панель моніторингу запасів: оборотність, частка дефіциту, точність прогнозу, завислі партії — з порогами, за яких спрацьовує оповіщення.
- Інструкції для закупівельника: покрокові сценарії роботи з рекомендаціями системи, розбір розбіжностей «прогноз проти досвіду» і порядок ескалації.
- Документація системи планування: схема потоків даних, обмін з обліковою системою, моделі даних, матриця ролей і доступів.
- Регламент супроводу: версіонування моделей, порядок перенавчання, контроль якості вхідних даних, журнал змін.
Кожен артефакт передаємо в робочій версії — з власником з боку замовника, точкою оновлення і критерієм, за яким видно, що налаштування застаріло.
Кейс: скоротили дефіцит і заморожені залишки
Виробничий майданчик: кілька тисяч позицій сировини й комплектуючих, терміни поставки від тижня до кварталу. Замовлення збиралося раз на тиждень в електронних таблицях, і до 40% рядків фахівці із постачання правили вручну за дзвінком із цеху.
Система не відрізняла сезонний сплеск від разового відхилення — дефіцит закривали терміновими закупівлями за верхньою межею прайсу.
Що змінили
Прогноз побудували за кожною позицією окремо: у розрахунку сезонність, термін поставки, кратність партії в постачальника і цільова частка покриття попиту.
Позиції рознесли за класами — за вартістю і передбачуваністю витрати, — і для кожного задали свій горизонт планування та рівень страхового запасу.
Фактичні витрати й надходження забирали з облікової системи 1С:ERP раз на добу, тому замовлення перераховувалося на свіжих даних, а не на даних місячної давності.
Метрики до і після
| Метрика | До | Після |
|---|---|---|
| Частка позицій у дефіциті | 9% номенклатури на тиждень | 2% |
| Заморожені залишки | базовий рівень | −37% |
| Термінові закупівлі | 27 на місяць | 6 |
| Ручні правки рядків замовлення | близько 40% | 8% |
Ручні правки не вимкнули, а перетворили на сигнал: кожна фіксується з причиною — зміна рецептури, брак партії в постачальника, позапланове замовлення — і потрапляє в наступний перерахунок.
Без цієї петлі модель втрачає контекст, який знає фахівець із постачання, і за місяць знову починає помилятися.
Як вбудувати AI-прогноз, якщо вже є свої правила закупівлі
Прогноз не замінює правила закупівлі, а вбудовується поверх них. Правила — мінімальний залишок, страховий запас, термін поставки, кратність упаковки — залишаються в обліковій системі як обмеження. Прогноз змінює лише рекомендовану кількість і момент замовлення.
На старті вивантажуємо з облікової системи рухи номенклатури, надходження, списання, резерви й скасування. Дані з 1С і суміжних систем зводимо в одну таблицю за кодом позиції та складом.
Розбіжності в довідниках — дублі, різні одиниці вимірювання, неактуальні категорії — вичищаємо до запуску, інакше прогноз вчиться на смітті.
Перші місяці прогноз іде паралельно з планом закупівельника і нічого не підміняє. Регулярно формуємо звіт розбіжностей: де прогноз і фахівець розходяться, наскільки і чому — акція, сезонність, зміна постачальника. Рішення ухвалює закупівельник, прогноз лише показує свою цифру.
Перехід поступовий, за товарними групами. Починаємо з позицій із довгою історією та сталим попитом; критичні й нові залишаємо на ручному управлінні.
Частку автоматичних рекомендацій збільшуємо в міру підтвердження точності на факті — за кожною групою окремо, з можливістю повернути ручний режим.
Зворотний зв'язок обов'язковий: відхиляючи рекомендацію, закупівельник зазначає причину, і вона йде в навчання. Так у модель потрапляє знання, якого немає в даних — домовленості з постачальником, зміна асортименту. Відкат — вимкнення рекомендацій для групи, правила закупівлі при цьому продовжують працювати.
Часті заперечення щодо точності та надійності моделі
Перед стартом майже завжди лунає один набір питань: чи вистачить історії для сировини, що буде при збої постачальника, хто відповідає за цифру в плані закупівель.
Що робити, якщо дані про рух сировини неповні?
Спочатку рахуємо частку пропусків і розбіжностей між складом та обліком. Якщо провали локальні, навчаємо модель на тижневих залишках — шум згладжується, прогноз залишається робочим.
Якщо історія коротша за цикл поставки, додаємо в розрахунок замовлення і підтверджені терміни від постачальників.
Як система реагує на разові сплески попиту?
Тримаємо окремий шар правил: різке зростання за однією позицією не переписує базовий прогноз по всій номенклатурі. Такий сплеск позначається як разовий, і після перевірки модель повертається до попередньої траєкторії. Стале зростання, навпаки, відразу змінює план закупівель.
Хто відповідає за прогноз, якщо постачальник зірвав термін?
Ми відповідаємо за якість прогнозу і його прозорість, а не за поведінку контрагента. У моделі є блок оцінки надійності постачальника за історією відвантажень, тому ризик зриву видно заздалегідь.
При зміні терміну перерахунок плану йде автоматично, а рішення про заміну постачальника залишається за вами.
Як контролюється дрейф моделі після запуску?
Показник помилки рахуємо щодня на фактичних витратах і порівнюємо з порогом, узгодженим на старті. При виході за поріг модель перенавчається, і ви отримуєте звіт: змінилося споживання чи якість даних про рух сировини.
Обговоримо задачу і повернемося з планом впровадження
Щоб розмова була предметною, а не «про AI взагалі», нам потрібні ввідні дані по вашому контуру запасів: номенклатура, історія руху й правила, за якими сьогодні ухвалюються рішення про закупівлю.
Із цього починається обговорення задачі управління запасами — яким позиціям прогноз справді потрібен, де зараз надлишок запасів, а де регулярний дефіцит.
Зазвичай просимо підготувати таке:
- Номенклатура та її структура — групи сировини й комплектуючих, аналоги та взаємозамінність, одиниці вимірювання, прив'язка до постачальників і складів.
- Вихідні дані для розрахунку — вивантаження надходжень, витрат, списань і повернень за достатній горизонт, з позначкою ділянок, де були ручні коригування або пропуски.
- Обмеження постачальників — мінімальна партія, кратність упаковки, термін поставки, періодичність рейсів, умови відстрочки й надійність відвантажень.
- Сезонність і зовнішні чинники — промо, планові зупинки, ремонти, великі разові замовлення, які не можна вважати трендом.
- Критичність позицій — що зупиняє виробництво, а що допускає очікування; припустимий рівень дефіциту за кожною групою.
- Склад робочої групи — хто володіє даними, хто підтверджує правила перерахунку, хто ухвалює результат і буде ним користуватися щодня.
- Цільові орієнтири — горизонт і крок планування, бажана оборотність, точки, де рішення має залишатися за людиною.
Після розбору цих ввідних повертаємося з оцінкою обсягу робіт і планом впровадження прогнозу: на яких даних навчаємо модель, як перевіряємо її на історичних періодах, як результат потрапляє в поточний процес закупівлі і як рахується ефект.
