Введение

Большинство проектов внедрения и сопровождения ERP‑систем сталкиваются с одной и той же проблемой: отсутствием единой методологии описания системы.

Обычно обсуждают инструменты хранения информации — Microsoft Word, Excel, Confluence, Wiki, BPMN, Draw.io. Отдельные вопросы Windows/Mac, в офисе или на удаленке и так далее.

Но практически не обсуждается главный вопрос:

Как именно необходимо описывать ERP‑систему?

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

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

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

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

Работая в множестве Франчайзи 1С мне ни разу не объясняли в чем же задача аналитика, поэтому возможно кому‑то будет полезно структурировать эту информацию. Разумеется, можно комментировать и подвергать сомнению или делиться своим опытом.

В текущем тексте я ни разу не упомяну софт‑скилы «отвага, находчивость, стрессоустойчивость». Буду говорить только о хард‑скилах — умениях и, к счастью, большая часть умений — довольно простая и механическая.

Пять базовых артефактов ERP‑системы

Любую корпоративную ERP‑систему можно описать через пять взаимосвязанных сущностей. На языке баз данных — это таблицы (справочники или документы), которые хранят экземпляр знаний.

Функция

Функция — минимальная законченная операция пользователя в информационной системе, имеющая самостоятельную бизнес‑ценность. Фактически это скелет функциональной модели. Точнее модель названа в ее честь — «Модель Функций». Хотя если выполнять данную методологию, то ее следует называть «Бизнес‑процессная функциональная модель». ИИ придумал новый термин ОКИС — операционная карта информационной системы.

Функции игры в Сапер

• Установка сложности (выбираем Новичок, любитель, профессионал).

• Проверка ячейки левой клавишей мыши

• Установка мины правой клавишей мыши

• Снятие мины правой клавишей мыши

• Открытие всех неустановленных ячеек нажатием двух клавиш мыши (когда открываются все ячейки периметра, если найдены все мины)

• Начало новой игры

• Завершение игры победой• Завершение игры поражением

8 функций у Сапера, а что 1С ERP?

Функция — это буквально user story

Примеры ERP:

Создание заказа клиента
Создание поступления товаров
Создание платежного поручения
Установка статуса Согласован в Заказе клиента

Функция отвечает на вопрос:

Что именно хочет сделать пользователь в текущей задаче над объектом метаданных?

Именно функция является основной единицей функционального моделирования.

В самой обычной ERP системе количество функций спокойно достигает 700 и более и да — все эти функции выполняют пользователи, не задумываясь — «о как их много», ведь каждый из них имеет дело с десятком, а команда вынуждена «держать в голове» общую картинку гигантской шахматной доски.

Часть функций фактически не выполняются реальными пользователями, а, например, регламентным заданием (получение и отправка писем) или импортом (Создание заказа клиента импортом из CRM), но все же это единичное и законченное действие условного пользователя над отдельными объектами метаданных, предполагая их модификацию. Например, нет функции «Посмотреть заказ клиента». Ведь нет бизнес‑цели и не происходит модификация.

2. Бизнес‑процесс

Бизнес‑процесс представляет собой последовательность функций (и событий), выполняемых для достижения определенного результата.

Процессы игры Сапер

Управление игрой (выбор сложности, начать с начала)
Игра (все функции по нажатию)

Пример ERP:

Продажа продукции
Управление данным клиентов
Управление тендерами

Бизнес‑процесс имеет 2 задачи — как‑то логически упорядочить сотни функций, а иногда и указать их последовательность — что перед получением денег от клиента желательно ему что‑то отгрузить.

Например, процесс Управление данными клиентов будет содержать все функции — от создания контрагентов, договоров, соглашений, товарных матриц и так далее. Главное — чтобы конечный пользовать нашел нужные функции по логической структуре процессов. В среднем ERP производство содержит 110–120 логических процесса, в которых упомянуты те самые 700 пользовательских функций.

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

3. Инструкция

Инструкция описывает способ выполнения функции. Она содержит: • последовательность действий пользователя

• особенности заполнения реквизитов

• возможные ошибки

• рекомендации по работе

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

Инструкция отвечает на вопрос:

Как правильно выполнить функцию?

Важно понимать, что инструкции не должны описывать весь процесс целиком — только отдельную функцию. Отсюда правило если у вас 1 функция — то должна быть минимум 1 инструкция (хотя бывает и больше, например, если у вас холдинг и внутри ERP живет 2 организации, то инструкция по созданию контрагента для Производства и для транспортной компании могут отличаться и на 1 функцию будет 2 актуальных инструкции

4.Объект метаданных

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

• документы;

o Заказ клиента

o Реализация товаров и услуг ‑

Для сапера скорее всего будет 1 рабочая таблица — она видимо будет генерироваться автоматически при начале игры и указывать, что в ячейке А1 — мина.

При этом, таблицы с накоплениями (такие как Продажи) нам не нужны — это технический уровень, для функционального моделирования он не интересен.

Также интересны некоторые Планы видов характеристик и регистры сведений, которые по сути своей являются справочникам.

Объект метаданных отвечает на вопрос:

Какие элементы ERP используются (модифицируют/создаются) при выполнении функции?

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

5. Требование

Требование фиксирует необходимость изменения существующей функциональности или создания новой, а также функциональные развилки, которые дает вендор. В рамках данной статьи следует выделить несколько видов требований

• Функциональное требование (требование к наличию функции системы) • Нефункциональное требование (требование к качеству, производительности, красоте)

• Бизнес‑требование (верхнеуровневые требования, например, система должна уметь начислять амортизацию)

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

И объект метаданных становится очень наглядным «навигатором», который позволяет очень быстро найти нужную функцию или требование

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

Любое требование должно отвечать минимум на два вопроса:

Какую функцию и объекты метаданных она затрагивает?

Общая схема зависимостей 5 артефактов

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

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

Как обычно исследуют системы

На традиционных проектах команда аналитиков обычно придерживается следующего алгоритма работы (хотя он и не проговаривается, так как считается, что это органически‑логично). Тут опишу тот плохой опыт, который сам видел.

Аналитик выявляет бизнес‑процесс на интервью и начинает его исследование.
При проработке процесса как правило не выделаются Функции как последовательные шаги, а зачастую анализируются Объекты метаданных и дается их полное визуальное описание
Выявляются дополнительные доработки к объектам метаданных

И очень часто получается следующая картина «Процесс Заказ клиента. »

Вот так выглядит карточка Заказа клиента. Реквизиты дата и номер показывают дату и номер, далее заполняется статус, далее указывается контрагент, заполняется ТЧ товары, при необходимости указываются параметры доставки. Если нужно — то можно поставить нужные товары к отгрузке»

Все это снабжается картинками и почти готово — Функциональная модель написана на 500 страницах.

Давайте разберем то, что лично мне кажется нелогичным.

Во‑первых, бизнес‑процесс «Заказ клиента». Заказ клиента не является Бизнес‑процессом — это Объект метаданных системы. Очень часто аналитикам сложно идентифицировать бизнес‑процессы, так как это слишком широкое определение. Поэтому выше я перечислил 5 артефактов Методологии и дал им исчерпывающее описание. Заказ Клиента может быть Бизнес‑процессом в какой‑то то другой методологии, но все‑таки нужно описать — какие артефакты в ней есть и как их нужно отделять друг от друга.

Неправильно (неоптимально) определив бизнес‑процесс как Заказ клиента, аналитик описывает то, что считает Инструкцией — визуальную форму Заказа клиента и все доступные реквизиты. И часто описывает переключатель статусов. Теперь представим, что пользователь создает заказ клиента и читает это повествование:

так какой статус он должен поставить?
Какой вариант обеспечения выбрать
Нужно ли заполнять соглашение?
Нужно ли указывать доставку?

То есть, описание Бизнес‑процесса Заказ клиента не является инструкцией для пользователя — это еще одна «справка f1» по форме, где нужно разбираться и надеяться, что пользователь имеет опыт работы с 1С и сам догадается.

Далее аналитик скорее всего выявит настоящий бизнес‑процесс Продажи, где заполнение Заказа клиента будет 1 шагом и столкнется с дилеммой — у него уже есть бизнес‑процесс Заказ клиента, где описан внешний вид Заказа клиента и как нужно поступить при описании бизнес‑процесса Продажи? Просто сослаться на другой процесс гиперссылкой или увеличить объем документации и просто скопировать текст?

В итоге полученный тысяча‑страничный документ практически не имеет жесткой структуры — ведь его делали не менее 4 аналитиков и каждый описал свое видение. Разумеется, для этих целей есть их надежный помощник, который все исправит — функциональный архитектор, который должен все переписать и попытаться все‑таки выявить структуру.

А теперь представьте, такой документ получает Заказчик после окончания проекта. Какова его судьба? Будет ли кто‑то из аналитиков заказчика пытаться его корректировать? Нет. Ситуация повторится, и новая команда будет заново пытаться нарисовать функциональную модель, выбирая инструмент, а не методологию.

Это и делает проекты по внедрению ERP такими сложными и дорогим и все из‑за отсутствия сформулированных правил.

1С ТКВ (технология корпоративного внедрения) также не отвечает на вопрос о артефактах функционального моделирования, а дает общий вектор — какие виды документов следует делать.

Последовательность обследования и внедрения ERP‑системы, которую я заложил в Методологии

С легкой руки ассистента по написанию статьи ИИ назвал это «Методология Ермолаева», так как вероятно есть другие методологии и нужно от них обособиться.

Во‑первых, следует разделить технологию выполнения проекта и технологию выполнения функционального моделирования. С технологией выполнения проекта все понятно и разногласий нет, есть вариации, но общий контур понятен

Предпроектное исследование (as is)
Функциональное моделирование (to be)
Настройка и разработка
Подготовка к ОПЭ
ОПЭ

Сейчас мы будем говорить про 1 и 2 этап — исследование информационной системы исторической и новой, но никто не запрещает исследовать существующую систему без цели внедрения. Обычно любой проект внедрения начинается с интервью и это очень дорогостоящая пустая трата времени (с точки зрения Методологии — вы увидите это позже).

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

Шаг 1. Выявить задействованные Объекты метаданных анализируемой системы

Получаем программным путем полные списки Документов и Справочников хотя бы с 1 созданным элементом, например, за последний год. Видим там знакомые Заказы клиентов, РТУ, Номенклатура и так далее. Значит пользователи их используют. Это хорошо и не надо об этом спрашивать.

В среднем на проекте может быть задействовано порядка 150 видов документов и 100 видов справочников. При этом в ERP 709 вида документа и 1072 справочника. И это совсем не похоже на Сапер. Вот истинная глубина и сложность этих монстров и каждое предприятие использует только небольшую часть документов и справочников, не говоря про общий объем бизнес‑логики, заложенной в программу — она просто не поддается представлению.

Шаг 2. Выявить Функции задействованных объектов метаданных

Логика тут простая и ее можно автоматизировать

Каждый созданный объект метаданных был кем‑то создан (предопределенные пока отбрасываем), значит была как минимум 1 функция «создание… заказа клиента», «создание номенклатуры»
Если у документа есть статусная модель (как у заказа клиента) очевидно, что пользователь создавал их в начальном статусе, а потом кто‑то повышал его и это тоже единичная функция системы
Если у документа есть табличная часть Товары, то кто‑то отдельно мог зарезервировать, поставить в отгрузку и это тоже функции — так как обладают их характерными признаками — обособленное осмысленное действие пользователя.
Есть еще несколько стабильных формул, выявления функций

Итак, мы определили перечень возможных пользовательских функций системы и в среднем на ERP проектах 500–700 функций, то есть пользователи могут сделать 500–700 видов воздействия над системой.

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

На этом этапе можно потерять интерес к Методологии — слишком много функции, слишком сложно, слишком много правил. Позвольте, но вы взялись за внедрение ERP системы и бюджет таких проектов десятки, а иногда сотни миллионов рублей и от непроработанного процесса может просто остановиться производство!

Давайте сравним это с нотной грамотой — если ли «простая методология описания музыки» — если не хочется изучать нотную грамоту? Либо с помощью нот, либо «парам‑пам‑пам‑пам‑пара‑пара‑парам‑па‑рам‑па‑па» (кстати я записывал реальную мелодию, но теперь не могу понять — что я пел).

Шаг 3. Собрать функции в бизнес‑процессы

На этом этапе нам все еще не нужны интервью с заказчиками, которые бы сказали, что для Продажи нужно сначала создать Заказ клиента. Мы это знаем.

А вот что действительно нужно — это опыт прошлых проектов и структура Бизнес‑процессов для данного вида предприятий. Как сказано выше — задача Бизнес‑процесса объединить логические функции для удобства навигации. И в среднем мы используем 100 бизнес‑процессов для объединения 700 функций.

При этом каждая функция обязательно должна войти в бизнес‑процесс. Это часть «автобалансировки» — вы не сможете упустить что‑то если зацепили это Методологией. Например, пользователи активно создают документ «Доход в натуральной форме». У вас уже есть это как Объект метаданных и есть функция «Создание Доход в натуральной форме». И обязательно нужно разобраться (если нужно на интервью) — а что это и в какой процесс входит?

Еще один лайфхак по бизнес‑процессам. Отчетливо выделяются 2 типа процессов

Последовательные процессы — где наблюдается четкая очередность шагов
- Продажи
  - Создание Заказа клиента
  - Создание РТУ
  - Создание СФ
Непоследовательные процессы — где не наблюдается четкая последовательность шагов
- Управление событиями ОС
  - Приобретение ОС
  - Изменение срока ПИ
  - Вывод из эксплуатации
- Управление данными клиентов
  - Создание контрагента
  - Создание договора
  - Создание соглашения

То есть в непоследовательном процессе вы не выполняете все 3 шага каждый раз, он является логическим контейнером, который говорит «во мне все возможные манипуляции с клиентскими данными». Такие процессы рекомендуется начинать с слова «Управление»

Последовательные же процессы — идеальные кандидаты для отрисовки BPMN схем.

Шаг 4. Валидация бизнес‑процессов заказчиков

Вот тут можно и начинать интервью, и буквально познакомить заказчика с его примерно 100 бизнес‑процессами, узнав некоторые подробности о них, кто за них отвечает и может быть есть дополнительные функции, которые важны в проекте, но выполняются не в 1С, а excel и других системах.

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

Шаг 5. Подготовка целевой системы

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

Шаг 6. Создание «статичных справочников» для тестирования, подготовка инструкций

Все справочники делятся на статичные и динамичные

Статичные — создание новых элементов крайне редкое (организация, склады) и как правило в «управляющих» процессах
Динамичные — создание новых элементов является рутиной (контрагенты, номенклатура, договоры) и как правило в последовательных бизнес‑процессах

Так как мы на этапе «Моделирования», то нам нужны статичные справочники в неполном объеме для моделирования. В продуктивную базу в дальнейшем будет загружена эталонная структура, поэтому не тратим много время и берем структуру статичных справочников из исторической системы.

Обязательно при первом создании экземпляров справочников формируем инструкции по каждой функции: Создание Организация, Создание Склад и так далее

Шаг 7. Создание «динамичных справочников» для тестирования, подготовка инструкций

Аналогично предыдущему шагу создаем набор НСИ для моделирования. Обязательно при первом создании экземпляров справочников формируем инструкции по каждой функции. Уже на этом этапе вы должны покрыть инструкциями порядка 170 функции 100 справочников — это можно сделать за первую неделю проекта.

Шаг 8. Создание инструкции по функции, регистрация требований

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

В целом у инструкции несколько задач

Выявить функциональные требования (особенности выполнения функции)
Показать коллегам аналитикам и архитектором ваше проектное решение по функции, чтобы они понимали без звонка. Еще раз — у вас тут 700 функций и команда до 10 человек, нет такой головы, чтобы помнила обо всем
Доказать, что аналитик выполнил работу по моделированию и решил все вопросы
Основа для обучения на этапе ОПЭ
На основании инструкции можно создать автотест
…… куча других причин
Возможно, кто‑то из пользователей в будущем посмотрит.

«Естественную» пользу Инструкции, что ее использует будущий пользователь для работы я намеренно поставил на самое последнее место по значимости. Самые важные — это первые 3 пункта Уже создавая тестовые статические справочники (например, организация), нужно создавать инструкции. Что за глупость — зачем создавать инструкцию по созданию Организации, ведь никто больше не будет создавать их в будущем? Верно, но у нас цель — собрать требования — особенности выполнения функции. И создание инструкции по Организации приведет вас к необходимости заполнить учетную политику. Чуть подробнее разберем самый очевидный кейс — создание Договора, хотя все знают — как создавать договоры. Зачем вообще нужна инструкция?

Но при создании тестового договора (то есть моделирование функции «Создание договора закупки») система начинает уточнять нюансы шага инструкции

Детализация расчетов — нужно выбрать из 5 вариантов
Порядок зачета оплат и накладных — выбор из 4 вариантов
Фиксировать ли сумму договора (да/нет)
Разрешать ли работу с дочерними партнерами (да/нет)
Налогообложение НДС (3 варианта) и так далее

На этом этапе вы получаете чудовищную вариативность 5 х 4 х 2 х 2 х 3 = 240 вариантов как пользователь может натыкать!!! И каждый раз система использует эти поля для бизнес‑логики и все будут удивляться — что за глючная 1С — делает неправильную обработку разных договоров!

Я это называю «функциональная развилка ERP», то есть вложенный алгоритм позволяет разным клиентам использовать разные механизмы конфигурации и ключевая задача аналитика понять — что нужно именно данному клиенту, внедряющему ERP — НАЙТИ ФОРВАТЕР!

И тут методика простая — на все выявленные функциональные развилки при выполнении функции и создании инструкции создавать Требование с типом «Функциональное». И среднее количество требований по развилкам — не менее 500.

То есть нужно зарегистрировать 500 требований и пока мы не говорим про gap — доработки системы. к этому мы еще даже не подошли. Поэтому, к шагу Инструкции «Укажите в детализации расчетов» — «?» мы должны создать требование и правильно его сформулировать.

Тут методология тоже проста и понятна — формируйте по следующей конструкции {система должна} {действие в командном виде}{пояснение} Получаем наименование требования

Детализировать расчеты с поставщиками по схеме Аванс по заказам долг по накладным

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

Фактически вы снижаете вариативность до 1 единственного правильного варианта — вот именно так и нужно создавать договоры, а не гуглить в интернете.

И черт подери — вы выбрали «Налоговый агент по НДС» и система вас просит еще указать «Вид договора налогового агента» — придется еще одно требование регистрировать и согласовывать.

Но на выходе у вас — ровно 1 инструкция и система будет использовать согласованную бизнес‑логику, а не хаотично выполнять операции, которые ей и поручили пользователи, когда тыкали наугад.

Шаг с инструкциями самый объемный и это основные трудозатраты команды, а вы хотели это пропустить.

Шаг 9. Проведение демонстрации функций и согласование требований с клиентом

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

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

Шаг 10. Согласование требований с архитектором

Требования, согласованные с заказчиком, должны попасть к Архитектору, чтобы он

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

Часто компании вынуждены иметь «Архитектора» на каждом блоке ERP: Продажи, закупки и так далее. Обычно же Интеграторы укрупняют до Архитектор Оперконтур, Архитектор Финконтур. Это выгоднее как минимум по зарплате. Вместо 12 архитекторов на архитекторской зарплате вы получаете 2 архитекторов на архитекторской зарплате. Плюс Архитектор Оперконтура действительно знает о всех требованиях Оперконтура и может видеть противоречия.

Шаг 11. Согласование требований с РП

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

Шаг 12. Выявление доработок, согласование

Параллельно с демонстрацией заказчик может предлагать модификацию: новые реквизиты или бизнес‑поведение. Это также является функциональным требованием и также должна формулироваться как «система должна делать».

При этом аналитик должен сформировать «дизайн разрыва», где описать на понятном языке как планируется его реализация: создание нового реквизита на форме, изменение алгоритма и так далее.

Аналогично происходит согласование с архитектором и руководителем проекта. При этом техническое задание на этом этапе можно не делать, так как мы находимся на этапе Функционального моделирования и наша задача — собрать пул будущих доработок

Шаг 13. Итоговое согласование реестра бизнес‑процессов, функций и требований

Финализируем будущие процессы и функции, чтобы заказчик смог подтвердить — да, все возможные ситуации учтены, а не только самые очевидные. В наших проектах мы даже фиксируем вид документа «Операция», его функцию «Создание операции», но дописываем к названию «Создание операции ЗАПРЕЩЕНО», чтобы если кто‑то нашел лайфхак — как менять данные на ОСВ за 5 секунд был остановлен на самом начале пути.

Отдельно согласуем требования без доработки и требования с доработками с дизайном разрыва.

Вспомогательные артефакты

Проект

Глобальный разделитель данных. Описание As Is мы ведем на одном проекта, а To Be на другом, обеспечивая сравнимость данных и не смешивая исследуемую и внедряемую систему

Топик

Функциональные разделы Информационной системы. Более подробно в блоке Слой.

Слой

Крайне важный разделитель функций. Основной слой учета как правило — это «ОУ» — операционный учет. Слой операций. Другие интересные слои — планирование, бюджетирование, БНУ (бухгалтерский и налоговый учет). Обратите внимание, БНУ не является функциональным разделом, а является слоем, так как если вам не нужно запускать бухучет в ERP, то вы просто выключаете «слой», а все функциональные области (топики) у вас остаются, ведь расчет себестоимости вы все равно будете делать, и он будет в Оперативном слое

Также слоями являются отдельные интеграции. Функция «Выгрузка заказов клиента на сайт» является функцией слоя «ERP <> Сайт». Таким образом, можно быстро найти все интеграционные взаимодействия информационных систем и, например, выделить их в отдельный бизнес‑процесс «Управление интеграциями ERP <> Сайт», используя как навигационный контейнер.

Проектный документ

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

Профиль пользователя

Указывается в функции и отвечает на вопрос «Кто может выполнять эту функцию».

Организация

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

Графические схемы

Позволяют визуализировать

• Бизнес‑процесс

• Функцию

• Требования

• Любую другую информацию, которую хочется держать «под рукой»

Backlogs

Фактически название очередей внедрения функций

Заказчики

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

Окончание первого этапа Моделирования

Главная задача аналитика заключается не в написании большого количества документов, а в построении целостной модели информационной системы. 5 артефактов позволяют обеспечить их полноту, а дополнительные разрезы — позволяют их упорядочить. Если каждая функция связана с процессами, инструкциями, объектами метаданных и требованиями, документация перестает быть набором разрозненных файлов и превращается в единое пространство знаний о предприятии.

Такой подход позволяет поддерживать актуальность описания системы, быстро оценивать влияние изменений и существенно снижать стоимость сопровождения ERP‑систем на протяжении всего их жизненного цикла. Более того по окончанию жизни ИС у вас полностью задокументированная схема процессов и функций и уже эта некогда «новая» ИС становится «исторической» и на ее основании сильно проще внедрять что‑то новое.

Перечислим состав ОКИС (операционная карта информационной системы)

Историческая Система
1. Перечень бизнес‑процессов и функций As Is
  1. Отрисовка Процессов без слова «Управление»
2. Схема интеграционных взаимодействий
3. Схема НСИ и документов к переносу
Внедряемая система
1. Перечень бизнес‑процессов и функций To Be
  1. Отрисовка Процессов без слова «Управление»
2. Инструкции по всем функциям To Be с ссылками на требованиями с согласованными функциональными развилками и доработками
3. Ролевая модель функций
4. Реестры требований в статусе Согласовано РП по функциональным развилкам
5. Реестры требований в статусе Согласовано РП по функциональным разрывам с описанным дизайном разрыва
6. Концепция интеграций
7. Концепция переноса начальных данных
Протоколы встреч

Как правило формируется первая версия ОКИС и команда идет дальше. Впереди еще несколько версий этого документа, поэтому не нужно относится к нему на этом этапе слишком серьезно. Вы будете не редактировать этот документ, а выпускать новые версии

Использование ИИ в моделировании

Мой ИИ помощник попросил раскрыть — а чем именно он может помочь в Моделировании. Вопрос хороший. Давайте посмотрим по каждому шагу

Выявить используемые объекты метаданных — никак.
Тут программная обработка довольно тупо перебирает виды объектов метаданных и считает количество элементов.
Выявить функции объектов метаданных
Тут есть потенциал, в случае если Интегратор накопил массу проектов по этой Методологии и в этом случае функции генерируются не по простым алгоритмам (чего не всегда достаточно), а берутся из других проектов. Такой опыт был и вполне возможно, что в следующем году это будет полностью отдано ИИ.
Собрать функции в процессы
Аналогично предыдущему шагу — при наличии базы данных других проектов упаковка функций в процесс можно полностью отдать ИИ
Валидация бизнес‑процессов
Пока этим занимаются люди в ходе интервью
Подготовка целевой системы, 6,7 (создание справочников), 8 (создание инструкций)
В моих текущих задачах есть цель по полной сборке целевой системы средствами 1С Тестировщик, а вот сценарии для него может готовить ИИ, поэтому кейс реален и я думаю в 28 году это будет стандартом.
9 Проведение демонстраций, 10 — согласование требований с ФА, 11 согласование требований с РП
Оставим людям. Но возможно привлечь ИИ для оценки влияния требования. Вдруг какую‑то потенциальную опасности несет и тогда архитектор будет привлекать ИИ и спрашивать: «что думаешь, Иван Иваныч?»
12.Выявление доработок

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

13 — Итоговое согласования

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

Преимущества Методологии

Наименование	Описание	Результат
Высокая полнота функционального обследования	Методология начинается с анализа существующей информационной системы, а не с интервью. Благодаря этому автоматически выявляются используемые объекты метаданных и связанные с ними функции. Это снижает вероятность пропуска функциональности, поскольку каждая найденная функция должна войти хотя бы в один бизнес‑процесс.	Снижается риск того, что часть используемой функциональности останется неописанной.
Высокая скорость обследования	Значительная часть исходной информации извлекается автоматически из информационной системы. Аналитик начинает работу не с чистого листа, а с уже сформированной заготовки функциональной модели. Плюс есть данные других аналогичных проектов.	Существенно сокращается объем ручной работы и количество интервью.
Проверка полноты модели	Методология содержит внутренние механизмы контроля	Модель становится самопроверяемой
Единая структура знаний	Все сведения о системе описываются через ограниченный набор взаимосвязанных артефактов. Это позволяет избежать ситуации, когда разные аналитики описывают одну и ту же систему по‑разному	Документация становится единообразной независимо от исполнителя.
Трассируемость изменений	Любое изменение можно проследить	Становится проще оценивать влияние изменений на систему
Масштабируемость	После формирования библиотеки функций и процессов они могут использоваться повторно на новых проектах аналогичного профиля. С каждым новым проектом объем повторного использования знаний увеличивается.	Трудоемкость последующих проектов постепенно снижается.
Независимость от программного продукта	Методология описывает структуру знаний, а не особенности конкретной ERP. Она может применяться к различным корпоративным системам при наличии пользовательского интерфейса и объектов предметной области	Единый подход можно использовать для различных информационных систем, в т.ч. web‑приложений
Поддержка полного жизненного цикла	Модель не заканчивается после обследования. Она используется: • при разработке; • тестировании; • подготовке инструкций; • обучении пользователей; • сопровождении; • развитии системы.	Знания не теряются после завершения проекта внедрения.
Готовность к автоматизации и использованию ИИ	Все знания представлены в виде формализованных сущностей и связей между ними. Это делает модель пригодной для машинной обработки, интеллектуального поиска, автоматического анализа влияния изменений и использования ИИ‑ассистентов.	Модель становится не только документацией для людей, но и базой знаний для программных инструментов.
Методология снижает зависимость проекта от конкретных специалистов	На многих ERP‑проектах знания о системе распределены между отдельными аналитиками, архитекторами и разработчиками. При смене команды значительная часть этих знаний теряется, и обследование приходится проводить заново. Формализованная функциональная модель превращает знания отдельных специалистов в знания организации.	Предприятие становится владельцем своей модели, а не зависит от памяти конкретных участников проекта.

Методология описания и внедрения ERP‑систем или как перейти на 1C ERP быстро, качественно, дешево