Как построить SJM

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

1. Подготовка

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

2. Построение карты

• Определить этапы пути: pre-service, service, post-service.
• Описать действия клиента.
• Описать frontstage: каналы, интерфейсы, уведомления, сотрудники на первой линии.
• Описать backstage: внутреннюю обработку, маршрутизацию, проверки, ручные действия.
• Добавить support-процессы: операционные команды, методология, контроль, эскалации.
• Добавить системы: каналы, CRM, workflow, справочники, интеграции, мониторинг.
• Добавить условия и ветвления: проверки, развилки, разные статусы.
• Добавить ошибки и исключения: отказ, недостаточно данных, сбой интеграции, просрочка SLA.
• Добавить метрики: время этапа, доля ручной обработки, ошибки, повторные обращения, эскалации.

2.1. Сквозной проход по карте

После описания основного пути отдельно пройти карту по сквозным слоям:

• evidence: интервью, логи, жалобы, транзакции, QA и инциденты;
• handoffs между каналами, командами и системами;
• third-party dependencies и fallback;
• accessibility-checks для критичных touchpoints;
• privacy / data touchpoints;
• compliance checkpoints с источником и юрисдикцией;
• customer harm risks;
• service recovery после отказа или деградации.

Для контрольных вопросов см. SJM — accessibility и inclusive design и SJM — privacy, compliance и customer harm.

3. Валидация

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

4. Улучшение

• Выявить bottlenecks: ожидания, ручные передачи, очереди, неочевидные зависимости.
• Выделить quick wins: текст уведомления, видимость статуса, простая маршрутизация, устранение дублей.
• Выделить системные изменения: интеграции, workflow, роли, правила SLA, изменения сервисной модели.
• Определить ответственных за изменения.
• Согласовать финальную версию и статус карты. Для версионирования см. Статусы SJM-секций.

Минимальный рабочий цикл

1. Черновая карта.
2. Валидация с участниками.
3. Уточнение исключений.
4. Добавление метрик.
5. Согласование решений.

Governance

Перед использованием карты как рабочего артефакта зафиксировать режим as-is, target-state или incident-review, владельца, дату проверки и триггеры пересмотра. См. SJM — governance и lifecycle карты.

Вывод

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