Задача: не замораживать деньги и не терять продажи
Типовой профиль заказчика — дистрибьютор или логистический оператор: несколько складов, от пяти до двадцати тысяч активных SKU, продажи в 1С, остатки в WMS, закупки — в Excel-плане, который обновляет один опытный специалист. Последствия знакомы всем: по одной группе позиций деньги заморожены в неликвидах, по другой — постоянный дефицит и упущенные заказы. Задача звучит так: прогнозировать спрос по связке «товар — склад — неделя» и превращать прогноз в готовый план закупок с объяснением каждого числа.
Важная деталь: заказчику нужен не «прогноз ради прогноза», а действие — черновик заказа поставщику, который закупщик проверяет и корректирует за минуты, а не считает вручную часами.
Почему это сложно
Первая причина — данные рассыпаны: продажи в 1С, движения в WMS, промо-план у маркетологов, календарь сезонности в голове категорийного менеджера; пока всё это не сведено, любая модель считает мусор. Вторая — иерархия прогнозов: сумма прогнозов по складам должна сходиться к прогнозу по товару, а не «гулять»; без специальных методов (иерархическое согласование) суммы расходятся на десятки процентов. Третья — промо и разовые события ломают историю: модель, не знающая о прошедшей акции, «наследует» всплеск в будущий прогноз. Четвёртая — доверие закупщиков: чёрный ящик не используют; прогноз обязан объяснять, из чего сложился, и честно показывать интервал неопределённости.
Архитектура: от данных к черновику заказа
Архитектура контура прогноза спроса (текстовая схема)
1С (продажи, закупки) + WMS (остатки, движения) + промо-календарь
│ консолидация, чистка возвратов/брака, восстановление пропусков
▼
Хранилище признаков: SKU — склад — неделя
сезонность · тренд · промо-флаги · праздники · цепочки поставки
▼
ML-ядро: градиентный бустинг на признаках (базовый прогноз)
+ иерархическое согласование SKU→категория→склад
выход: точечный прогноз + доверительный интервал
▼
LLM-слой (FastAPI-оркестрация):
разбор аномалий («почему всплеск?»), сводка для категорийного,
черновик заказа поставщику в строгом JSON → выгрузка в 1С
▼
BI-дашборд (АХРОМА): факт/прогноз/отклонение · точность по группам
▼
Обратная связь: ошибки недели ──► переобучение по расписанию
ML-ядро здесь — классические модели на признаках, а не LLM: табличные задачи прогнозирования градиентный бустинг решает надёжнее и дешевле. Роль ИИ-слоя другая — объяснять и готовить действие: свести аномалию недели с промо-календарём и погодой в короткую сводку, собрать черновик заказа со страховочным запасом. Оркестрация таких сервисов строится по паттернам FastAPI-оркестрации ИИ-сервисов, а наглядная часть живёт в BI-инструменте — наш типовой выбор описан в обзоре «BI АХРОМА: аналитика с ИИ». Черновики заказов передаются в 1С — паттерны интеграции показаны в кейсе «GigaChat в 1С-процессе».
Этапы внедрения
| Этап | Что получается | Бюджет | Срок |
|---|---|---|---|
| Аудит данных и процессов закупок | карта источников, качество истории, метрика базовой линии (как прогнозируют сейчас) | от 90 000 ₽ | 1–2 недели |
| Пилот на категории товаров | прогноз и черновики заказов по 1–2 категориям, сравнение с базовой линией на бэктесте | от 480 000 ₽ | 4–6 недель |
| Промышленный контур | все категории и склады, расписание переобучений, дашборды, роли | 0,9–1,2 млн ₽ | по ТЗ |
| Сопровождение | контроль деградации точности, новые признаки, доработка под ассортимент | по регламенту | — |
Бюджеты — прайс НЬЮ-ССТ на сентябрь 2026, «от», без НДС (УСН, п. 2 ст. 346.11 НК РФ). Сроки — типовые вилки проектов этого класса.
Типовые метрики «до/после»
Ниже — типовые вилки результатов внедрений прогнозирования этого класса. Базовая линия замеряется до старта: как прогнозирует текущий процесс (Excel, опыт закупщика, «как в прошлом месяце»); улучшение считается против неё на бэктесте и первые живые недели.
- Точность прогноза (WAPE): типовое улучшение на 15–30 процентильных пунктов против наивного прогноза; по стабильным позициям — больше, по промо-зависимым — меньше.
- Неликвидные запасы: −20–40% оборачиваемых денег из мёртвых позиций за счёт отказа от перестраховочных закупок.
- Дефицит ходовых позиций: −25–50% упущенных продаж по причинам «не успели закупить».
- Время планирования закупок: −50–80% — от ручной сборки плана к проверке черновика.
- Оборачиваемость запасов: +10–25% — деньги высвобождаются без потери уровня сервиса.
Безопасность и контур данных
Данные о продажах и закупках — коммерческая тайна, поэтому типовой контур разворачивается on-premise или в закрытом контуре заказчика; внешние LLM API для сводок не используются, LLM-слой работает на локальных моделях — обзор вариантов в «Ollama: локальный LLM». Если в срезах фигурируют персональные данные (например, менеджеры по продажам) — эти поля обезличиваются до попадания в хранилище признаков по 152-ФЗ. Сама модель прогноза со временем становится ИИ-активом: её признаки, веса и пайплайн — предмет инвентаризации по 243-ФЗ.
Об этом разборе. Это обезличенное типовое внедрение из нашей практики проектирования: без имён заказчиков (NDA) и без выдуманных цифр — метрики даны типовыми вилками класса, фактические значения фиксируются в КП на бэктесте и приёмке.