Среди всех подходов к управлению ИТ наибольшую популярность завоевала концепция IT Service Management. Суть ITSM хорошо известна, коротко ее можно сформулировать так: «Всем будет удобно, если основной результат работы ИТ‑подразделения представить в виде некоего набора ИТ-услуг».

Нет нужды описывать концепцию подробнее, ибо существует бесчисленное множество литературы на данный счет. Невооруженным взглядом видна всеобщая увлеченность этой темой, порой граничащая с эйфорией: «Вот оно, лекарство! Вот он, рецепт! Теперь‑то отношения с основным бизнесом наладятся, да и внутри ИТ‑отдела можно порядок навести…»

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

Краткая историческая справка

В середине прошлого столетия были изобретены и построены первые электронно-вычислительные машины, ЭВМ.

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

Однако в середине 70‑х годов прошлого века произошла революция, мир сильно изменился. Изобретение микропроцессора и создание на его основе микроЭВМ привели к возникновению той области знаний, которая теперь называется информационными технологиями. Информационные технологии стали доступны большому числу предприятий, круг решаемых задач драматически увеличился. Тем не менее новые возможности принесли с собой и новые заботы. Весьма заметным было стремление сделать всех пользователей прикладными программистами. Отчего же бизнес-пользователю не написать для себя программу самостоятельно? Искусству программирования стали учить даже в гуманитарных вузах.

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

Представление результатов работы ИТ-отдела

Исторически первым возник подход к управлению ИТ, который можно условно назвать компонентным. Его суть — ИТ-отдел предоставляет компании средства автоматизации, программно-аппаратные комплексы, одним словом — компоненты. Обычно в организации формируется отдельное подразделение, называемое, к примеру, департаментом информационных технологий. Во главе подразделения назначается руководитель — как правило, из числа толковых и опытных ИТ‑специалистов. Работа подразделения строится по принципу «получили задание — начинаем работать, а в остальное время следим за техникой». Задания формируются как функциональные требования к системам автоматизации: программа должна уметь выполнять определенные действия в ответ на определенные управляющие воздействия пользователя. Такого рода требования вполне реально получить от бизнес-заказчиков, которые зачастую так и называются — функциональные заказчики. Требования к надежности, доступности, обеспечению непрерывности и проч., как правило, системно не формируются, либо разрабатываются не для всех программно-аппаратных средств. И уж совсем редко они формируются для ИТ-инфраструктуры целиком.

Крайний случай такого подхода к управлению — собственные ИТ‑специалисты, входящие в какое‑либо бизнес-подразделение и подчиняющиеся непосредственно руководителю такого подразделения. Например, бухгалтерия (или финансовый департамент, или департамент контроллинга) имеет своих программистов 1С, никак не относящихся к ИТ‑департаменту компании (у которого, кстати, свой отдел программирования) и не подчиняющихся общим правилам компании в области ИТ. При этом управляемая и развиваемая такими программистами ИТ‑система (в данном случае — 1С) располагается в общей, разделяемой ИТ-инфраструктуре. Устойчивость такой управленческой конструкции зависит от власти и веса руководителя бизнес-подразделения, имеющего собственных специалистов по ИТ.

Может ли работать такая «компонентная» концепция управления ИТ? Безусловно. Более того — в большинстве российских компаний, в которых есть хоть какое‑то управление, именно она и работает.

Преимущества такого подхода весьма значительны: так как руководитель ИТ-отдела обычно «вырастает» из технического специалиста, строить работу вверенного подразделения ему проще, если и с бизнесом разговаривать категориями компьютеров и программ. «Строить работу» в данном случае означает: формировать организационно-штатную структуру, распределять обязанности, ставить цели и задачи, контролировать исполнение. Если исходить из подхода «ИТ-отдел предоставляет бизнесу средства автоматизации», то все перечисленные задачи не выглядят такими уж сложными. Однако есть и недостатки: во‑первых, основной бизнес организации, включая тех самых функциональных заказчиков, не всегда понимает, чем же так заняты люди в ИТ‑департаменте. Зачем их там так много? Из чего складывается ИТ-бюджет компании? Почему численность ИТ-персонала и размер ИТ-бюджета постоянно увеличиваются, если их сотрудники всего лишь настраивают программы да меняют картриджи в печатающих устройствах?

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

Важная особенность такого «компонентного» подхода — следующее наблюдение из практики: для того чтобы ИТ-директору сохранить свое рабочее место, ему необходимо уделять самое пристальное внимание двум основным направлениям:

  • обеспечивать стабильность среды эксплуатации — имеющиеся ИТ‑системы не должны часто «падать», и если уж «упадут», то должны быстро подниматься;
  • постоянно предлагать основному бизнесу новый функционал ИТ‑систем, чтобы тот ощущал пользу от ИТ.

Тот самый сервисный подход

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

Следствие применения сервисного подхода для ИТ-руководителя — более четкое понимание собственной зоны ответственности. В пример можно привести высказывание одного из ИТ-директоров, работающего в крупном российском банке: «Сервисный подход позволил мне ответить на вопрос «за что меня могут уволить?». А затем стало понятно, что следует делать, чтобы этого избежать».

Ключевое отличие сервисного подхода от прочих — в понятии «ИТ-услуга». С тех пор, как библиотека ITIL второй версии неосторожно назвала ИТ-услугой «одну или более ИТ‑систем, позволяющих работать бизнес-процессу (ITIL Service Delivery, 2000)», в умах началась самая настоящая путаница. Вроде бы ИТ-услуги и ИТ‑системы суть одно и то же. Однако же нет, ИТ-услуга гораздо больше! В случае внутреннего ИТ-подразделения это все, что нужно для работы конечного бизнес-пользователя, — и программа, и АРМ, и сеть, и поддержка Service Desk… Только такой взгляд на ИТ-инфраструктуру и деятельность ИТ-персонала позволяет, к примеру, определить сквозные (end-to-end) требования к доступности ИТ-услуг, от АРМ пользователя через всю широкую инфраструктуру до последнего сектора на жестком диске сервера.

Не только сервисы

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

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

Под ценностью подразумевается помощь в решении задач заказчика — повышение производительности бизнес-процессов и снижение влияния ограничений. Услуги — не самоцель (рис. 1). Так, COBIT не рассматривает предоставление услуг в качестве цели деятельности ИТ, но говорит об услугах просто как об основной форме предоставления информации: «Чтобы обеспечить организацию информацией для достижения целей, она должна инвестировать в ресурсы ИТ и управлять ими посредством структурированного комплекса процессов, обеспечивающих предоставление услуг для предоставления информации».

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

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

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

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

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

Четвертый контур, строго говоря, не относящийся к деятельности ИТ-подразделения, — это IT Governance, деятельность по обеспечению разумной уверенности в том, что информационные технологии в компании используются результативно, рационально, в соответствии с требованиями закона и регулирующих органов, а связанные с ИТ риски эффективно контролируются. Мы будем называть эту сферу деятельности «руководством ИТ». Руководство ИТ — область ответственности CIO, уполномоченного высшего руководителя компании, «курирующего» ИТ.

Отношения руководства ИТ и управления ИТ кратко можно описать следующим образом: Система управления ИТ предоставляет отчетность, позволяющую оценить полезность, рациональность, соответствие нормам и управление ИТ-рисками. Руководство ИТ транслирует в ИТ стратегические цели и ограничения, оценивает работу системы управления ИТ, предоставляет информацию о результатах оценки владельцам бизнеса и инициирует коррективы стратегии ИТ и системы управления ИТ (рис. 2). Для целей руководства ИТ могут использоваться такие средства, как контроль и аудит системы управления ИТ, в том числе — внешний аудит.

Но вернемся «внутрь» системы управления ИТ. Как, в самых общих чертах, она работает?

Сценарий 1, фантастический

  1. Высшее руководство формирует и утверждает стратегию бизнеса.
  2. На основании стратегии бизнеса CIO организует формирование и утверждение стратегии ИТ. В это же время на основании стратегии бизнеса определяются тактические цели организации и выстраиваются либо изменяются бизнес-процессы.
  3. На основании ИТ‑стратегии ИТ-менеджер ИТ под контролем CIO организует управление ИТ‑деятельностью (систему процессов и проектов). На основании той же стратегии и детализированных требований процессов и проектов формируются и развиваются активы ИТ — ресурсы и возможности. В это же время менеджеры бизнес-процессов формируют потребности в отношении автоматизации и информатизации бизнес-процессов.
  4. Менеджеры бизнес-процессов совместно с владельцами ИТ-услуг определяют требования к услугам. И оказывается, что активы, процессы и проекты ИТ как раз готовы эти требования поддержать, так как спроектированы и реализованы на основе той же бизнес‑стратегии, что и процессы, формирующие требования.
  5. Согласованные услуги предоставляются и поддерживаются. Их качество контролируется и повышается.
  6. Отчетность об услугах и процессах подтверждает соответствие ИТ‑деятельности и ее результатов требованиям бизнеса.

К сожалению, нам не встречались организации, в которых этот сценарий был бы реализован.

Сценарий 2, пессимистичный

  1. Стратегия бизнеса и бизнес-процессы развивались независимо друг от друга.
  2. Стратегия ИТ отсутствует либо представляет собой набор слайдов PowerPoint.
  3. Активы ИТ формировались естественно, в ответ на возникающие оперативные задачи.
  4. Менеджеры бизнес-процессов (или бизнес-функций) формируют требования к автоматизации и информатизации и предъявляют их ИТ-менеджерам.
  5. ИТ-менеджеры стараются оценить реализуемость требований и организовать использование активов ИТ так, чтобы результирующие продукты и основанные на них услуги максимально походили на то, как ИТ-менеджеры представили решение задачи, поставленной бизнес-менеджерами.
  6. Услуги, которые удается предоставить, предоставляются. Отчетность об их качестве формируется нерегулярно и неполно, совершенствование услуг производится эпизодически.

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

  • бизнес предъявляет требования к услугам;
  • услуги предъявляют требования к ИТ‑дея­тельности (процессам и проектам);
  • ИТ‑деятельность предъявляет требования к ИТ-активам (ресурсам и возможностям).

В ответ на предъявленные требования процессам и проектам предоставляются ресурсы и возможности; процессы обеспечивают предоставление услуг, проекты при необходимости формируют новые активы.

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

Очевидно, что по мере формирования комплексной системы управления ИТ организация сталкивается с важными и сложными задачами, не характерными для проектов «внедрения одного-двух процессов». Решение этих задач сопряжено с существенным реформированием ИТ-организации, немалыми затратами и рисками.

А что же дальше? Предсказания, прогнозы и пророчества

Не претендуя на полноту и уж тем более на точность, мы все же рискнем описать несколько сценариев развития ITSM в России.

Прогресс не остановить

  • Доля ИТ-решений, разработанных собственными силами, неуклонно снижается. Потребность в проектах, направленных на создание или модификацию ресурсов, сокращается. Проектная часть ИТ переориентируется с технических на организационные проекты или сокращается до незначительных размеров.
  • Доля услуг, использующих «чужую» инфраструктуру, доля «внешних» услуг в сервисном портфеле ИТ постоянно растет. Доля полностью «своих» услуг снижается.
  • Управление услугами для внутренней ИТ‑служ­бы постепенно превращается в управление взаимоотношениями — с поставщиками, с одной стороны, и с заказчиками, с другой. Прочие процессы ITSM сохраняются только у компаний-провайдеров.
  • ITSM перестает быть массовой методологией, превращается в узкоспециальный инструмент, подобный eTOM, усложняется и в то же время стандартизируется.

Мы пойдем своим путем

  • Бизнес-процессы компаний старательно сохраняют уникальность: в крупных компаниях — вследствие масштаба и неравномерного уровня зрелости, в небольших — вследствие низкого уровня зрелости и уверенности руководства в том, что собственные бизнес-процессы являются ноу-хау, либо, того хуже, конкурентным преимуществом.
  • Типовые решения не приживаются и требуют адаптации, сравнимой по масштабам с разработкой с нуля. Каждое новое требование заказчика требует привлечения проектного механизма управления.
  • Наряду с процессами поддержки (уже широко распространенными) активно применяются процессы управления уровнем услуг, изменениями и релизами, развиваются механизмы взаимодействия с проектами.
  • Формируется упрощенная модель управления услугами, подкрепленная организационными решениями (моделями ITSM‑совместимой организационной структуры), ее использование постепенно становится стандартом де-факто.
  • Адаптированная русскоязычная методология ITSM широко распространяется в России, пока в Европе реализуется первый сценарий.

Мы не пойдем

  • Российские подразделения западных корпораций и передовые российские компании постепенно реализуют первый сценарий.
  • Государственные и окологосударственные структуры реализуют второй сценарий, принимаются и насаждаются национальный ITSM‑стандарт и отраслевые стандарты (например, в банковской сфере), развивается соответствующий рынок услуг — аудит, сертификация…
  • Большинство российских компаний продолжает работать без учета рекомендаций и принципов ITSM, сохраняя в управлении ИТ уровень зрелости, близкий к единице. Что всех устраивает, потому что соответствует уровню зрелости всей организации. Во всех случаях анализ, создание, совершенствование теории ITSM останется уделом небольшого профессионального сообщества. Массовый характер может носить (или не носить) применение того, что это сообщество создаст. Российскому ITSM‑сообществу около десяти лет, и какой бы ни была судьба ITSM в России, можно уверенно утверждать, что у него все еще впереди.