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