МОДУЛЬ 4. Измерение и контроль Out-of-Stock: методы, алгоритмы, автоматизация
Чтобы управлять чем-либо — нужно это измерять. Управление уровнем Out-of-Stock (OOS) невозможно без системной и регулярной диагностики. В этом модуле мы разберем, как измеряется OOS, какие подходы существуют, какие алгоритмы наиболее точны, и главное — как автоматизировать процесс измерения и интегрировать его в BI и DWH-среду.
Мы будем рассматривать тему с позиции системного аналитика, архитектора данных и специалиста по BI. В фокусе — практическая реализация: SQL, алгоритмы, автоматизация, контроль качества и минимизация ошибок.
Что именно мы измеряем
Out-of-Stock — это не одна метрика, а целый набор измерений, отражающих разные аспекты недоступности товара. Вот основные типы метрик:
-
Item OOS Event Rate
Частота возникновения события OOS для одного SKU
Формула:
Количество OOS-событий / Количество возможных дней продаж -
Category OOS Event Rate
Доля товаров в категории, находящихся в состоянии OOS
Формула:
Кол-во SKU в категории с OOS / Всего SKU в категории -
OOS Duration Rate
Доля времени, когда товар отсутствовал
Формула:
Суммарное OOS-время / Общее рабочее время магазина -
Shelf Availability Rate
Вероятность найти товар на полке
Формула:
100% – OOS Duration Rate -
OOS Lost Unit Sales Rate
Потерянные продажи в штуках
Формула:
Потерянные продажи / (Фактические продажи + Потери) -
OOS Lost Revenue Rate
Потери в денежном выражении
Формула:
Потерянная выручка / (Фактическая выручка + Потери) -
OOS Customer Impact Rate
Влияние на клиентов (на корзины)
Формула:
1 – ((Ожидаемые корзины – Факт корзины) / Ожидаемые корзины)
Подходы к измерению OOS
Три метода измерения OOS, каждый со своими плюсами и минусами:
Метод 1. Ручной аудит (manual audit)
- Проверка полок визуально сотрудниками или мерчендайзерами
- Записываются "дыры", где товар должен быть, но его нет
Плюсы:
- Высокая достоверность при правильной методике
- Учитывает реальные выкладки, а не данные системы
Минусы:
- Ограниченность по частоте
- Высокая стоимость
- Не масштабируется на сеть из сотен магазинов
Метод 2. Анализ POS-данных (Point-of-Sale)
- OOS фиксируется при отсутствии продаж при наличии спроса
Алгоритм:
- Строится дневной (или почасовой) ряд продаж по SKU
- Если ранее были регулярные продажи, а в конкретный день — 0, возникает подозрение на OOS
- При этом смотрим на остатки: если остаток равен 0 — подтверждаем OOS
Плюсы:
- Автоматизируется, масштабируется
- Дешевый и устойчивый способ мониторинга
Минусы:
- Возможны ложноположительные случаи (например, реального спроса не было)
- Требует точного учета остатков и стабильного SKU-оборота
Метод 3. Перпетуальные запасы (Perpetual Inventory, PI)
- OOS измеряется по системным остаткам в системе
Пример:
- Если в учете stock_qty = 0, значит товар считается OOS
- Можно использовать для расчета долей времени, когда товар отсутствовал
Минусы:
- Часто присутствуют ошибки PI (phantom inventory)
- Не учитываются ситуации, когда товар есть, но не выложен
Автоматизация расчета метрик в DWH
Вся автоматизация сводится к построению аналитической витрины OOS_Events, в которой хранятся события отсутствия товара.
Ключевые поля витрины:
- SKU_ID
- Store_ID
- Date
- Sales_Qty
- Stock_Qty
- Is_OOS (флаг события)
- OOS_Type (Store/Shelf)
- OOS_Start_Date, OOS_End_Date
- Duration
- Lost_Sales
- Lost_Revenue
Алгоритм расчета событий OOS:
- Берем данные о продажах, остатках и поставках по SKU-Store-Day
- Если Stock_Qty = 0 и Sales_Qty = 0 — возможно OOS
- Если ранее продажи были стабильными — подтверждаем OOS
- Фиксируем дату начала и дату окончания
- Расчитываем потери: прогноз – факт
Пример SQL:
SELECT
s.SKU_ID,
s.Store_ID,
s.Date,
CASE
WHEN st.Stock_Qty = 0 AND s.Sales_Qty = 0 AND prev.Sales_Qty > 0 THEN 1
ELSE 0
END AS Is_OOS,
f.Forecast_Qty,
s.Sales_Qty,
f.Forecast_Qty - s.Sales_Qty AS Lost_Sales,
(f.Forecast_Qty - s.Sales_Qty) * p.Price AS Lost_Revenue
FROM fact_sales s
JOIN fact_stock st ON s.SKU_ID = st.SKU_ID AND s.Store_ID = st.Store_ID AND s.Date = st.Date
LEFT JOIN fact_forecast f ON s.SKU_ID = f.SKU_ID AND s.Store_ID = f.Store_ID AND s.Date = f.Date
LEFT JOIN dim_sku p ON s.SKU_ID = p.SKU_ID
LEFT JOIN (
SELECT SKU_ID, Store_ID, Date, Sales_Qty
FROM fact_sales
WHERE Date = CURRENT_DATE - INTERVAL '1 day'
) prev ON s.SKU_ID = prev.SKU_ID AND s.Store_ID = prev.Store_ID
Интерпретация результатов
Важно не просто фиксировать факт OOS, а анализировать паттерны:
- Повторяется ли отсутствие по определенным дням недели?
- Коррелирует ли с поставками?
- Возникает ли одновременно по нескольким товарам из одной категории?
На основе анализа можно строить BI-дашборды:
- Воронка потерь: от SKU до потерь в выручке
- Повторяющиеся паттерны (анализ временных рядов)
- Географическая карта OOS по регионам/магазинам
Использование BI для ежедневного контроля
-
Оперативный дашборд:
- Текущий уровень OOS
- Магазины, где доля SKU в OOS превышает 10%
- Категории с наибольшими потерями
- План-факт по заказу:
- Сравнение поставок и продаж
- Предупреждения об отклонении в прогнозе
- BI-правило: если SKU с KVI-флагом имеет OOS более 3 дней подряд — отправить уведомление менеджеру
- Интеграция с мессенджерами и задачами
- Автоматизация тревог:
Как бороться с рисками
|
Риск |
Метод решения |
|---|---|
|
Неверные остатки |
Сверка PI и факта, контроль расхождений, витрина Stock_Control |
|
Проблемы с чековой детализацией |
Требуется POS с транзакциями по SKU и времени |
|
Ложные OOS по редким товарам |
Настройка фильтров: минимум продаж за период для включения в аналитику |
|
Погрешности прогноза |
MAPE-контроль, ручная корректировка, гибридный подход |
|
Ошибки в планограммах |
Внедрение цифровой планограммы и проверка POG-compliance |
Измерение OOS — это не задача раз в месяц, это постоянный аналитический процесс. BI-система должна обеспечивать ежедневную прозрачность ситуации по всей сети. Хранилище данных играет ключевую роль: именно оно аккумулирует все сигналы, соединяет между собой продажи, остатки, поставки, прогнозы и операции на полке.
Главная задача автоматизации — не только фиксировать факт отсутствия товара, но и сделать его предсказуемым и управляемым.
