Использование референтных моделей для построения процесса управления изменениями

Правильность построения процесса управления изменениями может быть обеспечена, как уже сказано, использованием библиотеки ITIL, но детальное описание процесса с указанием бизнес-ролей и информации по нему библиотека не содержит. В данной работе, мы рассмотрим референтную модель компании IDS Scheer — ARIS ITIL Reference Model, которая помимо моделей процесса содержит основные данные, использующиеся при управлении изменениями.

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

Необходимо также использовать отдельный сценарий для срочных изменений, который предусматривает следующие действия:

· Специальное совещание (возможно, телефонная конференция по утверждению изменения).

· Принятие решения владельцем процесса.

· Упрощенное согласование изменения.

· Минимальное документирование изменения на этапе выполнения.

· Максимальный ресурс проектных групп.

· Последующее документирование.

· Формализованное понятие срочного изменения и определенный механизм принятия решения для его активизации.

В соответствии с данной схемой можно привести основные активности, специфические для процесса Управления изменениями:

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

2. Составляем модель «как есть» процесса.

3. Определяем категории изменений.

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

5. Принимаем решение по системе автоматизации процесса – в частности, будет ли система, автоматизирующая жизненный цикл прохождения изменения, интегрирована с CMDB или нет.

6. Определяем границы процесса, проводим разделение с процессами Управления релизами, разработки, закупок и т.п. Документируем процесс (модель «как будет»), составляем требования к отчетности по процессу.

7. Разработку, развертывание, тестирование системы привязываем по срокам к аналогичным активностям по Управлению конфигурациями.