Для архитекторов вышедших из программистов сложно пререйти к пониманию логики построения бизнес архитектуры. Для него привычное мышления сосредоточено на том, что для улучшения продукта надо разработать новый фукционал – имеено этим он занимался. Для него не привычно, что для улучшения продукта нужно убрать функционал, а именно при анализе поведения пользователей может оказаться, что слишком насыщенный продукт функционалом, которым пользуются единицы, мешает всем пользоваться продуктом. Но это болезненный и столь же эффективный способ перестать мыслить функционалом и перейти от своих ощущений, что функционал комуто-нужне и на него будет спрос автоматом к принятию решениям на этом слое. Решни могут быть направлены на оптимизацию обеспечения бизнеса или развитию взаимодействию с пользователя, причём технически они могу быть похожи, но резутат определяется на безнес уровне. Бизнес решения строятся не на простой последовательности действий, а на сегментах аудитории, каналах сбыта, количеству повторного использования, объёму и интенсивности оттока, глубине и ширине воронки привления и продаж, заинтересованные стороны, формирование потребностей, а оптимизационная часть в диаграмме окружения процесса на SLA, регулирующем законодательсве, рисках, KPI (экономических и других показателях). В принципе, процесс может состоять только из пользовательских операций и ручных операций сотрудника. Если проектируется совершенно новый процесс, то это как раз хорошо, так как менять и корректировать гораздо проце, а уж если процесс оправдает себя, то можно и автоматизировать. При этом как раз может быть и важным фактором, что процесс имеет индивидуальность под пользователя и неавтоматизирован. В таком случае, есть пользователи, есть обеспечения и может не быть IT. IT появляется, если в этом есть необходимость. Если же есть, то не нужно брасаться за реализацию, так как сначала нужно сделать нужно определить, иммется ли данный фукцнионал на карте (портфеле) систем, а если нет, то рассмотреть различные варианты или их комбинацию с учётом профильности (карты компетенций) функционала: покупка, аренда, оутсорс и как остаточный вариант – собственная разработка. Такой подход, довольно, непривычен для программистов.
Для редизайна клиентско пути необходимо владельцу клиентского пути определить основные преметры изменений для делегирования или наоборот, представить владельцу клиентского пути на утверждение для полученя полномочий:
* определить проблему, например, снижение пользователей или их удовлетворёность;
* определить цель по SMART (Конкретность, Измеримость, Достижимость, Согласованность, Ограниченность во времени);
* определить ожидаемый резульльтат – определить метрики результата, например, по удовлетворённости (NPS, CSI, CSI) или конверсии;
* управление – состав учасников команды (из экспертов изменяемых систем входящих в их состав и экспертов по доменам, таким как безопасность, аналитика, экспертови другим, экспертов по в бизнес домене систем), их полномочия и задачи;
* определить гараницы изменений в зависимости от возможностей: какой или какие клиенскоие пути следует изменить, или только процесс, или даже только часть процесса или только одну его траекторию;
* риски изменений – определить стратегию управления рисками, какими рисками будем упрвлять, а какими принебрежём;
* план действий – составление роудмэпа проекта.
В этом нам поможет аналитика, которая локализовать и предсказать изменения. На начальных этапах, нам нужно в принципе разобраться с текущей ситуацией. Вспомним, что бизнес по модели Александра Остервальдера состоит из двух частей, соединённых услугой. Правая часть – часть клиента, которая может рассматриваться как клиентский путь и бизнес процессы, обеспечиающие его предоствалением сервиса. Так, бизнес процессы – на строне компании, клиентский путь – на стороне клиента. Также можно построить слоёную архитектуру по TOGAF, верхними слоями будут – бизнес и пользвательские слои, а нижние – обеспечивающие слои, но это уже после проведения анализа, когда мы сможем зафиксировать требования предъявляемые бизенс процессами к их обеспечивающим информационным системам. А сейчас нам нужно проанализировать пользователький путь. Мы уже при рассмотрении модели бизенса любой компании говорили, что правая часть с пользователями анализируется, а левая – подстраивается под неё выбором решений. Чтобы опеделить, лувую часть на верхнем уровне – уровне бизнес процессов – нужно понимать равую и как влияет левая на правую. В этом нам поможет карта пользовательского пути CJM, которая отображает параметры пользвателького пути, бизнеснесс процессов и характеристики взаимодействия пользователького пути с бизнес процессами. Это выскоуровневый инструмент, который демонстрирует интересующий нас в данный момент срез контеретного бизнес процесса или процессов и пользователького пути. Сам пользователький путь зафиксирован и определяется точками взаимодействия между которыми пользователь движется с которыми взаимодействует. Оценка пользователем конкретно проходения пользователького пути (пользовательского опыта) определяется субъективными и объективными ожиданиями клиента от ожидаемго пользователького опыта, поэтому CJM составляется от набор характеристик пользовательского опыты разных килентов от их лица. Здесь мы можем произвести разлиыные срезы (набор параметров) по качественным характерстикам пользотелького пути по метрикам разных пользовательких опытов. Корректируя удовлетворённость и набор точек, мы изменяем результат пользователького пути и его общую оценку. Результат завист, смогли ли мы удовлетворить потребность, например, предоставить продукт набором контактов. Общая оценка по большей части есть самая плохая оценка, полученная при оценке всех точек контакта, поэтому важно находить выбросы и узкие места в пользовательком пути. Также важно поинмать, как оценка контакта влияет на пользователькую вороку и конверсию, чтобы определить улучешение каких точек даст наибольший эффект. На CJM аналитик это визиализирует, а бизнес архитектор может прикинуть требования к процессам. Конечно, есть общий набор процессов и для большей эффектиности один процесс из него переисользуется в разных пользовательких путях. Что бы архитектор смог понят трубования к процессам, он должне знать как минимум пиповые процессы для данной сферы бизнеса, так как создание процесса с нуля в очень больших компаниях занимает от полугода в самом лучшем случае.
Когда глобальные цели поставлены, мы высокоуровнево знаем с помощью кого, как, каким образом и над чем будет дейсвовать – нам нужно определиться с конкретикой. Для этого, нам нужно занать начальное состояние (AS IS) и целевое (TO BE), чтобы сделать дейсвия по переходу из начального состояния в целевое. Изучение AS IS заключается в изучении, как в компании устроено сейчас и как происходит взаимодействие, какие процессы есть и какие системы их обеспечивают. Изучение необходимого (TO BE) заключается в изучении пользователей и как им лучше взаимодействовать с компанией, какие проблемы у пользователей есть, какова их причина и какой вариант решения для них более релевантен. И при создании AS IS, и при создании TO BE содержат три этапа: целепологание, изучение и создание CJM. Изучение AS IS и TO BE должны проиходить независимо и не должны оновываться друг на друге. Эменно это даст достовеный результат, а нахождение различий с сходств, если они будут, – задача GAP анализа. Расмотрим поэтапно:
* Планировании направлений иследований влючает определение целей, хвата и карты стейкхолдеров (в miro.com есть шаблоны Stakeholder Map). Цели важно определить вначале, чтобы решать проблемы пользователей и не пытаться усвоить весь объём информации, который, скорее всего приведёт к избытку, и нам прийдётся строить модели, чтобы его уменьшить. Под целями можно понимать улучшение каких-то конретный пользовательских показателей, что может привести к потребности улучшить выбивающийся из общей картины сервиса, который понижает до своего уровня общую оценку пользователем пользоователького пути. Под этим сервисом на обеспечивающем уровне скрывается конкретный процесс, и скорее всего, в нём таже есть выбивающееся действие – "слабое звено". Что-бы можно было сравнивать показатели, они должны быть соизмеримы, то есть сходный характеристики, например, на сайте ответ обычной страницы и страцы требующей обработке BigData данных не имеет смысла приравнивать, а стоить выровнять остальные страницы, а долгий запрос сделать отложенным (ассинхронным) и передать результат push-уведомлением. Другим примеро может быть скрость разных каналов, например, личного посещения и на сайте, сильно разных групп пользователей имеющих опыт работы с сатом и нет на скорости работы с сайтом. Результатом этого этапа является паспорт редизайна, параметры которого согласовны на первой встрече (kick-off) со всеми основными участниками (владельцами путей и процессов, командой редизайна) которыми могут быть цели, задачи, риски, границы, выгоды и роадмап редизайна.
* Сбора видения процесса глазами клиентов, глазами компании и глазами конкурентов (Бенчмаркинг), для этого определим стейкхолдров помимо клиентов. Сгруппируем данные клиентов по их типам: физические, поведенческие, когнитивные, эмоциональные, потребности, события, сожности. Также, сгруппируем даные компании по их типам: отслеживаемые метрики, сложности у сотрудников, возможности улучшения, цели компании, процессы, взаимодействия с клиентом. Собирать данные относящихся к клиентам можно с помощью анализа (динамика обратной связи, воронки продаж, конверсия), интервью, но эфективнее всего наблюдая за пользователями или становясь самим пользователем (гемба), а также антекет и опросов. Собрать данные со стороны компании можно на основе мнения экспертов, при изучении процессвов и их отлонений от заданных. Важно, чтобы данные были об однородном объекте, например, однородной группе пользвателей или однотипных каналах, данных было достаточно: не менее десяти опрошенных в интервью клиентов или сотрудников, не менее нескольких десятков отзывов, не менее нескольких мнений руководителей. При интервью нужно задавать открытые воросы на что уже случилось и что было сделанно после некоторых вводных вопросов. Задавайте уточняющие вопросы.
* Построение карты клиентского пути: создание таблицы, где колонки – этапы клиентского пути, а строки – характеристики. Харатеристики и соответвенно строки их опысывающие можно сгрупировать в три категории: на характеристики самого клиента (цели, потребности), на взаимодействие его с сервисами компании (фактические сложности и субъективная оценка) и самих сервисов компании (проблемы и точки развития). При анализе большого текущего клиентского пути получается CJM большого размера на одно листе. Тут есть два решения. Первое – уменьшения детальносности карты на основном листе путём соствление эрахий CJM, когда есть общая, и есть детализирующие каждый этап карты. Второй – согращение масшатаба описания (охвата) с клиентского пути до отдельной услуги, отдельного клиентского сегмента, пользовательского канала в B2C или отдельного пользователя в B2B.
* Совместно с клиентским путём уточныется и процессы – это поможет CJM. Сами процессы обеспечивают работу клиентского пути и являются точками соприкосновения клиентов с сервисами компании. По этим точкам можно восстановить реальный клиентский путь, что клиент предоставляет (например, справки или анкеты) и что в ответ получает (рассылки SMS или Push уведомления), какие дублирующие действия он совершание (например, повторные документы из-за отсутвия единой базы данных). Анализировать процессы можно анализировтаь с помощью пользователей, логов, по налитике или с момощью экспертов систем их обеспечивающих, составляя тараекторию процесса. Логи могут помоч определить минимальное и максимальное время, наблюдение за польователями – взаимодейсвия, по аналитике модели данных – изменение данных. Если уже есть карта процесса – её нужно актуализировать и использоваться как вспомогательный источник информации. Важно сохраянть одинаковый уровень детализации.
* Анализ карты клиентского пути. Разместим проблемы на основе данных о клиентах по оси важности, а на основе данных о компании – по оси сложности исполнения решения проблемы. На основе расположения проблем – приоритизируем: в первую очередь выжные проблемы с простым их устранением, во сторую – важные проблемы с трудной реализацией и в третью – лёкие и менее важные проблемы.
* Дизайн целевого состояния клиетского опыта (TO BE) реализутеся как создание целевой клиентский путь с самого начала со стороны клиента, а не кооректируя начальный. Для этого может применяться мозговой штурм, экспертный совет, анализ решений на рынке, дизайн-мышление.
* Мозговой штурм: сбор любых идей, приоритизация по сложности и эффекту, отбор идей для горизонта планирования начиная с простых и эффективных, далее сложных и эффективных и заканчивая простыми и малоэффективными.
* Дизайн-мышление (творчество) по Герберт Саймон состоит из: определение проблемы, исследование, формирование идей, прототипирование, выбор лучшего решения, внедрение решения и оценка результатов.
** Для анализа конкурентов можно ссылграть роль в пользовательском пути их клиетов или роль сотрудника в их процессах.
* На основе нового дизайна клиентского пути определяются точки касания клиента с будущими сервисами. Эти сервисы обеспечиваются процессами компании. Для обепечения требуемого сервиса определяется набор фукнций, отображаемой в CJM. Теперь, когда определены важные для клиента фукнции необходимо по ним создать диграммы процессов. Их можно создать на BPMN, например, в ARIS. Имеющиеся фукнции необходимо объединить верхнеуровневаой логикой. Сами функции нам нужно детализировать на подроцессы. Для этого, нам нужно поределить, как может быть реализована какая-то фунция, например, с помощью мозгового штурма, и с помощью каких действий, которые могут реализовать информационных систем. Этими система могут быть существующие или созданные заново. Неоходимость реализации новой информционной системы или в рамках сущесвующих информационных систем поределяется доменными компитенциями, так как обычно, имеено по такому принципу объединяются по реализации функции в пучёк. Например, вместо заказа в офисе банковской карты мы решили предоставить возмоность это сделать через голосового помощника. Предположим, что у нас нет компетенции в машинном обучении, то для реализии данной функции будуте сформирована новая система машинного обучения. После формального описания необходимо проверить показатели нашего дизайна и для этого хорошо подходит прототипирование. Далее необходимо опрделить качество сервисов, стоимость автоматизации, квалификацию персонала, необходимое оборудование и производительность. Для этого тестируется прототип на реальных пользователях и принимается решение о внедрение, автоматизации и тому подбного.
Cогласование клиентского пути и процесса. Если готовность оказалась достаточно, презентуется Владельцу клиентского пути и Владельцам процессов с помощью короткой презентации для его валидации, выделения ресурсов и чтобы заручиться поддержкой заинтересованных сторон. Необходимо донести решаемую проблему, привести реальные примеры этих проблем, GAP нанализ AS IS и TO BE, дорожную карту внедрения на горизонты эксперементальной длительности (Fast to-be), среднесрочного (To-be) и долгострочного (Dream), покажите результы горизонтального прототипирования на пользователях и вертикального прототипирования технологического стека. Входе презентации необходимо зафиксировать принятые решения (выделение ресурсов) и замечания.
* Пилотирование разработанного клиентскаго пути. Для крупномасштабных изменений, сложнообратимых изменений, рискованных или дорогостоющих изменений необходимо предваритлеьно создние пилотного проекта, который продемонтрирует работу на небольшой части компании или части клиентов. После получения данных пилотирования их необходимо добавить в презентацию. Необходимо провести встречи с заказчиком, спонсором, владельцем клиентского пути и владельцами процессов. На этой всечи моно получить оценку метрик и успешности пилотирования. Эти данные можно добавить в презентацию.
* Внедрение пропилотированного целевого клиентского пути. На этом этапе нужно составить план внедрения. Внедрения можно проводить локально (волнами), в порядке увеличения критичности или уменьшения лояльности к измеениям, или крупномасштабно, и через полную замену, частичную замену или параллельно работающим системам. Эта стратегия внедрения зависит от ресурсов, вермени, влияния на текущие процессы и необходимой оперативности внедрения. Когда план готов, нужно найти добровольцев – для этого нужно проводить презентации с планом внедрения, влиянием на текущие процессы, необходимые ресурсы и результатом пилотирования. Результаты проведения этапа (волны) внедрения включаются в презентации и набирается статистика их измееннения со временем. Постоянный котроль и ведения статистики по ключевым метрикам является хрошей практикой. В последующи волнах демонтсрируются результаты по предыдущим.
Сам путь – это последовательность использования услугами, которые могут быть сгруппированы в продукты. Услуга – то что видет клиент. Для предоставления услуги необходимо совершить бизнесу определённые действия, которые не видны пользователям, но он видит их результат на своём пользовательском пути. Например, пользьзователь обращается в банк, он заполняет анкету и дожидается оценки его кредитоспособности. В случае его положительного результата, он общается с менежером, ему формируют кредитное предложение. После чего он дожидается кредитной карты и может пользоаться кредитными средствами. Для пользователя не заметны услуги по посещению офиса банка (банк проводит работы по рекламе, по ареднде до того как пользователь зашёл в офис). Дальше проверялись и запрашивалсь данные, провоидился кредитный скоринг по прогнозированию, после чего была выставлена рейтинговая оценка. Далее проводилиьс оперции по предоствлению средств и выпуск карты, для предоставления самого кредита. Повторяющиеся для разных пользователей такие действия называются процессами, а логика, по которым они предоставляются – безнес логиковй. Процесс – вид на взаимоотношения с клиентом со стороны бизнеса. Процессы разделяют на бизнес процессы (для внешнего клинета), поддерживающие процессы (для внутреннего клиента) и управляющие процессы (для раоты компании). Все процессы помещаются в реестр процессов и составляют бизнес ландшафт бизнес слоя. Этот слой оперирует и другими сущностями, такими как потребности, терриритор присутствие и другими. Сами процессы состоят из унифициронного набора операций, которые обеспечиваются функциями контертных программ. Проектированием клиентских путей, безнес процессов и операций занимается бизнес архитектор.
Этапы пользовательского пути:
* формирование потребности: это можеть реклама товара;
* принятия решения: выбор решение удовлетворения потребности;
* приобретение услуги: сам процесс оказания услуги (продажа или оказание услуги);
* послепродажное обслуживание: получение отызва, гарантия, исправление продукта.
Важно заметить, что тут нет ни производства, ни процессов компании – всё это на остороне обеспечения.
Клиентский путь обязателько связан, как минимум:
* с его владельцем клиентского пути, которые отвечает за него;
* с подразделение (депортамент), в рамках которого он обеспечиваестя;
* с продуктом (сервис), для получения которого прользователь проходит пользовательский путь;
* с процессами (процессом), которые обеспечивают возмозможность пользователя пройти по пользователькому пути.
Клиентские пути детализируется на ландшафте клиентского пути (Customer Journey Landsсape, CJL). Ландшафт клиентского пути связывает каждый из шести этапов клиентского пути с услугой, предосталяемой на этом этапе. Перечислим этапы клиетского пути: узнавание, расмотрение, приобретение, использование, рекомендации и закрытие услуги. Этап клиентского пути с оказываемой на неё услугой, детализируется на карте клиентского пути (Customer Journey Map, CJM). CJM позволяет найти узкие места в клиентском пути с помощью визуализации от лица пользователя. Карта клиентского пути детализирует по двум векторам: детализация этапа на подэтапы колонки, стаканы) и детализацию услуги (строки, дорожки) по качествам. Примером этапов может быть: формирование потребности, выбор решения, покупка решения, обслуживаение решения. Между покупкой решения и обслуживаением решения нет использование решения, так как мы указваем не действия клиента, а его взаимодействия: реклама, выбор, покупка, гарантийное обслуживание. Строки сгруппированы на описание компании, на описание клиента и описания взаимодействия клиента и компании. В зоне клиента указываются его параметры и его действия (цели, ожидания, потребности, сложности), в зоне компании – парметры компании (возможности, проблемы, процессы, ретабильность) и её действия, а в зоне взамодействия – эффект взаимодействия (решение проблемы, формальное выполнение обязательств, рациональная и эмоциональная оценка клиента). Так, если взаимодействие не стало успешным, то нужно сравнить прараметры клиента и компании, на сколько они соответствуют друг други, например, ожидения клиента и предложения компании. Так моно будте или ссузить и изменить польльзовательский сегмент или подстроить процессы под клиента. Конкретные строки запоняются теми данными, где есть проблема и необхоидимо принять решение. Если решение уже найдено и нет больше необходимости контролировать результат – строки убираются или заменяются на другие. Строки и столбцы образуют клетки. В каждую клетку може быть пемещён один или несколько стикеров, но так, чтобы CJM можно было ихватить одним взглядом. В стикер помещается ниболее ёмкие представление смысла. Стикеры горизонтально выравнивают и групируют, например, точка и канал (тип интерфейса взаимодействия с пользователем) один, а целей у клиента несоколько, тогда под ними распологиют соответсвующие этим целям целевые действия. Сама карта может быть выполенена в различных системах (например, в ARIS или Miro) или на магнитной достке. В строках CJM указываются важные факторы взаимодействи пользователя с улугой, например:
* точки взаимодействия, например, менеджер, продавец, офис;
* каналы взаимодействия, например, электронная почта, мобильное приложение, телефоный разговор, сеть продажи и другие, спам;
* цели клиента, например, покупка, аренда и другие;
* целевые действия, например, произведена оплата;
* потребности пользователей, например, в связи, в развлечениях, в иде;
* недостатки, например, долго, непонятно, некачественно;
* процесс, например, действия, компании по предовтавления улслуги, например, процесс продажи;
* оценка, например, полжительная, нейтраяльная, жалоба;
* возможности улучешия, например, ускорение, индивидуальный поход, автоматизация;
* KPI, например, средний чек, время обслуживания, длительность этапа, удовлетворённость клиента;
* ответсвенный за бизенс процесс.
Поговорим о каналах. Каналы коммуникации: устное общение в офисе продаж, телефонный контактный центр, чат, сайт, социальные стети и остановимся подробнее на
* электронная почта (дёшево, неконфедециально, ненадёжно в случае со спам-фильтрами, можно отверстать страницу и добавить вложения),
* Push-уведомления (дёшево, конфедициально, требует интернета, Сервисный Push поддерживает сценарии и чат),
* SSM сообщение (высокая вероятность прочтения, быстрота оповещения, высокая стоимость рассылки),
* традиционная почта (официально, долго и дрого).
Классификация:
* сервисные сообщения – информировнии об статусе его клиентского пути;
* персональные предложения – рекомедательные сообщения, о рекомендательных система в книге по ML.
Коммуникация с клиентом:
* соотносите аудиторию и канал, так наврядли увемолять о пенсиях стоит через модные push-уведомления;
* не спамьте людей не относящейся к ней и не актуальной информацией;
* кроме самой информации нужна информация, где можно уточнить и получить разъяснения;
* старайтесь сделать понятным и анализируйте это, например, избегайте таких терминов, как оферта;
* доносите актуальную информацию, так не забывайте уведомлять клиентов о стутусе их клиентского пути;
* ведите переписку сквозь все каналы, так чтобы по поводу push-уведомления рассказали в чате нужно объединить базу данных компании;
* контролируйте "состояние" клиентского пути, так если клиент уже купил разовую продукцию, то не стоит ему предлагать альтернативы.
* стиль коммуникации зависит от коанала и должен соответвовать клинету, так поисковый сервис для всех людей не может позволить свобыды которая допустима для музкального сервса для молодёжи;
* информируйте заранее, например, что очередной платёж по услуге нужно оплатать;
Упраление коммуникацией:
* Coll-центры исользуют скрипыт коммуникации.
* Можно использвать шаблоны и стандарты коммуникации.
Поговорим о подготовки пользователького пути к реализации. User Story – описание пользоательского пути от лица пользователя на языке потребностей. Решение создаётся при проектировании – иначе это ограничит архитектора и нацелет его не на решение проблемы. В качестве дополнительной информации может быть указан пользовательский сегмент, причина этих потребности. Описание User Story вносят в карту User Story Mapping, постепенно детализирую. Постепенность позволяет детализировать только те факторы, которые не меняются со временем. Список важных зараетериситк истории в INVEST (Independent, Negotiable, Valuable, Estimable, Small, Tetable).
Бэклог продукта – упорядоченные по приоритету требований продута для их реализации одно или несколькими камандами. Требования оценивается в ценности для клиента и трудозатрах команды. Более приоритетные имеют большую проработку и детализацию, а менее приоритетные – меньшую, чтобы постепенно детализироваться и прорабатываться не сильно устаревая. Приоритетность пределяется по стоитмости задержки в поставке ценности, критичности, наличию рисков, ценности для клиента на трудозатраты командой для её поставки. Чтобы было проце – делают таблицу по ценностям и их парамтерам.
Детализация User Story для добавления в бэклог может производиться разными способами. Важно, что деля пользовательский путь для того, чтобы уложиться в спринт, её части приносили ценность клинету, для этого есть несоколько способов. Перечислим их:
* выдлением минимального варианта ценности,
* по сегментам пользователя (для осведомлённых, для всех),
* по каналам сбыта или интеграции с внешними системами (оплата по дной карте, оплата по друм картам),
* по критериям приёмки (простое поле, поле с проверкой),
* по степени атоматизации (ручной, полуавтоматический, автоматический),
* по функционалу (базовый – ввод текстом, простой – ввод из списка, функциональный – ввод из календаря),
* по сложности реализации (оплата по помощью плагана, оплата с помощью неподдерживаемых плагинов карт),
* по оптимизации (медленный алгоритм, оптимизированный, масштабируемый),
* по шаблонизации (реализация взятая у конкурентов, своя реализация).
Мы уже говорили, что клиентсукий путь связан с процессом или процессами, которые его обеспечивают. Процесс может быть очень большим, поэтому его, в случае необходимости, описываю на различных уровнях детализации. Так, процесс может быть представлен несколькими действиями, понятными пользователями. Каждое такое действие емеет свою детализацию на его диаграмме процесса. Количество слоёв не ограниченно.
Владелец клиенсткого пути отвечает, уаправляет и контролирует клиентский путь, а принеобходимости изменяет его вместе с владельцами процессов, добавляя, убирая или изменяя процессы. Таким образом, владелец процесса должен обеспечить положительный клиенсткий опыт прохождения клиенсткого пути и результат. Владелец клиентского пути по карте клиентского пути видит может проводить аналитику. Например, на карте клиенского пути этапа приобретения он видит два подъэтапа (стакана): заказ и оплата, при этом для стакана оплата в дорожке "удовлетворённость" показатель ниже, чем остальных подъэтапах, а в дрожржке "недостатки" – отсутвие оплаты с помощью банковской карты. На основе этого, примается решения добавть в процесс оплаты дорожки "процесс" возмоность оплаты с помощью банковской карты, добавлением условия и действия оплаты по банкоской карты. Данное действие раскрывается на подроцесс, но этим уже занимается владелец процесса.
Для редизайна можно вопспользоваться досками, MS PowerPoint, MS Excel, FIGMA, UXPressia, Google Table, Miro.com и другими. Я воспользуюсь online сервисом досок https://miro.com/, а имеено доской клиентских путей. Нужно зарегистрироваться и перейти на страницу дашбордов: https://miro.com/app/dashboard/. Выбрав определённый дашборд и пригласить других участников изменения клиентского пути. Я вибиру шаблон Product RoadMap и создам доску. Можно выбрать и другие шаблоны: Kanban Framework (для упраления поточной разработкой задач), Business Model Canvas (моделирование устройства компании), Customer Journey Map (карта клиентского пути), Fishbone Diagram (диаграмма Исикавы для отображения дерева причин события) и многие другие. Я выбиру шаблон Customer Journey Map – с ним идёт видеоурок, как пользоваться этим шаблоном.
Посмотрим на фреймворк Customer Journey Map с точки зрния применения как интрумента для редизайна. Customer Journey Map – популярный (67% по иследованиям) инструмент в крупных компаниях систематизиции информации, аназиза от лица клиента текущего клиентского пути и отслуживания его изменения для пользователей. Это достигается визуализацией показателей взаимодействия клиента с компанием через интерфейсы его сервисов на одной странице, чтобы видеть картину в целом. Например, можно увидеть, что клиненту нужно указывать свои данные при регистрации в мобильно приложении и при отправке обращения одни и теже, при этом это реальный случай в первых версиях мобильного приложения ведущей в совей области компании. Также можно разделить пути по каким либо праметрам, например, по пользовательским сегментам и каналам и выявить, что пользовательский канал интернет сайт слишком сложне для основной пользовательской групппы. Клиент взаимодействует только с интерфейсами услуг, то они на сколько успешно он провзоимодействовал и определяет успешность клиентского опыта. Регулиря показатели этих взаимодейсвий через подстройку сервисов мы можем менять клиентский опыт. Так как сервисы являются обеспечивающим уровнем, то компания может на них влиять напрямую и через них на клиентский опыт. Анализируя всю карту можно увидеть узкие места – выпадающие по оценкам пользователей сервисы и сосредоточиться имеенно на них, так как устранение узкого места позволить устранить узкое горлышко в клиентском пути и увеличить поток на количество пользователей, которые не преодолели это узкое место. Для этого, нужно, чтобы характеристика контакта клиента с его интерфейсом была релевантна и отображала значимые для пользователей параметры, например, цена или неудобноство использования канала, вложность клиентского пути. При этом, характеристики нужно подбирать такие, которые выявляют проблемы, например, для определённого сегмента цена не является решающим показтаелем, а вот скорость прохождения – критически важным, например, чтобы уложиться в сроки заданные регуляторными органами. Эти знания позволяют определить возможности для улучшения одних показателей за счёт других для выравнивания клинтского пути или же улучшение показателей по мере приближения к целевому действию, так как стоимость лида (привлечения пользователя) увеличивается по мере ссужения воронки. Со временем данные уточняются и интрумент подстраивается к особенностям бизнеса. Это связанно с достоварностью и охватом данных.
Для разработки и использования Customer Journey Map потребуется собрать информацию, её проанализировать и систематизировать, нарисовать карту, проанализировать карту. Источником информации являются клиенты: их отзывы, отношения.
CJM должне быть достаточно детализированным, чтобы в нём находить узкием места и точки роста. Этапы CJM могут охватить жизнь продукта, но только, если он небольшой. Чтобы не описывать различные каналы, можно под каждый канал создать свой CJM и детализровать продукт на даиаграмме окружения продукта в ARIS на несколько диаграмм CJM. В случае большого и сложного продукта, непосредственно детализровать продукт в ARIS приведёт к дублированию (каналы разные, а остальные этапы одинаковые) и большим диаграммам (важно, чтобы CJM помещался на один экран). Чтобы разбить жизненный путь на множество отдельных используестя CJL, которая содержит как и единый CJM продукта его основные этапы. На CJL отображаются этапы и сервисы, предоставляемые на них. Уже сервис детализируется на CJM.