banner banner banner
Карта процесса-опыта. Проектирование услуги через её визуализацию
Карта процесса-опыта. Проектирование услуги через её визуализацию
Оценить:
 Рейтинг: 0

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


– 1999, появление CJM в версии компании IDEO, внёсшей большой вклад в её распространение.

– 2010, моё знакомство с CJM в версии Usability Lab, начало практикования с этой версией и поиск своих адаптаций.

– 2015–2023, годы практики гибридного подхода CJM с Service Blueprint в версии компании Byndyusoft.

– 2023, Карта процесса-опыта. Осознание того, что метод получил развитие и свои особенности, заслуживающие отдельной публикации. Метод собирает практики CJM, Service Blueprint, уточняет понятие ключевой точки и вводит методические указания по тому, как составлять карты.

Симбиоз схематизаций процесса и опыта

– 1984, Service Blueprint – диаграмма чертежа сервиса. Первый метод, в котором процессы деятельности внутри предприятия совмещаются с опытом потребителя услуги. Появляется понятие линии сервиса (Shostack, 1984).

– 2023, Карта процесса-опыта.

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

Авторская практика гибридной нотации в схематизации пользовательского опыта развивалась в течение восьми лет в компании 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. Карта процесса-опыта за пять минут