BPMN против блок-схем: когда и зачем использовать BPMN новичкам

Блок-схемы и диаграммы BPMN показывают, как работа переходит от одного шага к другому. Разница заключается в основном вцели и точности:

• Блок-схема — это универсальная диаграмма для отображения логики, шагов и решений.

• BPMN или «Моделирование бизнес-процессов и нотация» — это стандартизированный язык, разработанный специально для моделирования бизнес-процессов, обязанностей, событий, сообщений, данных и автоматизации.

Блок-схема часто является самым быстрым способом объяснить простую процедуру. BPMN становится более полезным, когда процесс включает несколько человек, отделов, организаций, исключений, сроков или программных систем.

BPMN поддерживается как официальная спецификация Группой управления объектами (Object Management Group). Его нотация разработана так, чтобы быть понятной для бизнес-заинтересованных сторон, оставаясь при этом достаточно точной для технической реализации. Текущая используемая официальная спецификация — BPMN 2.0.2.

1. Что такое блок-схема?

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

Типичная блок-схема включает:

• Овал: Начало или конец

• Прямоугольник: Процесс или действие

• Ромб: Решение

• Стрелка: Направление потока

• Параллелограмм: Ввод или вывод

• Форма документа: Документ или отчёт

Например, базовая блок-схема возмещения расходов может выглядеть так:

Начало
  ↓
Сотрудник подаёт отчёт о расходах
  ↓
Менеджер проверяет отчёт
  ↓
Одобрено?
 ├── Нет → Вернуть отчёт сотруднику
 └── Да → Финансовый отдел выдаёт оплату
  ↓
Конец

Блок-схемы легко создавать и понимать, поскольку они используют небольшое количество знакомых символов. Они полезны для:

• Объяснения простой процедуры

• Документирование алгоритма

• Описание шагов по устранению неполадок

• Составление карты личного или департаментского рабочего процесса

• Обучение сотрудников

• Показ базовой последовательности принятия решений

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

2. Что такое BPMN?

BPMN расшифровывается как Моделирование и нотация бизнес-процессов. Это стандартизированная нотация для описания бизнес-процессов согласованным образом.

Диаграммы BPMN могут отображать:

• Деятельность и задачи

• События начала, промежуточные и конечные события

• Решения и ветвящаяся логика

• Параллельная работа

• Участники и обязанности

• Взаимодействие между отделами или организациями

• Сообщения

• Входные и выходные данные

• Таймеры, ошибки, отмены и эскалации

• Повторно используемые подпроцессы

• Человеческая и автоматизированная деятельность

BPMN основана на концепциях блок-схем, но добавляет гораздо более богатый словарь для бизнес-операций. Её основные категории включают объекты потока, соединительные объекты, дорожки и артефакты.

Упрощённый процесс BPMN может быть описан следующим образом:

Клиент оформляет заказ
        ↓
Система продаж фиксирует заказ
        ↓
Склад проверяет наличие товара
        ↓
Товар в наличии?
 ├── Нет → Уведомить клиента
 └── Да → Подобрать и упаковать заказ
                 ↓
           Транспортная компания доставляет заказ

В реальной диаграмме BPMN каждый участник может быть представлен в отдельном пуле или дорожке, а коммуникация между ними может быть показана с помощью потоков сообщений.

3. BPMN и блок-схемы: краткое сравнение

Характеристика	Блок-схема	BPMN
Основная цель	Показать общую логику или последовательность	Моделировать бизнес-процессы
Стандартизация	Часто неформальны или специфичны для инструмента	Формальная международная нотация моделирования
Кривая обучения	Низкая	Средняя
Количество символов	Небольшой набор	Более обширный специализированный словарь
Роли и обязанности	Обычно ограничены	Явно представлены с помощью пулов и дорожек
Межорганизационная коммуникация	Сложно показать точно	Представлено потоками сообщений
Исключения и прерывания	Обычно упрощены	События могут представлять таймеры, ошибки, сообщения и эскалации
Параллельные действия	Возможно, но часто неясно	Поддерживаются с помощью параллельных шлюзов
Поддержка автоматизации	Ограниченная	Может быть достаточно детализированной для поддержки реализации
Наилучшее применение	Простые процедуры и логика	Сложные, совместные, повторяющиеся процессы
Типичная аудитория	Обычные пользователи, студенты, команды	Аналитики, владельцы процессов, разработчики, менеджеры
Уровень детализации	От низкого до среднего	От среднего до очень высокого

4. Основное различие: Общая логика против семантики бизнес-процессов

Самое важное различие заключается в том, что блок-схема в первую очередь отвечает на вопрос:

«Что произойдет дальше?»

BPMN может ответить на несколько дополнительных вопросов:

• Кто выполняет каждое действие?

• Какой отдел или организация вовлечены?

• Является ли взаимодействие внутренним или внешним?

• Вызван ли следующий шаг сообщением, таймером, ошибкой или условием?

• Могут ли действия происходить параллельно?

• Какие данные требуются?

• Что произойдет, если процесс завершится неудачей?

• Какие задачи выполняются людьми, системами или правилами?

• Может ли этот процесс быть автоматизирован или контролироваться?

Например, блок-схема может гласить:

Рассмотреть заявку → Утвердить заявку → Отправить подтверждение

Модель BPMN может различать:

• Клиент подает заявку.

• Команда службы поддержки клиентов проверяет её.

• Автоматизированная система проверяет кредитную информацию.

• Менеджер утверждает заявки, превышающие определённую сумму.

• Таймер запускает напоминание через три рабочих дня.

• Сообщение отправляется клиенту.

• Путь обработки ошибок решает проблему отсутствующей документации.

Блок-схема передаёт общую структуру. BPMN передаёт операционную структуру.

5. Основные элементы BPMN, необходимые новичкам

BPMN содержит множество символов, но новичкам сначала достаточно небольшого базового набора.

События

События представляют собой то, что происходит, а не то, что кто-то делает.

Они изображаются в виде кругов.

К распространённым типам относятся:

• Событие начала: Запускает процесс

• Промежуточное событие: Происходит в ходе процесса

• Событие завершения: Завершает процесс

• Событие сообщения: Получается или отправляется сообщение

• Таймерное событие: Вовлечены срок или запланированное время

• Событие ошибки: Происходит ошибка

• Событие эскалации: Вопрос требует внимания на более высоком уровне

Примеры:

• Клиент размещает заказ.

• Истекает срок оплаты.

• Получено электронное письмо.

• Произошла системная ошибка.

Деятельности

Деятельности представляют собой выполняемую работу. Они изображаются в виде прямоугольников со скруглёнными углами.

Они могут быть:

• Задачи: Отдельные единицы работы

• Подпроцессы: Группы связанных деятельностей

• Задачи с участием пользователя: Работа, выполняемая человеком с помощью системы

• Сервисные задачи: Работа, выполняемая автоматически программным обеспечением

• Ручные задачи: Работа, выполняемая без помощи системы

• Задачи по бизнес-правилам: Работа, определяемая бизнес-правилом или сервисом принятия решений

Для новичка самая важная идея проста:

События происходят; деятельности выполняются.

Шлюзы

Шлюзы управляют разделением или объединением процесса. Они изображаются в виде ромбов.

Распространённые типы шлюзов включают:

• Исключающий шлюз: Выбирается только один путь

• Параллельный шлюз: Несколько путей выполняются одновременно

• Включающий шлюз: Может быть выбран один или несколько путей

• Шлюз, основанный на событиях: Следующий путь зависит от того, какое событие произойдёт первым

Пример исключающего решения:

Оплата получена?
 ├── Да → Отправить заказ
 └── Нет → Отправить напоминание об оплате

Пример параллельной работы:

Заказ утверждён
      ↓
 ┌───────────────┬────────────────┐
 │               │                │
Упаковка заказа   Подготовка счёта   Уведомление клиента
 │               │                │
 └───────────────┴────────────────┘
      ↓
Заказ готов к отгрузке

Последовательность потоков

Сплошная стрелка показывает порядок, в котором действия, события и шлюзы происходят в рамках одного процесса.

Задача A → Задача B → Задача C

Поток сообщений

Пунктирная стрелка обозначает коммуникацию между отдельными участниками или пулами.

Например:

Клиент ──сообщение──> Компания
Компания ──подтверждение──> Клиент

Поток сообщений отличается от последовательности потоков:

• Последовательность потоков: Показывает порядок выполнения работ в рамках процесса

• Поток сообщений: Показывает коммуникацию между участниками

Пулы и полосы

Полосы (бассейны) организуют работу по участнику или ответственности.

• «пул» обычно представляет участника, организацию, бизнес-сущность или независимый процесс.

• «полоса» делит пул на роли, команды, отделы или системы.

Пример:

Полоса клиента:     Отправить заказ ─────────────── Получить подтверждение
                         │                              ↑
Полоса отдела продаж:      Проверить заказ ─────── Отправить подтверждение

Пулы и полосы отвечают на один из самых важных вопросов процесса:

Кто отвечает за этот шаг?

Объекты данных и аннотации

Объекты данных показывают информацию, используемую или создаваемую действием.

Примеры:

• Заявка

• Счет-фактура

• Договор

• Карточка клиента

• Транспортная этикетка

Аннотации добавляют поясняющий текст, не изменяя логику процесса.

6. Когда блок-схема является лучшим выбором

Используйте блок-схему, если процесс прост, линейен или в основном связан с принятием решений.

Блок-схема обычно достаточна, когда:

• Есть один основной участник

• Процесс имеет лишь несколько шагов

• Не требуется акцентировать ответственность

• Отсутствуют сложные взаимодействия с внешними сторонами

• Диаграмма предназначена для быстрого объяснения

• Процесс исследуется в неформальном порядке

• Вы документируете алгоритм или процедуру устранения неполадок

• Ваша аудитория не знакома с BPMN

Например, «Как сбросить пароль» может быть лучше представлено простой блок-схемой:

Начало
  ↓
Введите имя пользователя
  ↓
Учетная запись найдена?
 ├── Нет → Показать ошибку
 └── Да → Отправить письмо для сброса
                ↓
          Пользователь создает пароль
                ↓
               Конец

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

7. Когда BPMN является лучшим выбором

Используйте BPMN, когда необходимо смоделировать реальный бизнес-процесс, а не просто описать последовательность.

BPMN особенно полезен, когда процесс имеет:

• Несколько отделов

• Несколько ролей или участников

• Клиенты, поставщики, регуляторы или партнеры

• Передачи между командами

• Параллельные действия

• Внешние сообщения

• Таймеры или сроки

• Обработка ошибок или исключений

• Уровни согласования

• Автоматизированные системные задачи

• Требования соответствия

• Повторяющиеся усилия по улучшению процессов

• Будущая цель автоматизации рабочих процессов

Типичные случаи использования BPMN включают:

• Согласование заказа на покупку

• Обработка заявок на кредит

• Страховые случаи

• Адаптация сотрудников

• Эскалация обращений в службу поддержки

• Обработка счетов-фактур

• Возврат товаров

• Направление в сфере здравоохранения

• Рассмотрение контрактов

• Исполнение отгрузок

• Регуляторная отчетность

• Рабочие процессы развертывания программного обеспечения

Полезное правило:

Если процесс пересекает границы — между людьми, командами, системами или организациями — BPMN обычно стоит рассмотреть.

8. Зачем использовать BPMN?

Общий язык

Различные группы часто описывают один и тот же процесс по-разному. Бизнес-менеджер может говорить о согласованиях, разработчик — о сервисах, а сотрудник — о ежедневных задачах.

BPMN предоставляет общий визуальный язык, который может помочь этим группам обсуждать один и тот же процесс. Его цель — быть удобным для бизнес-заинтересованных сторон, при этом оставаясь достаточно точным для преобразования в программные компоненты процессов.

Четкая подотчетность

Дорожки делают ответственность видимой.

Вместо отображения:

Рассмотреть заявку → Утвердить заявку → Создать учетную запись

BPMN может показать:

• Клиент подаёт заявку

• Служба поддержки клиентов проверяет информацию

• Кредитный отдел проводит оценку

• Менеджер утверждает исключение

• ИТ-система создаёт учётную запись

Это может выявить дублирование работы, неясное распределение ответственности и ненужные передачи задач.

Улучшенный анализ исключений

Многие реальные процессы не следуют сценарию «успешного выполнения». BPMN упрощает их моделирование:

• Отсутствующая информация

• Отклонённые заявки

• Истёкшие сроки

• Неудачные платежи

• Ошибки системы

• Отмены

• Эскалации со стороны клиентов

• Компенсация или корректирующие действия

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

Поддержка автоматизации

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

Например, дизайнер процесса может различать:

• Задача, выполняемая сотрудником

• Задача, выполняемая автоматизированным сервисом

• Решение, оцениваемое по бизнес-правилу

• Сообщение, полученное от другой системы

• Таймер, запускающий действие

Улучшение улучшения процессов

Диаграмма BPMN может помочь выявить:

• Узкие места

• Длинные цепочки согласований

• Повторный ввод данных

• Излишние проверки

• Ручные задачи, подходящие для автоматизации

• Отсутствующие пути обработки исключений

• Избыточная передача задач

• Нечёткое распределение ответственности

• Задержки, вызванные внешними сторонами

Это делает BPMN ценным не только для документирования процессов, но и для их анализа и перепроектирования.

9. Недостатки BPMN

BPMN мощна, но она подходит не во всех случаях.

У неё более крутая кривая обучения

Блок-схемы часто можно понять сразу. BPMN требует от пользователей изучения различий, таких как:

• Последовательный поток против потока сообщений

• События против действий

• Бассейны против дорожек

• Исключающие шлюзы против параллельных шлюзов

• Прерывающие события против непрерывающих событий

• События получения против событий отправки

Диаграммы могут стать перегруженными

Большая диаграмма BPMN может содержать десятки символов и пересекающихся линий. Плохо спроектированные модели могут быть труднее для понимания, чем простая блок-схема.

Точность может создать ложное чувство уверенности

Использование символов BPMN автоматически не делает модель процесса точной. Модель по-прежнему зависит от корректной информации от владельцев процессов и экспертов в предметной области.

Не всем аудиториям нужна полная детализация

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

Её можно чрезмерно использовать

Пятишаговая внутренняя процедура не обязательно требует событий сообщений, нескольких бассейнов и вложенных подпроцессов. Нотация должна соответствовать задаче.

10. Практическое руководство по принятию решений

Используйте эти вопросы, чтобы выбрать между блок-схемой и BPMN:

1. Сколько участников вовлечено?

   • Один человек или команда: блок-схемы может быть достаточно.

   • Несколько команд или организаций: BPMN более подходит.

2. Имеют ли значение обязанности?

   • Если нет, используйте блок-схему.

   • Если да, используйте дорожки или пулы в BPMN.

3. Есть ли внешние коммуникации?

   • Если нет, может подойти любая нотация.

   • Если да, BPMN позволяет отличать сообщения от внутреннего потока процесса.

4. Есть ли таймеры, ошибки или эскалации?

   • Если нет, может быть достаточно блок-схемы.

   • Если да, BPMN предоставляет более чёткие инструменты моделирования.

5. Будет ли процесс автоматизирован?

   • Если нет, для простого процесса может быть достаточно блок-схемы.

   • Если да, BPMN обычно является лучшей основой.

6. Нужно ли использовать процесс повторно как формальный стандарт?

   • Если нет, используйте самую простую нотацию, понятную вашей аудитории.

   • Если да, BPMN обеспечивает большую согласованность между диаграммами и инструментами.

7. Каков уровень квалификации вашей аудитории?

   • Общая аудитория: начните с простой блок-схемы или высокоуровневого BPMN.

   • Аналитики и технические команды: используйте BPMN с соответствующей детализацией.

11. Метод моделирования BPMN, дружественный новичкам

Шаг 1: Определите границы процесса

Решите, где процесс начинается и заканчивается.

Например:

• Начало: Клиент подаёт запрос в службу поддержки

• Конец: Клиент получает решение

Избегайте попыток смоделировать всю организацию сразу.

Шаг 2: Определите участников

Перечислите людей, команды, организации и системы, участвующие в процессе.

Пример:

• Клиент

• Специалист службы поддержки

• Команда технической поддержки

• Система биллинга

• Менеджер услуг

Они могут стать пулами или дорожками.

Шаг 3: Сначала опишите счастливый путь

Опишите обычный процесс без исключений.

Получить запрос
  ↓
Классифицировать запрос
  ↓
Исследовать проблему
  ↓
Решить проблему
  ↓
Уведомить клиента
  ↓
Закрыть запрос

Это создаёт чёткую основу перед добавлением сложности.

Шаг 4: Добавьте события начала и окончания

Каждый полный процесс BPMN должен иметь чёткое начало и завершение.

Примеры:

• Начало: Сообщение получено

• Начало: Таймер сработал

• Начало: Клиент заполняет форму

• Конец: Дело закрыто

• Конец: Запрос отклонён

• Конец: Оплата завершена

Шаг 5: Распределите задачи между участниками

Разместите каждое действие в соответствующей дорожке.

Например:

Клиент:       Отправить запрос ───────────── Получить решение
Поддержка:                  Классифицировать ─ Исследовать ─ Решить
Система:                                      Отправить уведомление

Шаг 6: Добавьте шлюзы для принятия решений

Используйте эксклюзивный шлюз, когда должен быть выбран только один путь.

Проблема решена?
 ├── Нет → Эскалировать
 └── Да → Уведомить клиента

Не используйте шлюз только потому, что в названии задачи есть вопрос. Используйте его, когда процесс действительно разветвляется.

Шаг 7: Осторожно добавьте параллельную работу

Используйте параллельный шлюз, когда действия могут действительно происходить одновременно.

Например, после утверждения заказа:

• Зарезервировать товар

• Сформировать счёт

• Уведомить склад

Если одна деятельность должна происходить до другой, не моделируйте их как параллельные.

Шаг 8: Добавить сообщения и данные

Показывать сообщения при взаимодействии участников.

Примеры:

• Клиент отправляет заявку

• Поставщик отправляет уведомление о отгрузке

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

Добавляйте объекты данных, когда информация важна для деятельности.

Шаг 9: Добавить исключения

Задайте вопрос:

• Что делать, если отсутствует необходимая информация?

• Что делать, если клиент не отвечает?

• Что делать, если оплата не прошла?

• Что делать, если истекает срок?

• Что делать, если система недоступна?

• Что делать, если сотрудник отклоняет запрос?

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

Шаг 10: Проверьте схему с владельцами процессов

Схема должна быть проверена людьми, которые выполняют работу. Они могут выявить:

• Пропущенные шаги

• Неверные обязанности

• Неформальные обходные пути

• Исключения, не задокументированные в процедурах

• Задержки и ненужные согласования

12. Пример: версия блок-схемы против версии BPMN

Простая блок-схема

Предположим, что клиент возвращает товар:

Начало
  ↓
Клиент запрашивает возврат
  ↓
Имеет ли возврат право на возврат?
 ├── Нет → Отклонить запрос
 └── Да → Отправить этикетку для возврата
                ↓
          Получить возвращенный товар
                ↓
          Выдать возврат средств
                ↓
               Конец

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

Версия, ориентированная на BPMN

Более детальная модель BPMN различала бы участников:

Клиент

• Запросить возврат

• Упаковать товар

• Отправить товар

Служба поддержки клиентов

• Проверить запрос на возврат

• Одобрить или отклонить возврат

• Отправить инструкции по возврату

Склад

• Получить товар

• Проверить состояние

Финансы

• Оформить возврат средств

Система

• Отправить подтверждение

• Обновить складские запасы

• Зафиксировать возврат средств

Модель также может представлять:

• Сообщение от клиента

• Таймер для дедлайна возврата

• Шлюз на основе состояния товара

• Ошибка, если товар не получен

• Параллельные действия по обновлению запасов и возврату средств

• Сообщение, подтверждающее возврат средств

Блок-схема объясняет общую логику. BPMN объясняет операционное взаимодействие.

13. Распространённые ошибки новичков

Ошибка 1: Использование всех символов BPMN

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

Начните с:

• События начала и окончания

• Задачи

• Эксклюзивные шлюзы

• Последовательные потоки

• Бассейны и дорожки

• Потоки сообщений по мере необходимости

Добавляйте продвинутые элементы только тогда, когда они решают реальную проблему моделирования.

Ошибка 2: Путаница между последовательным потоком и потоком сообщений

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

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

Ошибка 3: Неправильное смешивание бассейнов и дорожек

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

Например:

• Отделы продаж, финансов и операций могут быть дорожками внутри одной компании.

• Клиент и поставщик могут быть отдельными бассейнами.

Ошибка 4: Рассмотрение каждого решения как эксклюзивного

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

Ошибка 5: Пропуск триггера

Процесс должен объяснять, что его запускает. «Обработка заказа» является неопределённой, если модель не показывает, является ли триггером:

• Заказ клиента

• Запланированная пакетная обработка

• Подтверждение оплаты

• Сообщение от другой системы

Ошибка 6: Моделирование только идеального процесса

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

Ошибка 7: Размещение слишком большого количества текста внутри операций

Подписи задач обычно должны использовать краткий формат «глагол-существительное»:

• Проверка заявки

• Проверка адреса

• Одобрить возврат

• Отправить подтверждение

Избегайте длинных абзацев внутри блоков задач. Размещайте поясняющую информацию в аннотациях или документации.

Ошибка 8: Создание одной гигантской диаграммы

Крупные процессы следует разбивать на подпроцессы. Диаграмма высокого уровня может отображать:

Получить заказ → Обработать оплату → Выполнить заказ → Закрыть заказ

Каждый этап может быть связан с более детальной диаграммой.

14. Лучшие практики BPMN для читаемых диаграмм

• Начинайте с чёткого события начала.

• Завершайте одним или несколькими значимыми конечными состояниями.

• Размещайте основной поток слева направо или сверху вниз.

• Держите линии последовательности максимально прямыми, насколько это возможно.

• Избегайте пересечения линий.

• Используйте согласованные названия задач.

• Поддерживайте основной диаграмму на уровне детализации, обеспечивающем читаемость.

• Используйте дорожки только тогда, когда важна ответственность.

• Подписывайте шлюзы значимыми вопросами или условиями.

• Подписывайте исходящие пути шлюзов, если их значение не очевидно.

• Используйте подпроцессы для сокрытия излишней детализации.

• Различайте обычные пути и пути обработки исключений.

• Поддерживайте потоки сообщений между соответствующими пулами.

• Используйте аннотации дозированно.

• Проверяйте модель с людьми, которые выполняют процесс.

• При перепроектировании процесса создавайте отдельные диаграммы «текущее состояние» и «будущее состояние».

15. Сколько BPMN должен изучить новичок?

Вам не нужно изучать всю спецификацию BPMN, чтобы создавать полезные диаграммы.

Уровень новичка

Изучите:

• События начала

• События завершения

• Задачи

• Потоки последовательности

• Исключающие шлюзы

• Параллельные шлюзы

• Пулы

• Дорожки

• Потоки сообщений

• Базовые объекты данных

Этого достаточно для многих диаграмм бизнес-процессов.

Промежуточный уровень

Добавить:

• Таймерные события

• События сообщений

• События ошибок

• Подпроцессы

• Вызовы действий

• Задачи пользователей

• Задачи обслуживания

• Граничные события

• Шлюзы на основе событий

• Пути компенсации

Продвинутый уровень

Изучить:

• Диаграммы хореографии

• Диаграммы диалога

• Непрерывные события

• Событийные подпроцессы

• Транзакции

• Компенсация

• Многоэкземплярные действия

• Корреляция

• Семантика выполнения

• Правила реализации, специфичные для инструмента

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

16. BPMN, блок-схемы и связанные нотации

BPMN — не единственная нотация моделирования.

• Блок-схемы:Лучше всего подходят для простой логики и процедур

• BPMN:Лучше всего подходят для бизнес-процессов и совместной работы в рамках рабочих процессов

• Диаграммы деятельности UML:Полезны для описания поведения программного обеспечения и систем

• DMN:Полезны для формализованных бизнес-решений и правил

• CMMN:Полезны для гибкой работы, основанной на случаях, где путь не полностью предопределен

• Карты потоков создания ценности:Полезны для анализа ценности и потерь на всем протяжении процесса

• Диаграммы SIPOC:Полезны для высокоуровневого анализа поставщик-вход-процесс-выход-клиент

BPMN может показать, что происходит принятие решения, в то время как нотация, ориентированная на решения, такая как DMN, может описывать правила, используемые для этого решения. Эти нотации могут дополнять друг друга, а не конкурировать.

17. Простое эмпирическое правило

Выберите блок-схемукогда:

Вам нужно как можно быстрее и проще объяснить последовательность шагов или решений.

Выберите BPMNкогда:

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

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

1. Начните с простой блок-схемы, чтобы понять общий процесс.

2. Преобразуйте её в BPMN, когда становятся важными роли, сообщения, исключения, временные рамки или автоматизация.

3. Создайте высокоуровневую диаграмму BPMN для руководителей и детализированную версию для аналитиков или разработчиков.

Заключение

Блок-схемы и BPMN не являются конкурирующими инструментами в каждой ситуации. Блок-схема — это лёгкое визуальное объяснение. BPMN — это структурированный язык моделирования для процессов, требующих большей ясности, подотчётности и операционной детализации.

Для новичков лучший подход — начать с простого:

• Определите границы процесса.

• Выделите участников.

• Опишите обычный путь.

• Добавьте точки принятия решений.

• Распределите обязанности.

• Добавляйте сообщения, таймеры, данные и исключения только тогда, когда это необходимо.

• Используйте подпроцессы для управления сложностью.

Если ваш процесс короткий и выполняется одним человеком или командой, блок-схемы, вероятно, будет достаточно. Если процесс включает несколько ролей, отделов, систем, внешних сторон, дедлайнов или автоматизацию, BPMN обычно обеспечит более ясную и устойчивую модель.

Эта статья также доступна на Deutsch, English, Español, فارسی, Français, English, Bahasa Indonesia, 日本語, Polski, Portuguese, Việt Nam, 简体中文 and 繁體中文