Нотації BPMN та DMN в межах Бібліотеки процесів

2.4.1. Опис нотації BPMN

Завдяки компонентам BPMN 2.0 ви можете легко моделювати бізнес-процеси, створюючи чіткі і зрозумілі схеми, які стають основою для їх автоматизації. BPMN служить проміжною ланкою між формалізацією/візуалізацією та впровадженням бізнес-процесів, допомагаючи вам краще розуміти і керувати вашими процесами.

Користуючись нотацією BPMN, ви зможете використовувати різноманітні графічні елементи для побудови схеми бізнес-процесів.

Діаграми BPMN містить наступні основні елементи:

• Ролі або зони відповідальності: пул/доріжки (див. розділ Пул/Доріжка
• Об'єкти потоку управління: події, дії та логічні оператори
• З'єднуючі об'єкти: потік управління, потік повідомлень та асоціації
• Артефакти: дані, групи та текстові анотації.

2.4.1.1. Пул/доріжка

Завдяки елементам Пул і Доріжка ви можете відображати взаємодію учасників процесу під час його виконання.

• Пул — це сукупність усіх операцій процесу та осіб, відповідальних за їх виконання. Він слугує для визначення меж процесу, надаючи вам чітке уявлення про всі етапи і відповідальних учасників.
• Доріжка використовується для відображення конкретних виконавців або ролей у процесі. У межах одного пулу може бути кілька доріжок, що допомагає вам детально показати, хто за що відповідає на кожному етапі процесу.

Таким чином, за допомогою Пулів і Доріжок ви зможете чітко і наочно організувати й показати взаємодію та відповідальність учасників бізнес-процесу. У кожній доріжці розташовуються дії, що виконуються одним виконавцем.

2.4.1.2. Дії

Дія у бізнес-процесі означає одиницю роботи, що виконується в його ході. Дії можуть бути простими (завдання) або складними (підпроцес).

BPMN передбачає наступні графічні позначення для основних типів дій:

• Абстрактне завдання
• Завдання отримання повідомлення
• Завдання користувача
• Завдання бізнес-правило
• Завдання сервіс
• Завдання-сценарій
• Викликаюча дія (Процес-посилання)
• Підпроцес
  • Згорнутий
  • Розгорнутий

Абстрактне завдання використовується для позначення простої дії або операції, яка не має подальшої декомпозиції в межах поточного бізнес-процесу.

Завдання отримання повідомлення використовується для відображення кроку процесу, який очікує отримання повідомлення з певним кодом.

Завдання користувача використовується для відображення завдання, яке виконує людина.

Завдання бізнес-правило використовується для виклику бізнес-правил (DMN діаграми).

Завдання сервіс використовується для виклику методів, отримання даних з сутностей, оновлення об'єктів або відправки email.

Завдання-сценарій використовується для відображення кроку процесу, при досягненні якого автоматично виконується скрипт.

Викликаюча дія (Процес-посилання) використовується для позначення посилання на один з процесів.

Підпроцес використовується для відображення складного процесу, що включений до поточного процесу. Підпроцес може бути:

• Згорнутий: діаграма не відображає деталі підпроцесу.

  

• Розгорнутий: діаграма відображає деталі підпроцесу.

  

2.4.1.3. Події

Подія є одним з основних елементів BPMN і описує те, що має статися (на відміну від завдання, яке описує те, що має бути зроблено).

Наприклад: Подією може бути підписання договору або розмова з клієнтом.

Графічні елементи подій у BPMN класифікуються за двома критеріями:

• Залежно від положення події на схемі процесу (див. розділ Положення події на схемі процесу)
• За типом події (див. розділ Основні типи подій)

2.4.1.3.1. Положення події на схемі процесу:

• Початкова подія ініціює бізнес-процес.

  

• Проміжна подія

  

• Завершальна подія завершує бізнес-процес.

  

2.4.1.3.2. Основні типи подій

• Прості події — це не типізовані події, які використовуються, найчастіше, для того, щоб показати початок або завершення процесу.

  

• Події-повідомлення показують отримання і відправку повідомлень в ході виконання процесу.

  

• Події-таймери моделюють події, регулярно відбуваються у часі. Також дозволяють моделювати моменти часу, періоди і тайм-аути.

  

• Події-ескалації перенесення розгляду задачі на вищий рівень організаційної ієрархії.

  

• Події-умови дозволяють інтегрувати бізнес правила у процес.

  

• Події-помилки дозволяють змоделювати генерацію й обробку помилок в процесі. Помилки можуть мати різні типи.

  

• Події-посилання використовуються для міжсторінкових з'єднань. Пара відповідних посилань еквівалентна потоку управління.

  

• Події-компенсації ініціюють компенсацію або виконують дії по компенсації.

  

• Події-сигнали розсилають і приймають сигнали між декількома процесами. Один сигнал може оброблятися кількома одержувачами. Таким чином, події сигнали дозволяють реалізувати трансляцію розсилання повідомлень.

  

• Події-зупинники призводять до негайного завершення всього бізнес-процесу (у всій діаграмі).

  

2.4.1.3.3. Змінити тип доданої події

1. У меню елементів, виберіть потрібне положення події (Початкова, Проміжна чи Завершальна).

   

2. Клацніть на додану подію, а потім у контекстному меню, виберіть піктограму .

   

3. У списку Змінити тип елемента, виберіть потрібний тип події. (Див. розділ Основні типи подій).

   

2.4.1.4. Оператори

Оператори — це елемент моделювання, який використовується для контролю потоку виконання процесу на основі певних умов або подій. Оператори визначають, як процес розгалужується або зливається в точках прийняття рішень. Вони допомагають керувати складністю процесу, забезпечуючи більш гнучке і чітке моделювання бізнес-процесів. Оператор можна уявити як пропускний пристрій, який або пропускає потік, або ні.

2.4.1.4.1. Додати оператор

1. Перейдіть в режим створення бізнес-процесу.

2. У меню елементів, виберіть піктограму , а потім клацніть на місце у формі, куди потрібно вставити оператор.

   

2.4.1.4.2. Змінити тип оператора

1. Додайте оператор у форму створення бізнес-процесу (див. розділ Додати оператора).

2. Клацніть на доданий оператор, а потім у контекстному меню, виберіть піктограму .

   

3. У контекстному меню, оберіть потрібний тип оператора (див. розділ Типи операторів).

   

2.4.1.4.3. Типи операторів

• Оператор виключного АБО, що керуються даними. При розгалуженні оператор активує один із вихідних потоків. При об'єднанні — очікує завершення одного вхідного потоку і активує вихідний потік.

  Приклад застосування: У процесі затвердження запиту на відпустку, Після того, як керівник розглядає запит, використовується Оператор виключного АБО для перевірки, чи затверджено запит. Якщо так, процес переходить до затвердження; якщо ні — переходить до відхилення.

  

• Оператор І. При розгалуженні оператор активує всі вихідні потоки. При об'єднанні — очікує завершення всіх вхідних потоків і активує вихідний потік.

  Приклад застосування: У процесі виплати зарплати, після розрахунку зарплати використовуємо Оператор І, щоб одночасно надіслати повідомлення працівнику і бухгалтерії.

  

• Оператор АБО. При розгалуженні активує один або більше вихідних потоків. При об'єднанні всі запущені вхідні потоки повинні бути завершені.

  Приклад застосування: У процесі обробки замовлення, після підтвердження замовлення використовуємо Оператор АБО для перевірки, чи потрібно надсилати товар кур'єром і чи потрібно надсилати рахунок електронною поштою. Обидва шляхи можуть виконуватись одночасно або окремо.

  

• Складний оператор. Моделює складні умови розгалуження та злиття. Може включати логіку з використанням кількох умов і правил.

  Приклад застосування: У процесі погодження проєкту, після етапу рецензування використовуємо Складний оператор для перевірки, чи потрібно затвердити проєкт тільки після отримання коментарів від обох рецензентів або якщо рецензент "A" надав особливий дозвіл.

  

• Оператор, що керується подіями — вибирає подальший потік на основі події, яка відбулася першою. Використовується, коли напрямок потоку залежить від зовнішньої події. Напрямок диктується тим, яка була здійснена подія, а не тим, яка була виконана умова.

  Приклад застосування: У процесі обробки технічної підтримки, після отримання запиту використовуємо оператор, що керується подіями, для визначення подальших дій на основі того, чи клієнт відповів на запит, або минув час очікування.

  

2.4.1.5. Потоки

Потік – це послідовність дій, яка позначається стрілкою. Елемент потік показує послідовність дій у бізнес-процесі.

2.4.1.5.1. Додати потік

Щоб підʼєднати один елемент процесу до іншого елементу, використовуйте потоки.

Щоб додати потік між двома елементами, виконайте наступні дії:

1. Клацніть на один з доданих елементів, а потім у контекстному меню виберіть піктограму .

   

2. Клацніть на другий елемент, до якого потрібно підʼєднати попередній елемент.

   

2.4.1.5.2. Змінити тип потоку

1. Клацніть на доданий потік, а потім у контекстному меню виберіть піктограму .

   

2. У контекстному меню виберіть необхідний тип потоку (див. розділ Типи потоків).

   

2.4.1.5.3. Типи потоків

• Потік керування – це стандартний потік, який не залежить від умов і не проходить через оператори, тобто є неконтрольованим.

  

• Потік за замовчуванням використовуйте, щоб показати, що подальше виконання процесу буде відбуватися за певним потоком, тільки якщо не виконується жодна з заданих умов.

  

• Умовний потік використовуйте, щоб показати, що процес буде виконуватись за цим потоком, тільки якщо задана умова виконана. Якщо умовний потік є вихідним від процесу, біля основи стрілки додається ромбик. Якщо умовний потік є вихідним від оператора, ромбик не додається.

  

2.4.1.6. Артефакти

Артефакти — це об'єкти, які не впливають на виконання бізнес-процесу безпосередньо. У BPMN артефакти використовуються для додаткового опису і доповнення бізнес-процесів. Вони допомагають робити моделі більш зрозумілими, деталізованими і інформативними.

Основними типами артефактів у BPMN є:

2.4.1.6.1. Типи артефактів

• Анотації. Використовуються для додавання коментарів або додаткової інформації до елементів моделі. Вони допомагають пояснити або деталізувати певні аспекти процесу, забезпечуючи кращу зрозумілість для тих, хто аналізує або використовує модель.

  

• Групи. Використовуються для візуального групування елементів моделі процесу з метою кращої організації і зрозумілості. Групи не впливають на послідовність виконання процесу.

  

• Дані. Використовуються для відображення інформації, яка обробляється або передається в межах процесу. Платформа містить наступні артефакти цього типу:

  • Створити посилання на обʼєкт даних — використовуйте, щоб відобразити конкретну одиницю інформації, яка використовується або створюється в межах процесу. Об'єкти даних можуть бути документами, файлами або іншими типами інформаційних об'єктів, які передаються між етапами процесу.

  • Створити посилання на сховище даних — використовується, щоб відобразити місце зберігання інформації, яке існує поза межами поточного процесу, але до якого процес може звертатися для зберігання або отримання даних. Це може бути база даних чи файлова система.

    

.

2.4.2. Опис нотації DMN

DMN (Decision Model and Notation) – це один з трьох стандартів для моделювання аспектів бізнес-процесів, що використовується у платформі Scriptum. DMN застосовується для створення і автоматизації правил прийняття рішень, забезпечуючи чітку і зрозумілу логіку прийняття рішень. Див. також детальне визначення DMN та розділ Виконати DMN.

Завдяки DMN ви зможете:

• Допомогти всім зацікавленим сторонам зрозуміти складну сферу.
• Приймати рішення за допомогою діаграм, які легко читати.
• Зменшити ризики проєктів автоматизації прийняття рішень за рахунок графічної декомпозиції вимог.
• Подати просте та достовірне визначення бізнес-правил у недвозначних таблицях рішень.
• Спростити розроблення систем прийняття рішень з використанням специфікацій, які можуть бути автоматично перевірені та виконані.

Щоб налаштувати логіку прийняття рішень, скористайтесь Таблицею рішень. Таблиця рішень використовується для відображення правил прийняття рішень у табличному форматі. Вона визначає, які дії виконуються на основі певних умов. Таблиця містить набори вхідних і вихідних параметрів та додаткових атрибутів, що визначають правила роботи з ними.

Таблиця рішень складається з наступних компонентів:

1. Назва — визначає таблицю рішень та її мету.

2. Метод спрацьовування (Hit Policy) — визначає, як обираються результати, якщо кілька правил можуть бути застосовані. Основні варіанти:

   • Unique — рішення має завжди формувати одне, унікальне рішення (перетин не допускається);
   • First — застосування одного рішення;
   • Collect Sum — сумарне застосування.

3. Вхідні змінні (Input expression). Їхні конкретні значення — input entry.

4. Вихідні дані (Output expression) для кожного можливого набору вхідних даних (input entry) визначають вихідну змінну (output entry).

5. Анотація (Annotations) — текст, який використовується для пояснення правил. Анотації не автоматизуються.

6. Правила (Rules) — набір вхідних і вихідних даних, які формують рядки таблиці. Кожне правило має номер.

   

Таблицю прийняття рішення надалі можна викликати з бізнес-процесу BPMN, передати вхідні дані та отримати вихідні, залежно від налаштованих умов. Це дозволяє значно оптимізувати схему бізнес-процесу за рахунок використання посилання на DMN замість використання операторів.