Историческая справка и назначение метода
Этот раздел можно легко пропустить, если у вас нет сомнений, что метод будет полезен в вашей практике. В ней рассмотрены предпосылки появления, связь с другими подходами и отличительные черты. Кроме того, обрисовано местоположение метода в общем процессе проектной и продуктовой деятельности. Если всё упомянутое навивает на вас скуку, смело переходите к первой главе.
Генезис
Корни метода уходят на пятьдесят лет в прошлое. Предтечи можно разбить на несколько направлений. Подходы к схематизации процессов развивались параллельно в сферах поточного производства в машиностроении, в разработке программного обеспечения и в сфере услуг.
Ниже приведена хронология основных вех в развитии методов схематизации вычислительных, производственных и прочих хозяйственных процессов. Приведены даты появления, названия ключевых диаграмм или методов и важное новшество, что они привнесли.
Хронология основных ветвей развития методов моделирования процессов и схематизации опыта
Ветка схематизации процессов в сфере информационных технологий
– 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 не доставало, – это соединения построенной карты с тем, что мы собирались как проектировщики системы разрабатывать для обеспечения этого опыта. Карта 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).
Фаза проектирования и реализации.