Управление уровнем ИТ-услуг. Часть 1. Высокие отношения

Говорим на одном языке

Что такое ИТ-услуга

Книги библиотеки ITIL начиная с версии 3 (май 2007 года) содержат великолепное определение:

(Здесь и далее определения из книг ITIL представлены в редакции официального русскоязычного перевода словаря терминов ITIL, выполненного itSMF России)

Данное определение ставит два важных акцента, которые потребуются нам в дальнейших рассуждениях.

• Нематериальность услуги (это свойство отличает услугу от товара). В данном выше определении этот акцент зафиксирован словами «содействие … в получении конечных результатов … без владения специфическими затратами и рисками». Это соответствует и отечественной нормативной базе. Так, налоговый кодекс РФ (статья 38, п. 5) дает следующее определение: «Услугой … признается деятельность, результаты которой не имеют материального выражения, реализуются и потребляются в процессе осуществления этой деятельности».
• Назначение услуги – предоставлять ценность заказчикам. Это, в частности, значит, что поставщик услуг должен предоставлять не только то, что он умеет делать, а то, почему и насколько это ценно для его заказчиков. Это, в свою очередь, значит, что нужно учиться говорить с заказчиком на одном языке.

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

Но после великолепного определения услуги дело начинает откровенно буксовать. Ведь ИТ-руководителям важно определить не только что такое услуга вообще, а что такое ИТ-услуга, которая входит в их область ответственности. Здесь ITIL неожиданно предлагает следующую пару определений:

Масло масленое.

Любопытно, что стандарт ISO/IEC 20000-1:2011 Information technology – Service management изящно избегает вопроса об определении ИТ-услуги, просто не используя этот термин! Вместо этого используется понятие «услуга», а согласно названию стандарта речь, очевидно, идет об услугах, которые касаются информационных технологий.

Вместе с тем, для того чтобы дать корректное определение ИТ-услуги, достаточно сформулировать, чем ИТ-услуги отличаются от прочих, то есть какую ценность для заказчика и каким образом они обеспечивают. В книге ITIL Service Strategy 2011 Edition в разделе 2.1.6 Utility and warranty читаем:

• чтобы услуги создавали ценность, они должны приносить пользу (utility) и обладать определенными гарантиями предоставления (warranty);
• польза от ИТ-услуги заключается ИЛИ в устранении ограничений (например, раньше мы не могли предоставлять клиентам банка дистанционное банковское обслуживание, а теперь можем), ИЛИ в повышении производительности труда (например, раньше формирование отчета занимало неделю, а теперь – 10 минут);
• в отличие от товаров, услуги не обладают внутренней ценностью. Ценность услуги определяется потребителем на основании того, какие новые возможности он получает, используя данную услугу.

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

(Под информационными процессами здесь мы понимаем процессы, связанные со сбором, обработкой, хранением, передачей или распространением информации).

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

Вот некоторые примеры ИТ-услуг:

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

Что такое сервисный подход

Как показали бурные дискуссии в ITSM-сообществе в 2012 году, понятие сервисного подхода также требует пояснения.

В книге ITIL Service Strategy 2007 года было несколько упоминаний понятия «сервисный подход» (service-oriented approach). Суть сводилась к тому, что сервисный подход есть концепция, перенесенная в ИТ из традиционного бизнеса. Она заключается в том, что ИТ-организации меняют фокус в диалоге с заказчиками – ставят во главу угла не области собственной компетенции (сети, приложения, базы данных), а ценность для заказчика, которую все эти компетенции, будучи правильно организованы, могут обеспечить. Именно так выживают и развиваются компании, оказывающие услуги на коммерческой основе, внутренним ИТ-поставщикам это свойственно в гораздо меньшей степени.

Аналогичного мнения придерживаются и международные эксперты, которым мы задавали вопрос о том, существует ли понятие «сервисный подход», и если да, то что оно означает. Их ответы приведены во врезке.

Следовательно, учитывая приведенные выше определения услуги и ИТ-услуги, понятие сервисного подхода в применении к ИТ можно определить таким образом:

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

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

Рис. 1. Баланс сервисных отношений

Типичными (хотя и не строго обязательными) свидетельствами сервисного подхода на предприятии являются:

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

Этот список можно использовать как форму самопроверки – чем больше свидетельств присутствует на предприятии, тем больше оснований говорить о зрелости сервисного подхода.

Любопытную (как всегда) позицию занимает IT-Skeptic (Роб Ингланд). Вот что он пишет в одной из своих заметок:

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

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

За (преимущества)…

Определившись с базовыми понятиями, можно перейти к ответу на главный вопрос — зачем? Что приобретают для себя (или могут приобрести) организации, решившиеся на реализацию сервисного подхода? Рассмотрим наиболее яркие ответы на этот вопрос.

Более четкое определение взаимных обязательств

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

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

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

Выравнивание видения поставщика и потребителей

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

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

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

Основа для объективной оценки деятельности ИТ-подразделения

Проектная деятельность измеряется относительно легко: есть список проектов, есть сроки и ответственные. Все, что нужно, – это ввести менеджерам проектов (и их руководителям) KPI по своевременности и качеству выполнения проектов. Качество может, например, оцениваться опросом заинтересованных сторон по утвержденной форме, рассчитываться как доля реализованных проектных требований или определяться проектным комитетом при закрытии проекта на основании заданных критериев. Допустим, K1 – это доля своевременно выполненных проектов (в диапазоне от 0 до 1), а K2 – оценка качества (также от 0 до 1). Тогда KPI = K1 x K2. Устанавливаем целевое значение (например, 0,9), и в целом задача решена.

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

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

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

Своевременное планирование и обоснование ресурсов

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

Однако после окончания проекта жизнь не застывает в статичной форме. Сегодня с приложением работает тысяча пользователей, а через год за счет подключения филиалов пользователей станет в три раза больше. Сегодня система обслуживает 100 тыс. транзакций в день, а завтра в связи с планами по захвату рынка их ожидается в десять раз больше. Сегодня отчет формируется по базе в 100 Гбайт, а в следующий год размер базы может составить 0,5 Тбайт. И перечисленные изменения не обязательно реализуются в форме проекта. Правда заключается в том, что они происходят постоянно, постепенно, не всегда предсказуемо и очень редко – управляемо (по крайней мере, с точки зрения поставщика ИТ-услуг).

Появляется ли при этом потребность в дополнительных ресурсах? Конечно. Но, в отличие от проекта, связать их с потребностями конкретных бизнес-подразделений гораздо труднее. Получается, что ИТ-подразделение постоянно просит ресурсы для себя, хотя на самом деле это в корне неверно.

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

Экономически обоснованное управление ИТ

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

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

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

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

…и против (трудности)

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

Остановимся на наиболее значимых моментах:

• отсутствие важнейшего рыночного механизма – конкуренции. В сценариях с внутренним ИТ-подразделением одновременно присутствуют признаки и монополии (один поставщик), и монопсонии (один потребитель). Более того, если в части стандартных приложений и пользовательской инфраструктуры (рабочие места, оргтехника) конкуренцию теоретически могут составить внешние поставщики ИТ-услуг, то в части сопровождения и эксплуатации информационных систем, поддерживающих основные бизнес-процессы предприятия, риск внешней конкуренции практически равен нулю. Это лишает стороны основного стимула развиваться, слышать контрагента, идти на компромисс и приходить к взаимовыгодным соглашениям – то есть важнейших основ сервисного подхода;
• широкое распространение доминирующей модели декларативного управления. Зачем ИТ-руководителю искать возможности для оптимизации, если сверху в любой момент может быть спущено требование «сократить затраты на 30%»? Чтобы выжить в такой ситуации, необходимо не оптимизироваться, а напротив – сохранять избыток ресурсов, которыми в крайнем случае можно пожертвовать (чтобы, пережив, снова накапливать внутренний резерв);
• отсутствие спроса на управление уровнем ИТ-услуг со стороны бизнес-подразделений. Отчасти это вызвано тем, что ИТ-подразделения затрудняются предложить в соглашениях об уровне ИТ-услуг что-либо, кроме ограничений. Разумеется, эта идея не находит горячего энтузиазма у потребителей ИТ-услуг. И это вовсе не говорит об их незрелости (как думают некоторые ИТ-специалисты), просто поставщик и заказчик говорят на разных языках и каждый преследует свои цели;
• сложности с формированием бизнес-ориентированного каталога ИТ-услуг. ИТ-специалисты традиционно формируют каталог услуг как перечень ИТ-систем. Такой подход непонятен потребителям ИТ-услуг, поскольку во многих случаях ни одна информационная система сама по себе не обеспечивает ценный бизнес-результат (например, какая ИТ-система обеспечивает своевременное закрытие операционного дня банка?). Как следствие, при формировании каталога ИТ-услуг от систем значительно труднее найти и включить в работу ответственных за ИТ-услуги со стороны заказчика. Кроме того, такой подход оставляет нерешенными массу вопросов по интеграции систем между собой (то есть на стыке ответственности) и в крупных компаниях приводит к каталогу из нескольких сотен ИТ-услуг, крайне неудобному в работе. С другой стороны, бизнес-подразделения в своей массе не настолько зрелы, чтобы четко сформулировать актуальную модель бизнес-процессов предприятия, которая могла бы стать основой бизнес-ориентированного каталога ИТ-услуг. Отчасти это связано с относительно низким уровнем конкуренции на рынке – предприятия пока не исчерпали возможности экстенсивного роста, а потому не слишком озабочены качеством обслуживания клиента и операционным совершенством (какие бы лозунги при этом ни звучали);
• сложности с закреплением сквозной ответственности за ИТ-услугу (как со стороны поставщика, так и со стороны заказчиков ИТ-услуг). Повсеместная «проблема пуговиц» – каждый привык отвечать за свой функциональный участок и не видит причин расширять зону ответственности;
• нехватка навыков ведения переговоров и позитивной установки у ИТ-менеджеров. Присутствуя на встречах по согласованию SLA между ИТ-поставщиком и заказчиком ИТ-услуг, я много раз слышал от менеджеров ИТ-услуг такой ответ: «Нет, мы это сделать не можем, потому что…». И действительно, не все пожелания заказчика можно реализовать. Но если хотя бы в половине случаев ответ был: «Хорошо, мы можем это сделать, но для этого нам понадобится…», прийти к компромиссу было бы гораздо проще.

Заключение

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

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

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

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

Дмитрий Исайченко (d.isaychenko@cleverics.ru) — директор по консалтингу компании Cleverics, ITIL Expert, член экспертного совета itSMF России