Модуль 4. Моделирование процессов: BPMN 2.0 + UML (UC/Activity/Class)
Зачем моделировать процессы и что именно должно получиться
Цель моделирования — сделать поведение системы и людей видимым, согласовать термины и границы, выделить узкие места и привязать требования к метрикам времени и качества. На выходе у вас должны быть:
- AS-IS (как работает сегодня) — достаточно детально, чтобы объяснить задержки/ошибки и источники данных.
- TO-BE (как хотим) — со сквозной логикой, SLA, контрольными точками качества данных, разграничением ответственности.
- Перечень изменений (процессных, данных, ролей, ИТ) и быстрых побед (quick wins за 2–6 недель).
BPMN 2.0 для BA: минимальный «набор, чтобы не ошибаться»
Карта символов и когда их использовать
-
Pools/Lanes: пул = организация/система; дорожки = роли/подразделения.
Правило: между пулами — только message flow (взаимодействие); внутри пула — sequence flow (порядок шагов). -
Events:
- Start (обычный, message, timer, signal) — что запускает процесс.
- Intermediate (на потоке или boundary) — ожидание сообщения, таймера, сигнала, ошибки, эскалации.
- End (обычный, message, error, terminate) — чем завершаем.
- Gateways:
- Exclusive (XOR) — ветка только одна.
- Parallel (AND) — ветки одновременно.
- Inclusive (OR) — одна или несколько.
- Event-based — выбор ветки по наступлению события (часто для SLA).
-
Tasks/Subprocesses: atomic task; Collapsed Subprocess (свернутая зона, детализация на другой диаграмме); Call Activity (вызов общего процесса).
Маркеры: loop, multi-instance (пакетные действия по множеству SKU, регионов). - Data: Data Object (временные данные шага), Data Store (стойкое хранилище — DWH, ERP), Message (пакет/файл/событие).
- Artifacts: Annotation (пояснение), Group (логическая рамка).
Четыре частые ошибки (и как исправить)
-
Соединяют пулы sequence-стрелкой.
→ Между пулами только message flow (иначе теряется смысл «кто с кем говорит»). -
Не моделируют ошибки и SLA.
→ Boundary events (timer/error/escalation) на задачах, альтернативные потоки и реакция. -
Схемы-простыни на 200 элементов.
→ Декомпозируйте на subprocesses, держите до ~25 элементов/лист. -
Нет данных на схеме.
→ Всегда показывайте Data Store/Message и ключевые Data Objects.
Как зашивать SLA и узкие места прямо в BPMN
- Timer boundary на задаче «Загрузка логистики (D+2)»: при таймауте → «Сформировать баннер “данные неполные” и заблокировать экспорт».
- Event-based gateway для ожидания одного из событий: «Пришёл флаг промо» или «Истекло 09:30 → идём без промо».
- Пункты контроля качества как отдельные задачи/скрипты: «DQ-проверка полноты ≥ 98%» с исходами «ОК/Fail».
Пример BPMN (AS-IS → TO-BE) для кейса «GM% и закрытие месяца»
AS-IS (фрагмент логики)
Пулы: Финансы; DWH; BI; Логистика; Продажи.
Проблема: лаг логистики D+2; промо отмечается вручную; возвраты попадают задним числом; Excel-сверки.
- Start (timer 1-е число 09:00) в пуле «Финансы».
- Task: «Запросить выгрузки у Логистики и Продаж» → message flow.
- В «DWH»: «Ручная загрузка CSV» → «Свод в Excel» (Data Object).
- Узкое место: «Сверка Excel» (multi-instance по регионам) → частые ошибки.
- End: «Отправить PDF отчёта CFO».
Наблюдаемые узкие места: ручной сбор, отсутствие SLA, ошибки Excel, нет ранних DQ-сигналов.
TO-BE (фрагмент)
- Start (timer 01:00, 07:00, 10:00, 13:00) в пуле «DWH»: «Инкрементальные загрузки».
-
Subprocess «DQ-проверки»: полнота логистики ≥ 98%, согласованность промо, отрицательные продажи.
- Boundary timer 09:30: при неуспехе — message «DQ-Alert» → «Финансы/Коммерция».
- Task «Построить витрину GM» (call-activity общего процесса расчёта).
- В пуле «BI»: «Публикация дашборда» с boundary message «Смена методологии» (эскалация).
- В пуле «Финансы»: «UAT-контроль эталонных SKU» → ветка «ОК/Не ОК».
- End: «Согласовано» + message «Снятие баннера “черновик”».
SLA на схеме: 10:00 — доступность данных D-1; при срыве — баннер и запрет экспорта.
UML для BA (Use Case / Activity / Class): где какая диаграмма помогает
Use Case Diagram — «кто и что хочет»
- Акторы: роли пользователей/внешние системы (например, «Финконтролёр», «Системный аналитик», «ERP»).
- Системная граница: что делает наша «BI-система»/платформа.
-
Связи:
- include — общий обязательный фрагмент («Сверка эталонов» включается в «Утверждение отчёта»).
- extend — опциональная/альтернативная история («Запрос пересчёта за прошлый период» расширяет «Просмотр отчёта» при флаге ошибки).
- generalization — наследование акторов/вариантов.
Практика: Use Case-карта даёт скелет backlog’а; на неё удобно навешивать приоритизацию и области ответственности.
Activity Diagram — «алгоритм и параллельность»
- Подходит для сквозных сценариев с условиями, параллельными ветками, «сигналами» и исключениями.
- Элементы: action, decision/merge, fork/join, object flow, swimlanes (как BPMN lanes), interruptible region (прерывание действия событием).
Пример: «Публикация дашборда»: разветвление на «Прогнать тесты перфоманса» и «Верифицировать роли доступа» с последующим join; interruptible region — если «обнаружено отклонение методологии» → прерывание и возврат в «Актуализировать формулы».
Class Diagram — «словарь домена и связи»
- BA-уровень = доменная модель, без методов, но с атрибутами, типами, кардинальностями и ограничениями (инвариантами).
- Отлично подходит, чтобы согласовать сущности и справочники: Product, Channel, Region, Promotion, Return, SalesTransaction, MarginSnapshot.
-
Покажите:
- ассоциации и кратности (Product 1..* — SalesTransaction *..1).
- агрегацию/композицию (MarginSnapshot состоит из MarginLine).
- обязательность полей (например, Promotion.type — enum).
- инварианты (текстом рядом): «Return.amount ≤ SalesTransaction.amount».
Практика: класс-диаграмма — мост от процессов к данным. Из неё рождается словарь данных и STT-мэппинги в SRS.
Связка «процессы ↔ данные ↔ требования»
- Процесс «Сверка GM%» даёт точки измерения: где считать lead time, где нужны DQ-контроли.
- Доменная модель фиксирует поля и связи для расчёта метрик и RLS.
- Use Case/Activity превращаются в User Stories с AC (Given/When/Then) и в SRS (правила расчёта, NFR).
- BPMN-SLA конвертируется в NFR/алерты/мониторинг.
Практика модуля (что сделать и сдать)
- AS-IS BPMN процесса «Закрытие GM%» (до 25 элементов, 3–4 пула, с Data Store/Message).
- TO-BE BPMN с boundary-таймерами, DQ-контролями, SLA и реакциями.
- Use Case Diagram для верхнего уровня (5–9 ключевых кейсов, include/extend где нужно).
- Activity для «Публикация дашборда и приемка» (fork/join, альтернативы, прерывание).
- Class Diagram домена «Маржинальность» (6–10 сущностей, кратности, инварианты).
- Перечень изменений: процессные (кто что теперь делает), ИТ (автоматизации), данные (новые атрибуты/источники), роли и доступы.
- Список quick wins (см. ниже).
Быстрые победы (quick wins) на базе моделей
- Вынести «ручную сводку Excel» в multi-instance job в DWH, сократив цикл на 0.5–1 день.
- Добавить ранний DQ-виджет полноты и алерты при < 98% до начала рабочего дня.
- Выделить «путь без промо» (fallback в TO-BE) — публиковать «черновик» с пометкой и блоком экспорта до прихода промо.
- Ввести роль-бэйзд доступ по Region/Channel, как видно на Class Diagram → уменьшить согласования с безопасностью.
Риски моделирования и как их снять
|
Риск |
Симптом |
Профилактика |
|---|---|---|
|
Схемы «для красоты», не для решения |
Нет SLA/исключений/данных |
Таймеры/ошибки на диаграмме, Data Store/Message, реакции на нарушения |
|
Неправильные связи между пулами |
Sequence flow через пулы |
Только message flow между пулами |
|
Перемешаны уровни абстракции |
Детали SQL рядом с целями |
Разделяйте уровни: L0/L1 для стейкхолдеров, L2 — для команды |
|
Нет связи с требованиями |
Диаграммы живут отдельно от SRS/Jira |
Ссылки на разделы SRS и эпики, таблица трассируемости |
|
Забыты альтернативы/ошибки |
«На UAT всплыло» |
Всегда рисуйте негативные сценарии и boundary events |
|
Слишком детально |
>25 элементов/лист, никто не читает |
Subprocess/Call Activity, серия компактных схем |
|
Неучтённая безопасность |
Блок на релизе |
На BPMN показать шаг «Review доступа/маскировки», добавить NFR |
Теория «ровно сколько нужно»
- BPMN token-semantics: один маркер идёт по sequence flow; parallel gateway кладёт несколько; join ждёт все. Это важно для корректных ожиданий по времени и блокировкам.
- Event vs gateway: event-based gateway выбирает ветку по факту события, а не по условию данных. Удобно моделировать SLA и конкурентные ожидания («что наступит раньше»).
- Boundary events: «прилипают» к задаче; interrupting прерывают, non-interrupting запускают побочный поток (например, алерт, но основная задача продолжается).
- UML include/extend: include — обязательный общий шаг; extend — опциональная «надстройка» при условии. Не путайте: extend не «вставляет» шаг внутрь, он добавляет альтернативный сценарий.
- Класс-диаграммы vs ERD: BA-класс-диаграмма — про бизнес-сущности, их свойства и связи; ERD — про физическое хранение. Мы начинаем с класса, затем в SRS появляется словарь/мэппинги.
Вопрос–ответ (FAQ)
Q: Что выбрать — BPMN или UML Activity?
A: Если нужны роли/организации и обмен сообщениями — BPMN. Если важна логика алгоритма с параллелизмом и обработкой прерываний — Activity. Часто используем обе: BPMN для «кто с кем и когда», Activity для «как именно течёт сценарий внутри».
Q: Как решить, какой уровень детализации нужен?
A: Начните с L0/L1 (до 25 элементов, без «внутренностей» задач). Детализируйте только больные участки в Subprocess L2. Каждый уровень — отдельный лист.
Q: Где показывать данные на диаграммах?
A: На BPMN — Data Store/Message/Data Object. На Activity — Object Flow (что передаём). В Class — сущности/атрибуты/связи. Ссылки между ними — в SRS.
Q: Как моделировать SLA 10:00?
A: Timer boundary «10:00» на задаче обновления/публикации + ветка реакции: баннер «черновик», запрет экспорта, алерт владельцам, лог для аудита SLA.
Q: Чем обосновать, что TO-BE лучше?
A: Сравните время цикла (lead time), количество ручных шагов, качество данных (DQ break rate), стабильность SLA. Это перекладывается в value case.
Q: Можно ли полностью обойтись Use Case без BPMN?
A: Для маленьких функций — да. Для сквозных процессов с несколькими ролями и системами — нет: без BPMN теряется взаимодействие и SLA.
Мини-шаблоны (перенесите в Confluence/Miro)
BPMN L1 (TO-BE) — чек-блоки на схеме:
- Start (timer/message)
- Ключевые задачи + collapsed subprocess
- Data Store (ERP/DWH/BI), Message
- Gateways (XOR/AND), не злоупотребляйте OR
- Boundary events (timer/error/escalation)
- End (message/terminate)
- SLA/реакции подписаны аннотациями
Use Case — карточка:
- Акторы: …
- Описание: …
- include: … / extend: …
- Предусловия / Постусловия
- Триггеры ошибок
- Ссылки: SRS §, Stories, Тест-кейсы
Activity — каркас:
- Swimlanes (роли/подсистемы)
- Decision/merge с условиями
- Fork/join для параллельности
- Interruptible region с событием прерывания
- Object flows (что передаём)
Class — доменная карта (фрагмент):
- Сущность (атрибут: тип, обязательность)
- Ассоциации с кратностью (1..*, 0..1 и т.д.)
- Инварианты текстом рядом
- Ссылки на словарь данных SRS
Чек-листы готовности
AS-IS готов:
- Пулы/дорожки соответствуют реальным ролям
- Узкие места и ручные шаги явно отмечены
- Показаны реальные источники данных/сообщения
- Есть негативные сценарии/исключения
TO-BE готов:
- Встроены SLA и реакции (boundary/events)
- DQ-контроли и пороги заданы
- Убраны/автоматизированы лишние ручные шаги
- Роли и ответственность (who does what) ясны
- Связи с SRS/Stories отражены
Доменная модель готова:
- 6–10 ключевых сущностей, кратности и инварианты
- Карта покрывает формулы метрик (GM%, promo flag, returns)
- Есть владельцы сущностей/справочников
Итог модуля и «что сделать завтра»
- Нарисуйте AS-IS BPMN и попросите ключевые роли «пройтись пальцем» по схеме — соберите расхождения факта и карты.
- Сделайте TO-BE с явными SLA/DQ/реакциями и спланируйте quick wins.
- Сверху положите Use Case карту, одну Activity для «узкого» сценария и доменные классы.
- Свяжите диаграммы с SRS/Stories и метриками эффекта — чтобы это были не «картинки», а договорённости, по которым команда строит систему.
