Карта процесса-опыта. Проектирование услуги через её визуализацию

Почему это следующий шаг в развитии

Авторская практика гибридной нотации в схематизации пользовательского опыта развивалась в течение восьми лет в компании Byndyusoft на проектах её заказчиков и обросла собственными особенностями. Когда мы говорили, что используем свою версию CJM, то слышали вновь и вновь: «Нам нравится ваш метод», – а следом: «Это что-то другое». Из разговоров с коллегами по компании и отрасли стало понятно, что получилось развитие метода и сто́ит это отметить и закрепить отдельно. Метод получил имя и описан в этой книге в формате методических инструкций.

Метод назван «Карта процесса-опыта», или на английском Experience—Process Mapping (коротко: XP Mapping, XPM), потому что он соорганизует внутренние процессы и пользовательский опыт.

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

– Как снизить разрывы в логике процесса и всячески улучшать опыт и впечатления человека в работе с сервисом – ориентация на человека, позиция UX.

– Как выстроить работоспособную машину сервиса с помощью имеющихся инструментальных технологий – инженерная позиция.

– Как обеспечить максимум потребительской ценности при минимуме затрат – предпринимательская позиция.

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

Что не устраивало в CJM, Service Blueprint и BPMN

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

Заказ и доставка пиццы. Схема классического CJM

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

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

Заказ и доставка пиццы. Схема Service Blueprint

Схема Service Blueprint была ближе к тому, чтобы строить чертёж сервиса, однако в нём не доставало важных элементов, которые были сильной стороной CJM. Сила схем типа CJM и User Story Mapping (Паттон, 2014; Шапиро, 2019) в том, что к каждому элементу карты пристыковывалась масса информационных слоёв. Как раз эту особенность нам захотелось сохранить и совместить её с дорожками и взаимодействиями между разными исполнительскими слоями сервиса из схем типа Service Blueprint.

Заказ и доставка пиццы. Схема взаимодействий в нотации BPMN из спецификации BPMN By Example

BPMN – прекраснейший язык моделирования процессов, схемы которого имеют возможность быть машинно-запускаемыми. Однако порог входа в его нотацию крайне высок. Количество элементов, их модификаций, нюансов, которые нужно изучить, требуют годы практики. Мой личный опыт составления BPMN-схем показывает, что BPMN требует существенного замедления при моделировании. Чтобы сделать шаг в процессе, нужно думать о форме организации его в схему, потому что вариантов крайне много. Это недопустимая роскошь в тех случаях, когда вам нужно зафиксировать процесс в присутствии группы людей. Когнитивная нагрузка на составителя при групповой работе максимальная, групповая динамика низкая – люди скучают, не говоря уже о том, что их нужно учить сложной нотации.

Ещё одним немаловажным аспектом для проектировщиков взаимодействия является отсутствие места для отображения мыслей, решений и впечатлений человека во всей этой махине процесса. Да, в нотации BPMN (OMG, 2010) есть соглашения о моделировании хореографий (Choreography Modeling Conformance) и коллабораций (Collaboration Modeling Conformance), с помощью которых можно проектировать взаимодействие, но мой опыт показывает, что их используют крайне редко. Де-факто нотация прекрасно подходит для системных аналитиков и технологов – тех, для кого процесс-механизм состоит главным образом из «железок».

Заказ и доставка пиццы. Схема в нотации Карты процесса-опыта

Я объединил сильные стороны, понятия и элементы нотаций CJM, Service Blueprint, BPMN и некоторые элементы системо-мыследеятельностной методологии. Всё это соединено вместе и припудрено видением того, что важно, а что вторично в проектировании процесса. На мой взгляд, схемы Карты процесса-опыта получаются ясными и лаконичными, сохраняя необходимую подробность. Сравните сами со схемами других подходов, приведённых выше.

Назначение и отличие метода

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

– в общих чертах или углублённо схватить механику процессов в деятельности;

– добиться согласованности во внутренних процессах;

– и пристально рассмотреть места стыков механизмов системы с живыми участниками, будь они потребители или её служащие.

Главными отличительными чертами метода являются:

– минимум элементов нотации, что снижает порог входа;

– абстракция ключевой точки, что даёт гибкость в управлении содержанием карты;

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

За границами применимости метода находится описание так называемых ad-hoc-процессов, или ситуативного управления, когда выверенного процесса нет, а действия и взаимодействия могут идти в произвольном порядке со спонтанным выбором средств в каждой ситуации. Для описания таких ситуаций больше подходит нотация Case Management Model and Notation, CMMN (OMG, 2016).

Место метода в цепочке проектирования

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

Ситуации применения разнятся, но чаще всего это возникновение разночтений, отсутствие понимания какой-то части процесса, нежелательных эффектов в нём или отсутствие процесса как такового. За формирование нового или видоизменённого процесса берутся, когда замышляется новострой или некоторый шаг развития в существующей деятельности. До работы с процессом требуется этап фокусировки на целях и способах их достижения. Это этап формирования высокоуровневого замысла и проверка его достижимости на уровне мыслительного эксперимента. Обычно это делают с помощью построения моделей на основе причинно-следственных цепочек. На этой стадии я рекомендую методы Карты гипотез (Бындю, 2023), Дерева гипотез развития (Шапиро, 2021) и подход к программированию деятельности (Щедровицкий, 1999).

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

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

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

Вот основные аналитические этапы в нашем процессе:

Фаза обнаружения продукта.

– Выявление целей ближайшего шага развития и согласование их с гипотезами способов достижения целей. Мы используем Карту гипотез (Бындю, 2023) и Дерево гипотез развития (Шапиро, 2021).

– Выявление основных точек потребительского опыта, процесса-механизма услуги и места систем-инструментов в этом процессе. Используемые методы: Карта процесса-опыта, Event Storming (Brandolini, 2021). Подходят, но имеют перечисленные в исторической справке недостатки: Customer Journey Mapping, Service Blueprint, BPMN.

– Выявление способов действования в разных ситуациях и согласование с ними требований к будущим инструментальным решениям. Используемые методы: User Story Mapping (Шапиро, 2019; Паттон, 2014).

Фаза проектирования и реализации.

Глава 1. Карта процесса-опыта за пять минут

«Карта – это не территория, но если она верна, она структурно подобна территории, и в этом её польза», Альфред Коржибский

1. Зачем и когда делать карту

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

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

Совместная работа над картой процесса-опыта формирует у группы общее понимание проектируемой деятельности. Задача карты процесса-опыта как общего артефакта – объединить и согласовать взгляды разных групп специалистов-предметников о процессах и пользовательском опыте в системе.

Карта поможет, когда требуется:

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

– разрешить проблемы в процессе или опыте конкретных участников;

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

2. Структура карты

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

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

Карта процесса-опыта схематично с её основными элементами

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

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

Две ключевые точки с наборами данных к ним

Каждой ключевой точке на схеме дают смысловое имя и прикрепляют к ней набор важных описательных данных. Состав может варьироваться от точки к точке, однако чаще всего не обойтись без таких данных, как:

– каналы, в которых совершается взаимодействие: очно в офисе, чат-боте и т. д.;

– операции, совершаемые людьми или машинами в этой точке;

– вход и выход – информация, вещи, ценности, попадающие из общего процесса на вход в ключевую точку, и те, что после преобразований появляются на её выходе;

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

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

3. Краткая инструкция по заполнению карты

3.1. Установить границы

До начала составления схемы важно установить ограничивающую рамку и решить:

– какая часть процессов деятельности будет схематизироваться и для чего;

– в каком состоянии будет браться процесс «как сейчас» или «как будет»;

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

3.2. Найти ключевые точки основной линии разворачивания процесса

В самом начале мы мысленно указываем воображаемым пальцем туда, откуда всё начинается с точки зрения изучаемого нами процесса. Для этого задаёмся вопросами: «С чего всё начинается?», «Откуда целесообразнее всего начать рассмотрение?» Ответы на них помогут выбрать первую ключевую точку. Фиксируем её на карте и даём ей имя.

Последовательность точек опыта читателя библиотеки. Только ключевые точки потребителя

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

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

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

3.3. Двинуться вглубь механизма обеспечения требуемого опыта

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

Фрагмент карты с дорожкой библиотекаря, реализующего извлечение и выдачу книги

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

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

3.4. Оснастить ключевые точки подробностями

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

– Какая информация или вещи попадают на вход этой ключевой точки и образуются на выходе из неё?

– Через какой канал происходит взаимодействие людей или потребителя с системой?

– Какие операции участников происходят в этой точке?

– Какие в ней есть барьеры? Что мы предпримем для того, чтобы эти барьеры снять? Барьеры оснащены средствами их преодоления или это дело будущего проектирования?

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

Фрагмент карты процесса курьерской деятельности

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

3.5. Достроить процесс-механизм до конца

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

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

3.6. Поддерживать карту и использовать её в проектировании

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

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