ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL

? Руководителя по Управлению Изменениями (председатель);

? Руководитель по Управлению (Уровнями) Услуг;

? Представителей Службы Service Desk и Процесса Управления Проблемами;

? Руководителей линейных подразделений компании;

? Бизнес-руководителей (или их представители) со стороны заказчика;

? Представителей пользователей;

? Представителей разработчиков приложений;

? Администраторов программного обеспечения и системных администраторов;

? Представителей поставщиков.

Охват (сфера действия или границы) [104] процесса

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

104

Scope.

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

Одним из способов выполнения таких действий является определение так называемых "предвари­тельно авторизованных" [105] изменений (или "категории 0"), которые записываются в базу данных из­менений (предпочтительно самими запрашивающими), но не требуют использования процедур по Управлению Изменениями. Например, если при приеме на работу нового сотрудника обычно вы­полняются четырнадцать действий (создание новой учетной записи [106] , настройка рабочей станции, электронной почты и т. д.), то эти действия не требуют столь внимательного изучения, как значи­тельные изменения инфраструктуры. Такой вид стандартных изменений обрабатывается по типово­му шаблону как предварительно авторизованный "Запрос на Обслуживание".

105

Pre-authorized.

106

Account.

7.2. Цель процесса

Целью Процесса Управления Изменениями является гарантия использования стандартных методов и процедур для быстрой обработки изменений с минимальным возможным отрицательным воздей­ствием изменения на качество услуг. Все изменения должны быть отслеживаемыми, чтобы можно было ответить на вопрос: "Что изменилось?"

7.2.1. Преимущества использования процесса

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

Преимуществами Процесса Управления Изменениями являются:

? уменьшение отрицательного воздействия изменений на качество ИТ-услуг;

? более точные оценки затрат для предлагаемых изменений;

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

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

? повышение производительности работы пользователей за счет более высокой стабильности и ка­чества ИТ-услуг;

? повышение производительности работы ИТ-персонала, не отрывающегося от плановой работы для проведения срочных изменений и процедур возврата;

? рост способности компании проводить частые изменения без нарушения стабильности ИТ-среды.

7.3. Процесс

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

Рис. 7.2. Позиционирование Процесса Управления Изменениями

Входы Процесса Управления Изменениями включают в себя:

? Запросы на Изменения (RFC);

? информация из базы данных CMDB (в частности, анализ степени воздействия изменений);

? информация из других процессов (из Базы данных мощностей CDB, информация о бюджете и т. д.);

? планирование изменений (Согласованный план изменений [107] FSC).

107

Forward Schedule of Change – FSC.

Выходы процесса включают:

? обновленный план изменений (Согласованный план изменений FSC);

? моменты инициирования действий (триггеры) в рамках Процессов Управления Конфигурациями и Управления Релизами;

? повестка дня Консультативного комитета CAB, протоколы и принятые решения;

? отчеты по Процессу Управления Изменениями.

Управление Изменениями имеет описанную ниже взаимосвязь с другими процессами.

7.3.1. Управление Инцидентами

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

7.3.2. Управление Конфигурациями

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

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

7.3.3. Управление Проблемами

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

7.3.4. Управление Релизами

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