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