ИИ для управления запасами: как внедрить и что это даст бизнесу

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

Что такое ИИ для управления запасами и чем он отличается от ERP, WMS и формульных методов

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

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

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

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

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

Почему формулы перестают работать на широком ассортименте

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

Добавьте к этому реальные условия российского рынка. Сроки поставки из Китая гуляют на две-три недели, промо на маркетплейсе может поднять продажи в восемь раз за сутки, а поставщик внезапно меняет кратность отгрузки. Формула, настроенная один раз в Excel, не умеет учитывать эти факторы одновременно. Закупщик компенсирует её слабость ручными правками, и через год никто уже не может объяснить, почему по этой позиции стоит коэффициент 1,7.

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

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

Чем ИИ не является

Стоит сразу снять несколько ожиданий, которые мешают проектам.

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

Какие задачи закрывает ИИ

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

1. Прогноз спроса по каждой позиции и каждой точке хранения на нужный горизонт планирования.
2. Расчёт точки пополнения и объёма заказа с учётом срока поставки и его нестабильности.
3. Формирование автозаказа поставщику с проверкой кратности, минимальной партии и бюджета.
4. Распределение товара между складами и регионами, когда общий запас достаточен, а локальный дефицит есть.
5. Контроль расхождений и аномалий в остатках до того, как они превратятся в недостачу при инвентаризации.
6. Выделение сезонности, промо-эффектов и каннибализации между похожими товарами.
7. Оценка риска по поставщикам на основе истории опозданий и недопоставок.
8. Категоризация новой номенклатуры и сопоставление карточек от разных поставщиков.
9. Расчёт уценки и вывода из ассортимента для позиций, которые уже не окупают хранение.

Разберём несколько пунктов, где детали принципиально меняют результат.

Прогноз спроса на уровне позиции и склада

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

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

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

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

Качество прогноза измеряйте не процентом попадания, а взвешенной ошибкой в деньгах или штуках. Метрика WAPE показывает, какую долю фактического объёма вы не угадали, и в отличие от среднего процента ошибки не ломается на позициях с нулевыми продажами. На практике переход от среднего за три месяца к нормальной модели даёт снижение ошибки на пятнадцать-тридцать процентов по длинному хвосту, и это уже заметно отражается на оборачиваемости.

Автозаказ и точка пополнения

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

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

• Фактический срок поставки и разброс этого срока за последний год, а не срок из договора.
• Минимальная сумма или объём партии и кратность упаковки.
• Периодичность отгрузок, если поставщик работает по графику.
• Условия по скидкам за объём, которые меняют экономику решения.
• Целевой уровень доступности товара, заданный отдельно для разных групп ассортимента.

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

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

Контроль остатков и выявление аномалий

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

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

Какие технологии работают под капотом

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

Прогнозные модели на временных рядах

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

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

• Продажи за предыдущие периоды с разными окнами агрегации.
• Календарные признаки, включая день недели, праздники и предпраздничные волны.
• Признаки доступности товара, потому что ноль продаж при нулевом остатке не означает отсутствие спроса.
• Цена, скидка и позиция относительно цен конкурентов.
• Участие в акциях площадки и рекламные бюджеты.
• Атрибуты товара для расчёта по аналогам при выводе новинок.

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

ИИ-агенты с доступом к учётным системам

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

Реалистичные сценарии применения на сегодня примерно такие.

• Сбор и сверка данных из нескольких источников перед формированием заказа.
• Подготовка сводки по отклонениям за неделю с объяснением, какие позиции требуют внимания и почему.
• Разбор входящих писем от поставщиков с извлечением дат, количеств и изменений условий.
• Заполнение и проверка накладных, сопоставление позиций из документа с номенклатурой в базе.
• Ответы на вопросы руководителя по текущему состоянию запасов на естественном языке.

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

Языковые модели и их реальная польза закупщику

Чат-модели вроде YandexGPT, GigaChat или зарубежных аналогов решают задачи, где нужно понять текст или сгенерировать его. Прогнозировать спрос они не умеют и не должны, хотя попытки скормить модели таблицу продаж и попросить прогноз встречаются регулярно. Результат получается правдоподобным по форме и бессмысленным по сути, потому что модель не считает, а воспроизводит паттерн ответа.

Зато в работе с номенклатурой и регламентами они дают быстрый эффект.

• Категоризация новых позиций по описанию от поставщика с заполнением атрибутов.
• Сопоставление одного и того же товара в прайсах разных поставщиков, где названия написаны по-разному.
• Формулирование и улучшение регламентов закупок на основе ваших черновиков.
• Подготовка писем и претензий поставщикам по шаблону с конкретными данными.
• Объяснение логики расчёта новому сотруднику в отделе закупок.

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

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

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

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

Экономический эффект и расчёт ROI

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

Метрики, по которым оценивают результат

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

Показатель	Что показывает	Типичный ориентир
Оборачиваемость запаса в днях	Сколько дней в среднем товар лежит на складе до продажи	Зависит от отрасли, цель — снижение на 10–25 процентов за год
Уровень доступности товара	Доля времени или спроса, когда товар был в наличии	95–98 процентов по ходовым позициям, ниже по хвосту
Доля неликвида	Запас без продаж за выбранный период, обычно 180 или 365 дней	Сокращение на треть за первый год реалистично
Ошибка прогноза WAPE	Какую долю фактического объёма модель не угадала	Улучшение на 15–30 процентов относительно расчёта по среднему
Упущенная выручка	Продажи, которые не состоялись из-за отсутствия товара	Считается по восстановленному спросу в периоды дефицита

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

Любое улучшение по одной метрике запасов нужно проверять второй метрикой из противоположной группы. Иначе через полгода вы обнаружите, что оптимизировали отчёт, а не бизнес.

Как посчитать эффект на своих данных

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

1. Зафиксируйте текущее состояние за последние двенадцать месяцев. Средний остаток в закупочных ценах, объём продаж, доля позиций без продаж, количество дней дефицита по топовым артикулам.
2. Оцените стоимость денег в запасе. Берите реальную ставку, по которой вы привлекаете финансирование, или доходность альтернативного вложения. Для большинства компаний это от восемнадцати до двадцати пяти процентов годовых, плюс складские расходы и потери от порчи.
3. Посчитайте два сценария выгоды. Первый — высвобождение капитала при сокращении среднего остатка на пятнадцать процентов. Второй — прирост выручки при снижении дефицита по ходовым позициям вдвое.

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

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

Что показывает практика внедрений

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

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

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

Применение на маркетплейсах: Wildberries, Ozon, Яндекс Маркет

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

Чем планирование на площадках отличается от обычного

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

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

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

Как выстроить расчёт на практике

Работающая последовательность для продавца с ассортиментом от нескольких сотен позиций выглядит так.

1. Соберите данные через интерфейсы площадок. Нужны заказы по дням и складам, остатки, история цен, участие в акциях, показы и переходы в карточку.
2. Восстановите спрос в периоды отсутствия товара. Без этого шага модель выучит ваши дефициты и будет их воспроизводить.
3. Разделите ассортимент по характеру спроса и жизненному циклу. Новинки, сезонные позиции и стабильные артикулы считаются разными методами.
4. Считайте прогноз по кластерам складов, а не только суммарно по площадке.
5. Переведите прогноз в план поставок с учётом графика приёмки и лимитов на поставку по каждому складу.
6. Отдельно рассчитайте запас под акции, добавив ожидаемый коэффициент подъёма спроса по глубине скидки.
7. Контролируйте результат по доле времени в наличии и по оборачиваемости в разрезе склада, а не в среднем.

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

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

Как оценить готовность бизнеса: данные, процессы, команда

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

Проверка данных

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

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

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

Проверка процессов

Технически корректная рекомендация не превратится в экономию, если в компании нет механизма её исполнения. Задайте себе несколько неудобных вопросов.

• Кто принимает финальное решение о заказе и может ли он отклонить рекомендацию без объяснения причины.
• Есть ли утверждённый целевой уровень доступности товара по группам ассортимента или он существует только в голове руководителя.
• Как компания принимает решение о выводе позиции из ассортимента и кто отвечает за уценку неликвида.
• Согласован ли бюджет закупок с планом продаж или он определяется по остатку денег на счёте.
• Как промо-акции попадают в план закупок и за сколько недель до старта.

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

Проверка команды

Нужный минимум скромнее, чем принято считать. Своя команда разработчиков не требуется, если вы берёте готовое решение. Требуется другое.

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

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

Пошаговое внедрение ИИ в управление запасами

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

1. Диагностика данных и процессов по чек-листам выше. Срок от одной до трёх недель, результат — перечень ограничений и оценка потенциальной выгоды.
2. Подготовка данных. Очистка номенклатуры, восстановление истории остатков, разметка промо. Срок от двух до шести недель в зависимости от состояния учёта.
3. Расчёт базовой линии. Считаете, какую ошибку даёт ваш текущий метод планирования на исторических данных. Без этого числа невозможно доказать улучшение.
4. Пилот на ограниченной выборке. Прогноз и рекомендации по заказу работают параллельно с действующим процессом, решения пока принимает человек.
5. Сравнение результатов и настройка. Разбор позиций с худшим прогнозом, добавление признаков, корректировка параметров уровня сервиса.
6. Интеграция с учётной системой. Рекомендации попадают в привычный интерфейс закупщика, а не в отдельный файл, который надо открывать вручную.
7. Расширение на остальной ассортимент группами, начиная с категорий, похожих на пилотную.
8. Перевод части позиций в автоматический режим и настройка контроля исключений.

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

Интеграция с 1С, ERP и WMS

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

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

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

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

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

Пилот: сроки, выборка, критерии успеха

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

Параметры, которые фиксируют до старта.

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

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

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

Ошибки при внедрении и как их избежать

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

1. Старт с выбора алгоритма вместо диагностики данных. Компания обсуждает нейросети и градиентный бустинг, пока в номенклатуре живут три карточки одного товара и остатки расходятся с фактом на десять процентов.
2. Прогноз без учёта дефицита. История продаж принимается за историю спроса, модель занижает потребность, дефицит закрепляется и воспроизводится из месяца в месяц.
3. Единый уровень доступности для всего ассортимента. Попытка держать девяносто восемь процентов по длинному хвосту раздувает запас сильнее, чем всё остальное планирование его сокращает.
4. Полная автоматизация с первого дня. Автозаказ включают сразу на весь ассортимент, после первой же крупной ошибки доверие теряется, и систему отключают целиком вместо разбора конкретного случая.
5. Рекомендации в отдельном файле. Закупщик должен переносить цифры руками, и через три недели он перестаёт это делать.
6. Отсутствие базовой линии. Эффект невозможно доказать, обсуждение результата превращается в обмен впечатлениями.
7. Игнорирование плана промо. Модель не знает о предстоящей акции и выдаёт прогноз по обычному режиму продаж.
8. Прогноз есть, а бюджета закупок нет. Система рекомендует заказать на двадцать миллионов, доступно восемь, и никто не определил, какие позиции важнее.
9. Закупщиков не вовлекли. Люди воспринимают систему как оценку своей работы и находят способы доказать её бесполезность.
10. Попытка решить всё языковой моделью. Расчёт запаса отдают чат-модели, получают правдоподобные цифры без математической основы.

Как снизить риск каждой из них

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

• Выделите первый этап проекта на данные и защитите его от сокращения, даже если он выглядит как трата времени без результата.
• Разделите ассортимент на три-четыре группы по вкладу в выручку и задайте для каждой свой целевой уровень доступности, зафиксировав это письменно.
• Включайте автоматический режим постепенно, начиная с позиций со стабильным спросом и коротким сроком поставки.
• Заложите в бюджет проекта доработку интерфейса закупщика, а не только расчётное ядро.
• Введите правило, по которому акции попадают в план закупок не позже чем за один срок поставки до старта.
• Определите логику приоритизации заказов при нехватке бюджета заранее, в спокойной обстановке.
• Соберите закупщиков до начала пилота и объясните, какие задачи с них снимаются и какие добавляются.

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

Система, которой закупщик не доверяет, не даёт эффекта, даже если её прогноз точнее. Доверие строится на прозрачности расчёта, а не на точности метрики в отчёте.

Безопасность данных и контроль решений ИИ

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

Что проверить при работе с внешними сервисами

Главный риск возникает в бытовом использовании чат-моделей. Сотрудник копирует выгрузку с ценами и объёмами в публичный сервис, чтобы быстро получить сводку. Данные уходят на сторону, и в части сервисов могут использоваться для обучения. Это не гипотетическая угроза, а ежедневная практика в компаниях без регламента.

Минимальный набор требований выглядит так.

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

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

Контроль решений и защита от тихой деградации

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

Защита строится на регулярном контроле по нескольким правилам.

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

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

Как выбрать решение: готовый сервис, модуль к ERP или своя разработка

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

Критерий	Готовый сервис	Модуль к учётной системе	Своя разработка
Срок до первого результата	От двух недель до двух месяцев	От одного до трёх месяцев	От шести месяцев
Стоимость входа	Низкая, оплата по подписке	Средняя, лицензия и настройка	Высокая, зарплаты команды
Гибкость под процессы	Ограниченная логикой сервиса	Средняя, настраивается в конфигурации	Полная
Требования к команде	Один ответственный от бизнеса	Специалист по учётной системе	Аналитик данных, разработчик, инженер данных
Зависимость от поставщика	Высокая	Средняя	Отсутствует, но есть зависимость от сотрудников
Кому подходит	Ассортимент до нескольких тысяч позиций, торговля на площадках	Компании с выстроенным учётом в 1С и типовыми процессами	Крупная розница и дистрибуция со специфичной логикой

Как принять решение практически

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

Своя разработка оправдана в трёх случаях.

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

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

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

Тренды ИИ в управлении запасами

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

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

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

Частые вопросы

Сколько стоит ИИ-система для управления запасами

Разброс велик, и ориентироваться стоит на три диапазона. Готовые сервисы по подписке для продавцов на маркетплейсах и небольшой розницы обходятся от нескольких тысяч до нескольких десятков тысяч рублей в месяц в зависимости от количества позиций. Модуль к учётной системе с настройкой под процессы компании стоит от нескольких сотен тысяч до двух-трёх миллионов рублей единовременно плюс поддержка. Собственная разработка начинается от команды из двух-трёх человек, то есть от нескольких миллионов рублей в год на фонд оплаты труда, и к этому добавляется инфраструктура.

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

Насколько ИИ точнее человека в прогнозе спроса

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

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

Подойдёт ли ИИ небольшому магазину или ИП

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

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

Нужна ли своя ИТ-команда

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

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

Заменит ли ИИ менеджера по запасам

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

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

На практике сокращение штата закупщиков после внедрения происходит редко. Чаще при росте ассортимента в два-три раза отдел остаётся в том же составе, и именно в этом состоит экономический эффект на стороне людей.

Работает ли ИИ с датчиками и оборудованием склада

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

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

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