5–7 часов ручной закупки в день на 50 000 SKU: как ИИ-агент встраивается в кастомную 1С и не создаёт двойную работу 

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

Короткий ответ, если лень читать полчаса. Автоматизировать закупку в кастомной 1С можно, и быстро: рабочий пилот собирается за 2–3 недели. Но только если с первого дня строить не «советчика», а агента с правом записи — систему, которая доводит дело до готового черновика заказа поставщику прямо в 1С, а человек подтверждает его в один клик. Всё, что останавливается на «вот вам список рекомендаций, дальше сами», — это не автоматизация. Это вторая работа поверх первой. Дальше — почему именно так, где закопаны мины и как выглядит архитектура, которая не рассыпается на кастомной конфигурации.

Откуда берутся 5–7 часов: анатомия ручной закупки на 50 000 SKU

Со стороны кажется, что закупка — это «посмотрел, чего мало, заказал». На потоке в десятки тысяч артикулов это не одна задача, а несколько вложенных, и каждая по отдельности несложная — но перемножьте их на ассортимент, и получите те самые часы.

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

Это не рутина в смысле «тупая механическая работа». Это многомерная задача оптимизации с жёсткими ограничениями, мягкими эвристиками и неявными компромиссами, которую человек решает в уме и в десятке открытых вкладок Excel. Жёсткие ограничения — MOQ, кратность, сроки, объёмные пороги. Мягкие эвристики — репутация поставщика, риск получить контрафакт, сезонность. Неявные компромиссы — оборотка против неликвида, маржа против объёмной скидки. Именно поэтому опытный закупщик стоит дорого и именно поэтому его невозможно просто «заменить кнопкой». А ещё поэтому он в 18:00 всё ещё сидит и сводит таблички вместо того, чтобы выбивать из поставщиков условия — то есть заниматься тем, что действительно приносит деньги.

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

Почему прошлое «внедрение ИИ» удвоило работу, а не сократило

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

А дальше закупщик открывает этот список и начинает делать свою работу заново. Потому что модель не знает, что по вот этому бренду сейчас стоп-отгрузка. Не знает, что этого поставщика две недели назад занесли в чёрный список за пересорт. Не знает про порог выкупа, ниже которого нет смысла заказывать. Не умеет положить строку в документ «Заказ поставщику» в 1С — а значит, всё, что она «нарекомендовала», всё равно нужно перенести в систему руками, попутно перепроверив каждую цифру, потому что доверия к чёрному ящику нет. Вместо одной работы стало полторы: сначала прочитать и перепроверить советы машины, потом всё равно сделать всё самому. Классическая двойная работа — и первое, что убивает такие проекты в глазах людей, которые с ними живут.

Это не частная неудача конкретного подрядчика. Это индустриальный паттерн, и цифры по нему жёсткие. Исследование RAND по 2400+ компаниям показало, что около 80% ИИ-проектов не доносят до бизнеса заявленную ценность — вдвое больше, чем у обычного IT. MIT в отчёте State of AI in Business 2025 насчитал, что 95% корпоративных GenAI-пилотов не дают измеримого эффекта на P&L. IDC с Lenovo — что 88% пилотов вообще не доезжают до прода. И это при том, что спрос-то есть: по опросу директоров по закупкам от Deloitte 92% планируют и оценивают генеративный ИИ, но реально пилотируют или внедряют только 37%. Разрыв между «хотим» и «работает в проде» — гигантский, и падают проекты не там, где не хватило модели, а там, где не хватило инженерии стыка с реальностью.

«Может, модель была слабая? Взяли бы GPT помощнее — и всё бы поехало».

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

Три мины автоматизации закупок в 1С

Разберём по очереди. Каждая из них по отдельности способна похоронить проект, а вместе они объясняют, почему «просто прикрутить нейросеть» не работает.

Мина первая: кастомная 1С, которую нельзя трогать

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

Правильный путь — работать рядом с 1С, а не внутри неё. И платформа для этого даёт ровно то, что нужно, без единой правки конфигурации. Автоматический REST-интерфейс на OData платформа 1С:Предприятие (начиная с 8.3.5) генерирует сама: включается галочкой «Публикация стандартного интерфейса OData» на веб-сервере, и наружу открывается доступ к справочникам, документам и регистрам по протоколу OData 3.0 — читать остатки, продажи, номенклатуру, писать черновики документов. Ничего в дереве конфигурации при этом не меняется. Там, где стандартного OData не хватает (нужна своя бизнес-логика на стороне 1С, например «собери мне доступный остаток с учётом резервов одним запросом»), пишется тонкий HTTP-сервис, вынесенный в расширение конфигурации — расширения накатываются поверх типовой и переживают её обновления, не смешиваясь с основным кодом. Для тяжёлого пакетного обмена есть внешние обработки (.epf) и планы обмена. У каждого механизма свой профиль по надёжности и задержке, но принцип один: интеграционный слой — снаружи, и обновление конфигурации его не затирает. Подробнее эту развилку — OData против HTTP-сервисов против обменов — мы разбирали в материале про то, как ИИ вводит первичку в 1С: там та же инженерная логика записи в систему учёта снаружи, только на входящих документах.

Мина вторая: лимиты выкупа поставщиков и правила, которых нет в системе

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

Потому что у дистрибьюторов есть пороги выкупа — минимальный объём за период, ниже которого слетает дилерская цена или бонус. Есть кратность упаковки: свеча продаётся поштучно, а приезжает коробками по восемь, и заказ на «11 штук» превратится в 16 или в 8, и это надо учесть до размещения, а не после. Есть минимальная партия (MOQ) и минимальная сумма заказа, ниже которой поставщик просто не поедет. Есть сроки поставки, которые надо закладывать в точку заказа, иначе полка опустеет до приезда. Есть приоритеты: с этим поставщиком годовой контракт с обязательством по объёму, и добить у него — стратегически выгоднее, чем сэкономить пять рублей у случайного. Всё это — жёсткие бизнес-правила, и цена ошибки в них считается в живых деньгах: либо переплата, либо замороженный неликвид, либо потерянный бонус, ради которого весь квартал работали.

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

Мина третья: правила «в голове» закупщика

Самая коварная. Часть логики закупки нигде не записана — она живёт в голове человека, который занимается этим восемь лет. «У этого поставщика по четвергам прайс обновляется, до обеда не заказываю». «Вот этот бренд берём только под заказ, на склад не морозим». «Если клиент — вот эта СТО, для них аналог не предлагаем, только оригинал, иначе вернут». «Этого менеджера если попросить, придержит дефицит». Формально этого нет ни в 1С, ни в регламенте. Фактически на этом держится половина решений.

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

Архитектура: где жёсткие правила, где LLM точечно, где интеграция

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

Раскладываем задачу на три слоя, и у каждого — свой ответственный.

Обратите внимание, где именно стоит LLM. Не «нейросеть управляет закупкой». LLM зовут точечно — там, где на входе человеческий текст, и только там. Сопоставить строку из присланного прайса «Кол.вал.пер.пер. 2108 к-т 8шт» с нашей номенклатурой — это fuzzy-задача, где нужно понять смысл сокращений, и языковая модель тут вне конкуренции. Но сколько этой детали заказать и у кого — считает движок правил, детерминированно, и его решение можно повторить и объяснить строчкой за строчкой. Псевдокод, чтобы было предметно:

# Детерминированное ядро. Считает деньги. LLM здесь нет и быть не должно.
def predlozhit_zakaz(sku, sklad, prognoz, postavshchiki, pravila):
    tochka_zakaza = prognoz.dnevnoy_rashod(sku) * srok_postavki(sku) + strahovoy_zapas(sku)
    dostupno = sklad.ostatok(sku) - sklad.rezerv(sku) + sklad.v_puti(sku)
    if dostupno > tochka_zakaza:
        return None                      # заказывать нечего — не трогаем

    deficit = tochka_zakaza + celevoy_zapas(sku) - dostupno

    # выбор поставщика — это ПРАВИЛА, а не «мнение модели»
    kandidaty = [p for p in postavshchiki if p.est_v_price(sku)]
    kandidaty = otsech_po_stop_listam(kandidaty, pravila)      # стоп-отгрузки, чёрный список
    if not kandidaty:
        return Isklyuchenie(sku, prichina="нет валидного поставщика")   # → человеку

    postavshchik = min(kandidaty, key=lambda p: (p.prioritet, p.cena(sku), p.srok(sku)))

    kol = okruglit_vverh_do_kratnosti(deficit, postavshchik.kratnost(sku))
    kol = dobit_do_poroga_vykupa(kol, postavshchik, pravila)    # добор до бонуса — по правилу
    if postavshchik.summa(sku, kol) < postavshchik.min_zakaz:
        return Otlozhit(sku, postavshchik)     # не набрали минималку — копим, не заказываем

    return StrokaZakaza(sku, postavshchik, kol)   # готовая строка для документа в 1С


# LLM зовём ТОЧЕЧНО — только там, где на входе текст, а не там, где деньги.
def sopostavit_pozitsiyu(stroka_praysa, katalog):
    kandidaty = bystryi_otbor_po_katalogu(stroka_praysa, katalog)   # сузили до десятка
    vybor = llm_vybrat_odin(stroka_praysa, kandidaty)               # модель решает спор
    if vybor.confidence < POROG:
        return NaProverku(stroka_praysa, kandidaty)                 # сомнение → человеку
    return vybor.sku

Ключевое здесь — не код, а разделение ответственности. Детерминированное ядро всегда можно прогнать на исторических данных и убедиться, что оно считает правильно. LLM всегда отдаёт результат с оценкой уверенности, и при сомнении отправляет позицию человеку, а не гадает. А там, где данные не сходятся (нет валидного поставщика, не набрали минималку, прайс не распарсился), система не выдумывает — она явно поднимает исключение и кладёт его в очередь на разбор человеку. Это и есть honest-by-design: машина делает 90% потока молча и правильно, а на 10% спорных честно поднимает руку. Кстати, отдельный плюс архитектуры «LLM точечно» — её можно держать полностью on-prem, без облака: прайсы и ценовая политика не покидают периметр компании, а это в закупках коммерческая тайна в чистом виде.

Прогноз спроса — отдельный слой, который я намеренно не смешиваю с движком правил. Он даёт на вход одну цифру — ожидаемый дневной расход, — и всё. Как именно строить этот прогноз на данных 1С:УТ (сезонность, тренды, всплески), мы подробно разбирали в материале про предсказание спроса на 90 дней вперёд. Важно, что его выход идёт внутрь детерминированного расчёта, а не наружу к человеку в виде очередного «списка рекомендаций». Тогда прогноз работает на систему, а не создаёт ещё одну таблицу, которую надо читать глазами.

Killer-фича: заказ в один клик, а не список рекомендаций

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

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

Технически за этим «одним кликом» стоит то самое право записи через интеграционный слой: агент формирует документ через OData или HTTP-сервис и кладёт его в 1С в статусе черновика. Не проводит, не отправляет поставщику, не двигает деньги — просто готовит. Финальное действие всегда за человеком, и это не компромисс, а осознанное проектное решение: у агента нет права подписи, у него есть право подготовить. Ровно так же, как ассистент готовит документ, а решение принимает руководитель. Разница между «система насоветовала, а я делаю» и «система сделала, а я проверил и утвердил» — это разница между двойной работой и десятикратным ускорением. Та же логика «черновик → подтверждение в один клик», только на входящих заказах клиентов, а не на исходящих поставщикам, — это соседняя задача про ИИ-агента в закупках и на складе; принцип идентичный, меняется только направление документа.

И вот что происходит с теми самыми 5–7 часами. Они не исчезают в ноль — это было бы враньём. Они сжимаются. Рутинные 90% потока — позиции, где всё однозначно, — агент готовит сам, и закупщик пролистывает их пачкой, подтверждая. Оставшиеся 10% — спорные исключения, которые система честно вынесла на разбор, — получают то самое дорогое человеческое внимание, ради которого закупщика и держат. Работа смещается с перебивания цифр на принятие решений по краям. Замеры по индустрии это подтверждают: Hackett Group насчитал у лидеров сокращение цикла «заявка → заказ» на 58%, а McKinsey оценивает прирост продуктивности закупок в 25–40% на задачах именно такого класса. Это не «нейросеть уволила отдел закупок» — это отдел закупок перестал работать переписчиком.

Как это ведёт себя на потоке: исключения, а не идеальный мир

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

Новый поставщик, которого ещё нет в справочнике, прислал прайс — агент не должен молча его проигнорировать или, хуже, создать дубль контрагента. Он поднимает исключение: «новый источник, нужна карточка». Позиции нет в каталоге — не выдумываем SKU, кладём в очередь на заведение номенклатуры. Цена в прайсе скакнула вдвое против прошлой поставки — не заказываем на автомате, флажок «аномалия цены, проверьте». Прайс пришёл битым PDF, где LLM не уверена в трёх строках из ста, — эти три строки идут человеку, остальные 97 проходят. Это и есть human-in-the-loop не как галочка, а как несущая конструкция: машина знает границы своей компетенции и честно останавливается на краю, вместо того чтобы уверенно ошибаться. Именно неумение системы сказать «я не знаю» и порождает недоверие, которое хоронит проекты, — про то, как кривой ИИ в учётной системе теряет деньги на молчаливых ошибках, мы писали в разборе ошибок на складе.

Второй столп доверия — объяснимость каждого решения. Рядом с любой строкой заказа агент показывает, почему она такая: «точка заказа 40, доступно 12, дефицит 28, округлил до кратности 32, поставщик А выбран по приоритету контракта, цена из прайса от вчера». Закупщик не обязан верить чёрному ящику — он видит арифметику и либо соглашается, либо правит правило, из-за которого вышло не так. Каждая правка — это дообучение системы на явных правилах, а не на туманных градиентах. Через месяц такой работы движок знает то, что раньше жило только в голове закупщика, — и знает это в редактируемом, передаваемом виде, который не уволится и не уйдёт в отпуск.

MVP за 2–3 недели: с чего начать, чтобы не утонуть

Соблазн — автоматизировать всё и сразу, все 50 000 SKU, всех поставщиков, все правила. Это верный способ никогда не дойти до прода: проект уходит в вечное «дособираем правила» и умирает пилотом-призраком, как 88% ему подобных. Правильный заход — обратный: узкий срез, который доезжает до боевого «Заказа поставщику» за две-три недели, и уже на нём виден эффект.

Как режется первый срез. Берём одну товарную группу — например, расходники по ходовой, где спрос стабильный и правила проще, — и двух-трёх ключевых поставщиков, а не весь пул. По этому срезу поднимаем интеграцию с 1С на чтение (остатки, продажи, номенклатура) и на запись черновика. Реализуем детерминированное ядро — точку заказа и выбор поставщика по явным правилам, которые за пару сессий вытащили из головы закупщика. Прикручиваем LLM ровно в одной точке — на разбор прайсов этих двух-трёх поставщиков. И замыкаем контур: агент кладёт черновик заказа в 1С, закупщик подтверждает в один клик. Всё. Дальше — расширение на следующие группы и поставщиков по накатанной, потому что каркас уже стоит и проверен на бою.

Что мерить, чтобы понять, взлетело или нет. Не «точность модели» — эта метрика ничего не говорит бизнесу. Мерить надо долю позиций, которые прошли без ручной правки (сколько потока агент реально снял), время на формирование заказа (те самые часы — до и после) и количество исключений, требующих человека (падает по мере того, как правила достраиваются). Экономику посчитать несложно и без нас: закупщик на кастомной 1С в рознице — это специалист, чьё рабочее время стоит десятки тысяч рублей в месяц, и если 60–70% этого времени уходит на перебивание цифр, то освобождение хотя бы половины — это прямая отдача уже на одном человеке, не считая денег, которые перестают течь сквозь пальцы на упущенных бонусных порогах и замороженном неликвиде. Прикинуть порядок цифр под свой объём и число закупщиков можно на калькуляторе — это не оферта, а честная вилка «от и до», чтобы разговор шёл предметно.

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

Мы в Morana Labs эту связку — ИИ-агенты с правом записи в 1С плюс прогноз спроса — катим именно так: детерминированное ядро на деньгах, LLM точечно на тексте, интеграция снаружи конфигурации, старт с узкого среза и человек, который подтверждает в один клик. Не «нейросеть заменит закупщика», а «закупщик перестанет быть переписчиком и начнёт выбивать условия». Если хочется не пилота ради галочки, а системы, которая доезжает до прода, — правильно начинать с аудита и дорожной карты: две недели, чтобы понять, где у вас закопаны эти три мины конкретно, и что из этого снимается первым.