Каталог ИТ-услуг: как приручить дракона

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

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

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

Каким должен быть каталог услуг?

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

Минимум определен. Но достаточен ли он? Попробуем разобраться.

Традиционно каталог услуг соотносят с теми процессами, которые раньше (в ITIL® второй версии) назывались «процессами предоставления услуг», а теперь (в ITIL третьей версии) - «процессами проектирования услуг». Эти процессы, а в первую очередь - процесс управления уровнем услуг (Service Level Management), работают в трех основных областях: проектирование новых/изменяемых услуг; управление качеством услуг, находящихся в эксплуатации; управление взаимоотношениями.

• Проектирование услуг - это деятельность по трансляции требований заказчиков к услугам (Service Level Requirements, SLR) в детальные спецификации услуг, включающие в себя их основные характеристики, модели услуг, требования и критерии для успешного развертывания услуг и их последующей эксплуатации. ITIL v3 называет результат этой деятельности Service Design Package, SDP.
  Требования к информации: для того, чтобы проектировать услуги, надо понимать как организована работа по их предоставлению, развертыванию, эксплуатации и поддержке, какие при этом необходимы и/или используются ресурсы, какие задействованы внешние и внутренние услуги.
• Управление качеством услуг, находящихся в эксплуатации, предполагает анализ данных о предоставлении услуг, оценку качества услуг и инициацию корректирующих мер, направленных либо на обеспечение соответствия этого качества ранее согласованным критериям, либо на его повышение с учетом ожидаемого будущего изменения этих критериев.
  Требования к информации: для того, чтобы выполнить эту работу, необходимо организовать сбор данных о функционировании компонентов инфраструктуры и исполнении работ внешними и внутренними командами, влияющих на итоговое качество услуги, а также об удовлетворенности заказчиков и конечных пользователей услуг.
• Управление взаимоотношениями можно разделить на две подгруппы - управление отношениями с поставщиками и управление отношениями с заказчиками (такое разделение используется в стандарте ISO/IEC 20000, и отчасти - в ITIL v3).
  Требования к информации: для того, чтобы управлять взаимоотношениями с поставщиками, надо знать какие услуги и на каких условиях они нам предоставляют, как эти услуги влияют на услуги, которые мы предоставляем заказчикам.
  Для того же, чтобы управлять отношениями с заказчиками, важно владеть информацией о том, какие услуги мы каждому из них предоставляем, каково влияние этих услуг на бизнес-деятельность, каковы особенности наших услуг при предоставлении разным заказчикам, как распределяются общие ресурсы (задействованные в предоставлении услуг для разных заказчиков).

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

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

Какие бывают каталоги?

Рассмотрим несколько моделей применения и, следовательно, организации каталога услуг.

Простой каталог

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

Цели / потребности:

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

Структура каталога: таблица с перечнем услуг.

Основные поля: идентификатор услуги, название¹, краткое описание (функциональное назначение услуги); тип услуги (см. ниже пример классификации услуг); основной заказчик услуги; бизнес-приоритет (уровень критичности); место предоставления; часы предоставления поддержки; ответственный в ИТ²; группа, ответственная за поддержку; статус³;

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

Преимущества: такой каталог довольно прост в формировании и сопровождении, он дает «быстрые победы», позволяя существенно оптимизировать процессы поддержки.

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

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

Непростой каталог

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

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

Цели / потребности:

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

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

Возможные компоненты: справочник услуг, предусматривающий различные представления для целей управления поставщиками, качеством отдельных услуг, отношениями с заказчиками и т.д.; модели услуг, позволяющие наглядно отобразить связи и зависимости как для «исходящих» услуг (от чего зависит услуга N?), так и для «входящих» (какие услуги зависят от услуги Z?); параметры (показатели объема и качества) услуг, а также их целевые и пороговые значения, согласованные с заказчиком, и информация о том, как по этим параметрам собираются данные и представляются отчеты; внутренние («технические») описания услуг, включающие в себя перечни основных систем и/или ресурсов, от которых зависит предоставление каждой услуги⁴.

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

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

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

Многоуровневый каталог

Известный критик «лучших практик», Роб Ингланд (Rob England), он же IT Skeptic, в своей книге «Owning ITIL» пишет о каталоге услуг⁵: «Каталог направляет ваших сотрудников. Это ключевой механизм изменений в культуре ИТ, основа отношений с заказчиками и важнейший инструмент организационных преобразований. Каталог услуг дает информацию всем процессам. Как только услуга определена в каталоге, процессы знают, что от них требуется, и знают, как приоритизировать эти требования».

В модели Скептика есть четыре уровня каталога услуг:

1. Актуальный каталог / Current Catalogue: срез текущего состояния, перечисление всех фактически предоставляемых услуг, включая те устаревшие услуги, которые мы больше не предлагаем новым пользователям. Это основной и необходимый элемент всей сервисной деятельности нашей ИТ-службы. Целевая аудитория - ИТ.
2. Красивый каталог / Brochure Catalogue: высокоуровневый документ, написанный бизнес-языком, определяющий, что ИТ предлагает заказчикам. Используется как основа для управления отношениями с заказчиками. Также используется пользователями как справочник при взаимодействии с ИТ. Определяет целевое состояние. Целевая аудитория - заказчики, пользователи.
3. Технический каталог / Technical Catalogue: объединение актуального и красивого каталогов, дополненное подробной технической информацией. Используется в работе ИТ. SLA (если есть) являются частью технического каталога; кроме того, в него входят: перечень критических компонентов, связанные услуги, правила эскалации… Целевая аудитория - ИТ.
4. Автоматизированный каталог / Automated Catalogue: интерактивный инструмент, позволяющий пользователям просматривать и заказывать услуги. Важно понимать, что технологическая оболочка - самая простая часть такого каталога. Она должна быть основана на трех перечисленных выше документах. Эти уровни дополняют друг друга, а не заменяют. Целевая аудитория: пользователи.

Из всего этого можно и нужно как можно быстрее создать Актуальный каталог. Красивый и Технический появятся со временем. Многие организации никогда не будут использовать Автоматизированный каталог.

Лучший каталог - полезный каталог

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

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

Сноски:

1. Верное определение услуг в каталоге - непростая и очень важная задача, достойная отдельной статьи.
2. Во многих проектах использовалась роль «куратор услуги», в ITIL v3 это «владелец услуги» (service owner).
3. Возможные статусы: планируется; в разработке; пилот; в эксплуатации; приостановлена; архив.
4. Известны случаи, когда в состав «непростого» каталога включаются также ресурсно-сервисные модели услуг и правила распределения затрат, связанных с услугами, на поддерживающие услуги и ресурсы. (См., например: К.Скрипкин, С.Растопшина, И.Баринов, «Основание. Каталог услуг в управлении ИТ-службой». Альманах «itSMF Россия 2010. Избранные статьи».
5. R.England, «Owning ITIL. A skeptical guide for decision makers» © Copyright Two Hills Ltd 2009, стр. 90-92
6. Если вы чувствуете, что для управления каталогом вам нужен специально организованный процесс Service Catalogue Management, то, скорее всего, вы нарушили два следующих правила в списке.

Автор: Лариса Будкова.