Якщо на співбесіді вас питають "Чи маєте ви досвід моделювання бізнес-процесів", то в неявному вигляді вас питають про досвід використання нотації 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 варіанти:
Переглянути рівень деталізації процесу, певні крокі об"єднати в підпроцеси, завдяки чому зменшити кількість елементів в діаграмі.
Або використати проміжну подію "Посилання" (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".
Дивно ж буває, коли думки у Денисів співпадають аж до абзаців) https://bpmn2.ru/blog/top-25-oshibok-bpmn