Как определить правильность бизнес-процесса в нотации?

Как определить правильность бизнес-процесса в нотации

Бизнес-процессы часто описываются в BPMN (Business Process Model and Notation) или других нотациях. Мне часто требуется проверить правильность этих диаграмм, и у меня есть четкий набор критериев валидации.

1. Синтаксическая правильность

Правила BPMN:

Стартовое событие (Start Event):

• Обязательно одно в начале процесса (или несколько для разных входных точек)
• Не должно быть входящих стрелок (incoming edges)
• Всегда должно иметь хотя бы одну исходящую стрелку

Финальное событие (End Event):

• Должно быть хотя бы одно
• Входящие стрелки есть, исходящих нет
• Каждый путь должен вести к end event

Задачи (Tasks) и деятельность (Activity):

• Каждая задача должна иметь входящую и исходящую стрелку
• Названия задач понятные, глаголы в форме действия ("Проверить заявку", не "Проверка")

Условные ветвления (Gateway):

• Exclusive Gateway (ромб) — одна входящая стрелка, несколько исходящих
• Все исходящие стрелки должны иметь условия (labels)
• Условия должны быть взаимоисключающими и полными (покрывают все случаи)

Пример ошибки:

Если заявка > 1000 рублей -> путь A
Если заявка > 500 рублей -> путь B

Проблема: пересечение условий! Заявка 700 рублей подходит под оба.

Правильно:

Если заявка >= 1000 -> путь A
Если 500 <= заявка < 1000 -> путь B
Если заявка < 500 -> путь C

2. Семантическая правильность

Логика процесса должна соответствовать реальности:

Последовательность задач:

• Порядок действий должен быть логичным
• Нельзя использовать результат до того, как его получили

Пример ошибки:

Утвердить заявку -> Проверить документы -> Уведомить клиента

Проблема: утверждаем, не проверив? Неправильный порядок!

Правильно:

Проверить документы -> Утвердить заявку -> Уведомить клиента

3. Полнота процесса

Все возможные пути должны быть описаны:

• Если есть условное ветвление, все ветви должны быть описаны
• Должны быть обработаны исключительные случаи (ошибки, отказы)
• Все пути должны вести к end event (нет "зависаний")

Правило: каждая стрелка должна вести либо к новой задаче, либо к end event. Нет стрелок в никуда.

4. Проверка на dead-lock и infinite loop

Dead-lock: путь, который приводит к зависанию (нет выхода)

Пример dead-lock:
Задача A -> Условие -> Если да, вернуться на Задачу A
(без условия выхода)

Бесконечный цикл: процесс никогда не заканчивается

Правильно:
Попытка 1 -> Если ошибка -> Попытка 2 -> Если ошибка -> Отклонить заявку
(максимум 2 попытки, потом end event)

5. Проверка соответствия требованиям

Валидирую процесс по техническому заданию:

• Все требования из ТЗ отражены в диаграмме?
• Процесс соответствует бизнес-правилам?
• Есть ли шаги, которые не требуются?

Метод:

1. Беру требование из ТЗ
2. Ищу соответствующие элементы в диаграмме
3. Проверяю, как оно реализовано

6. Проверка участников (Swimlanes)

Если процесс использует swimlanes (дорожки для разных участников):

• Каждая задача должна быть в правильной дорожке
• Передачи между дорожками должны быть явными
• Нельзя двум дорожкам работать одновременно на критичной операции

Пример:

Отдел продаж: Получить заявку -> Проверить КПП
Отдел управления: Утвердить (после проверки КПП)
Отдел логистики: Подготовить товар

7. Проверка читаемости

Диаграмма должна быть понятна не-техническим людям:

• Нет пересекающихся стрелок (возможно?)
• Логические группы близко друг к другу
• Названия элементов на русском, понятные
• Легенда или описание нестандартных элементов

8. Проверка через прогонку примеров

Лучший способ — пройти по процессу на реальных примерах:

Сценарий 1: Happy path (все хорошо)

Клиент подает заявку -> 
Проверяется -> 
Утверждается -> 
Отправляется результат -> 
Процесс завершается ✓

Сценарий 2: Ошибочное состояние

Клиент подает заявку с неправильными данными ->
Отклоняется (описано в диаграмме?) ->
Уведомляется клиент -> 
Процесс завершается

Сценарий 3: Edge case

Клиент подает заявку ровно в граничное время ->
Как обрабатывается? (описано?)

Если не все сценарии описаны — процесс не полный.

9. Проверка производительности

Анализирую потенциальные узкие места:

• Где происходит максимальное ожидание?
• Где требуется ручное вмешательство?
• Возможна ли автоматизация?

Пример: если процесс требует человеческого утверждения на каждом этапе, это может быть bottleneck.

Чеклист проверки BPMN диаграммы

✓ Есть стартовое и финальное события ✓ Все стрелки соединяют элементы (нет висящих) ✓ Все условные ветвления имеют условия на стрелках ✓ Условия на ветвлениях взаимоисключающие и полные ✓ Нет зацикливаний без условия выхода ✓ Все пути ведут к end event ✓ Порядок задач логичен ✓ Названия элементов понятные ✓ Процесс покрывает все требования из ТЗ ✓ Процесс проверен на 2-3 реальных сценариях ✓ Swimlanes (если используются) правильно распределены ✓ Диаграмма читаема и не перегромождена

Инструменты для проверки

• Lucidchart — визуализация и проверка
• ARIS — enterprise-level анализ
• Draw.io — простой, бесплатный
• Camunda Modeler — специализирован на BPMN

На практике я всегда прошу stakeholders пройти по диаграмме с примерами из жизни. Это быстро выявляет ошибки логики.