Сегодня я бы хотел поделиться своим опытом по созданию каталогов услуг (Service catalog) в различных компаниях. Надеюсь, несколько моих «боевых» советов смогут помочь вам. В своей деятельности я опираюсь на ITSM и ITIL феймворки, которые заслуженно считаются лучшими практиками по предоставлению услуг. И хоть эти методики были разработаны с фокусом на IT сферу, они могут быть адаптированы для компаний из других индустрий.
Что же такое услуга и при чём тут ценность?
На первый взгляд, услуге сложно дать чёткое определение из-за разнообразия форм, в которых она существует на сегодняшний день. Я считают, что услуга есть, если возникает какая-то ценность для клиента при работе с нами. Клиент не обязан обладать каким-то ресурсом или нести (хотя, может) ответственность при работе с нами. Если при взаимодействии для него возникла ценность, например, вынесена на аустсорсинг часть производственной цепочки, было разработано программное обеспечение, перевезены грузы, добыты полезные ископаемые, значит, мы оказали услуги. При этом, если еще созданная ценность соответствует или превышает ожидания клиента – это вообще отлично.
Ценность услуги определяется двумя аспектами:
- Utility – функциональность услуги соответствует надобностями клиента (грузы перевозятся);
- Warranty – гарантии того, что услуга предоставляется в соответствии с качественными требованиями (грузы перевозятся вовремя и в нужном объеме).
Каталог и портфель услуг — одно и то же?
Каталог услуг – это централизованный список услуг, которые в данный момент доступны для клиентов (внешних и внутренних относительно вашей организации). Как и с отдельными услугами, при его составлении необходимо делать упор на ценность. Если вы не уверены, что какой-то услугой вы можете чем-то помочь клиентам и будет ли она вообще пользоваться спросом, подумайте, стоит ли ее включать в каталог и формировать по ней предложение. Возможно, нужно ее перепозиционировать или включить в состав другой услуги. При составлении каталога также стоит принять во внимание его будущее продвижение. Вот показательный кейс, который свидетельствует о важности маркетинговой составляющей.
Мы сотрудничали с небольшой консалтинговой компанией. Это был десяток лучших экспертов в области юриспруденции и права. Пара человек специализировались на хозяйственном праве и договорах между компаниями. Один – был лучший в регионе специалист по поддержке таможенной деятельности. Еще пара человек имели огромный опыт в трудовом праве. Другие занимались сделками по слияниям и поглощениям, оказывали поддержку стартапам. Когда компания сделала свой каталог услуг, он содержал несколько десятков предложений. Они были горды, что могут охватить весь спектр юридических консалтинговых услуг и надеялись быстро занять лидирующие позиции на рынке. Однако через несколько лет выяснилось, что осуществлять маркетинговую и предпродажную поддержку такого объемного сервисного каталога силами десятка экспертов просто невозможно. Клиенты терялись при первом контакте. Например, когда к ним обращался стартап, которому требовалась юридическая поддержка, рано или поздно компания уходил к конкурентам, которые специализируются на молодых фирмах. В результате, сервисный каталог был пересмотрен и сокращен в разы.
Процесс по поддержке жизненного цикла услуг называется Управлением портфелем услуг (Service Portfolio Management). А портфель услуг содержит не только актуальное сервисное предложение, но также выведенные из каталога услуг и разрабатываемые сервисы. Например, со временем некоторые услуги теряют актуальность, становятся слишком сложными для выполнения или зависимыми от сторонних процессов, на услуги может упасть спрос; значит, услуги надо актуализировать — периодически или в связи с какими-то событиями (например, выход новой версии используемого инструмента). Если на рынке или внутри компании все еще присутствует потребность в ключевых ценностях, которые несёт услуга, то не следует расслабляться и оставлять всё как есть, а постоянно работать над её актуализацией. Если по каким-то причинам (нет спроса, невыгодно и тд) услугу оказывать не имеет смысла, то надо отправить ее на «пенсию».
Услуга: мы видим её по-разному
Когда клиент заказывает перевозку грузов, для него этот процесс выглядит следующим образом: он через какую-то очень простую точку контакта (телефонный звонок, простая веб форма с тремя полями) оставляет заявку и ждёт исполнителей, которые в желаемое время по указанному адресу придут, заберут груз и доставят его в сохранности по нужному адресу вовремя. Это уровень «запросов пользователей» (user request level).
С точки бизнеса это выглядит по-другому. У предприятия есть некие ресурсы (автомобили, компьютеры, серверы, электричество), то, что в ИТ обычно называют компоненты и инфраструктура (Components и Infrastructure), а также рабочая сила (man power). Очевидно, это имеет некую стоимость. Применяя вышеперечисленные компоненты в нужной конфигурации, компания создаёт услугу, которая и приносит ценность клиенту, а компания получает добавленную стоимость.
Есть еще производственный уровень. С точки зрения бригадира грузчиков это выглядит так. У него есть в удобном месте подробное описание задачи: адреса, объем груза, вес груза, контакты клиента и получателя, информация о грузе (хрупкость, форма), наличие бригады грузчиков и автотранспорта. Есть еще операционный менеджер, которому важен процесс. Он следит за содержанием заявок от клиентов, прогнозирует их поступление, планирует и распределяет ресурсы (люди, компоненты, инфраструктура – это все должно быть в наличии и работоспособно). У него также есть понимание, какие компоненты и в какой конфигурации задействованы при предоставлении услуги, что позволяет быстро восстановить работоспособность в случае деградации или сбоя (инцидента).
А если мы это применим к разработке программного обеспечения? Похоже? Конечно да.
Возьмем услугу «Управление доступами (Access management)». С точки зрения клиента, он бы хотел обратиться в единую точку контакта с сервисным провайдером и увидеть Каталог услуг. Там он хотел бы быстро выбрать и заказать услугу по изменению уровня своего доступа (например, попросить доступ в канал какого-то корпоративного месенджера) или обозначить проблему (не может войти в систему). На бизнес уровне должно присутствовать понимание стоимости оказываемой услуги, задействованные компоненты, инфраструктура и люди. На уровне процесса должны быть написаны инструкции и регламенты для технического персонала по предоставлению доступа в каждую систему (внутренняя база знаний), выделены рабочие часы специалистов, разработаны формы для запросов пользователей (через формы запрашивается необходимая и достаточная информация для качественного оказания услуги).
Один наш клиент, крупный интернет провайдер, оказывал услугу подключения новых абонентов к сети по оптическому каналу. Они внедрили программного обеспечение Сервис деск (Service Desk) для структурирования и автоматизирования процесса активации абонентов. Однако, клиенты не пользовались формой на веб портале, а продолжали слать емейл заявки на подключение и звонить в кол центр. Заявки терялись, нагрузка на персонал не была сбалансированной, автоматизация не работала, а клиенты нервничали. После анализа поведения пользователей выяснилось следующее. Название запроса пользователей (User request title) было слишком сложно сформулировано, и часть клиентов не понимали его и не могли найти нужную услугу на веб портале. Сама форма запроса также была слишком сложна, требовала емейл подтверждения активации профиля пользователя, содержала слишком много маркетинговой информации; кроме того, пользователь много данных должен был вводить вручную (например, название тарифного плана). Соответственно, для потенциального клиента было проще написать короткий емейл или позвонить. В результате, форма заявки услуги была упрощена, была выполнена интеграция с системой CMDB, некоторые данные (тарифные планы) «подтягивались» автоматически, не было необходимости вводить их вручную, можно было просто выбрать из списка. Также было настроено автоматическое уведомление клиентов о ходе работы над заявкой.
Вывод
В качестве краткого обобщения хотел бы порекомендовать при создании Каталога услуг не забывать при базовый принцип фреймворка ITIL: делайте все максимально просто (как минимум для клиентов). А также не забывайте просматривать ваш каталог услуг на актуальность и соответствие миссии организации и вашей команды, считайте стоимость предоставления услуг, учитывайте задействованные компоненты и зависимости, и все максимально автоматизируйте.
