Управление изменениями с SCSM 2010. Часть 2. Подходы
Как же так, это уже вторая статья про управление изменениями с помощью SCSM, а про продукт еще ни слова не сказано? Скажу больше – в этой статье я, пожалуй, тоже ничего про продукт говорить не буду. Почему? А вот такие мы загадочные …
Говоря серьезно, продукт в процессе Change Management дает не более 30-50% успеха. Остальное – это дисциплина, дисциплина, и еще раз дисциплина. Можно это еще назвать “волей руководства” :-) Особенно это относится к организациям, только начинающим формализовывать свои процессы или находящимся в середине пути. Ну а поскольку такие организации и есть наш основной заказчик, то … давайте порассуждаем о подходах. Не переживайте, дойдет речь и до продукта … скоро … может быть …
Итак, представьте себе организацию, в которой администраторы приложений, системные и сетевые администраторы делают то, что считают правильным по своему собственному расписанию. Тут приходит новый, мудрый, и, наверное, еще неопытный IT менеджер и с порога заявляет “Мы будем жить теперь по-новому. Изменения вносить только через мой труп, шаг влево-шаг вправо – расстрел на месте”. Администраторы вежливо слушают, а про себя дружно говорят “Ага, щас!”. Возникает конфликт, и в нем явно будут пострадавшие. Будут ли победители – это вопрос. Какие-то процедуры внедрятся, что-то умрет своей смертью, чему-то помогут умереть … Вы не участвовали в таких инициативах? Я – нет, но видел их со стороны. Неприятное зрелище.
Другой подход – “неразрушающий”. Например, на первом этапе организация принимает правило “Сделал – запишись”. Это означает, что все внесенные изменения должны быть зарегистрированы в электронном или бумажном (зависит от организации) журнале. В простейшем виде это может быть файл Excel или текстовый документ.
На следующем этапе, через месяц-другой-третий, зарегистрированные изменения анализируются, и определяется категория изменений, для внесения которых требуется разрешение. На третьем этапе добавляются дополнительные процедуры – контроль тестирования, анализ рисков, утверждение службой безопасности, финансистами и т.д. и т.п. Этот подход гораздо более плавный, но и гораздо более медленный.
Во многих организациях чаще всего пытаются найти золотую середину, и сразу выделяют одну или несколько категорий изменений, которые должны находиться под пристальным вниманием. Примерами таких изменений могут быть крупные обновления компонент ключевых бизнес-систем, магистрального сетевого оборудования, массовые обновления клиентских компьютеров и т.п.
Вот и давайте предположим, что дальше мы будем иметь дело именно с такой компанией, которая шаг за шагом внедряет и развивает свой процесс управления изменениями.
Пусть для примера на первом этапе такая компания определяет всего три основных категории изменений:
- Стандартные
- Крупные
- Срочные
1. Стандартное изменение – это, как правило, периодически вносимое типовое изменение, которое уже многократно протестировано и риск от его внесения минимален. Нужно ли утверждать такое изменение, или нет – зависит от компании. В некоторых случаях компания может сказать что все стандартные изменения уже утверждены, в других – что требуется утверждение менеджером сотрудника, подающего заявку на изменение, и в третьем – что стандартные изменения должны быть утверждены менеджером по управлению изменениями.
Процедура, как говорил один доктор, проста до боли в позвоночнике:
- Подать заявку
- Утвердить заявку
- Исполнить заявку
- Закрыть заявку
2. Крупное изменение (как обобщение Minor/Major/Significant Changes). Ключевая характеристика такого изменения состоит в том, что оно должно утверждаться не одним сотрудником, а группой людей. В ITIL-овских терминах, и переводя на русский казенный язык, их называют Комитет по управлению изменениями. По-английски, соответственно, это Change Advisory Board, или CAB. Дальше я буду использовать именно эту аббревиатуру. В общем случае в CAB входят представители разных подразделений, принимающих участие в принятии решения – IT, финансы, безопасность, бизнес-подразделения. Пример процедуры для крупного изменения с подтверждением выполнения каждого этапа:
- Подать заявку
- Проанализировать и утвердить заявку менеджером по управлению изменениями
- Утвердить заявку комитетом по управлению изменениями
- Разработать решение
- Получить разрешение на тестирование
- Провести тестирование
- Получить разрешение на внедрение
- Провести внедрение
- Проанализировать результаты внедрения
- Закрыть заявку
Я опускаю ветвления в этом процессе. Если один из этапов завершается неудачно, то по решению менеджера либо комитета по управлению изменениями, этап может быть повторен, заявка может быть возвращена на один из предыдущих этапов, или все изменение может быть отменено. Кроме того, в конкретной организации в этот процесс могут быть добавлены дополнительные этапы, например, отдельное утверждение заявки непосредственным менеджером инициатора заявки.
3. Срочное изменение. Организация сама определяет, какое изменение является срочным. Например, любое изменение, которое должно быть внесено в IT-инфраструктуру быстрее чем за 24 часа, может считаться срочным. Такие изменения должны утвержаться отдельным “срочным” CAB-ом, или Emergency CAB (eCAB). В особо срочных случаях заявка может вноситься пост-фактум, уже после внесения изменения.
Процедура может быть аналогичной процедуре внесения крупного изменения, с упрощениями “по вкусу” конкретной организации.
В следующих статьях уже можно будет описать требования к продукту, вытекающие из этих подходов, и перейти наконец-то к самому продукту …
