Не нейросеть вместо технолога, а прогноз внутри процесса

Перуанская кондитерская María Almenara показывает полезную для среднего бизнеса последовательность: сначала собрать операции в данные, затем связать прогноз с ограничениями производства и только после этого называть решение искусственным интеллектом.

Кейс OECD описывает путь компании от семейного бизнеса, начатого в 2007 году, к сети из 15 магазинов в Лиме и 421 сотрудника на момент исследования. Розничное направление открылось в 2017 году. На нынешней странице компании указаны уже 24 магазина и более 640 сотрудников. Эти цифры относятся к разным датам и показывают рост, но не доказывают, что его обеспечил только ИИ.

Основой системы стали кассы и интернет-магазин, передающие транзакции в ERP. По данным OECD, единая клиентская платформа собирала более 20 000 взаимодействий в месяц, а онлайн-канал давал 40% продаж. В данных были время и место покупки, товар, канал, а иногда и повод заказа. Только на такой базе появилась возможность оценивать спрос по магазину и продукту.

Прогноз учитывал повторяемые факторы: день недели, даты выплат зарплаты, праздники и температуру. В совместном проекте с MIT машинное обучение применяли не к абстрактной «продаваемости», а к планированию с учётом производственных и складских ограничений. Microsoft ранее сообщала, что интеграция прогноза с ERP позволяла строить дневные и недельные оценки по продуктам и торговым точкам. Показатель наличия товара, по заявлению поставщика, вырос с целевых 90% до 99%; это число следует считать заявленным результатом конкретного проекта, а не универсальным обещанием.

Как выглядит архитектура для российского предприятия

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

1. **Источник фактов.** Касса, сайт, маркетплейсы и ручные заказы передают строки продаж с едиными идентификаторами товара, магазина и времени.
2. **Справочники.** ERP хранит рецептуры, сроки годности, остатки, закупочные партии, производственные мощности и календарь цен.
3. **Витрина данных.** Процесс очистки исправляет возвраты, отмены, пропуски, смену кодов и выбросы. История сохраняется по дням и часам.
4. **Прогноз.** Модель оценивает спрос по товару и точке, показывает диапазон неопределённости и сравнивается с простым базовым правилом — например, продажами того же дня недели.
5. **Планировщик.** Отдельный алгоритм превращает прогноз в задание, учитывая минимальную партию, доступную печь, персонал, срок хранения и запас сырья. Руководитель смены подтверждает или корректирует выпуск.

Это разделение принципиально. Прогноз отвечает на вопрос «сколько, вероятно, купят», а оптимизатор — «сколько разумно произвести при наших ограничениях». Если смешать задачи, красивый прогноз может создать невыполнимое задание или лишние списания.

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

Какие данные нужны до пилота

Минимальный набор — 6–12 месяцев продаж по позиции и точке. Для выраженной годовой сезонности желательно 18–24 месяца. В строки должны попадать:

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

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

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

Как измерять эффект без самообмана

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

  • наличие: доля спроса, обслуженного без дефицита;
  • потери: списание в штуках и рублях по сроку годности;
  • операции: срочные допроизводства, перемещения и часы ручного планирования;
  • качество прогноза: WAPE или MAE по товару и точке, смещение вверх и вниз, доля попаданий в допустимый диапазон.

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

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

Модельная экономика пилота

Рассмотрим условную сеть из пяти точек. Себестоимость свежей продукции — 5 млн рублей в месяц, текущие списания — 7%, то есть 350 000 рублей. Пилот снижает списания до 5,5%, не ухудшая наличие. Экономия составляет 75 000 рублей в месяц.

Пусть управляющие также экономят 50 часов планирования по полной стоимости 900 рублей за час — ещё 45 000 рублей ресурса. Поддержка витрины и модели стоит 35 000 рублей в месяц. Модельный чистый эффект — 85 000 рублей. При затратах на интеграцию и пилот 680 000 рублей простой срок окупаемости равен восьми месяцам.

Это не результат María Almenara, а пример расчёта. В финансовый эффект время превращается только тогда, когда оно сокращает сверхурочные, ускоряет работу или позволяет расти без дополнительного найма. Стоимость дефицита и списаний нужно брать из учёта, а не из презентации поставщика.

Ограничения и риски

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

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

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

Что сделать за четыре недели

Первая неделя: выберите 20–40 товаров и две-три точки, сведите продажи, остатки и списания, зафиксируйте базовые метрики.

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

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

Четвёртая: примените рекомендации к ограниченной группе товаров с подтверждением человеком. Сравните наличие, списания, ручное время и стабильность интеграций.

Главный вывод кейса — начинать нужно не с выбора «самой умной» модели. Сначала единые коды, регулярные транзакции, остатки и ограничения производства; затем простой прогноз и контрольная группа. ИИ приносит пользу, когда его ответ заканчивается понятным управленческим решением, а не ещё одним графиком на совещании.