Стандартные изменения в ITIL V3 и ITIL4

В каком случае изменения могут быть стандартизованы и выполняться, как запросы на обслуживание? Вопрос, безусловно, уже с бородой. Однако он по-прежнему не теряет своей актуальности. Во всяком случае, слушатели курса ITIL RCV задают его снова и снова. Одним из тезисов, вносящих некоторую путаницу в понимание, является следующий: стандартные изменения являются «заранее авторизованными». На самом деле это вовсе не означает, что стандартные изменения не требуют никакой авторизации.

Давайте вспомним, что сказано про стандартные изменения в ITIL V3 (перевод текста источника здесь и далее выполнен автором заметки):

Стандартное изменение — это изменение услуги или другой конфигурационной единицы, для которого управлением изменениями заранее авторизован подход к его выполнению, и этот подход основан на отлаженной и утверждённой процедуре предоставления конкретного (заранее определённого) результата.

ITIL V3 Service Transition, 4.2.4.7

Формулировка в ITIL4 Foundation, на мой взгляд, добавляет чуть больше деталей относительно авторизации:

Стандартные изменения — это изменения с низким риском, ..., которые могут внедряться без дополнительной авторизации.

ITIL4 Foundation, 5.2.4

В обеих формулировках мы видим явное указание на то, что какая-то авторизация должна быть. Однако может быть не до конца ясно, в какой момент она должна происходить. В ITIL4 есть дополнительные указания, а именно: если процедура выполнения (модель) стандартного изменения вновь создаётся или пересматривается, требуется комплексная оценка рисков и авторизация процедуры выполнения. При этом комплексная оценка рисков для каждого отдельного изменения не выполняется, а запускается только при необходимости изменения стандартизованной процедуры.

Не следует также забывать, что для некоторых (!) запросов на обслуживание (которые, в том числе, могут требовать выполнения изменений) может требоваться авторизация в соответствии с правилами в части финансирования, информационной безопасности и прочих практик управления. Назовём эту авторизацию «специальной».

В итоге получается следующая картина:

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

Я попытался визуализировать процесс в упрощённом виде на иллюстрации ниже.

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

ITIL ITIL Intermediate: Release Control and Validation

Учебный курс: преобразование и контроль ИТ-услуг, управление изменениями, релизами и конфигурациями, а также построение CMDB — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Sinan Aliyev

    Standard change — A pre-authorized change that is low risk, relatively common and follows a

    procedure or work instruction. ST, 4.2.4.3

    Standard changes -These are low-risk, pre-authorized changes that are well understood and fully documented, and can be implemented without needing additional authorization. ITIL4F, 5.2.4

    Мне кажется в обоих случаях акцент на low risk.

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

    Если вопрос именно такой, то соответственно может быть разработанна матрица рисков, определён что такое low risk (какая вероятность и влияние на бизнес является низким риском) и отметить какие изменения попадают в эту категорию. И начинать стандартизировать эти изменения.

    В ITIL4 подчеркнули что не нужно их авторизовывать дополнительно. Мне кажется основное отличие тут, ибо в ITILv3 всё еще какая то человеческая авторизация была нужна.

    Authorization of each occurrence of a standard change will be granted by the delegated authority

    for that standard change (e.g. by the budget holding customer for installation of software

    from an approved list on a PC registered to their organizational unit, or by the third-party engineer for replacement of a faulty desktop printer). ITILv3 ST, 4.2.4.7

    Сегодня с культурой DevOps — автоматизируй на лету, включая workflow, дополнительная авторизация не эффективно.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний: