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

В статье рассмотрим:

1. Что такое цифровой двойник предприятия (ЦДП) и из каких слоёв он состоит.

2. Как бизнес-модель, ИТ-архитектура, мониторинг и аналитика связаны между собой.

3. Как процесс управления бизнес-требованиями запускает изменения в ЦДП.

 

Архитектура ЦДП: четыре ключевых слоя

ЦДП — это динамическая виртуальная модель предприятия, предназначенная для анализа, симуляции и оптимизации его работы. Она позволяет проверять гипотезы и внедрять улучшения, не подвергая риску реальные процессы. Для эффективной работы ЦДП необходимо, чтобы настроенные процессы полностью соответствовали бизнес-модели. К сожалению, не всегда процессы в ИТ-ландшафте соответствуют бизнес-модели. Более того, я встретился в одном проекте с ситуацией, когда комплексный проект с участием нескольких ИТ систем находился в фазе тестирования, а единого сквозного процесса выстроено не было. Бизнес-модель не соответствовала настроенным процессам в ИТ-ландшафте. Кроме правильно выстроенной модели и синхронизации бизнес-модели и ИТ-ландшафта необходимо иметь четкую обратную связь от ИТ-ландшафта, позволяющую оперативно обнаруживать возможные проблемы в работе бизнес-процессов и предупреждать расхождения между бизнес-моделью и ИТ-реализацией. Главным звеном в обратной связи являются системы мониторинга. Аналитика решает ключевую задачу. На основе полученных достоверных данных, производится анализ работы процессов, определяются узкие места в работе предприятия. На основе этого анализа определяются шаги по улучшению работы процессов. Чтобы реализовать эти преимущества, ЦДП необходимо выстраивать как целостную архитектуру, основываясь на требованиях бизнеса.     

Прямые потоки (сверху вниз):

1. Слой 1 → Слой 2: Бизнес-требования преобразуются в ИТ-реализацию

2. Слой 2 → Слой 3: Операционные системы генерируют данные для мониторинга

3. Слой 3 → Слой 4: Агрегированные метрики поступают для анализа

Обратные связи (снизу вверх):

1. Слой 4 → Слой 1: Результаты анализа влияют на развитие бизнес-модели

2. Слой 4 → Слой 2: Рекомендации по оптимизации при настройке процессов

3. Слой 3 → Слой 1: Сигналы о проблемах требуют корректировки бизнес-модели

Слой 1. Бизнес-модель

Это многоуровневый каталог всех бизнес-процессов предприятия, который описывает:

• Цели и ценности компании.

• Организационную структуру.

• Цепочки создания ценности.

• Иерархию процессов (с входами/выходами).

• KPI, регламенты, политики.

Содержит:

• Модели процессов (BPMN, EPC, IDEF).

• Дерево процессов с уникальными ID (BP-ID).

• Матрицы ответственности (RACI).

• Карты потоков создания ценности.

• Business Model Canvas[1].

Слой 2. Реализованная ИТ-архитектура

Это бизнес-модель, воплощенная в «железе» и ПО:

• Технологическая реализация процессов.

• Прикладные системы и их интерфейсы.

• Инфраструктура и платформы.

• Потоки данных, интеграционные шины, API.

Содержит:

• Диаграммы архитектуры (4+1 представление).

• Контракты API (OpenAPI/Swagger).

• Модели данных (ER-диаграммы, JSON Schema).

• Карта интеграций, реестр ИТ-активов (CMDB).

Слой 3. Мониторинг

Слой мониторинга в ЦДП имеет двухуровневую архитектуру:

1. Технический мониторинг — обеспечивает контроль ИТ-ландшафта. Он контролирует доступность и производительность серверов, сетей, баз данных и приложений.

2. Мониторинг бизнес-процессов — обеспечивает контроль бизнес-процессов. Он трансформирует низкоуровневые события технического слоя в бизнес-события: «заказ выполнен», «клиент ушёл с сайта», «нарушено SLA процесса».

Для полноценного анализа все события записываются в журналы в формате JSON Lines.

Слой 4. Аналитика и моделирование

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

Архитектура слоя:

• Диагностика

• Прогноз

• Цифровая песочница и оптимизация

Все слои связаны сквозными идентификаторами. Например, ID бизнес-процесса (BP-ID) присутствует в BPMN-модели, в коде workflow в BPMS, в метрике мониторинга и в дашборде аналитики. Это и есть основа семантической целостности ЦДП.

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

Процесс управления бизнес-требованиями: превращаем идею в план.

Как правило на всех предприятиях имеется четко определенный круг лиц, которые могут инициировать изменение в системе. Инициация изменения производится заполнением формы Запроса на Изменение (ЗНИ- Request for Change (RFC)) и передачей его в работу по процессу. Такой процесс сопряжён с долгим согласованием, а зачастую с необходимостью вначале заручиться утверждением на заседании Комитета по изменениям и в итоге сроки, обозначенные в ЗНИ, начинают сдвигаться вправо. После передачи в работу, исполнителю постоянно напоминают о необходимости ускориться. Это приводит к тому, что исполнитель второпях может сделать ошибки, плохо протестировать изменения и в конце концов, всё это может привести к инциденту при переносе в продуктивную систему выполненного изменения. Прежде чем направлять ЗНИ на утверждение необходимо понимать, что данное изменение целесообразно и возможно, а также представлять, как будет выполняться этот ЗНИ и что это дает компании. Для этого имеется процесс управления бизнес-требованиями.

В итоге процесс изменения в системах разбивается на этапы. Его первый этап — управление бизнес-требованиями (БТ).

Любой сотрудник может предложить идею. Для оптимизации на входе — чат-бот с ИИ, который анализирует инициативу и создаёт заготовку БТ.

Алгоритм процесса

1. Чат-бот создаёт заготовку БТ.

2. Бизнес-аналитик (БА) проводит первичный анализ, уточняет детали с инициатором.

3. БА и архитектор делают высокоуровневую оценку риска/сложности.

4. Выбор пути согласования в зависимости от объёма изменений (определяется стандартом компании).

А) Незначительные изменения 

• Согласование у Владельца продукта + Архитектора.

• Решение: Запрос на исправление в ближайший релиз.

Б) Средний объём изменений

1. БА формирует детальную спецификацию БТ (функционал, мониторинг, аналитика).

2. Проводит рабочую сессию с участием специалистов по мониторингу, аналитике и тестированию.

3. Параллельно запрашиваются оценки у Разработки, Мониторинга, Аналитики.

4. Бизнес-архитектор выполняет оценочную симуляцию для количественного обоснования и выявления рисков.

5. Согласование у Владельца продукта + Ведущего архитектора + Руководителя разработки.

6. Решение: Запрос на изменение → в бэклог.

В) Значительные изменения

1. БА формирует детальную спецификацию.

2. Проводит детальную рабочую сессию.

3. Параллельно запрашиваются оценки.

4. Бизнес-архитектор выполняет оценочную симуляцию.

5. Подготовка материалов для Комитета по изменениям (CAB).

6. Согласование CAB.

7. Решение: Проект или крупный запрос на изменение → в портфель.

Пример процесса:

По завершении процесса управления бизнес-требованиями запускается процесс управления изменениями (различные виды ЗНИ или Проект внедрения)

Итог

Цифровой двойник предприятия — это архитектурный подход и набор практик. Его суть — в синхронизации бизнес-модели, ИТ-ландшафта, мониторинга и аналитики через общие идентификаторы и процессы. Управление изменениями начинается не в Jira или SAP, а в бизнес-модели вашего цифрового двойника. Только так можно избежать хаотичных правок, точечных доработок и добиться согласованной эволюции всего ИТ-организма компании.

Примечания:

1. Business Model Canvas (BMC) — это стратегический шаблон для визуального описания, проектирования и анализа бизнес-модели компании на одной странице.