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

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

Во-первых, при обдумывании каталога следует постоянно держать в голове правильную структуру объектов управления, связанных с услугами, как таковыми.  То есть нам надо,  например,  различать услуги и уровни их предоставления, типовые запросы, стандартные операции и изменения. Как правило, практический опыт осмысливается нами «вертикально», как сквозной кейс. Этот поток сознания нужно и важно правильно структурировать. В результате услуга приобретает набор связанных сущностей, которые обеспечивают ее (услуги) использование в контексте различных процессов управления. О составе этого набора объектов можно подумать заранее, ведь существующие процессы нам известны.

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

Третье обстоятельство – прозрачность использования технологических и архитектурных решений в дизайне услуги. Я утверждаю, что решения эти потребителям чаще всего не интересны – утверждаю хотя бы на основе своего персонального потребительского опыта. На практике мы говорили о том, почему сервис печати, например, не относится к сетевым сервисам. Для потребителя может быть важно, где (как далеко от него) установлен принтер, на который он может отправить задание на печать. Но то, что для работы принтера используется сеть, потребителю само по себе не принципиально. Эта конкретная реализация (в данном случае) не влияет на конечные характеристики услуги.

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

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