Введение
Я помню как лет пять-семь назад бизнес-сообщество сходило с ума по CRM. О нем говорили на конференциях, его учили внедрять в Бизнес-молодости, а всем известный разработчик CRM сделал из презентации своего продукта шоу почти как Тони Роббинс.
Основной посыл этой движухи был такой: CRM повышает продажи. Дескать, внедрите соответствующее ПО в своей бизнес, и «тугая струя клиентов» (так и говорили, я не шучу) будет обеспечена. В итоге CRM внедряли, CRM настраивали и про CRM консультировали. Вокруг инструмента родилась целая отрасль.
Но порой среди этой «кайфовой атмосферы свободы и предпринимательства» (снова цитата) из разных мест раздавались робкие воззвания от наиболее адекватных специалистов, что вообще-то программное обеспечение CRM само по себе ничего не повышает. Автор этих строк тоже пытался разбавить всеобщую тарантеллу например вот этой вот статьёй (требуется VPN).
Действительно, в системах управления отношениями с клиентами нет ничего, что системно и гарантированно повышало бы продажи, потому как они не решают ни одну из корневых проблем, из-за которых у бизнеса эти самые продажи в дефиците. Этих причин, навскидку, три: ненужный или неконкурентоспособный продукт, отсутствующие или кривые процессы и неподходящие люди. Ни одна из этих проблем не решается только с помощью программирования. Софт должен лишь дополнять управленческие усилия.
CRM - это прежде всего процесс. Процесс, в котором нужные люди выполняют нужные операции, которые кто-то разработал, настроил и протестировал. Каким инструментом хранения информации и автоматизации рутины они при этом пользуются – не так важно, хоть экселькой. Абсолютно все интеграторы CRM, с которыми я обсуждал эту тему, были со мной согласны – без процесса внедрять какой бы то ни было софт совершенно бесполезно.
Сегодня хайп на CRM спал, и сейчас я то и дело встречаю запросы из серии «мы внедрили этот ваш CRM, но ничего принципиально не поменялось, помогите». Скоро исчезнут и они, рынок окончательно исчерпает хайпотенциал темы и переключится на другую. Точнее, уже переключился и раскачивает. Они чисто с точки зрения аббревиатуры на 2/3 похожи. Конечно же, я про CJM.
С ним та же история: хоть буква М и означает Map, гораздо более полезно было бы её расшифровать как в CRM – Management. Потому что карта точно также сама по себе не способна в компании ничего поменять. Нужен процесс работы с картой. Которого почти ни у кого нет.
Можно сказать, ситуация даже хуже, чем с CRM, потому что процессы продаж разной степени зрелости худо-бедно есть почти у всех. И порядочный консультант всегда найдёт точку опоры, возьмись он наводить порядок. В случае с CJM, соответствующих процессов нет почти ни у кого. Для многих сам факт их существования является открытием.
Цель этой статьи – рассказать о том, что процессы работы с картами клиентского опыта существуют и концептуально показать как они устроены, опираясь на опыт нашего Бюро. Мы занимаемся исследованием и построением этих процессов уже больше 5 лет и сейчас уже можно говорить о некоторой сложившейся картинке. Объем не позволит детально рассказать обо всех аспектах практики, поэтому в этой статье – обзорно. По мере выхода отдельных материалов по каждой из частей процесса, здесь будут появляться соответствующие ссылки.
Цели картирования
Когда к нам в Бюро приходит запрос на изготовление CJM, я всегда выясняю две вещи: какую проблему хотят решить картой, и какие действия собираются предпринимать для решения проблемы, когда карта будет готова. Ответ на первый вопрос помогает разобраться с целями картирования, им будет посвящена эта глава, а второй вопрос помогает прояснить процесс. О нем поговорим во второй части статьи.
Итак, когда компании заказывают CJM, они хотят в основном решить следующие проблемы:
Изолированность подразделений и команд друг от друга
Допустим, вы продаёте двери. Типичный путь вашего клиента выглядит примерно так: он заходит на ваш сайт, смотрит каталог, приценивается, выбирает несколько подходящих дверей и едет в ваш оффлайн-магазин смотреть их вживую. В шоуруме он их находит, закрывает-открывает, выбирает ручки и замки, оформляет покупку и заказывает вашу доставку и установку. Через какое-то время дверь ему доставляют и устанавливают.
Так вот почти всегда, подразделения компании, которое: а) управляет онлайн-каталогом б) управляет шоу-румом в) продаёт г) доставляет и д) устанавливает – это совершенно разные оргструктурные единицы, а некоторые могут вообще не являться частью организации, а выполнять эту функцию на аутсорсинге или в партнёрстве.
Это и есть изолированные подразделения. Клиент на своем пути последовательно взаимодействует с каждым из них, считая при этом, что он взаимодействует с одной компанией. Однако, представители этих отделов могут не знать и даже не интересоваться, что происходило у клиента с коллегами до и после того участка, за который отвечают лично они. Это приводит к тому, что клиент последовательно сталкивается со всеми проблемами в опыте, которые создают эти изолированные отделы, нанизывая их на свой путь как бусины на нитку. Поэтому даже если каждый департамент косячит понемногу, в итоге у клиента целый набор проблем.
Идея карты в том, чтобы объединить эти разрозненные подразделения, развернув их лицом к клиенту. Ведь когда у тебя есть наглядное пособие, можно на нем показать масштаб этого самого клиентского пути и разметить зоны ответственности, чтобы между ними не было зон, где за клиента, например, вообще никто не отвечает.
Недоверие стейкхолдеров
Вторая важная задача, с которой компании пытаются справиться с помощью карт – убеждение стейкхолдеров в необходимости перемен. В своей статье про фальшивых лидеров я писал о корпоративной культуре, в которой подчинённые вынуждены «продавать» своим начальникам идеи и улучшения. К сожалению, в сфере CX эта практика встречается особенно часто. В больших компаниях клиентоориентированность почти всегда прорастает именно снизу вверх, потому как сверху слишком мало знают о проблемах клиентов, чтобы предлагать какие-то улучшения.
Поэтому те инициаторы, кто пытается снизу продавать какие-то инициативы боссам, сталкиваются со скепсисом и недоверием. Стейкхолдеры с большим сомнением относятся к тому чтобы делать что-то на пользу клиенту, если за этим не стоит железобетонных доказательств необходимости.
Идея в том, чтобы в качестве такого доказательства предъявить прямую речь клиента, добытую, например, из интервью или собранную из отзывов и кластеризованную в паттерны. Карту пытаются использовать как хранилище такой информации, чтобы показывать топам с одной стороны масштаб проблемы, а с другой – исключить свою субъективность. Подразумевается, что это не мы всё придумали, это так говорят клиенты и этих цитат вон сколько. Прямая речь в сочетании с эффектом масштаба вызывает доверие и упрощает защиту инициатив.
Зависимость знаний по CX от конкретных людей в компании
Ну и наконец третья частая задача - минимизация последствий текучести в отделе CX. В любой большой компании кадры часто меняются, и срок жизни проекта по изменениям в среднем превышает срок работы специалиста в этом проекте. Поэтому очень важно, чтобы информация о том, что надо делать, что уже делается, что было сделано и что из всего этого получилось, хранилась где-то отдельно от голов людей, которые могут уйти и унести с собой важные сведения. Карта в этом случае видится как такое вот внешнее хранилище данных.
Поэтому, кстати, карта в виде большой схемы на стенке или в miro - не самый удобный артефакт для работы. Это просто слишком большой объем. Поскольку хорошое организованное хранилище знаний предполагает поиск, фильтрацию, кластеризацию и всякие другие действия с информацией, вместе с картой лучше вести базу знаний по клиентскому опыту, в которой содержится расширенная информация.
Решает ли карта эта задачи?
Теперь давайте посмотрим на эти три типичных ожидания и честно зададимся вопросом: а поможет ли карта со всем этим справиться?
Поможет ли карта синхронизировать команды? Честный ответ – нет. Сама по себе карта никого не способна вокруг себя синхронизировать. Она может стать отличным подспорьем, но только если кто-то будет целенаправленно прикладывать усилия к объединению изолированных команд, наблюдать за тем, как команды сближаются и корректировать их сближение, периодически обращаясь к карте. Без этих усилий по объединению карта ничего не значит.
Поможет ли карта убедить стейкхолдеров? Здесь не так очевидно, но тем не менее ответ тоже нет. Потому как если стейкхолдер настроен скептически по отношению е клиентоцентричности вообще, то он будет скептически настроен и по отношению к карте. Начнёт задавать вопросы про процесс сбора данных или придираться к репрезентативности. Поэтому карта и здесь выступает не более чем помогающим инструментом, усиливающим, а не заменяющим необходимость в активном убеждении, переговорах, создании коалиций и союзов. Без этой сложной и муторной работы карта никого ни в чём не убедит.
Ну и наконец, третья цель в какой-то момент может быть закрыта картой, однако и здесь есть подводный камень – единожды собранные данные быстро устаревают. Поэтому чтобы карта действительно была практически ориентированным хранилищем, необходимо её постоянно обновлять. А это как ни крути – отдельный процесс.
Итак, мы приходим к выводу, что все ожидания, которые компании озвучивают, когда хотят построить CJM, на самом деле не решаются CJM как картой. К ней необходим CJM как процесс – Customer Journey Management
Процесс CJ management
Глобально менеджмент клиентского пути, по нашему опыту, выглядит так. Начинается всё, естественно, с создания карты. Постепенно проект по картированию перетекает в процесс, а потом вокруг процесса постепенно вырастает департамент, который укореняется в оргструктуре компании. Так компания становится клиентоориентированная не на словах, а на деле. У нее появляются не только инструменты, но также процессы и люди.
Важно понимать, что создание карты клиентского пути – это еще не процесс. Это исследовательский проект, который начинается с отделения области знаний от области незнания, продолжается в поле (об этих этапах я подробно писал тут) и заканчивается сборкой артефакта, который я подробно описал в цикле из двух статей про CJM. Конечно, с тех пор кое что изменилось, карты стали более сложными, мы экспериментируем с собственной нотацией, похожей на BPMN, но об этом я еще напишу в других статьях.
После того, как карта, отражающая путь клиента готова, начинается сам процесс работы с этой картой, который изображён на схеме:
Этот процесс похож на конвейер, который перерабатывает данные, содержащиеся в карте, переводя их из стикеров на доске в реальные изменения в компании. Об этом процессе и поговорим далее. Первая его часть называется ПСК.
Подпроцесс ПСК
ПСК это «Причинно-Следственный Комитет» – название шуточное и каламбурное. Оно родилось в работе с одной компанией, где было много разных комитетов. Мы решили продолжить традицию и назвать собрание по анализу причин возникновения барьеров в клиентском опыте Причинно-Следственным Комитетом. Название прижилось, и теперь такие комитеты действуют и в других компаниях, где мы внедряли эту практику.
Суть ПСК вытекает из простой мысли: компании, которые никогда не занимались улучшениями в интересах клиента, гораздо лучше реагируют на инициативы, если понимают как они улучшат жизнь не только клиентов, но и лично их. Таким образом необходимо свести проблемы и барьеры в опыте клиента к так называемым НЖЯ – нежелательным явлениям для компании.
Простой пример из моей практики – про переполненные шоурумы и разницу между лидами и людьми. Почитайте о нем в канале, подпишитесь и возвращайтесь. В этом примере переполненный шоурум – барьер для клиента, а ушёдший и некупивший из-за этого клиент – НЖЯ для компании. Процесс взаимоувязки барьеров и НЖЯ с помощью специальным образом построенных логических цепочек и называется ПСК-анализом. Эта методология базируется на Теории Ограничений Систем, но в несколько адаптированном к нашей предметной области виде была разработана (и продолжает разрабатываться) внутри нашего опыто-конструкторского Бюро.
ПСК-анализ становится переходной практикой от проекта по картированию к налаживанию процесса CJM. Результатом его является отранжированный список НЖЯ. Поскольку формулировки НЖЯ содержат консенсус относительно того, что эти явления нежелательны именно для компании, а не только для клиента, снижается первый уровень сопротивления – сомнение «а надо ли вообще что-то менять». Таким образом ПСК готовит почву для второй части процесса – внедрению решений или, как мы их называем, CX-инициатив.
Разработка и внедрение CX-инициатив
После того как усилия по поиску точек приложения трансформаторских сил дали первые плоды, запускается второй подпроцесс – разработка и внедрение инициатив.
По сути этот процесс сводится к бенчмарку, изготовлению и тестированию прототипов решений тех ключевых проблем, которые были получены на ПСК. С последующей передачей в масштабирование наиболее успешных образцов.
И знакомые с темой читатели скажут — но ведь это стандартный двойной ромб дизайн-мышления! Не совсем.
Процесс дизайн-мышления – это популярный, но, к сожалению, совершенно не адаптированный под Российскую реальность процесс. Он строится на двух столпах: фокусе на количестве (а не на качестве) идей, и на многократной (чем больше, тем лучше!) итеративности процесса. Кроме того ДМ на практике тяготеет в основном на решение очевидных проблем клиентов, а не глубинных проблем компаний, так как там нет механизма перехода от одного к другому и нет инструмента учёта организационных ограничений. Например, клиенту неудобно искать что-то на карте, давайте перерисуем карту более понятно. Проблема и тут же решение. Да, на словах там есть предостережение «убедиться, что мы решаем ту проблему, которую надо», но на деле это никак методологически не раскрывается.
Все эти факторы делают процесс ДМ малопригодным к внедрению в Российские корпорации, в которых , кто бы что не говорил, культурно нет ни высокой толерантности к ошибкам, ни достаточного количества времени и денег на эксперименты. Чтобы это поменять, надо повысить уровень зрелости всей компании. Однако люди, которые руководят ДМ-практиками почти никогда не работают в компаниях настолько долго, чтобы застать, не говоря уж о том, чтобы организовать переход своей компании на следующий уровень зрелости. В итоге ДМ-тренинги и дизайн-спринты в большинстве случаев проходят и забываются, не причиняя никакого системного эффекта. Поэтому реально (а не номинально) практический процесс внедрения изменений должен учитывать реальный (а не выдуманный) культурный ландшафт:
Во-первых, он должен быть ориентирован не на количество, а на качество идей (т.к. в компаниях низкая толерантность к ошибкам).
Во вторых, он должен давать результаты за небольшое количество итераций, а в идеале показывать эффективность с первого раза (из-за дефицита времени на эксперименты).
В третьих, он должен быть ориентирован не на плоские, а на иерархические оргструктуры. Тут надо расшифровать. Мы помним, что одна из проблем компании, которая вообще приводит её в CX – изолированность подразделений. Поэтому процесс должен запускаться внутри потенциально такого же по началу изолированного от всех CX-департамента. Оттуда он должен способствовать налаживанию связей между другими изолированными подразделениями, а не их уничтожению. Перекраивание оргструктуры маленькой кучкой энтузиастов с картой наперевес – что-то из области утопического.
Наконец, он должен осмыслять директивные указания и фокус компании на извлечение прибыли как контекст, который нужно учитывать, а не как проблемы, с которыми нужно бороться.
Именно эти четыре фактора делают его идеологически принципиально иным, чем двойной алмаз дизайн-мышления. И они же делают его практически применимым к большинству (а не меньшинству) российских компаний.
Как это все реализуется практически? Расскажу пару примеров. В нашем Бюро мы используем Базу Полезных Образцов. Это что-то типа паттернов проектирования или информационного фонда в ТРИЗе, но содержащий образцы успешных реализаций взаимодействия людей и компаний в цифровом и физическом мирах.
Когда мы находим хорошо прояснённую глубинную проблему, в базе образцов почти всегда есть решение или несколько решений в комбинации, которое или полностью закрывает проблему, либо дает существенный прогресс в решении и дальше останется доработать напильником. Это даёт существенное сокращение количества итераций на тестирование нежизнеспособных идей.
Второй пример – принципы сбора CX-команды и сортировки инициатив. Наш опыт показывает что даже хорошо отсортированный по какому-нибудь хитрому фреймворку список инициатив совершенно бесполезен, если все равно ничего из этого не будет сделано. Ирония в том, что команды почти всегда на самом деле знают, что в их компании реально провернуть, а что нет. И поэтому очень легко и активно занимаются обсуждением инициатив, которым не суждено воплотиться. Поэтому в нашем процессе ключевым (и часто единственным) фактором сортировки выступает готовность команды взять на себя полную ответственность за реализацию инициативы.
Это только несколько из примеров как можно сократить неопределенность при создании инициатив. Еще используются инженерные техники, приёмы разрешения технических противоречий из ТРИЗ и много других практик. Для решения отдельных задач могут применяться специфические инструменты, например шаблон потребности.
Контроль эффективности инициатив и поддержание актуальности карты
Каждую карту нужно обновлять, чтобы она не устарела и не перестала отражать реальность. Обычно такие поддерживающие исследования проводят 2-3 раза в год, но, конечно в каждом конкретном случае всё зависит от того, как быстро происходит внедрение CX-инициатив. Например, если за квартал компания успевает лишь слегка скорректировать скрипт продавца, то переисследовать всю карту нет большого смысла.
Поддерживающие исследования также бывают количественные и качественные. Под количественными обычно подразумевается замеры NPS и CSI в нужных местах клиентского пути а под качественными — сбор обратной связи по прототипам инициатив и небольшие исследования по обновлению CJM в самых важных местах.
Один из самых частых вопросов при обновлении – какие части карты обновлять в первую очередь. На этот счёт существует несколько подходов. Один из них – обращать внимание на самые проблемные места, в которых NPS или CSI ниже всего. Это выглядит логично, но как и ДМ упирается в организационные ограничения, которые с наскоку не взять.
Поэтому мы и здесь придерживаемся принципа законченной ответственности: лучше всего начинать внедрять инициативы и обновлять клиентский путь там, где та команда, которая этим занимается, может довести дело до конца.
Например, если в вашей CX-команде живут по большей части представители маркетинга, а производства или продуктовых команд нет, то вам стоит начать с решения проблем, которые находятся полностью в зоне контроля маркетинга. Это может быть реформирование рекламных кампаний или неудачных POS-материалов.
Важный момент – это не заменяет решение более сложных и фундаментальных проблем, где требуется участие большого количества изолированных подразделений. Это необходимое условие для того чтобы к ним перейти. Ведь чем быстрее CX-команда покажет так называемые «быстрые победы», тем больше шансов, что она получит ресурсы и полномочия для побед более глобальных.
Возникновение отдела
Первым владельцем, можно сказать родителем процесса управления CJ становится рабочая группа проекта по созданию карты.
И если проект делать правильно, то новорожденный процесс очень быстро становится одним из самых структурированных в компании, т.к. у него в отличии от почти всех непрофильных процессов сразу есть методология, которую можно посмотреть в документах. Именно она производит впечатление на стейкхолдеров внутри компании. Для понимания: много ли вы знаете компаний, где в отделе маркетинга есть единая, утверждённая, донесённая до всех система сегментации целевой аудитории? Не какие-то черновики с персонажами, которые даже сам автор с трудом найдет, а официальный документ, к которому все обращаются? Или много ли вы знаете компаний, где существует формализованное ценностное предложение, содержащее исчерпывающий и доказанный ответ на вопрос чем продукт ценен и выгодно отличается от конкурентов?
А между тем появление, объяснение и утверждение таких документов, баз данных и инструкций - результат правильного процесса управления опытом. Поэтому когда он появляется, все прочие департаменты начинают относиться к отделу как минимум с уважением, а как максимум – спрашивать и советоваться и даже иногда брать пример.
Заключение
Как видите, CJM – это не только карта. Основные задачи, которые ставят компании, заказывая разработку карты – это синхронизация отделов, убеждение стейкхолдеров и сохранение актуальных данных о проблемах клиентов внутри компании. Ничего из этого не решается только картой. Необходим процесс.
Процесс этот запускается в конце исследовательского проекта по картированию и представляет собой цикл анализа найденных барьеров в клиентском опыте, выявление корневых причин их возникновения и разработки и тестирования решений этих корневых причин с одновременным поиском новых барьеров, которые и замыкают цикл. При этом сам процесс обладает некоторыми характерным чертами: он ориентирован на качество, а не количество идей, требует небольшого (в сравнении с дизайн-мышлением) количества итераций на проверку и ориентирован на иерархические, а не плоские оргструктуры.
Как только этот процесс запущен и руководству предъявлены первые быстрые победы, которые достигаются за счёт фокуса на тех участках клиентского пути, которые максимально находятся под управлением проектной команды, процесс можно легитимизировать внутри компании и подключать к нему другие подразделения, постепенно ликвидируя тем самым их изолированность.
Если вы хотите построить такой процесс у себя – обращайтесь к нам в Бюро. А если хотите научиться строить такой процесс самостоятельно – приходите на открытый курс по стратегической логике в CX или организуйте такое обучение для своей компании.
