Практически любой уважающий себя ИТ-менеджер или консультант по ИТ-сервисам прекрасно знаком с концепциями и терминологией ITIL и пользуется ее «лучшими практиками». Предлагая коммерческие ИТ-сервисы, любой поставщик обязательно упомянет ITIL, но почти всегда при этом отметит, что библиотека комбинируется с более практическими подходами. Сама методология развивается — например, в версии 2007 года и доработках 2011-го ряд общеизвестных концепций переведены в современный контекст «формирования ценности» посредством сервисов. ITIL теперь принимает во внимание применение аутсорсинга и его влияние на стратегические решения в области поддержки ИТ. Четче говорится о том, что, варьируя способы внедрения инструментов, можно повысить эффективность. Предложен более динамический подход к постоянному совершенствованию по сравнению с устаревающими принципами «ориентации на заказчика» и «управления качеством». Но стоит ли тратить сегодня силы на активную работу с ITIL, включая основные книги и дополнительные материалы? Да, книги ITIL — источник нужных и важных знаний практически для каждого ИТ-специалиста и должны присутствовать в его личной библиотеке.

Освоение ITSM не теряет своей актуальности — ITIL здесь выступает в качестве отраслевого руководства. Помимо этого, лучшие практики ITIL можно комбинировать с другими методологиями, такими как Lean for IT, стандарты ISO и различные комплексы знаний в области управления проектами и стратегического руководства. Однако слушатели соответствующих курсов задают вопросы и о том, какие у ITIL есть ограничения в сравнении с другими методологиями и с учетом реалий предприятий различных размеров, типов и уровней зрелости. Преимущества ITIL отлично задокументированы, но почти нет обсуждений внутренних ограничений, свойственных модели этой библиотеки, хотя профессионалы о них знают.

ITIL — не только об инфраструктуре

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

В некоторых компаниях есть необходимость четко делить сотрудников на специалистов по инфраструктуре и по приложениям, в других могут выбрать иную организационную структуру. Сервисы, потребляемые из облака, могут быть инфраструктурного уровня, уровня платформы или уровня приложений. Интеграция таких SaaS-сервисов сопровождается новыми сложностями. Но даже в случае внутреннего или частного облака и выделенных ИТ-сред, управляемых самостоятельно или с помощью партнеров, тщательная увязка между всеми компонентами и работающими на них бизнес-функциями является ключом к обеспечению максимальной ценности для пользователя.

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

Перевод терминологии на повседневный язык

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

Тем не менее ITIL по-прежнему славится своим собственным особым словарем, составленным для обеспечения целостности терминологии — «люди ITIL» не могут сказать, что некто обратился в техподдержку с проблемой: они скажут, что было обращение по поводу «инцидента». Смешивать «айтильский» с разговорным в повседневной речи сложно, это ведет к недоразумениям. Добавляют путаницы искусственные официальные переводы ITIL на другие языки, в которых зачастую больше в ходу все равно англоязычная терминология. При этом с каждой новой редакцией ITIL ситуация, похоже, становится все хуже. Едва мы успели привыкнуть ссылаться на CI (конфигурационные единицы) в CMDB (база данных управления конфигурациями) в соответствии со SLA (соглашение об уровне сервисов), как оказалось, что теперь CMDB вместе с IMDB (база данных управления инцидентами), PMDB (база данных управления проблемами) и KEDB (база данных известных ошибок) являются лишь частью CMS (система управления конфигурациями).

Сближение процессных принципов и их реализации

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

Все это — типовые задачи, выполняемые в реальных организациях, и их можно было бы включать в справочные руководства, пособия и документацию по процессам, однако почти для всех этих примеров непросто подобрать соответствующий процесс ITIL. Похоже, что процессы ITIL описываются на более высоком уровне абстракции, чем типичные задачи сегодняшних команд технической поддержки. Ключевые темы ITIL актуальны, когда нужно заставить разные команды работать вместе. Но эти процессы не рассчитаны на то, чтобы охватить все задачи, которые решаются для обеспечения работоспособности ИТ-сервисов в целом или на конкретных платформах. В сущности, если постараться, можно привязать вышеупомянутые задачи практически ко всем процессам ITIL и с таким же успехом отстаивать мнение о том, что эти задачи не охвачены ни одним из процессов.

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

Некоторые консультанты по ITIL потратили месяцы (и деньги из бюджета организации) на то, чтобы попытаться перевести хотя бы один процесс ITIL на язык реальных задач ИТ-отдела. Другие потратили еще больше времени на споры о «правильной» реализации или «верной» интерпретации. Проблема в том, как применяется ITIL, а не в ограничениях методологии самой по себе. Нельзя ли каким-то образом сделать связь ITIL с реальностью неотъемлемой частью самой методологии?

Стена между бизнесом и ИТ

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

Традиционная организационная структура в соответствии с ITIL — это закрытая система, предусматривающая наличие двух больших модулей, бизнеса и ИТ. Бизнес является клиентом ИТ-отдела и воспринимает его как «черный ящик». ИТ-отдел может иметь сложную внутреннюю структуру, которая скрыта от бизнеса. У бизнеса тоже может быть сложная структура, но она не имеет отношения к структуре ИТ. Наличие четких интерфейсов между различными частями организации призвано улучшить контроль и ясность для всех. Если каждый позаботится о том, чтобы его подразделение хорошо справлялось со своими обязанностями, то и вся организация будет успешно работать. Но так ли это сегодня?

Модель на основе единой точки контакта

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

Новые способы работы требуют общения внутри организации, выходящего за рамки обращений в единые точки контакта (ЕТК), причем в некоторых традиционных организациях таких точек уже больше, чем самих сотрудников. Служащим нельзя обращаться напрямую к своим знакомым в отделе маркетинга или кадров — необходимо это делать только через официальную ЕТК. В последней удостоверяются в соответствии передаваемого сообщения своей специализации, редактируют его и, возможно, передают нужному человеку в соответствующей структуре. Или может оказаться, что была использована не та ЕТК, что сообщение было передано по неверному каналу или не по правилам. Некоторые реализации ЕТК воздвигают, а не снижают барьеры для доступа к инструментам. То же самое может происходить, если создать чересчур негибкую структуру службы поддержки пользователей (Service Desk) и связанные с ней ЕТК в соответствии с ITIL. Известны случаи, когда необходимость обращаться в службу Service Desk было трудно обосновать, поскольку сами пользователи в ней не видели никаких удобств. Тем не менее ИТ-руководство навязывало службу пользователям, настаивая на том, что так будет лучше.

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

ITIL в средах с множеством заказчиков и партнеров

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

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

Ряд коммерческих поставщиков ИТ-сервисов разработали собственные подходы, позволяющие решать перечисленные задачи, но в то же время придерживаться терминологии ITIL и определенных в библиотеке интерфейсов взаимодействия с заказчиками.

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

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

Научное обоснование

В области ИТ-поддержки появились конкурирующие силы. Руководители ищут пути снижения издержек для каждого процесса и каждой организационной единицы без принесения в жертву непрерывности и производительности ИТ-сервисов. Все больше компаний идут на радикальные организационные изменения, чтобы продолжать приносить максимальную пользу заказчикам с меньшими затратами. Сегодня ITIL не воспринимается как источник методов максимальной оптимизации работы систем и сервисов, когда бюджет сократили, допустим, на 50%. ITIL используют скорее как обоснование определенного метода повышения качества деятельности, чем как источник проверенных способов сокращения расходов до минимума с одновременным достижением высокого качества.

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

Короче говоря, внедрение принципов ITIL сопряжено с трудной задачей обоснования того, что эти перемены действительно принесут улучшения, в отличие от альтернативных подходов. Но книги ITIL написаны в качестве руководств, разъясняющих, как «следует» решать те или иные задачи на основе анонимных так называемых лучших практик. Вся концепция оптимальных методов основана на идее, что есть «удачные» принципы работы, доказавшие свою полезность в различных организациях. Конкретные организации, где такие методы принесли измеримый положительный результат, в книгах не указаны. Читателю самому предлагается вынести суждение о том, имеет ли смысл пользоваться написанным в той или иной ситуации. Для обоснования некоторых положений используется заверение в том, что их применение позволяет снизить затраты или улучшить результативность работы. Большинство процессов и подходов, предлагаемых в ITIL, сопровождаются большими затратами на внедрение и перемены, в обмен на это дается обещание вернуть инвестиции за счет усовершенствований, которые они принесут. Широкой публике доступно очень мало исчерпывающих исследований, реальных свидетельств и расчетов, способных поддержать каждое из положений ITIL. Отсутствие подобных ссылок дополнительно затрудняет применение принципов ITIL на практике — любой провал можно отнести либо на счет неверного подхода к внедрению, либо к дефекту самой применяемой методологии. Четкое научное обоснование упростило бы включение в ITIL новых знаний, которые появились за те годы, что прошли со времени выхода первых версий библиотеки. По-настоящему действенная методология будущего должна предусматривать способы оценки и проверки работоспособности различных рекомендаций, а также систему обмена исследованиями, которые поддерживают или опровергают действенность различных «лучших практик» управления ИТ-организациями.

Повышение роли сообщества

Социальные СМИ, например Twitter и Facebook, помогают людям объединяться в группы сторонников той или иной идеи. Так где же сообщество, которое «оживит» концепцию или по крайней мере бренд ITIL? Как ITIL может развиваться в соответствии с новыми веяниями в ИТ и обществе? Сейчас ITIL развивается  не как платформа активной эволюции и обмена идеями. Сами книги слишком дороги, чтобы их могли позволить себе частные лица, а авторские права на них усиленно охраняются. Использование концепций, описанных в книгах, для учебных материалов и в других целях регламентируется специальными правилами. Электронные платформы, имеющие лицензии на использование ITIL и связанных материалов, ориентированы на защиту их проприетарного статуса, а не на то, чтобы принимать доработки от сообщества. Даже обширные пользовательские группы вроде itSMF воспринимаются как имеющие лишь ограниченное влияние «снизу» на содержание и эволюцию основных материалов.

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

Быть проще и доступнее

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

Однако уровень абстракции остался прежним, в итоге методология выглядит как набор концепций и теорий, для наглядного представления которых нужно многомерное пространство со сложными связями. Если концепции, уместность применения и недостатки предыдущей версии ITIL еще можно было за два дня разъяснить даже младшим ИТ-специалистам, то в новом варианте это стало сложнее. За трехдневный курс некоторые слушатели осваивают лишь гору специальной терминологии и традиционные концепции, получая только общее представление о том, как все это сочетается друг с другом. В результате проприетарные подходы к внедрению ITIL, например Microsoft Operations Framework, с различным успехом предпринимают попытки упростить теории из ITIL, а стандарт ISO 20000 вобрал в себя лишь 13 элементов из сотен, представленных в ITIL.

Совместимость с другими стандартами

ITIL не позиционируется в качестве формального стандарта, и нет процесса сертификации организаций на соответствие ITIL, однако уровень зрелости отделов ИТ в сравнении с другими надо как-то оценивать. Один из путей — обучение и сертификация специалистов. Кроме того, можно сертифицировать организации на частичное соответствие принципам ITIL по стандарту ISO 20000. И наоборот, внедрение ITIL — опорный способ перехода на принципы работы в соответствии со стандартом ISO 20000. Среди других методологий, которые комбинировали с ITIL, можно назвать, например, PRINCE2, PMBOK, CMM/CMMi, ISO9000 и COBIT.

Хотя на практике ITIL может использоваться в сочетании с другими теориями, методологиями и стандартами менеджмента, практических советов по поводу того, как применять их вместе, в различных источниках очень мало. В ITIL второй версии было 10 или 11 основных процессов, а в версии 3, разные выпуски которой выходили с 2007 по 2011 год, их стало 26, а затем еще больше. Для сравнения, в ISO 20000 версии 2005 года регламентировано 13 процессов, а в версии 2011-го — от 13 до 17. В COBIT 34 процесса, а в MOF v3, MOF v4, ASL и BISL предлагаются свои перечни и во всех используются разные названия и определения. Нет единой версии истины, поэтому рекомендации из разных источников, включая ITIL, нужно комбинировать и творчески применять в конкретных ситуациях.

***

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

Том Сигерс (tom.segers@reldolmen.com) — сертифицированный ITIL Expert, менеджер по предоставлению сервисов компании RealDolmen, одного из крупнейших провайдеров ИТ-сервисов в Бельгии.

Tom Segers, «ITIL Pro and contra — 10 things that would make us love ITIL even more» — статья стала лауреатом второй премии международного конкурса статей 2013 года, организованного Международным форумом по управлению ИТ-сервисами itSMF International (2013 International Whitepaper Competition). URL: http://www.itsmfi.org/files/u1/hings_That_Would_Make_us_Love_ITIL_Even_More.pdf. Все права сохранены. Перевод публикуется с сокращениями с разрешения itSMF International в рамках партнерства издательства «Открытые системы» и itSMF Russia (www.itsmforum.ru). Полный текст перевода статьи: http:// www.osp.ru/itsm/2014/05/13041088.html.