Искусственный интеллект развивается стремительно: пишет код, собирает аналитику, запускает агентов выполнять задачи, которые ещё недавно требовали целой команды. На этом фоне закономерно появляется мысль: если ИИ настолько умён, зачем вообще покупать готовую систему управления запасами — может, он и напишет её сам?
Мысль понятная, и просто отмахнуться от неё было бы нечестно. Давайте разберёмся всерьёз: где идея написать систему самому действительно работает, а где оборачивается дорогой ошибкой. Главный ответ зависит от масштаба — и ниже мы покажем, почему.
Где ИИ может быть полезен уже сейчас
Часть задач по управлению запасами вполне реально закрыть своими силами уже сейчас.
Если ассортимент небольшой — 200–500, пусть даже до тысячи позиций, — а процессы простые и некритичные, базовую автоматизацию можно собрать самостоятельно. Тем более что ИИ хорошо снимает рутину закупщика:
- собрать данные по рынку и отрасли в режиме глубокого поиска;
- написать скрипт вместо ручных связок из десятка таблиц;
- разобрать коммерческие предложения и подсветить проблемные места;
- подготовить письма поставщикам после переговоров;
- собрать дашборд под конкретный запрос;
- привести данные к единому формату;
- подсказать формулу или логику расчёта.
Это особенно полезно, когда задача локальная и результат можно быстро проверить: выгрузили файл, обработали, сравнили с ожиданиями, поправили.
Со всем этим ИИ справляется быстро и реально экономит время. Если раньше на подготовку небольшой автоматизации уходило несколько дней, то теперь часть таких задач можно решить быстрее. Особенно если у сотрудника уже есть базовое понимание данных, Excel, Python, Power Query или других инструментов.
Как помощник на таких задачах он отличный, и не пользоваться им сегодня - значит упускать конкурентное преимущество.
Но всё это работает, пока процессы простые, а цена ошибки невелика. Как только система становится масштабной и критичной для бизнеса, правила меняются. И первое, обо что спотыкается идея написать систему самому, — это представление о том, что вообще такое система управления запасами.
Система управления запасами — это далеко не только прогноз
Для многих система управления запасами — это в первую очередь прогноз спроса. Спрогнозировали продажи поточнее — и дело сделано. Отсюда и берётся ощущение, что вся задача сводится к одной модели.
На деле прогноз — лишь часть задачи, и далеко не самая сложная. Нормальная система решает целый набор связанных между собой задач:
- расчёт заказов: сколько именно заказать по каждой позиции;
- планирование поставок с учётом сроков и плеч поставки;
- расчёт оптимальных товарных запасов и страхового запаса;
- учёт кратности и квантов поставки, минимальных партий, бюджетов, вместимости транспорта;
- распределение запасов между складами и торговыми точками;
- учёт сроков годности, акций, сезонности и десятков других ограничений.
И всё это завязано друг на друга. Можно идеально спрогнозировать спрос и всё равно заказать неверно — потому что не учли кратность поставки, плечо или остаток на складе к дате прихода. Прогноз отвечает на вопрос, сколько примерно купят. А бизнесу нужен ответ на вопрос, сколько, когда и куда заказать, чтобы заработать. Это разные вопросы, и второй заметно сложнее.
Поэтому свести всю систему к одной модели не выходит. И именно здесь масштаб начинает играть решающую роль.
Где проходит граница
Граница не там, где ИИ стал умнее. Она — в масштабе и в цене ошибки.
Одно дело — автоматизировать пару процессов на тысяче позиций. Другое — система для крупной компании: десятки тысяч SKU, несколько складов, запасы на сотни миллионов рублей и решения, от которых напрямую зависят деньги. Это уже промышленная автоматизация с совсем другими требованиями: отраслевая экспертиза, контроль качества данных, безопасность, производительность на больших объёмах, устойчивость и объяснимость расчётов.
И здесь принципиально, где именно живёт расчёт. Решения о том, сколько заказать, когда это сделать, какой держать страховой запас и как распределить товар по складам, — это и есть точка, где компания зарабатывает или теряет деньги.
Ошибётесь в одну сторону — получите перезатаривание: деньги, замороженные в излишках, неликвиды, списания. Ошибётесь в другую — дефицит: упущенные продажи, падение уровня сервиса, недовольные клиенты. На тысяче позиций такую ошибку ещё можно поймать вручную. На десятках тысяч — уже нет, и цена каждой систематической ошибки умножается на весь ассортимент.
Поэтому критичные расчёты обязаны жить в надёжном, проверенном и объяснимом ядре — там, где видно, откуда взялось каждое число, и где результат можно повторить и перепроверить. Отдать эту логику наспех собранному ИИ-коду, который вы не в состоянии проверить, — значит сознательно заложить риск туда, где он стоит дороже всего.
Что именно ломается на масштабе
Допустим, компания всё же решает написать промышленную систему с помощью ИИ. На что она наткнётся?
Прототип и рабочая система — это две очень разные вещи. Собрать демо-версию, которая считает заказ на сотне позиций и красиво показывает результат, ИИ поможет за вечер. Но между таким прототипом и системой, которой можно доверить реальные заказы на десятки тысяч SKU, лежат месяцы, а может и годы работы. Система должна держать нагрузку, корректно работать на грязных и неполных данных, не падать на нестандартных случаях, восстанавливаться после сбоев и выдавать стабильный результат раз за разом. Собранный прототип ничего этого не умеет — он лишь показывает, что в принципе так можно. Расстояние от «в принципе можно» до «работает в продакшене каждый день» огромное, и ИИ его не сокращает.
Разработку вокруг ИИ нужно уметь выстраивать. Когда вы поручаете задачу ИИ, вы контролируете результат, но не процесс. В случае с кодом это значит, что у вас есть два варианта. Первый — положиться на код через принятие тестов и конечного результата. Но здесь вы сталкиваетесь с риском доверия «черному ящику». Второй вариант — ревью написанного кода. Но такая ревизия чужого, тем более машинного, кода — медленная и выматывающая работа, которая часто съедает всё то ускорение, ради которого ИИ и звали. Чтобы вести такую разработку всерьёз, нужны архитектура, тесты, непрерывная интеграция, мониторинг, оценка рисков — по опыту, всего этого требуется в разы больше, чем при обычной работе людей. И заниматься этим должны сильные инженеры, а они дорогие. Дешёвой такая разработка не бывает.
ИИ-агенты ведут себя непредсказуемо. Они умеют обходить ограничения и скрывать собственные ошибки. Это не страшилка, а наблюдаемое поведение. Реальный случай: антивирус заблокировал и удалил программу, с которой работал агент. Агент решил восстановить её сам — нашёл на дисках копию другой версии, подложил исполняемый файл, начал на ходу подгонять библиотеки и в попытке всё исправить едва не вывел систему из строя. Чем больше у агента доступа, тем выше цена такого поведения — поэтому в промышленной разработке безопасность идёт первым пунктом, а не последним.
Зависимость от одного человека — знакомая ловушка Excel в новой обёртке. Все видели, как это бывает: есть толковый сотрудник, который ведёт всё в своих таблицах, а когда он уходит, разобраться в них не может никто. С ИИ выходит то же самое, только хуже. Сегодня сильный сотрудник собрал на ИИ набор инструментов и расчётов, завтра он ушёл — и компания осталась с системой, логику которой никто не понимает и не может поддерживать. Знания снова заперты в одном человеке, а бизнес зависит от того, останется он или нет. Но справедливости ради стоит заметить, что этот риск можно в определенной степени нивелировать — просить ИИ объяснять что и как происходит, а также заранее планировать разработку с более высоким уровнем организации.
Прогноз ИИ-моделями — отдельная сложная тема. Тут важно понимать две вещи. Большие языковые модели вроде ChatGPT или Claude в принципе не созданы для прогнозирования: они работают с текстом, а не с временными рядами, и просить их предсказывать спрос бессмысленно. Есть и специализированные модели прогноза,. Но и они задачу не решают: это закрытый по логике инструмент, который часто заметно хуже работает на прерывистом и промышленном спросе. Мы, например тестировали модель трансформер Chronos от Amazon на реальных данных и сравнивали его с вероятностным ядром. Последнее выдавало заметно более качественные результаты.
Подробнее о прогнозных моделях мы рассказываем в статье “Что умеет ИИ в прогнозировании — и чего нет”
Получается, идея написать промышленную систему на ИИ упирается не в одну стену, а сразу в несколько: экспертиза, данные, безопасность, поддержка и сам прогноз.
Рабочий путь: сильное ядро и ИИ-контур
Разумнее не противопоставлять ИИ и систему, а соединять их. Вопрос не в том, заменить ли систему искусственным интеллектом, а в том, как усилить надёжное ядро его возможностями.
Удобно представить такую систему как матрёшку из трёх слоёв.
В центре — расчётное ядро. Это сложные расчёты, моделирование и подневная симуляция всей цепочки поставок: спрос, запасы, заказы, распределение по складам. Здесь живёт самая критичная логика, и здесь нужна экспертиза, наработанная годами. Например, в системе Forecast NOW! под капотом ядра — вероятностный подход: система прогнозирует не одно число, а распределение вероятностей, проигрывает тысячи вариантов будущего, оценивает стоимость каждого сценария и выбирает решение, оптимальное по деньгам. Такой расчёт прозрачен — видно, откуда взялось каждое число, в отличие от закрытой логики нейросети.
По сути, зрелая система должна уметь моделировать поведение цепочки поставок до принятия решения: проверять разные сценарии, учитывать ограничения и показывать, как изменения спроса или поставок повлияют на запасы.
Вокруг ядра — ИИ-слой. Он не считает заказы вместо ядра, а помогает людям с ним работать и ускоряет внедрение. Это та часть, которую ИИ берёт на себя без риска для критичных решений: проверка и контроль качества данных, помощь с настройкой под конкретный бизнес, объяснение результатов расчёта понятным языком, подсветка аномалий. Смысл — снизить порог входа и убрать рутину, не трогая математику, на которой держатся деньги.
Снаружи — экосистема: интеграции с системами клиента, внешние ассистенты, доступ к данным.
Принцип во всём один. Критичный узел остаётся в ядре, потому что цена ошибки в нём слишком высока. А ИИ навешивается сверху как помощник: он может пользоваться ядром как инструментом, но не подменяет его.
Как мы к этому пришли
Forecast NOW! разрабатывается уже 15 лет, и начинали мы в том числе с нейросетей — а затем осознанно отказались от них в прогнозировании в пользу прозрачного вероятностного подхода. Почитать об это можно в статье “Почемы мы перешли от нейросетей к вероятностному прогнозированию”.
За эти годы мы пришли к простому убеждению. В основе системы должно лежать сильное математическое ядро: понятное человеку, аккуратно считающее и, главное, проверяемое — такое, где можно открыть расчёт, увидеть, откуда взялось число, и убедиться, что оно верное. Без этого всё остальное не имеет смысла.
Но и это ядро стоит усиливать инструментами, которые помогают людям работать с ним быстрее и проще. Поэтому ИИ-слой мы развиваем вокруг ядра, а не вместо него. Покажем на конкретных примерах того, что у нас уже есть. У нас работает бот техподдержки, который отвечает на вопросы по продукту на основе базы знаний. Мы тестируем помощника, который проверяет качество загруженных данных и подсказывает, что с ними не так. И помощника по настройке, который подбирает параметры под конкретный бизнес: где включить учёт сезонности, где отфильтровать аномальные выбросы, где учесть сроки годности. Всё это ускоряет внедрение и снижает порог входа — а критичные расчёты при этом остаются в ядре.
Что в итоге
Не стоит загонять себя в ложный выбор: писать самому или покупать, по-простому или по-промышленному. И то, и другое — части одного ответа.
Самый сильный вариант — зрелое промышленное расчётное ядро в связке с ИИ-слоем. Ядро даёт надёжность, экспертизу и объяснимость и держит критичные расчёты там, где цена ошибки под контролем. ИИ добавляет скорость, удобство и низкий порог входа. Вопрос не в том, ИИ или система, а в том, как взять лучшее от обоих.
Если у вас простые и некритичные задачи на небольшом ассортименте — да, кое-что можно собрать и самому. Но на серьёзном масштабе выигрывает именно связка ядра и ИИ, а не ИИ сам по себе. Так устроен и наш подход в Forecast NOW!
Если вы сравниваете несколько SCM- или УТЗ-решений, отдельно проверяйте, где в системе находится критичная логика расчета, какую роль играет ИИ, насколько прозрачно объясняются рекомендации и можно ли проверить работу решения на ваших сценариях. Подробнее об этом читайте в статье "9 рекомендаций, как сранить между собой несколько систем управления запасами"
