Пропонуємо до Вашої уваги шикарну статтю від Дениса Гобова, опубліковану на ресурсі 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)
По-перше, пулів та доріжок на діаграмі може й не бути. Проте їх наявність спрощує розуміння діаграми.
-
конкретних виконавців/підрозділи в рамках одінєї організації, що беруть участь в процесі – моделюємо доріжками;
-
процеси або зовнішніх контрагентів моделюємо пулами;
-
виконавців у простих випадках позначаємо в назві доріжки
-
виконавців в складних випадках (наприклад, декілька виконавців) позначаємо у властивостях задачі.
3. Дієслово в назві
Назва задачі повинна містити дієслово: “Створити заявку”, “Відправити запит”. Дехто замість цього пише “Створення заявки”, або ще гірше “Заявка”. Це помилка в стилі.
4. Детальний опис процесу, про який ми нічого не знаємо
В попередньому пункті ми згадували згорнутий пул, що моделює незалежну сутність. Наприклад, ви показуєте процес обробки замовлення, що надійшло від клієнта. Клієнта краще за все зобразити згорнутим пулом. Що там діється у клієнта – для нас загадка, передбачити процес складно, вплинути ми на нього не можемо. З боку нашого процесу ми повинні визначити які дії з боку клієнта ми збираємось очікувати і це все. Але детальний процес для клієнта краще не вигадувати.
5. “Довга-довга історія”
Якщо процес містить багато кроків, то діаграма раптом починає нагадувати дитячу гру “змійка”:
-
Переглянути рівень деталізації процесу, певні кроки об’єднати в підпроцеси, завдяки чому зменшити кількість елементів в діаграмі.
-
Або використати проміжну подію “Посилання” (Link):
6. “Загублений лист”
Наступна помилка, на мій погляд, не є очевидною. І критичною вона стає тільки в тому випадку, коли ви моделюєте не тільки для візуалізації, а для виконання за допомогою BPMN-engine. Уявіть, що листоноша приносить лист, що має бути вручений особисто, а за адресою нікого. Листоноша у нас байдужий, він бере і викидає листа. Тепер розгляньмо приклад діаграми:
Для більш вибагливих поціновувачів можна також використати варіант з підпроцесом, що дозволяє взагалі позбутись повідомлень:
7. “У всіх свій шлях, своя мета, але на всіх нас чекає один кінець.” З висловлюванням Карлоса Кастанеди можна погоджуватись, можна ні. Але дуже рідко у процесу можливий тільки один варіант завершення, як зображено на діаграмі:
All’s Well That Ends Well або “Все добре, що добре закінчується”. Не залишайте фінальну подію в процесі без підпису. Особливо цей підпис є потрібним, коли завершальних подій в нас декілька, як на останньому малюнку в пункті 7. Зазначте, який результат ми отримали, коли дійшли до цього червоного кола. Це спростить сприйняття діаграми читачем, а engine зафіксує в протоколі, чим саме закінчився варіант процесу.
Часто в діаграмах можна побачити, що одна розвилка (gateway) використовується одночасно і для зведення, і для розгалуження потоків:
Завдяки наявності в BPMN розвилки “Або/Або” ми можемо моделювати різноманітні варіанти розвитку подій. Проте є рекомендація відділяти опис бізнес-правил від опису бізнес-процесу. Це і діаграми спрощує, і внесення змін робить простішим. Наприклад, зміна правил розрахунку кредитного рейтингу змінюються набагато частіше, ніж процес видачі кредиту. Тому від такої діаграми:
ми можемо перейти до такої:
, використавши спеціальний тип задачі “Business Rule Task”.
Далі буде…
Розклад тренінгів з бізнес-аналізу та аналізу даних від Art of Business Analysis