• Лекція 4
• Візуальне моделювання бізнес-процесів
  • 4.1 Функціональне моделювання IDEF0
    • 4.1.1 Контекстна діаграма
    • 4.1.2 Декомпозиція
    • 4.1.3 Переваги і недоліки нотації
    • 4.1.4 CASE-засоби
  • 4.2 ARIS (ARchitecture of Integrated Information Systems)
    • 4.2.1 Структура моделі
      • Дії
      • Події
      • Логічні оператори
      • З'єднання
      • Ролі
      • Артефакти
    • 4.2.2 Переваги і недоліки
    • 4.2.3 CASE-засоби

Лекція 4

Візуальне моделювання бізнес-процесів

Базові визначення

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

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

Нотація – система умовних позначень, прийнята в будь-якій галузі знань або діяльності.

Семантика – система правил, яка визначає зміст та інтерпретацію конструкцій відповідної мови.

Методологія – сукупність методів, засобів та стратегій дослідження об’єкту/явища/процесу.

Бізнес-процес – структурований набір дій, який охоплює різні сутності підприємства і який підпорядкований певній меті [ISO 15531-1] .

Бізнес-процес – цілеспрямована сукупність пов’язаних дій, що відповідно до певної технології перетворює входи у виходи, які мають цінність для користувачів.

Опис бізнес-процесу – схематичне зображення діяльності компанії із певною метою.

Мета в програмній інженерії – автоматизація зображеного процесу.

Моделювання бізнес-процесів – графічний опис бізнес-процесів за допомогою діаграм у певних нотаціях.

Типи моделей бізнес-процесів

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

TO-BE – як має бути – модель, яка показує процес після запровадження запропонованих змін.

Should-BE – хотілось, щоб було так – модель бажаної організації процесу.

4.1         Функціональне моделювання IDEF0

IDEF0 – графічна нотація, яка використовується для виявлення структури і функцій бізнес-процесу, а також показу потоків інформації та матеріальних ресурсів, які пов'язують ці функції. Стандарт IDEF0 затверджений в США в 1993 як Федеральний стандарт обробки інформації [1]. IDEF0 є частиною методології структурного аналізу та проектування (Structured Analysis and Design Technique, SADT). До особливостей нотації IDEF0 можна віднести:

• використання контекстної діаграми;

• підтримка декомпозиції;

• виділення 4 типів потоків – Вхід (Input), Управління (Control), Вихід (Output) та Механізм (Mechanism).

Центральним елементом моделі IDEF0 є функція, яка на схемі відображається у вигляді функціонального блоку-прямокутника, всередині якого зазначено дію в формі іменника, який походить від дієслова (рис.1) [2].

Дія може бути різного масштабу - від діяльності компанії взагалі і до конкретного процесу зокрема. Приклади: «Виробництво і продаж програмного забезпечення» і «Розробка структури бази даних».

У кожного функціонального блоку повинна бути як мінімум одна стрілка з кожного боку (так як не може бути роботи без ресурсів або результатів, а також неповною буде дія без виконавця або інструкції).

Незалежно від масштабу дій всі функції відображаються однотипно і обов'язково містять 4 ключових потоки, які жорстко закріплені за сторонами функціонального блоку:

• зліва - входи або використовані ресурси для виконання функції;

• праворуч - виходи або результати виконання функції;

• зверху - керуючі впливи, які визначають, як і скільки потрібно сформувати результатів;

• знизу - механізми, які відображають, хто і за допомогою чого повинен виконати цю роботу.

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

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

 

4.1.1         Контекстна діаграма

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

Контекстна діаграма має наступні характеристики:

• мета – конкретне формулювання призначення моделі, із яким можна звіряти надалі точність побудови моделі.

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

• тип моделі - це вказівка на те, яка інформація відображена на схемах. Тут може бути 2 принципових варіанти: AS IS ( «як є») або TO BE ( «як буде»). Такий поділ необхідно, так як ми можемо будувати моделі як для аналізу діяльності, так і для її трансформації. Ми повинні чітко усвідомлювати те, що ми робимо, а також доносити цю інформацію до оточуючих.

Таким чином, контекстна діаграма містить в самому узагальненому вигляді опис діяльності компанії, яку пронизують потоки, що зв'язують компанію з зовнішнім світом.

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

• матеріальний: матеріали та комплектуючі на вході і готову продукцію на виході.

• клієнтський: потенційний клієнт на вході і задоволений на виході.

• фінансовий: на вході це зазвичай інвестиції, платежі клієнтів (виручка), кредити та інші доходи; на виході - це платежі постачальникам, податки, платежі по кредитах і прибуток.

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

Стрілки управління (Controls) є інформаційними потоками і можуть бути розбиті на 2 підвиди:

• документи, такі як:

  • закони та норми;

  • накази, розпорядження;

  • інструкції і регламенти;

  • плани;

  • конструкторська документація та ін.

• недокументована інформація, до якої найчастіше ставляться вимоги власників.

Механізми можуть бути двох видів:

• обладнання, інструменти (матеріальний);

• виконавці (підрозділи і люди).

Для навігації в моделі передбачена наскрізна нумерація. Контекстна діаграма нумерується «А-0». Надалі кожен функціональний блок отримує свій номер, який би глибокої не була декомпозиція.

4.1.2          Декомпозиція

Після визначення усіх потоків контекстної діаграми можна виконувати декомпозицію досліджуваного процесу. Перехід на рівень нижче (підвищення деталізації уявлення) ніби відкриває «чорний ящик». Саме тут відбувається функціональне моделювання – визначаєть, який набір дій може зв'язати визначені раніше потоки і забезпечити виконання всіх вимог. Складність полягає в тому, що дій в організації дуже багато, а на схемі ми можемо відобразити не більше 8-9 функцій, інакше схема стане нечитабельною.

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

• Створення продукту (результату).

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

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

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

Подальша деталізація моделі аналогічна першому кроку – проводиться декомпозиція кожного функціонального блоку першого рівня (рис.3). Нумерація блоків буде містити при цьому номер першого рівня: А11 ... А1n, A21 ... A2n і т.д.

4.1.3         Переваги і недоліки нотації

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

Модель дозволяє вибудувати потоки зв'язків між зовні не вочевидь пов'язаними речами: зв'язати підсистеми фронт і бек-офісів з керуванням, що складніше вдається іншим нотаціям.

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

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

• конкретизації подій запуску і зупинки процесу;

• умов переходу від одних дій до інших;

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

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

У проектному управлінні цей стандарт моделювання найбільш зручний для використання там, де потрібно зв'язати наочними потоками різні проекти або процеси. Графічна модель при цьому дозволяє раціонально розподілити відповідальність і ресурси за завданнями. Логіка виконання завдань проекту, відображена на схемах, допомагає підготувати більш якісний календарний план у вигляді діаграми Ганта.

 

4.1.4         CASE-засоби

Для побудови діаграм у нотації IDEF0 можна використовувати такі інструменти:

• Microsoft Visio – універсальний гріфічний редактор та радактор діаграм від компанії (https://products.office.com/uk-ua/visio/flowchart-software);

• Edraw Max Pro - редактор діаграм (https://www.edrawsoft.com/);

• BPwin – CASE-інструмент побудови бізнес-процесів в нотаціях IDEF0, IDEF3 та DFD (http://old.intuit.ru/department/se/devis/7/, http://dit.isuct.ru/IVT/BOOKS/CASE/case5/Part1.html);

• ERwin Business Process – CASE-інструмент побудови бізнес-процесів (https://erwin.com/products/erwin-business-process/);

• Business Studio – система бізнес-моделювання (https://www.businessstudio.ru/wiki/).

 

4.2          ARIS (ARchitecture of Integrated Information Systems)

 

ARchitecture of Integrated Information Systems – методологія, нотація та CASE-засіб для професійного моделювання бізнес-процесів німецької компанії IDS Scheer AG [4]. На даний час IDS Scheer AG компанія ввійшла у склад Software AG.

Методологія ARIS є досить рафінована. Організація в ARIS розглядається з чотирьох точок зору (рис.4):

• організаційної структури,

• функціональної структури,

• структури даних,

• структури процесів.

При цьому кожна з цих точок зору розділяється ще на три підрівня: опис вимог, опис специфікації, опис впровадження. Серед великої кількості можливих методів опису організації для моделювання бізнес-процесів використовується eEPC (event-driven process chain) — метод опису процесів, що знайшов застосування в системі SAP ERP. Для моделювання даних застосовується ERM (Entity Relationship Model) — модель сутність-зв'язок для опису структури даних. Також наявні засоби ООП із застосуванням UML.

Моделі, побудовані в нотації eEPC (рис.5), дозволяють ефективно вивчати і аналізувати бізнес-процеси. На одній схемі можна побачити не тільки порядок виконуваних процесів, а й події, які керую розвитком процесу, документи, інформаційні системи, ресурси, персонал і т.д. Логіка побудови досить проста і зрозуміла.

Основними елементами моделі є:

• Функція/дія

• Подія

• Прикладна інформаційна система

• Кластер інформації

• Документ

• Організаційна структура

• Оператори логіки

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

Діаграма PCD Process Chain Diagram) є структурованим представленням  eEPC, де об’єкти  розділені за типами  (рис.6): 

• Події та частина логіки

• Функції

• Документи

• Прикладне ПЗ (системи)

• Посади організаційної структури

Методологія ARIS забезпечує процес досладження організації близько 80 типів моделей, кожна з яких належить тому чи іншому аспекту. У ARIS є потужна репрезентативна графіка, що робить моделі особливо зручними для представлення керівництву. Такий широкий спектр інструментів з одного боку є перевагою методології ARIS, а з іншого боку це ускладнює опанування та збільшує вартість використання (потрібні бізнес-аналітики високого рівня кваліфікації). Нотації  ARIS доцільно застосовувати у середніх і великих проектах інтеграції інформаційних систем із хорошим рівнем фінансування.

Основними CASE-інструментами побудови діаграм в нотації ARIS є:

• ARIS IT Architect

• ARIS Express (безкоштовний)

 Не дивлячись, що ARIS Express розповсюджується безкоштовно, він має достатньо широкий інструментрій моделювання бізнес-процесів:

• Організаційна діаграма (Organizational chart)

• Бізнес-процес (Business process)

• ІТ-інфраструктура (IT infrastructure)

• Карта процесів (Process landscape)

• Модель даних (Data model)

• Карта систем (System landscape)

• Дошка (Whiteboard)

• BPMN діаграма версії 2.0 (BPMN diagram)

• Загальні діаграми (General diagram)

 

BPMN

Business Process Model and Notation (BPMN) – нотація моделювання бізнес-процесів для забезпечення керування ними, яка спирається на їх опис в XML [5]. Розроблена Business Process Management Initiative (BPMI.org) і підтримується Object Management Group, після об’єднання цих організацій в 2005 році. Остання версія BPMN - 2.0 (2.0.2), попередня версія - 1.2.

BPMN - найзручніша, гнучка, наочна, функціональна і, разом з тим проста нотація [6].

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

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

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

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

 

4.2.1          Структура моделі

Моделювання з використанням BPMN виконується у вигляді діаграм, що складаються з різних елементів. Розрізняють чотири категорії елементів:

• Об’єкти потоку керування: дії, події та логічні оператори

• З’єднання: потік керування, потік повідомлень та асоціації

• Ролі: пули та доріжки

• Артефакти: дані, групи та текстові анотації

Дії

Одиниця роботи – задача. Якщо задача є підпроцесом, то вона може бути деталізована.

Набір логічно пов’язаних дій є транзакцією. Для транзакції може бути визначений протокол виконання.

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

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

Події

• Проста: нетипізована подія, зазвичай вказує на початок, зміну стану, чи завершення процесу.

• Повідомлення: Отримання і відправлення повідомлень.

• Таймер: циклічні події, моменти часу, часові періоди і тайм-аути.

• Ескалація: перенесення розгляду задачі на більш високий рівень організаційної ієрархії.

• Умовна: реакція на зміну бізнес-умов або інтеграція бізнес-правил.

• Посилання: пара відповідних посилань, що еквівалентна неперервному потоку керування.

• Помилка: генерація й обробка помилок заданого типу.

• Скасування: обробка скасування транзакції або ініціювання скасування.

• Компенсація: обробка або ініціювання компенсації.

• Сигнал: передається між процесами та може оброблятися декількома одержувачами одночасно.

• Складена: обробка однієї події із багатьох або генерація всіх визначених подій.

• Паралельна складена: обробка всієї множини паралельних подій.

• Зупинник: викликає негайне припинення виконання процесу.

Логічні оператори

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

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

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

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

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

• Оператор виключного АБО, що керується подіями (створює новий екземпляр). Настання кожної подій, яким передує оператор, створює екземпляр процесу.

• Оператор І, що керується подіями (створює новий екземпляр). Настання всіх подій, яким передує оператор, створює екземпляр процесу.

З'єднання

• Потік керування визначає порядок виконання дій.

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

• Умовний потік визначає потік, що буде виконаний, якщо пов'язана з цим потоком умова вірна.

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

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

Ролі

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

Артефакти

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

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

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

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

 

4.2.2         Переваги і недоліки

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

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

Одним з величезних плюсів даної нотації, є можливість переводити моделі бізнес процесів, безпосередньо в програмний код. Це істотно спрощує процес розробки ПЗ. Тому багато розробників віддають перевагу нотації BPMN.

Є ще можливості зв'язки моделей BPMN і 1С. У підсумку виходить ефективна система управління процесами з можливістю відстеження он-лайн.

Резюме - нотацію BPMN вибирає більшість професіоналів в управлінні бізнес-процесами. Вона найбільш сучасна і активно розвивається.

 

4.2.3         CASE-засоби

Програми, які орієнтуються на використання нотації BPMN, найбільш активно розвиваються. Багато з них можна використовувати безкоштовно, при цьому отримувати повний функціональний набір. Наприклад, програма BizAgi. Це ціла платформа, яка дозволяє не тільки моделювати і аналізувати, а й створювати виконувані бізнес-процеси. Це ПЗ можна впроваджувати в компанії будь-якого типу, розміру, з орієнтацією на будь-який бюджет.