На курсе «Основы управления ИТ-услугами» нередко возникает дискуссия по поводу того, как провести границу между практиками управления изменениями и управления запросами на обслуживания.

Вызвана она тем, что часто в рамках выполнения запроса на обслуживание реализуется изменение. Например, установка программного обеспечение, изменение прав доступа, перемещение или изменение конфигурации оборудования. Поэтому некоторые усваивают это в упрощённом виде: «Запрос на обслуживание – это стандартное изменение». И в этом случае теряются ориентиры. Как соотносятся эти практики, если в рамках одной выполняется работа с объектом, который является основным объектом управления в другой?

Справедливости ради стоит заметить, что нечто похожее на «запрос на обслуживание [ЗНО] – это стандартный запрос на изменение [ЗНИ]) мы можем увидеть и в библиотеке ITIL. Например, в книге «Основы» стандартное изменение описывает следующим образом.

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

И далее:

They are often initiated as service requests…

Т.е. они [стандартные изменения] часто инициируются как запросы на обслуживание.
Так, что, запросы на обслуживание – это стандартные изменения? Нет!

Так нередко говорят в повседневной жизни. Но важно понимать, что это огрубление, вызванное попыткой упростить коммуникации. Нужно понимать то, что это искажает картину, которая на самом деле выглядит следующим образом.

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

увеличивать количество (долю) успешных изменений услуг и продуктов, обеспечивая правильную оценку рисков, авторизацию изменений и управление графиком изменений.

Это назначение практики невозможно реализовать в полной мере, если в охват не будут попадать все изменения.

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

Как же реализуется эта ответственность, если сами изменения реализуются в рамках деятельности, относящейся к другим практикам?
Как раз через стандартные изменения. Т.е. через разработку моделей изменений. Нужно помнить, что модели – это необязательно пошаговая инструкция. Это может в том числе быть заранее предопределённый маршрут согласования, или верхнеуровнево описанная последовательность видов деятельности (которая может быть довольно сложной и длительной, с большим количеством участников). И тогда картина складывается.

В рамках практики «изменения» происходит управление изменениями, требующими анализа, согласования и т.п. А также постоянная разработка и актуализация моделей, которые задают правила реализации изменений в рамках прочих практик/процессов. В рамках прочих практик и процессов (включая практику управления запросами на обслуживание) по-хорошему тоже нужно выстроить регулярную деятельность по стандартизации (разработке и актуализации моделей отработки запросов на обслуживание).

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

Так что, нет, ЗНО – это не стандартные ЗНИ 😉

PS

Кстати, фраза про стандартные изменения, цитата из которой приведена выше в оригинале, целиком выглядит так:

They are often initiated as service requests, but may also be operational changes.

А в практическом руководстве «Change enablement» приводится ещё больше примеров сценариев, в которых могут реализоваться стандартные изменения:

• выполнение запроса обслуживание
• типовые решения инцидентов
• стандартные меры реагирования на чрезвычайные ситуации (в соответствии с ПАВ [DRP])
• обслуживание инфраструктуры
• плановое тестирование мер на случай непредвиденных обстоятельств
• высокоавтоматизированные изменения, проходящие через конвейер CI/CD
• рутинные обновления программного обеспечения.