Така схема може бути складена шляхом використання різних графічних елементів для різних операцій, як описано в роботі [13 ].

Можуть використовуватись різні схеми, які мають два виміри: процес - функція, процес - час і т.п.. Приклад такої схеми показаний на рис. 10.

Для вирішення завдань моделювання складних систем існують добре апробовані методології та стандарти. До таких стандартів належать методології IDEF [14-16]. З їхньою допомогою можна ефективно відображати й аналізувати моделі діяльності широкого спектра складних систем у різних розрізах. При цьому широта й глибина обстеження процесів у системі визначається самим розроблювачем, що дозволяє не перевантажувати створювану модель зайвими даними. У даний момент до сімейства IDEF можна віднести наступні стандарти [15]:

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

· IDEF1 – методологія моделювання інформаційних потоків всередині системи, що дозволяє відображати та аналізувати їх структуру й взаємозв’язки;

Рис. 9. Спрощена блок-схема процесів обслуговування на СТО.

Рис. 10. Схема процес - функція.

· IDEF1X (IDEF1 Extended) – методологія побудови реляційних структур. IDEF1X відноситься до типу методологій “Сутність - взаємозв’язок” (ER – Entity-Relationship) і, як правило, використовується для моделювання реляційних баз даних, що мають відношення до системи, яка розглядається;

· IDEF2 - методологія динамічного моделювання розвитку систем. У зв'язку з досить серйозними складностями аналізу динамічних систем від цього стандарту практично відмовилися, і його розвиток призупинився на самому початковому етапі. Однак у цей час існують алгоритми і їхні комп'ютерні реалізації, що дозволяють перетворювати набір статичних діаграм IDEF0 у динамічні моделі, побудовані на базі “кольорових мереж Петрі” (CPN - Color Petri Nets);

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

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

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

У наш час найбільш часто використовується методологія функціонального моделювання IDEF0 і методологія документування процесів IDEF3.

Історично, IDEF0, як стандарт був розроблений в 1981 році в рамках програми автоматизації промислових підприємств, що носила позначення ICAM (Integrated Computer Aided Manufacturing) і була запропонована департаментом Військово-Повітряних Сил США. Сімейство стандартів IDEF успадкувало своє позначення від назви цієї програми (IDEF=ICAM DEFinition). У процесі практичної реалізації, учасники програми ICAM зіштовхнулися з необхідністю розробки нових методів аналізу процесів взаємодії в промислових системах. З 1981 року стандарт IDEF0 дещо змінився. Остання його редакція була випущена в грудні 1993 року Національним Інститутом з стандартів і технологій США (NIST, http://www.nist.gov ) і прийнята як федеральний стандарт США (http://www.idef.com/IDEF0.html), а в 2000 році - як керівний документ зі стандартизації в Російській Федерації [16].

Національним технічним комітетом зі стандартизації «Управління якістю» Республіки Бєларусь в 2001 році розроблений проект нормативного документу ТК РБ 4.2-Р-05-2001 «Методика й порядок робіт з визначення, класифікації й ідентифікації процесів і побудови карт процесів», що базується на російському стандарті [16].

Докладніше про методологію функціонального моделювання.

В основі методології IDEF0 лежать чотири основних поняття:

Першим з них є поняття функціонального блоку (Activity Box). Функціональний блок графічно зображується у вигляді прямокутника (див. рис. 11) і персоніфікує собою деяку конкретну функцію в рамках розглянутої системи. За вимогами стандарту назва кожного функціонального блоку повинна бути сформульована в дієслівному нахиленні (наприклад, “виробляти послуги”, а не “виробництво послуг”).

Кожна із чотирьох сторін функціонального блоку має своє певне значення (роль), при цьому:

· Верхня сторона має значення “Управління” (Control);

· Ліва сторона має значення “Вхід” (Input);

· Права сторона має значення “Вихід” (Output);

· Нижня сторона має значення “Механізм” (Mechanism).

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

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

Рис. 11. Функціональний блок [15].

Графічним відображенням інтерфейсної дуги є односпрямована стрілка. Кожна інтерфейсна дуга повинна мати своє унікальне найменування (Arrow Label). На вимогу стандарту, найменування повинне бути оборотом іменника.

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

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

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

При побудові IDEF0 - діаграм важливо правильно відокремлювати вхідні інтерфейсні дуги від управляючих. Наприклад, на рис. 12 [15] зображений функціональний блок “Обробити заготівку”.

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

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

Рис. 12. Функціональний блок «Обробити заготовку» [15].

Рис. 13. Функціональний блок «Коректувати технологічні вказівки» [15].

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 14. Декомпозиція функціональних блоків [15].

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

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

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

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

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

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

При побудові IDEF-діаграми необхідно відповісти на наступні питання:

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

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

4.5. Методологія моделювання бізнес-процесів на підприємстві

4.5.1. Загальні підходи до опису бізнес-процесів

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

( http://www.tengrygroup.com/consulting ).

Для управління бізнес-процесом повинні бути розроблені документи, що представлені на рис. 15.

Рис. 15. Документи для управління бізнес-процесом.

Згідно з таким стандартом на підприємстві необхідно зробити описи всіх бізнес-процесів.

Опис бізнес-процесу має включати такі елементи [7]:

1. Текстовий опис моделі регламентованого бізнес-процесу;

2. Матрицю відповідальності за виконання операцій, що входять до складу бізнес-процесу.

3. Графічні моделі регламентованого бізнес-процесу (графічні схеми);

4. Перелік цільових показників бізнес-процесу;

5. Регламенти, що визначають періодичність і порядок аналізу результатів діяльності бізнес-процесу для:

а) оцінки відповідності бізнес-процесу поставленим цілям;

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

в) прийняття попереджуючих дій за відхиленнями, що передбачаються;

г) встановлення цільових показників бізнес-процесу на наступний період.

6. Регламент аналізу з боку власника бізнес-процесу;

7. Регламент аналізу з боку керівника.

У додатку до опису приводяться такі документи (див. Додаток):

1. Положення, посадові й робочі інструкції.

2. Специфікація операцій бізнес-процесу (БП-Ф01).

3. Специфікації входів/виходів (БП-Ф02).

4. Специфікації на ресурси (БП-Ф03).

5. Графічні схеми бізнес-процесу і їхній текстовий опис (БП-Ф04).

6. Показники бізнес-процесу (БП-Ф05).

7. Глосарій (БП-Ф06).

8. Перелік документів бізнес-процесу (БП-Ф07).

При описі бізнес-процесу повинна бути зібрана інформація, представлена нижче в таблиці.

4.5.2. Текстовий опис моделі бізнес-процесу

При описі бізнес-процесу на верхньому рівні в обов'язковому порядку повинні бути вказані:

· назва бізнес-процесу;

· входи бізнес-процесу;

· виходи бізнес-процесу;

· виконавець – структурні підрозділи організації, окремі працівники зовнішні (стосовно організації) виконавці;

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

· перелік операцій бізнес-процесу.

При формуванні мережі бізнес-процесів описуються:

1) значимість і трудомісткість операцій, що виконуються в бізнес-процесі;

2) їхнє відношення до основної діяльності даного підрозділу (бізнес-процесу);

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

Коротко характеризуються показники бізнес-процесу й способи їх досягнення.

4.5. 3. Матриця відповідальностей за виконання операцій бізнес-процесу

Форма матриці відповідальностей по бізнес-процесу має вигляд:

Вл – власник процесу - відповідальний за проведення й кінцевий результат роботи;

У – бере участь у проведенні роботи;

Ін– одержує інформацію про проведення бізнес-процесу (роботи) і результати.

Вик 1, Вик 2 …- виконавці роботи

Список посадових осіб за штатним розкладом:

1- посада 1;

2 - посада 2;

3 - посада 3.

Матрицю відповідальностей за конкретний бізнес-процес можна скласти за результатами заповнення форми БП-Ф01.

4.5. 4. Графічні моделі бізнес-процесу (графічні схеми)

Правила формування графічних схем бізнес-процесів за методологією IDEF докладно описані в [14, 15, 16].

А) Обов'язкові й рекомендовані формати графічних схем бізнес-процесів.

Вибір формату для опису бізнес-процесу визначається масштабом і ступенем деталізації розглянутого бізнес-процесу.

Виділяється кілька рівнів деталізації бізнес-процесу:

1) 1-й умовний рівень - бізнес-процес організації в цілому. Рекомендована глибина деталізації - 2-3 рівня;

2) 2-й умовний рівень - бізнес-процес підрозділу організації Можлива глибина деталізації операцій бізнес-процесу 2 – 3 рівня;

3) 3-й умовний рівень - бізнес-процес робочого місця підрозділу. Можлива глибина опису - 1-2 рівня.

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

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

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

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

Б) Правила формування моделей бізнес-процесів в IDEFO.

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

Модель IDEFO рекомендована до застосування в організації при описі бізнес-процесів на верхньому рівні.

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

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

Умовні позначки формату IDEFO представлені в таблиці.

№	Найменування	Опис	Графічне подання
	Модуль поведінки (функція або операція)	Об'єкт служить для опису функцій (операцій, робіт), що виконуються підрозділами/ співробітниками підприємства
	Стрілка зліва	Стрілка описує входи функції (операції)
	Стрілка праворуч	Стрілка описує виходи функції (операції)
	Стрілка зверху	Стрілка описує управляючу дію, наприклад розпорядження, нормативний документ і т.д.
	Стрілка знизу	Стрілка знизу описує механізми або ресурси, що не витрачаються, наприклад, персонал, які використовуються для виконання процесу

На діаграмі IDEFO стрілки зв'язують функції які виконуються.

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

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

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

Правила складання моделей IDEF0 наступні.

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

Блоки на діаграмі повинні розташовуватися діагонально - від лівого верхнього кута діаграми до правого нижнього в порядку наданих номерів.

Діаграми (крім контекстної) повинні містити не менш трьох і не більше восьми блоків.

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

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

Імена блоків (функцій, що виконуються) повинні бути унікальними.

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

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

Якщо ті самі дані служать і для управління, і для входу, показується тільки стрілка управління.

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

Зворотні зв'язки щодо управлінню показують «петлею зверху» (нагору й над). Зворотні зв'язки щодо входу зображуються «нижньою петлею» (униз і під).

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

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

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

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

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

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

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

В) Правила формування моделей бізнес-процесів в IDEF3.

Формат IDEF3 застосовується для опису бізнес-процесів у вигляді потоків операцій (робіт).

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

№	Найменування	Опис	Графічне представлення
	Модель операції (роботи )	Об'єкт служить для опису операцій (робіт), що виконуються підрозділами/співробітниками підприємства.
	Об'єкт посилання	Об'єкт, використовуваний для опису посилань на інші діаграми моделі, циклічні переходи в рамках однієї моделі, різні коментарі до операцій
	Логічне «І»	Логічний оператор, що визначає зв'язки між операціями в рамках процесу. Дозволяє описати розгалуження процесу	&
	Логічне «АБО»	Логічний оператор, що визначає зв'язки між операціями в рамках процесу. Дозволяє описати розгалуження процесу	O
	Логічне «АБО» що виключає	Логічний оператор, що визначає зв'язки між операціями в рамках процесу. Дозволяє описати розгалуження процесу	X

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

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

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

Кожна операція має назву й номер.

Назва операції виражається дієсловом або віддієслівним іменником.

Номер операції використовується для її ідентифікації в моделі.

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

Зв'язок між операціями, виражений як послідовність виконання в часі може бути двох видів: 1) старший зв'язок; 2) зв'язок -відношення.

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

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

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

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

Стрілки з'єднуються із прямокутниками, що зображують операції в такий спосіб: 1) кінці стрілок повинні торкатися зовнішньої сторони прямокутника, але не перетинати її; 2) стрілки повинні приєднуватися до прямокутника на його сторонах, приєднання в кутах не допускається; 3) на відміну від IDEFO-діаграм, стрілки можуть підходити й виходити з будь-яких граней прямокутників.

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

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

Стрілки можуть зливатися й розгалужуватися тільки через перехрестя.

У таблиці нижче приводяться типи перехресть що використовуються.

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

Правила створення перехресть.

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

Кожному перехрестю для злиття має передувати перехрестя для розгалуження.

Перехрестя для злиття «Й» не може випливати за перехрестям для розгалуження типу синхронного або асинхронного «АБО».

Перехрестя для злиття «Й» не може випливати за перехрестям для розгалуження «АБО» що виключає.

Перехрестя для злиття типу «АБО» що виключає не може випливати за перехрестям для розгалуження типу «Й».

Перехрестя, що має одну стрілку на одній стороні, повинно мати більше однієї стрілки на іншій.

Посилання використаються для вказівки деякої додаткової інформації про операції або перехрестя. Посилання застосовуються для вказівки наступних властивостей операцій і перехресть: 1) участі важливого об'єкта у виконанні операції; 2) циклів виконання операцій; 3) частоти виконання операцій; 4) іншої важливої інформації.

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

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

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

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

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

Як контекстну діаграму рекомендується використовувати діаграму, виконану в IDEF0 нотації.

Правила побудови діаграм IDEF3 такі.

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

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

Діаграми повинні містити не менш трьох і не більше 8 операцій.

Кожна операція має свій унікальний номер та ім'я.

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

Старший зв'язок і зв'язок-відносини можуть мати ім'я, які також повинні бути унікальними. Унікальним ім'ям повинні володіти об'єкти посилань.

Кожному перехрестю привласнюється унікальний номер.

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

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

Дочірні діаграми (описи й сценарії) повинні мати один вхід. Один вихід повинна мати дочірня діаграма-опис.

Стрілки повинні зливатися й розгалужуватися через перехрестя.

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

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

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

Діаграми повинні бути декомпозовані до рівня, на якому присутні операції обробки конкретних документів (або сукупності документів).

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

Г) Вимоги до оформлення листа моделі бізнес-процесу.

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

Графічно лист моделі оформляється так, як показано на рис. 16.

На кожному листі має бути зазначена наступна інформація:

1. назва моделі бізнес-процесу;

2. дата останньої зміни моделі;

3. статус листа;

4. номер діаграми в моделі бізнесу-процесу;

5. назва листа моделі;

6. номер версії листа;

7. номер листа в підшивці.

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

Кожному листу моделі бізнес-процесу привласнюється статус і номер версії.

Визначено наступні статуси моделі:

У - затверджена, діюча модель;

Р - модель що розроблюється (робоча);

А - архівна, застаріла, недіюча модель.

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

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

Моделі бізнес-процесу в цілому привласнюється статус і номер версії.

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

Приклади графічних схем бізнес-процесу підготовки документа «А» показані на рис. 17-22.

Рис. 16. Вимоги до оформлення листа моделі бізнес-процесів.

Рис. 17. Контекстна діаграма IDEF0 бізнес-процесу підготовки документу «А».

Рис. 18. Дочірня діаграма IDEF0 А0 бізнес-процесу підготовки документу «А».

Рис. 19. Діаграма IDEF3 потоку робіт (workflow modeling, Process Description Capture Method) опису бізнес процесу підготовки документу «А».

Рис. 20. Діаграма IDEF3 потоку робіт (workflow modeling, Process Description Capture Method) опису бізнес процесу підготовки документу «А».

Рис. 21. Діаграма IDEF3 потоку робіт (workflow modeling, Process Description Capture Method) опису бізнес процесу підготовки документу «А».

Рис. 22. Діаграма IDEF3 потоку робіт (workflow modeling, Process Description Capture Method) опису бізнес процесу підготовки документу «А».

4.5. 5. Перелік цільових показників бізнес-процесу;

Показники бізнес-процесу вибираються виходячи з наступних вимог:

1. Структурування за трьома основними напрямками:

· показники бізнес-процесу;

· показники продукту бізнес-процесу;

· показники задоволеності споживача (клієнта) бізнес- процесу.

2. Показники повинні адекватно відображати реальний стан справ.

3. Рекомендується визначати кількісні показники.

4. Показники повинні мати двоступінчастий характер (див. рис. 7):

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

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

Цільові показники бізнес-процесу встановлюються виходячи з:

а) стратегічних цілей і планів розвитку компанії;

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

в) поточних показників бізнес-процесу.