Прогнозування дефіциту з відновленням втрачених продажів

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

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

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

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

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

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

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

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

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

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

1. Щоденне вивантаження даних.Планувальник (cron, Airflow або рушій робочих процесів) запускає конвеєр вранці до початку зміни команди закупівель. Скрипт робить запити до сховища даних та вивантажує продажі за релевантний період, поточні залишки й довідник SKU.
2. Підготовка ознак. Розраховуються ковзні середні продажів по SKU, тижнева та річна сезонність, тренд, швидкість оборотності. Враховується час постачання від постачальника — від моменту замовлення до приходу товару на склад.
3. Модель прогнозу. Для кожного SKU розраховується очікуване споживання на горизонт до наступної можливої поставки. У базовій версії використовуються статистичні методи (експоненційне згладжування, Prophet); у просунутій — градієнтний бустинг з урахуванням зовнішніх факторів (акції, свята).
4. Оцінка ризику дефіциту. На основі прогнозу та поточного залишку розраховується вірогідність вичерпання запасів до приходу наступної поставки та рекомендований обсяг замовлення.
5. Фільтр і пріоритизація. SKU з високою вірогідністю дефіциту і значною маржею або оборотом відбираються в алерт. Решта логуються без сповіщень, щоб не створювати шум.
6. Сповіщення. Алерт надсилається у канал сповіщень із переліком SKU, причинами, рекомендацією та дедлайном для рішення.
7. Зворотний зв'язок. Рішення байера (замовив / відклав / проігнорував) логуються та використовуються для калібрування порогів і перекалібрування моделі.

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

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

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

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

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

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

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

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

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

Терміни

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

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

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