Почему сделать свою систему автозаказа с помощью ИИ сложнее, чем кажется?

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

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

Но между «ИИ быстро пишет код и настраивает серверы» и «у нас работает своя система автозаказа» — огромная пропасть. Систему мало сделать: кто-то должен решать, как она устроена, проверять её работу и годами отвечать за то, как она обновляется, чинится и стыкуется с другими программами компании. Ниже разбираем по пунктам, что ИИ ускоряет, что остаётся как было, какая команда нужна и из чего складываются затраты.

Что ИИ изменил, а что — нет?

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

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

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

Команда DORA из Google Cloud в отчёте «State of AI-assisted Software Development 2025»¹ по опросу почти 5 000 специалистов сформулировала это так:

ИИ не чинит команду, он усиливает то, что в ней уже есть.

DORA, State of AI-assisted Software Development 2025

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

Рис. 1. Экономика разработки с ИИ: сделать стало быстрее, а решать, проверять и отвечать — нет. Схема условная.

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

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

Почему прототип за две недели — ещё не система?

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

На практике это и есть ловушка. Аналитика только читает данные и показывает картинку. Если в графике ошибка, её видно, и она ничего не стоит: перестроили отчёт и пошли дальше. Работает такой прототип на компьютере разработчика, запускается вручную и никому не мешает, если однажды не запустился.

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

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

Рис. 2. Прототип и рабочая система: то, что видно сразу, и то, что приходится строить и поддерживать.

При этом там, где ошибка не бьёт по деньгам компании, ИИ правда позволяет многое сделать своими силами: дашборды, разовые расчёты, автоматизацию рутины на небольшом ассортименте. Об этом мы подробно писали в статье «Можно ли написать систему управления запасами с помощью ИИ?». Здесь же речь о системе, которой компания доверяет свои закупки.

Что придётся построить?

Система автозаказа — это не «нейросеть, которая предсказывает продажи». Это замкнутый контур:

данные и их очистка → расчёт заказа → проверки и согласование → заказ в учётной системе → поставка → фактический результат → контроль → изменение настроек.

Рис. 3. Контур системы автозаказа. Расчёт заказа — один шаг из восьми.

И каждый элемент этого контура должен где-то работать, связываться с соседними, переживать сбои и обновляться.

Ещё в 2015 году инженеры Google в работе «Hidden Technical Debt in Machine Learning Systems»² (Sculley и соавторы, конференция NeurIPS) показали: в реальных системах машинного обучения код самой модели занимает малую часть, а окружающая его инфраструктура «огромна и сложна».

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

20 вещей, о которых не думают на старте

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

Что придётся сделать, кроме кода?

1. Архитектура на годы

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

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

2. Логика автозаказа — отдельная экспертиза

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

• дефицит прячет спрос: товар закончился в обед, в данных — половина обычных продаж, система решает, что товар нужен меньше, и в следующий раз заказывает ещё меньше;
• плечо поставки — не константа: поставщик везёт то за 30 дней, то за 50, и считать нужно разброс, а не договорной срок;
• расчёт даёт 37 штук, а заказать можно только 0 или 48, и выбор между ними — экономическое решение;
• заказ поставщику собирается целиком: минимальная сумма, полная машина или паллета, график поставок, бюджет закупок, место на складе;
• для товаров с редким спросом средний спрос в 0,3 штуки в день мало что даёт — важна вероятность продать одну, две, три штуки до следующей поставки;
• промо, новинки, замена артикулов, выкладка на полке, сроки годности — у каждого свой механизм;
• уровень наличия — экономическое решение по каждому товару, а не один процент на весь ассортимент.

Хороший расчёт учитывает всё это одновременно, а не по шагам «сначала прогноз, потом заказ». Подробнее — в статьях «Почему нужно сразу моделировать заказ, а не прогнозировать отдельно спрос и запас» и «Точность прогнозирования или прибыль? Что нужно измерять?». Эту логику ИИ за вас не придумает. Её должны сформулировать люди, которые сами годами занимались закупками, прогнозированием и автозаказом.

3. Интеграции

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

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

4. Данные — постоянная работа, а не разовая чистка

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

5. Тестирование

Автоматические тесты проверяют, что программа считает так, как задумал разработчик, на заранее подготовленных примерах. Но они не проверяют, верен ли сам замысел и совпадают ли данные с реальностью. Если в карточке товара в коробке 24 рубашки, а приходит 12, тест не поможет. Именно так было у Target, когда сеть открывала магазины в Канаде, — об этом писало агентство Reuters в материале «Target Canada's supply chain gridlock: how Barbie SUVs snarled traffic»³ (2014): расчёт работал правильно, но данные о товарах были неверными.

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

6. Проверка того, что сделал ИИ

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

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

У этого подхода есть и обратная сторона. Если код никто не читает, никто и не знает, как система устроена внутри. Пока проверки проходят, это не мешает. Но когда что-то сломается, разбираться придётся в коде, который видят впервые, — об этом подробнее в пунктах 17 и 18. В отчётах DORA доля разработчиков, которые мало или совсем не доверяют коду от ИИ, — 39% в 2024 году и 30% в 2025-м.

Всё это — время сильных специалистов, то есть ровно то, на чём компания рассчитывала сэкономить.

7. Производительность и ресурсы

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

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

8. Рабочее место закупщика

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

Кто будет держать систему в рабочем состоянии?

9. Инфраструктура

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

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

10. Отказоустойчивость и восстановление

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

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

11. Мониторинг и дежурства

Данные загружаются в пять утра, расчёт должен закончиться к восьми, а заказ — уйти поставщику до часа, после которого тот уже не принимает заказы на ближайшую поставку. Если сбой случился в субботу в шесть утра, кто об этом узнает и кто починит? ИИ может разобрать журналы работы системы и подсказать причину сбоя. Время разбора он сокращает, но дежурство не отменяет: кто-то всё равно должен проверить его вывод и принять решение. А правила на такой случай — когда остановить расчёт, когда заказать по запасному правилу — придумывают заранее, а не в шесть утра.

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

Следить нужно и за бизнес-показателями. Предположим, после обновления система начала незаметно завышать запас на 3%. Технически всё в порядке, а деньги уходят. Поэтому нужен контроль наличия, излишков, оборачиваемости и доли ручных правок. А дежурства — это график и доплаты. Вдвоём такую нагрузку долго не выдержать, а с одним человеком отпуск или болезнь оставляют систему без присмотра.

12. Техподдержка пользователей

Закупщики каждый день задают вопросы: почему заказали столько, почему не заказали этот товар, как изменить настройку. Чтобы ответить на вопрос «почему вчера заказали 12 600 штук?», нужен журнал решений: какие были данные, какие ограничения сработали, кто и что поправил вручную. Если его не заложили с самого начала, ответ восстановить будет не из чего.

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

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

Без поддержки — человеческой или с помощью ИИ — люди либо принимают заказы не глядя, либо переделывают их по-своему, и в обоих случаях польза от автоматизации пропадает. Подробнее об этом — в статье «Почему не внедряется система управления запасами? Человеческий фактор».

13. Регулярные обновления

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

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

14. Безопасность

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

ИИ свободно подключает к коду готовые программные компоненты, и среди них может оказаться устаревший или уязвимый. Бывает и хуже: модель предлагает компонент, которого не существует. В исследовании «We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs»⁴ (Spracklen и соавторы, USENIX Security, 2025) коммерческие модели в среднем выдумывали не меньше 5% таких компонентов. Злоумышленники пользуются этим: регистрируют пакеты с придуманными моделями названиями и кладут в них вредоносный код. Поэтому, раз код никто не читает построчно, нужны автоматические проверки того, какие компоненты ИИ подключил к системе (см. пункт 6). А данные о продажах, закупках и поставщиках — коммерческая тайна, и если в них есть сведения о покупателях, к этому добавляются требования закона о персональных данных.

15. Зависимость от внешних сервисов

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

Кто будет делать систему и отвечать за неё?

16. Найм

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

17. Зависимость от конкретных людей

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

18. Технический долг

Так разработчики называют накопленные упрощения в коде. Код, написанный быстро, через год дорого менять: никто уже не помнит, почему он устроен именно так, и каждая правка ломает что-то в другом месте. В уже упомянутой работе инженеров Google «Hidden Technical Debt in Machine Learning Systems»² прямо сказано, что быстрый выигрыш в таких системах оборачивается постоянными затратами на сопровождение.

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

19. Развитие вместе с бизнесом

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

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

20. Внедрение и обкатка

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

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

Какая команда нужна?

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

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

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

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

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

Для ритейлеров и дистрибьюторов, у которых разработка программ — не основной бизнес, такой проект особенно рискованный. Если в компании нет сильной команды разработки, ИИ не заменит архитектора, тестирование и эксплуатацию. А без глубокой экспертизы в автозаказе у проекта нет основы: ИИ быстро напишет код по неверной логике, и вы узнаете об этом через пару сезонов по состоянию склада.

Из чего складываются затраты?

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

Сложность проекта и сроки. Размер проекта определяет не число товаров и не численность компании, а то, насколько сложно устроены её закупки. Крупная производственная компания на несколько тысяч сотрудников может закупать всего 500 позиций у пяти поставщиков. А небольшая сеть может работать с десятками поставщиков, несколькими складами и маркетплейсами. От ассортимента зависит в основном то, как быстро должен идти расчёт (пункт 7), а команду и сроки определяет сложность процессов.

Ориентир по нашей оценке:

Стоимость одного специалиста. По отчёту Хабр Карьеры «Зарплаты IT-специалистов в первой половине 2026 года»⁵, медианная зарплата бэкенд-разработчика (того, кто пишет расчётную и серверную часть системы) на руки — 278 тыс. ₽ в месяц в Москве, 251 тыс. в Петербурге и 220 тыс. в регионах. Сильные специалисты уровня senior, без которых такую систему не построить, получают больше: по калькулятору⁶ того же сервиса — около 340 тыс. ₽ по России и 380 тыс. в Москве.

Для компании это дороже. Сверху — НДФЛ по прогрессивной шкале⁷ и страховые взносы: 30% в пределах предельной базы⁸ 2 979 000 ₽ в год и 15,1% сверх неё. Льготные IT-тарифы ритейлеру, который пишет программу для себя, не положены.

В итоге разработчик с медианной зарплатой обходится компании примерно в 330 тыс. ₽ в месяц в регионах и в 410 тыс. в Москве, сильный специалист — 490–550 тыс. ₽. Это без рабочего места, техники, лицензий и времени руководителей.

Пример расчёта для небольшого проекта — например, дистрибьютора с одним складом и ежемесячными заказами. Допустим, команда из 7 человек со средней стоимостью 420 тыс. ₽ в месяц — например, трое сильных специалистов и четверо с медианной зарплатой — работает 8 месяцев до запуска. Только затраты на команду до запуска — около 24 млн ₽. В пределах оценок из таблицы эта сумма колеблется примерно от 12 до 50 млн ₽, причём 12 млн — оптимистичный край: он предполагает небольшую команду с медианными зарплатами, а специалисты по прогнозированию и расчёту заказа обычно дороже.

После запуска команда не распускается. Эту статью затрат при планировании легче всего упустить. Почти всё, о чём говорилось в 20 пунктах, продолжается и после запуска: интеграции нужно сопровождать, данные — чистить, сбои — разбирать, обновления — выпускать, пользователей — поддерживать, расчёт — дорабатывать под новый ассортимент. Допустим, после запуска остаются 4 человека — и это нижняя граница. Доработки и разбор сбоев с ИИ идут быстрее, но эти люди нужны не ради объёма работы, а ради дежурств (пункт 11), знания системы и ответственности за неё. Это ещё около 20 млн ₽ в год. За 5 лет только затраты на команду составят порядка 110 млн ₽ — и это для небольшого проекта и без учёта роста зарплат, поэтому реальная сумма будет выше.

Рис. 4. Затраты на команду за 5 лет в примере для небольшого проекта: один человек обходится компании в 420 тыс. ₽ в месяц с налогами и взносами. Серверы, лицензии, найм и потери обкатки — сверху.

Сравнивать эти деньги стоит с ожидаемым эффектом: насколько снизятся излишки и дефицит. Оценить его заранее можно на своих данных — об этом ниже.

Что ещё нужно заложить:

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

Bent Flyvbjerg и Alexander Budzier в исследовании «Why Your IT Project Might Be Riskier Than You Think»⁹ (Harvard Business Review, 2011) изучили 1 471 IT-проект. Средний перерасход бюджета составил 27%. Хуже другое: каждый шестой проект обернулся катастрофой — перерасход бюджета в среднем составил 200%, сроков — почти 70%.

McKinsey вместе с Оксфордским университетом в исследовании «Delivering large-scale IT projects on time, on budget, and on value»¹⁰ (2012) по более чем 5 400 проектам получила похожую картину: крупные IT-проекты в среднем на 45% дороже плана, на 7% дольше и приносят на 56% меньше ценности, чем ожидалось. Это не ИИ-проекты, но риск устроен так же: средний перерасход заметный, а отдельные проекты обходятся в разы дороже плана.

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

А что остаётся на компании, если купить готовую систему?

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

Готовая система снимает другое — ту часть, которая не зависит от конкретной компании: логику расчёта, отработанную на многих клиентах, рабочее место закупщика, развитие продукта, регулярные обновления и исправление ошибок, техническую поддержку, проверенные интеграции с типовыми учётными системами. Эту часть уже оплатили вместе многие клиенты. Поэтому и сроки другие: например, внедрение Forecast NOW! обычно занимает от 3 до 9 месяцев.

Зависимость от поставщика при покупке тоже есть. Разница в том, что её можно оценить заранее: где хранятся данные, можно ли их выгрузить, как устроена поддержка, что прописано в договоре. Например, Forecast NOW! устанавливается на сервер клиента, и все данные хранятся и обрабатываются у него. А расчётное ядро написано на C++ и проверено на ассортименте в 300 000 SKU и 400 магазинах — вопрос производительности, о котором шла речь в пункте 7, здесь уже решён.

Когда своя разработка всё-таки оправдана?

Своя система бывает оправдана, но только когда одновременно выполняется несколько условий:

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

Что проверить, если вы всё-таки хотите написать систему сами

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

Зачем и что считаем успехом

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

Разработка

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

Эксплуатация

• Где будет работать система и кто настраивает инфраструктуру?
• Что сделает система, если данные пришли не полностью?
• Что происходит, если расчёт не выполнился в день заказа, и сколько мы можем простаивать?
• Кто дежурит, пока формируется и отправляется заказ, включая выходные и праздники?
• Как выпускаем обновления и как быстро можем вернуть прежнюю версию?
• Кто отвечает на вопросы закупщиков и обучает новых сотрудников?

Безопасность и зависимости

• Кто может изменить заказ и где это видно?
• От каких внешних сервисов зависит система и что будет, если доступ к ним закроется?

Люди и деньги

• Кто решает, какие доработки делать первыми?
• Что будет, если ключевой разработчик уйдёт?
• Кто будет владеть системой через три года и сколько это стоит в год?
• Посчитана ли стоимость на 5 лет, включая инфраструктуру, найм, доработки учётной системы и потери обкатки?

Система, которая годами распоряжается деньгами

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

Поэтому вопрос стоит ставить не «за сколько ИИ напишет нам автозаказ», а «готовы ли мы стать владельцем системы, которая распоряжается нашими деньгами, на ближайшие 5–10 лет».

Если ответ «да» и у вас есть команда и экспертиза, чек-лист выше поможет не пропустить важное. Если сомневаетесь, разумно начать с проверки готовой системы на своих данных. Например, в Forecast NOW! для этого есть предпроектное исследование: за 2–3 недели система на ваших данных сравнивает, как заказывали вы и как заказала бы она, и показывает разницу в деньгах. Какой путь выбрать — решать вам. Но принимать это решение лучше, понимая полный объём работы и затрат.

Читайте также

• Можно ли написать систему управления запасами с помощью ИИ?
• Почему нужно сразу моделировать заказ, а не прогнозировать отдельно спрос и запас
• Точность прогнозирования или прибыль? Что нужно измерять?
• Разрабатывать свою систему управления запасами или внедрять стороннее решение?
• Почему не внедряется система управления запасами? Человеческий фактор
• Что умеет ИИ в прогнозировании — и чего нет

Подписаться на телеграм-канал Forecast NOW!

Источники

1. DORA (Google Cloud), «State of AI-assisted Software Development 2025». https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
2. Sculley D. и соавторы, «Hidden Technical Debt in Machine Learning Systems», NeurIPS, 2015. https://papers.nips.cc/paper_files/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html
3. Reuters, «Target Canada's supply chain gridlock: how Barbie SUVs snarled traffic», 2014. https://www.reuters.com/article/business/exclusive-target-canadas-supply-chain-gridlock-how-barbie-suvs-snarled-traffic-idUSBREA4K0UL/
4. Spracklen J. и соавторы, «We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs», USENIX Security, 2025. https://arxiv.org/abs/2406.10279
5. Хабр Карьера, «Зарплаты IT-специалистов в первой половине 2026 года». https://habr.com/ru/specials/1060148/
6. Хабр Карьера, калькулятор зарплат в IT. https://career.habr.com/salaries
7. Т-Банк, статья о прогрессивной шкале НДФЛ. https://www.tbank.ru/finance/blog/progressive-tax/
8. ФНС России, «Установлен единый предельный размер базы для исчисления страховых взносов на 2026 год». https://www.nalog.gov.ru/rn77/news/activities_fts/16577139/
9. Flyvbjerg B., Budzier A., «Why Your IT Project Might Be Riskier Than You Think», Harvard Business Review, 2011. https://arxiv.org/abs/1304.0265
10. McKinsey & Company, «Delivering large-scale IT projects on time, on budget, and on value», 2012. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value