В первой статье мы начали рассматривать мою Методологию функционального моделирования ERP-систем и показали, что основой проекта должна стать единая функциональная модель предприятия или ОКИС – операционная карта информационной системы.

Именно она объединяет функции пользователей, бизнес-процессы, инструкции, требования и объекты метаданных в единую структуру знаний. В этой части мы переходим к этапу Настройка и разработка и тоже будем говорить о процессе с точки зрения этой Методологии. Если на ваших предприятиях используется другая процедура, то это не противоречие - просто вы используете другой подход. Я буду рассказывать о собственных практиках, позволяющих проводить большую модернизацию ERP систем (сотни доработок) в очень быстрых проектах.

Можно выделить несколько видов доработки

Доработка функционального требования
BugFix
Обновление
Интеграции и так далее

В данной статье мы будем говорить о доработках функциональности.

Что происходит после окончания моделирования?

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

Именно так обычно изображают жизненный цикл ERP-проекта.

Иногда даже так

Но фактически при эксплуатации системы наблюдается вот такой цикл

Процесс модификации как правило начинается с небольшим отставанием от моделирования и фактически эти процессы идут параллельно весь жизненный цикл ИС и как только этот принцип ломается – документация начинает деградировать и в какой-то момент времени документирование всей системы прекращается и продолжается только разработка ТЗ и их выполнение.

В проектах внедрения является проблемой то, что формально ФМ завершен и доработки перестают вносить изменения в документацию, создавая массив незадокументированных ТЗ и протоколов испытаний.

Методология как раз и позволяет организовать сплошное документирование системы и фактически соединить процессы Моделирования и Доработок в сквозные бизнес-процессы.

Настройка и разработка как непрерывный процесс

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

Каждая доработка проходит одинаковый маршрут. Именно этот маршрут обеспечивает постоянную актуализацию модели предприятия.

Жизненный цикл доработки

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

Это позволяет управлять изменениями не вручную, а по заранее определенному регламенту. Каждый шаг – независимая задача с ответственным и постановщиком, а передвигаться к следующему шагу можно только при фактическом выполнении предыдущего. Можно сформировать конвейер доработки для параллельной работы с десятками и даже сотней модификаций.

Доработка в Методологии это программирование Требования, которая через Инструкцию модифицирует Функцию. Таким образом, мы никогда не «программируем заказ клиента» или «программируем Создание заказа клиента». Мы программируем особенность выполнения функции «Создание заказа клиента». Например,

(система должна) Хранить источник получения заказа клиента

Сформировав требование по шаблону мы понимаем, что модифицируем один из шагов инструкции по функции "Создание заказа клиента" где пользователь должен вручную указать в новом реквизите «ИсточникПоступленияЗаказа».

Вернемся к принципиальной картине взаимодействий 5 артефактов. Требование через инструкцию влияет на функцию.

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

Объектом доработки могут являться несколько Требований, объединенных «пакетом» - это контейнер, позволяющий объединить разработку по логическому принципу. Как раз Требования к новому документу (нужна ли ему ТЧ Товары, Доставка, нужна ли ссылка на контрагента и т.д.) и определяют пакет доработок. В идеале – каждый новый реквизит должен иметь прямую ссылку – зачем он вообще был создан. В нашем примере мы придумали добавить новый реквизит «ИсточникПоступленияЗаказа» с типом Строка (для прототы). Именно это единичная доработка и будет объектом Доработки.

Часто для экономии времени аналитики фиксируют Разрыв «Доработки документа Заказ клиента», чтобы в него впихнуть массив доработок и иметь возможность продолжать туда впихивать новую бизнес-логику. Безусловно, данный способ имеет право на существовании, но не в этой Методологии.

Итак, на этапе Моделирования выявлено, допустим 300 «квантов» доработок, то есть 300 Требований с признаком разрыва имеют статус «Согласовано РП», часть из них сформировали Пакеты, чтобы программист реализовывал их как единую доработку.

Workflow разработки

Ниже представлены задачи, обеспечивающие единство ФМ и НиР. Состав можно модифицировать исходя из фактических условий работы. В текущем примере работа Аналитика не ограничена, а часы разработки конечны и должны планироваться

№	Задача для Отв./Пров.	Ответственный	Проверяющий
1	Создать ТЗ / согласовать ТЗ	Аналитик	Функциональный архитектор
2	Оценить выполнение задачу в часах Разработчика	Технический архитектор/Разработчик	Аналитик
3	Отправить ТЗ и оценку Бизнес-заказчику для согласования	Аналитик	Заказчик
4	Назначить разработчика, разместить в бэклогах для ожидания старта	Руководитель проекта	Руководитель проекта
5	Выполнить разработку / протестироваться в тестовых базах	Разработчик	Аналитик
6	Включить доработку в релизный лист	Разработчик	Разработчик
7	Обновить Предпрод базу / Протестировать, подготовить протокол испытаний, обновить инструкцию	Разработчик	Аналитик
8	Обновить продуктивную базу / Провести дымовой тест	Технический архитектор	Аналитик
9	Сдать доработку заказчику	Аналитик	Заказчик
10	План-фактный анализ / Завершение	Руководитель проекта	Руководитель проекта

В данном примере у нас 10 последовательных шагов с 10 парами участников. И в названии задачи почти всегда 2 поручения – Что нужно сделать Ответственному и что после выполнения задачи ответственным должен (до)делать Принимающий. Логика довольно проста.

"Создать ТЗ" - Аналитик создает ТЗ. Как создал пробует «закрыть» этап и задача переходит к проверяющему – Архитектору, который выполняет вторую часть задачи - "согласовать ТЗ" (или вернуть на доработку)

Цель – использовать принцип Конвейера, чтобы все доработки шли к финишу и никто не перескакивал через этапы и каждый участник понимал что от него требуется на текущий момент. Дошла очередь до тебя - выполни, попытайся закрыть и задачу уйдет к следующему.

Обратите внимание, что на 7 этапе перед обновлением продуктивной базы аналитики обязаны протестировать с созданием протокола испытаний и обязательно обновить Инструкцию, так как уже завтра система будет работать по-другому. Протокол тестирования должен подсказать потомкам – а в чем именно была доработка и как система работала до и после. Разумеется Инструкция должны хранить историю, для анализа версий.

Выделяем ключевые принципы этих этапов

Техническое задание, прямо согласованное Заказчиком
Протокол испытаний
Обновленная Инструкция по Функции
Письменная приемка Заказчиком

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

Разумеется, допускается возврат к предыдущим шагам, когда реализация открывает новые возможности или несет угрозы и нужно вернуться к корректировки ТЗ в связи с новыми подробностями.

Почему заказчик должен участвовать на протяжении всего цикла

Во многих проектах взаимодействие с заказчиком заканчивается после согласования технического задания. Далее исполнитель самостоятельно принимает десятки решений.

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

Предлагаемая Методология построена иначе. Заказчик принимает участие практически на каждом этапе.

Он согласовывает техническое решение
Участвует в демонстрациях
Принимает результаты испытаний
Предлагает улучшения
Подтверждает изменения инструкций

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

Главный результат Методологии

Самый важный вывод заключается в следующем. Настройка и разработка не являются отдельным этапом проекта. Этап представляют собой непрерывный процесс развития функциональной модели предприятия

Каждая новая доработка порождает новые требования
Новые требования изменяют функции
Изменение функций приводит к корректировке бизнес-процессов и инструкций
Обновление от Вендора может приводить как к изменению Инструкций так и программированию, вызванным конфликтом кода
Bugfix если он затрагивает пользовательское поведение – идет по аналогичному пути, возможно с меньшими согласованиями

Тут следует заметить, что периодически bugfix вызван выполнением более ранней доработки и является открытым вопросом – вносить ли исправление ТЗ в модифицируемую доработку. С точки зрения Методологии это нужно указать ТЗ и в техническом отчете о реализации доработки.

После этого начинается следующий цикл разработки.

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

Именно этот механизм позволяет сохранять документацию актуальной, вовлекать заказчика в развитие системы и постепенно накапливать знания о предприятии.

Заключение

Традиционный подход рассматривает разработку как процесс создания программного кода. Предлагаемая Методология рассматривает разработку значительно шире.

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

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

ИИ и разработка

Внедрение ИИ в работу обычных пользователей произошла примерно в начале 2026, когда люди стали пробовать искать грибные места. Уже спустя полгода – Вайбкодинг является стандартом. Не исключено, что через полгода – не использовании ИИ станет моветоном.

Данная Методология увязывает весь контекст проекта в единую информационную систему (ОКИС), где собран контекст и все его артефакты связаны и это даже не «смысловая» связь, а «реляционная», то есть весь этот контекст машиночитаем. То есть потенциально ИИ понимает доработку как шаг инструкции со всеми вытекающим последствиями.

ИИ-Агент «Бизнес-аналитик»
Прекрасно понимает всю функциональную модель (сотни процессов, тысячи функций, десятки тысяч особенностей (ФТ) и тысячи доработок. И объем этого контекста благодаря тому, что он сосредоточен в жесткой структуре довольно небольшой – это не десятки гигабайтов файловых архивов, Confluence страниц, канбан трекеров и почтовых клиентов. Уверен, что такую модель может «осознать» локальный ИИ на игровом ноутбуке
ИИ-Агент «Программист-Аналитик»
Уже сейчас ИИ прекрасно справляет с программированием, а если благодаря первому пункту ТЗ на программирование будет обладать исключительной точностью, то и эффективность разработки будет максимальная.
ИИ-Агент «Аналитик-архитектор-Программист»
Многие сейчас используют термин Сингулярность, который пришел из единства времени и пространства. Представьте, в какой-то момент времени функциональная и техническая часть ERP станут сингулярны – и любая модификация будет едина и органичная с программным кодом. Вы буквально будете рисовать новое поле на форме и словами описывает бизнес-логику, а ИИ на лету проверять вас и писать код. Ужас.

Методология описания и внедрения ERP-систем. Часть 2. Настройка и разработка