Моделирование процессов и сервисов

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

Что это даёт в реальной работе

Согласует as-is и to-be между бизнесом, операциями, IT и поддержкой.
Показывает handoffs, очереди, роли, статусы и исключения.
Помогает связать процесс с инструментами: workflow, CRM, системой обращений, базой знаний.
Даёт основу для требований, тестов, SLA и мониторинга.

Ключевые подходы

Подход / источник	Как использовать	Ограничение
BPM CBOK	как профессиональную рамку BPM: процессное мышление, роли, governance, улучшение	официальный открытый источник сейчас указывает BPM CBOK 4.0; для 3.0 нужен материал пользователя
BPMN / OMG	как нотацию событий, задач, шлюзов, потоков, пулов и дорожек	BPMN не показывает клиентский опыт сам по себе
ELMA BPM	как русскоязычный вход в BPMN и исполняемые процессы	документация вендорская, не нейтральный стандарт
Михаил Рыбаков	как практический взгляд на описание, отладку и внедрение бизнес-процессов	для глубокого конспекта нужен полный текст книги: `source_required`
Остервальдер и Пинье	как слой бизнес-модели вокруг сервиса: value proposition, segments, channels, partners, costs	canvas не заменяет процесс и архитектуру
UML	как набор диаграмм для use cases, sequence, state, class/component-level reasoning	UML легко переусложнить
Desfray / Raymond	как практическую связку TOGAF, UML и BPMN для enterprise modeling	сохранена source card SJM Source - Desfray TOGAF UML BPMN 2014

Справочный слой

Материал Desfray/Raymond полезен как мост между бизнес-процессом, системной моделью и архитектурным представлением. Для сервисной модели это означает: один и тот же сервис нужно показывать несколькими видами, потому что клиент, поддержка, операционный владелец, аналитик, архитектор и риск-функция отвечают на разные вопросы.

Как выбирать представление

Представление	Когда использовать	Что не подменяет
SJM / service blueprint	нужно связать клиентский путь, backstage, support processes и experience	не заменяет исполняемый процесс
BPMN	нужно описать поток процесса, события, задачи, шлюзы, роли, сообщения и исключения	не показывает ценность и эмоции клиента
UML use case	нужно описать цель пользователя и границы системы	не заменяет backlog и критерии приёмки
UML sequence	нужно разобрать взаимодействие систем, API, очередей и handoffs	не заменяет интеграционный контракт
UML state	нужно зафиксировать статусы заявки, обращения, операции или инцидента	не заменяет SLA и правила ownership
Architecture viewpoint	нужно показать систему глазами stakeholder: поддержка, IT, compliance, risk, operations	не заменяет фактические данные production

Traceability для сервисной модели

Полезная цепочка выглядит так:

flowchart LR
    A[SJM step] --> B[BPMN task/event]
    B --> C[UML interaction/state]
    C --> D[Architecture decision]
    D --> E[Test oracle]
    E --> F[Monitoring/support evidence]
    F --> A

Такой traceability-контур помогает не потерять изменение: если меняется статус в CRM, должны обновиться SJM, BPMN, state model, тесты, KB и мониторинг.

Как применять в сервисной модели

Начать с простого описания сервиса словами.
Разделить клиентский путь, внутренний процесс и системную обработку.
Для стабильного повторяемого процесса использовать BPMN.
Для клиентского опыта и backstage использовать SJM / service blueprint.
Для сценариев взаимодействия с системой использовать use cases или user stories.
Для состояний заявки, обращения или операции использовать state model.
Для интеграционного сценария использовать sequence diagram.
Для бизнес-контекста проверить Business Model Canvas: ценность, канал, клиентский сегмент, партнёры и cost structure.
Для публичного Digital Garden использовать garden-ready схемы из BPMN процессы — индекс: Markdown + Mermaid как основной слой, Canvas как редакторскую карту.

Связь с SJM

SJM отвечает на вопрос “как сервис доставляется клиенту и организацией”. BPMN отвечает на вопрос “как течёт процесс”. UML помогает описать отдельные системные и сценарные аспекты.

Задача	Лучше подходит
Понять клиентский путь и backstage	SJM
Зафиксировать поток процесса и роли	BPMN
Описать сценарий использования	Use Case / User Story
Показать взаимодействие систем	UML sequence
Показать статусы обращения или операции	State diagram
Проверить ценность и экономику сервиса	Business Model Canvas

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

Процессная модель должна отвечать:

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

Практический чек-лист

У процесса есть старт и завершение.
Указаны роли и владельцы этапов.
Есть отличие frontstage и backstage.
Указаны основные статусы.
Есть негативные ветки и исключения.
Указаны системы и handoffs.
Есть связь с метриками и SLA.
Есть правило обновления модели после change request.

Ограничения

Не подменять сервисную модель нотацией.
Не рисовать BPMN, если достаточно таблицы SJM.
Не использовать Business Model Canvas как описание процесса.
Для BPM CBOK 3.0 и книги Рыбакова полный материал пока не предоставлен: source_required.