Планирование Внедрения. Управление изменениями, активами и конфигурациями в рамках Внедрения

8.2. Управление изменениями

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

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

Управление изменениями охватывает изменения в основных активах услуг и конфигурационных единицах в течение всего жизненного цикла услуг.

Управление изменениями необходимо по следующим причинам:

1. оптимизация рисков;
2. минимизация негативного влияния на бизнес со стороны ошибок и сбоев;
3. успешная реализация изменений с первой попытки.

Основными целями Управления изменениями является обеспечение:

• использования стандартных методов и процедур для быстрой и эффективной реализации изменений;
• фиксации всех изменений в активах услуг и конфигурациях в Системе Управления конфигурациями (CMS);
• оптимизации всех рисков для бизнеса.

На рис. 8.2 представлен охват процесса Управления изменениями.

увеличить изображение
Рис. 8.2. Охват Управления изменениями

Стратегические изменения поступают с этапа Построения стратегии или от процессов управления бизнес-отношениями. Тактические изменения услуг поступают от этапа Проектирования, Непрерывного улучшения услуг и от процессов управления на уровне услуг. Корректирующие изменения, исправление ошибок в существующих услугах - от этапа Эксплуатации.

Управление изменениями представляет ценность для бизнеса тем, что:

1. категорирует цели изменений бизнеса и заказчиков и помогает их осуществить;
2. реализует изменения, которые соответствуют потребностям заказчиков, одновременно с оптимизацией затрат;
3. старается выполнять требования закона, контрактов, руководства и регуляторов;
4. уменьшает количество неудавшихся изменений и, соответственно, количество сбоев, остановок и простоев услуг;
5. осуществляет изменения в установленном бизнесом временном интервале;
6. следит за изменениями на всем жизненном цикле услуг;
7. старается обеспечить лучшие показатели в аспектах качества, времени и затрат;
8. оценивает риски, сопутствующие внедрению;
9. помогает увеличить продуктивность работы персонала тем, что минимизирует нарушения и сбои, а, следовательно, улучшает доступность услуг;
10. уменьшает Среднее время восстановления услуг (MTRS) посредством быстрой и успешной реализации изменений;
11. сотрудничает с процессом изменения бизнеса для выявления возможностей улучшения бизнеса.

Хорошо структурированные и запланированные изменения помогают бизнесу сократить издержки и повысить эффективность.

Модель процесса изменения должна включать следующее:

1. шаги, которые должны быть предприняты для реализации изменения, в том числе разрешение проблем и непредвиденных событий;
2. хронологический порядок шагов;
3. ответственности и распределение обязанностей;
4. границы, в том числе временные, каждой деятельности в рамках процесса;

Ни одно изменение не должно осуществляться без четкого планирования действий в случае, если оно будет неудачным - "планирование исправления". В идеале должен быть некий план "backup", который позволит организации вернуться в состояние, предшествующее изменению. Только посредством оценки того, какие действия по исправлению возможны в конкретной ситуации, можно определить риски, соответствующие изменению.

Деятельности в рамках Управления изменениями включают:

1. планирование и контроль изменений;
2. составление расписаний для изменений и релизов;
3. обеспечение коммуникации между всеми участниками и компонентами;
4. авторизация к изменениям (то есть разрешения доступа тем, кто уполномочен вносить изменения) и принятие решений относительно изменений;
5. формирование планов по исправлению, которые будут задействованы в случае неудачных изменений;
6. измерение и контроль;
7. формирование управленческой отчетности;
8. оценка влияния изменения;
9. непрерывное улучшение.

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

• создание Запроса на изменение(RFC);
• пересмотр и проверка RFC, фильтрация изменений;
• оценка и определение изменения:
  • установить уровень управления изменением;
  • определить участников процесса;
  • оценить мотивацию бизнеса, издержки, риски и выгоды, связанные с изменением;
  • запросить независимую оценку изменения.
• утверждение изменения (в том числе определение механизмов авторизации к нему);
• формирование планов обновлений;
• координация реализации изменения;
• обзор и завершение изменения.

На рис. 8.3 показан процесс реализации стандартного изменения.

Рис. 8.3. Процесс реализации стандартного изменения

Рассмотрим подробнее действия в рамках реализации стандартного изменения.

Запрос на изменение создается инициатором, в качестве которого может выступать отдельный человек или группа людей. Если требуется значительное изменение, может потребоваться Предложение изменения (Change Proposal). Предложение изменения должно содержать в себе детальную информацию об изменении, обоснование его необходимости (в том числе экономическое). Все полученные запросы на изменения должны быть зарегистрированы, в терминологии ITIL у каждого изменения должна быть запись. Запись об изменении (Change Record) - запись, содержащая детальную

информацию об изменении. Каждая запись об изменении

документирует жизненный цикл одного изменения. Запись об изменении создается для каждого полученного Запроса на изменение, даже если он впоследствии отклонен (отвергнут). Запись об изменении должна содержать информацию о конфигурационных единицах, которые затрагивает данное изменение. Записи об изменениях хранятся в Системе управления конфигурациями[1]. Формат записи определяется на этапах планирования и проектирования. Информация, которую содержит запись об изменении, зависит от множества факторов: модель процесса реализации изменения, категория изменения и т.п.

В рамках пересмотра RFC Управление изменениями рассматривает каждое изменение и отфильтровывает непрактичные, некорректно обоснованные и т.п. изменения.

Для того чтобы оценить изменение ITIL предлагает ответить на 7 вопросов:

1. кто инициировал изменение?
2. какова причина изменения?
3. какой результат ждут от реализации изменения?
4. какие риски связаны с изменением?
5. какие ресурсы необходимы для реализации изменения?
6. кто ответственен за реализацию изменения?
7. какие связи изменение имеет с другими изменениями?

В рамках оценки изменения необходимо определить следующее:

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

График изменений (Change Schedule) - документ, в котором перечислены все утвержденные изменения и их плановые сроки внедрения. Ожидаемый простой услуги (Projected Service Outage или PSO) - документ, определяющий влияние спланированных изменений, деятельности по обслуживанию и планов испытаний на согласованный уровень услуг[1];

• дополнительные ресурсы, которые будут необходимы в случае реализации изменения;
• влияние на план обеспечения непрерывности, план распределения мощностей, план обеспечения безопасности и т.п[16].

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

Для категорирования рисков многие организации используют таблицы, аналогичные табл. 8.1.

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

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

• выгода для бизнеса в случае успешной реализации изменения;
• издержки и нарушения, которые возникнут, если изменение не будет реализовано.

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

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

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

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

После определенного промежутка времени Управление изменениями должно проводить обзор новой или измененной услуги с целью убедиться, что:

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

В контексте Управления изменениями вводится термин Комитет по изменениям.

Комитет по изменениям(Change Advisory Board или CAB) - группа людей, консультирующих менеджера по изменениям при выполнении им оценки соответствия, приоритезации и планирования изменений. Этот комитет обычно формируется из представителей всех заинтересованных сторон - поставщика услуг, бизнеса и третьих сторон, таких как прочие поставщики[1].

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

Комитет по срочным изменениям (Emergency Change Advisory Board или ECAB) -группа людей в составе Комитета по изменениям, которые принимают решения по Срочным изменениям с высоким влиянием. Необходимость участия в ECAB может быть выявлена непосредственно при созыве (организации) совещания и определяется исходя из сути Срочного изменения[1]. В рамках Управления изменениями должно быть специализировано, как будет определяться состав CAB и ECAB в той или иной ситуации. Состав CAB должен быть гибким, чтобы обеспечить представление интересов бизнеса в процессе предложения значительных изменений. Состав ECAB должен быть способен принимать необходимые решения в случае непредвиденных обстоятельств.

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

RFC от Построения стратегии направлены на достижение целей по минимизации рисков и затрат. Например:

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

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

Если на этапе Непрерывного улучшения услуг принято решение о том, как может быть улучшена услуга, оно должно быть также оформлено в виде Запроса на изменение, а затем передано Управлению изменениями.

Входами процесса Управления изменениями являются:

• Политики и стратегии изменений и релизов;
• Запросы на изменения;
• Предложение изменения;
• Планы изменения, внедрения, релиза, развертывания, тестирования, оценки и исправления;
• График изменений и Ожидаемый простой услуги(PSO);
• активы и конфигурационные единицы;
• результаты и отчеты тестирования/оценки.

Выходами процесса Управления изменениями являются:

• отклоненные RFC;
• утвержденные RFC;
• изменения услуг и инфраструктуры - результат утвержденных RFC;
• новые, измененные или распределенные активы или конфигурационные единицы;
• график изменений;
• пересмотренный Ожидаемый простой услуги(PSO);
• утвержденные планы изменений;
• решения и действия по реализации изменений;
• документация и записи изменений;
• отчеты Управления изменениями.

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

• количество реализованных изменений, которые смогли удовлетворить согласованные требования заказчиков в качестве/издержках/времени;
• выгода изменений - сравнение "ценность сделанных улучшений"+"предотвращенное негативное влияние" и стоимости реализации изменений;
• уменьшение количества сбоев услуг, дефектов и дополнительных работ;
• уменьшение количества неутвержденных изменений;
• уменьшение количества невыполненных запросов на изменение;
• уменьшение количества незапланированных изменений и экстренных исправлений;
• процент успешных изменений - отношение изменений, признанных успешными, к общему количеству утвержденных запросов на изменение;
• уменьшение количества изменений, в рамках которых есть работы по исправлению;
• уменьшение количества неудавшихся изменений;
• уменьшение количества инцидентов, связанных с изменениями;
• и т.п[16].