Рисунок 8.3а - Основные процедуры Управления изменениями - часть 1.

Рисунок 8.36 - Основные процедуры Управления изменениями - часть 2.

Рисунок 8.4 - Подход к стандартным процедурам Управления изменениями.

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

■ задачи хорошо известны и проверены;.

■ полномочия переданы заранее;.

■ цепочка событий, как правило, инициируется службой Service Desk;.

■ утверждение бюджета обычно предопределено или находится в сфере контроля того, кто запрашивает Изменение.

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

8.3.1 Запросы на Изменение.

У запросов на Изменение (RFC, или Request for Change) множество причин и источников. Причины могут быть следующие:.

■ требуется решение, указанное в отчете об Инциденте или Проблеме;.

■ неудовлетворенность Пользователя или Заказчика, переданная через связь с Заказчиком или Управление уровнем обслуживания;.

■ предложение о введении нового УЭ или удалении УЭ;.

■ предложение по модернизации некоторых компонентов инфраструктуры;.

■ изменение требований или направления бизнеса;.

■ нововведения или изменения в законодательстве;.

■ изменение местоположения;.

■ изменения в продуктах или услугах, предоставляемых поставщиками или подрядчиками.

RFC могут быть связаны с любой частью инфраструктуры или с любой услугой или деятельностью, например:.

■ аппаратное обеспечение;.

■ программное обеспечение;.

■ документация;.

■ телекоммуникационное оборудование;.

■ специализированное оборудование;.

■ образовательные курсы;.

■ процедуры управления ИТ-инфраструктурой;.

■ тактические планы;.

■ обеспечивающая инфраструктура.

RFC, может храниться как в бумажной форме, так и в электронном виде.

Следующие элементы должны быть включены в форму RFC (как бумажного, так и электронного):.

■ порядковый номер RFC (плюс перекрестная ссылка на номер отчета о Проблеме, если это необходимо);.

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

■ причина для внесения Изменения;.

■ последствия в случае, если Изменение не будет внедрено;.

■ версия изменяемого элемента;.

■ название, местоположение и телефонный номер человека, предлагающего Изменение;.

■ дата, когда было предложено Изменение;.

■ приоритет Изменения;.

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

■ рекомендации САВ, когда это уместно; эти рекомендации могут храниться отдельно или вместе с оценками воздействия и ресурсов, если это удобно;.

■ авторизующая подпись (может быть электронной);.

■ дата и время авторизации;.

■ планируемое внедрение (идентификация Релиза и/или даты и времени);.

■ местоположение плана Релиза/внедрения;.

■ сведения о том, кто разрабатывает/внедряет Изменения;.

■ план отката;.

■ действительные дата и время внедрения;.

■ дата проведения анализа;.

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

■ оценка и управление рисками;.

■ влияние на план непрерывности бизнеса и на план действий в чрезвычайных ситуациях;.

■ статус RFC, т.е. «обработан», «оценен», «отклонен», «принят», «в ожидании».

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

По мере продвижения Изменения по жизненному циклу запрос на Изменение и CMDB должны обновляться, чтобы инициатор Изменения мог знать его статус. В записях должна присутствовать информация о реально использованных ресурсах и затратах. Следует провести Анализ результатов внедрения (PIR, или Post-Implementation Review) для подтверждения достижения Изменением поставленных целей и того, что Заказчики довольны результатами, и неожиданных побочных эффектов не возникло. Полученные уроки должны отразиться на последующих Изменениях. Небольшие организации могут решить использовать выборочную проверку Изменений вместо крупномасштабного Анализа результатов внедрения. В больших организациях выборочная проверка может быть полезна, когда происходит много однотипных Изменений.

8.3.2 Консультативный комитет по изменениям.

Консультативный комитет по изменениям (Change Advisory Board, CAB) - орган, который существует для утверждения Изменений и для содействия Менеджерам процесса Управления изменениями при оценке и определении приоритетов изменений. САВ должен состоять из тех, кто способен обеспечить адекватную оценку всех Изменений с точки зрения как бизнеса, так и технологий. Для достижения такого баланса САВ должен включать людей с четким пониманием бизнес-нужд Заказчиков и сообщества Пользователей, а также технического развития и функций поддержки. Также см. параграф 8.5.5.

Рекомендуется, чтобы в САВ при необходимости входили:.

■ Менеджер изменений;.

■ Заказчик(и);.

■ Менеджер(ы) Пользователей;.

■ представитель(и) групп Пользователей;.

■ разработчики/специалисты по сопровождению приложений (если это целесообразно);.

■ эксперты/технические консультанты;.

■ обслуживающий персонал (по необходимости);.

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

■ представители подрядчиков и внешних поставщиков (по необходимости.

- например, в случаях аутсорсинга).

Важно подчеркнуть, что:.

■ САВ будет формироваться в зависимости от рассматриваемых Изменений;.

■ состав САВ может значительно варьироваться даже в течение одного собрания;.

■ в САВ должны входить поставщики, если это будет полезно;.

■ САВ должен отражать взгляды, как пользователей, так и Заказчиков;.

■ в САВ, вероятно, войдут Менеджер проблем и Менеджер уровня обслуживания.

Когда возникают крупные Проблемы, может случиться так, что для созыва САВ нет времени, и в связи с этим необходимо определить минимальный состав, который будет уполномочен принимать срочные решения. Такой орган известен как Комитет по срочным изменениям CAB (САВ/ЕС, или Change Advisory Board/Emergency Committee). Процедуры Изменений должны указывать, как в каждом случае будет определяться состав САВ и САВ/ЕС на основании критериев, описанных выше, и других критериев, которые могут быть целесообразны для бизнеса. Целью этого является обеспечение гибкости состава САВ, чтобы интересы бизнеса были соответствующим образом представлены в случаях, когда предлагаются крупные Изменения. Это также обеспечит то, что состав САВ/ЕС позволит принимать соответствующие решения с точки зрения, как бизнеса, так и технологий, при любом возможном стечении обстоятельств.

Практический совет: полезно помнить, что САВ должен иметь описанные и согласованные критерии оценки. Это поможет процессу оценки Изменений и будет служить шаблоном или структурой, с помощью которой члены САВ смогут оценивать каждое Изменение.

8.3.3 Метрики изменений.

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

Измерения должны быть связаны с целями бизнеса везде, где это практично, а также со стоимостью, доступностью и надежностью услуг. Любые прогнозы должны сравниваться с реальными показателями. Подробнее об этом можно прочитать в Разделе 8.7. «Метрики и управленческая отчетность».

8.3.4 Согласованный график изменений и модели изменений.

Одна область Управления изменениями развивается значительно быстрее других.

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

Следует уделять внимание вопросам, связанным с определением ответственности за оценку воздействия крупного Изменения. Это не является вопросом использования лучших практических методов, поскольку организации настолько различны по размерам, структуре и сложности, что не существует решения, единого для всех. Тем не менее, рекомендуется, чтобы крупные Изменения сначала обсуждались со всеми вовлеченными сторонами (с теми, кто занимается управлением программами/проектами и Управлением изменениями), чтобы прийти к разумным границам ответственности и улучшить коммуникации. Несмотря на то, что Управление изменениями несет ответственность за оценку Изменений и, в случае их утверждения, за их разработку, тестирование, внедрение и анализ, понятно, что конечная ответственность за ИТ-услугу, включая проводимые в ней Изменения, лежит на ИТ-директоре, Менеджере ИТ-услуг и Заказчиках, которые контролируют финансирование. САВ может рекомендовать принятие (или отклонение) более значительных Изменений, но их воздействие должно обсуждаться в достаточно большом масштабе, что может перенести конечную ответственность за пределы Управления услугами или даже за пределы ИТ и процесса Изменений. «Ответственность» здесь рассматривается в рамках процесса Управления изменениями, а также связанных с ним рисков и бюджетных ограничений.

С другой стороны, небольшие Изменения могут быть проведены с использованием «стандартных» моделей Изменений - например, обмен ПК или регулярное обновление ПО. До тех пор пока соблюдается предписанный график вместе со всеми критериями (возможно, критериями, связанными, например, с процессами сборки и тестирования), Менеджеры процесса Управления изменениями могут авторизовать подобные Изменения без задействования всего процесса Управления изменениями. Рисунок 8.4 показывает, как процесс использования стандартных моделей Изменений, определенный Менеджерами процесса Управления изменениями при согласии других менеджеров процессов поддержки услуг, может быть интегрирован в рамки обычных процессов Изменений. Следует заметить, что определение масштаба или сложности Изменений, связанных с использованием моделей, индивидуальны для каждой организации.

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

Для того чтобы улучшить этот процесс, Менеджеры процесса Управления изменениями должны координировать разработку и распространение «Согласованного графика изменений» (FSC) и «Ожидаемой доступности услуги» (PSA, или Projected Service Availability). Новейшие версии этих документов должны быть доступны каждому сотруднику в рамках организации. Предпочтительно, чтобы эти версии находились на общедоступном интернет- или интранет-сервере. FSC содержит сведения обо всех Изменениях, утвержденных к внедрению, и предлагаемые даты их внедрения. PSA содержит сведения об Изменениях в согласованных SLA и о доступности услуг вследствие планируемого FSC. Эти документы должны быть согласованы с Заказчиками из бизнеса, с Управлением уровнем обслуживания, со Службой Service Desk и с Управлением доступностью. После согласования Служба Service Desk должна сообщить всему сообществу Пользователей о любых дополнительно планируемых простоях наиболее эффективным из доступных способов.

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

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

Следует помнить, что существует значительная разница между блок-схемами и моделями процессов. Блок-схемы (несколько полезных примеров приведено в данных рекомендациях) позволяют Управлению изменениями видеть простые потоки информации, но не удаляться от реальных действий. Модель процессов, с другой стороны, показывает картину, с помощью которой можно с уверенностью провести детальную оценку. Пример для изучения из Приложения Б (основанный на анонимных данных крупной аутсорсинговой компании, которая столкнулась с проблемами внедрения процессов Библиотеки ITIL в Европейском регионе) поможет вам оценить использование блок-схем и моделей процессов.

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

8.3.5 Аутсорсинг и Управление изменениями.

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

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

■ Кто несет ответственность за ежедневное Управление Изменениями, происходящими на основании RFC из различных источников (см. параграф 8.3.1)?.

■ Какие рычаги контроля имеются над поставщиком услуг, чтобы не пришлось платить за нерациональные Изменения?.

■ Как можно убедиться в том, что Изменения не будут проводиться скрытно и по частям, при этом воздействуя на услуги и их стоимость?.

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

■ Кто отвечает за целостность системы и услуг после Изменений?.

■ Насколько тщательно рассматриваются вопросы безопасности систем?.

■ Кто должен входить в состав САВ?.

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

■ затрат;.

■ владения аппаратным и программным обеспечением;.

■ степени партнерства бизнеса с поставщиком (в отличие от простых взаимоотношений поставщик-потребитель);.

■ типа предоставляемых услуг;.

■ масштабов этих услуг (инфраструктура, службы help/service desk, разработка прикладного ПО и т.д.).

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

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

Управление изменениями должно охватывать следующие вопросы:.

■ содержание плана;.

■ владение;.

■ распространение;.

■ ключевые бизнес-направления, которые необходимо поддерживать;.

■ как эти бизнес-направления поддерживаются ИТ;.

■ связи с непрерывностью бизнеса и планами действий ИТ в чрезвычайных ситуациях;.

■ критические компоненты;.

■ временные рамки;.

■ риски;.

■ стратегия возврата в предыдущее состояние;.

■ иницирование.

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

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