Если до 2019 года вы успели поучиться ITIL, то, несомненно,  успели заметить, насколько важная роль в нём отведена процессам. Однако если посмотреть на ITIL 4 Foundation, то становится очевидно, что фокус сместился от процессов в пользу практик, потоков создания ценности и руководящих принципов. Это довольно существенные перемены для тех, кто строил свою карьеру на внедрении и улучшении ITIL в своих организациях.

Для этих изменений есть много веских предпосылок, которые мы рассмотрим в этой статье.

Процессы ITIL не являются типовыми для всех организаций

Одна из причин отказа от процессов ITIL и связанных с ними инструментов и методов заключается в отсутствии единого универсального подхода, например, для управления изменениями в организации. Его нет и никогда не было. Попытки дать примеры того, как запускать определенные процессы, имели непреднамеренным следствием то, что люди просто выполняли предписанное в книгах ITIL, вместо того, чтобы напрягаться и проводить непростую работу, требующую творческого мышления и обсуждений того, что больше подойдёт для их конкретных команд, культуры, организации, а главное – заказчиков.

Почему фокусироваться на процессах ITIL и дальше – плохо?

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

Зачастую излишняя сосредоточенность на процессах ITIL приводит к недальновидному взгляду на гораздо большую систему, которую необходимо изменять и улучшать. В ITIL 4 представлены три основных направления: практики, потоки создания ценности и руководящие принципы, которые пришли на смену процессам и способствуют более широкому взгляду на вещи.

От процессов к практикам ITIL 4

Одно из самых больших изменений в терминологии в ITIL 4 – переименование процессов в практики. Это может показаться лишь незначительным изменением в семантике, но в реальности – это существенная и очень необходимая корректировка. Давайте начнём с определения каждого слова:

Процесс:

1. Ряд действий или шагов, предпринятых для достижения определенной цели.

Практика:

1. Практическое применение или использование идеи, или метода

2. Обычная, привычная или ожидаемая процедура или способ выполнения чего-либо
3. Повторное упражнение или выполнение какого-либо действия или навыка с целью приобретения или поддержания уровня мастерства в нем.

Мне нравятся образы, связанные со словом «практика», поскольку успешные организации часто делают акцент на улучшение во всех областях. Внедрение процесса подразумевает, что деятельность по его созданию имеет конечную точку. В то время как практика – это то, что мы должны постоянно улучшать, чтобы оставаться конкурентоспособными и продолжать радовать наших заказчиков.

Слово «практика» также дает нам ощущение того, что мы должны постоянно над чем-то работать, как если бы занимались спортом, и что на этом пути мы будем часто совершать ошибки – но это часть процесса обучения и совершенствования. Из практики создаётся профессия, в которой команды работают, оттачивая своё мастерство в течение нескольких лет. То же самое можно сказать и о любой сервисной организации мирового уровня – ресторанах, отмеченных звездами Мишлен, курортах и так далее.

4 аспекта управления услугами в контексте практик ITIL 4

В публикациях ITIL 4 впервые представлена концепция « 4 аспекта управления услугами», которая отлично демонстрирует, что наличие процессов – всего лишь одна из многих вещей, которые необходимо учитывать в нашей работе. Она даёт целостное представление о многих областях, критичных для получения реальной выгоды.

4 аспекта управления услугами ITIL 4

Мыслить за пределами процессов, когда необходимо управлять изменениями

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

Всё это замечательно, но если команда на этом остановится, то упустит массу возможностей сделать общую практику внесения изменений более эффективной. Какие это возможности? Представьте себе, насколько более надежным станет процесс изменений, если они просто зададут себе несколько вопросов:

Как часто мы должны вносить изменения?

• Еженедельного собрания Совета по изменениям / контролю / действиям недостаточно. Как часто вы хотите общаться со своими заказчиками, чтобы понять, как быстро должны происходить изменения – ежедневно? Несколько раз в день? – и выяснить, какой должна быть эта частота и как быстрее её обеспечить. Например, многие Agile-мыслящие команды, проводят ежедневные Scrum, чтобы утверждать изменения каждый день и не заставлять своих клиентов ждать целую неделю (или больше) для внесения изменений.

Какой уровень риска нас устраивает?

• Показатель может меняться, в зависимости от конкретной организации. Например, у нас есть заказчик, который поддерживает программное обеспечение на AirForce One. По понятным причинам, они очень нетерпимы к рискам. Другие организации могут не иметь столь жестких требований и даже допускать риски при внесении срочных изменений.

Как обсуждать со всеми изменения, существенные для всех?

• Продолжая идею ежедневных стендапов Scrum, я также наблюдал, как заказчики проводят ежедневные собрания Scrum of Scrum, на которых команда обсуждает изменения, которые хотелось бы внести, а затем выделенный человек посещает еще одно короткое собрание для обсуждения изменений, которые влияют на другие команды. Так в обсуждении и принятии решения участвуют все.

Существуют ли альтернативные полномочия на изменения, которые мы можем использовать для определенных типов изменений?

• Какие изменения можно согласовать с коллегами и не обращаться к CAB?
• Какие изменения можно автоматизировать или одобрить заранее, чтобы не было необходимости подключать к этому людей?
• Какие изменения можно разделить на более мелкие, чтобы уменьшить риски?

Какие инструменты мы можем использовать, чтобы обрабатывать больше изменений и при этом поддерживать прозрачность этих изменений?

Как дать больше полномочий командам, чтобы решения принимались не только одним менеджером изменений или CAB?

Какая минимальная документация необходима и для каких типов изменений?

Какие важные системы необходимо заблокировать, чтобы изменения не происходили в тайне?

Если мы используем концепции Agile, Lean или DevOps, наша команда по изменениям (или, если уж на то пошло, команда руководителей) уже прошла базовое обучение и/или пообщалась с командами, практикующими эти методы, чтобы понять, как ИТ-специалисты могут наилучшим образом использовать эти идеи, чтобы изменения происходили быстрее, сохраняя при этом уровни риска на приемлемо низком уровне?

Это лишь примеры вопросов, которые возникают, если смотреть на изменения шире, за пределами самого процесса.

От процессов к потокам ценности в ITIL 4

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

ИТ на службе других внутренних бизнес-подразделений:

ИТ и другие бизнес-подразделения на службе у заказчика:

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

От процессов к руководящим принципам ITIL 4

Еще одна задача, с которой  заказчики и практики сталкивались на протяжении многих лет, заключается в том, как применить ITIL в своих организациях. Это особенно чувствовалось в ITIL v3, где на обучении изучались непростые 26 процессов ITIL. Это делало идею внедрения запутанной и пугающей. В 2016 году авторы ITIL опубликовали первую версию Руководящих принципов, которые вышли в составе книг ITIL 4 (см. диаграмму ниже). Причина, по которой они так важны, на мой взгляд, даже важнее, чем рассмотрение всех шагов, поддерживающих конкретный процесс, заключается в том, что, как и в случае с Agile, существует идея «быть гибким» вместо «делать гибким». Руководящие принципы ITIL отлично вписываются в категорию «быть ITIL». Наше мышление, ценности и убеждения во многом определяют наши действия, например, как мы подходим к концепциям ITIL, как применяем их и, в конечном итоге, предоставляем высококачественные, несущие ценность продукты и услуги, которые решают проблемы и двигают наши организации вперед. То, как выглядят наши процессы, является побочным продуктом наших Руководящих принципов.

Руководящие принципы ITIL:

В качестве заключения – наши новые горизонты и смена стиля общения с окружающими

Я надеюсь, что те из вас, кто переживает из-за того, что ITIL 4 уже не про процессы ITIL, нашли в этот статье идеи, которые сослужат вам пользу при внедрении ITIL в вашей организации. Включение Agile, Lean и DevOps в книги ITIL давно назрело, и я рада, что книги ITIL 4 (и обучение ITIL 4) более точно отражают работу современных организаций. Новые концепции дают тем из нас, кто работает в ИТ, дополнительные инструменты для поддержания конструктивного диалога с нашими коллегами и заказчиками. В конце концов, мы все хотим делать значимую работу для других, и ITIL 4 приближает нас к достижению этой цели.

Автор Эрика Флора (Erika Flora), оригинал Why ITIL 4 is shifting its focus away from ITIL processes

ОБУЧЕНИЕ

ITIL 4 Foundation, DSV, DPI, CDS, HVIT, DITS

и другие интересные аббревиатуры от соавторов ITIL 4