Домен "Приобретение и внедрение": процессы, отвечающие за поставку ИТ-ресурсов, управление и реализацию изменений

8.2. AI 6. Управление внесением изменений

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

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

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

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

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

Рис. 8.2. Процесс "Управление внесением изменений"

Управление внесением изменений.

удовлетворяет следующим бизнес требованиям к ИТ

соответствие бизнес требованиям в русле корпоративной стратегии, при сокращении дефектов и переделок в решениях и услугах.

сосредоточено на

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

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

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

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

В таблице 8.5 представлена информация, необходимая для процесса и ее источники.

В таблице 8.6 приведены результаты процесса и то, куда они должны поступить.

Таблица 8.7 содержит таблицу ОУКИ для процесса, а таблица 8.8 – цели и показатели.

Цели контроля

• AI 6.1. Стандарты и процедуры изменений

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

  Проводить оценку всех запросов на изменения в соответствии со структурным подходом, позволяющим определить последствия для системы промышленной эксплуатации и ее функциональности. Следует убедиться, что все изменения категорированы, расставлены по приоритетам и авторизованы.
• AI 6.3. Аварийные изменения

  Установить процесс определения, заявления, тестирования, документирования, оценки и авторизации аварийных изменений, которые не обрабатываются в соответствии с принятым стандартным процессом изменений.
• AI 6.4. Мониторинг и отчетность по статусу изменений

  Установить систему мониторинга и отчетности для документирования не принятых изменений, информирования о статусе принятых, находящихся в процессе и завершенных изменений. Следует убедиться, что принятые изменения реализованы в соответствии с планом.
• AI 6.5. Завершение изменений и документирование

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

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

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

Рассмотрим пример. Однажды внедренная ИТ-услуга (платформа для публикации произведений) требует изменений – необходимых, желаемых, нежелательных и т.п. Например:

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

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

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

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