Глава 3. Сервис глазами бизнеса и клиента

В сервисном дизайне мы часто используем инструменты Service Blueprint для описания сервисной модели и ее диагностики. Customer Journey Map или Employee Journey Map для визуализации опыта взаимодействия клиента с продуктом или компанией. Однако они имеют ряд недостатков для анализа и проектирования изменений на системном уровне.
Во-первых, они не позволяют учесть работу и взаимодействие всех сервис-провайдеров, участвующих в сложносоставных процессах, таких как государственные услуги. Об этом важном аспекте мы будем говорить в главе по работе со сложными сервисами. Соответственно, мы не можем системно описать процессы, которые происходят за пределами нашей компании с помощью этих инструментов и учесть все проблемы опыта клиента.
Например, при заказе сэндвича с доставкой мы можем описать процедуру получения и приготовления заказа. Но если сотрудничаем со службой доставки, то анализ сервисных процессов на их стороне сильно затруднен. Курьер может заблудиться, нагрубить клиенту, но мы не узнаем причину такого поведения.
Во-вторых, эти инструменты не учитывают степень значимости действий, совершаемых клиентом. Насколько тот или иной шаг, который мы предлагаем ему для выполнения, способствует получению услуги и реализации функции продукта?

В-третьих, эти инструменты не включают в себя разделение процессов по зонам взаимодействия, имеющим разную степень контроля, что исключает возможность анализировать причину проблем и подбирать оптимальную конфигурацию процессов, чтобы их устранить.
В Customer Journey Map и Service Blueprint вообще не заложен алгоритм поиска таких комбинаций. Это также одна из причин, почему после проектирования Customer Journey Map проектные команды не знают, как ее применить в дальнейшем, и ограничиваются лишь генерацией идей на уровне прямой боли клиента, не учитывая значимость проблемы, характер взаимосвязей всех участников сервисного производства и влияние решений на всю сервисную экосистему.
Для решения задачи, которое устраняет перечисленные недостатки, мы используем методику аудита сервисных процессов. Его результат — документирование сервисной модели для последующего анализа и изменений с помощью мощнейшего инструмента сервис-дизайна — PCN-диаграммы, работе с которой будет посвящена отдельная глава этой книги.

Согласно «объединенной теории сервиса», клиент своим участием может кардинально изменить процесс оказания услуги, даже если первоначально мы спланировали его наилучшим образом: разработали процессные карты, обучили персонал, создали автоматизацию процессов продаж на сайте. Клиент очень сильно влияет на то, как услуга может быть оказана в итоге, насколько стабилен будет результат от раза к разу. Для того чтобы сделать процесс оказания услуги устойчивым, мы должны иметь какие-то инструменты визуализации и проектирования производственного процесса.
Инструмент, который мы собираемся использовать для проектирования сервисов и поиска возможных идей для новых моделей услуг, называется PCN-анализ. Основной автор и методолог его применения для проектирования инноваций в сервисных моделях — доктор Скотт Сэмпсон, профессор университета Бригама Янга (США), с которым мне довелось состоять в переписке и глубоко разобраться в нюансах работы этого инструмента.
Практическая цель работы с PCN-анализом — поиск возможностей для улучшения процессов обслуживания путем:
— документирования процессов;
— оценки ценности действий, которые совершает клиент и организация;
— выявления проблемных областей в процессах взаимодействия;
— создания альтернатив в структуре процесса предоставления услуги.
PCN-анализ начинается с документирования процесса того, как услуга оказывается в настоящий момент:
— что является источником ценности для клиента, то есть за что он платит деньги;
— затраты, которые несет клиент (включая финансовые, эмоциональные, временные и т. д.);
— затраты сервисной организации (труд сотрудников, финансы и другие ресурсы);
— потенциальный доход компании, где она теряет и где может зарабатывать больше;
— риски возможного сбоя процесса обслуживания, включая выявление потенциальных причин сбоя;
— потенциальные возможности для поиска альтернативных конфигураций процесса.
PCN-анализ оценивает текущую конфигурацию процессов и определяет способы для ее улучшения или построения совершенно новой структуры процессов, более прибыльной или ценной для клиента.
Подробности того, как проводить аудит сервисных процессов и визуализировать сервисную модель для последующего анализа, рассмотрим в следующей главе. Здесь же поговорим о визуализации и анализе сервисной модели с помощью PCN-диаграммы, результат построения которой позволяет правильно интерпретировать сложности в текущей модели, чтобы начать процесс улучшений.

Напомню, что сервис — это процесс совместного производства, результатом которого является создание продукта — оказанная услуга. Совместное производство означает, что у нас есть взаимодействие, как правило между поставщиком услуг и потребителем.
Так, когда идем в больницу, то взаимодействуем с персоналом, оборудованием, для того чтобы поправить здоровье. Когда отправляемся в ресторан, у нас есть посетитель, гости ресторана, официант, повар, и мы работаем вместе, чтобы накормить себя. Мы сотрудничаем в производстве, чтобы получить результат, который устроит нас всех.
Пример, который хочу использовать дальше для обзора этого инструмента, из ресторанного бизнеса: это процесс приготовления сэндвичей SUBWAY. Давайте рассмотрим работу ресторана SUBWAY. Для описания сервисной модели и процесса приготовления нам нужно визуализировать все шаги клиента и действия ресторана.
Ответим на вопрос: «Откуда мы получаем сэндвич?» Вероятно, со сборочной линии. А как он попадает на нее? Скорее всего, после того как клиент выразил желание сделать заказ, а сотрудник начал сборку ингредиентов. Как клиент решает, что ему заказать? Сэндвичная разрабатывает меню и собирает рецептуру, по которой работники будут изготавливать его на кухне. Чтобы разработать рецептуру, ресторану надо понимать, какие ингредиенты есть на рынке и у поставщика. Заказать их у поставщика, доставить и складировать. Чтобы их заказать, нужно заключить договор на поставку и потом взаимодействовать с поставщиком для формирования заказа.
Таким образом, мы имеем некоторую систему процессов подготовки и приготовления. Визуализация всегда помогает нам увидеть шаги, приводящие к изменению привносимых ресурсов клиента, участвующих в сервисном производстве.
Процесс создания продукта или услуги — это всегда последовательность шагов, цель которых — изменение первоначального состояния входных ресурсов клиента. Трансформация их первоначального состояния, приводящая к их улучшению. На производстве — это материал, заготовки и полуфабрикаты, в сервисе — это клиенты и их ресурсы в виде: предметов собственности, информации или физического тела. Для формализации и анализа процесса приготовления сэндвича мы будем использовать простую блок-схему из прямоугольников и стрелок.
Поскольку сервис по созданию сэндвича — это обработка и улучшение качества входящих ресурсов клиента, то для описания процессов в каждом действии шага должно быть включено название самого ресурса, над которым происходит изменение.
Например:
— разогрев сэндвича;
— сборка ингредиентов;
— разработка рецептуры;
— заказ ингредиентов.

Вы можете заметить, что некоторые шаги совершаются совместно с клиентом, а какие-то автономно.
Чтобы понять, где и как происходят процессы приготовления сэндвича, нам нужен какой-то шаблон, чтобы визуально разделить их. Я хочу ввести понятие «сервисная сущность» в эту блок-схему, в которой происходят все эти процессы.
Для простоты понимания: сервисная сущность — это самостоятельный участник, вовлеченный в процессы оказания услуги. Это может быть клиент, ресторан, служба доставки, санитарная инспекция, поставщик продуктов и т. д.
У всех этих сущностей есть область, где происходят какие-то процессы. Давайте назовем ее «доменом процессов», которые управляются и контролируются конкретной сервисной сущностью в границах своей области. Важный принцип идентификации «сервисной сущности» — ее самостоятельность в принятии решений о действиях, которые она может совершать.

Именно поэтому мы не можем выделить официанта, повара или менеджера в разные сущности, они, как правило, работают под единым доменом, поскольку не обладают самостоятельностью. А вот клиента мы должны отделить, поскольку он действует единолично.
Когда мы изучаем различные способы классификации сервисных процессов, становится понятно, что контакты между сервисной фирмой и клиентом могут быть трех основных видов:
— прямой контакт человека с человеком;
— косвенный контакт человека с технологией или ресурсами другого;
— отсутствие контакта, то есть выполнение процессов автономно, без влияния другой сервисной сущности.
Поэтому мы используем для разделения вертикальные линии в зоне домена.
Далее увидим, что это за линии, и поймем значимость их использования для понимания процессов, которые происходят в нашей сервисной организации.