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

Почему в ITIL 4 процессы ITIL больше не главное?

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

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

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

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

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

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

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

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

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

Процесс:

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

Практика:

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

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

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

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

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

  • Павел

    Те же логотипы МТС, но вид сбоку, имхо. Почему сразу процессы стали архаичными, монструозными и отсталыми?
    А как же adopt & adapt? На процессе знак “ITIL совместимо” не ставят же после внедрения на предприятии. Да и само понятие “процесс внедрён” как-то не подчёркивается никем, кроме, может, аудиторов.
    Тот же SLM и Demand – это 2 разных процесса, но в 99,9% случаев это один человек, о чём на курсах слушатели единогласно соглашались. Availibility без Capacity тоже странно на практике.
    Практика и процесс – это как объект и класс, получается. Процесс задаёт форму, суть, содержание, цели, задачи, правила и т.д., а практика – это уже само применение процесса и активности с ним связанные.

    Никто не будет в жизни сверятся с библиотекой ITIL при работе над инцидентами, проблемами, SLA и, морща лоб, указывать, что тут вот не соответствует лучшим практикам.
    Само внедрение процессов, если не банда консультантов набежала, происходит поэтапно, т.к. сознание людей не имеющих даже зелёного ромба не сможет одномоментно следовать новой моде и правилам, что не приведёт к улучшению, а, может, и всё порушит. А именно улучшать и поддерживать бизнес-процессы завещали нам, уже устаревшие, 5 книг.

    • Константин

      Увы, сверяться с библиотекой ITIL (как и любой другой попавшей под руку методологией) всегда будут:
      – начальники-фанатики методологий, ищущие “универсальную таблетку”;
      – аудиторы, особенно если они думают, что знают как управлять ИТ….
      Как результат – имеет внедрение всего и сразу в полном хаосе с ничтожной эффективностью.

  • Евгений

    Руководящие принципы – отличное нововведение в ITIL. Их ценность в возможности применения в любых организациях и обстоятельствах.
    В целом, подход перехода от процессов к практикам оправдан в современных реалиях. IT очень быстро развиваются. Меняются технологии, соответственно меняется и методология.

  • Ирина

    Странная статья. Выглядит, как будто “ITIL умер, до здравствует ITIL”. На самом деле, если человек хоть раз Успешно внедрил ITIL в организации, даже версии 3, он пользовался теми же потоками ценности и руководящими принципами. Возможно делал это неосознанно, возможно, по-другому называл. Но пользовался!
    ITIL не живет сам по себе, он встраивается в общее управление, представляет собой систему, а любая система имеет границы, пограничные условия, входы в систему и выходы. Хорошо, что представили этот факт явно. Но удивительно, что окунувшись внутрь этой системы, не увидели процессов. А их реализация в каждой конкретной организации и при конкретных условиях и есть практика….
    Можно подумать, что существуют ИТ-специалисты, которые сидят и читают описание процесса, чтобы решить инцидент или выполнить запрос на обслуживание. Да не бывает такого! Зато бывает обобщенная или упрощенная канва жизни по процессу. “Это запрос…!”- “о, ес, пошел делать…”
    Вот что точно вносит сумятицу в жизнь организации, так это неописанные практики и неутвержденные процессы. Не важно, кстати, какие методологии мы в них заложили. Правила игры должны быть прозрачны и понятны всем: и руководству, и рядовым сотрудникам.

  • Дмитрий

    Новый процесс (практика) получения бабла.
    Новые учебные курсы, сертификация итд.
    Золотой телец рулит.

  • Максим

    Вот читаю я время от времени информацию по ITIL v 4 и все больше разочаровываюсь. Похоже авторы пошли на поводу agile-методов в создании ITIL v. 4. Упор все больше сделан на технологии, как например в devops. Что касается ценности ИТ для бизнеса, то в v.3 это проходит красной нитью через все книги. Опять же обратите внимание на типы экзаменов в v.3 и v. 4. Мне кажется это говорит о многом)


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM