Эволюция цифрового двойника компании: как управлять изменениями в сложном ИТ-ландшафте

Управление изменениями (Change Management): Основа стабильности и контролируемой эволюции.

В современном быстро меняющемся мире необходимо иметь возможность также быстро подстраиваться под изменившиеся условия. Поэтому все внедренные ИТ системы и ИТ услуги не могут оставаться неизменными. ЦДП претерпевает постоянные изменения, и наша задача эти изменения превратить в предсказуемую и безопасную эволюцию, а не революцию с потрясениями, приводящими в бизнесе к потерям. Не многие компании могут продемонстрировать четкий и безопасный процесс управления изменениями, особенно когда в периметре компании имеются самые разные типы архитектуры ИТ решений (Web, микросервисы, монолитные решения). Я столкнулся в своей работе с тем, что каждое направление использует свой процесс изменений не всегда формализованный и построенный на базе какого-либо ИТ решения. Микросервисные ИТ решения как правило используют Jira для регистрации и каким-либо образом управления изменениями, а для управления реализацией и переносом изменения используют DevOps, CI/CD. 1C руководствуются своим процессом. SAP системы имеют свои процессы по управлению и реализации изменений, настроенные в SAP Solution Manager. В итоге наличие такого зоопарка ИТ систем и решений со своими процессами изменений не позволяют производить синхронные изменения, что создает высокие риски для целостности ЦДП. Для стабильной работы ЦДП требуется единая система управления изменениями с особенностями управления переноса изменений из среды разработки в продуктивную среду с обязательной синхронизацией изменения бизнес-модели. В качестве платформы для такой системы можно выбрать BPMSoft. Я просто знаком с этой системой и на мой взгляд она подойдет для этой роли. Кто-то возможно предложит использовать другую платформу, это дело вкуса.

В этой статье:

1.    Типы изменений в процессе управления изменениями (Change Management)

2.    Что такое Задание на разработку

3.    Что такое Релизный контейнер и каких типов он может быть.

4.    Что такое Проект внедрения.

5.    Задание на Экстренное исправление.

6.    Что такое наряд на работу и каких типов он может быть.

Типы изменений

В зависимости от того, что мы хотим изменить и каковы при этом возникают риски для целостности систем и решений, изменения подразделяются на 3 типа:

1.    Стандартное изменение: Предопределенное, низко рискованное, частое. Выполняется по упрощенному процессу. Создается оно из обращения пользователя и не требует дополнительного согласования. Для управления процессом создается документ стандартного изменения.

2.    Обычное изменение: Наиболее частый тип. Требует полного цикла оценки и утверждения.  Для управления процессом изменения создается Задание на разработку (ЗНР), в рамках которого и производится изменение в системе. Создается ЗНР на основе Бизнес-требования.

3.    Экстренное изменение: Требует немедленного внедрения для устранения критического инцидента. Процесс ускорен, достаточно согласования архитектора, но требует последующего ретроспективного анализа. Создается данный вид изменения из инцидента. Для управления процессом изменения создается документ - Задание на экстренное исправление (ЗНСИ).

Что такое Задание на разработку (ЗНР)?

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

Задание на разработку:

1. Имеет установленный формат (утвержденный в стандарте бланк, шаблон).

2. Может инициироваться кем угодно (пользователем, администратором, бизнес-подразделением, руководством) через БТ.

3. Содержит обоснование, анализ и результат моделирования изменения, а не просто пожелание. Имеется в родительском документе — Бизнес-требовании.

4. Имеет уникальный идентификатор, статусы, историю согласований.

Бизнес-процесс ЗНР для небольших, средних и значительных изменений (без создания проекта) может выглядеть следующим образом:

Рис. 1 Процесс Задания на разработку

После согласования БТ для малого, среднего или значительного изменения (без создания проекта) создается одно или несколько ЗНР. Автоматически заполняются поля ЗНР.

• ЗНР создан.

• Квалификация. На этом шаге заполняются все необходимые для работы с документом поля.

• Подготовка ЧТЗ. На этом шаге создается алгоритм выполнения изменения.

• Согласование ЧТЗ. В согласовании участвуют все заинтересованные лица, определенные в стандарте.

• Подготовка документа оценки. В документе определяются ресурсы и стоимость работ.

• Согласования Документа оценки. В согласовании участвуют лица, определенные стандартом. Если уточненная оценка не отличается от предварительной оценки в БТ, производится автоматическое согласование.

• Включение в Релизный контейнер. После всех согласований ЗНР включается в соответствующий Релизный контейнер (Функциональный или календарный).

• Планирование объема. На этом шаге планируется количество нарядов, достаточное для выполнения изменения, которые будут созданы при переключении статуса в положение «В работе».

• В работе. На этом шаге в рамках нарядов производится изменение бизнес-модели (если это требуется), настройка/разработка в ИТ системе для реализации поставленной задачи, производится тестирование каждой отдельной функции, созданной в рамках каждого наряда, проверяется программный код на соответствие нормативам для разработок, проверяется экспертом информационной безопасности, архитектором.

• Приемочное тестирование. Производится приемка функционала с участием инициатора.

• Проверка модели и слияние в ветку тест. Производится проверка модели. Модель должна быть:

  • Валидной (проходить проверку синтаксиса BPMN).

  • Согласованной на уровне команды.

  •  Все изменения зафиксированы через коммиты в системе контроля версий (Git).

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

• Тестирование в составе Релизного контейнера. Производится тестирование всех изменений включенных в Релизный контейнер. Форма тестирования определяется отдельно. По результатам тестирования возможен перенос ЗНР в другой Релизный контейнер.

• Согласование переноса CAB (Консультативный совет по изменениям). CAB на уровне релиза производит согласование переноса изменения в составе релиза в продуктивную систему. CAB может принять решение о переносе каких-то ЗНР в другой Релизный контейнер.

• Импорт в продуктив. Выполняется импорт всех изменений Релизного контейнера в продуктивную среду. В рамках отдельного процесса производится перенос протестированной бизнес-модели в ветку main.

• Приемка ЗНР на сервис. Закрытие ЗНР. Производится передача изменений на сервис и закрываются все финансовые вопросы и документы.

"Релиз" для управления изменениями в цифровом двойнике предприятия

1. Общее понятие релиза

Релиз (Release) — это формализованный, скоординированный и атомарный акт переноса согласованной группы изменений из сред тестирования в предпродуктивные и продуктивные среды одного или нескольких ИТ-ландшафтов, осуществляемый в рамках утвержденного окна времени, с единым планом управления рисками, общей целью достижения нового стабильного состояния и измеримым бизнес-результатом. Как только мы переходим от управления изменениями к управлению релизами, возникает вопрос: как мы будем определять релизную политику. Для каждого БР свой релиз или релиз на Бизнес-систему, а может один релиз на весь ЦДП? По этому поводу у меня были споры с менеджером релизов. Я придерживаюсь мнения, что релизов в определенный период времени должно быть минимальное количество при условии, что они никоим образом не пересекаются. Об этом поговорим отдельно в последующих статьях.

Ключевые характеристики релиза:

1. Требует синхронизации между командами и системами

2. Релиз – это связанные между собой объекты, прошедшие все этапы разработки, тестирования и утверждения, и предназначенные для контролируемого и синхронного переноса по ландшафту от среды разработки до продуктивной среды с гарантией целостности, в рамках Релизного контейнера ЕСУИ.

3. Затрагивает несколько ландшафтов или сред

4. Имеет четкие критерии успеха и метрики

5. Сопровождается формальными процессами контроля и мониторинга

2. Классификация релизов по принципу формирования

Тип 1: функциональный релиз (feature release)

Функциональный релиз — это релиз, сформированный на основе функциональной связности изменений, где группа ЗНР объединена общей бизнес-целью, техническими зависимостями или необходимостью синхронного внедрения для обеспечения работоспособности единой бизнес-функции.

Критерии отнесения к функциональному релизу:

1. Изменения реализуют завершенную бизнес-функцию

2. Нельзя внедрить часть изменений без других

3. Бизнес-ценность достигается только при совместном внедрении

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

Тип 2: календарный релиз

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

Критерии отнесения к календарному релизу:

1. Изменения объединены по времени готовности

2. Экономия на координации развертываний

3. Следует утвержденному графику релизов

4. Все изменения достигли статуса "Ready for Production"

3. Сравнительная таблица типов релизов

Бизнес-процесс Релиза может выглядеть следующим образом:

Рис. 2 Процесс реализации Релизного процесса

Каждый год создается календарь релизов, если планирование производится на год. Если горизонт планирования более года, то каждый год производится актуализация календаря релизов (добавляются новые релизы). После создания календаря релизов релизные контейнеры переводятся в статус Формирование релиза. В этом статусе в контейнер можно включать ЗНР. После того как релиз сформирован, статус переключается в тестирование релиза. На этом статусе производится интеграционное тестирование измененных бизнес-процессов, если необходимо нагрузочное и другие виды тестирования. Если тестирование выявило ошибку, её исправляют или ЗНР, создающие эту ошибку, исключаются из релиза (переносятся в другой релиз, находящийся в статусе «Формирование»). После успешного тестирования идет согласование CAB на перенос релиза в продуктив. После получения разрешения, производится импорт изменений, выполненных в рамках всех ЗНР данного релизного контейнера и релиз закрывается.  

Что такое проект внедрения?

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

Примеры проектов внедрения в контексте бизнес-процессов:

• Проект внедрения BPM‑системы для автоматизации процесса согласования заявок.

• Проект внедрения нового сквозного процесса «Омниканальные продажи» с интеграцией CRM, ERP и кол‑центра.

• Проект внедрения системы KPI и дашбордов для мониторинга ключевых процессов отдела.

Проект внедрения создается из БТ и является его дочерним документом.

Фазы проекта:

ФАЗА 0: ИНИЦИАЦИЯ (ЗАПУСК)

·       Триггер: Формализованное бизнес-требование (БТ) из процесса управления процессами (например, "Необходим новый процесс онбординга клиентов").

·       Ключевые действия:

1.    Анализ осуществимости: Оценка ресурсов, сроков, рисков.

2.    Разработка Устава проекта (Project Charter): Формальное разрешение на начало. Фиксирует:

§  Цели и обоснование (связь с БТ и стратегией).

§  Ключевые требования и ожидания (какой процессный KPI должен улучшиться?).

§  Предварительные рамки (бюджет, сроки, границы).

§  Назначение руководителя проекта.

3.    Идентификация стейкхолдеров: Кто влияет на процесс, кто будет им пользоваться?

·       Выход: Утверждённый Устав проекта. Проект официально стартует.

ФАЗА 1: ПЛАНИРОВАНИЕ

·       Цель: Детализировать КАК будет достигнут результат. Превратить устав в рабочий план.

·       Ключевые действия (процессно-ориентированные):

1.    Планирование содержания: Детальная расшифровка требований (БТ). Создание BPMN-модели "как должно быть" (TO-BE) на высоком уровне с учетом моделирования в БТ.

2.    Планирование сроков: Разбивка работ (WBS) на задачи. Календарный план (дизайн, разработка, тестирование, обучение).

3.    Планирование ресурсов: Кто из бизнес-аналитиков, владельцев процессов, ИТ-специалистов нужен.

4.    Планирование стоимости: Бюджет на доработки систем, обучение, возможные лицензии.

5.    Планирование качества: Какие критерии приёмки нового процесса? (Например, "Все пользователи обучены", "Процесс протестирован на 20 тестовых кейсах").

6.    Планирование изменений и рисков: Что может пойти не так при внедрении нового процесса? План реагирования.

·       Выход: Комплексный план управления проектом, включая план управления содержанием, сроками, рисками и т.д.

ФАЗА 2: ВЫПОЛНЕНИЕ / РЕАЛИЗАЦИЯ

·       Цель: Создать все компоненты нового процесса и подготовить их к работе.

·       Ключевые подфазы и действия:

1. Углублённый дизайн и анализ:

§  Детальное моделирование процесса (BPMN 2.0 на уровне задач).

§  Симуляционное моделирование (DES) для проверки логики и расчёта нагрузок.

§  Разработка регламентов, инструкций, форм документов.

§  Согласование дизайна с бизнес-пользователями.

2.    Разработка и настройка:

§  Конфигурация/доработка ИТ-систем: Настройка workflow в BPM/ERP/CRM, разработка интеграций, доработка интерфейсов.

§  Создание тестовой среды.

3.  Тестирование:

§  Функциональное тестирование: Соответствует ли реализованный процесс BPMN-модели?

§  Выход: полностью готовый к приемочному тестированию бизнес-процесс в тестовой/пилотной среде.

ФАЗА 3: ТЕСТИРОВАНИЕ

·       Приёмочное тестирование: проводят будущие пользователи. Утверждают, что процесс решает их задачу, Бизнес модель переносится в ветку тест или feature/business-model-v2.

·       Выход: полностью готовый к запуску бизнес-процесс в пилотной среде.

ФАЗА 4: ПОДГОТОВКА К ВНЕДРЕНИЮ:

§  Разработка учебных материалов.

§  Обучение пилотной группы и всех пользователей.

§  Коммуникация о грядущих изменениях.

·       Выход: Полностью готовый к запуску бизнес-процесс в пилотной среде, пакет документации и обученные пользователи.

ФАЗА 5: ПЕРЕДАЧА В ОПЫТНО-ПРОМЫШЛЕННУЮ ЭКСПЛУАТАЦИЮ

·       Цель: формально подтвердить достижение проектом обозначенных требований, возможность завершить проект.

·       Ключевые действия:

1.    ПИЛОТНЫЙ ЗАПУСК: Запуск процесса для ограниченной группы или на ограниченном объёме.

2.    ПОЛНОМАСШТАБНЫЙ ЗАПУСК (Go-Live): Включение процесса для всех пользователей.

3.    ПОЛНАЯ ПОДДЕРЖКА: В дни/недели ОПЭ усиленная поддержка для решения "детских болезней".

·       Выход: Новый бизнес-процесс в опытно-промышленной эксплуатации.

ФАЗА 6: ЗАВЕРШЕНИЕ И ПЕРЕДАЧА В ЭКСПЛУАТАЦИЮ

·       Цель: формально завершить проект, передав результат в операционную деятельность.

·       Ключевые действия:

1.    Финальная передача:

§  Настройка и запуск мониторинга: Дашборды, KPI, алерты, Перенос бизнес-модели в ветку main.

§  Передача документации владельцу процесса и в службу поддержки.

§  Подписание Акта приёма-передачи.

2.    Завершение административное:

§  Закрытие контрактов (если были внешние подрядчики).

§  Архивация проектной документации.

§  Формальный роспуск проектной команды.

Выход: Новый бизнес-процесс в промышленной эксплуатации, полный пакет закрывающих документов, официально закрытый проект.

На всем протяжении работы проекта производится мониторинг и контроль. Изменение Бизнес-модели производится по отдельному процессу, который интегрирован с процессом управления проектами.

В Agile проектах мониторинг и контроль производится каждый раз после очередного инкремента продукта.

• ·       Цель: Следить за выполнением плана, вносить корректировки, управлять рисками.

• ·       Действия на протяжении всего проекта:

  • Сравнение фактических сроков и затрат с плановыми.

  • Управление изменениями требований (Change Control).

  • Отслеживание и обработка рисков.

  • Регулярная отчётность перед стейкхолдерами.

  • Регулярное совместно с переносом инкрементов перенос бизнес-модели в ветку main.

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

Рис. 3 Общий процесс управления изменениями.

Что такое Задание на срочное исправление (ЗНСИ)?

Задание на срочное исправление (ЗНСИ) — это документ, создаваемый на основе критического инцидента для оперативного устранения сбоя или уязвимости в обход стандартного цикла планирования. Оно имеет свою приоритезацию, статусную схему, упрощённый процесс согласования и обязательную последующую ретроспективу для анализа корневых причин и предотвращения повторения инцидентов. ЗНСИ создается из инцидента как последующий документ. После его создания эксперт анализирует, описывает требуемые срочные изменения и передает на утверждение Архитектору. Архитектор утверждает задание и планирует объем (количество нарядов на работы) и передает в работу. После реализации исправления производится документирование выполненных изменений и при необходимости производится актуализация бизнес-модели. Документирование можно производить на уровне наряда, но в этом случае все документы должны быть доступны в ЗНСИ и иметь ссылки в бизнес-модели.

Рис. 4 Процесс управления срочными изменениями.

Введение в Наряды

Всё, что мы описали выше, управляется на уровне заданий (ЗНР) и релизов. Но как контролируется каждая конкретная задача внутри? Для этого в нашей системе существует Наряд — атомарный документ на выполнение одной работы.

• Именно в рамках Наряда разработчик вносит код, конфигуратор настраивает систему, а администратор создаёт роль.

• Наряды бывают четырёх типов, адаптированных под разные задачи: для плановой разработки, для срочных исправлений, для административных действий и для управления доступом.

• Ключевой принцип: все наряды проходят чёткий цикл контроля (разработка → проверка → тестирование), а их готовые результаты становятся «строительными блоками» для Релизного контейнера.

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