Service Journey Mapping — что это такое

Service Journey Mapping (SJM) — это картирование сервисного пути, где рядом с действиями клиента описываются внутренние процессы, системы, команды, условия, исключения и метрики. По смыслу SJM близок к SJM и Service Blueprint, но в рабочей практике может быть более прикладным и менее формальным.

В контуре управления сервисной моделью SJM работает не только для проектирования. Та же карта помогает поддерживать сервис после запуска: объяснять маршрутизацию, проверять готовность поддержки, разбирать инциденты, фиксировать изменения и обновлять базу знаний.

Определение

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

Карта отвечает не только на вопрос «что делает клиент?», но и на вопросы:

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

Чем SJM отличается от блок-схемы процесса

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

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

Сервис под капотом

SJM полезен именно потому, что показывает сервис «под капотом». Клиент видит экран, уведомление, ответ сотрудника или статус заявки. Внутри за этим могут стоять проверки, маршрутизация, антифрод-логика, интеграции, очереди, ручная обработка, QA-контроль и правила эскалации.

Если эти внутренние слои не описаны, команда часто обсуждает только видимую часть сервиса и не видит настоящую причину проблем.

Зачем SJM нужен в банке

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

SJM помогает:

согласовать работу продукта, операций, IT, аналитиков, QA и поддержки;
увидеть расхождение между целевым и фактическим процессом;
подготовить изменения сервисной модели;
проверить готовность CRM, workflow, системы обращений, базы знаний и мониторинга;
связать поддержку и сопровождение с проектной моделью сервиса;
объяснить, почему клиентский опыт зависит не только от интерфейса;
связать изменения процесса с Метрики для SJM и SLA.

Какие проблемы помогает увидеть

ручные разрывы процесса;
задержки между системами;
неочевидные зависимости от команд;
дублирование проверок;
слабые места в поддержке;
несогласованность фронта и бэка;
отсутствие владельца этапа;
отсутствие support-readiness перед запуском;
разрыв между инцидентом, problem analysis и change request;
сценарии, которые работают только в идеальных условиях.

SJM как инструмент сопровождения

После запуска SJM полезна как operational reference:

первая линия видит, где искать статус и как эскалировать обращение;
QA понимает, какие негативные ветки и regression checks обязательны;
владелец процесса видит, какие handoffs и SLA требуют контроля;
IT видит, какие события, логи и monitoring-signals нужны для диагностики;
команда изменений видит, какие артефакты нужно обновить вместе: SJM, BPMN, база знаний, workflow, тесты и коммуникации.

Вывод

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