Как мы изменили функциональное моделирование в ERP-проектах и построили каркас ФМ за два часа

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

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

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

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

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

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

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

Но в этот раз речь уже не о методологии как таковой. Речь о том, что происходит, когда накопленную за несколько лет структурированную информацию мы начинаем отдавать ИИ. Материал может быть полезен компаниям, которые уже перешли на 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 с ранее реализованными проектами и выбираем проект из похожей сферы. Например, если исследуется производственное предприятие, логично ^[5] использовать в качестве основы модель другого производственного предприятия.

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

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

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

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

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

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

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

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

· функции;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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