AI-система управления ассортиментом: оптимизация и рост выручки

Управление ассортиментом AI: где ломается ручная логика

Товарную матрицу пересматривают раз в квартал — в таблице, по итогам закрытого периода. Пока позиции согласуют между закупкой, коммерцией и складом, спрос успевает уехать: то, что было в топе, уходит в хвост, а введённые новинки приезжают под уже отработанный сезон.

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

Цена такого сбоя накапливается медленно. Неликвиды на складе занимают место и оборотный капитал, а рядом растёт дефицит по позициям, которые как раз продаются. Несоответствие спроса и предложения проявляется через два-три цикла закупки — и его удобно списать на сезонность или на поставщика.

Классический ABC/XYZ-разбор по итогам месяца проблему не снимает: он тоже смотрит назад и усредняет всплески. Локальный рост в разрезе канала, региона и размера в нём не виден, поэтому решение всё равно принимает человек — по опыту и по последней выгрузке.

Управление ассортиментом AI меняет точку опроса: модель считает спрос по каждой позиции отдельно и в разрезе каналов, а решение о вводе и выводе строится на прогнозе, а не на прошлом периоде. Разбираем, из чего складывается такая система и что она даёт в цифрах.

Что меняется после внедрения: измеримые эффекты

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

Точность прогноза спроса считаем раздельно — по товарной позиции, складу и неделе, а не усреднённо по категории: внутри группы ошибки взаимно гасятся, и метрика начинает врать. Базовый сезонный профиль строим на открытой модели Prophet, поверх неё модель дообучается на промо и локальных всплесках. Ошибка прогноза на сопоставимом горизонте падает на 20–35% против планирования по среднему за прошлый период.

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

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

Режимы работы модели: пакетный, потоковый, гибридный

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

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

На практике чаще берут гибрид: топ позиций и акционные группы пересчитываются по событиям, остальная матрица — регламентным пакетом. Оба контура пишут в одну витрину рекомендаций с версионированием, поэтому обновление матрицы остаётся воспроизводимым, а расхождения между расчётами разрешаются по приоритету, а не по времени записи в базу.

Как мы внедряем систему: этапы инженерной работы

Внедрение идёт итерациями: каждый этап заканчивается артефактом, который проверяется на исторических данных, а не статусом в отчёте. Модель не запускается на всей матрице сразу — сначала узкий контур, где рекомендации сопоставимы с текущей политикой закупки, и только потом расширение. Ниже — последовательность работ.

1. Аудит данных. Собираем историю продаж, остатков, поставок, скидок и промо за доступный период; проверяем полноту матрицы «товар — день», дубли, пропуски и разрывы в справочниках. Фиксируем, какие категории данных достаточно для прогноза, а какие придётся вести по ручным правилам.
2. Схема модели. Определяем горизонт прогноза и уровень решения — отдельная товарная позиция или кластер взаимозаменяемых. В признаки идут сезонность, промо, эластичность спроса, срок годности и каннибализация; схема валидируется на отложенном периоде, который модель не видела.
3. Настройка правил отбора. Поверх прогноза накладываются ограничения бизнеса: минимальная выкладка, кратность упаковки, полочное пространство, лимиты поставщика. Правила лежат отдельно от модели, поэтому меняются без переобучения и согласуются с категорийными менеджерами.
4. Проверка качества рекомендаций. Сравниваем предложенную политику закупки с фактической на тех же периодах: считаем точность, долю дефицита, объём излишков и число ручных правок. Если рекомендации не выигрывают у текущего процесса — возвращаемся к схеме модели, а не расширяем пилот.
5. Пилот на ограниченном контуре. Запускаем на нескольких категориях параллельно с прежним процессом, сверяем план и факт каждую неделю и настраиваем пороги срабатывания.
6. Передача в эксплуатацию. Отдаём регламент переобучения, панель контроля деградации прогноза, инструкции для менеджеров и порядок отката к прежним правилам, если качество уходит ниже согласованного порога.

Что передаём на руки: конфигурации и регламенты

Передаём не «работающую систему», а набор артефактов, по которым ваша команда сможет менять правила сама — без обращения к нам за каждой корректировкой. Каждый пункт проверяем на приёмке: если по документу нельзя воспроизвести шаг, он не считается сданным.

• Конфигурация модели: признаки, пороги срабатывания, веса правил и границы, за которыми решение уходит на ручную проверку — с пояснением, как настройка влияет на выдачу.
• Регламент пересборки ассортимента: периодичность, источники данных, порядок запуска, контрольные точки и условия, при которых пересборку останавливают и возвращают предыдущую версию.
• Политики доступа и роли: кто меняет правила, кто только смотрит, кто согласует вывод категории — с разделением по уровням и журналом действий.
• Схема интеграции с учётной системой: откуда берутся справочники и остатки, как часто идёт синхронизация, что делать при расхождении и как читать журнал обмена.
• Документация на систему: логика решений, словарь данных, инструкции для аналитика и оператора, порядок эскалации сбоев.
• Набор проверок: сценарии на типовые и граничные случаи — новая категория, нулевой остаток, сезонный всплеск — чтобы правки не ломали выдачу.
• План передачи: совместный разбор с вашей командой, прогон пересборки на вашей стороне и период сопровождения изменений.

После приёмки правки в правилах, запуск пересборки и разбор сбоев ваша команда закрывает по регламенту — мы остаёмся на связи, когда меняется сама логика.

Кейс: пересборка ассортимента и уход от неликвидов

Дистрибьютор с матрицей около 9 000 артикулов пересобирал ассортимент раз в сезон. Категорийные менеджеры сводили продажи, остатки и условия поставок в таблицах — на одну пересборку уходило три недели, и к её концу часть расчётов уже была неактуальна.

Цена такого режима видна в цифрах того периода: доля неликвидов держалась на 34%, точность попадания в спрос не превышала 58%, а выведенные ранее позиции возвращались в матрицу по инерции — данных для уверенного решения не хватало.

Что изменили

Модель считает спрос по каждому артикулу ежедневно: сезонность, оборачиваемость, влияние соседних позиций и акций. На выходе — четыре класса рекомендаций: оставить, сократить долю, вывести, ввести замену. Данные подтягиваются из 1С без ручных выгрузок, поэтому пересборка матрицы занимает два рабочих дня вместо трёх недель.

Метрики до и после

• Доля неликвидов: 34% → 11% за два квартала.
• Точность попадания в спрос: 58% → 84%.
• Пересборка матрицы: три недели → два дня.
• Выручка на артикул: +19% при том же объёме полки.
• Срок до эффекта: первые решения по выводу — на третьей неделе, устойчивый сдвиг — к концу второго квартала.

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

Чем модель ранжирования отличается от правил на пороге

Правила на пороге — детерминированный слой: товар попадает в выдачу, только если выполнены условия по остатку, сроку поставки и ограничениям площадки. Такой слой объясним и воспроизводим — любой показ разбирается по шагам. Там, где ошибка дорога (запрещённая категория, нулевой остаток, истёкший срок), правила надёжнее любой модели.

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

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

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

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

Технические сомнения перед стартом проекта

Сомнения перед стартом касаются не алгоритмов, а данных и процессов. Ниже — пять вопросов, которые мы закрываем до запуска, чтобы результат не зависел от качества исходных выгрузок.

Хватит ли объёма истории продаж?

Для недельного прогноза нужен полтора-два полных цикла продаж — иначе не видно спадов. Короткую историю агрегируем до категорий: точность по отдельным позициям ниже, и это проговариваем заранее.

Почему система так рекомендует?

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

Учтёте нашу сезонность?

Сезонные профили строим по каждой категории отдельно, с поправкой на праздники, акции и локальные события. Календарь сети задаётся явно — прошлые пики не переносятся на новый период механически.

Кто сопровождает модель после запуска?

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

Обсудим задачу и вернёмся с планом работ

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

По такому описанию собираем картину целиком и приходим с конкретикой:

• Разбор процесса — разложим управление ассортиментом на шаги и найдём, какие из них автоматизируются, а какие остаются за человеком.
• Схема данных и интеграций — покажем, откуда система берёт историю продаж, остатки и внешние факторы, и что нужно со стороны учётных систем.
• Оценка сроков — назовём длительность этапов и момент, когда появятся первые управленческие решения на данных.
• Состав команды — зафиксируем, кто ведёт аналитику, кто отвечает за модель, кто за внедрение и сопровождение.
• План работ — этапы с проверяемым результатом на каждом, без длинного «слепого» периода в начале.
• Критерии приёмки — заранее договоримся, по каким метрикам считаем решение работающим: точность прогноза, доля позиций с автоподсказкой, скорость реакции на изменение спроса.
• Старт проекта — определим первый участок ассортимента для запуска, чтобы эффект был виден до полного развёртывания.

Опишите задачу в свободной форме — текущий процесс, узкие места, что хотите получить. Мы вернёмся с оценкой, схемой решения и планом внедрения, а дальше уже решите, подходит ли состав команды и сроки.