Книги

• Разное
• Экономика
• Право
• История
• Шпоры

реклама

3. Моделювання бізнес-процесів у середовищі BPwin

BPwin є могутнім засобом моделювання і документування бізнес-процесів. Цей продукт використовує технологію моделювання IDEF0 (Integration Definition for Function Modeling) – найбільш поширений стандарт, який прийнятий для моделювання бізнес-процесів. Цей стандарт був розроблений в лабораторії військово-повітряних сил США в 1981 році і успішно використовувався для розробки систем протиповітряної оборони.

Крім стандарту IDEF0, BPwin підтримує також методології моделювання DFD (data flow diagram) і IDEF3 (workflow). Методологія DFD служить для опису потоків даних, які виникають внаслідок діяльності компанії. Методологія IDEF3 служить для графічного опису потоку процесів (робіт), взаємодії процесів і об'єктів, які змінюються цими процесами.

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

Метод опису процесів IDEF0

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

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

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

Діаграми декомпозиції;

Діаграми дерева вузлів;

Діаграми для експозиції (FEO).

Контекстна діаграма – це вершина деревовидної структури ієрархічно впорядкованих і взаємопов'язаних підпроцесів; вона є найбільш узагальненим описом системи та її взаємодії із зовнішнім середовищем. В будь-якій моделі може бути тільки одна контекстна діаграма.

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

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

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

Роботи (Activity) означають найменування процесів, функцій або задач, які відбуваються протягом певного періоду часу і мають розпізнавані результати. Роботи зображаються у вигляді прямокутників. Всі роботи повинні бути названі і визначені. Ім'ям роботи повинно бути дієслово або дієслівна форма (наприклад "Виготовлення деталі", "Прийом замовлення" тощо). Робота "Виготовлення деталі" може мати, наприклад, наступне визначення: "Робота відноситься до повного циклу виготовлення виробу від контролю якості сировини до відвантаження готового упакованого виробу".

Контекстна діаграма складається тільки з однієї роботи - "прямокутника", як правило, це назва бізнес-процесу, що моделюється. Роботи на діаграмах декомпозиції зазвичай розміщуються по діагоналі від лівого верхнього кутка вікна моделі BPwin до правого нижнього. Такий порядок називається порядком домінування. Згідно такому принципу розміщення в лівому верхньому кутку розміщується найважливіша робота або робота, що за часом виконання є першою. Далі вправо вниз розміщуються менш важливі роботи або роботи, що виконуються пізніше попередньої. Таке розміщення полегшує читання діаграми, крім того, на ньому базується поняття взаємозв’язку робіт.

Кожна з робіт на діаграмі декомпозиції може бути в свою чергу декомпонована. На діаграмі декомпозиції роботи нумеруються автоматично зліва направо; номер роботи відображається в правому нижньому кутку прямокутника (роботи). В BPwin недекомпоновані роботи мають в лівому верхньому кутку невелику діагональну риску.

Взаємодія робіт із зовнішнім світом і між собою описується у вигляді стрілок.

Стрілки (Arrow) представляють деяку інформацію та іменуються іменниками (наприклад, "Заготівля", "Виріб", "Замовлення"). У IDEF0 розрізнюють п'ять типів стрілок:

Вхід (Input) – матеріал або інформація, які використовуються або перетворюються роботою для отримання результату (виходу). Допускається, що робота може не мати жодній стрілки входу. Кожний тип стрілок підходить до певної сторони прямокутника, що зображає роботу, або виходить з неї. Стрілка входу малюється як така, що входить в ліву грань роботи. При описі технологічних процесів (для цього спочатку і був створений IDEF0) не виникає проблем визначення входів. При моделюванні ІС входами є не фізичні об'єкти, а дані, тому часто виникають ситуації, коли входом і виходом процесу є одні й ті ж дані, але тим часом якість цих даних міняється. У зв'язку з цим стрілки входу і виходу повинні бути чітко визначені з тим, щоб указати на те, що дані дійсно були перероблені. Дуже часто складно визначити, чи є дані входом або управлінням. У цьому випадку підказкою може служити відповідь на питання: "Переробляються/ чи змінюються дані в роботі чи ні?". Якщо змінюються, то швидше усього це вхід, якщо немає – управління.

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

Вихід (Output) – матеріал або інформація, які виконуються роботою. Кожна робота повинна мати хоч би одну стрілку виходу. Робота без результату не має значення і не повинна моделюватися. Стрілка виходу малюється як така, що виходить з правої грані роботи.

Механізм (Mechanism) – ресурси, які виконують роботу, наприклад персонал підприємства, верстати, пристрої тощо. Стрілка механізму малюється як така, що входить в нижню грань роботи. По розсуду аналітика стрілки механізму можуть не зображатися в моделі.

Виклик (Call) – спеціальна стрілка, що вказує на іншу модель роботи. Стрілка виклику малюється як така, що виходить з нижньої грані роботи. Стрілка виклику використовується для зазначення, що деяка робота виконується за межами системи, що моделюється. У BPwin стрілки виклику використовуються в механізмі злиття і поділу моделей.

Метод опису процесів DFD – Data Flow Diagramming

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

функції обробки інформації (роботи);

документи (стрілки), об'єкти, співробітники або відділи, які беруть участь в обробці інформації;

зовнішні посилання (external references), які забезпечують інтерфейс із зовнішніми об'єктами, що знаходяться за межами системи, що моделюється;

таблиці для зберігання документів (сховище даних – data store).

У BPwin для побудови діаграм потоків даних використовується нотація Гейна-Сарсона.

Для того щоб доповнити модель IDEF0 діаграмою DFD, потрібно в процесі декомпозиції в діалозі Activity Box Count "клікнути" по радіокнопці DFD. Інструментарій BPwin поповниться новими можливостями:

можливість додати в діаграму зовнішнє посилання (External Reference), яке є джерелом або приймачем даних ззовні моделі;

можливість додати в діаграму сховище даних (Data store), яке дозволяє описати дані, які необхідно зберегти в пам'яті заздалегідь (до того, як вони будуть використані в роботах);

можливість створювати посилання на інші сторінки (off-page reference). На відміну від IDEF0 цей інструмент дозволяє направити стрілку на будь-яку діаграму, а не тільки на верхній рівень.

На відміну від стрілок IDEF0, які являють собою жорсткі взаємозв'язки, стрілки DFD показують, як об'єкти (включаючи дані) рухаються від однієї роботи до іншої. Таке подання потоків, сховищ даних і зовнішніх сутностей робить моделі DFD більш схожими на фізичні характеристики системи – рух об'єктів (data flow), зберігання об'єктів (data stores), постачання і розповсюдження об'єктів (external entities).

На відміну від IDEF0, де система розглядається як сукупність взаємопов'язаних робіт, DFD розглядає систему як сукупність предметів. Контекстна діаграма часто включає роботи і зовнішні посилання. Роботи звичайно іменуються подібно до назви системи, наприклад "Система обробки інформації". Включення зовнішніх посилань в контекстну діаграму не відміняє вимоги методології чітко визначити мету, область і єдину точку зору на систему, що моделюється.

Роботи. У DFD роботи – це функції системи, що перетворюють входи у виходи. Хоч роботи зображаються прямокутниками з округленими кутами, значення їх співпадає зі значенням робіт в IDEF0 і IDEF3. Так само як роботи IDEF3, вони мають входи і виходи, але не підтримують управління і механізми, як IDEF0.

Зовнішні сутності. Зовнішні сутності зображають входи в систему і/або виходи з системи. Зовнішні сутності зображаються у вигляді прямокутника з тінню і звичайно розташовуються по краях діаграми. Одна зовнішня суть може бути використана багато разів на одній або декількох діаграмах. Звичайно такий прийом використовують, щоб не малювати дуже довгих і заплутаних стрілок.

Стрілки (Потоки даних). Стрілки описують рух об'єктів з однієї частини системи в іншу. Оскільки в DFD кожна сторона роботи не має чіткого призначення, як в IDEF0, стрілки можуть підходити і виходити з будь-якої грані прямокутника роботи. Крім того, в DFD також застосовуються двонаправлені стрілки для опису діалогів типу "команда-відповідь" між роботами, між роботою і зовнішньою суттю, а також між зовнішніми сутностями.

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

Злиття і розгалуження стрілок. У DFD стрілки можуть зливатися і розгалужуватися, що дозволяє описати декомпозицію стрілок. Кожний новий сегмент стрілки, що розгалужується або зливається, може мати власне ім'я (що не допускається в IDEF0).

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

Альтернативним підходом є підхід, популярний при створенні програмного забезпечення, який носить назву розподілом подій (event partitioning), і в якому різні діаграми DFD створюють модель системи. По-перше, логічна модель будується як сукупність робіт і документування того, що вони (ці роботи) повинні робити.

По-друге, модель оточення (environment model) описує систему як об'єкт, взаємодіючий з подіями із зовнішніх сутностей. Модель оточення звичайно містить опис мети системи, одну контекстну діаграму і список подій. Контекстна діаграма містить один прямокутник роботи, що зображає систему загалом, і зовнішні сутності, з якими система взаємодіє.

По-третє, модель поведінки (behavior model) показує, як система обробляє події. Ця модель складається з однієї діаграми, в якій кожний прямокутник зображає кожну подію з моделі оточення. Сховища можуть бути додані для моделювання даних, які необхідно запам'ятовувати між подіями. Потоки додаються для зв'язку з іншими елементами, і діаграма перевіряється з точки зору відповідності моделі оточення.

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

Метод опису процесів IDEF3

Наявність в діаграмах DFD елементів для опису джерел, приймачів і сховищ даних дозволяє більш ефективно і наочно описати процес документообігу. Однак для опису логіки взаємодії інформаційних потоків більш підходить IDEF3, звана також workflow diagramming – методологією моделювання, що використовує графічний опис інформаційних потоків, взаємовідносин між процесами обробки інформації і об'єктів, що є частиною цих процесів. Діаграми Workflow можуть бути використані в моделюванні бізнесу-процесів для аналізу завершеності процедур обробки інформації. З їх допомогою можна описувати сценарії дій співробітників організації, наприклад послідовність обробки замовлення або події, які необхідно обробити за кінцевий час. Кожний сценарій супроводиться описом процесу і може бути використаний для документування кожної функції.

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

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

IDEF3 може бути також використаний як метод створення процесів. IDEF3 доповнює IDEF0 і містить все необхідне для побудови моделей, які надалі можуть бути використані для імітаційного аналізу.

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

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

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

Одиниці роботи – Unit of Work (UOW). UOW, також звані роботами (activity), є центральними компонентами моделі. У IDEF3 роботи зображаються прямокутниками з прямими кутами і мають ім'я, виражене іменником дієслівного походження, що вказує на процес дії, одиночним або в складі фрази, і номер (ідентифікатор); інше ім'я іменник в складі тієї ж фрази звичайно відображає основний вихід (результат) роботи. Часто ім'я іменник в імені роботи міняється в процесі моделювання, оскільки модель може уточнюватися і редагуватися. Ідентифікатор роботи присвоюється при створенні і не міняється ніколи. Навіть якщо робота буде видалена, її ідентифікатор не буде знову використовуватися для інших робіт. Звичайно номер роботи складається з номера батьківської роботи і порядкового номера на поточній діаграмі.

Зв'язки. Зв'язки показують взаємовідносини робіт. Всі зв'язки в IDEF3 однонаправлені і можуть бути направлені куди бажано, але звичайно діаграми IDEF3 стараються побудувати так, щоб зв'язки були направлені зліва направо. У IDEF3 розрізнюють три типи стрілок, що зображають зв'язки, стиль яких встановлюється через меню Edit/Arrow Style:

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

Відносини (Relational Link) – пунктирна лінія, що використовується для зображення зв'язків між одиницями робіт (UOW) а також між одиницями робіт і об'єктами посилань.

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

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

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

 

Рисунок 3 – Часова діаграма виконання робіт

Перехрестя (Junction). Закінчення однієї роботи може служити сигналом на початок декількох робіт, або ж одна робота для свого запуску може чекати закінчення декількох робіт. Перехрестя використовуються для відображення логіки взаємодії стрілок при злитті і розгалуженні або для відображення безлічі подій, які можуть або повинні бути завершені перед початком наступної роботи. Розрізнюють перехрестя для злиття (Fan-in Junction) і розгалуження (Fan-out Junction) стрілок. Перехрестя не може використовуватися одночасно для злиття і для розгалуження. Існує п'ять типів перехресть, значення кожного типу наведено в табл. 1.

 

Таблиця 1 – Типи перехресть

Позначення	Найменування	Значення у разі злиття стрілок (Fan-in Junction)	Значення у разі розгалуження стрілок (Fan-out Junction)
	Asynchronous AND	Все попередні процеси повинні бути завершені	Все наступні процеси повинні бути запущені
	Synchronous AND	Все попередні процеси завершені одночасно	Все наступні процеси запускаються одночасно
	Asynchronous OR	Один або декілька попередніх процесів повинні бути завершені	Один або декілька наступних процесів повинні бути запущені
	Synchronous OR	Один або декілька попередніх процесів завершені одночасно	Один або декілька наступних процесів запускаються одночасно
	XOR(Exclusive OR)	Тільки один попередній процес завершений	Тільки один наступний процес запускається

Об'єкт посилання. Об'єкт посилання в IDEF3 виражає деяку ідею, концепцію або дані, які не можна зв'язати зі стрілкою, перехрестям або роботою. Об'єкт посилання зображається у вигляді прямокутника, схожого на прямокутник роботи. Як ім'я об'єкта можна використати ім'я якої-небудь стрілки з інших діаграм або ім'я суті з моделі даних. Об'єкти посилання повинні бути пов'язані пунктирними лініями з одиницями робіт або з перехрестями. Офіційна специфікація IDEF3 розрізнює три стилі об'єктів посилань – безумовні (unconditional), синхронні (synchronous) і асинхронні (asynchronous). BPwin підтримує тільки безумовні об'єкти посилань. Синхронні і асинхронні об'єкти посилань, що використовуються в діаграмах переходів станів об'єктів, не підтримуються.

При внесенні об'єктів посилань крім імені потрібно вказувати тип об'єкта посилання. Типи об'єктів посилань приведені в табл. 2.

Таблиця 2 – Типи об'єктів посилань

Тип об'єкта посилання	Мета опису
OBJECT	Описує участь важливого об'єкта в роботі
GOTO	Інструмент циклічного переходу (в послідовності робіт, що повторюється), можливо на поточній діаграмі, але не обов'язково. Якщо всі роботи циклу присутні на поточній діаграмі, цикл може також зображатися стрілкою, що повертається на стартову роботу. GOTO може посилатися на перехрестя
UOB (Unit of behavior)	Застосуються, коли необхідно підкреслити множинне використання якої-небудь роботи, але без циклу. Наприклад, робота "Контроль якості" може бути використана в процесі "Виготовлення виробу" декілька разів, після кожної одиничної операції. Звичайно цей тип посилання не використовується для моделювання робіт, що автоматично запускаються
NOTE	Використовується для документування важливої інформації, що відноситься до яких-небудь графічних об'єктів на діаграмі. NOTE є альтернативою внесенню текстового об'єкта в діаграму
ELAB (Elaboration)	Використовується для удосконалення графіків або їх більш детального опису. Звичайно вживається для детального опису розгалуження і злиття стрілок на перехрестях

Декомпозиція робіт. У IDEF3 декомпозиція використовується для деталізування робіт. Методологія IDEF3 дозволяє декомпонувати роботу багато разів, тобто робота може мати безліч дочірніх робіт. Це дозволяє в одній моделі описати альтернативні потоки.

Внаслідок доповнення діаграм IDEF0 діаграмами DFD і IDEF3 може бути створена змішана модель, яка найкращим образом описує всі сторони діяльності підприємства. Ієрархію робіт в змішаній моделі можна побачити у вікні Model Explorer. Роботи в нотації IDEF0 зображаються зеленим кольором, IDEF3 – жовтим, DFD – синім.

Книги принадлежат их авторам и выставлены для ознакомления