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