ГлавнаяСтатьиЭффективный Каталог услуг

Эффективный Каталог услуг

Введение

Организации, внедряющие у себя концепцию ITSM (IT Service Management), являющейся одной из основных идей, описанных в библиотеке ITIL, обязательно сталкиваются с проблемой её применения на практике. Как получить конкретный результат для себя, с чего начать? Одной из этих проблем становится создание и внедрение Каталога ИТ-услуг. Очевидно, что применение концепции ITSM, невозможно без формализации описания самих услуг. То есть, если мы хотим разговаривать с Заказчиком в терминах предоставляемых услуг, то их состав и содержание необходимо где-то описать. Решением, предложенным для этого в ITIL, является формирование документа - Каталога услуг.

Преимущества от наличия утверждённого Каталога услуг следующие:

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

Обобщая всё вышесказанное, Каталог услуг ИТ можно сравнить с меню в ресторане. Если меню нет и клиент, придя в такой ресторан, объясняет официанту свои пожелания к обеду, то он а) долго ждёт свой обед; б) не факт, что вообще получит желаемое, в) много платит. Если же меню есть, то потребитель всегда знает, что он может получить, а производитель знает как планировать свои ресурсы, чтобы удовлетворить возможные запросы потребителей. Производитель заранее ограничивает запросы потребителя и очевидно это значительно снижает затраты на производство. Ну так если это уже десятки, а то и сотни лет работает в ресторанном бизнесе, почему такого "меню" зачастую нет в ИТ? Скорее всего потому что ресторанный бизнес изначально был сервисно-ориентированным, а ИТ начинает становиться таким только сейчас. В этом и заключается концепция ITSM.

Кроме всего перечисленного, если в организации существует задача построения ресурсно-сервисной модели (РСМ), то информация Каталога услуг формирует её, дополняя при этом информацию CMDB. Таким образом, РСМ является результатом деятельности двух процессов - Управления Каталогом услуг и Управления конфигурациями. Кратко перечислим некоторые возможные преимущества от наличия актуальной РСМ:

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

В этой статье мы рассмотрим подход к формированию Каталога, который обеспечит его полезность и эффективность. По опыту, полученному на проектах, включающих разработку Каталога услуг, необходимо и достаточно выполнить следующие шаги:
1. Определить структуру Каталога услуг.
2. Создать список услуг.
3. Определить описание услуги (атрибуты).
4. Подготовить шаблон документа и направить руководителям отделов ИТ для заполнения.
5. Разработать регламент поддержки Каталога услуг.

 

Структура Каталога услуг

В соответствии с ITIL, Каталог услуг может разделяться на "Каталог бизнес-услуг" и "Каталог технических услуг" (Рис. 1). Это может быть один документ, включающий описание обоих типов услуг, а может быть два документа (например, если их поддерживают разные люди, то такое разделение целесообразно).


Рис. 1 - Каталоги бизнес-услуг и технических услуг

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

Рассмотрим это на примере коммерческого банка. Предположим, что в этом банке существуют каталоги бизнес- и технических услуг, процесс Управления инцидентами и учёт проводимых работ.


Рис. 2 - Схема Каталога услуг Банка X и связей

Здесь мы дополняем схему понятием "системы" (то что в ITIL называется "составной КЕ"). Система - это группирующий элемент для конфигурационных единиц. Позволяет перейти от бизнес-услуги к технической, а также классифицировать заявки пользователей и инциденты в терминах инфраструктуры. Каталог технических услуг в этом примере по сути дела является классификатором работ ИТ. В таких условиях работа с Каталогами бизнес- и операционных услуг может быть организована следующим образом:

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

Каковы же преимущества такой схемы использования Каталога услуг? Перечислим их:

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

 

Список услуг

Создание простого списка услуг на первоначальном этапе формирования Каталога полезно, потому что это даёт представление всем участникам, о чём вообще идёт речь. Здесь появляется уже первый видимый результат. Крайне желательно эту работу выполнять коллегиально, то есть организовать совещание руководителей подразделений службы ИТ и от каждого получить (сразу!) наименования конкретных услуг, которые это подразделение оказывает. Также здесь следует договориться вообще о том, что такое услуга в применении к реалиям организации и о принципе их формирования. Можно выделить следующие принципы формирования услуг:

  • по бизнес-процессам организации. Воспользуемся вышеописанным примером банка: "кредитование физических лиц", "депозиты юридических лиц", "карточные продукты", "электронная почта";
  • по поддерживаемым приложениям и аппаратным системам: "поддержка SAP R/3", "поддержка MS Exchange", "поддержка MS SharePoint Portal" (слова "поддержка" можно исключить);
  • по обслуживаемым подразделениям организации: "Департамент розничного кредитования", "Управление бухгалтерского учёта и отчётности", "Казначейство".


Рассмотрим преимущества и недостатки каждого из этих принципов.

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


Формирование услуг по поддерживаемым приложениям и аппаратным системам. Преимущества: легко сформировать сам перечень услуг; проще рассчитать стоимость услуги. Использование этого метода влечёт сложность соизмерения прибыли от товара/услуги для организации в целом с затратами на ИТ.


Формирование услуг по обслуживаемым подразделениям организации. Основным преимуществом является то, что указание Инициатора заявки автоматически определяет услугу. Это упрощает жизнь диспетчерам. Основным недостатком является сложность поддержки такой схемы: при изменении организационной структуры необходимо пересматривать Каталог услуг и модель расчёта их стоимости.

 

Описание услуг в Каталоге

Каталог услуг не имеет смысла сам по себе. То есть, если мы просто сформируем перечень услуг и укажем какую-то информацию, связанную с услугой без ясного представления как это будет использоваться, велика вероятность породить документ, который будет благополучно забыт в столе навсегда. В соответствии с концепцией ITSM и процессной моделью, описанной в ITIL Каталог услуг применяется в деятельности процессов управления ИТ. Например, Управление инцидентами (Incident Management), Управление изменениями (Change Management), Управление финансами ИТ (Financial Management) и т.д. Обеспечить эффективность Каталога услуг - значит указать в нём ту информацию, которая будет использоваться в рамках процессов Управления ИТ. И ничего лишнего. Однако после прочтения ITIL к составу этой информации появляются вопросы.

В книге Service Design, входящей в ITIL v3 Core есть приложение G, в котором приведён пример описания услуги в Каталоге. Это таблица, в которой для каждой услуги указываются следующие сведения:

  • описание услуги;
  • тип услуги;
  • поддерживающие услуги;
  • бизнес-владелец;
  • бизнес-подразделения (потребители);
  • менеджеры услуги;
  • бизнес-влияние;
  • бизнес-приоритет;
  • SLA (Service Level Agreement);
  • часы поддержки;
  • контактное лицо со стороны бизнеса;
  • контактное лицо в случае эскалации;
  • отчёты по услуге;
  • пересмотры услуги;
  • рейтинг безопасности.

В том же приложении, к сожалению, не приводятся этому каких-либо комментариев или разъяснений. Таким образом, разработчики ITIL оставляют право определения описания услуг самим менеджерам службы ИТ или консультантам, выполняющим проектирование Каталога услуг для своего Заказчика. Как уже говорилось выше, создание Каталога услуг не имеет смысла без внедрения остальных процессов ITIL (по крайней мере, если не ставится формальная задача - составить Каталог услуг). Поэтому рассмотрим описание услуг с точки зрения используемости этой информации в процессах управления ИТ. При этом учтём пример, приведённый в ITIL, книге Service Design, творчески его переосмыслив.

Таблица 2. Пример описания услуги.
Информация Комментарий и применение
Наименование Уникальное определение услуги. Используется в справочных целях и ссылках
Тип услуги Показывает принадлежность услуги к бизнес- или техническим. Имеет смысл, если формируется объединённый Каталог услуг
Краткое описание Краткая информация, описывающая суть услуги
Бизнес-владелец Как правило, менеджер бизнес-подразделения, являющегося основным Заказчиком услуги.

Информация используется в следующих процессах:
  • Управление изменениями — для включения данного сотрудника в состав CAB при утверждении изменений;
  • Управление уровнем услуг — для контакта при установлении/пересмотре требований Заказчика к услуге. Также может являться получателем отчётности по исполнению SLA;
  • Управление доступностью — для определения состава и принципа расчёта метрик услуги;
  • Управление непрерывностью ИТ-услуг — определяет требования к восстановлению услуги после аварии.
Бизнес-приоритет Важность услуги для основной деятельности организации.

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

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

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

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

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

 

Формирование состава атрибутов услуги лучше выполнять коллегиально, также как и формирование перечня услуг.

 

Шаблон документа и его заполнение

На этом этапе выполняется техническая работа по подготовке документа с формированием структуры на основании перечня услуг. После останется только заполнить атрибуты всех услуг. Это можно сделать также на общем совещании или в offline-режиме.

 

Регламент поддержки Каталога услуг

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

 

Заключение

Разумеется, всё, что указано выше, является примером и не претендует на полноту. Наверняка, специалисты, прошедшие внедрение процессов ITIL в своей организации или организации Заказчика смогут добавить несколько примеров описания услуг и их применения в рамках процессов Управления ИТ. Также, у каждого подразделения ИТ существует свой контекст процессов и задач, который обязательно должен быть учтён при проектировании Каталога услуг. Это значит, что структура документа и состав информации, содержащейся в нём, могут отличаться для каждой из конкретных служб ИТ.