Прием в обработку

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

Проведение изменения ведет за собой обновление в базе данных CMDB, например:

§  изменение статуса существующей Конфигурационной Единицы;

§  изменение взаимосвязи между различными Конфигурационными Единицами;

§  новая Конфигурационная Единица или изменение существующей Конфигурационной Единицы;

§  новый владелец или другое месторасположение Конфигурационной Единицы.

Если Запрос на Изменения (RFC) принимается в работу, в регистрационную запись изменения включается информация, необходимая для дальнейшей обработки изменения. Позднее к записи добавляется следующая информация:

§  назначенный приоритет;

§  оценка степени воздействия и требующихся затрат;

§  категория;

§  рекомендации Руководителя Процесса Управления Изменениями;

§  дата и время авторизации изменения;

§  запланированная дата проведения;

§  план возврата к исходному состоянию;

§  требования по поддержке;

§  план проведения изменения;

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

§  фактическая дата и время проведения изменения;

§  дата проведения оценки результатов;

§  результаты испытания и обнаруженные проблемы;

§  причины отклонения Запроса (если необходимо);

§  оценка результатов.

Классификация

После приема Запроса на Изменения (RFC) определяются его приоритет и категория.

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

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

Определение приоритета

Пример системы кодирования приоритетов:

§  Низкий приоритет — изменение желательно, но его внедрение может быть отложено до более удобного времени (например, до следующего релиза или планового обслуживания).

§  Обычный приоритет — нет особой срочности и высокой степени воздействия, но изменение не следует откладывать. На совещании Консультативного комитета (CAB) при выделении ресурсов изменению присваивается обычный приоритет.

§  Высокий приоритет — изменение касается серьезной ошибки, затрагивающей ряд пользователей, или новой нетипичной ошибки, затрагивающей большую группу пользователей, или связано с другими срочными вопросами. Такому изменению на ближайшем совещании CAB присваивается высокий приоритет.

§  Наивысший приоритет — Запрос на Изменения (RFC) касается проблемы, серьезно влияющей на важнейший для заказчиков сервис, или касается срочного изменения в ИТ (например, новой функциональности для целей бизнеса), срочного изменения законодательства или быстрых небольших изменений, не терпящих отсрочки. Изменения с таким приоритетом классифицируются как «срочные». Для срочных изменений обычные процедуры не используются, так как необходимые ресурсы предоставляются незамедлительно. Может потребоваться проведение срочного совещания Консультативного комитета (CAB) или Руководящего комитета ИТ. Специально для этихцелей в компании должен быть сформирован Комитет по срочным изменениям (CAB/ЕС) с полномочиями для принятия экстренных решений. Все принятые ранее планы могут быть отложеныили прерваны.

Эти коды могут быть представлены в цифрах, например: низкий приоритет = 1 / наивысший приоритет = 4.

Определение категории

Категории определяются в рамках Процесса Управления Изменениями, в случае необходимости с участием Консультативного комитета (CAB), который определяем степень воздействия изменения и требования, предъявляемые им к ИТ-организации (в первую очередь, выделение ресурсов). Примеры категорий: