Если вы аналитик-внедренец ITSM-решений, то точно знаете, какой гигантский клубок информации приходится разматывать в каждом клиентском проекте. Разобраться в процессах, собрать требования, заполнить десятки документов и согласовать их… На любом из этих этапов легко попасть в ловушку данных. Спасает итеративный подход и… опыт.
На этапе проектирования в ИТ-системе клиентского каталога услуг, задач не меньше. В этой статье хотим рассказать, как мы попробовали разные подходы к созданию сервисных каталогов, почему отказались от многостраничных документов и таблиц, а также как организован процесс сейчас.
Эволюция подхода к созданию сервисного каталога
В клиентских проектах мы пробовали разные подходы к составлению сервисных каталогов.
Таблицы в Word. Еще несколько лет назад по каскадной модели разработки (Waterfall) скрупулезно собирали информацию в текстовые файлы. В этих документах фиксировали всё — от наименования услуг, основных ответственных до видов деятельности по определенной услуге и SLA.
Пример табличного описания услуги «Электронная почта» в формате текстового документа
Процедура такой «описи» нетривиальна и отчасти бесполезна. Пока поочередно перебираешь услуги и добираешься до последней, первая уже теряет актуальность: исполнитель изменился, сроки пересогласованы, набор возможностей пересмотрен. Всю работу можно делать заново.
К концу аудита услуг заполненные таблицы могли исчисляться десятками
Мало того, что информация корректируется на ходу, так и сам набор параметров с каждым обновлением таблицы пухнет и пухнет. Ведь по услуге недостаточно знать SLA и ответственность. Лучше помнить всех получателей поименно, а также выяснить, какие ресурсы инфраструктуры услуга предоставляет и от каких ресурсов зависит.
В то же время в любой компании процессы не статичны. Появляются новые сервисы, развиваются существующие. Услуги обрастают огромным слоем объектов: запросами, справочниками, связями, параметрами, КЕ.
Сколько бы ни длилась разработка документа, конца и края не видать. Документ сложно согласовать, да и его пригодность сомнительна. Это как с ремонтом, который нельзя закончить, а можно только приостановить. Так и в наших прошлых проектах работа с многостраничными «свитками» обычно заканчивалась фразой: «Довольно! Пора перебираться в систему».
Таблицы в Excel. Взамен многостраничных документов в нашу практику ворвались другие таблицы. Описательную часть для клиента мы по-прежнему оставляли текстом. А к нему прикладывали таблицу со списком услуг и их параметрами. Сложить нужную информацию в один документ опять не получалось. По факту каталог услуг вырастал в сеть взаимосвязанных таблиц.
Сопровождать в Excel множество вкладок и столбцов вручную неудобно. На эту работу аналитик внедрения тратил сотни часов
Такой способ составления списка услуг нами рассматривался как почва для первичного импорта в систему автоматизации. Далее развитие и оптимизацию планировали вести уже в ИТ-системе. Но и этот подход оказался не без минусов.
Как показывает наш проектный опыт, подготовка каталогов в виде статичных документов – экономически не оправданная задача. Трудозатраты огромны, выхлоп нулевой. Кроме как для подписания документа и закрытия актов он больше не понадобится. Если внедрен удобный инструмент автоматизации, никто эти таблицы-портянки не пересматривает.
Другое дело – динамический каталог, который изначально проектируется со своей структурой и ценностью в инструменте автоматизации. Подобный каталог начинает функционировать только с появления в нем первой услуги. Нельзя на этапе внедрения разработать каталог услуг под ключ. За этот период удается запустить процесс по его наполнению и актуализации. А значит оптимальный подход – собрать минимум информации и сразу идти в ИТ-систему.
В чем ценность каталога услуг
Пользу грамотно спроектированного сервисного каталога почувствуют все участники процесса.
Получатель услуг быстро в пару кликов сможет сформировать обращение и не запутается, где и что выбрать.
Интерфейс Портала самообслуживания с удобной группировкой услуг. Реализован на базе платформы Naumen SMP
Практикам процессов по услугам не нужен каталог как таковой. Заданная структура помогает упростить процесс классификации заявок и их последующую обработку. Становятся понятны сроки, шаги выполнения, затронутые услуги, заинтересованные лица в согласовании и эскалации.
Менеджерам процессов срез данных по портфелю предоставляемых услуг необходим для управленческих решений: аудит объема обращений, информации о достижении договоренностей и соблюдении процессных процедур.
Владельцам и Заказчикам интересны параметры качества и финансов.
Какие шаги помогут создать каталог услуг в ИТ-системе
В основу разработки понятного каталога услуг лучше положить итеративный подход и двигаться по шагам.
Шаг 1. Определение цели
Главный вопрос в любой деятельности – «зачем?». Для себя цели сервисного каталога сформулировали так:
- Организовать продуктивное взаимодействие с получателями услуг.
- Использовать единую платформу для построения ITSM-процессов и применения сервисного подхода во всех подразделениях компании.
- Заложить основу для управления и развития всех бизнес-процессов.
Шаг 2. Проведение обследования
Нередко клиенты говорят: «Каталог услуг у нас готов. Но его не покажем, чтобы не сбивать подходом по наитию. Предложите нам правильный каталог с нуля».
В наше время «с нуля» – это как вернуться в каменный век или попробовать заново изобрести велосипед. Не стоит отказываться от наработок. Берем все, что есть, и упаковываем в ИТ-систему.
Если каталог услуг в компании не формализован, анализируем такие артефакты:
- журнал обращений;
- (если используются) классификаторы и справочники для заявок;
- список информационных систем и оборудования;
- оргструктуру;
- сервисные контракты с внешними поставщиками.
Далее алгоритм следующий:
- Выделяем популярные вопросы к сервисным службам.
- Формируем набор услуг на понятном пользователю языке.
- Группируем и «приземляем» обращения на управляемые ресурсы.
- Предлагаем наименование услуги, которое увидит пользователь в ИТ-системе при подаче обращения.
Пример корреляции: Обращение пользователя-Оборудование-Услуга в ИТ-системе
Изначально в каталоге стоит предусмотреть услугу «Прочее»/«Заявка в свободной форме». Негласно ее называют «Канал подачи мусора». При периодическом анализе подобных обращений можно определить:
- неудачно сформулированные наименования услуг. Например, конкретная услуга присутствует в каталоге, но пользователи ее не находят и выбирают универсальную;
- потребность в обучении персонала. Например, пользователи конкретного отдела систематически указывают услугу «Прочее», в то время как большинство подразделений выбирают корректные классификаторы;
- тенденции и потребности в развитии сферы услуг. Например, поступает большой объем повторяющихся обращений на услуги, которые не предоставляются сервисной организацией.
Шаг 3. Распределение ответственности
Когда стартовый набор услуг готов, необходимо установить и зафиксировать исполнителей.
Важно определить уровни ответственности:
- Исполнитель обращений.
- Менеджер услуги.
- Менеджер каталога.
Исполнителя найти проще. Для этого в опоре на статистику журнала обращений сопоставляем должностные инструкции с функциональными обязанностями и компетенциями.
Менеджером услуги будет тот, к кому в первую очередь приходят Заказчики, если услуга не функционирует либо ее качество не устраивает потребителей. Скорее всего, это руководитель исполнителя либо вышестоящий по ветке оргструктуры сотрудник.
Выбор ответственного за весь каталог – задача посложнее. Как показывает практика, чаще такими менеджерами назначаются:
- Руководитель проекта внедрения ПО. Видит картину в целом и может принимать управляющие централизованные решения.
- Руководитель сервисной организации (ИТ-департамента). Наиболее заинтересован в развитии взаимоотношений заказчиков и исполнителей, владеет знаниями стратегии сервисной организации и знает, как они коррелируют со стратегией основного бизнеса.
- Группа компетенций. Ответственность закрепляется не за конкретным специалистом, а формируется на основе знаний участников проекта внедрения: РП, главных консультантов, сотрудников, которые способны передавать знания другим участникам.
Шаг 4. Подготовка каталога
Когда первичная версия каталога собрана, можно приступать к более глубокой проработке.
Здесь сразу делимся нашими наработкам: какие параметры на практике оказались наиболее востребованными и зачем они нужны.
Готовый перечень параметров услуги. Скачать полную версию
Результатом формирования каталога услуг в ИТ-системе становится качественный классификатор, при этом еще обновляемый и управляемый.
Шаг 5. Развитие каталога
Важный этап развития каталога услуг – настройка связи с ресурсно-сервисной моделью (РСМ). Ее проектирование и поддержка может поглощать бесконечные трудоресурсы. Но пользы от нее гораздо больше.
Ценность этой связи покажем на простом примере. В компании не работает интернет. Инцидент зарегистрирован. Именно РСМ поможет быстрее узнать, в чем источник проблемы (по связям с поддерживающим оборудованием) и какие зависящие от этого узла сервисы будут отваливаться дальше.
Финальный аккорд – расписать взаимозависимости между услугами, добавить перечень КЕ и завести в ИТ-систему процесс управления конфигурациями. И главное – жить по процессу, чтобы все это нежно собранное не расплескать!
Пример части каталога услуг, который одновременно служит классификатором КЕ
Когда каталог услуг сформирован, КЕ загружены и связи прописаны, останется провести интеграцию с системой бухгалтерского учета. Рассчитать себестоимость услуг, стоимость их поддержки. Но это уже другая история…