Портал №1 по управлению цифровыми
и информационными технологиями

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

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

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

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

ITIL V3 Service Transition, 4.2.4.7

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

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

ITIL4 Foundation, 5.2.4

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

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

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

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

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

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

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Комментариев: 2

  • ALEXANDR ZHILINSKY

    Отлично и очень хорошо подмечено, Артем!
    Иногда небольшая статья с полезной заметкой гораздо круче большой статьи с кучей материала)

  • 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, дополнительная авторизация не эффективно.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM