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

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

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

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

Где закупка теряет время

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

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

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

Что получает ИИ-агент

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

• ERP или учётная система: номенклатура, остатки, действующие заказы и статусы.
• CRM или сервисная система: связанный клиентский заказ, проект или обращение, если закупка возникла из него.
• Корпоративные документы: регламент, лимиты, перечень обязательных полей и правила выбора маршрута согласования.
• Справочник контрагентов: только разрешённые сведения об одобренных поставщиках и условиях работы.
• Почта, форма или Telegram: удобный интерфейс для уточнений и уведомлений, но не отдельная система учёта.

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

Как проходит заявка

Агент собирает недостающие сведения

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

Проверяет, нужна ли новая закупка

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

Готовит пакет для согласования

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

Передаёт решение ответственному

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

Что можно выполнять автоматически

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

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

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

Как обрабатывать исключения

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

Хороший сценарий не заставляет модель угадывать. Для каждого исключения заранее определяется ответственная роль, канал уведомления и доступные действия. Закупщик получает причину остановки и ссылки на источники, а не сообщение «не удалось выполнить» без объяснения.

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

Роли, права и журнал действий

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

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

С чего начинать внедрение

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

Что получает бизнес

Результат такого внедрения — не «автономный отдел закупок». Бизнес получает единый вход для заявки, меньше возвратов из-за пропущенных данных, понятный пакет для согласования и прозрачную передачу между ролями.

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

Проверка готовности процесса

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

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