Развитие IT Infrastructure Library, библиотеки с описанием лучших способов организации работы подразделений или компаний, предоставляющих услуги в области ИТ, британское правительство, изначальный собственник ITIL, доверило компании AXELOS. Развитием библиотеки в компании занимается команда из четырех специалистов. Один из них, Роман Журавлев, на форуме ITMF 2017, организованном издательством «Открытые системы», сделал доклад о настоящем и будущем ITSM, он также провел круглый стол и собрал мнения сотни его участников о том, что наиболее востребовано в реальной практике ITSM, а что скорее опасно. Журавлев рассказал Computerworld Россия, почему рекомендации ITIL, принятые десять лет назад, до сих пор актуальны, о направлениях развития библиотеки, а также о том, как правильно развивать сервисный подход в условиях ограниченных ресурсов.
— Текущей версии библиотеки ITIL скоро исполнится десять лет. За эти годы в мире ИТ все изменилось до неузнаваемости, не только с технической точки зрения, но и с точки зрения вовлеченности ИТ в бизнес. Неужели рекомендации десятилетней давности отвечают новым условиям?
Да, третья версия ITIL появилась в 2007 году. В 2011-м вышло обновление, но библиотеке в текущем году действительно исполняется десять лет.
Несмотря на все упомянутые перемены, принципы изменились довольно мало. Кроме того, для своего времени библиотека была весьма прогрессивной. Как сегодня сказал Максим Тищенко (директор департамента ИТ Банка России, один из ключевых докладчиков на ITMF 2017. — Прим. ред.), многим понадобились эти десять лет, чтобы дорасти до уровня, который был тогда задан.
В ITIL v.3 многое было сделано на вырост, ее важнейшие принципы — главенство интересов бизнеса, ориентация на заказчика и т. д. — никуда не делись. ИТ по-прежнему работает для бизнеса, а не для технологий, и даже более, чем раньше. И в мелочах все по-прежнему: инциденты нужно разрешать как можно быстрее; изменения нужно проводить быстро, но при этом безопасно; мощностей должно хватать с учетом завтрашних и послезавтрашних потребностей, и к тому же недорого.
Технологически ответы на эти вопросы меняются, а задачи и базовые принципы их решения в значительной степени остаются неизменными. Это с одной стороны. С другой — ИТ-индустрия развивается очень быстро, ITIL медленнее, а многие организации еще медленнее. Поэтому есть компании, которые до сих пор преодолевают задачу, например, построения адекватной пользовательской поддержки.
И это не только российская специфика. Немного удивительно, но для многих американских компаний только сейчас наступил период знакомства с ITIL.
— Велики ли страновые различия? Насколько точно одна библиотека описывает процессы по всему миру?
Разумеется, есть довольно много национальных и локальных различий, которые следует принимать во внимание, поэтому в ITIL один из ключевых принципов — это adopt & adapt: необходимо не просто копирование того, что в ней написано, а принятие принципов и адаптация под свою среду. Индийский сервис-провайдер, работающий для большого американского заказчика, работает не так, как работают обычно в Индии, и не так, как в Америке. Но и для него, и для обычной индийской компании, и для обычной американской рекомендации ITIL применимы как набор принципов и набор практик.
ITIL вообще с самого начала не про то, «как надо», а про то, «как можно». Наверное, наиболее полная его аналогия — это ящик с инструментами у домашнего мастера. Дома, особенно у нас в стране, как правило, есть ящик с инструментами, но это не значит, что надо использовать все инструменты из ящика, что их нужно использовать в том порядке, в котором их туда сложили на заводе, или что их нельзя смешивать с инструментами из других ящиков.
То же самое касается страновых различий. Если я просто возьму опыт Голландии и постараюсь применить его в культуре Северной Кореи, скорее всего, ничего не получится. Но базовые принципы, которые надо иметь в виду, применяя этот опыт для каждой из стран, или для каждой из отраслей, или для каждого из предприятий, более или менее неизменны.
— Продолжая географическую тему: в вашей команде развития ITIL нет ни одного американца. Мы как-то привыкли, что стандарты устанавливают в США…
Ну, ITIL изначально создана в Великобритании. Тем не менее из четырех человек, которые входят в нашу команду, двое имеют большой опыт работы в США. У индуса Акшая Ананда хороший консалтинговый бэкграунд, он работал в крупных консалтинговых компаниях в Великобритании и США. Джулия Харрисон — англичанка. Она очень много была занята в реальном секторе, также в первую очередь в Америке и Великобритании. Мой опыт связан в основном с тренинговой работой, а наш руководитель эстонец Каймар Кару трудился на разных позициях, в том числе в Эстонии в Skype, когда тот не был еще частью Microsoft, и в госсекторе. Другими словами, у нас довольно разносторонняя команда, члены которой происходят из разных культур, и наш опыт работы с ITIL охватывает почти все возможные сферы применения.
— Необычно слышать, что Америка догоняет Европу. А как выглядит Россия на этом фоне?
По зрелости я скорее склонен сравнить российский рынок с европейским, чем с американским. У нас есть примеры комплексных, успешных реализаций проектов на базе ITIL. Их немного, но их и в мире немного. Наиболее зрелые компании, как и везде, — банки, телеком, сервис-провайдеры, ИТ-фирмы, а также местные филиалы западных компаний.
Интересен опыт Банка России, который, с одной стороны, трудно напрямую применить другим банкам, в силу того что это все же опыт регулятора. Но, с другой стороны, его рекомендации задают направление развития для банковской отрасли. Если в ЦБ диджитализация процессов разовьется до нужного уровня, то это подтолкнет к диджитализации и другие банки.
Очень интересные и зрелые практики в области управления ИТ-услугами у «Лаборатории Касперского». Они базируются на ITIL, но не являются копией западных решений, а созданы в самой компании.
— Банк России имеет силы и средства внедрить у себя все по полной. А есть ли какая-то подбиблиотека «для умных, но бедных»? Для тех, кто хочет в пределах имеющихся у них бюджетов сделать, возможно, не очень много, но хорошо…
Прежде всего, нет такой задачи — «внедрить ITIL по полной». Помните про ящик с инструментами? Иметь под рукой рекомендации библиотеки и выбирать нужные по мере появления новых задач полезно для компании любого масштаба и достатка.
Но если умные бедны настолько, что и литературу предпочитают бесплатную, то я бы, наверное, рекомендовал обратить внимание на, к сожалению, уже не развиваемый подход под названием FITS (Framework for Information Technologies Support). Его когда-то развивали в Великобритании на базе второй версии ITIL, чтобы помочь образовательным учреждениям (университетам, колледжам) управлять информационными технологиями. Соответствующие публикации можно найти на сайтах британских учебных заведений.
Роман Журавлев вместе с участниками конференции пытается выяснить, что именно реально востребовано в практике ITSM |
— В одном из докладов разбиралась ситуация — внедрили модный ныне портал самообслуживания, а он оказался и дорогим, и неудобным для пользователей. Многим, вероятно, нужны не советы, что делать, а советы, чего не делать?
В ITIL сейчас нет отрицательных кейсов, «историй неуспеха». Но мы видим высокий спрос на них. Когда на любой конференции организаторы опрашивают на тему: «О чем бы вы хотели услышать в следующий раз?», то самый популярный ответ, разумеется, «больше кейсов». А второй по популярности — «больше отрицательных кейсов».
При этом, разумеется, очень мало тех, кто любит рассказывать про свои провалы, многие просто не имеют права рассказывать про них. Но чужие ошибки — это очень востребованный материал.
Если брать частный пример с порталом, то в ITIL по подобным вопросам есть рекомендации про, условно говоря, количество линий поддержки, про использование или неиспользование самообслуживания, аутсорсинга тех или иных функций. В этом как раз ценность ITIL, что, помимо общих принципов, которые много где изложены, есть ответы на конкретные вопросы о том, как принять решение, и о том, что поможет принять решения… По более общим вопросам много ответов в недавно выпущенной публикации ITIL Practitioner Guidance. Более специальные рекомендации — в соответствующих базовых публикациях; в частности, про портал — в Service Operations, раздел Technologies for Service Operations. И там говорится, что внедрение средств самообслуживания не самоцель, что без качественного наполнения этих систем, без удобных интерфейсов для пользователей такое внедрение может дать существенный негативный эффект.
— То есть вам надо искать провальные кейсы, предлагать их в максимально «обезличенном» виде?
Такие идеи есть. Исследовательская работа нашей группы как раз нацелена на то, чтобы понять, что нужно в первую очередь, каковы потребности различных сегментов нашей аудитории. А поняв, по возможности ответить на эти потребности новыми публикациями.
— Какие еще запросы у потенциальных потребителей?
Очень не хватает рекомендаций, касающихся управления единым потоком формирования ценности, того, что стало развиваться вместе с термином DevOps. Он очень часто воспринимается только как объединение Dev и Ops, а должен бы восприниматься гораздо более полно, потому что Development и Operations — это «серединка» потока процессов, который начинается с бизнес-ожиданий и заканчивается работающей услугой. А разработка и эксплуатация — середина этой цепочки.
Тем, кто пытается взять под контроль всю эту цепочку, весь поток, очень не хватает интегрирующего руководства, средств оценки бизнес-ценности результата.
Также маловато работ в области SIAM, Service Integration and Management. Зависимости, которые мы привыкли рисовать как сервисно-ресурсные модели (чтобы у меня была электронная почта, мне нужно приложение, операционная система, ПК, доступ в Интернет и т. д.), сейчас превращаются из цепочек в сети. И эти сети объединяют не ресурсы, а услуги — услуги смежников внутри компании, услуги смежников за пределами компании. Существующих рекомендаций по управлению поставщиками и уровнем услуг не хватает.
SIAM описывает управление этими сетями. В последние пару лет на эту тему много пишут, появляются кейсы, всякий уважающий себя крупный западный интегратор предлагает строить такую систему SIAM или даже стать «точкой входа» для заказчика.
Пока это очень молодая и не очень богатая историями успеха тенденция, тем не менее очень перспективная, потому что объективно связи становятся все сложнее, а зависимостей все больше. Еще одна смежная область, в которой не всем хватает публикаций ITIL, а поэтому появляются самостоятельные продукты, — Business Relationship Management.
Упомяну еще Enterprise Service Management, о котором говорил Стивен (Стивен Манн, старший аналитик ITSM.tools, один из ключевых докладчиков ITMF 2017. — Прим. ред.). Это применение сервисных принципов для управления компанией в целом и опыта ITSM для поставщиков не-ИТ-услуг.
— Есть запросы на руководства с отраслевой спецификой или для небольших компаний?
К нам поступает много пожеланий по учету отраслевой специфики. В текущей работе по развитию ITIL мы думаем, как это сделать.
Но я должен уточнить, что отсутствие таких документов компенсируется тем, что в главных документах ITIL прописаны общие принципы, не зависящие от сферы деятельности. Которые, как я уже говорил, не устарели за десятилетие.