Библиотека ITIL. Проектирование услуг

Процесс "Управление Каталогом услуг"

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

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

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

Границы процесса. Процесс включает следующие активности:

• определение услуги;
• создание и поддержание точного Каталога услуг;
• интерфейсы, зависимости и согласованность Каталога услуг и Портфеля услуг;
• интерфейсы и зависимости между всеми услугами (включая поддерживающие услуги), содержащимися в Каталоге, и Системой управления конфигурацией^{19англ. Configuration Management System} ;
• интерфейсы и зависимости между всеми услугами и поддерживающими их компонентами и Элементами конфигурации^{20англ. Configuration Items} , содержащимися в Каталоге услуг и Системе управления конфигурацией.

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

Политики, принципы и базовые концепции

Каждая организация должна разработать и поддерживать политику, относящуюся к содержанию Портфеля и Каталога услуг. Политика должна определять детальность описания и статус каждой услуги. Политика должна также определять ответственности за поддержание каждого раздела Портфеля услуг (т. е. Воронки услуг и Каталога услуг), а также границы и содержание разделов.

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

Рис. 12.3. Структура Каталога услуг

В простейшей форме Каталог услуг может представлять собой матрицу или электронную таблицу. Часто Портфель услуг и Каталог услуг интегрируют в Систему управления конфигурацией. Определяя услуги как Элементы конфигурации и выстраивая их, если нужно, в иерархию, организация получает возможность связывать события, такие как инциденты или запросы на изменение, с услугами, которые эти события затрагивают. Это позволяет организовать мониторинг услуг и построение отчетов с использованием интегрированного инструмента (например, "выдать число инцидентов, связанных с данной конкретной услугой"). Поэтому существенно, что изменения Портфеля или Каталога услуг выполняются с применением процесса " Управление изменениями^{21англ. Change Management} ".

Каталог услуг используется в ряде других процессов ядра ITIL, в частности "Планирование непрерывности услуг" и "Управление мощностями".

Некоторые организации предпочитают иметь только Каталог бизнес-услуг или только Каталог технических услуг (см. рис. 12.3). Желательно тем не менее, чтобы существовали оба каталога и чтобы объединяющий их Каталог услуг входил частью в Портфель услуг. Комбинация каталогов очень полезна для быстрой оценки влияния инцидентов и изменений на бизнес.

Активности процесса, методы выполнения, технические приемы

Ключевые активности процесса:

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

Триггеры, входы, выходы и интерфейсы

Источниками информации для процесса служат:

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

Триггеры процесса^{22Так в ITIL v.3 называются события, запускающие процесс.} - это изменения бизнес-требований и услуг. Поэтому главные источники триггеров - это запросы на изменение и процесс "Управление изменениями". Изменения могут заключаться в появлении новых услуг, модификации существующих услуг, удалении услуг.

Выходами процесса являются:

• документация и соглашение об "определении услуги";
• обновления Портфеля услуг: все услуги должны иметь текущий статус и связанные с ними требования;
• Каталог услуг, содержащий для каждой действующей и вводимой в эксплуатацию услуги детальное описание и текущий статус, а также ее интерфейсы и зависимости.

Управление информацией

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

Ключевые показатели эффективности процесса

Два основных показателя эффективности процесса:

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

Примеры других возможных показателей:

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

Проблемы, критические факторы успеха и риски

Основная проблема с процессом "Управление Каталогом услуг" - это необходимость поддержания точного Каталога услуг как составляющей Портфеля услуг, входящего в Систему управления конфигурациями CMS^{23от англ. Configuration Management System} и Систему управления знаниями об услугах SKSM^{24от англ. Service Knowledge Management System} . Наилучший метод решения проблемы состоит в том, чтобы начать с разработки автономных баз данных или электронных таблиц, содержащих данные из Каталога бизнес-услуг и Каталога технических услуг, а затем включить их в CMS и SKMS. Тот факт, что Каталог услуг и Портфель услуг являются существенными источниками информации, которую персонал ИТ использует и сопровождает, должен стать частью корпоративной культуры.

Основные критические факторы успеха процесса "Управление Каталогом услуг" следующие:

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

Риски, связанные с созданием и поддержкой точного Каталога услуг, следующие:

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

Приведенное описание процесса, несмотря на некоторые повторы и местами излишнее многословие, хорошо структурировано и компактно. Это характерно для всех процессов, описанных в книге "Проектирование услуг".

В заключение я хотел бы вернуться к вопросу о том, что такое услуга в ITIL v.3. Теперь, после обсуждения назначения и структуры Каталога услуг, стал более понятен подход ITIL v.3 к определению услуги.

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

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

Вот несколько примеров услуг, использующих эти ресурсы.

Услуга по предоставлению доступа к приложениям с использованием единого пароля связана со стабильностью состава приложений.

Услуги корпоративной системы электронного документооборота обусловлены постоянством оргструктуры, ролей в оргструктуре и бизнес-процессах, стабильностью правил информационного обмена внутри предприятия.

Услуги по подготовке регламентного отчета, например, об отгрузках на определенную дату, услуги по предоставлению доступа к информации о складских остатках или по выполнению определенных бухгалтерских транзакций обусловлены стабильностью бизнес-процессов и основных бизнес-объектов.

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

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

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

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

Краткие итоги

В лекции кратко рассмотрено содержание второй книги ITIL v.3 - "Проектирование услуг" и подробно проанализированы структура Каталога услуг и процесс "Управление каталогом услуг". Делается вывод о Каталоге услуг как механизме, поддерживающем принятие решений, касающихся развития информационных ресурсов.

Вопросы

1. Какие процессы входят в Проектирование услуг?
2. Что такое Каталог услуг? Какова его структура?
3. В чем состоят назначение, цель и задача процесса "Управление Каталогом услуг?
4. Каковы входы, выходы и триггеры процесса "Управление Каталогом услуг"?
5. Каковы основные активности процесса "Управление Каталогом услуг"?