МОДУЛЬ 2. Корневые причины Out-of-Stock: аналитический взгляд и автоматизация через данные
Когда мы говорим о проблеме отсутствия товара на полке — Out-of-Stock или сокращенно OOS — мы часто склонны видеть лишь вершину айсберга: "товар не нашли на полке — значит, надо заказать больше". Но если подходить к проблеме системно, особенно в контексте цифровой трансформации и использования хранилищ данных и BI, становится ясно: причины отсутствия товара — это сложная сеть взаимосвязанных факторов. В этом модуле мы разберем, какие именно причины лежат в основе OOS, как их классифицировать, как визуализировать и автоматизировать их отслеживание.
Мы не просто укажем на ошибки. Мы рассмотрим, как каждая из этих причин "живёт" в данных, и как правильно строить витрины, метрики и оповещения, чтобы поймать эти причины до того, как клиент столкнется с пустой полкой.
Общая классификация причин OOS
Согласно исследованию Gruen & Corsten и последующим практикам в ритейле, можно выделить 7 ключевых причин возникновения Out-of-Stock, каждая из которых имеет свои корневые источники в данных:
- Ошибки в данных о товаре (product master data)
- Ошибки в остатках (phantom inventory, inaccuracy in PI)
- Ошибки в прогнозе спроса
- Неритмичность или недостаточность поставок
- Ограниченность полочного пространства
- Несоблюдение планограмм (POG compliance)
- Ошибки в операциях на полке и ручном управлении
Мы разберем каждую из них с технической точки зрения.
Product data accuracy — ошибки в мастер-данных
Что это значит: товар неправильно описан в справочниках, содержит неверный EAN, неправильный pack-size, неверный case-pack или срок годности. Это приводит к неверной логистике, ошибкам в заказах, невозможности анализа через BI.
Как проявляется в данных:
- разные EAN на один и тот же товар в заказах
- дубли в каталоге
- несовпадения единиц измерения (штука против коробки)
- товар отображается как отсутствующий, хотя есть аналог с другим кодом
Формула оценки:
- Доля уникальных EAN на один SKU
- Количество дублирующих позиций в каталоге / общее количество SKU
Автоматизация:
- Использование справочников Golden Record в DWH
- Внедрение MDM (master data management)
- Контроль консистентности на этапе ETL (валидация, бизнес-правила)
Пример:
В сети из 500 магазинов товар "Сок яблочный 1л" зарегистрирован под 3 кодами. Один код актуален, два — устарели, но "живут" в базе. Автоматическая аналитика по остаткам "не видит" часть товара, отчего система делает ложный заказ.
Риски:
- отсутствие централизованной системы данных
- ручной ввод
- неавтоматизированные процессы очистки справочников
Inventory accuracy — ошибки в остатках (phantom inventory)
Одна из самых критичных проблем, особенно в автоматических заказах. Переполненные данные в PI-системах показывают, что товар есть, хотя по факту на складе пусто. Это тормозит автоматический перезаказ.
Как проявляется:
- реальный остаток = 0, а в системе числится > 0
- товар числится в магазине, но не выходит в продажу (не отгружается, не пробивается)
- остаток > 0, но POS-продаж нет более 7 дней
Формула оценки:
Inventory accuracy rate = (количество SKU с совпадающим PI и реальным остатком) / общее количество проверенных SKU
Автоматизация:
- построение витрины с PI vs фактические продажи
- ежедневная сверка остатков в BI
- тревожные сигналы, если остаток > 0, а продаж нет более X дней
Пример:
Система показывает 3 единицы товара, но продажи стоят на 0 более 10 дней. BI-алгоритм срабатывает и уведомляет категорийного менеджера о возможном phantom inventory.
Риски:
- отложенное обновление остатков в учетной системе
- складской персонал не списывает поврежденный или украденный товар
- ошибки при приемке
Demand forecasting error — ошибки прогнозирования
Ошибки в прогнозе порождают цепочку сбоев в заказах. Если прогноз недооценивает спрос, полки остаются пустыми. Если переоценивает — возникает избыток, но не в том магазине.
Как выявляется:
- пересечение прогноза vs факт в BI
- отсутствие тенденции роста прогноза при росте продаж
- неожиданные всплески дефицита на пике продаж
Формулы
MAPE (mean absolute percentage error) MAPE = (1/n) * ∑ |(Факт - Прогноз) / Факт| * 100%
Автоматизация:
- ML-модель прогнозирования на уровне SKU x Store x Day
- Интеграция прогноза в DWH
- BI-дашборды по точности прогноза
Пример:
Прогноз по товару "Молоко 2,5%" в июле занижен на 20% в дачном регионе. Алгоритм на Python (XGBoost) пересчитывает прогноз с учетом метео-данных и сезонности.
Риски:
- использование только средних значений
- отсутствие факторов: погода, промо, праздники
- ручная корректировка без истории
Replenishment error — сбои пополнения
Поставка может прийти не вовремя или в меньшем объеме, чем нужно. Часто причина — несовпадение между ритмом продаж и графиком поставок.
Проявление:
- регулярные провалы в один и тот же день недели
- одинаковые временные интервалы отсутствия товара
- POS-шаблоны "два дня есть, два дня нет"
Автоматизация:
- BI-анализ повторяющихся OOS-паттернов
- Витрина "Replenishment Diagnostics" по SKU x Store x Week
- Предиктивный расчет нужной частоты поставок
Пример:
Товар стабильно заканчивается в среду, а поставка — только по пятницам. BI-алгоритм предлагает либо увеличить safety stock, либо добавить поставку в среду.
Shelf capacity and planogram issues
Если товар физически не помещается на полку — он быстрее заканчивается, и до следующей поставки возникает OOS. Особенно часто с KVI-товарами.
Проявление:
- скорость продаж > Time Supply по планограмме
- доля продаж > доли полочного пространства
- POG выполнен, но не соответствует динамике
Формулы:
Time supply = (количество товара на полке) / среднедневных продаж Если Time supply < среднего интервала пополнения — вероятен OOS.
Автоматизация:
- загрузка POG (из Excel, SAP Retail, JDA) в BI
- расчет фактического Time Supply на каждый SKU
- сигналы при несоответствии POG и спроса
Риски:
- отсутствие цифрового учета планограмм
- ручная выкладка без контроля
- отсутствие мониторинга compliance
Execution / shelf management issues
Даже если товар есть в магазине, но он не выложен — это классический Shelf OOS.
Проявление:
- продажи остановились, но товар в наличии
- не найден в аудитах, но числится в наличии
- SKU числится на складе, но не "пробивается"
Методология:
- Использование shelf-audit данных (мерчендайзер, компьютерное зрение)
- RFID на коробах
- Связь backroom-inventory и shelf-level
BI-решение:
- сравнение бэкрум остатков и POS-активности
- алгоритм «если остаток >0, а продаж нет >N дней» — то Shelf OOS
- дашборд по дисциплине выкладки (по дням недели, сменам, категориям)
Как бороться с рисками и автоматизировать
- Классифицируйте причины OOS в своей архитектуре: в справочниках, витринах, BI и правилах обработки.
- Стройте витрины с осознанной логикой: пусть витрина Inventory_Accuracy будет иметь столбцы Fact_Stock, System_Stock, Phantom_Flag.
- Автоматизируйте сигналы и тревоги: например, по матрице SKU vs Store: если MAPE > 30% и OOS Duration > 10%, отправьте инцидент в Trello, Jira или почту.
- Поддерживайте Data Quality: ошибки мастер-данных порождают всю цепочку сбоев.
- Используйте машинное обучение, но не забывайте про правила: гибридный подход (ML + правила) работает лучше всего.
