Почему не только ArchiMate
Я не агитирую использовать только одну нотацию. Посмотрите разные подходы, сделайте выводы и применяйте то, что подходит вам.
ArchiMate — сильная вещь, но чаще ближе к разработке, бизнес-анализу и системному анализу. Поэтому не всегда ее удобно рекомендовать всем участникам команды, особенно если вы хотите быстро объяснить ситуацию стейкхолдерам “простым языком”.
Пример: цифровизация почтового отделения
Чтобы показать механику карты процесса-опыта, рассмотрим знакомый бытовой сценарий — отправка и получение посылки.
В карте есть несколько «дорожек» (swimlanes):
- Отправитель.
- Получатель.
- Сотрудники почты (и иногда сервисы/ИТ-системы).
Важно: мы смотрим на каждую дорожку глазами участника, который проживает этот фрагмент процесса.
Как читается карта
Процесс стартует с точки оформления отправки. Для каждой ключевой точки можно фиксировать:
- канал;
- вход;
- выход.
Например, в точке оформления отправки выходом часто будет квитанция с трек-номером.
Дальше появляются опциональные точки:
- отправитель может уведомить получателя (но не всегда);
- получатель может получить трек-номер по e-mail или в приложении (но не всегда).
Опциональность в КПО отмечается специально — это позволяет показывать ветвления без громоздких «если/то».
Точки синхронизации между дорожками
Есть связка, когда действия двух участников происходят «в одном месте», но описываются отдельно:
- отправитель оформляет отправку;
- сотрудник почты принимает посылку.
Точечная связь между точками показывает, что в этот момент два опыта синхронизированы, но каждый участник проживает его по-своему. Такой подход нужен, если вы хотите «надеть шлем» другого участника процесса — например, сотрудника отделения.
Зачем «надевать шлем» сотрудника
Иногда достаточно описать только потребительский опыт. Но когда вы улучшаете сервис системно, часто нужно разбирать опыт не только клиента, но и тех, кто обеспечивает услугу:
- где у сотрудника перегруз;
- где информация теряется;
- где системные ограничения превращаются в проблемы пользователя.
В учебном примере этот слой показан специально — чтобы было видно, как карта расширяется.
Ключевой фрагмент: оформление доставки и провал UX-логики
На карте есть развилка: получатель может
- прийти и забрать посылку сам;
- или выбрать ветку «оформить доставку»;
В приложении всё выглядит красиво:
Хочешь разобраться, что тебе даст Продуктовый подход?
Выбери, что ближе твоему запросу — и получи 🎁 подарок
- оформить доставку на дом;
- ввести реквизиты;
- оплатить.
Но дальше возникает сбой: пользователь получает уведомления «что-то не удалось», без объяснения причин.
Реальная причина выяснилась уже офлайн: в отделении нет человека, который может выполнить доставку.
Это штатная ситуация — но она не обработана в логике процесса:
- в системе нет корректной диагностики причины;
- нет понятного статуса;
- нет альтернативы («выберите другое время», «нет курьеров — получите в отделении» и т.д.).
Именно такие разрывы карта процесса-опыта позволяет увидеть и разобрать: где интерфейс говорит «всё ок», но процесс физически не может выполниться.
Из чего состоит карта процесса-опыта
КПО строится из дорожек и ключевых точек, но отличается от BPMN.
В КПО:
- нет подробной «операционной» трассировки;
- акцент на узловых точках опыта;
- остаются триггеры, события, ветвления, но без перегруза блок-схемами.
Что такое ключевая точка
Ключевая точка — это узел, который описывается темой (“оформление доставки”, “получение уведомления”), а внутри может содержать десятки действий.
Чтобы точка была полезной, обычно фиксируют:
- Вход / выход: что есть на входе и что должно получиться на выходе.
- Каналы: приложение, сайт, e-mail, бумажная квитанция — и где возможны разрывы.
- Действия: что делает человек или система в рамках точки.
- Барьер: что мешает прохождению точки (например, “некем доставить”).
- Средства: что нужно создать/купить/доработать, чтобы убрать барьер (например, механизм подбора исполнителя, корректный статус, альтернативные сценарии).
Как строили карту на практике
Чтобы не “зависнуть” на деталях, начали с событий и узлов:
1) Стартовая точка опыта
- Проблемы со здоровьем;
- опционально: выписан рецепт;
- возможный триггер: лекарство закончилось.
2) Поиск лекарственного товара
Здесь сразу всплывают нюансы:
- нужен ли аналог;
- хватает ли дозировки/количества;
- что показывать в карточке товара.
Важно: карта помогает не утонуть в интерфейсных деталях, а зафиксировать «узел», который нельзя выкинуть из процесса.
3) Заказ товара
Затем попробовали перейти на сторону «внутреннего процесса»:
- система/аптека получает входящую заявку;
- начинается сборка заказа;
- возможны барьеры: очередь, нехватка персонала, задержки;
- событие: передано в службу доставки.
На практике специально обозначили: часть элементов — это гипотезы. Карта помогает сделать эти гипотезы видимыми и потом уточнить их фактами.
Где КПО реально применяется
Карту процесса-опыта используют не только UX-специалисты. По опыту автора, полезны она может быть тем, кто работает в зоне discovery и проектирования:
- продуктовые команды;
- дизайнеры и исследователи;
- проектные/продуктовые менеджеры;
- аналитики;
- предприниматели малого/среднего бизнеса (чтобы «расписать и объяснить», как работает механизм).
Частые кейсы применения:
- передача знаний и онбординг
- согласование видения «как работает система»;
- разбор провалов опыта и проектирование улучшений;
- «сборка» единого представления между разными ролями.
Как изучать КПО дальше
Есть несколько путей:
- Методичка (бесплатная): «делай раз, делай два» — самый быстрый старт.
- Книга: для тех, кому важно понять именно мышление и логику КПО.
- Канал/чат; можно задавать вопросы, показывать карты, разбирать вместе.
- Тренинг-практикум: обучение на практике.
Ответы на частые вопросы
Нужно ли фиксировать эмоции (позитив/негатив)?
Можно. Количество слоёв не ограничено.
Но эмоциональная разметка обычно полезна на раннем этапе — чтобы подсветить болевые точки и потом превратить их в барьеры и задачи.
Вход следующей точки всегда равен выходу предыдущей?
Часто да, но не всегда один-к-одному.
Иногда вход/выход пишут отдельно, потому что точки сначала выделяют как “черные ящики”, а связывают уже потом.
Как заставить разработчиков реально смотреть в карту?
Ключ — вовлечение.
Если карту «принесли готовой», она чужая. Когда команда спорит, уточняет и дописывает — она становится их инструментом.
Рабочий приём: если вам сложно «прочитать» чужую схему, пересоберите ее в другой нотации — это заставляет по-настоящему понять материал, а не «пробежать глазами».