Закупщик начинает день с десятков разных сигналов: новые заявки, изменение производственного плана, просроченные ответы поставщиков, приближение срока поставки и просьбы руководителя подготовить сводку. Чтобы ответить на один вопрос, приходится открывать ERP, SRM, почту и несколько отчетов.
ИИ-агент для закупок дает единое окно работы с этими данными. Сотрудник формулирует задачу обычным языком, агент собирает факты из разрешенных систем, объясняет результат и предлагает действие. Через MCP-сервер он может получить потребность, остатки, заказы и карточки поставщиков, а затем создать черновик, задачу или другой предусмотренный объект после подтверждения пользователя.
Чем агент отличается от обычного чата
Языковая модель умеет понимать запрос и готовить текст, но ей нужен актуальный контекст компании. Копирование таблицы в чат дает снимок на один момент и не позволяет проверить связанные документы. Агент обращается к корпоративным системам во время выполнения задачи и получает структурированный ответ.
MCP-сервер выступает связующим сервисом между агентом и учетной системой. Он публикует только предусмотренные ресурсы и инструменты: например, найти открытую потребность, получить историю цен, показать заказы поставщику или создать проект запроса предложения. Права пользователя и правила подтверждения сохраняются на этом уровне.
В результате агент работает с фактами, доступными конкретному сотруднику. Он знает, из какого документа получен срок, какая валюта указана в предложении и когда обновлялись остатки. Ответ можно проверить по исходным объектам.
Утренний список приоритетов
Первый полезный сценарий - краткая сводка исключений. Агент собирает заявки без ответственного, позиции с риском дефицита, заказы без подтвержденной даты, просроченные поставки и договоры, требующие действия.
Запрос может звучать так: «Покажи, какие поставки на этой неделе влияют на производственные заказы и требуют моего участия». Агент находит связанные потребности, учитывает доступный остаток и возвращает список с причиной приоритета.
Закупщик выбирает событие и просит раскрыть детали. В одном диалоге видны позиция, количество, заказ, поставщик, последняя договоренность и следующий контрольный срок. Агент может создать задачи по выбранным строкам, сохраняя связь с исходными документами.
Подготовка закупочной заявки
На входе часто встречаются неполные названия, свободный текст и вложения. Агент сопоставляет запрос с номенклатурой, находит похожие прошлые закупки и задает уточняющие вопросы. Окончательный выбор позиции подтверждает сотрудник.
После уточнения агент проверяет остаток, резерв, ожидаемые поступления и потребность по датам. Если закупка требуется, он готовит проект заявки с позициями, количеством, сроком и основанием. Заявка проходит установленный маршрут согласования.
Базовая логика заявок остается в SRM-системе. Агент ускоряет поиск и заполнение, сохраняя правила лимитов, согласований и ответственности.
Сравнение предложений поставщиков
Коммерческие предложения приходят в разных форматах. Агент извлекает позиции и условия, сопоставляет их с запросом и формирует единую структуру сравнения. Для каждой строки сохраняется источник, чтобы закупщик мог открыть документ и проверить значение.
Сравнение учитывает цену, валюту, срок, минимальную партию, условия оплаты, доставку и срок действия предложения. По данным системы добавляются качество предыдущих поставок, фактические задержки и рекламации. Критерии оценки задаются процессом компании.
Агент выделяет неполные или несопоставимые условия и готовит вопросы поставщикам. Решение о выборе принимает ответственная роль по утвержденным критериям, а результат фиксируется в закупочном процессе.
Контроль заказов и сроков
После размещения заказа агент отслеживает точки, где требуется коммуникация. Он видит отсутствие подтверждения, изменение даты, частичную отгрузку и расхождение между обещанным и требуемым сроком.
Для выбранного поставщика агент готовит письмо на основании заказа и последней переписки. Текст содержит конкретные позиции и даты из системы. Отправка выполняется по настроенному правилу: как черновик для проверки или как подтвержденное действие сотрудника.
При получении ответа агент извлекает новую дату и предлагает обновить состояние. Изменение планового срока остается отдельным действием с подтверждением и записью автора. Если поставка влияет на производство, уведомление получает планировщик или ответственный за заказ.
Вопросы руководителя
Руководитель может спросить, какие позиции подорожали, где выросла доля срочных закупок, какие поставщики чаще нарушают срок и почему изменился план-факт. Агент собирает расчет по утвержденным показателям и показывает состав выборки.
Вместо статичного отчета можно продолжить разбор: перейти от общей суммы к категории, поставщику и конкретному заказу. При этом определения показателей должны оставаться закрепленными в системе, чтобы одинаковый вопрос давал сопоставимый результат.
Подход к регулярному сопоставлению потребности и факта раскрыт в статье про план-факт закупок. Агент делает такой анализ доступным в диалоге и помогает сформировать задачи по найденным отклонениям.
Какие действия можно доверить агенту
Удобно разделить инструменты по уровню последствий. Чтение и подготовка сводки выполняются сразу в рамках прав пользователя. Создание черновика заявки, письма или задачи дает обратимый результат. Размещение заказа, изменение существенного срока и отправка сообщения требуют явного подтверждения или установленного маршрута.
Для каждого инструмента задаются входные данные, проверка полномочий и ожидаемый результат. Агент показывает, что собирается сделать: какой объект создать, какие поля заполнить и на основании каких документов. После подтверждения MCP-сервер выполняет операцию и возвращает идентификатор.
Повторный вызов защищается от дублирования. Журнал хранит пользователя, запрос, инструмент, параметры, результат и время. Это позволяет разбирать действия так же, как операции сотрудника в ERP.
Роли и защита данных
Закупщик видит свои категории и поставщиков, руководитель - подразделение, а согласующий - документы в рамках маршрута. Агент наследует этот контекст. Доступ к договорам, ценам и персональным данным открывается по действующим ролям.
Языковая модель получает только информацию, необходимую для текущей задачи. Реквизиты подключения к ERP остаются у интеграционного сервиса. MCP предусматривает авторизацию клиента, а проект дополнительно определяет аудит, хранение истории и правила работы с выбранной моделью.
Источник каждого важного факта полезно показывать в ответе. Сотрудник может открыть заявку, заказ или предложение и проверить вывод. Для действий с последствиями сохраняется подтверждение.
Как агент связывает несколько систем
Закупочный процесс редко находится в одной программе. Потребность формируется в ERP, поставщики ведутся в SRM, договоры хранятся в архиве, а переписка идет по почте. Для агента создаются отдельные управляемые инструменты, которые возвращают объекты в согласованном формате.
ERP-система остается источником потребности, остатков и учетных документов. SRM отвечает за закупочный процесс и поставщиков. Агент объединяет контекст задачи, сохраняя владельца каждого объекта.
Такая архитектура позволяет начинать с одного полезного сценария. Например, сначала агент только собирает просроченные подтверждения и готовит черновики писем. После проверки качества данных подключаются заявки, сравнение предложений и разрешенные действия.
Первый сценарий для пилота
Для первого этапа выбирают повторяющуюся задачу с понятным результатом. Описываются вопросы закупщика, источники данных, требуемые поля, роли и действия. На реальных примерах проверяется, может ли система однозначно найти нужные документы.
Далее ИНДИНС разрабатывает MCP-сервер и агентный сценарий под используемые SRM, ERP, 1С и внутренние сервисы. В решение входят инструменты доступа, правила подтверждения, журнал, обработка ошибок и интерфейс работы с агентом.
Пилот оценивают по времени выполнения задачи, полноте результата, числу ручных переходов между системами и качеству предложенных действий. После подтверждения пользы контур расширяется на соседние процессы закупок.