Склад забит, а ходовые товары заканчиваются. Как мы научили систему считать закупки
У ритейла одновременно две дорогие проблемы.
Склад забит товаром — деньги заморожены в запасах. По отчётам всё выглядит неплохо: остатки сокращаются, DSI улучшается.
И тут же заканчиваются ходовые позиции — компания теряет продажи там, где могла бы зарабатывать.
Самое неприятное: эти проблемы могут существовать одновременно.
Одни говорят: «Нужно сокращать запасы». Другие: «Нельзя допускать out-of-stock».
Оба правы. И именно поэтому простое управление одной метрикой здесь не работает.
Почему закупки всё ещё часто считают вручную
На поверхности всё выглядит просто:
продажи → прогноз → заказ поставщику.
Дальше категорийный менеджер корректирует заказ в Excel.
Но у каждого SKU своя реальность. На объём закупки одновременно влияют:
- скорость и вариативность продаж;
- сезонность;
- текущий остаток;
- уже заказанный товар;
- срок поставки;
- минимальная партия;
- целевой уровень доступности;
- риск дефицита.
Если всё это свести к средним продажам, система будет регулярно ошибаться.
Сократили запас — и неожиданно закончился лидер продаж.
Увеличили страховой запас — и ещё больше денег заморозили в товаре, который продаётся месяцами.
Получается парадокс: склад может быть одновременно переполнен и недостаточно обеспечен.
Поэтому мы сделали не ещё один дашборд
В этом проекте BI — только верхний слой.
Основная работа происходит внутри ML-модели, которая рассчитывает закупку на уровне конкретного SKU.
Для каждого товара система прогнозирует спрос и определяет, сколько нужно заказать с учётом остатков, поставок в пути, сезонности и сроков поставки.
При этом модель не пытается просто минимизировать склад.
Для ходовых товаров действует ограничение по доступности: если сокращение заказа создаёт высокий риск out-of-stock, система не выбирает его ради красивого показателя DSI.
То есть задача модели звучит не как:
«Как держать меньше товара?»
А как:
«Как держать минимальный необходимый запас, не потеряв продажи?»
Где здесь появляются деньги
В одном из сценариев модель обнаружила избыточное покрытие по части категорий.
Там можно было сократить закупки и высвободить около 18 млн ₽ капитала.
Но одновременно по нескольким A-SKU система увидела риск дефицита.
Поэтому около 4 млн ₽ из высвобождаемого капитала мы направили в дополнительный запас ходовых позиций.
Получается совсем другая экономика:
18 млн ₽ — высвобождаем из избыточных запасов. 4 млн ₽ — дополнительно защищаем в товарах, которые нельзя отдавать в out-of-stock.
Вместо борьбы финансов с коммерцией появляется единое решение по капиталу и доступности.
А дашборд здесь — уже финальный слой
Вся сложная работа происходит до него.
Модель считает закупки, а BI показывает руководителю результат:
что заказать → сколько заказать → где можно сократить запас → сколько капитала высвободится → где появляется риск дефицита.
Поэтому я бы вообще не называл такой инструмент «дашбордом по запасам».
Это система управления закупками, в которой дашборд — просто интерфейс для принятия решений.
В итоге задача перестаёт звучать как:
«Давайте снизим запасы».
Она звучит гораздо точнее:
«Какой минимальный объём капитала нужно держать в товаре, чтобы сохранить нужную доступность и не потерять продажи?»
Именно этот вопрос мы и отдали модели.
А BI оставили человеку — чтобы он видел, что происходит с деньгами и почему система рекомендует именно такие закупки.