Stockout prediction з відновленням lost sales

Grow2.ai розгортає stockout-prediction pipeline, який читає дані з data warehouse і передбачає, коли кожен SKU вийде в дефіцит. Модель враховує історію продажів, сезонність і поточні залишки, а коли ймовірність stockout перевищує поріг — надсилає алерт у робочі канали команди закупівель.

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

1. Збирає дані з data warehouse: історію замовлень, поточні залишки за SKU, параметри постачань (lead time, MOQ).
2. Розраховує прогноз споживання для кожного SKU на горизонт до дати наступного постачання.
3. Порівнює прогнозований розхід із залишком і обчислює ймовірність stockout до приходу поповнення.
4. Надсилає структурований алерт у communications-канал: категорія, SKU, залишок, дата прогнозного out-of-stock, рекомендований обсяг замовлення.
5. Логує факт алерту і рішення команди, щоб з часом підлаштовувати пороги та вдосконалювати модель.
6. Паралельно виявляє SKU з надлишковим запасом, де закупівлю варто скоротити.

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

• Не розміщує замовлення у постачальників автоматично — фінальне рішення про закупівлю залишається за байером.
• Не замінює ERP або WMS як джерело істини щодо залишків; pipeline читає дані, але не пише у складські системи.
• Не гарантує 100% точність: рідкісні події (вірусні продажі, збої у постачальника, різка зміна попиту) потребують ручного коригування.

Основна мета — зсунути момент рішення про закупівлю з «товар закінчився» на «товар закінчиться через N днів». У цитованому e-commerce кейсі це знизило кількість stockouts з 47 до 8 за квартал (-83%), допомогло повернути £18,000 упущених продажів і скоротити надлишкові запаси на £43,000.

Рішення підходить для e-commerce і retail з каталогом від сотень активних SKU та історією продажів від 6 місяців. Чим чистіші дані в data warehouse, тим точніший прогноз; базовий сетап із денною гранулярністю дає помітний ефект вже через 2-3 цикли замовлення.

Технічне рішення — це pipeline на custom-code (найчастіше Python), який підключається до data warehouse, рахує прогноз по кожному SKU та розсилає алерти в communications-канал. Розгортання займає кілька тижнів при готових даних.

Основний потік

1. Щоденний extract.Scheduler (cron, Airflow або workflow-рушій) запускає pipeline вранці до початку зміни команди закупівель. Скрипт робить запити до data warehouse та вивантажує продажі за релевантний період, поточні залишки й довідник SKU.
2. Feature engineering. Розраховуються ковзні середні продажів по SKU, тижнева та річна сезонність, тренд, швидкість оборотності. Враховується lead time постачальника — від моменту замовлення до приходу товару на склад.
3. Модель прогнозу. Для кожного SKU розраховується очікуване споживання на горизонт до наступної можливої поставки. У базовій версії використовуються статистичні методи (exponential smoothing, Prophet); у просунутій — gradient boosting з урахуванням зовнішніх факторів (акції, свята).
4. Stockout score. На основі прогнозу та поточного залишку розраховується вірогідність out-of-stock до приходу наступної поставки та рекомендований обсяг замовлення.
5. Фільтр і пріоритизація. SKU з високою вірогідністю stockout і значною маржею або оборотом відбираються в алерт. Решта логуються без сповіщень, щоб не створювати шум.
6. Notification. Алерт надсилається в communications-канал із переліком SKU, причинами, рекомендацією та дедлайном для рішення.
7. Feedback loop. Рішення байера (замовив / відклав / проігнорував) логуються та використовуються для калібрування порогів і recalibration моделі.

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

Порядок впровадження

1. Аудит даних у data warehouse: повнота історії продажів, синхронізація залишків, довідник SKU.
2. Розробка baseline-моделі на вибірці SKU (A-категорія за оборотом) із ретро-валідацією на історичних даних.
3. Налаштування pipeline та scheduler, винесення параметрів (пороги, горизонт, lead time) у конфіг.
4. Інтеграція з communications-каналом та узгодження формату алерту з командою закупівель.
5. Пілот 2-3 тижні: порівняння прогнозів із реальністю, калібрування порогів, зворотний зв'язок від байерів.
6. Масштабування на весь каталог та закріплення feedback loop для безперервного покращення.

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

Для запуску stockout prediction Grow2.ai потребує підготовлених даних і готовності команди працювати з прогнозом, а не з post-factum звітами.

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

• Data warehouse або BI-шар з історією продажів мінімум 6 місяців (бажано 12+ для річної сезонності).
• Поточні залишки по SKU, синхронізовані з warehouse або ERP не рідше разу на добу.
• Довідник SKU з категоріями, постачальниками та lead time.
• Параметри закупівель: мінімальні обсяги замовлення, терміни постачання, безпечний запас за категоріями.
• Communications-канал (Slack, email або Telegram) для розсилки алертів з API-доступом.

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

• Власник процесу з боку закупівель — приймає рішення за алертами і надає зворотний зв'язок моделі.
• Техлід або аналітик для налаштування pipeline і роботи з warehouse.
• Узгоджений формат алерта і SLA на реакцію (наприклад: alert прийшов вранці — рішення до кінця дня).
• Політика дій при false positive / false negative: хто і як оновлює пороги.

Терміни

Для простого варіанту з чистими даними впровадження займає 2-4 тижні:

1. Тиждень 1: аудит даних, baseline-модель, ретро-валідація.
2. Тиждень 2: pipeline, scheduler, інтеграція з communications.
3. Тиждень 3-4: пілот, калібрування порогів, масштабування на каталог.

Якщо історія продажів фрагментована, залишки несинхронізовані або потрібно покрити десятки тисяч SKU з довгим хвостом — терміни зростають до 6-10 тижнів, а рішення переходить у категорію medium.