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

ITIL и новые модные штуки

В самом начале 2000-х мне, как и многим другим ребятам, было очень важно узнать: как организовать современный (на тот момент) ИТ-департамент коммерческой компании среднего размера. Скажем, на 50-200 “айтишников”. То был не праздный интерес, а вполне реальная задача – столкнувшись с управленческим аспектом организации труда стало понятно следующее:

  1. Работа персонала может и должна быть организована (в противовес простому устройству мира “все люди изначально хорошие, и они просто ходят на работу, и там работают изо всех сил“).
  2. Работа может быть организована сильно по-разному.
  3. Способ организации работы существенным образом влияет на получаемые результаты.

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

Прошло почти двадцать лет. Теперь мы умеем решать все те задачи, но вот загвоздка: нынешние задачи стали иными. Для многих коммерческих компаний они находятся в области того, что теперь называется цифровой трансформацией, высокоскростными ИТ, управлением продуктами. В старых книжках ITIL про это ничего не сказано, разумеется. Сказано ли в новых? Хороший вопрос.

С одной стороны, авторы первой книжки четвёртой версии ITIL старались, и это очень заметно. Слово “product” и однокоренные встречаются не менее, чем 300 раз. Слово “agile” – не менее 90. А ещё в тексте есть “team“, “devops” и “lean“. С другой стороны, слова есть, а направление остаётся (по крайней мере для меня) не совсем понятным. Этот казус я рассмотрю более подробно в выступлении на “ITIL 4 Russia Launch” 12 марта. То есть как бы попытка есть, но попытка так себе. Однако не всё так однозначно.

Видите ли, первая публикация новой версии ITIL – это книжка “ITIL Foundation”, основы. В ней и не предполагается давать чётких рекомендаций, это не методичка по всем вопросам. Объём книги ограничен, и авторы сообщили нам самые главные концепции, идеи и понятия. Всё остальное будет написано в следующих книжках, которые ожидаются к концу 2019 года. И тут я задумался.

Я представил себя в той же роли, в которой я был двадцать лет назад. Предположим, у меня есть задача организации ИТ-департамента средней или крупной коммерческой компании. Предположим, что бизнес хочет того, с чем сейчас носятся все: цифровизации, омниканальности, нового клиентского опыта (как же нужно ненавидеть русский язык, чтобы так разговаривать?), новых возможностей и, самое главное, принципиально другой скорости от ИТ. То есть не проект за год (вместо трёх), и не релиз каждый месяц (вместо раз в квартал), а чтобы в понедельник идея, а в пятницу она уже в среде эксплуатации и мы дружно наблюдаем и измеряем эффект (или его отсутствие). Так вот, с такими предположениями, на какие вопросы я бы искал ответы в ITIL?

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

Далее, нужно разобраться с архитектурами. И с бизнес-архитектурой, и с информационной, и с технологической. Архитектуры должны помогать двигаться быстро, а не мешать. Как?

Разумеется, следует подумать про измерение и деятельности, и результатов. Какие метрики мне пригодятся? Для чего? Какие решения я смогу принимать?

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

Вспоминая про широкую функциональность, десятки и сотни эксплуатируемых систем, тысячи одновременно проводимых изменений, десятки ключевых заказчиков, неоднородную и в большой степени устаревшую ИТ-инфраструктуру – вспоминая всё это становится понятно, что банальные советы для компании из десятка Scrum-команд никак не помогут. Это кровавый Enterprise, тут всё веселее.

Теперь к сути моей заметки. Дело вот в чём: книга “High Velocity IT”, запланированная в ITIL 4, пока не написана. Можем мы позволить себе помечтать? Можем. Больше того, мы можем даже набросать ТЗ, задание для авторов этой книги. Пусть они точно знают, что от них требуется. Пусть напишут то, что будет помогать. Пусть затронут сложные вопросы и поднимут непростые темы. Пусть новый ITIL будет таким же полезным, как и предыдущий.

Набросаем задание авторам? Что бы вы хотели прочесть в книге с названием “ITIL 4: High Velocity IT”? Дайте список вопросов, на которые обязательно нужно получить ответы. Можете в комментариях ниже, можете на мой электронный адрес, а можете просто на info@realitsm.ru.

А я передам коллективу авторов. Пусть думают.

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

  • Ольга

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

    • Ольга, спасибо. Обозначенные темы понятны, я с ними согласен.
      Сомневаюсь, что нам дадут исчерпывающие ответы.
      Но это не повод не попробовать задать вопросы. Что не расскажут в ITIL – узнаем и научимся сами, а потом перепишем этот ITIL 🙂

  • Александр Васильев

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

    • Александр, а как же архитектурная проработка и контроль? Есть ли у вас какие-либо управленческие надстройки над командами/продуктами? Если есть, то как организована их работа: кто входит, когда привлекаются, какие имеют полномочия?
      Мне кажется, что без такой надстройки оно внизу точно будет расползаться…

  • Дина Гайсина

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

    • Дина, про финансовое планирование – это Вы прямо в точку попали. Есть такой вопрос, и непростой. Спасибо.

  • Андрей Угольков

    Цифровая трансформация размывает границы между ИТ и бизнесом. Product Owner для продуктов типа B2B-портала скорее коммерсант (e-commerce), чем ИТ-шник. Я бы в новой книге хотел прочитать как все-таки эти границы не терять, как построить ИТ процессы находящиеся одной ногой в бизнес-процессах. А еще и по продуктам, поддерживаемым по ITIL, а дорабатываемые по Agile.

  • Константин

    Олег, спасибо за статью!
    Вопрос как совмещать традиционные и гибкие подходы, чтобы они не становились “русским Agile бессмысленным и беспощадным”.
    Как совместить работу продуктовых команд над проектам и поддержкой этих проектов

    • Константин, про продукты и проекты мне тема очень понятна, а что такое русский Agile?


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM