4. Побудова діаграм потоків даних dfd і Workflow (idef3).

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

Діаграми потоків даних (Data flow diagramming, DFD) використовуються для опису документообігу та обробки інформації. Їх можна використовувати як доповнення до моделі IDEF0 для більш наочного відображення поточних операцій документообігу в корпоративних системах обробки інформації. DFD описують функції обробки інформації (роботи), документи (стрілки, arrow), об'єкти, співробітників або відділи, які беруть участь в обробці інформації (зовнішні посилання, external references) та таблиці для зберігання документів (сховище даних, data store). На відміну від IDEF0 для стрілок немає поняття вхід, вихід, управління або механізм і неважливо, в яку грань роботи входить або з якої грані виходять стрілки. У BPwin для побудови діаграм потоків даних використовується нотація Гейна-Сарсона. Для того, щоб доповнити модель IDEF0 діаграмою DFD потрібно в процесі декомпозиції в діалозі Activity Box Count кликнути по радіокнопки DFD. У палітрі інструментів на новій діаграмі DFD з’являються нові кнопки:

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

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

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

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

Прямокутники на діаграмі Workflow називаються одиницями роботи (Unit of Work, UOW) і позначають подію, процес, рішення або роботу. Для редагування діаграми використовуються приблизно ті ж діалоги, що і для IDEF0. У палітрі інструментів на діаграмі Workflow є кнопки для нових елементів:

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

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

Всі перехрестя на діаграмі нумеруються, кожен номер має префікс "J". Можна редагувати властивості перехрестя за допомогою діалогу Definition Editor. На відміну від IDEF0 і DFD, в IDEF3 стрілки можуть зливатися і розгалужуватися тільки через перехрестя. Тут розрізняють три типи стрілок, стиль яких встановлюється через меню Edit / Arrow Style:

Таблиця 1.

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

Рис. 49. Діаграма в нотації DFD

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

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

Рис. 50. Діаграма в нотації EDEF3

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

Синтаксичний аналіз моделі дозволяє легко виявити марні (що не мають виходу), "некеровані" (що не мають управління) і "простоюють" роботи. Більш тонкий аналіз дозволяє виявити дублюючі, надлишкові або неефективні роботи. Модель дає цілісне уявлення про роботу системи в цілому і дозволяє зрозуміти взаємозв’язки всіх складових системи. При цьому часто з’ясовується, що обробка інформації та використання ресурсів неефективні, важлива інформація не доходить до відповідного робочого місця і т.д. Ознакою неефективної організації робіт є, наприклад, відсутність зворотних зв’язків по входу і управлінню для багатьох, критично важливих робіт.

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