Бесплатный фрагмент - Карта процесса-опыта

Отзывы

Михаил Руденко · Консультант по улучшению клиентского опыта, директор ОКБ «Понедельник» · Сфера: Проектирование клиентского опыта

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

Александр Бындю · Автор книги «Антихрупкость в IT» и метода стратегического планирования «Карта гипотез» · Сфера: информационные технологии

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

Григорий Костромин · Директор проектов департамента развития корпоративного бизнеса КИБ, СберБанк · Сфера: корпоративный банкинг

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

Юрий Кузнецов · Разработчик логистических бизнес-процессов · Сфера: транспортная логистика

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

Антон Кожемяко · Основатель Бизнес-ассоциации ТРИЗ, вице-президент MATRIZ Official в России · Сфера: консалтинг

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

Что меня особенно восхитило — автор умудрился уделить на карте внимание принципам, механикам, лежащим в основе сценариев; различить деятелей и функционеров; показать, как раскрываются процессы внутри узловых точек Карты процесса-опыта (тонкие и важные на практике различения понятий).

Видно, что инструмент синтезирован на основе самого надёжного сплава, который только может быть: хорошей теоретической подготовки автора и огромного практического опыта. Инструмент получился мощный, даже прорывной. Овладение им — конкурентное преимущество.

Антон Большаков · Фасилитатор процесса продуктовой разработки · Сфера: информационные технологии

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

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

Константин Полуянов· Дизайнер цифровых продуктов · Сфера: информационные технологии

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

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

Благодарности

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

Отдельно хочу отметить и поблагодарить тех, кто помог мне, где экспертизой, а где искренностью и мужеством признать свою некомпетентность; где мыслью, а где просто присутствием и поддержкой.

Иделю Гизатуллину — за активный интерес к продуктовой аналитике и за его первые заметки о процессе сбора требований, с которых началась архивация знаний. Владимиру Аршукову — за рвение делать ошибки и подаренное вдохновение писать об избитой теме, как мне тогда казалось. Яне Мильбергер — за идею быстрее выпустить книгу о конкретном методе, чем вечность писать бесконечную эпопею о проектировании, за которую я изначально взялся. Александру Бындю — за живой пример, как играючи воплощать в жизнь то, что тебя волнует. Наталье Бондарь — за проницательность в поиске содержания и советы по способу его донесения. Петру Щедровицкому — за призыв отказаться от многоуровневой рефлексии и возвратиться к личной практике.

Большое спасибо всем, кто давал обратную связь по рукописи, спрашивал и разбирался в методе: Денису Бескову, Антону Большакову, Алёне Вальтер, Владиславу Гайфуллину, Егору Гилеву, Владу Головачу, Андрею Дерюгину, Илье Динмухаметдинову, Анастасии Илюшиной, Антону Кожемяко, Юрию Кузнецову, Алексею Кулакову, Илье Мясникову, Оксане Пешковой, Константину Полуянову, Денису Фадееву, Илье Ципельштейну, Игорю Штангу.

Введение

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

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

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

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

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

Набросок карты процесса-опыта на клочке бумаги для системы репетиторства

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

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

Предлагаемый в этой книге метод сформировался из моей личной практики и по меньшей мере пятидесятилетнего наследия в области моделирования процессов и пользовательского опыта. К главным преимуществам метода относятся:

— лаконичная, наглядная схема процесса;

— минимум элементов нотации;

— высокая скорость групповых сессий визуализации процесса;

— гибкость в выборе масштаба схемы;

— пристальное рассмотрение мест взаимодействия людей и сервисов;

— поддержка нелинейного пользовательского пути.

Для кого эта книга

Книга будет полезна специалистам, вовлечённым в проектирование услуги на любом этапе её жизненного цикла. Неважно, цифровая ли это услуга, традиционная или смешанная.

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

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

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

В предметной области сервис-дизайна существует идея карты путешествия пользователя (Customer Journey Map). Однако эти карты делаются настолько по-разному, что найти чётко описанную методику не представляется возможным (Калбах, 2016). Типичные переживания начинающих касаются того, правильно ли они делают эти карты, верно ли выявляются точки опыта. С выходом этой книги оснований для переживаний остаться не должно. В ней представлен метод, раскрывающий и совершенствующий идею карты путешествия пользователя, объединяя её с сильными сторонами подходов к описанию разветвлённых процессов. Подход изложен во всех деталях с пошаговым алгоритмом, что поможет как тем, кто ищет чёткого руководства по линейным картам путешествий, так и тем, кто хочет охватить единой схематизацией все сквозные процессы в своём сервисе.

Структура книги

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

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

Четвёртая глава в подробностях рассматривает основные элементы карты, исключая события.

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

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

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

Предуведомление

Для понимания назначения метода «Карта процесса-опыта» важно уделить пару слов тому, в какой деятельности он возник. Большую часть профессионального опыта я приобрёл в сфере информационных технологий в роли проектировщика информационных систем и дизайнера интерфейса пользователя. Примерами систем, для которых применялся метод, были потребительские и корпоративные веб-сервисы и приложения. Это были веб-сервисы площадок электронной коммерции, приложения для инвентаризации магазинов розничных сетей и настройки особенностей транспортной и складской логистики; мобильные приложения для курьеров, кладовщиков и многие другие.

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

Под аббревиатурой UX (User Experience) скрывается проектирование пользовательского опыта. Эта междисциплинарная область знаний, увы, имеет высокую планку входа для новичков и до сих пор недостаточно стандартизирована и превращена в учебники и справочники. Принято считать, что область проектирования взаимодействия является уделом узких специалистов — UX-проектировщиков. Специалист в этой области достигает зрелости по прошествии десятилетий, что представляет собой непозволительную роскошь в современном мире. Я считаю, что знаниями по проектированию опыта либо должны обладать все в команде, либо специалистами в этой области важно становиться гораздо быстрее.

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

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

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

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

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

Из-за чего метод карты работает? Формально он даёт небольшой набор конструктивных элементов и порядок их выкладывания в схему. Но куда важнее не формальный порядок составления карты, а то размышление, что происходит во время её создания. Как только мы выложили элементы в схему, она начинает что-то утверждать. В этот момент мы впервые получаем шанс отнестись к этому критически и сделать следующий мыслительный шаг. Таким образом, схема становится инструментом мышления проектировщика.

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

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

— осознание потребности потребителем,

— поиск исполнителей потребности,

— коммуникация о понимании содержания потребности,

— исполнение её,

— коммуникация о качестве исполнения,

— распространение сведений об исполнителе.

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

Карта процесса-опыта абстрактной услуги

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

Историческая справка и назначение метода

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

Генезис

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

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

Ветка схематизации процессов в сфере информационных технологий

— 1970, ANSI Flowchart — широко известная нотация блок-схем. Появление стандарта по обозначению ветвления в программах.

— 1997, UML 1.1 — многоцелевая нотация с диаграммами структуры объектов и их поведения, выросшая из объектно-ориентированной парадигмы проектирования и разработки. Схематизация сильна учётом инженерных механик, принятых в разработке программного обеспечения. Наиболее важные в контексте процесса средства: диаграмма деятельности (англ. Activity Diagram), развивающие средства Flowchart и диаграмма последовательности (англ. Sequence Diagram) — прародитель дорожек в BPMN.

— 2008, UML 2.2 — максимальная точка развития UML на текущий момент. После разработчики стандарта перешли к нотации BPMN.

— 2004, BPMN 1.0 — нотация, созданная в кооперации с бизнес-аналитиками и нацеленная на управляемость и автоматизацию бизнес-процессов.

— 2013, BPMN 2.0 — максимальная на 2024 год точка развития стандарта. Объединение потокового и событийного подходов. Поддержка нескольких соглашений о моделировании: процесс, коллаборации, хореографии.

Событийно-ориентированное (англ. event-based) направление

— 1990, Event-Driven Process Chain, Август-Вильгельм Шеер — первый из известных мне методов схематизации процесса, делающий акцент на событиях.

— 2013, Event Storming, Альберто Брандолини — метод коммуникации о процессе, призванный штурмовать проблемное пространство и изучать процесс, состоящий из рекордно малого количества элементов в нотации — шести.

— 2018, Event Modeling, Адам Димитрюк — шаг вперёд от Event Storming с акцентом на моделирование в форме раскадровки с экранами интерфейса.

Потоко-ориентированная ветка

— 1910, диаграммы Ганта — средство визуализации зависимостей, создание сетевого графика как направленного математического графа.

— 1984–1997, деревья текущей и будущей реальности в Теории ограничений (Theory of Constraints, TOC). Подход оптимизации главных потоков в деятельности, направленный на последовательное исключение наибольшего ограничения в тракте поставки ценности.

— 1995, Value Stream Mapping (VSM) — диаграммы схематизации потока ценности, выросшие из Производственной системы «Тойоты» (англ. Toyota Production System) и Шести сигм (англ. Six Sigma).

Ветка схематизации опыта

— 1989, Customer Journey Mapping (CJM), идея схемы предложена в статье Беллом и Земке (Chip Bell, Rom Zemke, 1989).

— 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 давала представление о пользовательском опыте в некотором отрыве от того, как мы его будет реализовывать.

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

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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 2. Построение карты на примере

«Личный пример — не просто лучший метод убеждения, а единственный», Альберт Швейцер

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

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

1. Первые ключевые точки и их превращения

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

Что происходит после? Вероятно, мы вспомним, что человек пришёл для того, чтобы решить свой вопрос, и он попробует как-то об этом рассказать. В качестве следующей ключевой точки напрашивается «Объяснение потребности».

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

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

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

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

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

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

Как только мы убрали название предыдущей точки, карта стала направлять наши размышления на происходящее ранее, до точки «Объяснение потребности». Двигаясь туда в размышлении, мы можем вспомнить, что человеку нужно как-то добраться до салона. А можем пройти ещё раньше и подумать, как он вообще узнаёт про наш салон. Он шёл по улице и наткнулся на него? Такое может быть, если человек давно хотел что-то распечатать и вдруг случайно, идя по улице, увидел вывеску.

2. Фиксация подробностей

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