IDEF0. Знайомство з нотацією і приклад використання. Програма комп'ютерного моделювання BPwin (AllFusion Process Modeler) Програми розробки моделей idef0

Відома сьогодні вже не тільки у вузьких колах абревіатура IDEF0 є першою методологією, що стандартизує роботу над бізнес-процесами. Вона була розроблена в середині минулого століття в рамках аерокосмічного проекту в США і, показавши свою ефективність, стала федеральним стандартом. У нашій країні 2000 року підготовлений документ « Методологія функціонального моделювання IDEF0. керівний документ Методологія функціонального моделювання IDEF0 Керівний документ. Видання офіційне. Держстандарт Росії РД IDEF0 - 2000. Розроблено Науково-дослідним Центром CALS - технологій «Прикладна Логістика». Прийнято і введений в дію наказом Держстандарту України 2000 г. Москва», Але як стандарт він так і не був затверджений. Хоча це не завадило даної методології стати в нашій країні одним з найбільш популярних інструментів графічного моделювання бізнес-процесів. У даній статті я пропоную вам розглянути модель IDEF0 і оцінити актуальність цього підходу в даний час.

Основні поняття і скорочення

Розберемося трохи з назвами ключових елементів методології. Графічний стандарт IDEF0 є частиною методології SADT (Structured Analysis and Design Technique - метод структурного аналізу і проектування). IDEF - це скорочення від ICAM Definition, а ICAM утворено від Integrated Computer Aided Manufacturing, що перекладається як інтегрована комп'ютеризація виробництва. Методологія SADT - це ціле сімейство з 15 різних моделей, які в комплексі повинні були дозволити досліджувати структуру, параметри і характеристики виробничо-технічних і організаційно-економічних систем.

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

Нотація IDEF0 - це досить сувора методика, яка спочатку була розроблена, як і стандарти технічного конструювання, для ручного моделювання. Тому там містяться вимоги щодо розміщення стрілок, формату всіх елементів, змісту інформаційної рамки до IDEF0 діаграмі тощо. Оскільки діяльність компанії - це складна багаторівнева система дій, то схем виходить завжди багато, і необхідна однозначна систематизація і навігація по всіх елементах моделі. Зараз це роблять в основному комп'ютерні системи, що підтримують моделювання в даній нотації. На території Росії найбільш відомими і доступними на сьогодні є системи AllFusion Process Modeler і Business Studio. Оглядом цих систем я планую присвятити окремі статті.

функціональний блок

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

Обов'язкові елементи функціонального блоку в IDEF0

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

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

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

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

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

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

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

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

1. Мета - конкретна формулювання призначення моделі, по якій можна звіряти надалі точність побудови моделі.
2. Точка зору - від чийого особи будується модель, так як модель залежна завжди від її автора і фокусу уваги. Якщо ми будуємо загальну модель підприємства, то зазвичай вона представляється з точки зору його директора.
3. Тип моделі - це вказівка ​​на те, яка інформація відображена на схемах. Тут може бути 2 принципових варіанти: AS IS ( «як є») або TO BE ( «як буде»). Такий поділ необхідно, так як ми можемо будувати моделі як для аналізу діяльності, так і для її трансформації. Ми повинні чітко усвідомлювати те, що ми робимо, а також доносити цю інформацію до оточуючих.

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

Основні потоки

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

1. Матеріальний: матеріали та комплектуючі на вході і готова продукціяна виході.
2. Клієнтський: потенційний клієнт на вході і задоволений на виході.
3. Фінансовий: на вході це зазвичай інвестиції, платежі клієнтів (виручка), кредити та інші доходи; на виході - це платежі постачальникам, податки, платежі по кредитах і прибуток.
4. Інформаційний: на вході це все потоки інформації про зовнішнє середовище (стан ринку, поведінку конкурентів, технологічні інноваціїта ін.), а на виході - це потік інформації, яку компанія повідомляє про себе світові (вся рекламна інформація, а так само всі види звітності перед контролюючими органами).

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

(Натисніть для збільшення)

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

Стрілки управління можуть бути представлені тільки 1 видом потоку - інформаційним, який можна розбити на 2 підвиди. Перший - це документи, такі як:

• закони та норми;
• накази, розпорядження;
• інструкції і регламенти;
• плани;
• конструкторська документація та ін.

Другий - це недокументированная інформація, до якої найчастіше ставляться вимоги власників.

І, нарешті, механізми - тут тільки 2 види потоків: обладнання (матеріальний) і виконавці (підрозділи і люди). Тут не може бути документів, як і не може бути людей на стрілках управління!

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

декомпозиція

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

(Натисніть для збільшення)

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

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

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

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

(Натисніть для збільшення)

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

Подальша робота над моделлю аналогічна першому кроці - проводиться декомпозиція кожного функціонального блоку першого рівня. Нумерація блоків буде містити при цьому номер першого рівня: А1.1 ... А1.n, A2.1 ... A2.n і т.д.

Висновки про актуальність нотації

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

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

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

• конкретизації подій запуску і зупинки процесу;
• умов переходу від одних дій до інших;
• можливості наочно відобразити всі ресурси і виконавців без перевантаження схеми стрілками.

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

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

Навчіться бачити і розуміти функціональну структуру свого бізнесу!

В даний час в Росії різко зріс інтерес до загальноприйнятих на Заході стандартам менеджменту, проте, в реальній практиці управління існує один дуже показовий момент. Багатьох керівників до сих пір можна поставити в глухий кут прямим питанням про організаційній структурікомпанії або про схему існуючих бізнес-процесів. Найбільш просунуті і регулярно читають економічну періодику менеджери, як правило, починають креслити зрозумілі тільки їм одним ієрархічні діаграми, а й в цьому процесі зазвичай швидко заходять в глухий кут. Те ж саме стосується співробітників і керівників різних служб і функціональних підрозділів. У більшості випадків, єдиним набором викладених правил, відповідно до яких має функціонувати підприємство, є набір окремих положень і посадових інструкцій. Найчастіше ці документи складалися не один рік тому, слабо структуровані і невзаємопов'язаних між собою і, внаслідок цього, просто припадають пилом на полицях. До пори до часу подібний підхід був виправданий, тому що під час становлення російської ринкової економіки поняття конкуренції практично було відсутнє, та й витрати вважати не було особливої ​​потреби - прибуток була гігантською. В результаті цього, ми бачимо протягом останніх двох років цілком зрозумілу картину: великі компанії, які виросли на початку 90-х років, поступово здають свої позиції, аж до повного виходу з ринку. Частково це обумовлено тим, що на підприємстві не були впроваджені стандарти управління, повністю відсутнє поняття функціональної моделі діяльності і місії. За допомогою моделювання різних областей діяльності можна досить ефективно аналізувати "вузькі місця" в управлінні та оптимізувати загальну схему бізнесу. Але, як відомо, на будь-якому підприємстві вищий пріоритет мають тільки ті проекти, які безпосередньо приносять прибуток, тому мова про обстеження діяльності та її реорганізації зазвичай йде тільки під час відчутного кризи в управлінні компанією.

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

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

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

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

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

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

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

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

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

Історія виникнення стандарту IDEF0

Методологію IDEF0 можна вважати наступним етапом розвитку добре відомого графічного мови опису функціональних систем SADT (Structured Analysis and Design Teqnique). Кілька років тому в Росії невеликим тиражем вийшла однойменна книга, присвячує опису основних принципів побудови SADT-діаграм. Історично, IDEF0, як стандарт був розроблений в 1981 році в рамках великої програми автоматизації промислових підприємств, Яка носила позначення ICAM (Integrated Computer Aided Manufacturing) і була запропонована департаментом Військово-Повітряних Сил США. Власне сімейство стандартів IDEF успадкувало своє позначення від назви цієї програми (IDEF = ICAM DEFinition). В процесі практичної реалізації, учасники програми ICAM зіткнулися з необхідністю розробки нових методів аналізу процесів взаємодії в промислових системах. При цьому крім вдосконаленого набору функцій для опису бізнес-процесів, однією з вимог до нового стандарту була наявність ефективної методології взаємодії в рамках "аналітик-фахівець". Іншими словами, новий метод повинен був забезпечити групову роботу над створенням моделі, з безпосередньою участю всіх аналітиків і фахівців, зайнятих в рамках проекту.

В результаті пошуку відповідних рішень народилася методологія функціонального моделювання IDEF0. C 1981 року стандарт IDEF0 зазнав кілька незначних змін, в основному обмежує характеру, і остання його редакція була випущена в грудні 1993 року Національним Інститутом За стандарти і Технологій США (NIST).

Основні елементи і поняття IDEF0

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

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

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

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

Малюнок 1. Функціональний блок.

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

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

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

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

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

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

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

Малюнок 2.

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

Малюнок 3.

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

Обов'язкова наявність керуючих інтерфейсних дуг є одним з головних відмінностей стандарту 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 - моделі. Наочно принцип декомпозиції представлений на малюнку 4. Слід звернути увагу на взаємозв'язок нумерації функціональних блоків і діаграм - кожен блок має свій унікальний порядковий номер на діаграмі (цифра в правому нижньому кутку прямокутника), а позначення під правим кутом вказує на номер дочірньої для цього блоку діаграми . Відсутність цього позначення говорить про те, що декомпозиції для даного блоку не існує.

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

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

Малюнок 4. Декомпозиція функціональних блоків.

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

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

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

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

Дисципліна групової роботи над розробкою IDEF0-моделі

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

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

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

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

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

В останні рокиінтерес в Росії до методологій сімейства IDEF неухильно зростає. Це я постійно спостерігаю, переглядаючи статистику звернень до своєї персональної web-сторінці (http://www.vernikov.ru), на якій коротко описані основні принципи цих стандартів. При цьому інтерес до таких стандартів, як IDEF3-5 я б назвав теоретичним, а до IDEF0 цілком практично обґрунтованим. Власне кажучи, перші Case-засоби, що дозволяють будувати DFD і IDEF0 діаграми з'явилися на российкие ринку ще в 1996 році, одночасно з виходом популярної книги по принципам моделювання в стандартах SADT.

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

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

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

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

Які функції, і в якій послідовності виконуються в рамках підрозділу?

Хто є відповідальним за виконання кожної з функцій?

Чим керується виконавець при виконанні кожної з функцій?

Що є результатом роботи підрозділу (на виході)?

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

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

Висновок з усього цього можна зробити наступний: зовсім не обов'язково кожен раз самим придумувати рішення для стандартних завдань. Завжди, коли Ви зустрічаєтеся з необхідністю аналізу тієї чи іншої функціональної системи (від системи проектування космічного корабля, до процесу приготування комплексного вечері) - використовуйте роками перевірені і обкатані методи. Одним з таких методів і є 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 наказує побудова ієрархічної системи діаграм - одиничних описів фрагментів системи. Спочатку проводиться опис системи в цілому і її взаємодії з навколишнім світом (контекстна діаграма). Було побудовано три рівня діаграми:

1. Контекстна

2. Функціональна декомпозиція

Малюнок 1 - Контекстна діаграма «Облік комп'ютерної техніки підприємства»

На малюнку 1 представлена ​​контекстна діаграма бізнес процесу «Облік комп'ютерної техніки підприємства». Вона відображає систему в цілому і її взаємодія з основними зовнішніми потоками інформації.

На контекстної діаграмі позначені стрілки.

Види стрілок:

· Вхід (вхідні матеріали: комп'ютери та комплектуючі)

· Вихід (виходом є звіт)

· Стрілками управління є документи і керівники

· Стрілками механізмів є співробітники і обладнання

Вхідна інформація для обробки:

Комп'ютери - ПК (персональні комп'ютери) знаходяться на підприємстві

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

Вихідні потоки:

Звіт - готовий звіт з обліку комп'ютерної техніки підприємства

Вхідні управління:

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

Накази - поставлена ​​задача підприємству (провести облік комп'ютерної техніки на підприємстві за допомогою тих чи інших інформаційних систем)

Керівники - директора і головні керуючі підприємством.

Вхідні ресурси:

ПК - комп'ютери, за допомогою яких ведеться облік.

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

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

Малюнок 2 - Функціональна декомпозиція «Облік комп'ютерної техніки підприємства»

Були виділені наступні види робіт:

1) Оформлення поставок - процес, в якому відбувається привласнення id товару, відправка на зберігання, на склад і занесення інформації про товар в програму.

У роботу Оформлення поставок входить сім граничних стрілок (вхід, управління, механізм) і виходить внутрішня стрілка (зв'язок по входу).

Стрілка зв'язок по входу між роботами Оформлення поставок і обслуговування комп'ютера (комп'ютер);

Стрілки входу, виходу, управління повторюються в наступних роботах.

2) Обслуговування комп'ютера - процес, в якому відбувається збірка, ремонт і модернізація комп'ютерів.

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

Стрілка управління - правила, накази, керівник;

Стрілка зв'язок по входу між роботами Обслуговування комп'ютера і Розстановка (занесення даних в базу), між роботами Обслуговування комп'ютера і Складання звіту (занесення даних в базу);

3) Розстановка - процес, в якому відбувається розстановка комп'ютерів по офісах (кабінетах).

Стрілки управління - правила, накази, керівник;

Стрілка механізму - співробітники;

Стрілка зв'язок по входу між Розстановка і Складання звіту (привласнення id);

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

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

На малюнку 3 представлена ​​діаграма, що показує роботу Оформлення поставок більш докладно.

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

Стрілка входу - комп'ютери та комплектуючі;

Стрілками управління є правила, накази та керівник. Стрілки розгалужується;

Стрілки механізму, розгалужується - ПК, співробітники;

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

1) Присвоєння номера - привласнення індивідуального номера комп'ютерів та комплектуючих.

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

Стрілки управління - правила, накази і керівник;

Стрілки механізму - ПК та Співробітники;

Стрілка зв'язок по входу між роботами Присвоєння номера і Відправка товару на склад (переміщення), між «Присвоєння номера» і «Постановка на баланс» (внесення в базу);

2) Відправлення товару на склад - оправлення товару з присвоєним номером на склад.

Стрілка виходу - комп'ютер;

Стрілки управління - правила, накази та керівник.

Стрілка зв'язок по входу між роботами «Відправлення товару на склад» і «Постановка на баланс» (кількість);

3) Постановка на баланс - занесення інформації в комп'ютер.

Стрілки управління - правила, накази і керівник;

Стрілки механізму - ПК та Співробітники;

На малюнку 4 представлена ​​діаграма, що деталізує обслуговування комп'ютера більш докладно.

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

У роботу Обслуговування комп'ютера входить 4 граничні стрілки (вхід, вихід, управління, механізм). Внутрішні стрілки (зворотний зв'язок по входу, зв'язок по входу).

1) зі складання комп'ютерів - конфігурація комп'ютерів за індивідуальним замовленням керівників.

Стрілка входу - комп'ютери;

Стрілки управління - правила, накази і керівник;

Стрілки механізму - Співробітники;

Стрілка зв'язок по входу між роботами: «Збірка комп'ютерів» і «Ремонт комп'ютерів» (комп'ютер);

2) Ремонт комп'ютерів - збірка затверджених до поліпшення комп'ютерів.

Стрілка входу - комп'ютери;

Стрілка виходу - занесення в базу;

Стрілки управління - правила, накази і керівник;

Стрілки механізму - Співробітники;

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

Стрілка зв'язок по входу між роботами: «Ремонт комп'ютерів» і «Upgrade» (комплектуючі);

3) Upgrade - удосконалення, поліпшення, оновлення комп'ютера.

Стрілка виходу - занесення в базу;

Стрілки управління - правила, накази і керівник;

Стрілки механізму - Співробітники;

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

На малюнку 5 представлена ​​діаграма «Складання звіту» більш докладно. У декомпозицію роботи Складання звіту входить 4 граничних стрілки (вхід, вихід, управління, механізми). Внутрішні стрілки (зворотний зв'язок по входу, зв'язок по входу).

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

1) Збір даних - збір інформації для аналізу і прийняття рішень.

Стрілка входу - привласнення id;

Стрілки управління - правила, накази і керівник;

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

Стрілка зв'язок по входу між роботами: Збір даних і Перевірка даних (записи);

2) Перевірка даних - перевірка інформації і відправка її на складання звіту.

Стрілка входу - привласнення id, занесення даних в базу;

Стрілка виходу - Звіт;

Стрілки управління - правила, накази і керівник;

Стрілки механізму - Співробітники, ПК;

Стрілки входу (привласнення id), управління, механізму є розгалужуються;

Стрілкою зворотного зв'язку по входу з «Перевірки даних» на «Збір даних» (повторна перевірка).

Опис DFD діаграми

У декомпозиції роботи «Обслуговування комп'ютера» Малюнок 1 визначено чотири внутрішні роботи, дві зовнішні сутності і два сховища даних.

Малюнок 1 - Обслуговування комп'ютера

1) Складання комп'ютера - процес складання комп'ютера з існуючих комплектуючих.

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

3) Діагностика - перевірка на працездатність

4) Upgrade - удосконалення, поліпшення, оновлення комп'ютера.

Зовнішні сутності: комп'ютери та комплектуючі

Сховища даних:

1) Склад - місце, де зберігаються зібрані і модернізовані комп'ютери.

2) БД - база даних, в якій зберігаються всі звіти і вся інформація про виконані роботи.

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

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

У декомпозиції роботи «Складання звіту» Малюнок 2 визначено три внутрішні роботи, три зовнішні сутності і два сховища даних.

1) Збір даних - збір відомостей про комп'ютери та комплектуючих.

2) Перевірка - перевірка даних на точність.

3) Звіт - написання звіту про виконану роботу.

Зовнішні сутності: комплектуючі, комп'ютери, керівник.

Сховище даних - Дані про комп'ютери та комплектуючих, дані звіту.

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

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

Опис IDEF3 діаграми

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

1) Ремонт - збірка комп'ютера збірними комплектуючими

2) Збірка - приведення комп'ютера в нормальний вигляд

3) Upgrade - модернізація комп'ютера

4) Комп'ютери - товар після складання і модернізації

5) Надіслати на склад - відправити на зберігання після поліпшення (збірки)

6) Діагностика - перевірка на працездатність.

7) Звіт - інформація про виконану роботу.

Перехрестя - з'єднувачі:

1) J2 - всі дії починаються одночасно.

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

3) J7 - показано, що ці умови одночасно виконуватися не можуть.

4) J9 - ці дії закінчуються одночасно після чого складається звіт по виконаній роботі.

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

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

Щоб увійти в DEMOпроект використовуйте Ім'я користувача — MANAGER, пароль - MANAGER

Як створити свій проект детально зображається в цьому відео

Після створення нового проекту ви також зможете використовувати для входу Ім'я користувача — MANAGER і пароль - MANAGER

створення моделі

Для того, щоб створити модель IDEF0 включите панель проектуі перейдіть в розділ моделювання Essential Domain

Примітка : Аналогічно можна створювати моделі і в розділі моделювання Implementation Domain, а також в будь-якому розділі, налаштованому користувачем. Розділ моделювання - це фактично простір імен, в рамках якого можна повторно використовувати потоки.

Щоб створити контекстну модель IDEF0 клацніть правою кнопкою миші по розділу IDEF0 і виберіть пункти меню Новий-> Елемент

Зверніть увагу, що це найменування всієї моделі в цілому, а не функціонального блоку на A0.

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

Створення функціонального блоку

Для цього виберіть символ функціонального блоку на палітрі

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

З'явиться діалогове вікно, в якому необхідно ввести найменування функціонального блоку, після чого натиснути ОК.

В результаті буде створений функціональний блок з заданим вами іменем

Ви можете виділити кордон блоку і змінити його масштаб

створення потоків

Щоб створити потоки, виберіть на палітрі символ потоку (без тунелювання або з туннелированием)

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

після цього з'явиться діалогове вікно для введення назви потоку. Введіть коротка назвапотоку і натисніть OK

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

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

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

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

декомпозиція моделі

в діалозі залиште налаштування за замовчуванням і натисніть OK

Після чого буде створена дочірня діаграма A1 і на неї перенесені всі потоки з діаграми A0.

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

Щоб перейменувати заготовку функціонального блоку, виділіть її та в контекстному меню виберіть Перейменувати

і введіть найменування

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

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

В результаті ви отримаєте потік з двома вигинами

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

Подивіться відеофрагмент для того, щоб побачити це в динаміці

Щоб видалити (або додати) точку вигину, натисніть клавішу SHIFT на клавіатурі і клацніть в точку, яку необхідно видалити або в те місце потоку, де її треба створити

Збережіть діаграму і переконайтеся в тому, що створені відповідні специфікації

За аналогією можна провести декомпозицію функціональних блоків A1.