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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.4.5. Координация

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

Подготовка изменения

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

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

Building.

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

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

•количество .завер1неииых изменений за определенный пpo.vleжyтoк вре.мени в разбивке по катего-)иям:

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

*количество и1ииадептов, вызватнгых изменениями;

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

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

•количест во срочных и:шенений.

Тестирование

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

Внедрение

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

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

Performance indicators Operational acceptance Implementins.

7.4.6.Оценка

Необходимо давать оцешсу произведеи1И)1м измеиеииям, за возмолсиым исключением стандартных изменении. Г11)и необходимости Консультагив1№н"1 комитет (CAB) принимает penieiine о провсдснип последующих дополиителыгых мероприятии. Лолж1и>1 быть рассмотрены слсдуюиию вопросы:

•Привело лн измепенне к достижешпо памеченнон цели?

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

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

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

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

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

7.4.7.Проведение срочных изменений

Как бы хорошо ни проводилось планирование, могут быть измеиепия, требуюище наивыспгего приоритета. Срочные измене1И1я очень важны для компании и они должны осуп1ествляться как можно скорее. В больпиигствс случаев на эти изменения направляют ресурсы, иредназначеппые для других видов деятельности. Срочные изменения могут серьезно повлиять на запланироваи-ную работу. Следовательно, задачей является сведение к минимуму числа срочных или неожиданных измеиений (с «наивыснтм» приоритетом). Возможные превагтивпые меры включают:

•обеспече1П1е своевременной подачи Запросов на Изменения, пока они не стали срочными.

•при Т1снравлении опнтбок, возникпитх в резу;гьтате плохой подготовки изменений, возврат не до-ч-жеи заходтггь дальше н])сжпсй версии, то есть дальнш Прежнего стабильного состояния-. После возврата следует тщательно подготовить новый улучпшнный план нзменс1итя.

Несмотря на указанные выше меры С1ючнь1е изменения все же могут возникнуть. Omi требуюч- njjo-цедур для срочной обработки, но с coxpaneinicM обшиО контроля со стороны Процесса Управления Изменениями. В случае возннкнове1И1я такой ситуации Руководите;и> П])оцссса Управления Изменениями может организовать чрезнычайиое совеп1аиие комитета САВ/ЕС. Если для этого нет времени или ecjHi Запрос поступил в нерабочее время, должен существовать альтернативный сиособ получения авторизации изменения. Это не обязательно должна бьггь встреча «лицом к лицу», в.ме-сто нее можно провести телефонную копферешпио.

Пример этого был упомянут в главе по Управле(иио Ин1П1де1ггами, когда экстренный ремонт может быть предложен для разрешения серьезного 1ииц1дснта. Если дело обсто1гт оче}1Ь плохо и о1срочка неприемлема, необходимо следовать процедуре обработки срочного Запроса на Изменение.

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

Post Implementation Review - PIR. Previous Trusted State.