Бізнес – це суцільний потік рішень. Від простих «чи надавати знижку цьому клієнту?» до складних «чи схвалювати багатомільйонний кредит?». Часто ці рішення приймаються на основі заплутаних правил, досвіду окремих співробітників чи навіть інтуїції.
А що, якби існував спосіб зробити ці правила кришталево прозорими, зрозумілими для всіх і, головне, легко керованими та автоматизованими? Зустрічайте DMN (Decision Model and Notation) – стандарт, який разом із BPMN (Business Process Model and Notation) та CMMN (Case Management Model and Notation) утворює справжній "золотий тріумвірат" для моделювання та автоматизації бізнес-процесів та операцій.
У цьому блозі ми розберемося, що таке DMN, і чому його поєднання з BPMN та CMMN – це справжня суперсила для вашого бізнесу.
Що таке стандарт DMN, і навіщо він потрібен, якщо є BPMN?
BPMN — знайомий багатьом інструмент для опису бізнес-процесів у вигляді зрозумілих блок-схем. Наприклад: отримали заявку → перевірили дані → погодили → повідомили клієнта. Все чітко, логічно й прозоро.
Але ось нюанс: коли ми кажемо «перевірили дані», що саме мається на увазі? Як система чи співробітник вирішує, що дані правильні? За яким принципом заявка потрапляє до керівника А, а не Б? У BPMN на такі запитання відповісти складно.
Можна, звісно, спробувати прописати всю логіку розгалужень у самій діаграмі — але щойно правил стане більше, схема перетвориться на щось дуже схоже на павутину. І розібратись у ній зможе хіба автор.
У таких ситуаціях на допомогу приходить стандарт прийняття рішень DMN – Decision Model and Notation. Це стандарт, створений спеціально для моделювання бізнес-рішень і правил, за якими ці рішення приймаються.
DMN – мапа логіки рішень
Уявіть, що BPMN описує, коли слід приймати рішення. А DMN – як саме ці рішення приймаються. Це дозволяє:
- Відокремити логіку від процесу. Ви розділяєте потік дій і логіку прийняття рішень. Завдяки цьому і процес, і рішення легше зрозуміти, підтримувати та змінювати.
- Зробити правила прозорими. Вони більше не “заховані” у коді чи головах експертів – все викладено у зрозумілій формі.
- Швидко вносити зміни. Якщо змінились умови – наприклад, оновились правила надання знижок, – достатньо змінити лише DMN-модель. Основний процес BPMN лишається незмінним.
Як це працює: діаграми і таблиці
У DMN є два основні інструменти:
- Діаграма вимог до рішень (Decision Requirements Diagram, DRD)
Це загальний огляд: які рішення потрібно прийняти, які дані потрібні, які джерела знань використовуються. Наприклад: щоб визначити кредитний ліміт, спершу треба знати доходи клієнта і оцінити ризик. DMN показує ці залежності. - Таблиці рішень (Decision Tables)
Найзручніший спосіб описати логіку. У стовпчиках – умови, у рядках – правила. Як у цьому прикладі:
| Статус клієнта | Сума замовлення | Знижка (%) |
|---|---|---|
| VIP | > 10 000 грн | 15% |
| VIP | ≤ 10 000 грн | 10% |
| Постійний | > 5 000 грн | 7% |
| Постійний | ≤ 5 000 грн | 5% |
| Новий | будь-яка | 0% |
Зрозуміло, зручно і не треба залазити в код. А якщо правила складніші — у DMN є мова FEEL (Friendly Enough Expression Language), яка дозволяє описувати логіку у вигляді формул, близьких до людської мови.
А як щодо кейсів? Тут з’являється CMMN
У бізнесі багато процесів не такі чіткі, як подача заявки. Наприклад, розслідування інциденту, розгляд скарги чи запуск нового продукту – тут не завжди зрозуміло, що робити далі. Такі ситуації називають кейсами.
Щоб їх моделювати, є інший стандарт – CMMN (Case Management Model and Notation). Він не диктує жорстку послідовність кроків, а описує можливі дії, які виконуються залежно від подій, даних і рішень.
І тут DMN знову незамінний. Бо всередині кейсу часто потрібно прийняти рішення: чи достатньо даних? Чи є ризики? Чи потрібен додатковий етап перевірки? Усі ці рішення теж описуються через DMN, і CMMN просто “викликає” відповідні моделі.
Сила трьох: стандарт DMN + BPMN + CMMN
Окремо кожен з цих стандартів корисний. Але справжня магія починається, коли вони працюють разом:
- BPMN описує чіткі процеси: що робити і в якій послідовності.
- CMMN – кейси, де шлях залежить від обставин.
- DMN – як приймаються рішення в межах процесів і кейсів.
Уявіть реальну ситуацію:
- Ви моделюєте процес подачі заявки (BPMN).
- На певному етапі треба перевірити кредитоспроможність – це окреме рішення (DMN).
- Якщо сума занадто велика чи є підозри, запускається розслідування (CMMN).
- У цьому розслідуванні теж можуть бути рішення – наприклад, чи передавати справу далі.
Чому це важливо
- Прозорість. Усі правила, процеси і сценарії задокументовані. Легше навчати нових працівників, проходити аудит, координувати дії між командами.
- Гнучкість. Зміни в логіці не вимагають переробки всього процесу. Можна швидко адаптуватися до нових умов.
- Єдині правила. Те саме рішення приймається однаково – незалежно від людини чи системи, контексту чи етапу.
- Легка автоматизація. Low-code платформи дозволяють «взяти» DMN-модель і одразу виконати її без програмування.
- Краще розуміння між бізнесом і IT. Таблиці рішень зрозумілі всім – і менеджерам, і розробникам.
- Контроль і відповідність. Ви чітко бачите, як приймаються рішення, і можете легко пояснити це регуляторам чи аудиторам.
Як це виглядає на low-code платформі?
У редакторі ви створюєте модель процесу (BPMN). На етапі «Оцінка кредитоспроможності» додаєте задачу «Прийняття рішення» й підключаєте до неї DMN-модель із прописаними правилами: вік, дохід, історія → рішення (Схвалити / Відхилити / Ручна перевірка). Платформа сама передає дані у DMN, виконує логіку й повертає результат назад у процес.
Те саме працює і з кейсами. У потрібний момент CMMN викликає DMN для прийняття рішення – і робота триває.
Висновок
DMN – не просто ще один технічний стандарт. Це ключ до прозорих, послідовних і автоматизованих рішень. У парі з BPMN та CMMN він дозволяє не лише впорядкувати бізнес, а й зробити його гнучким і адаптивним.
Інтеграція цих трьох стандартів – це шлях до створення систем, де процеси логічні, кейси гнучкі, а рішення приймаються прозоро, послідовно та швидко. І сучасні low-code платформи, як Scriptum, роблять впровадження цього «золотого тріумвірату» доступним як ніколи раніше.