О процессе управления изменениями

4.1. Политики процесса

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

Целями процесса управления изменениями в данной редакции являются:

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

· убедиться в том, что все изменения были оценены, утверждены, реализованы и рассмотрены в управляемом режиме.

Основными участниками процесса являются следующие роли:

· Пользователь;

· Контактное лицо;

· Диспетчер ООЗ;

· Ответственный по группе, он же координатор изменения;

· Аналитик изменения (исполнитель задач);

· Менеджер процесса управления изменениями по направлению, проблемами, инцидентами.

1. Процесс управления изменениями является единым для всех подразделений, вовлеченных в предоставление ИТ-услуг.

2. Автоматизация процесса управления изменениями в АСУ ИТУ реализуется с использованием следующих объектов:

· Изменение;

· Задача (по изменению).

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

4. Изменение может быть зарегистрировано:

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

§ по инициативе второй линии поддержки и других подразделений службы ИТ.

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

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

7. В рамках процесса управления изменениями может быть установлена связь с другими процессами управления:

· между записями об инцидентах, записями о проблемах, записями о обращениях.

8. Изменение закрывается в одном из следующих случаев:

· Оно было успешно выполнено;

· Изменение является дублем;

· Координатор изменения принял решение о нецелесообразности дальнейшей обработки изменения.

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

10. За контроль соблюдения технологии и совершенствование процесса отвечают менеджеры процесса по направлению.

11. Ключевые показатели эффективности (КПЭ) собираются с целью:

· оценки качества работы подразделений службы ИТ и систем;

· регулярного совершенствования процесса управления изменениями.

4.2. Описание процесса

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

На данном этапе в процессе определена единственная категория изменения ”Стандартное изменение”, которая состоит из трех фаз: Регистрация, Выполнение, Закрытие.

4.3.Фаза “Регистрация”

4.3.1. Обработка обращения пользователя

4.3.2. Создание нового RFC

4.3.3. Назначение RFC на группу исполнителей

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

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

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

· Инициатор – ФИО инициатора изменения (пользователя из обращения);

· Номер (уникальный ID) изменения;

· Начальный статус = “Открыто”;

· Начальная фаза = “Регистрация”;

· Краткое описание из обращения;

· Детальное описание из обращения;

· Координатор изменения = ответственный по группе.

4.3.4. Проверка назначения

4.3.5. Внесение дополнительной информации

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

4.3.6. Открытие RFC

Ответственный по группе проводит анализ всех вновь поступивших инцидентов и определяет, является ли инцидент изменением.

Если установлено, что инцидент является изменением, ответственный по группе должен закрыть данный инцидент с кодом ”Работы выполняются в рамках процесса Change Management”. В таком случае, связанное обращение автоматически не закрывается, а ответственный по группе должен в ручном режиме зарегистрировать изменение для связанного обращения.

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

4.3.7. Верификация изменения

4.3.8. Верификация успешна?

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

Координатор изменения обязан проводить анализ всех изменений, направленных в его группу.

Если информация предоставлена не в полном объеме, координатор обязан связаться с инициатором изменения и запросить дополнительные сведения.

4.3.9. Переход к фазе “Закрытие”

Координатор изменения должен закрыть изменение, если оно не соответствует политикам и стандартам применяемым в компании, либо, изменение не является логичным или выполнимым. Для закрытия изменения, необходимо перейти к фазе “Закрытие”.

4.3.10. Анализ изменения/анализ трудозатрат

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

4.3.11. Переход к фазе “Выполнение”

После того, как работы по регистрации изменения были выполнены, необходимо закрыть фазу ”Регистрации” и перейти к следующей фазе.

4.4. Фаза “Выполнение”

4.4.1. Детальный анализ выполнения изменения

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

4.4.2. Создание заданий на выполнение изменения

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

При создании задачи автоматически копируются из изменения и могут быть уточнены координатором:

· краткое описание задачи;

· подробное описание задачи;

· плановое начало;

· плановое окончание;

· плановые трудозатраты;

· рабочая группа.

Координатор может скорректировать описание задачи для аналитика.

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

Координатор может откорректировать рабочую группу.

4.4.3. Выполнение работ по заданию

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

Ответственный по группе или исполнитель проводит анализ сути задачи в целях:

· определения правильности назначения в рабочую группу;

· определения исполнителя.

В рамках анализа может использоваться информация, указанная в задаче.

Если задача направлена неверно, ответственный по группе или исполнитель выполняет следующие действия:

· протоколирует причину отклонения в протоколе, в т.ч. указывает рекомендации по назначению и/или составу работ;

· закрывает задачу с кодом «Отклонено».

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

Исполнитель всегда автоматически информируется по электронной почте о назначении на него новой задачи.

После назначения исполнителя задачи он выполняет следующие действия:

· проводит анализ полученной задачи (поле " Краткое описание", " Описание",, протокол и пр.);

· устанавливает статус «В работе» (при этом автоматически устанавливается дата/время принятия в работу);

· приступает к выполнению необходимой работы.

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

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

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

4.4.4. Закрытие задания

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

· контролирует правильность оформления задачи, при необходимости вносит корректировки (код закрытия; КЕ, над которыми велись работы и т.д.);

· проверяет актуальность CMDB в части КЕ, которые были изменены в рамках выполнения работ;

· указывает фактические трудозатраты, связанные с выполнением задачи;

· меняет статус задачи на «Выполнена» (дата/время выполнения работы отмечается автоматически).

Комментарий: выполненные задачи в системе недоступны для редактирования никому, кроме менеджера процесса и администратора АСУ ИТУ.

4.4.5. Контроль выполнения заданий

4.4.6. Верификация заданий

4.4.7. Переход к фазе “Закрытие”

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

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

4.5. Фаза ”Закрытие”

4.5.1. Верификация изменения

4.5.2. Внесение комментария и установка кода закрытия изменения

Координатор изменения должен проконтролировать:

· корректность внесенных изменений в CMDB, при необходимости внесения изменений в БД;

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

Координатор должен ввести поясняющий комментарий в поле ”Решение для пользователей” и установить соответствующий код закрытия.