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

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

Эволюция подхода к созданию сервисного каталога


В клиентских проектах мы пробовали разные подходы к составлению сервисных каталогов.

Таблицы в Word. Еще несколько лет назад по каскадной модели разработки (Waterfall) скрупулезно собирали информацию в текстовые файлы. В этих документах фиксировали всё — от наименования услуг, основных ответственных до видов деятельности по определенной услуге и SLA.

image

Пример табличного описания услуги «Электронная почта» в формате текстового документа

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



К концу аудита услуг заполненные таблицы могли исчисляться десятками


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

В то же время в любой компании процессы не статичны. Появляются новые сервисы, развиваются существующие. Услуги обрастают огромным слоем объектов: запросами, справочниками, связями, параметрами, КЕ.

Сколько бы ни длилась разработка документа, конца и края не видать. Документ сложно согласовать, да и его пригодность сомнительна. Это как с ремонтом, который нельзя закончить, а можно только приостановить. Так и в наших прошлых проектах работа с многостраничными «свитками» обычно заканчивалась фразой: «Довольно! Пора перебираться в систему».

Таблицы в Excel. Взамен многостраничных документов в нашу практику ворвались другие таблицы. Описательную часть для клиента мы по-прежнему оставляли текстом. А к нему прикладывали таблицу со списком услуг и их параметрами. Сложить нужную информацию в один документ опять не получалось. По факту каталог услуг вырастал в сеть взаимосвязанных таблиц.



Сопровождать в Excel множество вкладок и столбцов вручную неудобно. На эту работу аналитик внедрения тратил сотни часов


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

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

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

В чем ценность каталога услуг



Пользу грамотно спроектированного сервисного каталога почувствуют все участники процесса.

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



Интерфейс Портала самообслуживания с удобной группировкой услуг. Реализован на базе платформы Naumen SMP

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

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

Владельцам и Заказчикам интересны параметры качества и финансов.

Какие шаги помогут создать каталог услуг в ИТ-системе


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

Шаг 1. Определение цели


Главный вопрос в любой деятельности – «зачем?». Для себя цели сервисного каталога сформулировали так:

  1. Организовать продуктивное взаимодействие с получателями услуг.
  2. Использовать единую платформу для построения ITSM-процессов и применения сервисного подхода во всех подразделениях компании.
  3. Заложить основу для управления и развития всех бизнес-процессов.

Шаг 2. Проведение обследования


Нередко клиенты говорят: «Каталог услуг у нас готов. Но его не покажем, чтобы не сбивать подходом по наитию. Предложите нам правильный каталог с нуля».

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

Если каталог услуг в компании не формализован, анализируем такие артефакты:

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

Далее алгоритм следующий:

  1. Выделяем популярные вопросы к сервисным службам.
  2. Формируем набор услуг на понятном пользователю языке.
  3. Группируем и «приземляем» обращения на управляемые ресурсы.
  4. Предлагаем наименование услуги, которое увидит пользователь в ИТ-системе при подаче обращения.



Пример корреляции: Обращение пользователя-Оборудование-Услуга в ИТ-системе


Изначально в каталоге стоит предусмотреть услугу «Прочее»/«Заявка в свободной форме». Негласно ее называют «Канал подачи мусора». При периодическом анализе подобных обращений можно определить:

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

Шаг 3. Распределение ответственности


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

Важно определить уровни ответственности:

  • Исполнитель обращений.
  • Менеджер услуги.
  • Менеджер каталога.

Исполнителя найти проще. Для этого в опоре на статистику журнала обращений сопоставляем должностные инструкции с функциональными обязанностями и компетенциями.

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

Выбор ответственного за весь каталог – задача посложнее. Как показывает практика, чаще такими менеджерами назначаются:

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

Шаг 4. Подготовка каталога


Когда первичная версия каталога собрана, можно приступать к более глубокой проработке.

Здесь сразу делимся нашими наработкам: какие параметры на практике оказались наиболее востребованными и зачем они нужны.



Готовый перечень параметров услуги. Скачать полную версию

Результатом формирования каталога услуг в ИТ-системе становится качественный классификатор, при этом еще обновляемый и управляемый.

Шаг 5. Развитие каталога


Важный этап развития каталога услуг – настройка связи с ресурсно-сервисной моделью (РСМ). Ее проектирование и поддержка может поглощать бесконечные трудоресурсы. Но пользы от нее гораздо больше.

Ценность этой связи покажем на простом примере. В компании не работает интернет. Инцидент зарегистрирован. Именно РСМ поможет быстрее узнать, в чем источник проблемы (по связям с поддерживающим оборудованием) и какие зависящие от этого узла сервисы будут отваливаться дальше.

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



Пример части каталога услуг, который одновременно служит классификатором КЕ


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