На idef0 діаграмі тунель використовується. IDEF0: функціональне моделювання ділових процесів. Історія виникнення стандарту IDEF0

Методологія IDEF0

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

Кожна IDEF0-діаграмамістить блоки та дуги. Блоки зображують функції системи, що моделюється. Дуги зв'язують блоки разом і відображають взаємодії та взаємозв'язки між ними.

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

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

Кожна сторона блоку має особливе, цілком певне призначення. Ліва сторона блоку призначена для входів, верхня – для керування, права – для виходів, нижня – для механізмів. Таке позначення відбиває певні системні принципи: входи перетворюються на виходи управління обмежує чи приписує умови виконання перетворень, механізми показують, як і виконує функція.

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

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

Розташування блоків на сторінці відбиває авторське визначення домінування. Таким чином, топологія діаграми показує, які функції мають більший вплив на інші. Щоб підкреслити це, аналітик може перенумерувати блоки відповідно до порядку їхнього домінування. Порядок домінування може позначатись цифрою, розміщеною в правому нижньому куті кожного прямокутника: 1 вказуватиме на найбільше домінування, 2 – на наступне і т.д.

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

У IDEF0 розрізняють п'ять типів стрілок.

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

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

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

Механізм- Ресурси, що виконують роботу. Стрілка механізму малюється як входить у нижню грань роботи. На розсуд аналітика стрілки механізму можуть не зображуватися на моделі.

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

Мал. 2.1Типи стрілок

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

Мал. 2.2.Зв'язок по виходу

Мал. 2.3.Зв'язок з управління

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

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

Зворотний зв'язок з управління виникає тоді; коли вихід деякого блоку впливає блок із великим домінуванням.

Зв'язки «вихід-механізм» трапляються нечасто. Вони відображають ситуацію, коли вихід однієї функції стає засобом досягнення мети для іншої.

Мал. 2.4.Зворотній зв'язок по входу

Мал. 2.5.Зворотній зв'язок з управління

Зв'язки «вихід-механізм» притаманні розподілу джерел ресурсів (наприклад, необхідні інструменти, навчений персонал, фізичний простір, обладнання, фінансування, матеріали).

У IDEF0 дуга рідко зображує один об'єкт. Зазвичай вона символізує набір об'єктів. Оскільки дуги представляють набори об'єктів, можуть мати безліч початкових точок (джерел) і кінцевих точок (призначень). Тому дуги можуть розгалужуватися та з'єднуватися різними способами. Вся дуга або її частина може виходити з одного або кількох блоків та закінчуватися в одному або кількох блоках.

Розгалуження дуг, що зображується у вигляді ліній, що розходяться, означає, що весь вміст дуг або його частина може з'явитися в кожному відгалуженні. Дуга завжди позначається до розгалуження, щоб дати назву всьому набору. Крім того, кожна гілка дуги може бути позначена або не позначена відповідно до таких правил:

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

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

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

Мал. 2.6.Зв'язок вихід-механізм

непомічені гілки містять вагу об'єкти, зазначені у загальній мітці дуги після злиття;

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

кількість блоків на діаграмі - N;

рівень декомпозиції діаграми - L;

збалансованість діаграми - В;

число стрілок, що з'єднуються з блоком, - А

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

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

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

Мал. 2.7.Приклад незбалансованої діаграми

Введемо коефіцієнт збалансованості діаграми

Необхідно прагнути, щоб Кьбув мінімальним для діаграми.

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

Після формування словника та складання пакета діаграм системи необхідно розглянути нижній рівень моделі. Якщо на ньому виявляться збіги назв блоків діаграм і слів зі словника, це говорить, що достатній рівень декомпозиції досягнутий. Коефіцієнт, який кількісно відображає даний критерій, можна записати як L * C -добуток рівня моделі на кількість збігів імен блоків зі словами зі словника. Чим нижчий рівень моделі (більше L), тим цінніші збіги.

При запуску BPWin за промовчанням з'являється основна панель інструментів, панель інструментів та Model Explorer.

При створенні нової моделі виникає діалог, у якому слід зазначити, чи буде створена модель заново, чи вона буде відкрита з репозиторію ModelMart, внести ім'я моделі та вибрати методологію, в якій буде побудовано модель (рис. 2.8).

Рис.2.8Діалог створення моделі

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

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

Побудова моделі системи має починатися з вивчення всіх документів, що описують її функціональні можливості. Одним із таких документів є технічне завдання, а саме розділи "Призначення розробки", "Цілі та завдання системи" та "Функціональні характеристики системи".

Після вивчення вихідних документів та опитування замовників та користувачів системи необхідно сформулювати мету моделювання та визначити точку зору на модель. Розглянемо технологію її побудови на прикладі системи "Служба зайнятості в рамках ВНЗ", основні можливості якої були описані у лабораторній роботі №1.

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

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

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

Отже, визначимо контекстну діаграму системи (рис. 2.9).

Рис. 2.9.Контекстна діаграма системи

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

Визначення рівня доступу до системи.

Вибір підсистеми.

Звернення до підсистеми.

Зміна БД (за потреби).

Отримаємо діаграму, зображену на рис. 2.10.

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

Мал. 2.10.Декомпозиція роботи "Обслуговування, клієнта системи"

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

Мал. 2.11.Декомпозиція роботи «Визначення рівня доступу до системи»

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

Декомпозуємо роботу «Обробка запиту клієнта», що виконується підсистемою обробки запитів, визначення категорій та повноважень користувачів. Перед пошуком відповіді на запит необхідно відкрити БД (підключитися до неї). У загальному випадку БД може перебувати на віддаленому сервері, тому може знадобитися встановлення з'єднання з нею. Визначимо послідовність робіт:

Відкриття БД.

Виконання запиту.

генерація звітів.

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

Слід зазначити, що у «Виконання запиту» включається робота різних підсистем. Наприклад, якщо запит включає тестування, то його буде виконувати підсистема професійних і психологічних тестів. На етапі виконання запиту може знадобитися зміна вмісту БД, наприклад, при складанні експертних оцінок. Тому на діаграмі необхідно передбачити таку можливість.

Мал. 2.12.

Під час аналізу отриманої діаграми виникає питання, за якими правилами відбувається генерація звітів? Необхідна наявність заздалегідь сформованих шаблонів, за якими проводитиметься вибірка з БД, причому ці шаблони повинні відповідати запитам і повинні бути заздалегідь визначені. Крім того, клієнту має бути надана можливість вибору форми звіту.

Скоригуємо діаграму, додавши до неї стрілки «Шаблони звітів» та «Запити на зміну БД» та тунельну стрілку «Клієнт системи». Тунелювання «Клієнта системи» застосовано для того, щоб не виносити стрілку на діаграму верхнього, тому що функція вибору форми звіту не є достатньо важливою для відображення її на батьківській діаграмі.

Зміна діаграми потягне за собою коригування всіх батьківських діаграм (рис. 2.13 – 2.15).

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

Мал. 2.13.Декомпозиція роботи "Обробка запиту клієнта"

Мал. 2.14.Декомпозиція роботи «Обслуговування клієнта системи» (варіант 2)

Мал. 2.15.Контекстна діаграма системи (варіант 2)

Перейдемо до декомпозиції останнього блоку «Зміна БД». З погляду клієнта, ці системи розташовуються в одній БД. Реально в системі присутні шість БД:

БД користувачів,

БД студентів, (варіант 2)

БД вакансій

БД успішності,

БД тестів,

БД експертних оцінок,

БД резюме.

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

Визначається БД, у якій змінюватиметься інформація.

Оператором формується тимчасовий набір даних та надається адміністратору.

Адміністратор здійснює контроль даних та вносить їх до БД.

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

Мал. 2.16.Декомпозиція роботи «Зміна БД»

Мал. 2.17.Декомпозиція роботи "Зміна БД" (варіант 2) Для першого варіанту, зображеного на рис. 2.12

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

Декомпозицію роботи «Виконання запиту» буде проведено у наступній лабораторній роботі, ілюструючи застосування діаграм DFD для опису процесів обробки інформації.

Проведемо кількісний аналіз моделей, зображених на рис. 2.12 та 2.13, згідно з вищеописаною методикою. Розглянемо поведінку коефіцієнта у цих моделей. У батьківської діаграми «Обробка запиту клієнта» коефіцієнт дорівнює 4/2 = 2, а діаграми декомпозиції 3/3 = 1. Значення коефіцієнта зменшується, що свідчить про спрощення описи функцій зі зниженням рівня моделі.

Розглянемо зміну коефіцієнта До b у двох варіантів моделей.

для другого варіанта

Коефіцієнт До b не змінює свого значення, отже, збалансованість діаграми змінюється.

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

Підбиваючи підсумки розглянутого прикладу необхідно відзначити важливість розгляду кількох варіантів діаграм при моделюванні системи. Такі варіанти можуть виникати під час коригування діаграм, як це було зроблено з «Обробкою запиту клієнта» або під час створення альтернативних реалізацій функцій системи (декомпозиція роботи «Зміна БД»). Розгляд варіантів дозволяє вибрати найкращий та включити його в пакет діаграм для подальшого розгляду.

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

1. Визначення ділових процесів у вигляді IDEF0-моделі

1.1. Визначення ділового процесу.

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

Примітки:

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

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

2 Загальною метою моделей у рамках цього документа є створення системи менеджменту якості, що відповідає вимогам СТБ ISO 9000-2001, СТБ ISO 9001-2001 та СТБ ISO 9004-2001.

Для того, щоб виявити ділові процеси, необхідно визначити таке:

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

Примітка – Для різних видів продукції чи різних категорій споживачів можна розглядати різноманітні ділові процеси.

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

Фабрика є закритим акціонерним товариством. Мета побудови моделі – створення системи менеджменту якості. На підставі цієї інформації в діяльності швейної фабрики можна виділити один діловий процес-«Виробляти жіночі пальта». Входами цього процесу є: а) зовнішня інформація, включаючи вимоги споживачів (магазинів та компаній); б) сировину та матеріали; в) ресурси. Виходами процесу є: а) партії готової продукції, призначені споживачам; б) інформація зовнішніх споживачів. Управління процесом складає підставі нормативних документів, які регламентують виробничі процеси на фабриці. Враховуючи, що нас цікавить процес з погляду менеджменту якості, то як зовнішнє управління розглядатимемо нормативні документи, що регламентують цю сферу, у тому числі вимоги СТБ ІСО 9000. Карта ділового процесу на швейній фабриці представлена на рис. 3.

Мал. 3 Діловий процес на швейній фабриці

1.2. Опис структури ділового процесу

З другого краю етапі визначення ділового процесу необхідно описати його внутрішню структуру. Для цього необхідно визначити:

з яких процесів складається діловий процес, що моделюється;
як ці процеси взаємодіють між собою.

У моделюванні IDEF0 для опису внутрішньої структури процесу використовується механізм декомпозиції.

Відповідно до вимог методології IDEF0, щоб декомпозувати діловий процес, необхідно створити діаграму – нащадок. На цій діаграмі слід уявити процеси, з яких складається діловий процес у рамках системи менеджменту якості (СМЯ).

Розглянемо декомпозицію ділового процесу «Виробляти жіночі пальта» (рис.3).

З огляду на мету моделювання - відповідність ділового процесу вимогам СТБ ІСО 9001 - 2001 декомпозиція ділового процесу включає 4 блоки процесів, представлених на рис. 4.

Відповідно до вимог СТБ ІСО 9000 діловий процес «Виробляти жіночі пальта» включає такі процеси:

- реалізувати відповідальність вищого керівництва з менеджменту якості;

- Здійснювати менеджмент ресурсів;

– реалізувати процеси життєвого циклу;

– здійснювати вимірювання, аналіз та покращення СУЯ.

Примітка – На малюнку 4 не представлені взаємодії між функціональними блоками, що становлять декомпозицію процесу «Виробляти жіночі пальта».1.3.Опис взаємодій між процесами

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

У методології IDEF0 допустимими є 5 (п'ять) типів взаємодій між блоками в межах однієї діаграми (табл.1):

керування;
вихід – вхід;
зворотний зв'язок з управління;
зворотний зв'язок по входу;
вихід – механізм.

Таблиця 1

	Взаємозв'язок з управління: вихід одного процесу впливає виконання іншого процесу, тобто. вихідна дуга блоку 1 є керуючою для блоку 2. У СТБ ІСО 9001 така взаємодія визначає функцію управління «відповідальність керівництва» по відношенню до інших процесів
	Взаємозв'язок по входу: вихід одного процесу є входом іншого, тобто. вихідна дуга блоку 1 є вхідний для блоку 2. Ця взаємодія характерна для будь-яких процесів в організації, наприклад, для процесів життєвого циклу
	Зворотний зв'язок з управління: виходи з одного процесу впливають виконання інших процесів, виконання яких своєю чергою впливає виконання вихідного процесу. Вихідна дуга блоку 1 є керуючою для блоку 2, а вихідна дуга блоку 2 є керуючою для блоку 1. У СТБ ІСО 9001 така взаємодія може визначати: – функцію управління «відповідальність керівництва»; – функцію управління «управління процесами життєвого циклу»; – функцію управління «вимірювання, аналіз та покращення»
	Зворотний зв'язок по входу: вихід із процесу є входом іншого процесу, вихід якого є йому входом, тобто. вихідна дуга блоку 2 є вхідний для блоку 1, вихід якого є для нього входом. У СТБ ІСО 9001-2001 така взаємодія може визначати функцію управління «управління процесами життєвого циклу»
	Взаємозв'язок «вихід - механізм»: вихід одного процесу є механізмом іншого, тобто. вихідна дуга блоку 1 є дугою механізму блоку 2. Такий тип зв'язку відноситься найчастіше до процесів забезпечення ресурсами. У СТБ ISO 9001 така взаємодія може визначати функцію управління «менеджмент ресурсів»

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

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

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

Розглянемо взаємодії між процесами, що становлять діловий процес «Виробляти жіночі пальта» (рис. 5).

Процес «Реалізувати відповідальність вищого керівництва з управління якістю» є керуючим процесом всім інших процесів. Відповідно, вихід цього процесу-«Політика, цілі, посібник з якості, програми якості» є керуючим входом для решти процесів, представлених на діаграмі (рис. 5).

Процес «Здійснювати менеджмент ресурсів» має зв'язок «вихід – механізм» з процесами «Реалізувати процеси життєвого циклу» та «Здійснювати вимірювання, аналіз та покращення СУЯ».

На діаграмі представлений контур зворотного зв'язку: вихід процесу «Здійснювати вимірювання, аналіз та покращення СМЯ» з входом процесу «Реалізувати відповідальність вищого керівництва з менеджменту якості»

Примітка – Правило повноти функціональної моделі IDEF0 точно відповідає вимогам СТБ ІСО 9001 в частині того, що кожен процес повинен забезпечуватися ресурсами (дуги механізмів у IDEF0-моделі), керуватися (дуги управління), виробляти продукцію на виході (вихідні дуги), переробляючи матеріали та/або інформацію, що надходять на його входи (вхідні дуги).

Рис.5 – Взаємодія між процесами

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

На діаграмі А0 (рис.5) діловий процес «Виробляти жіночі пальта» представлений у вигляді 4 процесів. Діаграма А0 є першим рівнем декомпозиції (деталізації) цього процесу. Кожен із 4 представлених процесів у свою чергу може бути декомпозований. На рис. 6 представлена декомпозиція процесу "Реалізувати процеси життєвого циклу".

На діаграмі А3 (рис. 6) процес «Реалізувати процеси життєвого циклу» представлений у вигляді шести процесів, включаючи «Здійснювати закупівлі», який також може бути декомпозований (рис. 7).

Мал. 6.- Декомпозиція процесу «Реалізувати процеси життєвого циклу»

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

Глосарій представляє впорядкований у алфавітному порядку список термінів. Кожному терміну цього списку відповідає визначення чи посилання відповідне визначення, наведене у нормативних документах організації чи вищих органів, регламентах тощо.

Наприклад, для діаграми А34 (рис. 7) фрагмент глосарію виглядатиме так.

Далі розглянемо стандартні методи системного структурного аналізу, описані серією федеральних стандартів США. Icam Definition", відповідно до . Детальну інформацію про всі стандарти цієї серії можна знайти на сайті http://www.idef.com.

Стандарт IDEF0(FIPS183) призначений для створення функціональної моделі, що відображає структуру та функції системи, а також потоки інформації та матеріальних об'єктів, що пов'язують ці функції. Цей документ є оформленням (за ініціативою Міністерства оборони США) у вигляді стандарту технології аналізу складних систем SADT(Structured Analysis and Design Technique), розробленою групою американських аналітиків на чолі з Дугласом Россом у 1973 році.

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

Методологія IDEF0 заснована на таких положеннях:

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

2. Блокове моделювання та його графічне уявлення. Основний концептуальний принцип методології IDEF – представлення будь-якої системи, що вивчається у вигляді набору взаємодіючих і взаємопов'язаних блоків, що відображають процеси, операції, дії, що відбуваються в системі, що вивчається. У IDEF0 усе, що відбувається у системі та її елементах, прийнято називати функціями. Кожній функції ставиться у відповідність блок. На IDEF0-діаграмі (частіше говорять SADT-діаграмі), основному документі при аналізі та проектуванні систем, блок є прямокутником. Інтерфейси, за допомогою яких блок взаємодіє з іншими блоками або з зовнішнім по відношенню до моделюється середовищем, представляються стрілками, що входять в блок або виходять з нього. Вхідні стрілки показують, які умови повинні бути виконані одночасно, щоб функція, що описується блоком, здійснилася.

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

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

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

Приклади завдань, які вирішуються на основі методології моделювання IDEF0:

Аналіз та реінжиніринг бізнес-процесів.

Розробка інформаційної системи управління даними якості.

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

Проектування інформаційної інфраструктури, процедур та регламентів інформаційної взаємодії.

Завдання аналізу ризиків щодо інформаційної безпеки.

Розглянемо відповідно до роботи принципи побудови діаграм за технологією SADT (IDEF0).

Графічна мова SADT проста і гармонійна. В основі методології лежать чотири основні поняття.

Першим із них є поняття « функціональний блок». Функціональний блок графічно зображується у вигляді прямокутника (див. рис. 3.23) і уособлює деяку конкретну функцію в рамках аналізованої системи. За вимогами стандарту назва кожного функціонального блоку має бути сформульована у дієслівному способі (наприклад, « здійснювати послуги", а не " виробництво послуг»). Кожна із чотирьох сторін функціонального блоку має своє певне значення (роль), при цьому: верхня сторона має значення « управління»(cont r ol); ліва сторона має значення « Вхід» ( input); права сторона має значення « вихід» ( output); нижня сторона має значення « механізм» ( mechanism). Кожен функціональний блок у рамках єдиної системи, що розглядається, повинен мати свій унікальний ідентифікаційний номер.

Мета роботи:

вивчення основних принципів методології IDEF0,
створення нового проекту в BPWin,
формування контекстної діаграми,
проведення зв'язків.

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

Кожна IDEF0-діаграма містить блоки та дуги. Блоки зображують функції системи, що моделюється. Дуги зв'язують блоки разом і відображають взаємодії та взаємозв'язки між ними.

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

Типи стрілок

У IDEF0 розрізняють п'ять типів стрілок.

Мал. 2.1Типи стрілок

Мал. 2.2.Зв'язок по виходу

Мал. 2.3. Зв'язок з управління

Зворотний зв'язок з управління виникає тоді; коли вихід деякого блоку впливає блок із великим домінуванням.

Мал. 2.4.Зворотній зв'язок по входу

Мал. 2.5.Зворотній зв'язок з управління

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

Мал. 2.6.Зв'язок вихід-механізм

непомічені гілки містять вагу об'єкти, зазначені у загальній міткедуги після злиття;
помічені перед злиттям гілки містять усі або деякі об'єкти з перерахованих у загальній мітці після злиття,

Кількісний аналіз діаграм

Для проведення кількісного аналізу діаграм перерахуємо показники моделі:

кількість блоків на діаграмі - N;
рівень декомпозиції діаграми - L;
збалансованість діаграми - В;
число стрілок, що з'єднуються з блоком, - А

Мал. 2.7.Приклад незбалансованої діаграми

Введемо коефіцієнт збалансованості діаграми

Необхідно прагнути, щоб Кьбув мінімальним для діаграми.

Інструментарій BPWin

При запуску BPWin за промовчанням з'являється основна панель інструментів, панель інструментів та Model Explorer.

При створенні нової моделі виникає діалог, в якому слід зазначити, чи буде створено модель заново, чи вона буде відкрита з репозитарію ModelMart, внести ім'я моделі та вибрати методологію, в якій буде побудовано модель (рис. 2.8).

Рис.2.8Діалог створення моделі

приклад

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

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

Отже, визначимо контекстну діаграму системи (рис. 2.9).

Рис. 2.9.Контекстна діаграма системи

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

Визначення рівня доступу до системи.
Вибір підсистеми.
Звернення до підсистеми.
Зміна БД (за потреби).

Отримаємо діаграму, зображену на рис. 2.10.

Мал. 2.10.Декомпозиція роботи "Обслуговування, клієнта системи"

Мал. 2.11.Декомпозиція роботи «Визначення рівня доступу до системи»

Відкриття БД.
Виконання запиту.
генерація звітів.

Мал. 2.12.

Коригування діаграми

Зміна діаграми потягне за собою коригування всіх батьківських діаграм (рис. 2.13 – 2.15).

Мал. 2.13.Декомпозиція роботи "Обробка запиту клієнта"

Мал. 2.14.Декомпозиція роботи «Обслуговування клієнта системи» (варіант 2)

Мал. 2.15.Контекстна діаграма системи (варіант 2)

БД користувачів,
БД студентів, (варіант 2)
БД вакансій
БД успішності,
БД тестів,
БД експертних оцінок,
БД резюме.

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

Мал. 2.16.Декомпозиція роботи «Зміна БД»

Мал. 2.17.Декомпозиція роботи "Зміна БД" (варіант 2) Для першого варіанту, зображеного нарис. 2.12

Розглянемо зміну коефіцієнта До bу двох варіантів моделей.

для другого варіанта

Коефіцієнт До bне змінює свого значення, отже, збалансованість діаграми змінюється.

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

перелік Контрольних питань:

Що таке модель в нотації IDEF0?
Що означають роботи в IDEF0?
Назвіть порядок найменування робіт?
Яка кількість робіт має бути присутня на одній діаграмі?
Що називається порядком домінування?
Як розташовуються роботи за принципом домінування?
Яким є призначення сторін прямокутників робіт на діаграмах?
Перелічіть типи стрілок.
Назвіть види взаємозв'язків.
Що називається граничними стрілками?
Поясніть принцип іменування стрілок, що розгалужуються і зливаються.
Які методології підтримуються BPWin?
Наведіть основні елементи головного вікна BPWin.
Опишіть процес створення нової моделі у BPWin.
Як провести зв'язок між роботами?
Як встановити ім'я роботи.
Опишіть декомпозицію роботи.
Як додати роботу на діаграму?
Як дозволити тунельовані стрілки?
Чи може BPWin містити діаграми кількох методологій?

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

При побудові моделі має бути поставлена мета моделювання,що відповідає на такі питання:

· Чому цей процес повинен бути змодельований?

· Що має показувати модель?

· Що може отримати читач?

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

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

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

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

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

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

Мал. 1. Контекст IDEF0.

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

У IDEF0 розрізняють п'ять типів стрілок:

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

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

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

4. Механізм - ресурси, що виконують блок, наприклад, персонал підприємства, верстати, пристрої тощо. На розсуд аналітика стрілки механізму можуть не зображуватися в моделі.

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

Стрілки на контекстній діаграмі служать для опису взаємодії системи з навколишнім світом. Граничні стрілки- стрілки, які починаються біля межі діаграми, а закінчуються у роботи чи навпаки. Внутрішні стрілкизв'язують блоки між собою. Розрізняють п'ять видів зв'язків робіт.

1. Зв'язок по входу – стрілка виходу вищого блоку прямує на вхід нижчестоящого (рис. 2).

Мал. 2. Відношення "вихід-вхід".

2. Зв'язок з управління - вихід вищого блоку прямує на керування нижчестоящого (рис. 3).

Мал. 3. Відношення "вихід-управління".

3. Зворотний зв'язок з управління - вихід нижчого блоку спрямовується на управління вищого (рис. 4).

Мал. 4. Зворотній зв'язок з управління

4. Зворотний зв'язок по входу - вихід нижчого блоку прямує на вхід вищого (рис. 5).

Мал. 5. Відношення зворотного зв'язку по входу

5. Зв'язок вихід-механізм – вихід одного блоку спрямовується на механізм іншого (рис. 6).

Мал. 6 Зв'язок «вихід-механізм».

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

Мал. 7 Приклад контекстної діаграми IDEF0.

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

Рис.8 Приклад діаграми декомпозиції IDEF0.