Текст книги "ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL"
Автор книги: Jan van Bon
сообщить о нарушении
Текущая страница: 8 (всего у книги 18 страниц)
7.3.2. Управление Конфигурациями
Управление Изменениями и Управление Конфигурациями являются настолько тесно связанными процессами, что они могут быть эффективно интегрированы между собой – шаг, рекомендованный в библиотеке ITIL.
Изменения регистрируются под контролем Процесса Управления Конфигурациями, анализ воздействия изменений также проводится с участием Процесса Управления Конфигурациями. Управление Конфигурациями определяет зависимость между Конфигурационной Единицей CI (вовлеченной в проводимое изменение) и другими CI, чтобы определить, на какие другие элементы будет воздействовать это изменение.
7.3.3. Управление Проблемами
Взаимосвязь между Процессами Управления Изменениями и Управления Проблемами во многом похожа на такую же связь между Процессами Управления Изменениями и Управления Инцидентами. С одной стороны, изменения часто бывают необходимы для разрешения проблем. С другой стороны, если проведение изменений недостаточно контролируются, они могут привести к новым проблемам.
7.3.4. Управление Релизами
Изменения часто приводят к необходимости разработки и распространения новых приложений или установке технической инфраструктуры. Это осуществляется с помощью Процесса Управления Релизами. Контроль над распространением новых версий осуществляется Процессом Управления Изменениями.
7.3.5. Управление Уровнем Сервиса
Процесс Управления Уровнем Сервиса вовлечен в определение степени воздействия изменений на предоставление услуг и бизнес-процессы. В зависимости от ситуации в Консультативном комитете (CAB) могут участвовать представители Процесса Управления Уровнем Сервиса. Если изменение оказывает значительное воздействие или связано с высоким риском, его внедрение и сроки должны всегда обсуждаться с заказчиком. Управление Изменениями направляет в Управление Уровнем Услуг отчет "Проектируемая доступность услуг"[108]108
Projected Service Availability – RCA.
[Закрыть] (PSA). В этом отчете Управление Изменениями излагает изменения в имеющихся Соглашениях об Уровне Услуг (SLA) и воздействие Согласованного плана изменений (FSC) на доступность услуг.
7.3.6. Управление Доступностью
Процесс Управления Доступностью инициирует изменения, направленные на повышение доступности услуг и проверяет, привели ли предпринимаемые меры к ожидаемому результату. Управление Доступностью часто привлекается при оценке потенциального воздействия изменений, так как это воздействие может повлиять на доступность услуги.
7.3.7. Управление Мощностями
Руководитель Процесса Управления Мощностями в первую очередь занимается вопросом анализа совокупного эффекта по результатам изменений в течение продолжительного периода времени, например, увеличением времени реакции приложений или потребностью в большей емкости для хранения информации. На основе составленного Плана мощностей Управление Мощностями регулярно предлагает усовершенствования и инициирует изменения в форме Запросов на Изменения (RFC).
7.3.8. Управление Непрерывностью ИТ-услуг
Превентивные мероприятия и планы восстановления, гарантирующие непрерывность услуг, должны постоянно контролироваться, так как изменения инфраструктуры могут сделать эти планы неосуществимыми или избыточными. Процесс Управления Изменениями действует в тесной взаимосвязи с Процессом Управления Непрерывностью ИТ-услуг, чтобы в нем учитывались все изменения, которые могут повлиять на планы восстановления, и предусматривались меры, необходимые для проведения восстановления.
7.3.9. Виды деятельности в рамках Процесса Управления Изменениями
Процесс Управления Изменениями включает в себя следующие виды деятельности для обработки изменений:
? Направление Запроса – не включается в виды деятельности по Управлению Изменениями, но поддерживается этим процессом, так как Управление Изменениями отвечает за правильную регистрацию всех изменений.
? Прием в обработку – предварительный просмотр (фильтрация) Запросов на Изменения и прием их к дальнейшему рассмотрению.
? Классификация – сортировка Запросов на Изменения по категориям и приоритету.
? Планирование – объединение изменений, планирование их проведения и планирование необходимых ресурсов.
? Координация – координирование компоновки, испытаний и проведения изменений.
? Оценка – оценка успешности каждого изменения и составление заключения для будущей деятельности (накопление знаний).
Рис. 7.3. Виды деятельности в рамках Процесса Управления Изменениями
7.4. Виды деятельности
7.4.1. Регистрация
Прежде всего, все Запросы на Изменения (RFC) должны быть зарегистрированы. При подаче Запроса на Изменение для решения проблемы также регистрируется номер известной ошибки.
Что представляет собой Запрос на Изменения (RFC)?
Не каждый Запрос на Модификацию обрабатывается как изменение: некоторые повседневные задания, точно определенные и подчиняющиеся установленным процедурам (стандартизованные), но включающие в себя модификации, могут обрабатываться как Запросы на Обслуживание (например, изменения "категории 0", см. 7.1.1). В результате возникает следующая классификация изменений:
? Запросы на Обслуживание (здесь: стандартные изменения) – полностью определенные и утвержденные изменения, регистрируемые, но не оценивающиеся Процессом Управления Изменениями. Эти изменения проводятся в рабочем порядке. (Примечание. Не все Запросы на Обслуживание являются изменениями).
? Запросы на Изменения – все другие Запросы на Модификацию инфраструктуры.
Откуда исходят Запросы на Изменения (RFC)?
Запросы на Изменения могут касаться всех аспектов инфраструктуры в пределах сферы действия процессов ITIL. Любой сотрудник, работающий с инфраструктурой, может подать Запрос на Изменения (RFC). Можно определить несколько источников Запросов на Изменения (RFC), например:
? Управление Проблемами – предлагает решения для исключения долговременных ошибок с целью стабилизации предоставления услуг.
? Заказчики – могут запросить больший, меньший Уровень Сервиса или другие услуги. Эти запросы могут подаваться прямо как Запрос на Изменения или направляться через Управление Уровнем Сервиса (SLM) или через Управление Отношениями с заказчиками ИТ (IT CRM).
? Политика компании – тактические и стратегические процессы из области Предоставления услуг (Service Delivery Set) и Указания руководства (Managers Set) могут привести к направлению Запросов на Изменение Услуг. Например, Управление Уровнем Услуг, Управление Доступностью и Управление Мощностями составляют ежегодные планы улучшения услуг, которые позднее могут быть поданы как Запросы на Изменения (RFC).
? Законодательство – если возникают ограничения, регламентирующие бизнес-деятельность, или вводятся новые требования по ИТ-безопасности, непрерывности бизнес-процессов и Управлению Лицензиями.
? Поставщики – поставщики выпускают новые версии и модификации[109]109
Upgrades.
[Закрыть] своих продуктов и сообщают об исправленных ими ошибках. Они могут сообщить, что больше не поддерживают определенные версии или что не могут гарантировать производительность версии (например, из-за «Ошибки тысячелетия» – Millennium bug). Это может дать толчок Процессам Управления Проблемами или Управления Доступностью к подаче Запроса на Изменения (RFC).
? Проекты – проект часто вызывает ряд изменений. Руководство проекта должно эффективно согласовывать свои действия с Управлением Изменениями с помощью соответствующих процессов, таких как Управление Уровнем Услуг, Управление Мощностями и т. п.
? Любой другой сотрудник ИТ – в принципе, любой сотрудник может подать предложения по улучшению услуг. В особенности, ИТ-персонал может способствовать усовершенствованию процедур по поддержке и предоставлению услуг и обновлению руководств.
Регистрация Запросов на Изменения
Вот примеры информации, которая может включаться в Запросы на Изменения (RFC):
? идентификационный номер Запроса;
? номер проблемы/известной ошибки (если имеется), связанной с Запросом;
? описание и определение соответствующих Конфигурационных Единиц (CI);
? причина изменения, включая обоснование и ожидаемый бизнес-результат;
? текущая и новая версия изменяемой Конфигурационной Единицы;
? имя, адрес и номер телефона лица, направляющего Запрос;
? дата подачи;
? предварительная оценка необходимых ресурсов и времени.
7.4.2. Прием в обработку
После регистрации Запроса на Изменения (RFC) Управление Изменениями делает первичную проверку, нет ли среди них неясных, нелогичных, непрактичных или ненужных Запросов. Такие Запросы отклоняются с объяснением причин. Сотруднику, направившему Запрос, всегда должна быть предоставлена возможность для защиты своего Запроса.
Проведение изменения ведет за собой обновление в базе данных CMDB, например:
? изменение статуса существующей Конфигурационной Единицы;
? изменение взаимосвязи между различными Конфигурационными Единицами;
? новая Конфигурационная Единица или изменение существующей Конфигурационной Единицы;
? новый владелец или другое месторасположение Конфигурационной Единицы.
Если Запрос на Изменения (RFC) принимается в работу, в регистрационную запись изменения включается информация, необходимая для дальнейшей обработки изменения. Позднее к записи добавляется следующая информация:
? назначенный приоритет;
? оценка степени воздействия и требующихся затрат;
? категория;
? рекомендации Руководителя Процесса Управления Изменениями;
? дата и время авторизации изменения;
? запланированная дата проведения;
? план возврата к исходному состоянию;
? требования по поддержке;
? план проведения изменения;
? информация о разработчике и сотрудниках, ответственных за проведение изменения;
? фактическая дата и время проведения изменения;
? дата проведения оценки результатов;
? результаты испытания и обнаруженные проблемы;
? причины отклонения Запроса (если необходимо);
? оценка результатов.
7.4.3. Классификация
После приема Запроса на Изменения (RFC) определяются его приоритет и категория.
? Приоритет показывает, насколько важным является данный Запрос по сравнению с другими. Это, в свою очередь, определяется его срочностью и степенью воздействия. Если изменение касается исправления известной ошибки, код приоритета уже может быть назначен Управлением Проблемами. Однако Управление Изменениями назначает окончательный код приоритета после рассмотрения других обрабатываемых Запросов.
? Управление Изменениями присваивает категорию, исходя из степени воздействия и требуемых ресурсов. Эта классификация определяет дальнейшие процедуры обработки Запроса и обозначает важность изменения.
Определение приоритета
Пример системы кодирования приоритетов:
? Низкий приоритет – изменение желательно, но его внедрение может быть отложено до более удобного времени (например, до следующего релиза или планового обслуживания).
? Обычный приоритет – нет особой срочности и высокой степени воздействия, но изменение не следует откладывать. На совещании Консультативного комитета (CAB) при выделении ресурсов изменению присваивается обычный приоритет.
? Высокий приоритет – изменение касается серьезной ошибки, затрагивающей ряд пользователей, или новой нетипичной ошибки, затрагивающей большую группу пользователей, или связано с другими срочными вопросами. Такому изменению на ближайшем совещании CAB присваивается высокий приоритет.
? Наивысший приоритет – Запрос на Изменения (RFC) касается проблемы, серьезно влияющей на важнейший для заказчиков сервис, или касается срочного изменения в ИТ (например, новой функциональности для целей бизнеса), срочного изменения законодательства или быстрых небольших изменений, не терпящих отсрочки[110]110
Quick Fix.
[Закрыть]. Изменения с таким приоритетом классифицируются как «срочные». Для срочных изменений обычные процедуры не используются, так как необходимые ресурсы предоставляются незамедлительно. Может потребоваться проведение срочного совещания Консультативного комитета (CAB) или Руководящего комитета ИТ[111]111
IT Steering Committee.
[Закрыть]. Специально для этих целей в компании должен быть сформирован Комитет по срочным изменениям (CAB/ЕС)[112]112
Emergency Committee.
[Закрыть] с полномочиями для принятия экстренных решений. Все принятые ранее планы могут быть отложены или прерваны.
Эти коды могут быть представлены в цифрах, например: низкий приоритет = 1 / наивысший приоритет = 4.
Определение категории
Категории определяются в рамках Процесса Управления Изменениями, в случае необходимости с участием Консультативного комитета (CAB), который определяет степень воздействия изменения и требования, предъявляемые им к ИТ-организации (в первую очередь, выделение ресурсов). Примеры категорий:
? Низкая степень воздействия – изменение, требующее выполнения небольшого объема работ. Руководитель Процесса Управления Изменениями может авторизовать эти изменения без привлечения Консультативного комитета (CAB).
? Существенная степень воздействия – изменение, требующее значительных усилий и оказывающее существенное воздействие на ИТ-услуги. Эти изменения обсуждаются на совещании Консультативного комитета (CAB) для определения необходимых усилий (ресурсов и др.) и потенциального воздействия. Перед совещанием членам Консультативного комитета (CAB) и, возможно, специалистам и разработчикам направляется соответствующая документация.
? Наивысшая степень воздействия – изменение, требующее значительных усилий. Руководителю Процесса необходимо предварительно получить авторизацию на выполнение изменения от руководства ИТ или Руководящего комитета ИТ, после чего изменение представляется на рассмотрение Консультативного комитета (CAB).
Эти коды могут быть представлены в цифрах, например: низкая степень = 1 / высшая степень = 3.
Большинство изменений относятся к двум первым категориям. В добавление к классификации должны быть также определены группы, участвующие в работе над техническим решением, и услуги, затрагиваемые изменением.
7.4.4. Планирование
В рамках процесса осуществляется планирование изменений на основе графика, называемого Согласованным планом изменений[113]113
Forward Schedule of Change – FSC.
[Закрыть] (FSC). План FSC содержит подробную информацию обо всех утвержденных изменениях и их планировании. Члены Консультативного комитета (CAB) дают рекомендации по планированию изменений, так как необходимо учитывать наличие персонала, ресурсов, затраты, различные аспекты задействованных услуг, а также мнение заказчиков. Консультативный комитет (CAB) играет роль консультативного органа. В целом Управление Изменениями имеет делегированные полномочия, т. к. оно действует от лица руководства ИТ. Возможно, что изменения наивысшей категории необходимо утверждать руководством ИТ до их представления Консультативному комитету (CAB). Утверждение изменения имеет несколько аспектов:
? Финансовое одобрение – анализ затрат/выгод и выделение бюджета.
? Техническое одобрение – оценка необходимости, возможности проведения изменения и его степени воздействия.
? Бизнес-одобрение – одобрение пользователями требуемой функциональности приложения и степени воздействия изменения.
Для целей эффективного планирования Управление Изменениями должно взаимодействовать с проектным офисом и другими подразделениями компании, занимающимися разработкой и внедрением изменений. Кроме того, достаточное внимание должно уделяться своевременному осведомлению пользователей о планировании изменений, возможно, в виде рассылки Согласованного плана изменений (FSC).
Политика проведения изменений
Изменения по разным Запросам можно объединять в одном релизе. В этом случае при неудачной реализации будет достаточно одного возврата к исходному состоянию[114]114
Back-out.
[Закрыть]. Такой групповой релиз должен рассматриваться как одно изменение, даже если он содержит в себе несколько изменений. Релизы могут планироваться с учетом функциональных задач, необходимых для бизнеса. Они могут охватывать аппаратные и программные средства, и их внедрение осуществляется Процессом Управления Релизами. Рекомендуется определить политику компании в этой области и информировать о ней ИТ-организацию и заказчиков (см. также «Управление Релизами»). Цель политики – оградить пользователя от ненужного беспокойства («перекапывание дороги каждую неделю»).
После консультаций с участвующими ИТ-подразделениями, Консультативный комитет (CAB) может определить регулярные периоды времени ("окна") для проведения изменений, когда степень воздействия на ИТ-сервисы будет минимальной. Подходящими периодами могут быть выходные дни или нерабочее время. Таким же образом могут быть определены периоды, когда допускается минимум изменений или они вообще не допускаются, например, рабочее время или конец финансового года, когда все подразделения пользователей делают отчеты.
Совещания Консультативного комитета (CAB)
Информация о планировании изменений должна распространяться заранее до совещания CAB. Соответствующая документация и информация о пунктах повестки дня также должны рассылаться до совещания.
Повестка дня совещания CAB должна включать ряд постоянных пунктов, в том числе:
? неавторизованные изменения;
? Запросы на Изменения (RFC), которые должны быть оценены членами Консультативного комитета (CAB);
? авторизованные изменения, которые не были представлены на рассмотрение консультативного комитета (CAB);
? открытые и закрытые изменения;
? оценка произведенных изменений.
Оценка степени воздействия и ресурсов
При оценке необходимых ресурсов и степени воздействия изменения члены Консультативного комитета (CAB), Руководитель Процесса Управления Изменениями и другие участники (определенные Консультативным комитетом) должны учесть следующие аспекты:
? вопросы возможностей ("мощности" или "емкости") подвергающихся воздействию услуг;
? надежность и возможность восстановления;
? планы по Управлению Непрерывностью ИТ-услуг;
? планы возврата к исходному состоянию;
? вопросы безопасности;
? степень воздействия изменения на другие ИТ-сервисы;
? регистрация изменения и его предварительное одобрение;
? необходимые ресурсы и затраты (поддержка и обслуживание);
? количество и наличие необходимых специалистов;
? необходимое время на весь цикл изменения;
? новые ресурсы, которые должны быть закуплены и пройти тестирование;
? степень воздействия на текущую операционную деятельность;
? какие-либо возможные конфликты с другими изменениями.
Члены Консультативного комитета (CAB) могут также дать рекомендации по определению приоритета изменения.
7.4.5. Координация
Об утвержденных изменениях сообщают соответствующим техническим специалистам, которые будут разрабатывать и внедрять эти изменения. Перед внедрением происходит этап тестирования. В разработке, испытании и внедрении утвержденных изменений важную роль может играть Процесс Управления Релизами. Большое внимание должно уделяться вопросам информирования персонала внутри компании для поддержки изменений.
Подготовка изменения[115]115
Building.
[Закрыть]
Не все изменения проходят отдельную фазу компоновки. Например, стандартные изменения, такие как перемещение персональных компьютеров, могут планироваться и осуществляться незамедлительно.
Компоновка может включать создание новой версии программы с новой документацией, руководствами, инсталляционными процедурами, планом возврата к исходному состоянию и аппаратными изменениями. Управление Изменениями осуществляет контроль и координацию, его поддерживают Процесс Управления Релизами и руководители линейных подразделений, которые обеспечивают предоставление необходимых ресурсов.
Процедура возврата к исходному состоянию должна разрабатываться как часть общей схемы проведения изменения на случай, если изменение не обеспечивает достижение необходимого результата. Управление Изменениями не должно одобрять проведение изменения при отсутствии процедуры возврата. Если изменение влияет на среду пользователя, должен быть составлен коммуникационный план. План внедрения изменения также составляется на стадии компоновки.
Показатели эффективности[116]116
Performance Indicators.
[Закрыть] демонстрируют, насколько успешно Процесс Управления Изменениями осуществляет эффективную и рациональную обработку изменений при минимальном возможном отрицательном воздействии на согласованный Уровень Услуг. Эти показатели охватывают такие параметры, как:
? количество завершенных изменений за определенный промежуток времени в разбивке по категориям;
? скорость проведения изменений;
? количество отклоненных изменений;
? количество инцидентов, вызванных изменениями;
? количество возвратов к исходному состоянию, связанных с проведением изменений;
? затраты на произведенные изменения;
? соотношение между расчетными и фактическими затратами ресурсов и времени;
? количество срочных изменений.
Тестирование
Процедура возврата к исходному состоянию, план внедрения изменения и ожидаемый результат должны проходить тщательную проверку. При этом необходимо учитывать критерии, определенные ранее консультативным комитетом (CAB). В большинстве случаев для испытаний необходима изолированная тестовая среда или лаборатория. Тестирование на ранних стадиях может производиться разработчиками, однако внедрение изменений не может осуществляться без проведения независимого тестирования. Обычно проводится два вида испытаний: приемо-сдаточные испытания для пользователей, при которых представители бизнес-подразделений (обычно заказчики изменения) проверяют его функциональные характеристики, и операционные (эксплуатационные) испытания[117]117
Operational Acceptance.
[Закрыть], при которых независимое тестирование проводят те, кто должен поддерживать и обслуживать новую инфраструктуру. Сюда включаются также отделы технической поддержки и Служба Service Desk. Они проверяют соответствующую документацию, процедуры резервного восстановления данных (back-up) и т. д. Необходимы также четкие инструкции для мониторинга качества тестирования и документирования его результатов.
Внедрение[118]118
Implementing.
[Закрыть]
Любой сотрудник соответствующего подразделения, ответственный за администрирование ИТ-инфраструктуры, может получить задание о непосредственном проведении (внедрении) изменения. Управление Изменениями гарантирует, что это является запланированным изменением. Должен существовать точный план информирования всех вовлеченных сотрудников о проведении изменения (коммуникационный план), например, пользователей, Службы Service Desk, группы администрирования сетей и т. п.
При невозможности проведения необходимого тестирования возможно внедрение изменения для небольшой пилотной группы пользователей и оценка полученных результатов перед внедрением изменения в более широком масштабе.
7.4.6. Оценка
Необходимо давать оценку произведенным изменениям, за возможным исключением стандартных изменений. При необходимости Консультативный комитет (CAB) принимает решение о проведении последующих дополнительных мероприятий. Должны быть рассмотрены следующие вопросы:
? Привело ли изменение к достижению намеченной цели?
? Удовлетворены ли пользователи результатом?
? Возникали ли какие-либо побочные эффекты?
? Были ли превышены расчеты по затратам и ресурсам?
Если изменение осуществлено успешно, Запрос на Изменение (RFC) может быть закрыт. Это происходит на этапе Анализа результатов внедрения[119]119
Post Implementation Review – PIR.
[Закрыть] (PIR), т. е. этапе оценки изменения. Если же изменение закончилось неудачно, процесс возобновляется с того места, где он вызвал сбой, с использованием нового подхода. Иногда бывает лучше сделать возврат назад и создать новый или модифицированный Запрос на Изменения (RFC). Продолжение работы с неудачным изменением часто приводит к ухудшению ситуации.
Процедуры с автоматическим отслеживанием времени гарантируют, что этап оценки изменений не будет пропущен. В зависимости от природы изменения оценку можно проводить или через несколько дней, или через несколько месяцев. Например, оценка изменения в использующемся ежедневно персональном компьютере может быть совершена через несколько дней, а изменение в системе, использующейся раз в неделю, может быть сделана только через три месяца.
7.4.7. Проведение срочных изменений
Как бы хорошо ни проводилось планирование, могут быть изменения, требующие наивысшего приоритета. Срочные изменения очень важны для компании и они должны осуществляться как можно скорее. В большинстве случаев на эти изменения направляют ресурсы, предназначенные для других видов деятельности. Срочные изменения могут серьезно повлиять на запланированную работу. Следовательно, задачей является сведение к минимуму числа срочных или неожиданных изменений (с "наивысшим" приоритетом). Возможные превентивные меры включают:
? обеспечение своевременной подачи Запросов на Изменения, пока они не стали срочными.
? при исправлении ошибок, возникших в результате плохой подготовки изменений, возврат не должен заходить дальше прежней версии, то есть дальше Прежнего стабильного состояния[120]120
Previous Trusted State.
[Закрыть]. После возврата следует тщательно подготовить новый улучшенный план изменения.
Несмотря на указанные выше меры срочные изменения все же могут возникнуть. Они требуют процедур для срочной обработки, но с сохранением общего контроля со стороны Процесса Управления Изменениями. В случае возникновения такой ситуации Руководитель Процесса Управления Изменениями может организовать чрезвычайное совещание комитета CAB/ЕС. Если для этого нет времени или если Запрос поступил в нерабочее время, должен существовать альтернативный способ получения авторизации изменения. Это не обязательно должна быть встреча "лицом к лицу", вместо нее можно провести телефонную конференцию.
Пример этого был упомянут в главе по Управлению Инцидентами, когда экстренный ремонт может быть предложен для разрешения серьезного инцидента. Если дело обстоит очень плохо и отсрочка неприемлема, необходимо следовать процедуре обработки срочного Запроса на Изменение.
Возможна также нехватка времени для проведения нормального тестирования. Например, рабочая станция управляет большой машиной, которая смешивает крахмал для приготовления таблеток в фармацевтическом производстве. Если рабочая станция не будет исправлена в течение часа, крахмал затвердеет, и для его удаления вручную, с помощью молотка и зубила, потребуется работа двух человек в течение двух недель. В это время компания будет терпеть убытки в тысячи долларов за час, так как препараты не будут производиться. При такой ситуации Руководитель Процесса Управления Изменениями должен оценить риски и принять решение о проведении изменения. После этого должны быть пройдены все необходимые этапы нормального процесса для гарантии того, что все пропущенные испытания теперь проведены, вся информация обновлена (произведена регистрация изменений в базе данных CMDB) и что все изменения отслеживаются.
7.5 Контроль процесса
7.5.1 Отчеты для руководства
Задачей Процесса Управления Изменениями является достижение баланса между гибкостью и стабильностью. Для характеристики текущей ситуации в организации могут быть использованы следующие отчеты:
? количество проведенных изменений за определенный период времени (всего и по категориям Конфигурационных Единиц);
? перечень причин изменений и перечень Запросов на Изменения;
? количество успешно внедренных изменений;
? количество возвратов к исходному состоянию и их причины;
? количество инцидентов, связанных с проведенными изменениями;
? графики и анализ тенденций за соответствующие периоды.
Показатели эффективности[121]121
Performance Indicators.
[Закрыть] определяют, насколько успешно Процесс Управления Изменениями осуществляет эффективную[122]122
Effective.
[Закрыть] и рациональную[123]123
Efficient.
[Закрыть] обработку изменений при минимальном отрицательном воздействии на согласованный Уровень Услуг. Эти показатели могут быть следующими:
? количество изменений, завершенных за единицу времени, по категориям;
? скорость проведения изменений;
? количество отклоненных изменений;
? количество инцидентов, вызванных изменениями;
? количество возвратов к исходному состоянию, связанных с изменениями;
? затраты на проведенные изменения;
? количество изменений, осуществленных в рамках расчетных затрат ресурсов и времени.
7.6. Затраты и проблемы
7.6.1. Затраты
? Затраты на персонал – в большинстве случаев уже имеется персонал, занимающийся координацией изменений. Однако для выполнения задач Руководителя Процесса Управления Изменениями и организации работы Консультативного комитета по изменениям (CAB) возможны дополнительные расходы на персонал. Во многих случаях Управление Изменениями вводится для повышения качества услуг, и возникшие дополнительные расходы рассматриваются как расходы на качество. После успешного запуска процесса расходы на координацию изменений компенсируются уменьшением расходов на разрешение инцидентов и проблем.
? Затраты на инструментальные средства – расходы на аппаратное и программное обеспечение должны определяться заранее. Часто при внедрении нескольких процессов закупается общее инструментальное средство для Процессов Управления Изменениями, Проблемами, Конфигурациями и Инцидентами. При работе в сложной ИТ-среде почти невозможно контролировать эти процессы без такого инструментального средства.
7.6.2. Проблемы
При внедрении Процесса Управления Изменениями возможно появление следующих проблем:
? Работа без средств автоматизации слишком трудоемка, она будет создавать много проблем.
? Возможно сопротивление всеохватывающему Процессу Управления Изменениями, осуществляющему мониторинг всех аспектов ИТ-инфраструктуры. В этом случае необходимо обучение персонала, который должен осознать, что все компоненты ИТ-инфраструктуры могут оказывать значительное влияние друг на друга, и что реализуемые изменения Конфигурации требуют общей координации.
? Возможны попытки проведения изменений в обход согласованных процедур. Абсолютно необходимо, чтобы такие попытки встречали соответствующую реакцию со стороны компании. Целостность Процесса Управления Изменениями зависит от полного соответствия процедурам. Претензии сотрудников и предложения по усовершенствованию Процесса Управления Изменениями должны пониматься и приветствоваться, однако неподчинение необходимо решительно пресекать, иначе весь процесс будет поставлен под угрозу.
? Другие способы обеспечения исполнения процедур по Управлению Изменениями включают:
? проведение регулярного аудита, возможно, независимым инспектором, для оценки соответствия процедурам Управления Изменениями;
? осуществление контроля со стороны руководства над внутренним и внешним обслуживающим персоналом и разработчиками;
? обеспечение контроля за всеми Конфигурационными Единицами и версиями программ путем защиты базы данных CMDB и организации регулярного аудита Конфигураций в рамках Процесса Управления Конфигурациями;
? предоставление информации из Управления Инцидентами о фактах доступа пользователей к аппаратному и программному обеспечению, не отраженного в CMDB;
