Лариса Будкова, ведущий тренер-консультант, Cleverics
Роман Журавлёв, директор по обучению, Cleverics
Все, кто так или иначе сталкиваются с необходимостью организации работы по управлению ИТ-услугами, признают важность каталога услуг. В самом деле, первое, что представляется разумным сделать при решении такой задачи, это ограничить ее. Как средство ограничения охвата системы управления услугами, а вместе с ним – и ответственности службы ИТ, каталог может быть полезен любому поставщику ИТ-услуг – внешнему, внутреннему…
Вторая очевидная функция каталога – определить предмет взаимодействия с заказчиком. Идет ли речь о первичных переговорах (продажа/покупка услуг), или о регистрации инцидентов и запросов, или об оценке качества услуг за период – каталог как меню помогает заказчику и поставщику услуг общаться друг с другом.
Естественным дополнением названных функций является использование каталога для закрепления ответственности за качество отдельных услуг и последующего определения виновных в неудовлетворительном качестве этих услуг.
С учетом перечисленных функций можно определить структуру простейшего каталога услуг: это перечень всех услуг, предоставляемых заказчикам или доступных для заказа, с указанием для каждой услуги основной функциональности (назначения), а также лица или подразделения, отвечающего за ее предоставление.
Минимум определен. Но достаточен ли он? Попробуем разобраться.
Традиционно каталог услуг соотносят с теми процессами, которые раньше (в ITIL второй версии) назывались «процессами предоставления услуг», а теперь (в ITIL третьей версии) – «процессами проектирования услуг». Эти процессы, а в первую очередь – процесс управления уровнем услуг (Service Level Management), работают в трех основных областях: проектирование новых/изменяемых услуг; управление качеством услуг, находящихся в эксплуатации; управление взаимоотношениями.
Какие из перечисленных потребностей в информации могут быть удовлетворены или поддержаны с использованием простейшего каталога услуг? Безусловно, каталог, представляющий собой «перечень всех предоставляемых услуг», для вышеперечисленных задач не достаточен. Но, быть может, он с небольшими дополнениями подойдет для решения более простых задач, например, оптимизации поддержки пользователей?
Очевидно, что не существует универсального, «правильного» каталога. В каждом случае направление развития каталога и его структура будут зависеть от того, кто будет ключевыми потребителями содержащейся в нем информации, их задач и, соответственно, требований – к охвату и детальности информации в каталоге, к механизмам ее обработки и представления.
Рассмотрим несколько моделей применения и, следовательно, организации каталога услуг.
Что в учебниках?
2001: ITIL®v2 (Service Delivery, ©2001 Crown Copyright): «Перечень услуг, типовых уровней и дополнительных возможностей.»
2003: MOF ® v3 (Service Level Management SMF, ©2003 Microsoft Corporation ): «Перечень всех услуг, используемых в организации».
2007: ITIL® v3 (ITIL®v3 Glossary Russian Translation v0.92, itSMF-Russia): «База данных или структурированный документ, содержащий информацию обо всех ИТ-услугах в режиме промышленной эксплуатации, включая те ИТ-услуги, которые доступны для развертывания. Каталог услуг – единственная часть портфеля услуг, которая публикуется для заказчиков и используется для поддержки продаж и предоставления ИТ-услуг. Каталог услуг включает в себя информацию о результатах, ценах, точках контакта, процессах выполнения заказов и запросов.»
2008: MOF® v.4.0 (Glossary, © 2008 Microsoft Corporation): «Полный перечень услуг, включающий бизнес-приоритеты и связанные с услугами SLA.»
Ситуация: системное управление ИТ-услугами только начинается. Организованы процессы поддержки пользователей, осуществляется регистрация и контролируемая обработка заявок. Требования к качеству услуг не формализованы, критерии качества поддержки универсальны или минимально дифференцированы.
Цели / потребности:
Структура каталога: таблица с перечнем услуг.
Основные поля: идентификатор услуги, название*1, краткое описание (функциональное назначение услуги); тип услуги (см. ниже «Пример классификации услуг»); основной заказчик услуги; бизнес-приоритет (уровень критичности); место предоставления; часы предоставления поддержки; ответственный в ИТ*2; группа, ответственная за поддержку; статус*3;
Возможные поля: группы пользователей услуги и их уровни поддержки, регламентированные запросы на обслуживание, сценарии определения высокого влияния услуги на бизнес-деятельность (временные периоды, определенные события), целевые группы оповещения.
Преимущества: такой каталог довольно прост в формировании и сопровождении, он дает «быстрые победы», позволяя существенно оптимизировать процессы поддержки.
Недостатки: «простой» каталог описывает только предоставляемые услуги, и поэтому почти не дает информации для управления взаимоотношениями с внутренними и внешними командами, обеспечивающими управление «составными частями» услуги. Как правило, он не содержит информации о стоимости подключения/предоставления услуг, а в тех случаях, когда содержит, эта информация статична и формируется без использования каталога. Когда требования разных заказчиков к качественным характеристикам услуги (функциональности, производительности, доступности) заметно отличаются, использование «простого» каталога не оправдывает затрат на его сопровождение.
Примечание: для многих российских компаний, сознательно организующих управление ИТ-услугами, «простой» каталог будет полезен и достаточен.
Выход в 2007 году третьей версии ITIL® подтвердил давно уже многими принятую модель, согласно которой каталог услуг должен использоваться для управления всеми услугами, находящимися под контролем ИТ, а не только предоставляемыми («исходящими»). Это предполагает включение в каталог внешних и внутренних операционных услуг, появление в нем невидимой заказчикам области. Очевидно, что такое расширение каталога имеет смысл только вместе с добавлением в него информации о связях и взаимном влиянии услуг. С учетом этого добавления структура каталога перестает укладываться в простой список или таблицу, и становится уместным говорить о каталоге как о базе данных.
Ситуация: бизнес требует обоснования затрат на предоставляемые ИТ-услуги и гарантий качества услуг; ИТ-менеджмент нуждается в понимании структуры затрат и зависимости от субподрядчиков. При этом «полноценные» процессы управления финансами, конфигурациями, поставщиками по каким-либо причинам не выстраиваются.
Цели / потребности:
Структура каталога: база данных, содержащая информацию обо всех управляемых услугах, связях и зависимостях между ними, показателях объема и качества услуг и их согласованных целевых значениях.
Возможные компоненты: справочник услуг, предусматривающий различные представления для целей управления поставщиками, качеством отдельных услуг, отношениями с заказчиками и т. д.; модели услуг, позволяющие наглядно отобразить связи и зависимости как для «исходящих» услуг (от чего зависит услуга N?), так и для «входящих» (какие услуги зависят от услуги Z?); параметры (показатели объема и качества) услуг, а также их целевые и пороговые значения, согласованные с заказчиком, и информация о том, как по этим параметрам собираются данные и представляются отчеты; внутренние («технические») описания услуг, включающие в себя перечни основных систем и/или ресурсов, от которых зависит предоставление каждой услуги*4.
Преимущества: Как альтернатива построению CMDB, организации системы функционально-стоимостного учета и заключению множества SLA, «непростой» каталог услуг позволяет при сравнительно(!) невысоком уровне затрат на построение и сопровождение помочь в решении важных управленческих задач. Одновременно он не отменяет возможности развития полнофункциональных процессов управления финансами, конфигурациями, уровнем услуг и других. Напротив, сформированный таким образом каталог создает благоприятные условия для их дальнейшего развития. При этом «непростой» каталог сохраняет все плюсы «простого», кроме, разумеется, простоты.
Недостатки: Невысокий уровень затрат – лишь сравнительная характеристика. Разработка, наполнение и сопровождение «непростого» каталога требуют серьезных ресурсов и могут столкнуться с ограничениями средств автоматизации или нехваткой у участников проекта специфических знаний. Срок получения полезного результата существенно дольше, чем у «простого» каталога, в то время как точность, в особенности финансовой информации, невысока.
Примечание: «непростой» каталог услуг – одна из форм всегдашнего стремления ИТ специалистов и руководителей построить систему «все в одном», которая позволит эффективно автоматизировать всю работу. Авторы ITIL® видят в качестве такой мега-системы систему управления знаниями. Все понимают, что построить такую штуку нельзя, но, поскольку по-прежнему очень хочется, начинают искать компромиссные решения. «Непростой» каталог услуг – одно из таких решений. Выбирая этот путь, важно не увлекаться. Точка получения полезного результата за разумные деньги лежит на этом пути гораздо раньше, чем точка достижения совершенства полноты и точности.
Известный критик «лучших практик», Роб Ингланд (Rob England), он же IT Skeptic, в своей книге «Owning ITIL» пишет о каталоге услуг*5: «Каталог направляет ваших сотрудников. Это ключевой механизм изменений в культуре ИТ, основа отношений с заказчиками и важнейший инструмент организационных преобразований. Каталог услуг дает информацию всем процессам. Как только услуга определена в каталоге, процессы знают, что от них требуется, и знают, как приоритизировать эти требования.»
В модели Скептика есть четыре уровня каталога услуг:
Из всего этого можно и нужно как можно быстрее создать Актуальный каталог. Красивый и Технический появятся со временем. Многие организации никогда не будут использовать Автоматизированный каталог.
Подведем некоторые итоги. Как любой инструмент управления ИТ-услугами, каталог должен обеспечивать решение актуальных задач и поддерживать развитие системы управления. При этом польза от его использования должна перевешивать затраты и риски, связанные с его внедрением и сопровождением. Для того, чтобы так все и случилось, могут быть полезными следующие простые правила:
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, то, скорее всего, вы нарушили два следующих правила в списке.
Источник: www.it4business.ru/lib/2256/