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

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

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

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

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

Функціональна методика IDEF0

Методологію IDEF0 можна вважати наступним етапом розвитку добре відомої графічної мови. функціональних систем SADT (Structured Analysis and Design Technique). Історично IDEF0 як стандарт був розроблений у 1981 році в рамках великої програми автоматизації промислових підприємств, яка мала позначення ICAM (Integrated Computer Aided Manufacturing). Сімейство стандартів IDEF успадкувало своє позначення від назви цієї програми (IDEF = Icam DEFinition), і остання його редакція була випущена в грудні 1993 Національним Інститутом по Стандартам і Технологіям США ( NIST ).

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

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

(Activity Box) є деякою конкретною функцією в рамках аналізованої системи. За вимогами стандарту назва кожного функціонального блоку має бути сформульована у дієслівному способі (наприклад, "здійснювати послуги"). На діаграмі функціональний блок є прямокутником (рис. 6.1). Кожна із чотирьох сторін функціонального блоку має своє певне значення (роль), при цьому:

• верхня сторона має значення "Управління" (Control);
• ліва сторона має значення "Вхід" (Input);
• права сторона має значення "Вихід" (Output);
• нижня сторона має значення "Механізм" (Mechanism).

Рис. 6.1.

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

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

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

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

Обов'язкове наявність керуючих інтерфейсних дуг одна із головних відмінностей стандарту IDEF0 з інших методологій класів DFD ( Data Flow Diagram ) і WFD (Work Flow Diagram).

Декомпозиція(Decomposition) є основним поняттям стандарту IDEF0. Принцип декомпозиції застосовується при розбиття складного процесу на його функції . При цьому рівень деталізаціїпроцесу визначається безпосередньо розробником моделі.

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

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

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

У пояснювальному тексті до контекстній діаграмімає бути вказана ціль(Purpose) побудови діаграми у вигляді короткого описута зафіксована точка зору(Viewpoint).

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

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

Виділення підпроцесів. У процесі декомпозиції функціональний блок, який у контекстній діаграмівідображає систему як єдине ціле, деталізується на іншій діаграмі. Діаграма другого рівня, що вийшла, містить функціональні блоки, що відображають головні підфункції функціонального блоку контекстної діаграми, і називається дочірньою (Child Diagram) стосовно нього (кожен із функціональних блоків, що належать дочірній діаграмі, відповідно називається дочірнім блоком – Child Box). У свою чергу, функціональний блок - предок називається батьківським блоком по відношенню до дочірньої діаграми (Parent Box), а діаграма, до якої він належить – батьківською діаграмою (Parent Diagram). Кожна з підфункцій дочірньої діаграми може бути деталізована далі шляхом аналогічної декомпозиції відповідного їй функціонального блоку. У кожному випадку декомпозиції функціонального блоку всі інтерфейсні дуги, що входять до цього блоку або виходять із нього, фіксуються на дочірній діаграмі. Цим досягається структурна цілісність IDEF0 -моделі.

Іноді окремі інтерфейсні дуги вищого рівнянемає сенсу продовжувати розглядати на діаграмах нижнього рівня, чи навпаки - окремі дуги нижнього відбивати на діаграмах вищих рівнів – це лише перевантажувати діаграми і робити їх складними сприйняття. Для вирішення подібних завдань у стандарті IDEF0 передбачено поняття тунелювання. Позначення " тунелю " (Arrow Tunnel ) як двох круглих дужок навколо початку інтерфейсної дуги позначає, що ця дуга була успадкована від функціонального батьківського блоку і виникла (з " тунелю " ) лише з цій діаграмі. У свою чергу, таке ж позначення навколо кінця (стрілки) інтерфейсної дуги в безпосередній близькості від блоку-приймача означає той факт, що в дочірній по відношенню до цього блоку діаграмі ця дуга не відображатиметься і не розглядатиметься. Найчастіше буває, що окремі об'єкти та відповідні їм інтерфейсні дуги не розглядаються на деяких проміжних рівнях ієрархії, – у такому разі вони спочатку "занурюються в тунель", а потім за необхідності "повертаються з тунелю".

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

  Що надходить у підрозділ "на вході"?

  • Які функції та у якій послідовності виконуються у межах підрозділу?
  • Хто є відповідальним за виконання кожної з функцій?
  • Чим керується виконавець під час виконання кожної з функцій?
  • Що результат роботи підрозділу (на виході)?

  На основі наявних положень, документів та результатів опитувань створюється чернетка (Model Draft) моделі.

• Поширення чернетки для розгляду, погоджень та коментарів. На цій стадії відбувається обговорення чернетки моделі з широким колом компетентних осіб (у термінах IDEF0 – читачів) на підприємстві. При цьому кожна з діаграм чорнової моделі письмово критикується та коментується, а потім передається автору. Автор, у свою чергу, також письмово погоджується з критикою або відкидає її з викладом логіки прийняття рішення та знову повертає відкориговану чернетку для подальшого розгляду. Цей цикл триває доти, доки автори та читачі не дійдуть єдиної думки.
• Офіційне утвердження моделі. Твердження узгодженої моделі відбувається керівником робочої групиу тому випадку, якщо у авторів моделі та читачів відсутні розбіжності щодо її адекватності. Остаточна модель є узгодженим уявленням про підприємство (систему) з заданої точкизору та для заданої мети.

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

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.

IDEF0 діаграми будуються за допомогою програми BPWin. Призначені вони для графічного моделювання бізнес-процесів, що відбуваються.

Про методологію IDEF0

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

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

Елементи, що використовуються для IDEF0

Як уже згадувалося, використовується 2 типи геометричних примітивів: прямокутники та стрілки. Прямокутники позначають певні процеси, функції, роботи або завдання, що мають на меті і ведуть до зазначеного результату. Взаємодія процесів між собою та зовнішнім середовищем позначається за допомогою стрілок. У IDEF0 розрізняють 5 різних типівстрілки.

Можливості використання IDEF0

Методологію IDEF0 можна використовуватиме опису функціонального аспекти будь-якої інформаційної системи.

Типи зв'язків між процесами IDEF0

В інтересах моделі створювати такі зв'язки побудов, щоб внутрішні зв'язки були якомога сильнішими, а зовнішні - якомога слабшими. Це сильна сторонамоделювання за допомогою IDEF0. Приклади діаграм можна побачити самі і переконатися в правдивості цих слів. Для полегшення встановлення зв'язків такі з'єднуються у модулі. Між модулями встановлюються зовнішні зв'язки, а всередині модулів – внутрішні. Розрізняють кілька типів зв'язків.

1. Ієрархічний ("частина" - "ціле") зв'язок.

2. Керуюча (регламентуюча, підлегла):

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

3. Функціональна чи технологічна:

2) зворотний вхідний.

3) споживча;

4) логічна;

5) методична чи колегіальна;

6) ресурсна;

7) інформаційна;

8) тимчасова;

9) довільна.

Побудова блоків та зв'язків у діаграмах

Методологія IDEF0 надає цілий рядправил та рекомендацій щодо свого використання та покращення якості використання. Так, у діаграмі відображається один блок, на якому можна задати назву системи, її призначення. До блоку або блоку веде 2-5 стрілок. Можна більше або менше, але щонайменше дві стрілки необхідні для входу/виходу, а решта для додаткових робітта їх вказівки на діаграмі. Якщо стрілок більше 5, слід подумати про оптимальність побудови моделі, і чи не можна зробити її ще більш деталізованою.

Побудова блоків у діаграмах декомпозиції

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

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

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

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

Найменування

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

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

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

Інформація про стрілки

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

Приклад реалізації методології IDEF0 на конкретній моделі

Ви вже дізналися, що таке IDEF0 діаграма, приклади та правила побудови таких діаграм частково побачили. Тепер слід звернутись і до практики. Для кращого розуміння пояснення йтиме не на якійсь «загальній» моделі, а на конкретному прикладі, який дозволить краще та повніше зрозуміти особливості роботи з IDEF0 у програмі BPWin.

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

Вихідною інформацією виступають:

1. дані про лінію шляхів;
2. паспорт усієї дистанції;
3. план шляху.

Керуючі дані:

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

Результатом моделі є:

1. Обмеження допустимих швидкостей із зазначенням причини обмеження.
2. Допустимі швидкості під час руху на окремих пунктах і під час перегону складів.

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

Висновок

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

Методологія функціонального моделювання IDEF0 - це технологія опису системи в цілому як множини взаємозалежних дій або функцій. Важливо відзначити його функціональну спрямованість, тобто. IDEF0-функції системи досліджуються незалежно від об'єктів, які забезпечують їхнє виконання. "Функціональна" думка дозволяє чітко відокремити аспекти призначення системи від аспектів її фізичної реалізації. Приклад діаграми IDEF0 наведемо на рис. 3.6.19 а, 3.6.19 б, 3.6.19, 3.6.19г.

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

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

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

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

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

Синтаксис графічної мови IDEF0 включає блоки, стрілки, діаграми та правила.

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

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

Рис. 3.6.20. Приклад блоку

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

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

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

Рис.3.6.19а. Приклад такої контекстної функції

Рис. 3.6.19 б. Приклад діаграми IDEF0

Рис. 3.6.19 ст. Приклад діаграми IDEF0

Рис. 3.6.19 Приклад діаграми IDEF0

У IDEF0 також моделюються управлінняі механізми виконання.Під управлінням розуміються об'єкти, що впливають спосіб, яким блок перетворює вхід у вихід. Механізм виконання – об'єкти, які безпосередньо виконують перетворення входу у вихід, але залишаються незмінними.

I (Input) – вхід – те, що споживається під час виконання процесу;

З (Control) – управління – обмеження та інструкції, що впливають перебіг виконання процесу;

О (Output) – вихід – те, що результат виконання процесу;

М (Mechanism) – виконуючий механізм – те, що використовується виконання процесу, але залишається незмінним.

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

Рис. 3.6.21. Кожен тип стрілки з'єднується з певною стороною функціонального блоку

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

Дамо докладне призначення кожної стрілки.

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

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

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

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

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

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

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

Комбіновані стрілки. У IDEF0 існує п'ять основних видів комбінованих стрілок: 1) вихід – вхід, 2) вихід – управління, 3) вихід – механізм виконання, 4) вихід – зворотний зв'язок на управління та 5) вихід - Зворотній зв'язок на вхід.

1) Стрілка вихід – вхід застосовується, коли один із блоків повинен повністю завершити роботу перед початком роботи іншого блоку. Так, на рис. 3.6.22 формування рахунку має передувати прийому замовлення.

Рис. 3.6.22. Комбінація стрілок вихід – вхід

2) Стрілка вихід – управління відображає ситуацію переважання одного блоку над іншим, коли один блок керує роботою іншого. На рис. 3.6.23 принципи формування інвестиційного портфеля впливають поведінка брокерів на біржі.

Рис. 3.6.23. Комбінована стрілка вихід – керування

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

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

Рис. 3.6.24. Комбінована стрілка вихід – механізм виконання

Рис. 3.6.25. Комбінована стрілка вихід – зворотний зв'язок на керування

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

Рис. 3.6.26. Комбінована стрілка вихід – зворотний зв'язок на вхід

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

Рис.3.6.27. Роз'єднана на дві частини та перейменована стрілка

На IDEF0-діаграмах є ще стрілки виду (?). Такі стрілки називають тунелями. Вони пов'язані з поняттям пов'язаних стрілок,яке використовується для керування рівнем деталізації діаграм. На рис. 3.6.28, наприклад, стрілка "корпоративна інформаційна система" є важливим механізмом виконання для даної діаграми, але, можливо, вона більше ніде не використовується в моделі. Тунель у разі використовується як альтернатива захаращенню батьківських діаграм приміщенням ними несуттєвих їхнього рівня стрілок.

Рис. 3.6.28. Приклад застосування тунелю

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

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

Усі елементи заголовка діаграми перераховані у табл. 3.1.6.

Рис. 3.6.29. Приклад застосування тунелю

Таблиця 3.1.6. Елементи заголовка діаграми IDEF0

Всі елементи підвалу діаграми перераховані в табл. 3.1.7.

Таблиця 3.1.7. Елементи "підвалу" діаграми IDEF0

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

Формально механізм рецензування та модифікації діаграм підтримується полями Status та нумерацією діаграм, контроль історії змін – полем Field (див. табл. 3.1.6).

Жодна модель має будуватися без ясного усвідомлення об'єкта і цілей моделювання. Вибране визначення мети моделювання має відповідати на такі запитання:

Чому моделюється даний процес?

Що виявить дана модель?

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

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

Які завдання менеджера?

Які завдання клерка?

Хто контролює роботу?

Яка технологія потрібна для виконання кожного кроку? і т.п.

Щоб ближче познайомиться зі стандартом IDEF0, про нього необхідно дізнатися наступне:

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

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

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

Класифікація входів та виходів робіт

Стандарт пропонує наступну типізацію входів робіт:

• Вхід. Входить у роботу ліворуч і показує інформаційні та матеріальні потоки, які перетворюються на бізнес процесі.
• Управління.Входить у роботу зверху і показує матеріальні та інформаційні потоки, які перетворюються на процесі, але необхідні його виконання.
• Механізм.Входить у роботу знизу і показує людей, технічні засоби, інформаційні системиі т.п., за допомогою яких бізнес-процес реалізується.
• Результативиходять із блоку праворуч.

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

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

IDEF0 - модель:

Модель включає такі документи, які посилаються один на одного:

• Графічні діаграми— головний компонент IDEF0-моделі, який графічно, за допомогою блоків і стрілок та їх з'єднань, відображає інформацію про систему, що моделюється. Блоки становлять основні функції. Ці функції можуть бути розбиті (декомпозовані) на складові і представлені у вигляді більш докладних діаграм. Процес декомпозиції триває до того часу, поки об'єкт нічого очікувати описаний лише на рівні деталізації, необхідному задля досягнення цілей конкретного проекту.
• Текст;
• Глосарій— Для кожного елемента діаграми створюється та підтримується набір визначень, ключових слів, пояснень, що характеризують об'єкт, який представляє цей елемент. Цей набір називається глосарієм та є описом сутності даного елемента. Глосарій гармонійно доповнює наочну графічну мову, забезпечуючи діаграми необхідною додатковою інформацією.

Принцип декомпозиції при побудові моделі бізнес-процесів

1. Контекстна діаграма: мета та думка

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

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

2. Деталізація

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

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

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

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

Принцип тунелювання

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

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

Принцип обмеження складності

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

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

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

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

Для аналізу діаграми з погляду її перевантаженості та складності для сприйняття використовується кількісний аналіз. Для аналізу використовуються такі показники:

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

Коефіцієнт збалансованості

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

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

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

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

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

Оцінка імен

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

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

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

Коефіцієнт, що кількісно відображає даний критерій, можна записати як:

L*C

— твір рівня моделі на кількість збігів імен блоків зі словами зі словника. Чим нижчий рівень моделі (більше L), тим цінніші збіги.