Метод, с помощью которого организация решает внедрить процесс Управления изменениями, в основном зависит от имеющихся ресурсов (таких как время, приоритеты, человеческие ресурсы и, прежде всего, финансы).

8.5.1 Планирование внедрения процедур операционного уровня.

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

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

8.5.2 Регистрация и фильтрация изменений.

Следует установить процедуры документирования RFC с использованием стандартных форм, e-mail-форм или интранет-форм. Там, где есть компьютеризированные средства поддержки, они могут диктовать использование какого-либо формата. Там, где нет стандарта, определяемого средством поддержки, или если необходимо использовать систему с бумажным документооборотом, рекомендуется, чтобы элементы, указанные в параграфе 8.3.1. были включены в форму RFC.

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

Все принятые RFC должны быть зарегистрированы и обязательно должны получить идентификационный номер (в хронологической последовательности). В случае, когда запросы на Изменение направляются с целью разрешения какойлибо Проблемы, важно сохранить первоначальный номер PR (Problem Record), чтобы связь между Проблемой и ее решением была очевидной.

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

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

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

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

8.5.3 Назначение приоритетов.

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

Приведенные приоритеты представлены только в качестве примеров. Многие программные средства предоставляют широкие возможности по присвоению приоритетов.

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

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

■ Средний. Влияние изменения не слишком значительно, но меры по устранению не могут откладываться до следующего по графику Релиза или модернизации. Следует назначить средний приоритет для использования ресурсов.

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

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

8.5.4 Категоризация изменений.

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

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

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

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

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

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

■ получить доступ к четкой и полной информации о затратах на каждую услугу, область работ Заказчиков и т.д.;.

■ идентифицировать повторяющиеся Изменения, последующие Изменения и связанные с ними области появления.

Пр об л ем/Инцидентов.

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

Значительное воздействие и/или требуются значительные ресурсы для сборки и рабочего цикла.

В зависимости от срочности проводимого Изменения Менеджеры процесса Управления изменениями должны решить, насколько целесообразно проведение переговоров с САВ или созыв САВ/ЕС. Перед каждым собранием должна быть распространена вся документация для оценки воздействия и ресурсов.

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

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

8.5.5 Собрания САВ.

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

Стандартная повестка дня собрания САВ должна включать обсуждение:.

■ неудавшихся Изменений; Изменений, после которых пришлось вернуться к предыдущему состоянию; Изменений, которые были проведены процессами Управления инцидентами, Управления проблемами или Управления изменениями без участия САВ;.

■ RFC, по которым члены САВ должны дать оценку;.

■ RFC, по которым члены САВ уже дали свою оценку за обсуждаемый период;.

■ проведенных Изменений;.

■ процесса Управления изменениями, включая все поправки, которые были сделаны в этом процессе за обсуждаемый период, а также предлагаемые Изменения;.

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

Собрания САВ требуют довольно больших затрат времени его членов. Поэтому все RFC вместе с FSC и PSA должны распространяться заранее. Кроме того, члены САВ должны иметь возможность выбора - либо посещать собрания самостоятельно, либо направлять представителя, либо отправлять свои комментарии через Менеджера процесса Управления изменениями. Требуемые документы должны распространяться заранее, чтобы дать возможность членам САВ (а также всем, кого потребуют привлечь Менеджеры процесса Управления изменениями или члены САВ) провести оценку влияния и необходимых ресурсов.

При некоторых обстоятельствах может быть предпочтительнее рассмотреть RFC на одном собрании, предоставив более подробные разъяснения до того, как члены САВ возьмут документы на рассмотрение, и принять решение на следующем собрании.

Анализ Изменений более подробно обсуждается в параграфе 8.5.12.

8.5.6 Оценка влияния и ресурсов.

Проводя оценки влияния и ресурсов для рассматриваемых RFC, Менеджеры процесса Управления изменениями, САВ, САВ/ЕС или все те, кто вовлечен в этот процесс (Менеджерами процесса Управления изменениями или членами САВ), должны учесть следующие моменты:.

■ воздействие Изменения на бизнес-деятельность Заказчиков;.

■ воздействие на инфраструктуру и на предоставление услуг Заказчикам, как определено в SLA, а также на мощности и производительность, надежность, устойчивость, планы действий в чрезвычайных ситуациях и безопасность;.

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

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

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

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

■ текущий FSC и PSA;.

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

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

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

Рекомендации САВ.

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

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

8.5.7 Утверждение изменений.

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

Получение утверждения.

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

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

8.5.8 Составление графика изменений.

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

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

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

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

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

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

Графики Изменений должны широко распространяться, поскольку предлагаемые Изменения и время их проведения влияет на планирование деятельности и работу во многих частях организации внутри и вне процесса Управления услугами. Уведомление вне процесса обычно проходит через службу Service Desk и процессы Управления уровнем обслуживания и Управления взаимоотношениями с Заказчиками. Доступ к графику должен предоставляться всем процессам Управления услугами. Руководящий аппарат Управления изменениями должен подкрепить эту информацию с помощью программы активного ознакомления, в ходе которой можно определить ожидаемое влияние Изменений на другие процессы, например, на Управление мощностями, Управление доступностью и другие.

Особенно важно при составлении графика рассмотреть бизнес-потребности организации, не забывая о потребностях Заказчика и конечного пользователя.

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

■ сборку нового производственного модуля;.

■ создание новой версии одного или более программных модулей;.

■ внешнюю закупку оборудования или получение его со склада;.

■ подготовку модификации аппаратного обеспечения;.

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

■ подготовку обновленных тренингов для Пользователей.

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

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

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

■ производительности;.

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

■ возможности обслуживания;.

■ поддерживаемости;.

■ надежности/доступности;.

■ функциональности.

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

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

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

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

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

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

8.5.10 Срочные изменения.

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

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

Рисунок 8.5 - Процедура внедрения срочного Изменения.

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

8.5.11 Сборка, тестирование и внедрение срочных Изменений.

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

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

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

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

Если после ряда попыток проведение срочного Изменения оказалось безуспешным, необходимо ответить на три вопроса:.

1.

Была ли Проблема правильно проанализирована?.

2.

Было ли предлагаемое решение достаточно тщательно протестировано?.

3.

Правильно ли решение было внедрено?.

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

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

8.5.12 Анализ Изменений.

Управление изменениями должно проводить анализ всех внедренных Изменений по окончании установленного периода. К этому процессу также могут привлекаться члены САВ - Менеджеры процесса Управления изменениями могут обращаться к ним за помощью в процессе анализа.

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

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

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

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

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

■ план внедрения сработал правильно (следует включить комментарии группы внедрения);.

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

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

Все проблемы и несоответствия должны быть направлены членам САВ (либо для индивидуальных консультаций с членами САВ, либо для рассмотрения на собрании), а также лицам, выполняющим оценку воздействия, и уполномоченным по продуктам и Релизам, чтобы в будущем улучшить процесс оценки.

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

8.5.13 Анализ продуктивности и эффективности процесса Управления изменениями.

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

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

Говоря о любом таком анализе, следует заметить, что большое количество RFC не всегда является показателем проблем в процессе Управления изменениями - это может просто отражать общую изменчивость систем. Любая попытка уменьшить количество RFC может ограничить нововведения. Основной индикатор эффективности процесса Управления изменениями - поддержка правильного пропорционального состава типов RFC, а не уменьшение количества RFC с течением времени.

Ниже приведены другие возможные показатели эффективности процесса Управления Изменениями:.

■ уменьшение отрицательных воздействий на качество услуг;.

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

■ уменьшение количества откатов Изменений;.

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

■ отсутствие свидетельств об Изменениях, которые были проведены без участия систем Управления изменениями и Управления конфигурациями;.

■ полное соответствие между FSC и реальным внедрением Изменений;.

■ отсутствие RFC с высоким приоритетом в списке ожидания, а также то, что этот список ожидания не увеличивается;.

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

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

■ успешное внедрение изменений, в которых ясно видны преимущества для бизнеса, и которые удовлетворяют требования Заказчиков;.

■ низкий процент необоснованно отклоненных RFC.

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

8.5.14 Роли и обязанности.

Очевидно, должен быть назначен человек на роль Менеджера процесса Управления изменениями с четко определенными обязанностями, что необходимо для эффективной работы этого процесса. Предлагаемый список обязанностей для ролей в процессе Управления изменениями приведен ниже:.

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

Основные обязанности Менеджера изменений, некоторые из.

которых могут быть делегированы, перечислены ниже:.

■ Получение, регистрация RFC и назначение приоритета всем RFC, совместно с их инициатором. Отклонение RFC, которые совершенно несостоятельны.

■ Вынесение всех RFC на собрания САВ, составление плана собраний и распространение всех RFC среди членов САВ до проведения собрания с целью предварительного ознакомления.

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

■ Созыв срочных собраний САВ или САВ/ЕС для всех срочных RFC.

■ Ведение всех собраний САВ и САВ/ЕС.

■ После рассмотрения рекомендаций САВ или САВ/ЕС, авторизация приемлемых Изменений.

■ Выпуск FSC посредством Службы Service Desk.

■ Взаимодействие со всеми необходимыми сторонами для координации сборки, тестирования и внедрения Изменений в соответствии с графиком.

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

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

■ Анализ всех открытых RFC, которые ждут своего рассмотрения или каких-либо действий.

■ Анализ записей об Изменениях для нахождения тенденций или явных проблем. Переговоры по исправлению ситуации со всеми необходимыми сторонами.

■ Закрытие RFC.

■ Составление квалифицированных и точных управленческих отчетов.

Учреждение Консультативного комитета по изменениям (САВ).

Если учреждается САВ, он нуждается в составлении соответствующих правил работы (например, регулярность собраний, масштабы его влияния, связи с.

управлением программами). Для обеспечения должного представительства члены этого Комитета должны включать представителей от:.

■ Заказчиков, на которых воздействуют Изменения;.

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

Управления услугами;.

■ групп разработчиков приложений;.

■ руководителей групп Пользователей или их представителей.

Менеджер изменений должен выполнять функции председателя этого Комитета. Менеджер процесса Управления изменениями или Управления конфигурациями или кто-либо из персонала службы поддержки может выступать в роли секретаря Комитета.

Консультативный комитет по изменениям (САВ).

Основные обязанности членов САВ перечислены ниже:.

■ Анализ всех RFC, представленных на рассмотрение. Исходя из целесообразности, определять и предоставлять сведения о возможном влиянии, ресурсах, требуемых для внедрения, и о текущих затратах для всех Изменений.

■ Участие во всех существенных собраниях САВ и САВ/ЕС. Рассмотрение всех Изменений, указанных в повестке дня, и высказывание своего мнения о том, какие Изменения должны быть авторизованы. Участие в составлении графика всех Изменений.

■ Предоставление консультаций (только для САВ/ЕС), если это требуется для срочного Изменения.

■ Предоставление рекомендаций Управлению изменениями по всем аспектам предлагаемого срочного Изменения.