Люди знакомые с ITSM/ITIL знают о том, что, описывая любую услугу, мы можем выделить характеристики «полезности» (utility) и «гарантии» (warranty). Также нередко обсуждаются характеристики, описывающие опыт (experience: user experience, UX и customer experience, CX).
Как соотносятся эти понятия? Можем ли мы говорить о том, что experience — это ещё одна, третья группа характеристик? Что вообще даёт это понятие, и почему utility и warranty может быть недостаточно?
Коротко про сами понятия
[ITIL4 SLM, 2.2.1 (Практическое руководство ITIL 4 по управлению уровнем обслуживания)].
Полезность (utility) – функциональность, предлагаемая продуктом или услугой для удовлетворения конкретной потребности. Соответствие назначению («то, что услуга делает»).
Например, услуга обеспечивает формирование отчётов, или возможность проведения видеоконференции.
Гарантия (warranty) – гарантия того, что продукт или услуга будут соответствовать согласованным требованиям. Соответствие условиям предоставления («то, как услуга предоставляется»).
Например, скорость формирования отчётов, максимальное количество пользователей, которые могут участвовать в видеоконференции, доступность услуги и т.п.
Важно также то, что для обеспечения создания максимального уровня ценности комбинация требований в этих областях, предъявляемых различными заказчиками, может различаться. В ITIL v3 была вот такая картинка, иллюстрирующая мысль о том, что важны и функциональные требования, и нефункциональные.
Поскольку важно и то, и другое, несмотря на то, что при анализе, разделение на utility и warranty может помочь не забыть важные аспекты оценки услуги, в целом можно обойтись и без деления. Более того, в практике SLM [2.2.1] есть любопытная мысль:
Привычка разделять управление функциональными и нефункциональными характеристиками сервисов (от определения требований до оценки достигнутого качества) происходит от разделения команд разработки и эксплуатации.
А что с опытом (experience)? Здесь, помимо уже упомянутой публикации практики SLM, основным источником является книга DSV (ITIL 4 Drive stakeholder value, «Совместное создание ценности для заинтересованных сторон»), 1.2.4.
Опыт заказчика (customer experience, CX) – воспринимаемая заказчиком совокупность функционального и эмоционального взаимодействия с услугой и провайдером.
Опыт пользователя (user experience, UX) – воспринимаемая пользователем совокупность функционального и эмоционального взаимодействия с услугой и провайдером.
Эмоциональное взаимодействие
Если «функциональное» взаимодействие можно соотнести с описанными в первой части заметки характеристиками услуги, то как быть с эмоциональным? Конечно, на эмоции, появляющиеся у потребителя (пользователя или заказчика) в рамках сервисных отношений, влияет то, насколько услуга хороша с точки зрения utility и warranty. Но только ли они?
Авторы DSV предлагают рассматривать более широкий контекст. В том числе, не ограничиваясь анализом путешествия заказчика (customer journey).
Т.е. опыт, формирующийся у потребителя – это намного более сложная история, чем только характеристики услуги (в т.ч. utility и warranty). Она включает в себя и опыт взаимодействия с сервис-провайдером (в том числе, например, то насколько приятны и эффективны коммуникации), и восприятие бренда (т.е. я часть не столь объективная).
Ключевым отличием характеристик experience является то, что их можно оценить только по поведению потребителя. Это может быть:
- либо то, что потребитель делает в рамках потребления услуги (например, customer efforts – объём усилий, затрачиваемых на выполнение какой-либо операции или решение своей задачи; количество ошибок, допущенных пользователем; количество обращений за помощью; длительность пауз или количество незавершённых покупок в интернет-магазине и т.п.),
- либо то, что потребитель думает (например, CSAT – уровень удовлетворённости заказчика [регулярные опросы — например, в рамках service review, операционные опросы — «как вы оцениваете обработку данного обращения?» и т.п.], NPS и пр.)
- либо то, что потребитель решает/делает (например, прекращает сервисные отношения; меняет объём потребления; меняет характер/каналы потребления/взаимодействия и т.п.)
Обратная связь
Среди всех этих способов оценки того, как выглядит опыт потребителя, важным является получение обратной связи.
Остаётся вопрос о том, где проходит граница между utility/warranty и experience в той области, которая описывается более-менее объективными параметрами.
Мне кажется любопытным то, что, если мы будем использовать в качестве критерия необходимость использования обратной связи, граница не будет чёткой. Ведь мы можем прибегать к использованию обратной связи не только потому, что иначе «оцифровать» тот или иной аспект предоставления услуги невозможно. Но и потому, что это может быть нерационально. Или невозможно на текущем этапе нашего развития. Например, мы по какой-то причине не можем (или это нерационально) измерить те или иные параметры быстродействия (warranty). И, допустим, для данной части функциональности услуги быстродействие важно. Будет оно влиять на восприятие потребителя и формирование его опыта? – Безусловно да. Как мы об этом влиянии узнаем? – Видимо, по обратной связи.
Т.е. мы не оцениваем быстродействие (или любую другую характеристику) с помощью получения обратной связи (вместо какого-либо прямого и объективного измерения). Мы оцениваем опыт потребления. И далее, возможно, выйдем на то, что нужно задать более узкий вопрос (в данном примере — конкретно про быстродействие). А может быть дойдём до необходимости измерения этого самого быстродействия. В идеале мы должны выявить и оцифровать наиболее важные для заказчика характеристики (а также согласовать эту оцифрованную картину). Именно про это метод сервисных операций. О нём в библиотеке ITIL4 кратко упоминается и в небольшом документе из группы white papers — «Experience level agreements in ITIL 4» авторства Антонины Кленцовой. Но пока мы не идентифицировали требования потребителя (или не научились измерять степень их удовлетворения), информация об отклонении фактических значение таких характеристик от ожидаемых будет улавливаться нами только по оценке опыта потребителя.
Получается, что,
- Если мы не рассматриваем вырожденную ситуацию – «всё есть experience, и часть из того, что влияет на experience, мы идентифицируем как характеристики utility/warranty).
- Если experience — это не только про то, какие параметры мы пытаемся оценивать, но и то, как мы это делаем.
То одни и те же характеристики в одной ситуации могут быть отнесены к группе experience, в другой нет. Или я что-то путаю?
