Может ли ITIL быть agile (в вашей компании)?

Каймар Кару
перевод Романа Журавлева

Чтобы ответить на этот вопрос, давайте сначала разберемся, почему вы (или ваши коллеги) уверены, что ITIL (в вашей компании) – не agile, и на что это влияет.

Те дискуссии, где слова ITIL и agile оказываются вместе, обычно ведутся о том, как бы нам научиться быстрее делать то, что мы делаем. В этих дискуссиях, как правило, меньше говорят о командах и их взаимодействии (для этого ведутся DevOps-дискуссии) и о контурах обратной связи и постоянном обучении и улучшении (эти вещи, вообще-то, описаны в ITIL, но обычно игнорируются).

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

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

Как мы управляем изменениями: это точно не agile

В последние семь лет, в связи с развитием практик continuous integration / continuous   delivery, пожалуй, никакая другая тема в управлении ИТ-услугами не обсуждается так горячо, как управление изменениями.  Громоздкий и нередко болезненный процесс управления изменениями обычно включает в себя:

  • Ежемесячные (или пару раз в месяц) заседания совета по изменениям (Change Advisory Board, CAB), на которых рассматриваются все поданные за период запросы на изменения
  • Длинные списки лиц, согласующих изменения – несмотря на то, что многие из них не слишком разбираются в том, что согласуют, и не слишком зависят от предлагаемых изменений
  • Большое число экстренных изменений, используемых как способ обойти установленный процесс, чтобы хоть что-то довести до конца в разумные сроки.

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

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

Разберемся в причинах

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

Следуя этим практикам, мы поддерживаем иллюзию контроля, прикрывая хрупкость ИТ-систем покрывалом ложного спокойствия.

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

Для чего существует CAB? Чтобы поддерживать ЧСВ его участников, или чтобы корректно решать конфликты приоритетов между продуктами, услугами, командами с учетом бизнес-контекста? И могут ли эти задачи быть решены иначе, или могут ли текущие решения быть упрощены и оптимизированы, оставаясь при этом эффективными?

Отчего у нас так много согласующих? Оттого, что людям нравится посещать совещания и читать описания изменений, или же оттого, что нам важно понять влияние изменений на услуги, бюджеты и графики работы? Действительно ли ручная оценка технических аспектов изменений – оптимальный способ, или же нам может помочь автоматизация развертывания и контроля качества? И можно ли заблаговременно получить от управления портфелем полезные практические рекомендации для планирования изменений и снизить долю панического бюджетирования?

Что можно улучшить?

Вероятно, в вашей компании есть и другие практики, связанные с ITIL, не слишком успешно вписывающиеся в парадигму agile.

Говорится ли в ITIL, что организация должна разработать идеальный процесс перед тем, как начать его использовать? Нет. Вы можете внедрять сравнительно небольшие улучшения в те практики, которые уже работают – назовем результат, например, «минимальным жизнеспособным процессом» (minimum viable process). При этом важно помнить, что для заказчика важна приносимая вами ценность, а не объем формируемой при этом документации (это не повод отказываться от документации совсем – просто не увлекайтесь ей сверх меры). Да, такой процесс скоро потребует улучшения. И отлично. Постоянное улучшение – лучше попыток «внедрить все и сразу».

Говорится ли в ITIL, что на каждую описанную роль следует назначить отдельного человека? Нет. Роли описывают области ответственности, потому что так эти области легче понять. Неважно, как вы называете человека, который анализирует требования к доступности проектируемых услуг, пока кто-то это делает, и вы знаете, кто именно.

Говорится ли в ITIL, что разные задачи, поступающие к инженеру, должны находиться в разных очередях, по очереди на процесс? Нет. Для людей, совмещающих несколько ролей и работающих над разными задачами – решением инцидентов, анализом проблем, обслуживанием систем – постоянное переключение между очередями означает потери времени и постоянный стресс. Что важнее – решить инцидент среднего приоритета или разобраться с задержкой развертывания обновлений? Отслеживание отдельных категорий задач в некоторых случаях удобно для менеджеров, но организовав, например, канбан-доску для управления потоками работ, вы очень поможете перегруженным задачами сотрудникам.

Так что, может ITIL быть agile?

Тут я по-консультантски отвечу «зависит». Поскольку, в самом деле, ответ зависит от вас, от вашей компании.

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

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

Выходит, ответ на вопрос «может ли ITIL быть agile» – в том, может ли ваша компания быть agile.

ITIL® торговая марка AXELOS Limited.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

The Phoenix Project Основы DevOps

Новый учебный курс 2017
 

Проект Феникс — DevOps на практике

Новая деловая игра от GamingWorks
 

DevOps: погружение

Новый корпоративный семинар
 

Комментарии и мнения

  1. Андрей другой

    В защиту ITIL.

    Где в ITIL авторы видели утверждения про три перечисленных пункта: про CAB, число согласующих и обходные маневры? ITIL вообще НЕ содержит описания бизнес процессов в его классическом понимании. Во всяком случае, то, что там предложено в качестве описания таковым не является. Там есть лишь рекомендации, оформленные в том числе и схематически. Есть рекомендация о CAB, что его не плохо бы иметь, но нет утверждения, по поводу регулярности его созыва, равно как нет утверждения по поводу числа согласующих. Хотите сделать свой процесс управления изменениями Agile? Так и сделайте его таким. И я вас уверяю, он все равно будет соответствовать РЕКОМЕНДАЦИЯМ ITIL. Вот что правильно замечено, так это про непрерывность процесса усовершенствования процессов(извиняюсь за тафтологию). Но в ITIL и про это есть намеки — CSI. Там, правда, как обычно, ничего хоть сколько ни будь конкретного. Но я вот попробовал поразмышлять на эту тему(www.corisys.ru/images/doc...csi__itil___.pdf).

    1
    0
  2. Павел

    ❶ 2 Anton Boganov.

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

    ❷ 2 Автор статьи.

    Достаточно было вложить графические модели структуры и функций ITIL и Agile, т.е. схемы структурные и функциональные. Выполнить хотя ба характеристическое сравнение. Однако, как я предполагаю, у автора несколько иные цели, и, как следствие, иные методы.

    ❸ 2 Авторам подобных статей. Пожелаю «удачи» в жонглировании словами для соответствующих аудиторий.

    PS: Agile не более чем очередной маркетинговый продукт представляющий собой очередную псевдо-методологию (см. состав и назначение методологий). Выбранный метод продвижения соответствует понятию дезинформация.

    0
    6

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
27
Учебный курс:
Основы ITIL (очно)