BI в ритейле: запасы, спрос и маркетинг

Источник - Росстат, «Торговля в России. 2025»

Один SKU - несколько состояний 

Даже внутри одного канала товар существует одновременно в нескольких состояниях. 

В учётной системе записан остаток. Часть товара зарезервирована. На маркетплейсе доступно своё количество. На складе находится партия, срок хранения которой приближается к критическому. Следующая поставка уже едет. В одном магазине товар заканчивается, в другом продаётся медленно. 

Поэтому цифра: «остаток – 600 единиц» сама по себе почти ничего не говорит о состоянии запаса. 

Похожая ситуация возникает с продажами. Рост выручки может быть связан с реальным увеличением спроса, изменением цены, промо, открытием новой точки, изменением ассортимента или перераспределением спроса между товарами. 

Для анализа приходится связывать цепочку: 
продажа → товар → магазин → запас → закупка → цена → промо → покупатель → финансовый результат

Какие решения должен поддерживать BI 

Ценность появляется в связях между данными и действиями пользователя.


Решение о закупке, например, зависит одновременно от доступного остатка, скорости продаж, товара в пути и даты следующего поступления.

Какие метрики нужны BI в ритейле

Количество показателей само по себе не делает BI полезнее. 
Для каждой метрики нужно заранее определить формулу, гранулярность и действие пользователя при отклонении.


У части показателей нет единственной универсальной бизнес-формулы. 

Отсутствие товара на складе - можно рассчитывать по часам доступности, дням, комбинации SKU × магазин или доле спроса, который не удалось закрыть наличием. 
Коэффициент списания можно считать относительно продаж, поступлений или среднего запаса. 

Поэтому определение метрики должно храниться рядом с самим показателем. 

Фраза «у нас наличие/доступность 96%» малоинформативна, если отдел закупок, логистика и BI-команда рассчитывают эти 96% по разным правилам.

Запасы и закупки 

Для управления запасами BI должен отвечать на конкретные вопросы: где возникает риск дефицита, где сформировался избыток, какой товар перестал двигаться и успеет ли следующая поставка до исчерпания остатка. 

1С, ERP или WMS продолжают фиксировать приходы, списания, перемещения, резервы и инвентаризации. Аналитический контур связывает результаты этих операций со спросом и показывает последствия. 

Остаток нужно связать со спросом 

Предположим, доступно 600 единиц товара. 
Если продажи составляют 10 единиц в день, запаса хватит примерно на: 
600 / 10 = 60 дней 

При спросе 150 единиц в день: 
600 / 150 = 4 дня 

Один из базовых расчётов: 
дни покрытия = доступный остаток / ожидаемый среднедневной спрос 

Одинаковый остаток в первом сценарии может означать избыточный запас, а во втором – близкий дефицит.


Для сезонных категорий простое среднее может давать искажение. 
Расчёт потребности тогда уже требует прогноза спроса.

Сигналы для работы с запасом 

Полезнее выводить пользователю не десятки графиков, а список исключений.


После сигнала пользователь должен иметь возможность перейти к SKU, магазину, движению товара и периоду, который сформировал отклонение. 

Расчёт потребности 

Базовая цепочка может выглядеть так: 
текущий запас → ожидаемый спрос → страховой запас → товар в пути → срок поставки → потребность

Для относительно стабильного спроса можно использовать упрощённую точку повторного заказа: 
Reorder Point = спрос за lead time + страховой запас 

Предположим: 

• средний спрос – 24 единицы в день; 
• срок поставки – 9 дней; 
• страховой запас – четыре дня спроса. 

Тогда: 24 × (9 + 4) = 312 единиц 

При приближении доступного запаса к 312 единицам появляется основание для нового заказа. 

В рабочей закупочной модели возникают дополнительные ограничения: минимальная партия поставщика, кратность упаковки, календарь поставок, ёмкость склада, срок хранения, сезонность и финансовые ограничения. 

Правила расчёта лучше закреплять в модели подготовки данных или специализированном контуре планирования. BI показывает результат, исключения и детализацию для принятия решения.

Расчёт: дефицит до поставки 

Рассмотрим более насыщенный сценарий для одного SKU.


Первые два дня товар продаётся в обычном режиме: 
115 × 2 = 230 шт. 

Затем начинается промо. 

Ожидаемый спрос во время акции: 
115 × 1,35 ≈ 155 шт./день 

За следующие четыре дня: 
155 × 4 = 620 шт. 

Общий ожидаемый спрос до поставки: 
230 + 620 = 850 шт. 

Но доступно только 690 единиц. 

Расчётный дефицит: 
850 – 690 = 160 шт. 

Если процесс оставить без изменения, запас закончится до прихода следующей партии. 

При промоцене 449 рублей верхняя оценка выручки, находящейся под риском: 
160 × 449 = 71 840 ₽ 
Расчётная валовая прибыль этого объёма: 
160 × (449 – 350) = 15 840 ₽ 

Назвать 71 840 рублей гарантированной потерянной выручкой нельзя. 
Часть покупателей может выбрать аналог, перейти в другой магазин, перенести покупку или отказаться от неё. 
Но BI уже дал конкретный объект для решения: 
160 единиц потенциального дефицита. 

Допустим, в соседнем магазине находится 620 единиц того же SKU, а спрос составляет 40 штук в день. 

Покрытие: 
620 / 40 = 15,5 дня 
Если переместить 180 единиц, останется: 
440 / 40 = 11 дней покрытия 

В первой точке риск stockout снижается, а во второй сохраняется запас на 11 дней. 

Дальше бизнес сравнивает стоимость перемещения с маржой, страховым запасом и риском отсутствия товара. 

Именно такой сценарий показывает отличие отчёта об остатках от системы поддержки решения: 
сигнал → расчёт → причина → вариант действия → проверка результата

Кейс «Цветы Любимым» 

Сеть «Цветы Любимым» объединяет 15 торговых точек и два склада. 

До проекта данные для управленческой аналитики находились в 1С и отдельных Excel-файлах. 

Для закупок требовалось сопоставлять поступления, продажи, списания, уценки и остатки. 

В проекте был построен контур: 
1С + Excel → Экстрактор 1С → ClickHouse → DVT → DataLens 

Для подготовки заявок на закупку реализовали четыре модели расчёта. 

Аналитику можно детализировать от сети до магазина и отдельной товарной позиции. 

Проект развивался пятью этапами с апреля 2025 года по май 2026 года; два Excel-источника удалось исключить после переноса расчётов на данные 1С. 

Этот кейс показывает удобную последовательность развития retail BI: сначала закрывается один регулярный управленческий сценарий, затем на созданной модели данных появляются следующие.

Спрос и прогнозирование 

История продаж и реальный спрос могут расходиться. 

Товар мог закончиться. Магазин мог быть закрыт. Цена менялась. На SKU действовало промо. Покупатели могли переключиться на заменитель. 

Если эти события не отметить в данных, модель может воспринимать их как обычное изменение покупательского поведения. 

Продажи могут скрывать спрос 

Допустим, товар продавался так: 
40 → 42 → 39 → 0 → 0 → 0 

Если последние три дня товара не было, нулевые продажи ещё не означают нулевой спрос. 
Средний объём первых трёх дней: 
(40 + 42 + 39) / 3 = 40,3 единицы 

Если последние три дня SKU отсутствовал, потенциальный незакрытый спрос при сохранении прежнего темпа: 
40,3 × 3 ≈ 121 единица

При цене 450 рублей верхняя оценка выручки, относящейся к этому объёму: 
121 × 450 = 54 450 ₽ 

Эта сумма тоже не равна автоматически потерянной выручке. 
Покупатель мог выбрать заменитель, другой канал или перенести покупку. 
Поэтому прогнозирование нужно связывать с наличием товара.

Что нужно прогнозной модели 

Набор данных для forecasting-сценария обычно шире простой истории продаж:

продажи + наличие + остаток + цена + промо + сезонность + календарь + магазин + категория + поставки 

В отдельных сценариях добавляются погода, локальные события, поисковый интерес и другие внешние признаки. 

BI может отображать прогноз и сравнивать его с фактом. 

Для полноценной модели дополнительно нужны: 

• исторические данные; 
• корректная гранулярность; 
• признаки, влияющие на спрос; 
• алгоритм прогнозирования; 
• backtesting; 
• метрика ошибки; 
• регулярная проверка модели; 
• анализ отклонения прогноза от факта. 

Сама модель может выполняться в Python, SQL, ML-платформе или другом вычислительном контуре. 

BI получает результат: 
прогноз → факт → отклонение → SKU → магазин → причина

Что искажает прогноз:

• Промо. Период со скидкой нельзя механически использовать как обычную историю продаж. 
• Каннибализация. Рост одного SKU может сопровождаться снижением продаж соседнего товара. 
• Stock-up. Покупатель может купить во время акции товар впрок, забрав часть будущего спроса. 
• Новый товар. Для SKU без собственной истории приходится искать аналоги по категории, цене, магазину и другим признакам. 
• Излишняя агрегация. Общая динамика сети может скрывать противоположное поведение отдельных магазинов. 
• Отсутствие товара. Ноль продаж без признака OOS искажает историю спроса.

Российский кейс прогнозирования 

Показательный пример – проект X5 по автоматизации прогнозирования спроса и пополнения товарного запаса в «Перекрёстке» и «Карусели». 

В системе использовались данные о продажах, маркетинговой и рыночной активности, изменениях цены, промо и внешних событиях. X5 сообщала, что после внедрения точность прогноза повысилась на 17%, фактическая доступность товара на полках – на 5%, а уровень товарного запаса снизился на 13%. Компания также сообщала о выходе проекта на положительный возврат инвестиций за два месяца вместо первоначально запланированных восьми. Эти показатели относятся к конкретному проекту 2018 года и не могут использоваться как универсальный benchmark другого внедрения. 

Для retail BI здесь важна сама причинная цепочка: 
точнее прогноз → точнее заказ → выше доступность → меньше потребность держать избыточный запас 

Эта логика сохраняется и в текущей практике крупного российского ритейла. В 2026 году X5 описывает классическое машинное обучение как часть ценообразования, прогнозирования спроса, управления запасами и логистики; модели учитывают спрос, покупательское поведение, сезонность и конкурентную среду. 

По итогам 2025 года X5 также сообщила примерно о 5 млрд рублей дополнительной операционной прибыли от совокупности внедрённых AI-решений. Основной вклад компания связывает с моделями в прогнозировании спроса и пополнении, ценообразовании, управлении ассортиментом и рекомендательных механиках. Это совокупный эффект нескольких направлений, поэтому относить все 5 млрд к прогнозированию или BI было бы некорректно.

Как проверить экономику промо 

Рост продаж одного товара ещё не раскрывает результат акции. 

Предположим, обычная цена SKU – 500 рублей. 
Себестоимость – 325 рублей. 
Обычный объём – 1000 единиц. 

Выручка: 
1000 × 500 = 500 000 ₽ 

Валовая прибыль: 
1000 × (500 – 325) = 175 000 ₽ 

Во время акции цену снизили до 450 рублей, а продажи выросли до 1400 единиц. 

Выручка: 
1400 × 450 = 630 000 ₽ 

То есть: 
объём +40% 
выручка +26% 

Валовая прибыль: 
1400 × (450 – 325) = 175 000 ₽ 

Она осталась прежней. 

Акция дала заметный прирост продаж и выручки, но на уровне валовой прибыли результат равен исходному периоду. 

Если добавить рекламные расходы, дополнительные логистические затраты, каннибализацию соседних SKU или stock-up, экономика может стать отрицательной. 

Поэтому промо-анализ должен учитывать: 
инкрементальные продажи → маржу → каннибализацию → stock-up → halo effect → наличие → повторную покупку

Аналитика становится рабочим контуром 

Показателен пример Dialog X5. 

В марте 2025 года X5 открыла поставщикам расширенную аналитику продаж. Сервис позволяет анализировать динамику спроса в натуральном и денежном выражении на уровне сети и регионов; в текущем продукте также доступны показатели контракта, продаж, промо и другие срезы. 

К октябрю 2025 года X5 сообщала, что уже 50% действующих поставщиков регулярно используют аналитику Dialog X5 в операционной и стратегической работе. В «Барометре контракта» доступны, в частности, оборачиваемость, РТО, уровень сервиса и доступность. 

X5 так формулирует задачу инструмента: 

«Его задача – не просто дать возможность следить за KPI, а стать основой для предметного диалога с ритейлером». 

Этот пример хорошо показывает зрелое состояние аналитики: данные становятся рабочим языком уже между несколькими участниками цепочки – ритейлером и поставщиком. 

Аналитическая система отвечает не только на вопрос «сколько продано». 

Она позволяет искать причину отклонения: 
спрос → заказ → поставка → доступность → цена → промо → ассортимент

Архитектура retail BI 

Для компании, где основной учёт ведётся в 1С, базовый поток выглядит так: 

1С → Экстрактор 1С → DWH / аналитическая СУБД → BI 

Экстрактор 1С получает данные из 1С и передаёт их во внешний аналитический контур. 

Если источников несколько: 
1С → Экстрактор 1С 
CRM / API / файлы / СУБД → DVT 
данные → DVT → DWH / витрины → BI 

DVT используется для объединения, очистки, преобразования данных и формирования аналитических витрин.


Какая гранулярность нужна 

Ключевой принцип – заранее определить детализацию данных. 

Для управления запасами: SKU × магазин × день 

Для внутридневного контроля: SKU × магазин × час 

Для клиентского анализа: клиент × чек × товар 

Для поставок: SKU × поставщик × поставка 

Гранулярность определяется вопросом бизнеса. 
Если смешать данные разной детализации без явных правил агрегации, SQL может отработать технически корректно, но управленческий показатель окажется неверным.

Работа с большими объёмами 

Для крупных наборов данных важна уже техника чтения и обработки. 

В DVT нода Read Query DB V3 поддерживает сегментированное чтение SQL-запросов с параллельной обработкой частей набора, а архитектура выполнения проектов DVT основана на Dask. 

Масштаб рабочего контура показывает кейс Happywear Юг. В ClickHouse компании находится около 2 ТБ данных, а через Экстрактор регулярно обновляются более 50 таблиц, регистров и справочников. Аналитика детализируется до категорий и номенклатуры. 

Эти показатели относятся к конкретному проекту и не задают универсальный предел производительности Экстрактора или DVT. 

Для другого контура результат будет зависеть от инфраструктуры, структуры данных, запросов, частоты обновления, трансформаций и других параметров.

Внедрение и частые вопросы 

Как начать внедрение 

Первый пилот retail BI лучше строить вокруг одного регулярного управленческого решения. 

Например: 
Какие SKU нужно пополнить на следующей неделе? 

Такая постановка сразу задаёт минимальный набор данных: 
продажи → остатки → поступления → товар в пути → срок поставки 

Если начинать с общей задачи «сделать BI для ритейла», проект быстро разрастается. Появляются десятки показателей, несколько источников, разные уровни детализации и пользователи с разными требованиями. 

Пилот вокруг одного решения проще проверить: понятно, кто пользуется аналитикой, какое действие должен выполнить человек и по какому критерию оценивается результат. 

Шесть шагов пилота 

1. Зафиксировать решение 

Сначала нужно определить действие пользователя. Например: закупщик регулярно получает список SKU с риском дефицита и данные для расчёта пополнения.
 
2. Описать исходный процесс 

До автоматизации нужно понять, как задача решается сейчас. 

Полезно зафиксировать: 

• время подготовки отчёта; 
• количество Excel-файлов; 
• объём ручного переноса данных;
• периодичность обновления; 
• количество сверок; 
• участников процесса. 

Это создаёт исходную точку, с которой можно сравнивать новый процесс.
 
3. Определить источники 

Для каждого показателя фиксируются: 

• система-источник; 
• объект или таблица; 
• владелец данных; 
• гранулярность; 
• частота обновления; 
• идентификаторы объектов. 

Например, продажи могут находиться в POS или 1С, остаток – в 1С, товар в пути – в ERP, а срок поставки – в отдельном справочнике. 

До построения витрины данные нужно связать через согласованные идентификаторы SKU, магазина, склада и поставщика. 

4. Проверить качество 

Для ритейла критичны: 

• дубли SKU; 
• разные справочники магазинов; 
• несовпадающие единицы измерения; 
• возвраты; 
• отрицательные остатки;
• пропуски в истории продаж;
• разные даты одного события; 
• нестабильные идентификаторы клиентов. 

Например, упаковка из шести единиц и одна штука могут храниться в разных системах с разными единицами измерения. 

Без нормализации аналитика получит расхождение в шесть раз, хотя SQL и все последующие расчёты технически выполнятся без ошибки. 

5. Построить одну витрину 

Первый контур можно ограничить одной гранулярностью: 

SKU × магазин × день 

и небольшим набором показателей: 
остаток → продажи → прогноз → товар в пути → дни покрытия → риск дефицита 

После проверки модели можно добавлять: 
страховой запас → минимальную партию → поставщика → сезонность → промо → перемещения → стоимость запаса → маржу 

Так проще отделить проблему качества данных от сложности бизнес-логики. 

6. Проверить рабочий сценарий 

Финальный тест пилота – возможность выполнить действие. 

Рабочая цепочка: 
отклонение → SKU → причина → решение → действие → проверка результата 

Например: 
риск дефицита → магазин → SKU → задержка поставки → избыток в другой точке → перемещение → контроль остатка 

Если пользователь дошёл до графика и на этом процесс закончился, аналитический контур ещё не встроен в управление.

Что считать результатом пилота 

Первый проект не обязан сразу охватывать всю сеть, весь ассортимент и все доступные источники. 

Для пилота достаточно доказать работоспособность полного цикла: 

данные → расчёт → исключение → детализация → действие → проверка 

После этого становится понятно, какие правила можно масштабировать на другие магазины, категории и процессы, а какие требуют отдельной логики. 

Так снижается риск построить большой BI-контур с десятками показателей, который плохо поддерживает ежедневные решения.