Ян Ван Бон - ИТ Сервис-менеджмент. Введение
• назначенный приоритет;
• оценка степени воздействия и требующихся затрат;
• категория;
• рекомендации Руководителя Процесса Управления Изменениями;
• дата и время авторизации изменения;
• запланированная дата проведения;
• план возврата к исходному состоянию;
• требования по поддержке;
• план проведения изменения;
• информация о разработчике и сотрудниках, ответственных за проведение изменения;
• фактическая дата и время проведения изменения;
• дата проведения оценки результатов;
• результаты испытания и обнаруженные проблемы;
• причины отклонения Запроса (если необходимо);
• оценка результатов.
7.4.3. Классификация
После приема Запроса на Изменения (RFC) определяются его приоритет и категория.
• Приоритет показывает, насколько важным является данный Запрос по сравнению с другими. Это, в свою очередь, определяется его срочностью и степенью воздействия. Если изменение касается исправления известной ошибки, код приоритета уже может быть назначен Управлением Проблемами. Однако Управление Изменениями назначает окончательный код приоритета после рассмотрения других обрабатываемых Запросов.
• Управление Изменениями присваивает категорию, исходя из степени воздействия и требуемых ресурсов. Эта классификация определяет дальнейшие процедуры обработки Запроса и обозначает важность изменения.
Определение приоритета
Пример системы кодирования приоритетов:
• Низкий приоритет – изменение желательно, но его внедрение может быть отложено до более удобного времени (например, до следующего релиза или планового обслуживания).
• Обычный приоритет – нет особой срочности и высокой степени воздействия, но изменение не следует откладывать. На совещании Консультативного комитета (CAB) при выделении ресурсов изменению присваивается обычный приоритет.
• Высокий приоритет – изменение касается серьезной ошибки, затрагивающей ряд пользователей, или новой нетипичной ошибки, затрагивающей большую группу пользователей, или связано с другими срочными вопросами. Такому изменению на ближайшем совещании CAB присваивается высокий приоритет.
• Наивысший приоритет – Запрос на Изменения (RFC) касается проблемы, серьезно влияющей на важнейший для заказчиков сервис, или касается срочного изменения в ИТ (например, новой функциональности для целей бизнеса), срочного изменения законодательства или быстрых небольших изменений, не терпящих отсрочки[110]. Изменения с таким приоритетом классифицируются как «срочные». Для срочных изменений обычные процедуры не используются, так как необходимые ресурсы предоставляются незамедлительно. Может потребоваться проведение срочного совещания Консультативного комитета (CAB) или Руководящего комитета ИТ[111]. Специально для этих целей в компании должен быть сформирован Комитет по срочным изменениям (CAB/ЕС)[112] с полномочиями для принятия экстренных решений. Все принятые ранее планы могут быть отложены или прерваны.
Эти коды могут быть представлены в цифрах, например: низкий приоритет = 1 / наивысший приоритет = 4.
Определение категории
Категории определяются в рамках Процесса Управления Изменениями, в случае необходимости с участием Консультативного комитета (CAB), который определяет степень воздействия изменения и требования, предъявляемые им к ИТ-организации (в первую очередь, выделение ресурсов). Примеры категорий:
• Низкая степень воздействия – изменение, требующее выполнения небольшого объема работ. Руководитель Процесса Управления Изменениями может авторизовать эти изменения без привлечения Консультативного комитета (CAB).
• Существенная степень воздействия – изменение, требующее значительных усилий и оказывающее существенное воздействие на ИТ-услуги. Эти изменения обсуждаются на совещании Консультативного комитета (CAB) для определения необходимых усилий (ресурсов и др.) и потенциального воздействия. Перед совещанием членам Консультативного комитета (CAB) и, возможно, специалистам и разработчикам направляется соответствующая документация.
• Наивысшая степень воздействия – изменение, требующее значительных усилий. Руководителю Процесса необходимо предварительно получить авторизацию на выполнение изменения от руководства ИТ или Руководящего комитета ИТ, после чего изменение представляется на рассмотрение Консультативного комитета (CAB).
Эти коды могут быть представлены в цифрах, например: низкая степень = 1 / высшая степень = 3.
Большинство изменений относятся к двум первым категориям. В добавление к классификации должны быть также определены группы, участвующие в работе над техническим решением, и услуги, затрагиваемые изменением.
7.4.4. Планирование
В рамках процесса осуществляется планирование изменений на основе графика, называемого Согласованным планом изменений[113] (FSC). План FSC содержит подробную информацию обо всех утвержденных изменениях и их планировании. Члены Консультативного комитета (CAB) дают рекомендации по планированию изменений, так как необходимо учитывать наличие персонала, ресурсов, затраты, различные аспекты задействованных услуг, а также мнение заказчиков. Консультативный комитет (CAB) играет роль консультативного органа. В целом Управление Изменениями имеет делегированные полномочия, т. к. оно действует от лица руководства ИТ. Возможно, что изменения наивысшей категории необходимо утверждать руководством ИТ до их представления Консультативному комитету (CAB). Утверждение изменения имеет несколько аспектов:
• Финансовое одобрение – анализ затрат/выгод и выделение бюджета.
• Техническое одобрение – оценка необходимости, возможности проведения изменения и его степени воздействия.
• Бизнес-одобрение – одобрение пользователями требуемой функциональности приложения и степени воздействия изменения.
Для целей эффективного планирования Управление Изменениями должно взаимодействовать с проектным офисом и другими подразделениями компании, занимающимися разработкой и внедрением изменений. Кроме того, достаточное внимание должно уделяться своевременному осведомлению пользователей о планировании изменений, возможно, в виде рассылки Согласованного плана изменений (FSC).
Политика проведения изменений
Изменения по разным Запросам можно объединять в одном релизе. В этом случае при неудачной реализации будет достаточно одного возврата к исходному состоянию[114]. Такой групповой релиз должен рассматриваться как одно изменение, даже если он содержит в себе несколько изменений. Релизы могут планироваться с учетом функциональных задач, необходимых для бизнеса. Они могут охватывать аппаратные и программные средства, и их внедрение осуществляется Процессом Управления Релизами. Рекомендуется определить политику компании в этой области и информировать о ней ИТ-организацию и заказчиков (см. также «Управление Релизами»). Цель политики – оградить пользователя от ненужного беспокойства («перекапывание дороги каждую неделю»).
После консультаций с участвующими ИТ-подразделениями, Консультативный комитет (CAB) может определить регулярные периоды времени («окна») для проведения изменений, когда степень воздействия на ИТ-сервисы будет минимальной. Подходящими периодами могут быть выходные дни или нерабочее время. Таким же образом могут быть определены периоды, когда допускается минимум изменений или они вообще не допускаются, например, рабочее время или конец финансового года, когда все подразделения пользователей делают отчеты.
Совещания Консультативного комитета (CAB)
Информация о планировании изменений должна распространяться заранее до совещания CAB. Соответствующая документация и информация о пунктах повестки дня также должны рассылаться до совещания.
Повестка дня совещания CAB должна включать ряд постоянных пунктов, в том числе:
• неавторизованные изменения;
• Запросы на Изменения (RFC), которые должны быть оценены членами Консультативного комитета (CAB);
• авторизованные изменения, которые не были представлены на рассмотрение консультативного комитета (CAB);
• открытые и закрытые изменения;
• оценка произведенных изменений.
Оценка степени воздействия и ресурсов
При оценке необходимых ресурсов и степени воздействия изменения члены Консультативного комитета (CAB), Руководитель Процесса Управления Изменениями и другие участники (определенные Консультативным комитетом) должны учесть следующие аспекты:
• вопросы возможностей («мощности» или «емкости») подвергающихся воздействию услуг;
