Наверняка у многих бизнес-аналитиков есть цель использовать особые артефакты: Impact Map, CJM (Customer Journey Map), USM (User Story Map). Особые, т. к. не так часто они встречаются в бизнес-требованиях, и даже бывалый аналитик может с непривычки растеряться, если не создаёт их каждый день. 

Меня зовут Ирина, я ведущий бизнес-аналитик с более чем пятилетним опытом. Сейчас работаю в X5 Tech в направлении “Цепочки поставок”.

В статье описываю общие принципы построения Impact Map, CJM и USM и вариации их использования не только на примере своих рабочих кейсов, но и на бытовых примерах (буквально на жареной картошке и строительстве дома). Для опытных специалистов разобранные примеры пополнят копилку насмотренности. А для новичков в бизнес-анализе статья будет полезна с точки зрения постижения азов.

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

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

CJM

Смешная таблица со смайликами – CJM – не что иное, как описание сквозного процесса, который у пользователя (или заказчика) вызывает разные эмоции:

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

CJM представляет собой таблицу со столбцами – шагами процесса и строками, фиксирующими для каждого шага:

• роль, выполняющую действие на шаге;

• общую цель с метриками (KPI);

• точку взаимодействия – что именно происходит;

• канал взаимодействия (например, систему, в которой осуществляется действие);

• целевое действие – что именно достигается данным шагом;

• текущие барьеры – что мешает на этом шаге достижению цели;

• текущие эмоции – какую эмоцию этот шаг сейчас вызывает у пользователя;

• точки развития – как можно снять барьер, что изменить на этом шаге;

• изменение KPI – как изменения по точкам развития позволят изменить метрики для достижения цели.

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

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

Важный момент: CJM допускает удаление лишних строк и добавление новых. Это очень удобно, если кейс требует изменение стандартного вида карты. Так, например, может понадобиться избавиться от строки “Канал взаимодействия”, если все действия происходят оффлайн. Вариантом решения может быть объединение столбцов. В случае, если требуется зафиксировать суммарный результат от нескольких изменённых шагов, может потребоваться финализирующая строка внизу.

Приведу свой простой рабочий пример CJM:

В задаче требовалось перенести функционал связки завода с АСЗ (альтернативно-ссылочный завод - совокупность магазинов с одним ценовым сегментом) с техподдержки на бизнес-пользователей. В As-Is, соответственно, бизнес-заказчика ужасно раздражала необходимость составлять и пересылать обращение в техподдерку на каждую привязку, а затем ещё и ждать результата три дня. В данном кейсе CJM сыграл роль подтверждения результата интервью, фиксации проблемы и связки её с решением через обоснование результативности. 

Если перейти на бытовой уровень, то тут CJM может помочь при обсуждении, например, неудобств на кухне. Допустим, супруги спорят про место хранения картофеля, соли и растительного масла в шкафчиках гарнитура. Нужно доказать, что хозяйка в процессе приготовления блюд много перемещается за нужными ингредиентами и инструментами, что неудобно (тратит время и силы, да и картошка регулярно подгорает). Соответственно, если разложить процесс приготовления конкретного блюда по шагам и указать, где именно происходят самые раздражающие действия, то наглядная карта будет ярким аргументом в этом семейном споре:

Итого: CJM помогает показать в бизнес-требованиях, где именно в процессе совсем плохо, а где более-менее, обосновать это и указать, что конкретно на этом шаге можно изменить (точки развития).

USM

USM – инструмент визуализации последовательности разработки пользовательских историй (User Story, US). Иными словами, это карта про приоритеты: 

По науке, USM требует:

• поделить US по ролям;

• для каждого персонажа (роли) выделить эпики (блоки работ), расположив их по уменьшению важности слева направо;

• внутри эпиков выделить активности (более мелкие части блоков работ), также от более срочного к менее значимому;

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

Таким образом, можно определить последовательность выполнения тех или иных US при разработке.

USM – достаточно спорный инструмент для применения бизнес-аналитиком, ведь в идеальном мире последовательность разработки определяет владелец продукта или руководитель проекта с участием команды.

В моей практике USM был несколько раз использован под другим углом зрения. Я столкнулась с задачей о ролевой модели для новой системы. Требовалось описать, как именно будут настраиваться роли и добавляться конкретные права доступа в них. Огромное количество AC (Acceptance Criteria) для каждой US, куда вошли требования службы безопасности и технарей – это взрывало мозг. К тому же всё, что описывалось, было не доработкой, а созданием с нуля.

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

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

Фрагмент готовой USM-карты требований по кейсу:

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

Если разложить такой нелинейный план в виде USM, то описание будет гораздо удобнее, чем простой список дел, ведь наглядно понятно, за что браться первым делом. Да и правки вносить, переставляя «кубики», будет куда проще. Ремонт – место проявления фантазии и новых задумок по ходу процесса. Чтобы лучшие идеи не потерялись, их лучше сразу зафиксировать на карте:

Impact Map

Честно признаюсь, этот инструмент для меня, наверное, самый сложный из трёх. В первую очередь, взявшись за Impact Map (в переводе с английского – «карта влияний»), стоит отличать его от других диаграмм, так как соблазн нарисовать что-то иное, вероятно, окажется большим.

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

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

При этом получается, что левее «Что?» расположено описание «как есть», т. е. As-Is, а «Что?» – это то, что мы можем сделать, чтобы достичь цели лучше, т. е. To-Be.

Impact Map можно прочесть справа-налево: мы (разработчики) можем что-то сделать, чтобы действие конкретной роли более эффективно приводило к нас к цели, достижение которой мы сможем проверить по метрикам.

Такое прочтение наводит на мысль, что для Impact Map важно чтобы:

• это действие (или хотя бы одно действие на всей карте) уже существовало в природе, т. е. выбранная цель уже до нас как-то достигалась;

• вариантов движения к цели и/или ролей должно быть больше одной ветки, ведь иначе у нас в утрированном случае будет только лишь одна строка.

Также из Impact Map можно для каждого «что» построить User Story: «Я как «Кто», хочу сделать «Что», чтобы осуществить «Как» и в конечном итоге выполнилась «Цель».

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

Ещё одна сложность Impact Map – движение ОТ цели и К цели. Долгими тренингами многих из нас учили любое исследование проводить от проблемы. То есть теоретически все понимают, что решить задачу можно разными способами, но по факту строить карту, не записывая решаемые проблемы, – занятие не такое простое.

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

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

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

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

Для обсуждения с заказчиком мне потребовалась визуализация. Я слева расположила цель с метриками, правее указала роли и системы, а за ними блоки действий («Зачем?») и рядом сами действия систем и ролей:

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

Приведу ещё один бизнес-пример использования Impact Map. У меня есть учебный кейс, когда в создаваемой с нуля системе блоки «Как?» прописывались как вновь создаваемые (т. е. ранее этого не было, но согласно концепту, сценарию, теперь будет выполняться), а правее указывались «Что?» в значении «Что для этого потребуется доработать, чтобы пользователь мог выполнить действие «Как?». В таком варианте Impact Map действительно оказался полезным для разработки US.

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

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

В заключение

Что же делать, если артефакт нужен, а задача под него не подходит? Не отчаиваться!

• Даже отсутствие нужного поля приводит к какому-то действию, которое мучает и не оставляет равнодушным заказчика. А если такого шага нет ещё в процессе, то просто узнайте у респондента, к чему ведёт отсутствие нужного поля, как сейчас выходят из положения, что делают, и опишите это в последовательность действий в таблице. Таким образом, CJM хотя бы из пары действий в As-Is всегда получится.

• USM собрать из Acceptance Criteria – также не проблема. Определить, какое AC важней, не столь сложно: сначала описываем саму сущность, затем расписываем, как она действует в зависимости от условий («если – то»). Если User Story хотя бы 5, то распределить их в классическом представлении USM будет вполне обоснованным применением.

• Impact Map в самом простом виде может иметь и одну веточку от цели. Важно не потерять все варианты решений, действительно провести исследование, есть ли другие пути по достижению цели, и кто ещё может оказывать на неё влияние. Проверка связи справа налево от изменения до цели очень помогает отсекать действия, которые для достижения цели не пригодятся.

Важный момент: не ограничивайте себя в желании экспериментировать. Если в CJM есть "лишняя" строка, то можно легко от неё избавиться. Если есть идея структурировать USM ещё как-то, дерзайте. Да и Impact Map, в целом, можно использовать в разных ситуациях, хотя и более ограниченно, чем CJM.

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

Коллеги, буду рада вашим кейсам в комментариях, давайте поможем друг другу.