Политика проведения изменений

Изменения по разным Запросам можно объединять в одном релизе. В этом случае при неудачной реализации будет достаточно одного возврата к исходному состоянию. Такой групповой релиз должен рассматриваться как одно изменение, даже если он содержит в себе несколько изменений. Релизы могут планироваться с учетом функциональных задач, необходимых для бизнеса. Они могут охватывать аппаратные и программные средства, и их внедрение осуществляется Процессом Управления Релизами. Рекомендуется определить политику компании в этой области и информировать о ней ИТ-организацию и заказчиков (см. также «Управление Релизами»). Цель политики — оградить пользователя от ненужного беспокойства («перекапывание дороги каждую неделю»).

После консультаций с участвующими ИТ-подразделениями, Консультативный комитет (CAB) может определить регулярные периоды времени («окна») для проведения изменений, когда степень воздействия на ИТ-сервисы будет минимальной. Подходящими периодами могут быть выходные дни или нерабочее время. Таким же образом могут быть определены периоды, когда допускается минимум изменений или они вообще не допускаются, например, рабочее время или конец финансового года, когда все подразделения пользователей делают отчеты.

СОВЕЩАНИЯ КОНСУЛЬТАТИВНОГО КОМИТЕТА (CAB)

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

Повестка дня совещания CAB должна включать ряд постоянных пунктов, в том числе:

§ неавторизованные изменения;

§ Запросы на Изменения (RFC), которые должны быть оценены членами Консультативного комитета (CAB);

§ авторизованные изменения, которые не были представлены на рассмотрение консультативного комитета (CAB);

§ открытые и закрытые изменения;

§ оценка произведенных изменений.

Оценка степени воздействия и ресурсов

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

§ вопросы возможностей («мощности» или «емкости») подвергающихся воздействию услуг;

§ надежность и возможность восстановления;

§ планы по Управлению Непрерывностью ИТ-услуг;

§ планы возврата к исходному состоянию;

§ вопросы безопасности;

§ степень воздействия изменения на другие ИТ-сервисы;

§ регистрация изменения и его предварительное одобрение;

§ необходимые ресурсы и затраты (поддержка и обслуживание);

§ количество и наличие необходимых специалистов;

§ необходимое время на весь цикл изменения;

§ новые ресурсы, которые должны быть закуплены и пройти тестирование;

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

§ какие-либо возможные конфликты с другими изменениями.

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

КООРДИНАЦИЯ

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

ПОДГОТОВКА ИЗМЕНЕНИЯ

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

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

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

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

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

§ скорость проведения изменений; •количество отклоненных изменений; •количество инцидентов, вызванных изменениями;

§ количество возвратов к исходному состоянию, связанных с проведением изменений; •затраты на произведенные изменения;

§ соотношение между расчетными и фактическими затратами ресурсов и времени; •количество срочных изменений.

ТЕСТИРОВАНИЕ

Процедура возврата к исходному состоянию, план внедрения изменения и ожидаемый результат должны проходить тщательную проверку. При этом необходимо учитывать критерии, определенные ранее консультативным комитетом (CAB). В большинстве случаев для испытаний необходима изолированная тестовая среда или лаборатория. Тестирование на ранних стадиях может производиться разработчиками, однако внедрение изменений не может осуществляться без проведения независимого тестирования. Обычно проводится два вида испытаний: приемо-сдаточные испытания для пользователей, при которых представители бизнес-подразделений (обычно заказчики изменения) проверяют его функциональные характеристики, и операционные (эксплуатационные) испытания, при которых независимое тестирование проводят те, кто должен поддерживать и обслуживать новую инфраструктуру. Сюда включаются также отделы технической поддержки и Служба ServiceDesk. Они проверяют соответствующую документацию, процедуры резервного восстановления данных (back-up) и т. д. Необходимы также четкие инструкции для мониторинга качества тестирования и документирования его результатов.

ВНЕДРЕНИЕ

Любой сотрудник соответствующего подразделения, ответственный за администрирование ИТ-инфраструктуры, может получить задание о непосредственном проведении (внедрении) изменения. Управление Изменениями гарантирует, что это является запланированым изменением. Должен существовать точный план информирования всех вовлеченных сотрудников о проведении изменения (коммуникационный план), например, пользователей, Службы Service Desk, группы администрирования сетей и т. п.

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

ОЦЕНКА

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

§ Привело ли изменение к достижению намеченной цели?

§ Удовлетворены ли пользователи результатом?

§ Возникали ли какие-либо побочные эффекты?

§ Были ли превышены расчеты по затратам и ресурсам?

Если изменение осуществлено успешно, Запрос на Изменение (RFC) может быть закрыт. Это происходит на этапе Анализа результатов внедрения (PIR), т. е. этапе оценки изменения. Если же изменение закончилось неудачно, процесс возобновляется с того места, где он вызвал сбой, с использованием нового подхода. Иногда бывает лучше сделать возврат назад и создать новый или модифицированный Запрос на Изменения (RFC). Продолжение работы с неудачным изменением часто приводит к ухудшению ситуации.

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