Контроль складських залишків

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

Конкретний набір кроків налаштовується під процеси компанії — нижче типовий сценарій для виробництва та рітейлу.

Що робить автоматизація

1. Підтягує дані по залишках зі сховища даних або BI-шару із заданою періодичністю — від 15 хвилин до разу на добу залежно від критичності SKU.
2. Нормалізує SKU, склади та одиниці виміру — приводить дані до єдиної довідкової структури, щоб метрики були зіставні між майданчиками.
3. Розраховує прогноз споживання на горизонт планування по кожній позиції, враховуючи історичний попит, сезонність та відкриті замовлення в системі.
4. Порівнює поточний рівень залишків з мінімально допустимим (страховий запас) та з прогнозованою точкою вичерпання.
5. Визначає, які позиції потребують реакції: нижче критичного рівня зараз або вийдуть за нього в межах горизонту планування.
6. Надсилає структуровані алерти в Slack, Telegram або email із зазначенням SKU, складу, поточного залишку, прогнозу та відповідального.
7. Фіксує події у логу — для аудиту, розбору інцидентів та ретроспективного аналізу точності прогнозу.
8. Формує періодичний дайджест по залишках для керівника напряму — без необхідності вручну збирати звіт.

Чого автоматизація НЕ робить

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

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

Потік даних

1. Конектор до сховища даних: AI-агент звертається до вітрини залишків та історії продажів через SQL-підключення або BI API.
2. Шар нормалізації: зіставляє довідники SKU, складів та одиниць виміру. Якщо в компанії кілька облікових систем, цей шар приводить їх до єдиного вигляду.
3. Прогнозний модуль: по кожному SKU розраховує очікуване споживання на горизонт планування. Метод залежить від стабільності попиту — від ковзного середнього до ML-моделі з сезонними компонентами.
4. Правила контролю: на виході прогнозу застосовуються бізнес-правила — мінімальний страховий запас, час поповнення постачальника, пріоритет SKU.
5. Рушій сповіщень: сформовані алерти надсилаються в Slack або Telegram (канал комунікацій) з правилами маршрутизації — яка група SKU іде до якого відповідального.
6. Шар логування: кожна подія, кожен алерт, кожна зміна прогнозу записується в окреме сховище для розбору постфактум.

Як влаштована реалізація

1. Провести аудит джерел даних: де зберігаються залишки, де історія продажів, з якою затримкою оновлюються, яка якість довідників.
2. Зібрати бізнес-правила щодо страхового запасу та пріоритетів SKU — разом із закупівельником та операційним керівником.
3. Вибрати прогнозний метод за групами SKU: для стабільного попиту достатньо ковзного середнього, для сезонних позицій потрібна окрема модель.
4. Реалізувати конектор до сховища даних та шар нормалізації, перевірити відтворюваність розрахунків на історичних даних.
5. Налаштувати рушій сповіщень з тестовим каналом та валідувати формат алертів з кінцевими отримувачами — текст, частота, групування.
6. Провести паралельний тіньовий запуск протягом 2-4 тижнів: система формує алерти, але реакція залишається ручною — це дає матеріал для калібрування.
7. Перевести в бойовий режим, запровадити SLA на реакцію і почати збирати метрики точності прогнозу та пропущених дефіцитів.

Компоненти рішення

Custom-code підхід вибрано невипадково: типові low-code платформи погано справляються з нестандартною обліковою логікою — багаторівневими складами, внутрішніми переміщеннями, консигнацією. Для компаній з прямолінійною структурою можлива легша збірка; для виробництв і рітейлерів з кількома джерелами обліку custom-code окупається.

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

Дані та доступи

• Сховище даних або BI-шар з вітриною залишків по SKU і складах, що оновлюється не рідше одного разу на добу.
• Історія продажів або споживання мінімум за 6-12 місяців — без цього прогнозний модуль не зможе калібруватися.
• Єдиний довідник SKU або прописані правила маппінгу між обліковими системами, якщо їх декілька.
• Доступ лише для читання до джерел через SQL, BI API або вивантаження за розкладом.
• Канал сповіщень на боці комунікацій — готовий Slack або Telegram-воркспейс із правами бота.

Готовність команди

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

Строки впровадження

Для типового проєкту з одним сховищем даних і одним каналом сповіщень строк від старту до бойового запуску становить 6-10 тижнів. З них 1-2 тижні йдуть на аудит даних, 2-4 тижні — на реалізацію конектора, прогнозного модуля і правил, 2-4 тижні — на тіньовий запуск і калібрування. Компанії з кількома різнорідними обліковими системами або зі складною складською структурою виходять за ці строки — у таких випадках впровадження обговорюється окремо.