Customer Journey-Based Process Design (Процессы от клиентского пути)

Процессы от клиентского пути (Customer Journey-Based Process Design) — подход к проектированию бизнес-процессов, при котором отправной точкой служит путь клиента — то, как клиент решает свою задачу от первого контакта до результата, — а не внутренняя функциональная структура компании. Сначала описывают путь и его слабые места глазами клиента, затем под каждый значимый этап проектируют или перестраивают поддерживающий процесс, ответственных и метрики. Причина: процессы, выросшие из организационной структуры, устроены удобно для функций, а клиент вынужден проходить по ним «швами» между подразделениями. Методику не создал один автор; у неё есть две опоры — практическая (статья консультантов McKinsey в Harvard Business Review, 2013, «The Truth About Customer Experience») и академическая (обзор Кэтрин Лемон и Питера Верхуфа о клиентском опыте и пути, 2016; работы по сервисному проектированию, включая метод service blueprinting Мэри Джо Битнер и соавторов, 2008). В этой статье — что об этом сказано в источниках, как перестраивать процессы вокруг пути, где подход ошибается и как использовать фрейм OrgDevTools.

Что такое проектирование процессов от клиентского пути и когда оно нужно

Обычная последовательность: компания делит работу по функциям (продажи, доставка, биллинг, поддержка) и оптимизирует каждую. Клиент же видит одну задачу — «переехать», «подключить услугу», «вернуть товар» — и сталкивается с передачами между функциями, повторными вопросами и потерей информации. Подход от клиентского пути переворачивает порядок: сначала определяют путь, важный для клиента, затем проектируют процесс, который обеспечивает результат для клиента от начала до конца, и только затем — организационные и системные изменения.

Подход нужен, когда путь пересекает несколько функций, клиенты жалуются на «передачу от одного к другому», отток или неудовлетворённость сосредоточены на определённом процессе (подключение, смена адреса, возврат). Он менее полезен, когда процесс лежит внутри одной функции и клиент почти не участвует в нём, а также для маловажных путей, где улучшения не окупятся. Смежные методы: аналитика клиентского пути, Customer Effort Score, сквозной процесс (End-to-End), Service Blueprint, карта клиентского пути (CJM), голос клиента (VoC), NPS и CRM-стратегия.

Происхождение и исследовательская база

Метод сложился на стыке клиентоориентированного управления бизнес-процессами (BPM) и проектирования клиентского опыта. Академическая рамка — обзор Лемон и Верхуфа «Understanding Customer Experience Throughout the Customer Journey» (Journal of Marketing, 2016): клиенты взаимодействуют с фирмами через множество точек контакта в разных каналах, опыт стал более социальным, поэтому компаниям нужно объединять несколько бизнес-функций и внешних партнёров, чтобы создавать положительный опыт. Инструмент сервисного проектирования — service blueprinting, описанный Битнер, Остром и Морган (California Management Review, 2008): он основан на опыте клиента и позволяет наглядно представить динамические сервисные процессы; в отличие от физических продуктов, сервисы «текучи», динамичны, переживаются клиентом и часто создаются совместно клиентами, сотрудниками и технологиями в реальном времени.

Практическую рамку перестройки процессов вокруг путей дали Алекс Роусон, Юэн Дункан и Конор Джонс из McKinsey в статье «The Truth About Customer Experience» (Harvard Business Review, сентябрь 2013). На примерах телекомов, энергокомпаний, оператора платного ТВ и компании по прокату автомобилей они показали, как выбирают приоритетные пути, изучают причины проблем, перепроектируют опыт вместе с сотрудниками первой линии и перестраивают управление. Ниже — рерайт этих идей. Оговорка: данные статьи — результаты консультантов, работавших с компаниями; строгих контролируемых исследований она не содержит.

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

Академическая теория: как перестраивать процессы вокруг пути

Сначала путь, потом процесс

Авторы HBR предлагают начинать с выбора приоритетных путей: компании объединяют операционные, маркетинговые данные и исследования клиентов и конкурентов, чтобы увидеть опыт клиента по разным путям и решить, какие приоритетны. Для многих это первая такая работа, и она может занять несколько месяцев, но созданная база фактов позволяет руководству чётко увидеть опыт клиента и выбрать приоритеты. Затем каждый выбранный путь изучают подробно: фокус-группы клиентов и сотрудников, прослушивание звонков; так составляют карту самых значимых вариантов пути так, как их переживает и описал бы клиент.

Пример из статьи: оператор платного ТВ и отток

Оператор платного телевидения, один из лучших в отрасли по управлению оттоком, столкнулся со зрелым рынком, усилением конкуренции и растущими затратами на удержание лучших клиентов: обычные меры — предложения по апгрейду, скидки, «столы спасения» — были дорогими. Руководители обратились к другому рычагу — клиентскому опыту. Анализ показал, что установка для недовольных клиентов задерживалась из-за несогласованных стимулов: сотрудники бэк-офиса не оценивались и не поощрялись за точность заявок и иногда обрабатывали их с недостающей или неверной информацией. Традиционная панель показателей опыта не выявила проблему, потому что не включала показателя сквозного успеха. Как сказал один из руководителей, показатели напоминали арбуз: снаружи всё зелёное, а внутри красное.

Перепроектирование вместе с первой линией

Когда приоритетные пути выбраны и проблемы поняты, руководителям нужно избегать соблазна «спуститься с вертолёта» и диктовать решения, включая решения со стороны. Перестройка идёт вместе с сотрудниками первой линии. В энергокомпании, где приоритетом стал путь смены адреса, рабочие группы собрали сотрудников разных функций, а компания дала обещание «мы доставим»: доля недовольных переездом клиентов заметно упала, а выручка выросла на 4 миллиона евро (данные статьи). В компании по прокату автомобилей провели пилоты в ключевых аэропортах: команды первой линии — сотрудники стойки, мойщики, охрана выезда, водители автобусов — под руководством назначенного топ-менеджера должны были нарисовать опыт клиента и найти идеи улучшения, совместно определить причины проблем и решения и скоординировать действия, чтобы максимизировать скорость обслуживания с точки зрения клиента.

Управление: владельцы путей и метрики

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

Метрики пути вместо показателей передачи

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

Service blueprinting: процесс за кулисами

Инструмент сервисного проектирования, с которым обычно связывают этот подход, — service blueprinting. Схема показывает действия клиента, видимые ему действия сотрудников («на сцене»), невидимые «за кулисами» и поддерживающие системы, а также границу видимости между ними; по ней видно, какие внутренние процессы обеспечивают каждый шаг клиента и где возможны сбои. Это общепринятое описание метода; в практике его используют, чтобы связать карту пути с процессами, исполнителями и системами. Метод хорошо подходит для сервисов, потому что они создаются совместно клиентами, сотрудниками и технологиями в реальном времени.

Ключевые идеи и принципы проектирования процессов от клиентского пути

1. Принцип: путь клиента — отправная точка

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

2. Принцип: выбирайте приоритетные пути

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

3. Принцип: изучайте причины, а не симптомы

   Метрики точек контакта показывают «зелёные» цифры, пока путь в целом «красный». Причины часто лежат в несогласованных стимулах, потерях информации при передаче и отсутствии сквозной ответственности.

4. Принцип: перепроектируйте вместе с первой линией

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

5. Принцип: у пути есть владелец и метрики

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

6. Принцип: путь — это управленческая перестройка

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

Как спроектировать процессы от клиентского пути: пошаговая инструкция

Практическая последовательность такая. Определите пути клиентов, важные для бизнеса: подключение, покупка, обращение в поддержку, смена адреса, возврат, продление. Соберите данные для приоритизации: удовлетворённость и усилия по путям, отток, обращения, стоимость. Выберите один–три пути для перепроектирования. Опишите выбранный путь глазами клиента: этапы, ожидания, точки контакта, эмоции, проблемы (карта пути), используя фокус-группы, интервью и записи обращений. Постройте схему процесса за кулисами: кто из функций и какие системы обеспечивают каждый шаг клиента и где происходят передачи (service blueprint). Найдите причины проблем: потери информации, ожидание, дублирование, несогласованные стимулы. Соберите кросс-функциональную команду, включая сотрудников первой линии, и предложите перепроектированный процесс с ответственными и метриками пути. Проверьте изменения на пилоте в одном подразделении. Закрепите владельца пути и включите метрики пути в оценку функций. Масштабируйте и повторяйте анализ.

Учебный расчёт покрытия

Условный пример. Путь возврата товара включает 10 точек контакта: заявка на сайте, подтверждение, инструкция, упаковка, курьер, приёмка, проверка, решение, возврат денег, уведомление. Для 6 из них есть явно описанный процесс (владелец, срок, стандарт), для 4 — нет: курьер, проверка, решение и уведомление обрабатываются «по ситуации». Покрытие — 6 ÷ 10 = 60 %. Вывод: процессы для четырёх точек нужно спроектировать; но покрытие само по себе не говорит о качестве процессов и о том, какие из непокрытых точек критичнее. Числа условные.

Пример из практики: энергокомпания и смена адреса

Документированный пример из статьи HBR: энергокомпания, у которой отток среди клиентов, переезжающих на новый адрес, достигал 40 %, выбрала этот путь приоритетным. Рабочие группы объединили сотрудников разных функций, ввели новые кросс-функциональные показатели для каждого сотрудника первой линии, работавшего со сменой адреса (например, безошибочная фиксация данных колл-центром для последующих этапов), а обещание клиентам сформулировали как «мы доставим». По словам авторов, доля недовольных клиентов при переезде заметно снизилась, а выручка выросла на 4 миллиона евро; затем масштаб программы расширили до пяти критических путей, каждый из которых вёл член руководства с еженедельными обзорами. Оговорка: цифры сообщены консультантами, участвовавшими в проекте, без независимой проверки и без базы сравнения.

Ограничения, слепые зоны и критика проектирования от клиентского пути

Типовые ошибки при проектировании процессов от клиентского пути

1. Ошибка 1: процессы проектируют по оргструктуре.

   Каждая функция оптимизирует свою часть; клиент проходит по «швам» между ними и теряет время и информацию.

   Как избежать

   начинать с пути клиента и проектировать процесс под его шаги, а не под структуру подразделений.

2. Ошибка 2: опираются на метрики точек контакта.

   Панель показателей «зелёная», а путь в целом «красный»; проблема скрыта.

   Как избежать

   ввести метрики пути и сквозной успех: удовлетворённость и результат в конце пути.

3. Ошибка 3: решения спускают сверху.

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

   Как избежать

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

4. Ошибка 4: нет владельца пути.

   Путь принадлежит всем и никому; улучшения зависают между функциями.

   Как избежать

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

5. Ошибка 5: несогласованные стимулы.

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

   Как избежать

   изменить показатели и вознаграждение, чтобы функции отвечали за результат пути.

6. Ошибка 6: карта без процесса.

   Картирование пути завершается красивой схемой; процессы, исполнители и системы не меняются.

   Как избежать

   связать каждую точку пути с процессом, исполнителем, системой и метрикой (service blueprint).

7. Ошибка 7: пытаются перестроить всё сразу.

   Одновременно перепроектируют десятки путей; ресурсы распыляются, эффект не виден.

   Как избежать

   выбрать один–три приоритетных пути, получить быстрые победы и масштабировать.

Метрики: как оценивать перепроектированные процессы

Универсальных нормативов нет; фиксируйте динамику по своим данным:

• Покрытие процессами: доля точек пути, для которых есть явно спроектированный процесс с владельцем.

• Удовлетворённость по пути: оценка опыта на всём пути, а не только в точках контакта.

• Сквозной успех: доля клиентов, прошедших путь без повторных обращений и ошибок.

• Отток на пути: доля клиентов, потерянных на пути (например, при переезде или подключении).

• Время пути: длительность от начала до результата для клиента.

• Передачи: число передач между функциями и доля обращений с потерей информации.

Клиент видит одну задачу, а компания — набор функций: процессы, спроектированные по функциям, оставляют клиента разбираться со «швами».

План внедрения проектирования процессов от клиентского пути по неделям

1. Неделя 1: выбор пути

   Соберите данные об удовлетворённости, оттоке и обращениях и выберите один–три приоритетных пути.

2. Неделя 2: карта и причины

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

3. Неделя 3: перепроектирование

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

4. Неделя 4: пилот и владелец

   Запустите пилот, назначьте владельца пути и включите метрики в оценку функций.

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

Как реализовать план проектирования от клиентского пути с помощью фрейма «Процессы от клиентского пути» в OrgDevTools

Фрейм состоит из двух вкладок — «Дизайн» и «Итоги». На вкладке «Дизайн» вы перечисляете шаги клиентского пути списком записей (например, «клиент оформляет возврат товара») и вводите два числа: общее число точек контакта и число точек, для которых спроектирован процесс. Покрытие считается автоматически как их отношение в процентах и подсвечивается цветом. На вкладке «Итоги» показаны вердикт и кнопка задачи «Спроектировать процесс для непокрытой точки пути», в описание которой подставляется первый записанный шаг пути.

• Неделя 2 — путь: запишите шаги клиентского пути.

• Неделя 3 — покрытие: введите число точек и число точек с процессом.

• Неделя 4 — задача: создайте задачу на проектирование процесса для точки без процесса.

Вердикт строится по ступеням: шаги пути не названы — предложение начать с картирования; шаги есть, а покрытие не заполнено — предупреждение; покрытие ниже 50 % — красное предупреждение; ниже 80 % — предупреждение о заметном пробеле; иначе — подтверждение, что большинство точек имеют спроектированный процесс.

Чего фрейм не делает. Он не связывает шаги пути с конкретными процессами: список шагов и два числа покрытия никак не связаны между собой, и общее число точек может не совпадать с числом записанных шагов. Фрейм не показывает, какие именно точки не покрыты: в описание задачи подставляется первый записанный шаг, а не непокрытая точка. Он не хранит владельцев, метрики, схему процесса за кулисами и не оценивает качество процессов; покрытие говорит только о наличии процесса, но не о том, что клиентам стало проще. Пороги 50 % и 80 % зашиты в код и не основаны на источнике.

Книги и материалы по теме проектирования процессов от клиентского пути

Алекс Роусон, Юэн Дункан, Конор Джонс — «The Truth About Customer Experience» (Harvard Business Review, сентябрь 2013). Путь против точек контакта, выбор приоритетных путей, перепроектирование с первой линией, управление и метрики.

Кэтрин Лемон, Питер Верхуф — «Understanding Customer Experience Throughout the Customer Journey» (Journal of Marketing, 2016, т. 80, № 6, с. 69–96). Академический обзор клиентского опыта и пути.

Мэри Джо Битнер, Эми Остром, Фелиция Морган — «Service Blueprinting: A Practical Technique for Service Innovation» (California Management Review, 2008, т. 50, № 3, с. 66–94). Метод сервисного проектирования, основанный на опыте клиента.

Линн Шостак — «Designing Services That Deliver» (Harvard Business Review, 1984). Ранняя работа о схемах сервисных процессов.