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. Отправляет структурированный alert в 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.