Бережливый сервис. Иногда меньше сервиса лучше для клиента

Андрей Иващенко

Книга отвечает на вопрос, как создавать лучший сервис и проектировать инновации в бизнесах сферы услуг, а также содержит много примеров из практики сервис-дизайна в сферах ритейла, здравоохранения, логистики, финансов и ресторанного бизнеса.Автор разбирает пошаговую методологию и необходимый инструментарий по созданию новых моделей услуг и поиску альтернативных конфигураций процессов обслуживания, призванных увеличивать рентабельность сервисного бизнеса и удовлетворенность клиентов.

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

Customer Journey Map не панацея

В сервисном дизайне мы часто используем инструменты Service Blueprint⁸ для описания сервисной модели и ее диагностики. Customer Journey Map⁹ или Employee Journey Map¹⁰ для визуализации опыта взаимодействия клиента с продуктом или компанией. Однако они имеют ряд недостатков для анализа и проектирования изменений на системном уровне.

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

Например, при заказе сэндвича с доставкой мы можем описать процедуру получения и приготовления заказа. Но если сотрудничаем со службой доставки, то анализ сервисных процессов на их стороне сильно затруднен. Курьер может заблудиться, нагрубить клиенту, но мы не узнаем причину такого поведения.

Во-вторых, эти инструменты не учитывают степень значимости действий, совершаемых клиентом. Насколько тот или иной шаг, который мы предлагаем ему для выполнения, способствует получению услуги и реализации функции продукта?

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

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

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

Введение в PCN-анализ

Согласно «объединенной теории сервиса», клиент своим участием может кардинально изменить процесс оказания услуги, даже если первоначально мы спланировали его наилучшим образом: разработали процессные карты, обучили персонал, создали автоматизацию процессов продаж на сайте. Клиент очень сильно влияет на то, как услуга может быть оказана в итоге, насколько стабилен будет результат от раза к разу. Для того чтобы сделать процесс оказания услуги устойчивым, мы должны иметь какие-то инструменты визуализации и проектирования производственного процесса.

Инструмент, который мы собираемся использовать для проектирования сервисов и поиска возможных идей для новых моделей услуг, называется PCN-анализ¹¹. Основной автор и методолог его применения для проектирования инноваций в сервисных моделях — доктор Скотт Сэмпсон, профессор университета Бригама Янга (США), с которым мне довелось состоять в переписке и глубоко разобраться в нюансах работы этого инструмента.

Практическая цель работы с PCN-анализом — поиск возможностей для улучшения процессов обслуживания путем:

— документирования процессов;

— оценки ценности действий, которые совершает клиент и организация;

— выявления проблемных областей в процессах взаимодействия;

— создания альтернатив в структуре процесса предоставления услуги.

PCN-анализ начинается с документирования процесса того, как услуга оказывается в настоящий момент:

— что является источником ценности для клиента, то есть за что он платит деньги;

— затраты, которые несет клиент (включая финансовые, эмоциональные, временные и т. д.);

— затраты сервисной организации (труд сотрудников, финансы и другие ресурсы);

— потенциальный доход компании, где она теряет и где может зарабатывать больше;

— риски возможного сбоя процесса обслуживания, включая выявление потенциальных причин сбоя;

— потенциальные возможности для поиска альтернативных конфигураций процесса.

PCN-анализ оценивает текущую конфигурацию процессов и определяет способы для ее улучшения или построения совершенно новой структуры процессов, более прибыльной или ценной для клиента.

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

_{Иллюстрация 3: Пример ценностного предложения ресторана SUBWAY на PCN-диаграмме}

Напомню, что сервис — это процесс совместного производства, результатом которого является создание продукта — оказанная услуга. Совместное производство означает, что у нас есть взаимодействие, как правило между поставщиком услуг и потребителем.

Так, когда идем в больницу, то взаимодействуем с персоналом, оборудованием, для того чтобы поправить здоровье. Когда отправляемся в ресторан, у нас есть посетитель, гости ресторана, официант, повар, и мы работаем вместе, чтобы накормить себя. Мы сотрудничаем в производстве, чтобы получить результат, который устроит нас всех.

Пример, который хочу использовать дальше для обзора этого инструмента, из ресторанного бизнеса: это процесс приготовления сэндвичей SUBWAY. Давайте рассмотрим работу ресторана SUBWAY. Для описания сервисной модели и процесса приготовления нам нужно визуализировать все шаги клиента и действия ресторана.

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

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

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

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

Например:

— разогрев сэндвича;

— сборка ингредиентов;

— разработка рецептуры;

— заказ ингредиентов.

Вы можете заметить, что некоторые шаги совершаются совместно с клиентом, а какие-то автономно.

_{Иллюстрация 4: Доменная зона процессов сервисной сущности}

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

Для простоты понимания: сервисная сущность — это самостоятельный участник, вовлеченный в процессы оказания услуги. Это может быть клиент, ресторан, служба доставки, санитарная инспекция, поставщик продуктов и т. д.

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

Именно поэтому мы не можем выделить официанта, повара или менеджера в разные сущности, они, как правило, работают под единым доменом, поскольку не обладают самостоятельностью. А вот клиента мы должны отделить, поскольку он действует единолично.

Когда мы изучаем различные способы классификации сервисных процессов, становится понятно, что контакты между сервисной фирмой и клиентом могут быть трех основных видов:

— прямой контакт человека с человеком;

— косвенный контакт человека с технологией или ресурсами другого;

— отсутствие контакта, то есть выполнение процессов автономно, без влияния другой сервисной сущности.

Поэтому мы используем для разделения вертикальные линии в зоне домена.

Далее увидим, что это за линии, и поймем значимость их использования для понимания процессов, которые происходят в нашей сервисной организации.

Типология сервисных процессов

Если посмотреть на наш ресторан и все процессы, которые происходят в нем, то их можно объединить в большое поле взаимодействий, где каким-то образом распределены все процессы.

По краям данного примера мы можем видеть зоны прямого взаимодействия: с правой стороны — с потребителями, которые делают заказ, и с левой стороны — с поставщиком при оформлении контракта.

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

В косвенной зоне мы как организация взаимодействуем с ресурсами клиента, которые были нам переданы, возможно, с информацией от человека, когда собираем сэндвич, возможно, с объектами, принадлежащими клиенту. Например, при ремонте автомобиля в автосервисе.

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

В центре независимой зоны мы работаем независимо от кого-либо: поставщиков, потребителя. Это наши внутренние операции. Обычно такие процессы изучает операционный менеджмент, и они относятся к традиционным внутренним процессам, происходящим в организации. Сейчас мы их рассматривать не будем.

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

_{Иллюстрация 5: Сервисное взаимодействие на PCN-диаграмме}

Мы видим в доменной области клиента процессы, которые также можно разместить в трех зонах:

— прямое взаимодействие с рестораном при выборе размера и сборе сэндвича, оплате и получении заказа;

— процессы в косвенной зоне при изучении меню и употреблении сэндвича;

— процессы в зоне независимого производства при осознании голода и поездки из ресторана.

Таким образом, у нас есть процессы, выполняемые участниками независимо друг от друга, и процессы, выполняемые клиентом и сервисной организацией совместно с разной степенью вовлеченности, эти вторые мы и называем сервисом.

Давайте подведем итог типологии процессов любой услуги. Их все можно разделить на три типа:

— независимое производство, где происходят процессы над собственными ресурсами, которыми владеет и которые контролирует сервисная сущность;

— зона косвенного взаимодействия, если объект процесса воздействует на ресурсы другого объекта процесса без прямого контакта;

— зона прямого взаимодействия человека непосредственно с человеком.

Что влияет на качество оказания услуги?

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

Это может быть:

— сотрудник, указывающий посетителю, куда сесть или на что посмотреть;

— цифровое табло с номером заказа, показывающее клиенту, сколько времени ему нужно находиться в ожидании;

— клиент, который в нашем случае говорит сборщику сэндвича, какую начинку ему положить.

Для описания степени контроля над процессами, выполняемыми участниками сервиса, предлагаю рассмотреть еще один элемент PCN-диаграммы.

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

Конец ознакомительного фрагмента.

Примечания

8

Service Blueprint — карта сервиса, описывающая модель работы сервисного процесса. Lynn Shostack. Harvard Business Review, 1984.

9

Customer Journey Map — фреймворк для визуализации и анализа опыта пользователей при взаимодействии с продуктом или сервисом.

10

¹⁴ Employee Journey Map — фреймворк для визуализации опыта сотрудников в процессе взаимодействия с внутренними продуктами компании или при выполнении процессов во время оказания услуги.

11

Dr. Scott Sampson. Essentials of Service Design and Innovation», 2019.