AI агент закупок: где ломается текущий процесс снабжения
Заявка на закупку редко приходит в одном формате: почта, рабочий чат, таблица отдела, устная договорённость после планёрки. Снабженец вручную сводит это в общий реестр, уточняет номенклатуру и досылает пропущенные поля — и обработка заявок на закупку растягивается ещё до того, как появится первое предложение поставщика.
Дальше начинаются ручные сверки поставщиков. Цены, сроки отгрузки, минимальная партия и условия оплаты живут в переписке, а не в общей базе: сравнивать приходится по последнему письму, история цен нигде не накапливается. Одна и та же позиция у разных поставщиков идёт под разными артикулами и фасовками — сопоставление держится на памяти конкретного человека, а не на правилах, поэтому при его отсутствии процесс встаёт.
Отдельное узкое место — ожидание подтверждений. Согласование уходит в мессенджер, теряется среди других обсуждений, инициатор по несколько раз уточняет статус. Пока заявка ждёт, предложение поставщика истекает, срок поставки сдвигается, и часть позиций уходит в срочную закупку на худших условиях.
Цена этих участков — не в одной ошибке, а в накоплении: заметная доля заявок идёт вне регламента, срок от потребности до заказа растёт, срочные закупки становятся нормой, а экономия на условиях теряется незаметно. Узкие места процесса закупок почти всегда лежат не в переговорах, а в ручной передаче данных между людьми. Разбираем, как AI агент закупок закрывает каждый из этих участков — от разбора входящей заявки до готового заказа.
Что меняется после внедрения агента закупок
Первый сдвиг виден на цикле заявки. Раньше сбор потребности, сверка со справочником, запрос предложений и согласование растягивались на дни, и почти каждое действие выполнялось руками. AI-агент закупок собирает данные из учётной системы и почты, проверяет остатки и действующие договоры и отдаёт закупщику готовую заявку с расчётом — человек принимает решение, а не переносит цифры.
Доля ручных операций падает до уровня, который видно по загрузке отдела: типовые закупки уходят в автоматический маршрут, у специалиста остаются нетиповые позиции, переговоры и работа с рисками. Время обработки заявки сокращается в разы — ожидание ответа от поставщика и внутренние согласования идут параллельно, а не по очереди.
Качество данных о поставщиках перестаёт зависеть от памяти сотрудников: история цен, фактических сроков и рекламаций живёт в одном реестре. Доля просрочек падает за счёт раннего предупреждения — агент сравнивает текущий срок с историей по позиции и эскалирует заявку до того, как поставка сорвана.
Часть ошибок уходит не реже, а совсем: дубли позиций, закупка по устаревшему прайсу, потерянные заявки, согласование в обход регламента. Проверка идёт до отправки, а не после. Агент работает в контуре 1С:ERP через штатные интерфейсы, поэтому данные не расходятся между таблицами и учётной системой.
Режимы работы агента: автономность и контроль человеком
Режим работы агента — это не общая настройка «включить автономию», а политика уровня категории закупки. Для каждой категории отдельно определяется, что агент закрывает сам, где он обязан остановиться на подтверждении человеком и какие заявки уходят в разбор исключений вручную. Такой подход позволяет начать с жёстких правил и скриптов и расширять границы автономности по мере накопления статистики, не переписывая интеграцию.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Правила и скрипты | Повторяемые закупки фиксированной номенклатуры, длинные рамочные соглашения | Не работает на новых категориях, ломается на нестандартном запросе |
| Подтверждение человеком | Первые месяцы эксплуатации, новые категории, значимые заказы | Скорость ограничена доступностью согласующего, копится очередь заявок |
| Автономия внутри лимитов | Устоявшийся круг поставщиков, типовые объёмы, заданы пороги | Требует актуальных лимитов и мониторинга, пороги нужно пересматривать |
| Разбор исключений после действия | Высокий поток типовых заявок, зрелые правила и накопленная история | Ошибку видно уже после действия, нужны журнал решений и быстрый откат |
Границы автономности пересматривают по накопленным данным: если в категории агент долго работает без откатов и возвратов, порог поднимают; после серии отклонений категорию возвращают на подтверждение человеком. Каждое решение агента попадает в журнал с обоснованием, использованными условиями и источником данных — поэтому разбор исключений занимает минуты, а не часы сверки переписки.
Этапы внедрения: аудит процесса, схема, проверка, передача
Работу начинаем не с настройки модели, а с разбора процесса: кто инициирует заявку, где согласуют, на каком шаге подключается поставщик и какие исключения обрабатывают вручную. Без этого агент воспроизводит не регламент, а привычки отдела — и расхождения всплывают уже на живых закупках. Ниже — порядок этапов внедрения агента с артефактом и точкой контроля на каждом шаге.
- Описание процесса закупок как есть. Интервью с закупщиками, разбор истории заявок и договоров, фиксация развилок и ручных обходов. На выходе — схема потока с пометкой, где решение формализуемо, а где остаётся за человеком.
- Карта правил принятия решений. Из описания выделяем условия: категория, срок, история поставщика, отклонение цены от обычной. Каждое правило получает приоритет и признак, по которому агент его применяет.
- Проектирование решений агента. Делим действия на три группы: выполняет сам, предлагает с подтверждением, эскалирует человеку. Отдельно прописываем поведение при нехватке данных — заявка не «зависает», а уходит на ручной разбор.
- Связь с учётной системой. Настраиваем обмен справочниками, заявками, статусами и документами, права агента ограничиваем нужными операциями. Каждое решение пишется в журнал с основанием и ссылкой на правило.
- Проверка на исторических данных. Прогоняем агента на прошлых закупках и сверяем с фактическими решениями. Считаем долю совпадений, расхождения разбираем: правила уточняем, спорные случаи оставляем человеку.
- Приёмка результата и передача. Контрольные сценарии на рабочем контуре, регламент исключений, обучение закупщиков и передача документации с картой правил и точками контроля.
Конфигурация агента, политики доступа и интеграции
Агент закупок работает не в вакууме: он читает номенклатуру, историю закупок и лимиты из учётной системы и действует от имени компании. Поэтому вместе с решением заказчику передаётся вся обвязка — от правил выбора поставщика до порядка действий дежурного инженера. Ниже перечень того, что остаётся в контуре заказчика и живёт без нашего участия.
- Конфигурация агента — карточки по классам закупок: категории, пороги количества, приоритеты поставщиков, правила подбора аналога, стоп-условия, при которых заявка не уходит дальше.
- Политики доступа и роли — кто видит переписку, кто утверждает отклонение от условий, кто меняет лимиты. Агент работает под отдельной сервисной учётной записью с минимально нужными правами, а не от суперпользователя.
- Интеграция с учётной системой — схема обмена: какие справочники читаются, как часто, по какому признаку сопоставляются позиции; поведение при недоступности системы и порядок повторных попыток.
- Регламент эскалации — условия остановки и передачи задачи человеку: нестандартная позиция, конфликт условий, спор по условиям поставки, молчание контрагента дольше заданного срока.
- Шаблоны сообщений — тексты запросов, напоминаний и отказов на языке контрагента, с подстановкой переменных и правилами тональности.
- Инструкции по сопровождению — где смотреть журнал решений агента, как воспроизвести конкретный кейс, как откатить изменение настроек и к кому идти при отклонении от ожидаемого поведения.
Комплект передаём в ваш репозиторий под контролем версий: любое изменение конфигурации проходит ревью, а не правится «по месту». Опишите задачу — вернёмся с оценкой и планом передачи.
Кейс: агент в снабжении — метрики до и после
Что было до внедрения
Снабжение разбирало заявки вручную: инженер открывал письмо, сверял позицию с номенклатурным справочником в 1С, проверял складские остатки, уточнял у инициатора сроки и только потом собирал пакет на согласование. На строку уходило 20–30 минут, а цикл согласования заявки растягивался до 4–7 рабочих дней. При 60–80 заявках в неделю очередь копилась, и часть позиций уходила в срочный обход регламента — именно там возникали расхождения в номенклатуре.
Что изменили и что получили
Кейс автоматизации закупок строился не на замене людей, а на снятии рутины. Агент закупок принимает заявку из почты и формы, приводит позиции к справочнику, подтягивает остатки, историю цен и прежних поставщиков, сам запрашивает недостающее у инициатора и отправляет пакет по маршруту согласования. Снабженец подключается только там, где решение выходит за правила: нестандартная позиция, новый поставщик, превышение лимита.
| Метрика | До | После |
|---|---|---|
| Заявок без ручного вмешательства | 0% | 74% |
| Цикл согласования заявки | 4–7 дней | 1–2 дня |
| Расхождения в номенклатуре | 12% | 1,5% |
| Время снабженца на строку | 20–30 мин | 4–6 мин |
Класс устранённых отказов — расхождения номенклатуры, дубли позиций и заявки, ушедшие в согласование без подтверждённого бюджета, — закрывается на входе. Снятая нагрузка на снабжение ушла не в простой, а в работу с поставщиками и срочные закупки вместо разбора очереди.
Чем агент отличается от правил и скриптов?
Правила и скрипты работают, пока заявка приходит в размеченную форму: позиция выбрана из справочника, количество — числовое поле, поставщик — из списка. Такой сценарий воспроизводим: одинаковый вход даёт одинаковый выход, а сбой повторяется на тестовом наборе и лечится правкой одного условия.
Ломается это на свободном тексте. «Те же фильтры, что в прошлый раз, но больше и с доставкой на склад» — под такую фразу правило не написать: вариантов формулировки десятки, а в справочнике пять похожих позиций с разными характеристиками. Набор условий обрастает исключениями, каждое новое задевает предыдущие, и доля заявок, уходящих на ручной разбор, растёт.
Агент разбирает формулировку целиком: выделяет позиции, сопоставляет их со справочником и историей закупок, достраивает недостающие условия — единицу измерения, кратность упаковки, срок — и помечает уверенность по каждой строке. При неоднозначном совпадении он не угадывает, а формирует уточняющий вопрос заявителю и фиксирует причину.
Граница проходит по цене ошибки. Лимиты, согласования и аудит остаются за детерминированными проверками: агент готовит данные и обоснование, решение принимает правило. Это сохраняет воспроизводимый след по каждой заявке и снижает ручной разбор без потери контроля.
Частые технические вопросы перед стартом
Перед стартом проверяют не то, умеет ли система читать письма, а как она ведёт себя в спорных случаях. Ниже — ответы на инженерные сомнения, которые чаще всего решают судьбу проекта.
Что происходит, если агент ошибётся?
Агент не пишет в учётную систему напрямую: он готовит черновик с обоснованием и ссылкой на источник, а запись проходит подтверждение по порогу уверенности. Всё ниже порога уходит человеку в очередь разбора, решения логируются — версия правил, входные данные, результат.
Как система обрабатывает нестандартные заявки?
Отклонение распознаётся по структуре: новая категория, нетипичное сочетание полей, незнакомая формулировка. Такие заявки агент не додумывает, а помечает и передаёт ответственному с указанием, чего не хватило для решения.
Нужны ли изменения в учётной системе?
На старте достаточно чтения справочников и истории заявок — обработка идёт в отдельном контуре со сверкой. Если учётная система отдаёт данные через штатные интерфейсы, доработок почти не нужно, а запись включается после параллельной работы.
Есть ли ограничения по категориям и ролям?
Границы задаёт заказчик: категории, доступные контрагенты, роли, круг подтверждающих. Категории с неформальными условиями остаются за человеком — агент готовит справку, но решение не принимает.
Кто отвечает за решения агента?
Правила и пороги утверждает заказчик, спорные случаи всегда за человеком: агент исполняет регламент, а не принимает решения. Журнал показывает, почему предложен вариант, а за итоговую заявку отвечает сотрудник, который её подтвердил.
Обсудим задачу: с чего начнём работу
Первый разговор — не презентация решения, а разбор процесса закупок: кто инициирует заявку, где она согласуется, на каком шаге появляется поставщик и какие исключения ломают регламент. Нужен весь путь целиком, включая ручные обходы и таблицы, которые живут вне учётной системы — именно там агент чаще всего и даёт эффект, а не в парадной части процесса.
Подготовка к старту со стороны заказчика — минимальная, но конкретная:
- выборка закрытых закупок: заявки, полученные предложения, итоговые условия — в любом формате, в котором они есть;
- справочники поставщиков и номенклатуры как есть, без предварительной чистки: качество данных мы оценим сами;
- маршруты согласования и матрица ответственных — по категориям, суммам и подразделениям;
- доступы и данные для первого контура: учётная запись только на чтение, копия базы или тестовый стенд, канал обмена;
- ограничения по данным: что нельзя выносить за периметр и что требуется обезличить до старта;
- критерии приёмки: метрики, которые фиксируем до начала работ, чтобы потом было с чем сравнивать результат;
- ответственный с вашей стороны, кто подтверждает логику и принимает работу по этапам.
С этими вводными готовим план работ по агенту: объём первого контура, этапы, состав команды, зависимость сроков от готовности данных и точки, где потребуется ваше решение. Возвращаемся с планом и оценкой в оговорённый срок, с явными допущениями — чтобы дальше обсуждать не ожидания, а конкретные шаги.
Опишите задачу в сообщении: какие системы задействованы, какие данные доступны и что хотите получить на выходе. Созвонимся, уточним детали и вернёмся с оценкой и планом запуска.
