Ян Ван Бон - ИТ Сервис-менеджмент. Введение

• Законодательство– если возникают ограничения, регламентирующие бизнес-деятельность, или вводятся новые требования по ИТ-безопасности, непрерывности бизнес-процессов и Управлению Лицензиями.

• Поставщики– поставщики выпускают новые версии и модификации [109] Upgrades. своих продуктов и сообщают об исправленных ими ошибках. Они могут сообщить, что больше не поддерживают определенные версии или что не могут гарантировать производительность версии (например, из-за «Ошибки тысячелетия» – Millennium bug). Это может дать толчок Процессам Управления Проблемами или Управления Доступностью к подаче Запроса на Изменения (RFC).

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

• Любой другой сотрудник ИТ- в принципе, любой сотрудник может подать предложения по улучшению услуг. В особенности, ИТ-персонал может способствовать усовершенствованию процедур по поддержке и предоставлению услуг и обновлению руководств.

Регистрация Запросов на Изменения

Вот примеры информации, которая может включаться в Запросы на Изменения (RFC):

• идентификационный номер Запроса;

• номер проблемы/известной ошибки (если имеется), связанной с Запросом;

• описание и определение соответствующих Конфигурационных Единиц (CI);

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

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

• имя, адрес и номер телефона лица, направляющего Запрос;

• дата подачи;

• предварительная оценка необходимых ресурсов и времени.

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

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

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

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

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

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

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

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

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

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

• категория;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Наивысший приоритет– Запрос на Изменения (RFC) касается проблемы, серьезно влияющей на важнейший для заказчиков сервис, или касается срочного изменения в ИТ (например, новой функциональности для целей бизнеса), срочного изменения законодательства или быстрых небольших изменений, не терпящих отсрочки [110] Quick Fix. . Изменения с таким приоритетом классифицируются как «срочные». Для срочных изменений обычные процедуры не используются, так как необходимые ресурсы предоставляются незамедлительно. Может потребоваться проведение срочного совещания Консультативного комитета (CAB) или Руководящего комитета ИТ [111] IT Steering Committee. . Специально для этих целей в компании должен быть сформирован Комитет по срочным изменениям (CAB/ЕС) [112] Emergency Committee. с полномочиями для принятия экстренных решений. Все принятые ранее планы могут быть отложены или прерваны.

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

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

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

• Низкая степень воздействия– изменение, требующее выполнения небольшого объема работ. Руководитель Процесса Управления Изменениями может авторизовать эти изменения без привлечения Консультативного комитета (CAB).

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