Представьте первый день проекта внедрения ERP. Заказчик передал копию информационной базы 1С. Спустя два часа у нас уже есть перечень используемых объектов, возможных функций и предварительная модель бизнес-процессов. А после обеда можно не спрашивать главного бухгалтера: «Используете ли вы заказы клиентов?», а обсуждать, как именно устроен процесс работы с заказами.

Это не фантазия. Такой сценарий мы используем на реаных проектах, и этот подход сокращает длительность этапа «ФМ» минимум на один месяц. Это даже оставляет возможность внедрить 1С ERP с 1 января 2027 года.

Для этого за последний месяц мы реализовали ИИ-агента для вполне практических задач, которого пока назовем «Ассистент проектного аналитика».

Это продолжение серии статей о проектах внедрения ERP-систем компании «Автомакон»:

- [статья про методологию функционального моделирования] https://habr.com/ru/articles/1063672/

- [статья про методологию управления разработкой] https://habr.com/ru/articles/1064294/

Руководитель данного направления – наш давний сотрудник, автор и разработчик программно-методологического комплекса ERP-tools, который позволяет управлять всем жизненными циклом информационных систем – от внедрения и текущего развития до замены следующим поколением. Будем знакомить с техникой данного подхода в наших статьях. Также, приглашаем посетить конференцию Infostart с 12 до 14 ноября 2026 года, где будет интересный доклад (https://infostart.ru/event/apm2026/agenda/2739686/) по автоматизации функционального моделирования.

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

Почему функциональное моделирование до сих пор делают вручную

В крупном и среднем бизнесе информационный ландшафт редко состоит из одной системы. Это десятки информационных систем на 1С, различные Java-приложения и порталы, CRM, HR-системы и, как правило, Confluence, где каждый проект имеет свое пространство.

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

Традиционно функциональное моделирование происходит по такой схеме: 

1. Интервью с пользователями, выявление бизнес-процессов и шагов

2. Сохранение данных в различных Excel-файлах

3. Текстовое описание процессов в произвольном виде

В функциональном моделировании информационной системы мы используем другой, достаточно простой подход:

1. Выявить используемые объекты метаданных.

2. Выявить функции этих объектов.

3. Собрать функции в бизнес-процессы и получить бизнес-процессную функциональную модель.

4. Обсудить собранную модель с заказчиком

Первые две задачи выглядят как аналитическая работа. Но действительно ли они требуют аналитика?

А что, если функцию вообще не нужно искать?

Допустим, в информационной базе есть документ «Заказ клиента». Можно пригласить аналитика, показать ему систему и спросить: «Какие функции есть у этого документа?» Он посмотрит интерфейс, поговорит с пользователями и запишет: «Создание заказа клиента».

Но если документ существует в системе, то кто-то его создал. То есть функция «Создание заказа клиента» не является результатом интеллектуального открытия аналитика. Она следует из самого существования объекта.

Если у документа есть табличная часть «Товары», то появляются другие возможные действия:

· резервирование;

· снятие резерва;

· постановка в отгрузку;

· отмена строки

И здесь возникает довольно простая мысль.

Необязательно заставлять человека выявлять то, что уже следует из структуры информационной системы.

В нашей практике значительную часть функций можно получить алгоритмически. Условно мы оцениваем эту часть примерно в 95%. Оставшиеся функции действительно требуют работы аналитика: они могут зависеть от конкретной настройки, доработки, особенностей предприятия или бизнес-процесса.

Но наличие этих 5% не означает, что человек должен вручную искать остальные 95%.

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

Для анализа исследуемой информационной системы мы сделали обработку, которая последовательно выполняет несколько шагов:

1. Реестр используемых документов и справочников.

2. Реестр включенных констант.

3. Реестр возможных функций справочников и документов.

4. Реестр профилей доступа.

Здесь нет никакой магии и не нужен LLM. Система сама является источником фактов о себе. И это, пожалуй, важный принцип всей нашей дальнейшей работы с ИИ:

Если информацию можно получить непосредственно из информационной системы — не нужно просить LLM угадывать из мирового контекста.

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

· Создание авансового отчета,

· Создание авансового отчета в статусе Подготовлен,

· Утверждение авансового отчета

Теперь нужно ответить на другой вопрос: в каком бизнес-процессе находятся эти функции? И здесь уже нет однозначного ответа.

Можно назвать процесс:

· Работа с авансовыми отчетами

· Расчеты с подотчетными лицами

· Управление подотчетными лицами

Какой вариант правильный? Формально — все три могут описывать одну и ту же область деятельности. Получается интересная ситуация. Функцию мы можем получить из структуры системы. А вот упаковка функции в бизнес-процесс уже в значительной степени является результатом экспертной работы.

Именно здесь мы решили попробовать ИИ. Мы специально не стали отдавать LLM всю задачу целиком. Нам не нужно, чтобы модель самостоятельно придумывала:

· какие документы есть в 1С;

· какие функции у них существуют;

· какие пользователи имеют доступ;

· какие бизнес-процессы вообще бывают.

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

В качестве модели мы использовали связку Ollama + Qwen 2.5. Все работает локально, поэтому данные не покидают внутреннюю сеть, а во время работы не возникает расходов на драгоценные (и волшебные) токены.

Откуда у ИИ взялась эталонная модель

Это, пожалуй, самая важная часть эксперимента. За несколько лет работы над проектами у нас накопилась база ранее реализованных моделей разных предприятий и отраслей в формате базы данных ERP-tools. В ней есть:

· бизнес-процессы;

· функции;

· Требования

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

· Управление расчетами с подотчетными лицами

А внутри него функция:

· Создание авансового отчета

Для новой информационной системы мы получили:

· Создание авансового отчета в статусе Подготовлен

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

Как работает агент

Шаг 1. Выбираем похожий проект

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

Шаг 2. Загружаем эталонную модель.

Получаем перечень бизнес-процессов и функций, которые были сформированы в предыдущем проекте.

Шаг 3. Запускаем LLM.

Для каждой функции исследуемой системы агент пытается найти соответствие в эталонной модели.

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

Шаг 4. Загружаем результат в ERP-tools 

После обработки данные выгружаются в новый проект. В среднем мы имеем дело примерно со 100 бизнес-процессами и 600 функциями системы. Создаются необходимые артефакты:

· объекты метаданных;

· функции;

· связи функций с объектами;

· бизнес-процессы;

· целевые шаги процессов;

· связи шагов с функциями.

И что получилось? Самое интересное — время. Спустя примерно два часа после получения от заказчика копии базы мы уже можем переходить к предметному разговору, а у аналитиков появляется практически полный перечень задач: промоделировать все функции всех процессов, выявить нюансы и необходимые доработки.

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

Что произошло с работой аналитика?

Аналитик никуда не исчез. Более того, на мой взгляд, его работа становится интереснее. Раньше значительная часть времени уходила на:

· просмотр системы;

· составление реестров;

· перенос информации в Excel;

· фиксацию очевидных функций;

· первоначальную упаковку функций в процессы.

Теперь эту работу можно в значительной степени автоматизировать. А человеку остается то, ради чего его действительно приглашали на проект:

· разобраться в неоднозначных местах;

· понять особенности конкретного предприятия;

· определить реальные бизнес-процессы;

· обсудить функциональные разрывы;

· выбрать между несколькими вариантами реализации.

То есть ИИ не заменяет аналитика. Он убирает из его работы ту часть, которая вообще не требует аналитического мышления.

Что агент пока не умеет. До полноценного «Проектного аналитика» нам еще далеко. Сейчас агент хорошо работает с тем, что можно сопоставить с уже существующей базой знаний. Но в реальном проекте остаются задачи, где простого сопоставления недостаточно.

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

Есть ли сложности с получением этих данных? Нет. Они лежат в эталонном проекте и ждут повторного использования.

Тогда агент сможет не только сказать:

«У вас есть функция X», но и: «Для этой функции в 1С предусмотрено несколько вариантов реализации. В аналогичном проекте мы использовали такой вариант. Еще один вариант требует доработки, которую уже реализовывали раньше».

Это уже гораздо ближе к работе настоящего проектного аналитика.

Главный вывод

Самым интересным результатом этого эксперимента для нас оказался даже не сам LLM. Раньше мы просто старались правильно и подробно описывать проекты. Тогда мы и не думали, что однажды эти данные станут сырьем для ИИ.

Теперь оказалось, что именно структурированная информация о бизнесе позволяет построить довольно практичного корпоративного агента. Мы не загрузили в LLM тысячи документов и не попросили:

«Разберись, как работает предприятие».

Мы сделали наоборот.

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

Не заставлять ИИ каждый раз заново изучать бизнес. Сначала нужно научиться хранить сам бизнес в форме, с которой ИИ сможет работать.

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

Часто от LLM ждут чуда: «Агент посчитал стоимость проекта для клиента, а мы просто отдали ему файл с техническим заданием». Или даже: «LLM выдала функциональную модель, хотя мы просили заказать пиццу!»