BPMN-модель на перший погляд може виглядати правильно — мати необхідні події, розгалуження та розмежування — але ніхто в команді її не розуміє. Завдання плутаються, комунікація зривається, процеси затягуються на місяці.
Галина Цимбал, Lead Business Transformation Analyst у Ciklum, понад 10 років допомагає компаніям перетворювати складні процеси на зрозумілі BPMN-моделі. В цій статті Галина ділиться 7 правилами, які роблять такі моделі зрозумілими та корисними, щоби процеси працювали на бізнес.
Скоро в Галини стартує курс «Нотації BPMN» у Laba.
#1. Починайте з чіткої межі процесу (Start-End)
Одна з найпоширеніших проблем BPMN-моделей — коли незрозуміло, де старт і де кінець процесу. Таку модель неможливо ні проаналізувати, ні автоматизувати.
Процеси можуть бути різного масштабу. Є високорівневі, які описують загальну логіку бізнесу, а є зовсім дрібні — яку кнопку потрібно натиснути, щоб виконати конкретну дію. В каталозі процесів вони зазвичай вибудовуються ієрархією: від верхнього рівня до нижнього, поступово деталізуючись.
Перш ніж щось малювати, важливо відповісти собі на два запитання:
— який рівень процесу ми зараз моделюємо?
— який ступінь деталізації для нас достатній?
Від цього і залежить, де саме будуть межі процесу.
Одна з типових помилок — завершувати процес занадто рано. Наприклад, компанія хоче найняти нового співробітника. Стартом може бути відкриття позиції. А завершенням — не момент, коли знайшли кандидата, а коли новий співробітник пройшов онбординг і став повноцінною частиною команди. Або ж коли позицію закрили через зміну контексту, бо вона, наприклад, більше не потрібна бізнесу.
У більшості випадків процес має один логічний старт, але він може ініціюватися в різний спосіб. Наприклад, клієнт може оформити замовлення через сайт, під час телефонного звернення або через e-mail. Це різні події, але якщо для моделі не важливо, яким саме каналом скористалися, їх можна об’єднати в один узагальнений старт — «Замовлення оформлено». Якщо ж канал має значення, стартів буде кілька.
Процес може мати кілька варіантів завершення, які відображають різні бізнес-результати. Замовлення доставлено, замовлення скасовано, процес передано в інший відділ — усе це різні, але коректні завершення.
Щоби перевірити модель, зручно користуватися поняттям токена. Якщо уявити процес як систему труб, то токен — це вода, яка по них тече. Процес вважається коректним, коли:
Якщо токен десь застрягає, ходить по колу або зникає — значить, десь є незавершена логіка. В таких випадках потрібно повернутися до цієї точки та поставити запитання: який тут має бути бізнес-результат? Можливо, процес не «обривається», а передається в інший відділ, іншу систему або запускає інший процес. І це буде коректним завершенням.
#2. Не змішуйте кілька бізнес-цілей в одному процесі
В межах однієї діаграми не варто змішувати різні цілі. Якщо мета змінюється — це вже інший процес або окремий підпроцес.
Виконуючи процес, ми завжди можемо відповісти на запитання: яку саме цінність для бізнесу ми отримуємо в результаті? Якщо в межах одного процесу з’являється декілька різних цінностей, це означає лише одне: ми намагаємося поєднати кілька процесів в один.
У такій ситуації є два варіанти: або розділити процеси та моделювати їх окремо, або піднятися на вищий рівень і зафіксувати верхньорівневий процес, у якому ці цілі будуть окремими етапами. Але залишати кілька бізнес-цілей всередині одного «плоского» процесу — погана ідея.
В платіжних системах це правило порушується особливо часто. Підключення платіжного провайдера і конкретного платіжного методу — це не одне й те саме. Підключаючи провайдера, ми досягаємо мети: з’являється технічна можливість проводити транзакції через цього провайдера. Які саме платіжні методи ми використовуватимемо — це вже інше рішення та інша мета. Наприклад, у Stripe є карткові платежі, buy-now-pay-later та інші локальні методи.
Підключення провайдера — це один процес.
Підключення конкретного payment method — інший.
В межах великого процесу — наприклад «вихід на новий ринок» — ці дії можуть бути етапами:
1. підключити провайдера
2. підключити доступні в цій країні платіжні методи
Але всередині одного BPMN-процесу змішувати такі цілі не варто.
Або візьмемо фінтех. На перший погляд здається, що реєстрація клієнта, KYC, антифрод і онбординг — це все один процес. Але якщо подивитися на мету, стає зрозуміло, що це різні речі. Антифрод і KYC мають одну мету — переконатися, що перед нами людина, з якою бізнес може безпечно працювати. Що вона не під санкціями, не пов’язана з ризиковими схемами та не є ботом, створеним для зловживань.
Онбординг має зовсім іншу мету — навчити користувача працювати з сервісом, пояснити можливості продукту й допомогти почати користуватися ним ефективно. Це різні цілі, різні рішення та різна логіка:
— антифрод має відбутися до рішення про співпрацю
— онбординг — після
В межах одного верхньорівневого процесу «залучення нового користувача» вони можуть існувати поруч. Але як детальні BPMN-процеси — це краще відображати різними діаграмами.
Якщо ж в одному процесі опиняються декілька бізнес-цілей, такий процес складно тестувати й майже неможливо коректно вимірювати. Різні цілі — це різні метрики успіху. Наприклад, для підключення платіжного провайдера успіхом буде API, який працює, опція провайдера на UI, можливість проводити транзакції та зрозуміла комісія і вартість інтеграції. А для платіжного методу метрики будуть зовсім іншими: які картки приймаються, швидкість транзакцій, відсоток помилок і стабільність конкретного методу.
Як перевірити «чистоту мети» процесу? Поставте прямі запитання:
— яка одна ключова мета цього процесу?
— які метрики показують, що процес виконаний успішно?
— чи це один логічний набір показників, чи кілька різних?
Якщо метрик кілька і вони описують різні результати — швидше за все, перед вами кілька процесів.
#3. Відокремлюйте події від дій
Подія описує те, що сталося (факт), незалежно від того, хто і що в цей момент робив. Дія — це активна робота, яку хтось виконує. Наприклад:
«Менеджер отримує заявку» — це не подія, бо тут є конкретна дія конкретної людини.
«Заявка отримана» — це подія, бо щось сталося, і після цього процес може рухатися далі.
Подія або відбулася, або ні. А дія завжди передбачає виконавця. У BPMN ці дві речі принципово різні, і їх дуже часто плутають, особливо у великих процесах.
Візьмемо приклад — служба підтримки інтернет-провайдера. Клієнт не може подзвонити й надсилає листа, що в нього не працює інтернет. Отримання цього листа — подія, message event. Саме з цього моменту стартує бізнес-процес:
— хтось із підтримки приймає звернення
— перевіряє, чи є загальна проблема в сегменті
— інформує клієнта про масовий збій або призначає виїзд майстра
Отримання повідомлення — це не дія підтримки. Це тригер, який запускає дії. Все інше — це задачі, які виконуються після того, як подія сталася.
#4. Завжди закривайте розгалуження
Ми не можемо перейти до наступного кроку бізнес-процесу, доки не зрозуміло, що відбулося в усіх релевантних гілках. Якщо процес розгалузився, він має або завершитися в кожній з гілок, або знову зійтися в контрольній точці. Відкриті гілки означають логічну помилку моделі.
Наприклад: документи повні — йдемо далі, документи не повні — запитуємо додаткову інформацію. Але перейти до наступного кроку можна лише тоді, коли документи стали повними. Тобто незалежно від сценарію — гілки мають зійтися в одній точці:
Як перевіряти правильність розгалужень? Користуйтеся простим правилом: поставте собі запитання, як мають виконуватись дії після розгалуження.
— Якщо дії мають виконуватися одночасно — використовуйте Parallel Gateway (AND).
— Якщо з кількох варіантів можна обрати лише один — це Exclusive Gateway (XOR). Неважливо, скільки варіантів: два чи десять. Якщо обирається тільки один шлях, це все одно XOR.
— Якщо можна обрати один, кілька або всі варіанти одночасно — використовуйте Inclusive Gateway (OR).
Виняток щодо злиття: якщо одна з гілок завершується End Event, її не потрібно з’єднувати з іншими. Процес у цій гілці просто закінчується, тоді як інші гілки продовжують виконуватися.
Наприклад, у процесах контролю якості часто використовується Inclusive Gateway (OR), тому що один продукт може потребувати кількох перевірок одночасно. Медичні вироби можуть проходити і стерилізаційну перевірку, і перевірку міцності. Звичайні ручки — лише одну базову перевірку. М’ячі — перевірку на герметичність і вагу.
Якщо завод виробляє складний продукт, який одночасно є медичним і потребує механічної перевірки, шлюз OR активує обидві відповідні гілки.
Перед відвантаженням на склад усі запущені перевірки мають зійтися в шлюзі OR на вході. Цей шлюз працює як точка синхронізації: він «чекає», доки завершаться всі перевірки, які були запущені. Лише після цього процес переходить далі — до підбиття підсумків, розрахунку відсотка браку та формування партії для дистрибуції.
#5. Показуйте ролі через пули та доріжки, а не текстом
Якщо для розуміння того, хто що робить, потрібні текстові пояснення, коментарі або примітки — модель уже перевантажена. І найчастіше це означає, що пули та доріжки або не використовуються, або використовуються неправильно.
Доріжки в BPMN-моделях використовуються для ролей або відділів усередині однієї організації. Пули — для різних систем, компаній або окремих учасників процесу, які діють незалежно.
Між доріжками передається виконання процесу — sequence flow. Це означає, що робота логічно переходить від однієї ролі до іншої в межах однієї організації. Між пулами процес не виконується — передаються лише повідомлення, тому там використовується message flow. Поява пулів одразу показує, що це взаємодія різних сторін, а не один замкнений процес. Це змінює сприйняття моделі та прибирає багато питань без додаткових пояснень.
Наприклад, у research-процесі Researcher, Legal та IP Registry оформлюються через пули, бо частина роботи відбувається всередині організації, а частина — у зовнішній незалежній структурі. Researcher готує матеріали, legal-департамент перевіряє їх, а IP Registry отримує запит, проводить власну перевірку і повертає результат — підтвердження, запит на уточнення або відмову. В такому процесі нормально одночасно використовувати й доріжки, і пули.
Скільки пулів та доріжок має бути в процесі? Стільки, скільки потрібно, щоби було зрозуміло, хто за що відповідає. Головне — щоб логіка була послідовною. Тоді взаємодія через message flow читається без додаткових пояснень.
#6. Виносьте складну логіку в підпроцеси або DMN
Людський мозок може одночасно тримати в полі зору приблизно 10 об’єктів. Якщо їх більше, навіть досвідчений користувач може загубитися. Тому головне завдання — не просто показати всі деталі, а організувати інформацію так, щоб вона вміщалась на екран.
Інакше поки ви дійдете до кінця діаграми, аудиторія вже забуде, де ви почали, де є зараз і коли процес закінчиться. В таких умовах дуже складно обговорювати логічні частини процесу, знаходити неузгодженості та отримувати практичні коментарі.
Особливо складно стає, коли в процесі намагаються відобразити всю логіку ухвалення рішень:
У BPMN це зазвичай виглядає через XOR-, OR-, AND-шлюзи, і діаграма швидко перетворюється на «снігову лавину». Вона росте, множиться і часом нікому не зрозуміла — навіть тим, хто її розробляв. Тож краще створити кілька підпроцесів, які можна відкрити й вивчити за потреби, або винести складну логіку в DMN-таблиці.
Наприклад, в e-commerce та інших бізнесах часто використовується динамічне ціноутворення: різні регіони, валюти, пристрої (iPhone vs Android) і сегменти клієнтів. Якщо все це намагатися показати через шлюзи BPMN, діаграма швидко розростеться.
Замість цього краще використати DMN-таблицю. В BPMN залишається одна дія — «Визначити актуальну ціну», а деталі розрахунку — умови → значення, правила для регіону, сегменту, пристрою — відображаються в DMN.
#7. Кожна модель має проходити перевірку «читання без пояснень»
Кожна діаграма створюється для роботи з нею, а не для зберігання в шухляді. Вона призначена для конкретного користувача та аудиторії, з якою будуть працювати. Наприклад:
🧑💻 Технічні команди бачать інтеграції та залежності
🧑💼 Керівники бачать вузькі місця і втрати часу
👥 Менеджери бачать, хто що робить і коли
Обов’язково створюйте легенду для діаграм, де показуйте:
Якщо людина побачила легенду, але дивиться на діаграму і все одно не може зрозуміти, що відбувається, знаючи, де дія / подія / перехід відповідальності / повідомлення, — це проблема.
Наприклад, для керівника BPMN-модель — це не інструкція «хто що робить», а спосіб побачити, де бізнес втрачає час, рішення або відповідальність. Коли процес описаний зрозуміло, керівник одразу помічає ролі або підрозділи, через які проходить забагато рішень, точки, де рішення накопичуються або постійно відкладаються. А ще — місця, де відповідальність розмита або передається кілька разів без явного результату.
На цьому рівні видно не окремий bottleneck в одному процесі, а повторюваний патерн: одна і та сама роль гальмує кілька процесів одночасно. Це сигнал про проблему в дизайні процесів або розподілі відповідальності.
Завдяки цьому керівник може ухвалювати рішення:
— де потрібні додаткові ролі або делегування
— які процеси варто спростити або об’єднати
— де рішення можна винести на інший рівень, щоб зменшити затримки
BPMN — це «спільна мова», яка допомагає навести лад у процесах і зробити так, щоби бізнес, аналітики та ІТ говорили одне з одним без перекладачів. Сам собою стандарт не закриє всі проблеми, але він дає міцний фундамент для аналізу та оптимізації.
Розібратися в BPMN глибше можна на курсі Галини «Нотації BPMN». Буде робота з реальними кейсами та уроки зі створення моделей, які можна ефективно використовувати в бізнесі.
