Моделювання процесів: IDEF0, BPMN, UML. BR-діаграми

Тема 3: Бізнес-аналіз та вимоги до ІТ-продуктів · Заняття 2

1. Методологія IDEF0: принципи, нотація, контекстна діаграма

1.1. Призначення

IDEF0 — методологія функціонального моделювання, що описує систему як сукупність функцій та їх взаємозв’язків. Вона відповідає на питання «що робить система» (функції), а не «як» чи «в якому порядку». IDEF0 корисна для верхньорівневого погляду й декомпозиції складних процесів.

1.2. Нотація (ICOM)

Основний елемент — прямокутник (функція, дієслово). Стрілки описують зв’язки за принципом ICOM:

Стрілка	Значення (сторона блоку)
Input (вхід)	Що перетворюється функцією (ліва сторона).
Control (керування)	Правила, нормативи, обмеження (верхня сторона).
Output (вихід)	Результат функції (права сторона).
Mechanism (механізм)	Хто/чим виконує: люди, системи (нижня сторона).

1.3. Контекстна діаграма та декомпозиція

Моделювання починають з контекстної діаграми (A-0) — один блок, що описує систему в цілому, з зовнішніми входами, виходами, керуванням і механізмами. Далі блок декомпозують на підфункції (A0, потім A1, A2…), зберігаючи узгодженість стрілок між рівнями.

Приклад. Контекстна функція «Вести облік майна»: Input — надходження/списання майна; Control — накази, нормативи обліку; Output — актуальні дані обліку; Mechanism — відповідальний, система обліку.

1.4. Правила побудови

функції — дієсловами («вести облік», «проводити інвентаризацію»);
узгодженість стрілок між рівнями декомпозиції;
3–6 блоків на діаграмі (не перевантажувати);
кожна стрілка має джерело й призначення.

1.5. Коли застосовувати IDEF0

IDEF0 доречна на початку аналізу, коли треба охопити систему «згори» — які функції вона виконує, що на вході/виході, за якими правилами й хто виконує, — без деталей послідовності. Для детального аналізу «як саме відбувається процес у часі» переходять до BPMN. Часто IDEF0 і BPMN використовують разом: IDEF0 — для загальної картини, BPMN — для деталізації окремих функцій.

Типові помилки:

опис послідовності дій (це не завдання IDEF0 — для цього BPMN);
перевантаження діаграми блоками;
неузгоджені стрілки між рівнями.

Проміжний висновок: IDEF0 дає функціональний, верхньорівневий погляд «що робить система» через блоки й ICOM-стрілки.

2. Нотація BPMN: події, активності, шлюзи, потоки, доріжки

2.1. Призначення

BPMN (Business Process Model and Notation) — стандарт моделювання бізнес-процесів, що описує послідовність дій, події, розгалуження та учасників. На відміну від IDEF0, BPMN показує «як відбувається процес у часі». Це найпоширеніша нотація для аналізу процесів.

2.2. Базові елементи

Елемент	Позначення	Значення
Подія (event)	Коло.	Початок, проміжна подія, кінець процесу.
Активність (task)	Прямокутник із заокругленнями.	Дія/робота у процесі.
Шлюз (gateway)	Ромб.	Розгалуження/об’єднання потоку.
Потік послідовності	Суцільна стрілка.	Порядок виконання.
Потік повідомлень	Пунктирна стрілка.	Обмін між учасниками.
Доріжка (pool/lane)	Смуга.	Учасник/роль, що виконує дії.

2.3. Типи подій і шлюзів

Події — події: стартова (тонке коло), проміжна (подвійне коло), кінцева (жирне коло); за типом — таймер, повідомлення, помилка;
Шлюзи — шлюзи: виключний (XOR — один із шляхів за умовою), паралельний (AND — усі шляхи одночасно), інклюзивний (OR — один або кілька).

2.4. Потоки повідомлень та даних

Потік послідовності (суцільна стрілка) показує порядок дій у межах одного учасника; потік повідомлень (пунктир) — обмін між різними учасниками (доріжками). Об’єкти даних показують, які документи/дані використовуються.

2.5. Правила читання й побудови

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

2.6. Розширені елементи

Підпроцес (subprocess) — згорнута активність, що містить власний процес (для спрощення схеми верхнього рівня);
Типи задач — користувацька (виконує людина), сервісна (виконує система), ручна, скриптова — уточнюють характер дії;
Гранична подія — прикріплена до активності подія (напр., таймер), що перериває її за настання;
Об’єкт даних — документи/дані, що використовуються або створюються активністю.

На практиці спочатку будують «кістяк» процесу (події, активності, шлюзи), а потім за потреби уточнюють типи задач і додають підпроцеси, щоб не перевантажувати схему.

Типові помилки:

процес без стартової/кінцевої події;
розгалуження без умов на шлюзах;
змішування потоків послідовності й повідомлень.

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

3. UML-діаграми для аналізу вимог: Use Case, Activity, Sequence

3.1. UML в аналізі

UML (Unified Modeling Language) — мова моделювання, частину діаграм якої BA використовує для аналізу вимог (не лише для проєктування системи).

3.2. Use Case Diagram

Показує, хто (актори) і що (варіанти використання) робить із системою. Актор — роль користувача або зовнішня система; use case — функція, корисна актору. Зв’язки: асоціація, include (обов’язкове включення), extend (розширення). Корисна для окреслення обсягу функцій системи.

Приклад. Актор «Відповідальний за облік» — use cases: «внести майно», «провести інвентаризацію», «сформувати звіт».

3.3. Activity Diagram

Показує потік дій із розгалуженнями та паралелізмом — близька до BPMN, але з UML-нотацією. Корисна для опису логіки окремого сценарію (алгоритму дій).

3.4. Sequence Diagram

Показує взаємодію учасників/об’єктів у часі (хто кому й у якій послідовності передає повідомлення). Корисна для опису сценаріїв взаємодії між системами чи ролями.

3.5. Коли яку діаграму застосовувати

Діаграма	Коли доречна
Use Case	Окреслити обсяг функцій і акторів системи.
Activity	Описати логіку/алгоритм окремого сценарію.
Sequence	Описати взаємодію учасників у часі.

3.6. Основний та альтернативні сценарії Use Case

Кожен use case має основний сценарій (успішний шлях) і альтернативні (відхилення, помилки, винятки). Опис сценаріїв — місток до детальних Use Cases на Занятті 4.

Приклад. Use case «Провести інвентаризацію»: основний сценарій — звірка без розбіжностей; альтернативний — виявлено розбіжність → складання акта; винятковий — недоступна система → ручна звірка.

Типові помилки:

використання UML «для краси» без потреби;
змішування рівнів (use case з деталями реалізації);
дублювання того, що вже показано у BPMN.

Проміжний висновок: UML-діаграми (Use Case, Activity, Sequence) доповнюють BPMN, описуючи обсяг функцій, логіку сценаріїв і взаємодію.

4. BR-діаграми: призначення, правила читання та побудови

4.1. Призначення

BR (Business Rules) — бізнес-правила, що визначають обмеження й логіку прийняття рішень у процесі («якщо…, то…»). BR-діаграми/таблиці систематизують ці правила окремо від процесу, щоб їх було легко переглядати й змінювати.

4.2. Форми подання

Бізнес-правила подають у вигляді структурованих тверджень або таблиць рішень (decision tables): умови → дії. Це робить логіку явною й перевірюваною.

Приклад. Правило: «Якщо позиція майна не звірялася понад 12 місяців — позначити для позачергової інвентаризації».

4.3. Зв’язок із процесами

BR виносять логіку рішень зі схеми процесу: на BPMN залишається шлюз «перевірити правило», а самі правила описані окремо. Це спрощує процес і полегшує зміну правил без переробки всієї моделі.

Типові помилки:

«зашивання» складної логіки в схему процесу замість окремих BR;
нечіткі правила без явних умов і дій;
суперечливі правила.

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

Порівняння нотацій: коли що застосовувати

Нотації не конкурують, а доповнюють одна одну — кожна відповідає на своє питання про процес.

Нотація	Відповідає на питання	Коли застосовувати
IDEF0	Що робить система (функції)?	Верхньорівневий функціональний погляд, декомпозиція.
BPMN	Як відбувається процес у часі?	Детальний аналіз процесів, пошук неефективностей.
UML Use Case	Хто і що робить із системою?	Окреслення обсягу функцій.
UML Activity/Sequence	Яка логіка / взаємодія?	Опис сценарію або взаємодії учасників.
BR	За якими правилами ухвалюються рішення?	Винесення бізнес-логіки окремо.

На практиці BA найчастіше використовує BPMN для процесів, доповнюючи його Use Case (обсяг) і BR (правила).

5. Практична вправа: побудова BPMN-моделі процесу підрозділу ЦТ

Мета вправи: слухачі будують BPMN-модель реального бізнес-процесу свого підрозділу (або наскрізного прикладу — процесу обліку майна).

Вихідні дані: опис процесу; довідник BPMN (Додаток 2); приклад моделі (Додаток 4).

Форма роботи: у парах, з подальшою презентацією 2–3 моделей.

Порядок виконання

Визначити межі процесу: стартова та кінцева події — 15 хв.
Виділити учасників (ролі) і рознести їх по доріжках — 15 хв.
Викласти послідовність дій (активності) від старту до кінця — 30 хв.
Додати шлюзи (розгалуження) з умовами та потоки повідомлень — 25 хв.
Перевірити модель за чек-листом (Додаток 5) і презентувати 2–3 роботи — 20 хв.

Еталонне проходження (зразок для викладача)

Процес «Інвентаризація майна» (BPMN, текстовий опис):

Старт: настання строку інвентаризації (подія-таймер).
Доріжка «Відповідальний»: «сформувати опис майна» → «звірити з фактом» → шлюз XOR «є розбіжності?».
Якщо так → «скласти акт розбіжностей» → «передати командиру»; якщо ні → «підтвердити дані».
Доріжка «Командир»: «розглянути акт» → «ухвалити рішення» (потік повідомлень до відповідального).
Кінець: «облік актуалізовано» (кінцева подія).

Методичні вказівки викладачу

Викладач перевіряє: (1) є стартова й кінцева події; (2) ролі рознесені по доріжках; (3) шлюзи мають умови; (4) дії — дієсловами. Для розбору обирає одну читану й одну перевантажену модель, показуючи, як спростити.

Контрольні питання

Що описує IDEF0 і що означають стрілки ICOM?
Назвіть базові елементи BPMN та поясніть різницю між типами шлюзів.
Чим потік послідовності відрізняється від потоку повідомлень у BPMN?
Які UML-діаграми використовує BA і для чого кожна?
Що таке BR-діаграми і навіщо виносити правила окремо від процесу?
Опишіть порядок побудови BPMN-моделі процесу.

Завдання на самостійну підготовку

Тема: Виявлення та категоризація проблем у поточних процесах.

Опрацювати метод «5 чому» та діаграму Ішикави для аналізу першопричин проблем.
Опрацювати шаблони фіксації проблем та їх кластеризацію для подальшого аналізу.
Побудувати BPMN-модель ще одного процесу свого підрозділу.

Довідка для підготовки:

«5 чому» — послідовно ставити питання «чому?» (≈5 разів), доходячи до першопричини, а не симптому;
Ішикава — діаграма «риб’ячий скелет»: групування можливих причин за категоріями (люди, процес, засоби, дані, середовище);
Шаблони — фіксувати проблеми уніфіковано (опис, наслідок, частота, категорія) і кластеризувати для пріоритезації.

Додаток 1. Довідник нотації IDEF0

Елемент	Значення
Блок (функція)	Дія/функція, названа дієсловом.
Input (ліва стрілка)	Що перетворюється.
Control (верхня)	Правила, нормативи, обмеження.
Output (права)	Результат.
Mechanism (нижня)	Хто/чим виконує.
A-0 / A0 / A1…	Рівні декомпозиції (контекст → деталі).

Додаток 2. Довідник нотації BPMN

Елемент	Вигляд	Значення
Стартова подія	Тонке коло.	Початок процесу.
Проміжна подія	Подвійне коло.	Подія в ході процесу (таймер, повідомлення).
Кінцева подія	Жирне коло.	Завершення процесу.
Активність	Заокруглений прямокутник.	Дія/робота.
Шлюз XOR	Ромб з «Х».	Один шлях за умовою.
Шлюз AND	Ромб з «+».	Паралельні шляхи.
Потік послідовності	Суцільна стрілка.	Порядок дій.
Потік повідомлень	Пунктирна стрілка.	Обмін між учасниками.
Доріжка (lane)	Смуга.	Роль/учасник.

Додаток 3. Довідник UML-діаграм для аналізу

Діаграма	Показує	Ключові елементи
Use Case	Обсяг функцій і акторів.	Актори, use cases, include/extend.
Activity	Потік дій сценарію.	Дії, розгалуження, паралелізм.
Sequence	Взаємодію в часі.	Учасники, повідомлення, порядок.

Додаток 4. Приклад BPMN-моделі (текстовий опис для розбору)

Процес «Інвентаризація майна»:

Старт (таймер): настав строк інвентаризації.
[Відповідальний] Сформувати опис майна → Звірити з фактом → Шлюз XOR «Є розбіжності?».
Гілка «Так»: Скласти акт розбіжностей → Передати командиру.
Гілка «Ні»: Підтвердити дані.
[Командир] Розглянути акт → Ухвалити рішення.
Кінець: Облік актуалізовано.

Додаток 5. Чек-лист якості BPMN-моделі та критерії оцінювання

Чек-лист:

Є стартова й кінцева події.
Ролі рознесені по доріжках.
Шлюзи мають умови; розгалуження об’єднуються.
Дії названі дієсловами.
Модель читається зліва направо й однозначна.

Критерії оцінювання:

Критерій	Бали	Орієнтир
Коректність нотації BPMN	0–3	Правильні події, шлюзи, потоки.
Повнота процесу (старт→кінець)	0–3	Немає розривів.
Ролі та розгалуження	0–2	Доріжки, умови на шлюзах.
Читаність і однозначність	0–2	Модель зрозуміла без пояснень.
Разом	0–10	9–10 «відмінно»; 7–8 «добре»; 5–6 «задовільно».

Додаток 6. Глосарій ключових термінів

IDEF0 — методологія функціонального моделювання (функції + ICOM).
ICOM — Input, Control, Output, Mechanism — типи стрілок IDEF0.
BPMN — нотація моделювання бізнес-процесів (у часі).
Шлюз (gateway) — елемент розгалуження/об’єднання потоку.
Доріжка (lane) — смуга учасника/ролі у BPMN.
UML — мова моделювання; для аналізу — Use Case, Activity, Sequence.
Use Case — варіант використання системи актором.
BR (business rules) — бізнес-правила: умови й дії прийняття рішень.
Таблиця рішень — подання правил у форматі умови → дії.
«5 чому» — метод пошуку першопричини послідовними питаннями.
Діаграма Ішикави — групування причин проблеми за категоріями.

Додаток 7. Приклад IDEF0-декомпозиції (текстовий опис)

Контекстна функція A-0: «Вести облік майна».

Input: надходження / списання майна;
Control: накази, нормативи обліку, вимоги ЗІ;
Output: актуальні дані обліку, звіти;
Mechanism: відповідальний, система обліку.

Декомпозиція A0 на підфункції:

A1 «Приймати/списувати майно» (input: документи руху; output: оновлені записи);
A2 «Проводити інвентаризацію» (control: строки; output: акти);
A3 «Формувати звіти» (input: записи; output: звіти командиру).

Стрілки між рівнями узгоджені: виходи A1/A2 стають входами A3; усі підфункції разом реалізують контекстну A-0.