Портал №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: если есть возможность заранее оценить риски, а также сформировать и авторизовать детальную последовательность шагов, необходимых для выполнения изменения, вы имеете дело с изменением-претендентом на стандартизацию, которое может не просто инициироваться запросом на обслуживание, но и выполняться в рамках этой практики управления.

ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от участников разработки

Комментариев: 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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Самое свежее

    • Работать меньше, чтобы сделать больше
      Все, а больше всех инвесторы и спонсоры, хотят, чтобы вся команда работала над новыми задачами, фичами, эпиками не останавливаясь. Тем не менее, несмотря на столь жгучее желание, …
    • Это же не наш профиль…
      Не смотр на то, что на нашем портале мы обсуждаем вопросы ITSM, я хотел бы затронуть тему “котиков”. Многие наверняка скажут: “Причем здесь котики? Это же не ваш профиль”. А какой …
    • Кто такие агенты изменений в продуктовой команде?
      Компании, которым жизненно необходимы частые выпуски изменений программного обеспечения, предпочитают переводить управление ИТ-разработкой в продуктовый подход. В этой статье я не …
    • Обновление Scrum Guide
      18 ноября 2020 года отцы-основатели Scrum Кен Швабер (Ken Schwaber) и Джеф Сазерлэнд (Jeff Sutherland) опубликовали новую версию руководства Scrum (Scrum Guide). Это особенно …
    • Где в ITIL можно почитать про управление техническим долгом?
      Во время вебинара нам поступил вопрос: Есть ли в практиках ITIL разделы\главы, в которых уделяется внимание управлению техдолга? (чтобы почитать)…
    • Технический долг: как бороться с невидимым врагом
      Зачастую о техническом долге говорят, как о плохо сделанной работе. Но брак есть брак, он порождает отходы, а не долги. А технический долг может накапливаться незаметно и …
    • Он и тебя посчитал
      В своей недавней заметке Олег Скрынник начал диалог на тему диагностики продуктовых команд, как потока. Думая о теме со своей стороны, больше с ракурса уютной внутрикомандной …
    • «DevOps Handboek» — «DevOps для ИТ-менеджеров» на голландском
      Книга Олега Скрынника «DevOps для ИТ-менеджеров» — лучший выбор для тех, кто хочет разобраться в том, что такое DevOps, — вышла на голландском …
    • Диагностика продуктовых команд как поток
      Представим, что у нас есть продуктовая команда. Ну или группа людей, которые очень хотели бы таковой стать. Ну или мы хотим, чтобы они стали — не суть. Предположим, что …
    • Учёт доступности? А можно как-то попроще?
      На днях, когда я в очередной раз рассказывал про управление доступностью на курсе ITIL PPO, мне задали такой вопрос: «а можно как-то попроще?». Вопрос, в общем-то, …
  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT