top of page

Типові помилки при моделюванні бізнес-процесів в нотації BPMN (Ч.1)

Оновлено: 25 лист. 2022 р.

Якщо на співбесіді вас питають "Чи маєте ви досвід моделювання бізнес-процесів", то в неявному вигляді вас питають про досвід використання нотації BPMN. Мені можуть заперечити, що є і інші нотації, наприклад, UML Activity diagram або старий-добрий IDEF0. Але на сьогодні місце лідера за BPMN.

До переваг цієї нотації відноситься багата палітра елементів, яка дозволяє краще передати тонкощі процесу. Але це одночасно є і недоліком. Бо неправильне розуміння поведінки елементів призводить до некоректного використання. Багато хто "переосмислює" елементи нотації, на виході отримуємо "нативну нотацію" - елементи правильні, а діаграму без автора зрозуміти неможливо.

В інтернеті є цілий ряд статей, присвячених розгляду помилок, які найчастіше роблять при створенні діаграм в нотації BPMN (посилання 1, посилання 2, посилання 3, ...). На їх основі я написав цю статтю. Помилки у BPMN бувають трьох видів:

  • Помилки формальні – діаграма не відповідає нотації BPMN.

  • Помилки стилю – діаграма формально правильна, але читати чи модифікувати її незручно. Стилеві уподобання у всіх свої.

  • Логічні помилки - елементи використані правильні, стиль дотриманий, але є проблеми в суті того, що намальовано.

Формальні помилки та помилки стилю виправити легко – не треба знати предметну область. Помилки логіки виправити складно, потрібно розбиратися у кожному окремому випадку. 1. Не BPMN

У діаграмі використані елементи, яких немає у BPMN. Це символи з UML, IDEF та інших нотацій. Або це саморобні, вигадані автором символи. Найпростіше переконатись в тому, що ви використовуєте коректні елементи - звернутись до постеру BPMN elements

2. Пули (Pool) та доріжки (Lane)

По-перше, пулів та доріжок на діаграмі може й не бути. Проте їх наявність спрощує розуміння діаграми.

Для чого використовують пули? Або для відображення сусіднього процесу, або для відображення сутності, на яку ми не впливаємо. В другому випадку ми використовуємо згорнутий пул - не моделюємо процес, що відбувається в цій незалежній сутності. Доріжки дозволяють нам показати учасників описуваного процесу - хто яку задачу в рамках процесу виконує. Якщо вдаватись в деталі, то доріжки - елемент суто візуальний. Виконавця/виконавців для кожної задачі зазначають у її властивостях. Ось як це виглядає в Bizagi:

Можна побачити, що тут є можливість вказати учасників і зазначити їх залученість у виконання задачі за RACI-матрицею. Проте в більшості випадків виконавцем є саме той, хто вказаний на доріжці. Отже,

  • конкретних виконавців/підрозділи в рамках одінєї організації, що беруть участь в процесі - моделюємо доріжками;

  • процеси або зовнішніх контрагентів моделюємо пулами;

  • виконавців у простих випадках позначаємо в назві доріжки

  • виконавців в складних випадках (наприклад, декілька виконавців) позначаємо у властивостях задачі.

3. Дієслово в назві Назва задачі має містити дієслово: "Створити заявку" , "Відправити запит". Дехто замість цього пише "Створення заявки", або ще гірше "Заявка". Це помилка в стилі.


4. Детальний опис процесу, про який ми нічого не знаємо

В попередньому пункті ми згадували згорнутий пул, що моделює незалежну сутність. Наприклад, ви показуєте процес обробки замовлення, що надійшло від клієнта. Клієнта краще за все зобразити згорнутим пулом. Що там діється у клієнта - для нас загадка, передбачити процес складно, вплинути ми на нього не можемо. З боку нашего процесу ми маємо визначити які дії з боку клієнта ми збираємось очікувати і це все. Але детальний процес для клієнта краще не вигадувати.


5. "Довга-довга історія"

Якщо процес містить багато кроків, то діаграма раптом починає нагадувати дитячу гру "змійка":

Виглядає щонайменше неестетично. І рекомендації - "читаємо зліва-направо, зверху-вниз" порушені. Для вирішення цієї ситуації є 2 варіанти:

  1. Переглянути рівень деталізації процесу, певні крокі об"єднати в підпроцеси, завдяки чому зменшити кількість елементів в діаграмі.

  2. Або використати проміжну подію "Посилання" (Link):


6. "Загублений лист"

Наступна помилка, на мій погляд, не є очевидною. І критичною вона стає тільки в тому випадку, коли ви моделюєте не тільки для візуалізації, а для виконання за допомогою BPMN-engine. Уявіть, що листоноша приносить лист, що має бути вручений особисто, а за адресою нікого. Листоноша у нас байдужий, він бере і викидає листа. Тепер давайте розглянемо приклад діаграми:


Якщо Task 2 буде завершено раніше ніж Task 1, то відправлене Process 2 повідомлення загубиться, бо Process 1 починає його очікувати лише після завершення Task 1. А до цього моменту "листоношу" ніхто не зустрічає. Для виправлення цієї ситуації ми можемо змінити діаграму наступним чином:

Тут ми лист починаємо очікувати відразу після відправки з боку Process 1.


Для більш вибагливих поціновувачів можна також використати варіант з підпроцесом, що дозволяє взагалі позбутись повідомлень:


7. "У всіх свій шлях, своя мета, але на всіх нас чекає один кінець." З висловлюванням Карлоса Кастанеди можна погоджуватись, можна ні. Але дуже рідко у процесу можливий тільки один варіант завершення, як зображено на діаграмі:


Для підвищення наглядності краще явно показати можливі варіанти завершення. А з точку зору виконуваної моделі це дозволить зафіксувати досягнутий результат в протокол виконання, що в свою чергу дає кращі можливості аналізу виконаних процесів:



8. "Кінець діло хвалить" або завершення без опису.

All's Well That Ends Well або "Все добре, що добре закінчується". Не залишайте фінальну подію в процесі без підпису. Особливо цей підпис є потрібним, коли завершальних подій в нас декілька, як на останньому малюнку в пункті 7. Зазначте, який результат ми отримали, коли дійшли до цього червного кола. Це спростить сприйняття діаграми читачем, а engine зафіксує в протоколі, чим саме закінчився екземпляр процесу.



9. "і швець, і жнець, і в дуду́ грець"

Часто в діаграмах можна побачити, що одна розвилка (gateway) використовується одночасно і для зведення, і для розгалуження потоків:

Практики та теоретики рекомендують використовувати одну розвилку або для зведення, або для розгалудження. Змінюємо діаграму наступним чином:

10. "Змішалися в купу коні, люди"

Завдяки наявності в BPMN розвилки "Або/Або" ми можемо моделювати різноманітні варіанти розвитку подій. Проте є рекомендація відділяти опис бізнес-правил від опису бізнес-процесу. Це і діаграми спрощує, і внесення змін робить простішим. Наприклад, зміна правил розрахунку кредитного рейтингу змінюються набагато частіше, ніж процес видачі кредиту. Тому від такої діаграми:

ми можемо перейти до такої:

, використавши спеціальний тип задачі "Business Rule Task".


3 055 переглядів2 коментарі

Останні пости

Дивитися всі

2 Comments


Oleksandr Chornous
Oleksandr Chornous
May 15, 2023

Дивно ж буває, коли думки у Денисів співпадають аж до абзаців) https://bpmn2.ru/blog/top-25-oshibok-bpmn

Like
Denis Gobov
Denis Gobov
May 15, 2023
Replying to

Саме тому на це джерело та декілька інших є посилання на початку статті

Like
bottom of page