Пропонуємо до Вашої уваги шикарну статтю від Дениса Гобова, опубліковану на ресурсі Art of Business Analysis про досвід роботи з BPMN. Стаття буде корисна бізнес-аналітикам усіх рівнів. Мабуть, кожен зможе взяти з неї щось корисне!
Якщо на співбесіді вас питають “Чи маєте ви досвід моделювання бізнес-процесів”, то в неявному вигляді вас питають про досвід використання нотації BPMN. Мені можуть заперечити, що є і інші нотації, наприклад, UML Activity diagram або старий-добрий IDEF0. Але на сьогодні місце лідера за BPMN.
До переваг цієї нотації відноситься багата палітра елементів, яка дозволяє краще передати тонкощі процесу. Але це одночасно є і недоліком. Бо неправильне розуміння поведінки елементів призводить до некоректного використання. Багато хто “переосмислює” елементи нотації, на виході отримуємо “нативну нотацію” – елементи правильні, а діаграму без автора зрозуміти неможливо.
В інтернеті є цілий ряд статей, присвячених розгляду помилок, які найчастіше роблять при створенні діаграм в нотації BPMN (посилання 1, посилання 2, посилання 3, …). На їх основі я написав цю статтю. Помилки у BPMN бувають трьох видів:
-
Помилки формальні – діаграма не відповідає нотації BPMN.
-
Помилки стилю – діаграма формально правильна, але читати чи модифікувати її незручно. Стилеві уподобання у всіх свої.
-
Логічні помилки – елементи використані правильні, стиль дотриманий, але є проблеми в суті того, що намальовано.
Формальні помилки та помилки стилю виправити легко – не треба знати предметну область. Помилки логіки виправити складно, потрібно розбиратися у кожному окремому випадку.
1. Не BPMN
У діаграмі використані елементи, яких немає у BPMN. Це символи з UML, IDEF та інших нотацій. Або це саморобні, вигадані автором символи. Найпростіше переконатись в тому, що ви використовуєте коректні елементи – звернутись до постеру BPMN elements
2. Пули (Pool) та доріжки (Lane)
По-перше, пулів та доріжок на діаграмі може й не бути. Проте їх наявність спрощує розуміння діаграми.
![Пули (Pool) та доріжки (Lane)](https://i0.wp.com/www.ba.in.ua/wp-content/uploads/2022/11/49cfb6_6a52a15b6573436789b637b01adf5686_mv2.png?resize=715%2C328)
![Зазначення виконавця у властивостях у нотації BPMN за допомогою інструменту Bizagi](https://i0.wp.com/www.ba.in.ua/wp-content/uploads/2022/11/49cfb6_3f18613b188d44d5b3be8dd1befdf8c0_mv2.png?resize=821%2C463)
-
конкретних виконавців/підрозділи в рамках одінєї організації, що беруть участь в процесі – моделюємо доріжками;
-
процеси або зовнішніх контрагентів моделюємо пулами;
-
виконавців у простих випадках позначаємо в назві доріжки
-
виконавців в складних випадках (наприклад, декілька виконавців) позначаємо у властивостях задачі.
3. Дієслово в назві
Назва задачі повинна містити дієслово: “Створити заявку”, “Відправити запит”. Дехто замість цього пише “Створення заявки”, або ще гірше “Заявка”. Це помилка в стилі.
![Назва задачі повинна містити дієслово](https://i0.wp.com/www.ba.in.ua/wp-content/uploads/2022/11/49cfb6_74e688cde8754e7ba3afa673e2efe5b3_mv2.png?resize=423%2C365)
4. Детальний опис процесу, про який ми нічого не знаємо
В попередньому пункті ми згадували згорнутий пул, що моделює незалежну сутність. Наприклад, ви показуєте процес обробки замовлення, що надійшло від клієнта. Клієнта краще за все зобразити згорнутим пулом. Що там діється у клієнта – для нас загадка, передбачити процес складно, вплинути ми на нього не можемо. З боку нашого процесу ми повинні визначити які дії з боку клієнта ми збираємось очікувати і це все. Але детальний процес для клієнта краще не вигадувати.
5. “Довга-довга історія”
Якщо процес містить багато кроків, то діаграма раптом починає нагадувати дитячу гру “змійка”:
!["Довга-довга історія"](https://i0.wp.com/www.ba.in.ua/wp-content/uploads/2022/11/49cfb6_ad92f1a17a9c44d5a7b29af47df45cce_mv2.png?resize=960%2C416)
-
Переглянути рівень деталізації процесу, певні кроки об’єднати в підпроцеси, завдяки чому зменшити кількість елементів в діаграмі.
-
Або використати проміжну подію “Посилання” (Link):
![Використання проміжної події "Посилання" (Link)](https://i0.wp.com/www.ba.in.ua/wp-content/uploads/2022/11/49cfb6_000f53ee9da84ceba800aad0a329dbec_mv2.png?resize=421%2C203)
6. “Загублений лист”
Наступна помилка, на мій погляд, не є очевидною. І критичною вона стає тільки в тому випадку, коли ви моделюєте не тільки для візуалізації, а для виконання за допомогою BPMN-engine. Уявіть, що листоноша приносить лист, що має бути вручений особисто, а за адресою нікого. Листоноша у нас байдужий, він бере і викидає листа. Тепер розгляньмо приклад діаграми:
!["Загублений лист"](https://i0.wp.com/www.ba.in.ua/wp-content/uploads/2022/11/49cfb6_1b241879587a451aa375caa1edbc7aa5_mv2.png?resize=566%2C302)
![Виправлення "загубленого листа"](https://i0.wp.com/www.ba.in.ua/wp-content/uploads/2022/11/49cfb6_9753b180ffca4fa8848c02c635f1c9d8_mv2.png?resize=647%2C331)
Для більш вибагливих поціновувачів можна також використати варіант з підпроцесом, що дозволяє взагалі позбутись повідомлень:
![Використання підпроцесу для вирішення "загубленого листа"](https://i0.wp.com/www.ba.in.ua/wp-content/uploads/2022/11/49cfb6_f00ce8578a394025801d7dec225f5909_mv2.png?resize=757%2C308)
7. “У всіх свій шлях, своя мета, але на всіх нас чекає один кінець.” З висловлюванням Карлоса Кастанеди можна погоджуватись, можна ні. Але дуже рідко у процесу можливий тільки один варіант завершення, як зображено на діаграмі:
![Варіант діаграми з одним можливим варіантом завершення](https://i0.wp.com/www.ba.in.ua/wp-content/uploads/2022/11/49cfb6_3880560939e446cb8da35282667f128a_mv2.png?resize=730%2C132)
![Приклад діаграми з кількома варіантами завершення процесу](https://i0.wp.com/www.ba.in.ua/wp-content/uploads/2022/11/49cfb6_ae4803925c1343568b97bb29956bdafd_mv2.png?resize=712%2C139)
All’s Well That Ends Well або “Все добре, що добре закінчується”. Не залишайте фінальну подію в процесі без підпису. Особливо цей підпис є потрібним, коли завершальних подій в нас декілька, як на останньому малюнку в пункті 7. Зазначте, який результат ми отримали, коли дійшли до цього червоного кола. Це спростить сприйняття діаграми читачем, а engine зафіксує в протоколі, чим саме закінчився варіант процесу.
![Зазначте, який результат ми отримали, коли дійшли до цього червного кола. Це спростить сприйняття діаграми читачем](https://i0.wp.com/www.ba.in.ua/wp-content/uploads/2022/11/49cfb6_f4fb703740aa4e47a5c0705985f65589_mv2.png?resize=709%2C149)
Часто в діаграмах можна побачити, що одна розвилка (gateway) використовується одночасно і для зведення, і для розгалуження потоків:
![Одна розвилка (gateway) використовується одночасно і для зведення, і для розгалуження потоків. Приклад](https://i0.wp.com/www.ba.in.ua/wp-content/uploads/2022/11/49cfb6_2276a301b1b14f498ead1add60839306_mv2.png?resize=363%2C322)
![Практики та теоретики рекомендують використовувати одну розвилку або для зведення, або для розгалуження](https://i0.wp.com/www.ba.in.ua/wp-content/uploads/2022/11/49cfb6_42a9b1f9b66d47eca6b2309b33a46e5a_mv2.png?resize=460%2C304)
Завдяки наявності в BPMN розвилки “Або/Або” ми можемо моделювати різноманітні варіанти розвитку подій. Проте є рекомендація відділяти опис бізнес-правил від опису бізнес-процесу. Це і діаграми спрощує, і внесення змін робить простішим. Наприклад, зміна правил розрахунку кредитного рейтингу змінюються набагато частіше, ніж процес видачі кредиту. Тому від такої діаграми:
![Опис бізнес-правил і бізнес-процесів на одній діаграмі. Приклад](https://i0.wp.com/www.ba.in.ua/wp-content/uploads/2022/11/49cfb6_b24efeace1d3485394a98f8385e575a9_mv2.png?resize=643%2C701)
ми можемо перейти до такої:
![](https://i0.wp.com/static.wixstatic.com/media/49cfb6_41904ab60e804d949700c6441851919a~mv2.png/v1/fill/w_615,h_148,al_c,lg_1,q_85,enc_auto/49cfb6_41904ab60e804d949700c6441851919a~mv2.png?w=960&ssl=1)
, використавши спеціальний тип задачі “Business Rule Task”.
Далі буде…
Розклад тренінгів з бізнес-аналізу та аналізу даних від Art of Business Analysis