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

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

• 1. Регистрация запросов на изменение из процесса управления заявками пользователей (процесс управления инцидентами);
• 2. Классификация, согласование, оценка и визирование запросов на изменение;
• 3. Организация установки разработанных изменений в продуктивную среду.

Объектами процесса являются сущности, жизненный цикл которых [5], полный или частичный, сопровождается при помощи настоящего процесса (рис. 2). информационный скорость качество обслуживание Менеджер процесса производит классификацию запроса на изменение по следующим параметрам:

• 1) ИТ-система или ИТ-услуга. Необходимо точно и однозначно определить, к какой ИТ-системе или ИТ-услуге относится данное изменение [6, 7]. Однозначность определения необходима для последующего формирования релизов [8, 9].
• 2) Определить возможную необходимость изменений в смежных ИТ-системах [10, 11], в том числе в ИТ-системах внешних партнеров, при изменении в интерфейсах и/или форматах передаваемых и принимаемых данных.

Рис. 2. Схема запроса на изменение компании «О'КЕЙ»

3) Ожидаемая дата внедрения данного изменения в продуктивную среду [12, 13] для конечного пользователя. Данный параметр необходим для группировки нескольких запросов на изменение в единый релиз, выпускаемый к строго определенной дате. При этом также необходимо учитывать, повлечет ли данное изменение «стабилизационный» период, при котором необходимо будет временно выводить ИТ-систему из промышленной эксплуатации в опытно-промышленную.

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

На следующем этапе проводится согласование технической возможности проведения данного изменения, оценка трудозатрат, необходимости привлечения внешних дополнительных ресурсов [16, 17] и т. д. Также обсуждаются и утверждаются технологии, включая смежные [18, 19], с помощью которых будет достигнут результат изменения.

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

На этапе визирования производится окончательное утверждение данного изменения со стороны спонсора. Менеджер процесса управления изменениями представляет бизнес-спонсору окончательные результаты согласования изменения с технической стороны. Бизнес-спонсор утверждает (либо отклоняет) согласованную оценку стоимости и сроков [20, 21]. При положительном решении запрос на изменение переходит в статус «В разработке».

После того, как разработанное и протестированное изменение установлено в продуктивную среду начинается этап анализа и оценки результатов [22, 23]. При этом может быть определен «стабилизационный» период, при котором меняется статус измененной ИТ-системы (из промышленной эксплуатации в опытно-промышленную, либо наоборот). Изменение статуса ИТ-системы в первую очередь влияет на диспетчеризацию потока заявок от пользователей ИТ-системы. На этапе анализа и оценки результатов проводится полный анализ достижения желаемого результата, оценка реализации [24, 25] и подтверждение, что сроки и стоимость изменений были соблюдены в точности. В случае, если результаты не удовлетворяют бизнес-спонсора данного изменения, возможно, инициировать возврат ИТ-системы к предыдущей версии.

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

При положительном результате анализа и оценки результатов инициируется процедура закрытия запроса на изменения. На этом этапе уточняется и финализируется вся документация по изменению. Менеджер процесса проверяет наличие ссылок на версию релиза, документально подтверждает согласие бизнес-спонсора с результатами изменений [26, 27].

Последним шагом является перевод запроса на изменение в статус «Закрыт». После перевода в статус «Закрыт» запрос на изменение становится архивным и изменению не подлежит. И, как уже было указано ранее, при формулировке уникальных знаний в процессе изменения создается новая статья в базе знаний [28, 29].