- •1 Сучасні case-технології та їх застосування для моделювання і аналізу бізнес-процесів
- •1.1 Case-технології. Призначення та основні особливості
- •1.2 Основні стандарти, які застосовуються в сфері моделювання та аналізу бізнес-процесів
- •1.2.1 Стандарт idef0. Призначення та основні особливості
- •1.2.2 Стандарт idef3. Призначення та основні особливості
- •1.2.3 Стандарт dfd. Призначення та основні особливості
- •1.3 Моделювання бізнес-процесів за допомогою case-засобу bpWin
- •2.1 Аналіз предметної галузі
- •2.2 Розробка моделей бізнес-процесів на основі стандарту idef0
- •2.3 Розробка моделей бізнес-процесів на основі стандарту idef3
- •2.4 Розробка моделей бізнес-процесів на основі стандарту dfd
- •1.4 Опис предметної області. Постановка задачі дослідження
- •2 Побудова моделей бізнес-процесів на основі стандартів idef0, idef3, dfd
- •Висновки
1.2.2 Стандарт idef3. Призначення та основні особливості
Для опису логіки взаємодії інформаційних потоків більш підходить IDEF3, що називається також workflow diagramming, – методологія моделювання, яка застосовує графічний опис інформаційних потоків, взаємовідносин між процесами обробки інформації і об’єктів, що є частиною цих процесів. Діаграми Workflow можуть бути застосовані в моделюванні бізнес-процесів для аналізу завершеності процедур обробки інформації. З їх допомогою можна описувати сценарії дій співробітників організації, наприклад послідовність обробки замовлення або події, які необхідно обробити за кінцевий час. Кожен сценарій супроводжується описом процесу і може бути застосований для документування кожної функції.
IDEF3 – це метод, який має основною ціллю дати можливість аналітикам описати ситуацію, коли процеси виконуються в певній послідовності, а також описати об’єкти, що беруть участь в одному процесі.
Техніка опису набору даних IDEF3 є частиною структурного аналізу. На відміну від деяких методик опису процесів IDEF3 не обмежує аналітика дуже жорсткими рамками синтаксису, що може привести до створення неповних або суперечливих моделей.
IDEF3 може бути також використаний як метод створення процесів. IDEF3 доповнює IDEF0 і містить все необхідне для побудови моделей, які в подальшому можуть бути використані для імітаційного аналізу.
Кожна робота в IDEF3 описує якийсь сценарій бізнес-процесу і може бути складовою іншої роботи. В зв’язку з тим, що сценарій описує ціль и рамки моделі, важливо, щоб роботи іменувались іменником, який означає процес дії, або фразою, яка містить такий іменник.
Точка зору на модель повинна бути документована. За звичай це точка зору людини, що відповідає за роботу в цілому. Також необхідно документувати ціль моделі – ті питання, на які призвана відповідати модель.
Діаграма є основною одиницею опису в IDEF3. Важливо правильно побудувати діаграми, оскільки вони призначені для читання іншими людьми (а не тільки автором).
Одиниці роботи — Unit of Work (UOW) – їх також називають роботами (activity), є центральними компонентами моделі. В IDEF3 роботи зображуються прямокутниками з прямими кутами і мають ім’я, виражене іменником, що означає процес дії, одиночним або в складі фрази, і номер (ідентифікатор); інший іменний в складі тієї ж фрази звичайно відображує основний вихід (результат) роботи (наприклад, «Заключение договора на поставку») (рисунок 1.3). Часто іменник в імені роботи змінюється в процесі моделювання, тому що модель може уточнятися. Ідентифікатор роботи присвоюється при створенні і не змінюється ніколи. Навіть якщо робота буде видалена, її ідентифікатор не буде знову застосований для інших робіт. За звичай номер роботи складається з номеру батьківської роботи і порядкового номеру на поточній діаграмі.
Рисунок 1.3 – Зображення роботи в IDEF3
Зв’язки показують взаємовідносини робіт. Всі зв’язки в IDEF3 односпрямовані і можуть бути спрямовані куди завгодно, але за звичай діаграми IDEF3 намагаються побудувати так, щоб зв’язки були спрямовані зліва направо. В IDEF3 виділяють три типа стрілок, що зображують зв’язки, стиль яких встановлюється через меню Edit/Arrow Style:
старша (Precedence)
– лінія, що зв’язує одиниці робіт
(UOW). Рисується зліва направо або зверху
вниз. Показує, що робота-джерело повинна
закінчитися раніше, чим робота-ціль
почнеться;відношення (Relational Link)
– пунктирна лінія, яка застосовується
для зображення зв’язків між одиницями
робіт (UOW), а також між одиницями робот
і об’єктами посилань;потоки об’єктів (Object Flow)
– стрілка с двома наконечниками,
застосовується для опису того факту,
що об’єкт застосовується в двох або
більше одиницях роботи, наприклад, коли
об’єкт породжується в одній роботі і
застосовується в іншій.
Старший зв’язок показує, що робота-джерело закінчується раніш, ніж починається робота-ціль. Часто результатом роботи-джерела становиться об’єкт, необхідний для запуску роботи-ціли. В цьому випадку стрілку, що визначає об’єкт, зображують з подвійним наконечником. Ім’я стрілки повинно ясно ідентифікувати об’єкт, що відображується. Потік обкатів має ту ж семантику, що і старша стрілка.
Відношення показує, що стрілка є альтернативою старшій стрілці або потоку об’єктів в смислі завдання послідовності виконання робіт – робота-джерело не обов’язково повинна закінчитися, перш ніж робота-ціль почнеться. Більш того, робота-ціль може закінчитися перш ніж закінчиться робота-джерело.
Закінчення однієї роботи може служити сигналом до початку декількох робіт, або ж одна робота для свого запуску може очікувати закінчення декількох робіт. Для відображення логіки взаємодії стрілок при злитті і розгалуженні або для відображення множини подій, які можуть або повинні бути завершені перед початком наступної роботи, застосовують перехрестя (Junction). Розрізнюють перехрестя для злиття (Fan-in Junction) і розгалуження стрілок (Fan-out Junction). Перехрестя не може бути використане одночасно для злиття і для розгалуження. Зміст кожного типу перехрестя приведений в таблиці 1.1.
Всі перехрестя на діаграмі нумеруються, кожен номер має префікс J. Можна редактувати властивості перехрестя за допомогою діалогу Junction Properties, який викликається в контекстному меню перехрестя командою Definition/Note. На відміну від IDEF0 в моделі IDEF3 стрілки можуть зливатися і розгалуживатися тільки через перехрестя.
Об’єкт посилання в IDEF3 виражає ідею, концепцію або дані, які не можна зв’язати зі стрілкою, перехрестям або роботою. Об’єкт посилання зображується у вигляді прямокутника, схожого на прямокутник роботи. В якості імені об’єкту посилання можна використати ім’я стрілки з інших діаграм або ім’я сутності з моделі даних. Об’єкти посилання повинні бути зв’язані з одиницями робіт або з перехрестями пунктирними лініями. Офіційна специфікація IDEF3 розрізнює три стиля об’єктів посилання – безумовні (unconditional), синхронні (synchronous) та асинхронні (asynchronous). При внесенні об’єктів посилання крім імені слід вказувати тип об’єкта посилання.
В IDEF3 декомпозиція застосовується для деталізації робіт. Методологія IDEF3 дозволяє декомпозувати роботу багатократно, тобто робота може мати множину дочірніх робіт. Це дозволяє в одній моделі описати альтернативні потоки. Можливість декомпозиції пред’являє додаткові вимоги до нумерації робіт. Так, номер роботи складається з номеру батьківської роботи, версії декомпозиції і власного номеру роботи на поточній діаграмі.
Таблиця 1.1 – Типи перехрестя
Означення |
Найменування |
Зміст у випадку злиття стрілок (Fan-in Junction) |
Зміст у випадку розгалуження стрілок (Fan-out Junction) |
|
Asynchronous AND |
Всі попередні процеси повинні бути завершені |
Всі наступні процеси повинні бути запущені |
|
Synchronous AND |
Все попередні процеси завершені одночасно |
Все наступні процеси запускаються одночасно |
|
Asynchronous OR |
Один або декілька попередніх процесів повинні бути завершені |
Один або декілька наступних процесів повинні бути запущені |
|
Synchronous OR |
Один або декілька попередніх процесів повинні бути завершені одночасно |
Один або декілька наступних процесів запускаються одночасно |
|
XOR (Exclusive OR) |
Тільки один попередній процес завершений |
Тільки один наступний процес запускається |
Розглянемо процес декомпозиції діаграм IDEF3, що включає взаємодію автора (аналітика) і одного або декількох експертів предметної області.
Перед проведенням сеансу експертизи у експертів предметної області повинні бути документовані сценарії і рамки моделі, для того щоб з’ясувати цілі декомпозиції. За звичай експерт предметної області передає аналітику текстовий опис сценарію. Додатково до цього може існувати документація, що описує потрібні процеси. З цієї інформації аналітик повинен скласти попередній список робіт (іменники, що означають процес) і об’єктів (іменники, що означають результат виконання роботи), які потрібні для перелічених робіт. У деяких випадках доцільно створити графічну модель для пред’явлення її експерту предметної області.
Рисунок 1.4 – Опис процесу в методології IDEF3
На рисунку 1.4 як приклад представлений фрагмент опису процесу «Збирання настільних комп'ютерів» у методології IDEF3.
В IDEF3 декомпозиція застосовується для деталізації робіт. Методологія IDEF3 дозволяє декомпозувати роботу багаторазово, тобто робота може мати безліч дочірніх робіт. Це дозволяє в одній моделі описати альтернативні потоки. Можливість множинної декомпозиції висуває додаткові вимоги до нумерації робіт. Так, номер роботи складається з номера батьківської роботи, версії декомпозиції й власного номера роботи на поточній діаграмі.
