Методология sadt нотация idef0 примери. Диаграма IDEF0: примери и правила за конструиране

Знаеше ли, Какво е мисловен експеримент, gedanken експеримент?
Това е несъществуваща практика, неземно преживяване, въображение за нещо, което всъщност не съществува. Мисловните експерименти са като будни сънища. Те раждат чудовища. За разлика от физическия експеримент, който е експериментална проверка на хипотези, „мисловният експеримент“ магически замества експерименталното тестване с желани заключения, които не са били тествани на практика, манипулирайки логически конструкции, които всъщност нарушават самата логика, като използват недоказани предпоставки като доказани, че е, чрез заместване. По този начин основната задача на кандидатите за „мисловни експерименти“ е да заблудят слушателя или читателя, като заменят истински физически експеримент с неговата „кукла“ - фиктивни разсъждения на условно освобождаване без самата физическа проверка.
Изпълването на физиката с въображаеми, „мисловни експерименти“ доведе до появата на абсурдна, сюрреалистична, объркана картина на света. Истинският изследовател трябва да разграничи такива „опаковки от бонбони“ от реалните ценности.

Релативистите и позитивистите твърдят, че „мисловните експерименти“ са много полезен инструмент за тестване на теории (също възникващи в съзнанието ни) за последователност. С това те заблуждават хората, тъй като всяка проверка може да се извърши само от източник, независим от обекта на проверка. Самият заявител на хипотезата не може да бъде тест за собственото си твърдение, тъй като причината за самото това твърдение е липсата на противоречия в твърдението, видимо за заявителя.

Виждаме това в примера на SRT и GTR, които се превърнаха в своеобразна религия, която контролира науката и общественото мнение. Никакви факти, които им противоречат, не могат да преодолеят формулата на Айнщайн: „Ако един факт не съответства на теорията, променете факта“ (В друга версия „Фактът не отговаря ли на теорията? - толкова по-лошо за факта, “).

Максимумът, за който може да претендира един „мисловен експеримент“, е само вътрешната последователност на хипотезата в рамките на собствената, често по никакъв начин невярна, логика на кандидата. Това не проверява съответствието с практиката. Истинската проверка може да се извърши само в действителен физически експеримент.

Експериментът си е експеримент, защото не е усъвършенстване на мисълта, а проверка на мисълта. Мисъл, която е самосъгласувана, не може да провери сама себе си. Това е доказано от Курт Гьодел.

Отворете проекта, в който искате да създадете модела. Ако все още не сте създали проект, можете да използвате проекта DEMO, който е достъпен веднага след инсталирането на Cradle, или да създадете свой собствен проект.

За да влезете в ДЕМОНСТРАЦИЯизползване на проекта Потребителско име — УПРАВИТЕЛ, парола - МЕНИДЖЪР

Как да създадете свой собствен проект е показано подробно в това видео.

След като създадете нов проект, вие също ще можете да използвате Потребителско име — УПРАВИТЕЛ и парола - МЕНИДЖЪР

Създаване на модел

За да създадете IDEF0 модел, активирайте Панел за проектии отидете в раздела за моделиране Основен домейн

Забележка : По подобен начин можете да създавате модели в раздела за моделиране на домейна на изпълнение, както и във всеки конфигуриран от потребителя раздел. Разделът за моделиране всъщност е пространство от имена, в което нишките могат да се използват повторно.

За да създадете контекстен модел IDEF0, щракнете с десния бутон върху секцията IDEF0 и изберете елементите от менюто Нов->Елемент

Моля, имайте предвид, че това е името на целия модел, а не на функционалния блок на A0.

След това ще се отвори областта за рисуване и можете да започнете да създавате контекстния модел.

Създаване на функционален блок

За да направите това, изберете символа на функционалния блок в палитрата

и щракнете веднъж върху работното пространство, където искате да създадете функционалния блок.

Ще се появи диалогов прозорец, в който трябва да въведете името на функционалния блок и след това да щракнете върху OK.

В резултат на това ще бъде създаден функционален блок с името, което сте посочили

Можете да изберете границата на блок и да промените неговия мащаб

Създаване на нишки

За да създадете нишки, изберете символа на нишка в палитрата (без тунелиране или с тунелиране)

след това щракнете върху страната на функционалния блок, където искате да създадете нишка, и щракнете върху която и да е област на функционалния блок

След това ще се появи диалогов прозорец за въвеждане на името на потока. Въведете кратко име за потока и щракнете върху OK

Забележка: Ще можете да влезете Подробно описаниепоток след това в неговата спецификация.

След това, по аналогия, можете да създадете всички необходими нишки

Запазете модела, като натиснете бутона за дискета или клавишната комбинация CTRL+S. Запазването ще създаде спецификации на символи, които можете да редактирате, за да предоставите по-подробни описания на елементите на модела.

След като запазите модела, ще можете да видите създадените спецификации в панела на проекта в същия раздел, където сте създали модела. Ще бъдат създадени два типа спецификации – Function и Flow.

Декомпозиция на модела

в диалоговия прозорец, който се появява, оставете настройките по подразбиране и щракнете върху OK

След това ще бъде създадена дъщерна диаграма A1 и всички потоци от диаграма A0 ще бъдат прехвърлени към нея.

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

За да преименувате предварително зададен функционален блок, изберете го и изберете Преименуване от контекстното меню

и въведете желаното име

По аналогия създайте други функционални блокове, съответстващи на това ниво на разлагане

За да създадете потоци между тези функционални блокове, трябва първо да щракнете върху източника, след това върху междинната точка, за да създадете огъване и след това върху мивката, например така:

Резултатът е поток с две завои

Можете да регулирате позицията на завоите, като изберете потока и плъзнете точките за огъване до желаното място

Гледайте видеоклипа, за да го видите в действие

За да премахнете (или добавите) точка на огъване, натиснете клавиша SHIFT на клавиатурата и щракнете върху точката, която искате да изтриете, или върху точката в потока, където искате да я създадете

Запазете диаграмата и се уверете, че са създадени подходящите спецификации

По аналогия можем да разложим функционалните блокове A1.

Научете се да виждате и разбирате функционалната структура на вашия бизнес!

В момента в Русия се наблюдава рязко нарастване на интереса към стандартите за управление, общоприети на Запад, но в реалната управленска практика има един много важен момент. Много мениджъри все още могат да бъдат объркани от директен въпрос за организационна структуракомпания или за схемата на съществуващите бизнес процеси. Най-напредналите мениджъри, които редовно четат икономическа периодика, като правило започват да чертаят йерархични диаграми, които само те могат да разберат, но в този процес обикновено бързо стигат до задънена улица. Същото важи и за служители и ръководители на различни служби и функционални отдели. В повечето случаи единственият набор от посочени правила, съгласно които едно предприятие трябва да работи, е набор от индивидуални разпоредби и длъжностни характеристики. Най-често тези документи са съставени преди повече от една година, са зле структурирани и несвързани помежду си и в резултат на това просто събират прах по рафтовете. Засега такъв подход беше оправдан, тъй като по време на формирането на руския пазарна икономикаконцепцията за конкуренция практически липсваше и нямаше особена нужда да се изчисляват разходите - печалбите бяха гигантски. В резултат на това през последните две години наблюдаваме напълно разбираема картина: големи компании, които се разраснаха в началото на 90-те години, постепенно губят позициите си, докато напълно напуснат пазара. Това отчасти се дължи на факта, че в предприятието не са въведени стандарти за управление; концепцията за функционален модел на дейност и мисия напълно отсъства. Чрез моделиране на различни области на дейност можете доста ефективно да анализирате тесните места в управлението и да оптимизирате цялостната бизнес схема. Но, както знаете, във всяко предприятие само онези проекти, които директно носят печалба, имат най-висок приоритет, така че въпросът за проверка на дейностите и реорганизирането им обикновено възниква само по време на значителна криза в управлението на компанията.

В края на 90-те години, когато пазарът стана по-конкурентен и рентабилността на предприятията започна да пада рязко, мениджърите изпитаха огромни трудности в опитите си да оптимизират разходите, така че продуктите да останат едновременно печеливши и конкурентни. Точно в този момент стана абсолютно ясна необходимостта да имате пред очите си модел на дейността на предприятието, който да отразява всички механизми и принципи на взаимовръзка на различни подсистеми в рамките на един бизнес.

Самото понятие „моделиране на бизнес процеси“ навлезе в ежедневието на повечето анализатори едновременно с появата на пазара на сложни софтуерни продукти, предназначен за комплексна автоматизацияуправление на предприятието. Такива системи винаги предполагат задълбочено предпроектно проучване на дейността на компанията. Резултатът от тази проверка е експертно становище, в което по отделни точки се правят препоръки за премахване на „тесните места“ в управлението на дейността. Въз основа на това заключение непосредствено преди проекта за внедряване на система за автоматизация се извършва така наречената реорганизация на бизнес процесите, понякога доста сериозна и болезнена за компанията. Това е естествено; винаги е трудно да принудиш екип, формиран през годините, да „мисли по нов начин“. Такива изчерпателни проучвания на предприятията винаги са сложни и варират значително в зависимост от случая. За решаване на такива проблеми при моделиране на сложни системи има добре изпитани методологии и стандарти. Тези стандарти включват семейството от методологии IDEF. С тяхна помощ можете ефективно да показвате и анализирате модели на активност на широк набор от сложни системи в различни контексти. В същото време широчината и дълбочината на изследването на процесите в системата се определят от самия разработчик, което позволява да не се претоварва създадения модел с ненужни данни. В момента фамилията IDEF включва следните стандарти:

IDEF0 - методология за функционално моделиране. Използвайки визуалния графичен език IDEF0, изследваната система се представя на разработчиците и анализаторите под формата на набор от взаимосвързани функции (функционални блокове - в термините на IDEF0). По правило IDEF0 моделирането е първата стъпка в изучаването на всяка система;

IDEF1 е методология за моделиране на информационни потоци в рамките на една система, която ви позволява да показвате и анализирате тяхната структура и взаимоотношения;

IDEF1X (IDEF1 Extended) – методология за изграждане на релационни структури. IDEF1X принадлежи към типа методология Entity-Relationship (ER) и обикновено се използва за моделиране на релационни бази данни, подходящи за въпросната система;

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. От 1981 г. стандартът IDEF0 претърпя няколко незначителни промени, предимно от ограничителен характер, и последното му издание беше издадено през декември 1993 г. от Националния институт за стандарти и технологии на САЩ (NIST).

Основни елементи и концепции на IDEF0

Графичният език IDEF0 е изненадващо прост и хармоничен. Методологията се основава на четири основни концепции.

Първата от тях е концепцията за функционален блок (Activity Box). Функционалният блок е изобразен графично като правоъгълник (виж фиг. 1) и представлява специфична функция в рамките на разглежданата система. Съгласно изискванията на стандарта името на всеки функционален блок трябва да бъде формулирано в устно настроение (например „произвежда услуги“, а не „произвежда услуги“).

Всяка от четирите страни на функционалния блок има свое специфично значение (роля) и:

Горната страна е настроена на „Контрол“;

Лявата страна е настроена на „Вход“;

Дясната страна е настроена на „Изход“;

Долната страна има значението „Механизъм“.

Всеки функционален блок в рамките на една разглеждана система трябва да има свой собствен уникален идентификационен номер.

Фигура 1. Функционален блок.

Вторият стълб на методологията IDEF0 е концепцията за интерфейсна дъга (стрелка). Интерфейсните дъги също често се наричат потоци или стрелки. Интерфейсна дъга представлява системен елемент, който се обработва от функционален блок или по друг начин засяга функцията, представена от този функционален блок.

Графичното представяне на интерфейсна дъга е еднопосочна стрелка. Всяка интерфейсна дъга трябва да има свое собствено уникално име (Arrow Label). Според изискванията на стандарта, името трябва да е форма на съществително.

С помощта на интерфейсни дъги се показват различни обекти, които в една или друга степен определят процесите, протичащи в системата. Такива обекти могат да бъдат елементи от реалния свят (части, коли, служители и т.н.) или потоци от данни и информация (документи, данни, инструкции и т.н.).

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

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

Когато конструирате IDEF0 диаграми, е важно правилно да разделите входящите интерфейсни дъги от контролните дъги, което често е трудно. Например Фигура 2 показва функционалния блок „Обработка на детайла“.

IN реален процесна работника, извършващ обработката, се дава заготовката и технологични инструкции за обработка (или правила за безопасност при работа с машината). Може погрешно да изглежда, че както детайлът, така и документът с технологични инструкции са входящи обекти, но това не е така. Всъщност при този процес детайлът се обработва съгласно правилата, отразени в технологичните инструкции, които съответно трябва да бъдат представени от дъгата на контролния интерфейс.

Фигура 2.

Друг е въпросът, когато технологичните инструкции се обработват от главния технолог и се правят промени в тях (фиг. 3). В този случай те се показват от вече входяща интерфейсна дъга, а контролният обект е например новите индустриални стандарти, въз основа на които се правят тези промени.

Фигура 3.

Горните примери подчертават външно сходния характер на дъгите на входящия и контролния интерфейс, но за системи от същия клас винаги има определени разлики. Например, когато разглеждаме предприятия и организации, има пет основни типа обекти: материални потоци(части, стоки, суровини и др.), финансови потоци (парични и безкасови, инвестиции и др.), документни потоци (търговски, финансови и организационни документи), информационни потоци (информация, данни за намерения, устни нареждания и др.). .) и ресурси (служители, машини, машини и др.). Освен това, в различни случаи, всички видове обекти могат да бъдат показани чрез входящи и изходящи интерфейсни дъги, като се управляват само тези, свързани с потока от документи и информация, и само ресурси чрез дъгови механизми.

Задължителното присъствие на контролни интерфейсни дъги е една от основните разлики между стандарта IDEF0 и другите методологии на класовете DFD (Диаграма на потока от данни) и WFD (Диаграма на работния поток).

Третата основна концепция на стандарта IDEF0 е разлагането. Принципът на декомпозицията се използва при разделянето на сложен процес на съставните му функции. В този случай нивото на детайлност на процеса се определя директно от разработчика на модела.

Декомпозицията ви позволява постепенно и структурирано да представите системния модел под формата на йерархична структура от отделни диаграми, което го прави по-малко претоварен и по-лесен за смилане.

Моделът IDEF0 винаги започва с поглед върху системата като едно цяло - една функционална единица с интерфейсни дъги, простиращи се извън разглеждания домейн. Такава диаграма с един функционален блок се нарича контекстна диаграма и се обозначава с идентификатора "A-0".

Обяснителният текст на контекстната диаграма трябва да посочва целта на построяването на диаграмата във формуляра Кратко описаниеи гледната точка е фиксирана.

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

Гледната точка определя основната посока на развитие на модела и необходимото ниво на детайлност. Ясното фиксиране на гледната точка ви позволява да разтоварите модела, като откажете да детайлизирате и изучавате отделни елементи, които не са необходими, въз основа на избраната гледна точка на системата. Например функционални модели на едно и също предприятие от гледна точка на главния технолог и финансов директорще се различават значително в посоката на тяхното детайлизиране. Това се дължи на факта, че в крайна сметка финансовият директор не се интересува от аспектите на обработката на суровините на производствените машини, а главният технолог няма нужда от начертани диаграми финансови потоци. Правилен изборгледна точка значително намалява времето, изразходвано за изграждане на крайния модел.

По време на процеса на декомпозиция функционален блок, който представя системата като цяло в контекстна диаграма, е детайлизиран в друга диаграма. Получената диаграма от второ ниво съдържа функционални блокове, показващи основните подфункции на функционалния блок на контекстната диаграма и се нарича Child диаграма във връзка с нея (всеки от функционалните блокове, принадлежащи на дъщерната диаграма, съответно се нарича Child Box). На свой ред функционалният блок на предшественика се нарича родителски блок по отношение на дъщерната диаграма (Parent Box), а диаграмата, към която принадлежи, се нарича родителска диаграма (Parent Diagram). Всяка от подфункциите на дъщерна диаграма може да бъде допълнително детайлизирана чрез подобно разлагане на съответния й функционален блок. Важно е да се отбележи, че във всеки случай на разлагане на функционален блок, всички интерфейсни дъги, влизащи или излизащи от този блок, са фиксирани върху дъщерната диаграма. Това постига структурната цялост на модела IDEF0. Принципът на декомпозиция е ясно представен на фигура 4. Трябва да обърнете внимание на връзката между номерирането на функционалните блокове и диаграмите - всеки блок има свой уникален сериен номер на диаграмата (номерът в долния десен ъгъл на правоъгълника) , а обозначението в десния ъгъл показва номера на дъщерната диаграма за този блок. Липсата на това обозначение показва, че няма разлагане за този блок.

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

Последната от концепциите на IDEF0 е речникът. За всеки от IDEF0 елементите: диаграми, функционални блокове, интерфейсни дъги съществуващ стандартвключва създаване и поддържане на набор от подходящи дефиниции, ключови думи, наративни изявления и т.н., които характеризират обекта, показан от този елемент. Този набор се нарича речник и представлява описание на същността на даден елемент. Например за дъгата на контролния интерфейс „платежно нареждане“ речникът може да съдържа списък с полета на документа, съответстващ на дъгата, необходимия набор от визи и др. Речникът хармонично допълва визуалния графичен език, като предоставя на диаграмите необходимата допълнителна информация.

Фигура 4. Декомпозиция на функционални блокове.

Принципи за ограничаване на сложността на IDEF0 диаграми

Обикновено IDEF0 моделите съдържат сложна и концентрирана информация и за да се ограничи претоварването им и да ги направят четими, съответните ограничения на сложността са приети в съответния стандарт:

Ограничете броя на функционалните блокове на диаграмата до три до шест. Горната граница (шест) принуждава дизайнера да използва йерархии, когато описва сложни обекти, а долната граница (три) гарантира, че съответната диаграма има достатъчно детайли, за да оправдае създаването си;

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

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

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

Създаване на модел от група специалисти, свързани с различни областидейности на предприятието. Тази група се нарича Автори в термините на IDEF0. Изграждането на първоначалния модел е динамичен процес, по време на който авторите интервюират компетентни лица за структурата на различни процеси. Въз основа на съществуващи разпоредби, документи и резултати от проучването се създава модел на проект на модела.

Разпространение на проекта за преглед, одобрение и коментар. На този етап черновата на модела се обсъжда с широк кръг от компетентни лица (по отношение на читателите на IDEF0) в предприятието. В този случай всяка от диаграмите на проектомодела се критикува и коментира писмено, след което се предава на автора. Авторът от своя страна също се съгласява писмено с критиката или я отхвърля, като очертава логиката на решението и връща преработения проект за доразглеждане. Този цикъл продължава, докато автори и читатели не постигнат консенсус.

Официално одобрение на модела. Утвърденият модел се утвърждава от управителя работна групав случай, че авторите на модела и читателите нямат разногласия относно неговата адекватност. Крайният модел е съгласуван изглед на предприятието (системата) от дадена гледна точка и за дадена цел.
Яснотата на графичния език IDEF0 прави модела напълно четим дори за хора, които не са участвали в проекта по създаването му, както и ефективен за показвания и презентации. В бъдеще на базата на изградения модел могат да се организират нови проекти, насочени към извършване на промени в предприятието (в системата).

Характеристики на националната практика за използване на функционално моделиране с помощта на IDEF0

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

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

Не е тайна, че почти всички проекти за проучване и анализ на финансови и стопанска дейностСега предприятията в Русия по един или друг начин са свързани със строителството автоматизирани системиуправление. Благодарение на това стандартите IDEF, според разбирането на мнозинството, станаха условно неделими от прилагането информационни технологии, въпреки че с тяхна помощ понякога можете ефективно да разрешите дори малки местни проблеми, буквално с помощта на молив и хартия.

При провеждане комплексни проектипроучвания на предприятия, разработването на модели в стандарта IDEF0 ви позволява ясно и ефективно да показвате целия механизъм на дейността на предприятието в необходимия контекст. Най-важното обаче са възможностите за сътрудничество, които IDEF0 предоставя. В моето практически дейностиИмаше доста случаи, когато изграждането на модела се извършваше с пряката помощ на служители от различни отдели. В същото време консултантът струва достатъчно кратко времеим обясни основните принципи на IDEF0 и ги научи как да използват свързания приложен софтуер. В резултат на това служителите на различни отдели създадоха IDEF диаграми на дейностите на тяхното функционално звено, които трябваше да отговорят на следните въпроси:

Какво получава отделът като вход?

Какви функции и в каква последователност се изпълняват в отдела?

Кой отговаря за изпълнението на всяка функция?

От какво се ръководи изпълнителят при изпълнение на всяка от функциите?

Какъв е резултатът от работата на отдела (резултат)?

След съгласуване на проектните диаграми във всеки конкретен отдел, те се сглобяват от консултанта в проект на модел на предприятието, който свързва всички входни и изходни елементи. На този етап се записват всички несъответствия в отделните диаграми и техните спорни области. След това този модел отново преминава функционални отделиза по-нататъшно съгласуване и извършване на необходимите корекции. В резултат на това за сравнително кратко време и с минимални инвестиции човешки ресурсиот страна на консултантската компания (а тези ресурси, както знаем, са много скъпи), получаваме IDEF0 модел на предприятието, базиран на принципа „както е“, и което е важно, той представя предприятието от позицията на служителите, които работят в него и добре познават всички нюанси, включително неформалните. В бъдеще този модел ще бъде прехвърлен за анализ и обработка на бизнес анализаторите, които ще търсят „тесните места” в управлението на компанията и ще оптимизират основните процеси, трансформирайки модела „Както е” в съответния „Както трябва” Be” представителство. Въз основа на тези промени се издава окончателно заключение, което съдържа препоръки за реорганизация на системата за управление.

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

Изводът от всичко това може да се направи по следния начин: изобщо не е необходимо всеки път сами да измисляте решения на стандартни проблеми. Всеки път, когато сте изправени пред необходимостта да анализирате определена функционална система (от система за проектиране космически кораб, преди процеса на приготвяне на комплексна вечеря) – използвайте проверени и изпитани през годините методи. Един от тези методи е IDEF0, който ви позволява да решавате сложни житейски проблеми с помощта на неговите прости и разбираеми инструменти.

Описание на диаграми на бизнес процеси „Счетоводство за компютърно оборудване на предприятие“

Описание на IDEF0 диаграми

Диаграма IDEF0 беше използвана за изграждане на бизнес процес. Методологията IDEF0 предписва изграждането на йерархична система от диаграми - единични описания на фрагменти от системата. Първо се извършва описание на системата като цяло и нейното взаимодействие с външния свят (контекстна диаграма). Изградени са три нива на диаграмата:

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

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

Фигура 1 - Контекстна диаграма „Счетоводство“ компютърно оборудванепредприятия"

Фигура 1 показва контекстна диаграма на бизнес процеса „Счетоводство за компютърно оборудване на предприятието“. Той отразява системата като цяло и нейното взаимодействие с основните външни информационни потоци.

Контекстната диаграма е обозначена със стрелки.

Видове стрели:

· вход (вложени материали: компютри и компоненти)

· изход (изходът е отчетът)

· стрелките за управление са документи и мениджъри

· стрелките на механизмите са служители и оборудване

Входна информация за обработка:

Компютри - компютри (персонални компютри), разположени в предприятието

Компоненти - материали, необходими за надграждане на компютри (видео карти, дънни платки, процесори, кутии, захранвания, модули памет)

Изходни потоци:

Доклад - готов отчет за осчетоводяване на компютърна техника на предприятие

Контроли за въвеждане:

Правилата са условия, които трябва да бъдат изпълнени, за да се постигне целта.

Поръчки - задачата, възложена на предприятието (да извършва счетоводство на компютърно оборудване в предприятието с помощта на определени информационни системи)

Мениджърите са директори и главни мениджъри на предприятието.

Входящи ресурси:

Компютрите са компютри, използвани за водене на записи.

Служителите са специалисти, които изпълняват инструкции, възложени от ръководството. След изграждането на концептуалния модел беше извършена функционална декомпозиция - системата беше разделена на подсистеми и всяка подсистема беше описана отделно (декомпозиционни диаграми).

Фигура 2 показва функционално разлагане, състоящо се от четири работни места.

Фигура 2 - Функционална декомпозиция „Счетоводство за компютърно оборудване на предприятие“

Бяха идентифицирани следните видове работа:

1) Регистрация на доставки - процес, при който се присвоява идентификатор на продукт, изпратен за съхранение, в склад и се въвежда информация за продукта в програмата.

Работата по Регистрация на доставките включва седем гранични стрелки (вход, управление, механизъм) и вътрешна стрелка (входна връзка) изходи.

Стрелкова връзка на входа между работите Регистрация на доставки и Компютърна поддръжка (компютър);

Стрелките за влизане, излизане, управление се повтарят в следващите работи.

2) Компютърната поддръжка е процес, при който се извършва сглобяването, ремонтът и надграждането на компютри.

Работата по поддръжката на компютъра включва четири гранични стрелки (вход, управление, механизъм, изход) и няколко вътрешни стрелки (входна комуникация, входна обратна връзка).

Управление на стрелките - правила, заповеди, лидер;

Връзка със стрелки чрез въвеждане между работите Компютърна поддръжка и подреждане (въвеждане на данни в базата данни), между работите Компютърна поддръжка и Създаване на отчет (въвеждане на данни в базата данни);

3) Подреждане - процесът, при който компютрите се подреждат в офиси (офиси).

Управление на стрелките - правила, заповеди, лидер;

Стрелков механизъм - служители;

Стрелкова връзка на входа между Подреждане и Отчитане (задаване на id);

4) Изготвянето на отчет е последният етап от счетоводния процес, който се състои в обобщаване на окончателни показатели, получени чрез извършване на предходни текущи счетоводни данни.

След това всяка подсистема се разбива на по-малки декомпозиции и така нататък, докато се постигне желаното ниво на детайлност.

Фигура 3 показва диаграма, показваща по-подробно работата на Delivery Clearance.

В резултат на детайлизирането бяха идентифицирани основните функции. Секцията „Регистриране на доставка“ включва седем основни стрелки (вход, изход, управление, механизъм).

Стрелка за вход - компютри и компоненти;

Стрелките на контрола са правилата, заповедите и лидерът. Разклоняващи се стрели;

Механизъм стрелки, разклонения - PC, служители;

Стрелките за влизане, контролите, механизмите се повтарят във всички произведения.

1) Присвояване на номер - присвояване на индивидуален номер на компютри и компоненти.

Стрелки за влизане - компютри и компоненти. Компютърната стрелка се повтаря в следващите работи, с изключение на подготовката на доклада;

Контролни стрелки - правила, заповеди и лидер;

Механизъм стрелки - PC и Staff;

Стрелкова връзка чрез въвеждане между работите Определяне на номер и Изпращане на стоки в склада (движение), между „Определяне на номер” и „Поставяне на баланс” (въвеждане в базата данни);

2) Изпращане на стоки до склад - изпращане на стоки с присвоен номер до склада.

Стрелка за изход - компютър;

Контролни стрелки - правила, заповеди и лидер.

Връзка със стрелка на входа между заданията „Изпращане на стока на склад” и „Завеждане на баланс” (количество);

3) Балансиране – въвеждане на информация в компютъра.

Контролни стрелки - правила, заповеди и лидер;

Механизъм стрелки - PC и Staff;

Фигура 4 е диаграма, която описва по-подробно поддръжката на компютъра.

В резултат на детайлизирането бяха идентифицирани основните функции, изпълнявани по време на процеса на поддръжка на компютъра.

Работата по поддръжката на компютъра включва 4 гранични стрелки (вход, изход, управление, механизъм). Вътрешни стрелки (входна обратна връзка, входна комуникация).

1) Монтаж на компютри - конфигурация на компютри по индивидуални поръчки на ръководители.

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

Контролни стрелки - правила, заповеди и лидер;

Механизъм стрелки - Служители;

Стрелкова връзка на входа между работите: “Асемблиране на компютри” и “Ремонт на компютри” (компютър);

2) Ремонт на компютри - асемблиране на одобрени за подобрение компютри.

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

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

Контролни стрелки - правила, заповеди и лидер;

Механизъм стрелки - Служители;

Стрелките за влизане, излизане, управление и механизъм се разклоняват;

Стрелкова връзка на входа между работите: „Ремонт на компютри” и „Надстройка” (компоненти);

3) Upgrade - подобряване, подобряване, актуализиране на вашия компютър.

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

Контролни стрелки - правила, заповеди и лидер;

Механизъм стрелки - Служители;

Контролните стрелки и механизмът са разклонени;

Фигура 5 показва по-подробно диаграмата „Писане на отчет“. Декомпозицията на работата Изготвяне на отчет включва 4 гранични стрелки (вход, изход, управление, механизми). Вътрешни стрелки (входна обратна връзка, входна комуникация).

В резултат на работата бяха получени следните функции:

1) Събиране на данни – събиране на информация за анализ и вземане на решения.

Стрелка за влизане - присвояване на идентификатор;

Контролни стрелки - правила, заповеди и лидер;

Стрелките за влизане, управление и механизъм са разклонени;

Връзка със стрелки чрез въвеждане между работи: Събиране на данни и Проверка на данни (записи);

2) Проверка на данните - проверка на информацията и изпращането й за отчет.

Стрелка за вход - задаване на id, въвеждане на данни в базата данни;

Стрелка за изход - Доклад;

Контролни стрелки - правила, заповеди и лидер;

Механизъм стрелки - Служители, PC;

Стрелките за влизане (задаване на идентификатор), управление и механизъм са разклонени;

Стрелка обратна връзкакато влезете от „Проверка на данни“ в „Събиране на данни“ (повторна проверка).

Описание на DFD диаграма

В декомпозицията на работата „Поддръжка на компютъра“ Фигура 1, четири вътрешна работа, две външни единици и две хранилища за данни.

Фигура 1 - Поддръжка на компютъра

1) Сглобяване на компютър - процесът на сглобяване на компютър от съществуващи компоненти.

2) Изготвянето на отчет е процес, който се състои в обобщаване на крайни показатели, получени чрез изпълнение на текущата счетоводна работа.

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

4) Upgrade - подобряване, подобряване, актуализиране на вашия компютър.

Външни обекти: компютри и компоненти

Хранилище за данни:

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

2) БД - база данни, в която се съхраняват всички отчети и цялата информация за извършената работа.

Ние събираме информация за компютъра и избираме компоненти за неговото сглобяване. След това сглобяваме компютъра и го изпращаме в склада за съхранение, но освен това, след като го сглобим, можем първо да го изпратим за диагностика, проверка за функционалност и след това само в склада. След диагностика на сглобения компютър изпращаме данни за съставяне на отчет за свършената работа и въвеждаме информацията в Базата данни.

Имаме и друг външен обект, това е компютър. Изпращаме го за модернизация, а след това за диагностика за проверка на функционалността му, след което съставяме протокол и въвеждаме информация за извършената работа в Базата данни. Или след модернизация изпращаме стоките в склада, след което извършваме диагностика, съставяме протокол и въвеждаме информацията в базата данни.

В декомпозицията на работата „Изготвяне на отчет“ Фигура 2 са дефинирани три вътрешни дейности, три външни обекта и две хранилища на данни.

1) Събиране на данни - събиране на информация за компютри и компоненти.

2) Верификация - проверка на данните за точност.

3) Отчет – писане на отчет за свършената работа.

Външни субекти: компоненти, компютри, мениджър.

Data warehouse - Данни за компютри и компоненти, отчетни данни.

Събиране на информация за компютри и компоненти, след което изпращането им за съхранение. След това проверяваме данните за точност, съставяме отчет и отново го изпращаме за съхранение в първия склад за данни (Фигура 2) или изпращаме данните от отчета до втория склад за данни (Фигура 2) и след това го изпращаме на мениджъра за проверка.

Управителят проверява, прави бележки, корекции и изпраща за повторна проверка. След което отчетът се изпраща за съхранение до повторна проверка от мениджъра.

Описание на IDEF3 диаграми

В декомпозицията на работата по поддръжката на компютъра (фиг. 1) са дефинирани няколко пресечни точки, които свързват едно или повече работни места, няколко вътрешни работни места.

1) Ремонт - сглобяване на компютър с помощта на готови компоненти

2) Сглобяване - привеждане на компютъра в норма

3) Upgrade - надграждане на компютъра

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

5) Изпращане до склад - изпращане за съхранение след подобрение (сглобяване)

6) Диагностика - проверка за функционалност.

7) Отчет - информация за извършената работа.

Кръстовище - съединители:

1) J2 - всички действия започват едновременно.

2) J6 - кръстовище. Възел, който събира много стрелки в една, което показва необходимостта от условието за завършване на работните източници на стрелките, за да продължи процеса.

3) J7 - показва се, че тези условия не могат да бъдат изпълнени едновременно.

4) J9 - тези действия се извършват едновременно, след което се съставя отчет за извършената работа.

Диаграмата IDEF3 показва, че пресечната точка J2 има две разклоняващи се стрелки за работа (монтаж и надстройка), които започват да се изпълняват едновременно. Едва след завършване на тези работи излиза крайния продукт(компютър), свързва кръстовище J6. След което има връзка чрез кръстовище J7, което показва, че две задачи (изпращане на стока до склада и диагностика) не могат да се изпълняват едновременно. След приключване на предишната работа, процесът на съставяне на протокол за извършената работа е в ход, който е свързан с кръстовище J9.

IDEF0 е нотация за графично моделиране, използвана за създаване на функционален модел, който изобразява структурата и функциите на система, както и потоците от информация и материални обекти, които свързват тези функции. Нотацията IDEF0 е една от най-популярните нотации за моделиране на бизнес процеси.

Целта на техниката е да се изгради функционална диаграма на изследваната система, описваща всички необходими процеси с точност, достатъчна за недвусмислено моделиране на дейността на системата.

Методологията се основава на четири основни концепции: функционален блок, интерфейсна дъга, декомпозиция, речник.

Функционален блок(Кутия за дейности) представлява някои специфични функцияв рамките на разглежданата система. Съгласно изискванията на стандарта името на всеки функционален блок трябва да бъде формулирано в устно настроение (например „произвежда услуги“). На схемата функционалният блок е изобразен като правоъгълник (фиг. 3.).

Всяка от четирите страни на функционалния блок има свое специфично значение (роля) и:

Горната страна е настроена на "Контрол";

Лявата страна е настроена на "Вход";

Дясната страна е настроена на Изход;

Долната страна има значението "Механизъм".

Интерфейсна дъга(Стрелка) показва системен елемент, който се обработва от функционален блок или влияе по друг начин функция, представен от този функционален блок. Интерфейсните дъги често се наричат потоци или стрелки.

Ориз. 3. - Функционален блок

В зависимост от това коя страна на функционалния блок пасва тази интерфейсна дъга, тя се нарича „входяща“, „изходяща“ или „контролна“.

Разграждане(Разлагане) е основна концепция на стандарта IDEF0. Принципът на разлагане се използва при разделянето на сложен процес на неговите компоненти функции. В този случай нивото на детайлност на процеса се определя директно от разработчика на модела.

Декомпозицията ви позволява постепенно и структурирано да представите модела на системата под формата на йерархична структура от отделни диаграми, което го прави по-малко претоварен и лесно смилаем (фиг. 4.).

Последната от концепциите на IDEF0 е речникът. За всеки от IDEF0 елементите - диаграми, функционални блокове, интерфейсни дъги - съществуващият стандарт изисква създаването и поддържането на набор от съответстващи дефиниции, ключови думи, наративни изявления и т.н., които характеризират обекта, показан от този елемент. Този набор се нарича речник и представлява описание на същността на даден елемент. Речникът хармонично допълва визуалния графичен език, като предоставя на диаграмите необходимата допълнителна информация.

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

Обяснителният текст за контекстната диаграма трябва да посочва мишена(Цел) да се изгради диаграма под формата на кратко описание и да се запише гледна точка.

Ориз. 4. - Схема на декомпозиция на функционални блокове на модела

Гледната точка определя основната посока на развитие на модела и необходимото ниво на детайлност.

Ясното фиксиране на гледната точка ви позволява да разтоварите модела, като откажете да детайлизирате и изучавате отделни елементи, които не са необходими, въз основа на избраната гледна точка на системата. Правилният избор на гледна точка значително намалява времето за изграждане на крайния модел.

Избор подпроцеси. По време на процеса на декомпозиция функционален блок, който представя системата като цяло в контекстна диаграма, е детайлизиран в друга диаграма. Получената диаграма от второ ниво съдържа функционални блокове, показващи основните подфункции на функционалния блок на контекстната диаграма, и се нарича дъщерна диаграма във връзка с нея (всеки от функционалните блокове, принадлежащи към дъщерната диаграма, съответно се нарича дъщерна кутия) .

На свой ред функционалният блок на предшественика се нарича родителски блок по отношение на дъщерната диаграма (Parent Box), а диаграмата, към която принадлежи, се нарича родителска диаграма (Parent Diagram). Всяка от подфункциите на дъщерна диаграма може да бъде допълнително детайлизирана чрез подобно разлагане на съответния й функционален блок. Във всеки случай на разлагане на функционален блок, всички интерфейсни дъги, влизащи или излизащи от този блок, се фиксират върху дъщерната диаграма. Това постига структурната цялост на модела IDEF0.

Понякога отделните интерфейсни дъги от най-високо ниво няма смисъл да продължават да се разглеждат в диаграми по-ниско ниво, или обратното - отделни дъги от по-ниско ниво трябва да бъдат отразени върху диаграми от по-високи нива - това само ще претовари диаграмите и ще ги направи трудни за разбиране. За разрешаване на такива проблеми стандартът IDEF0 предоставя концепцията за тунелиране. Обозначението „Тунел със стрелка“ на две скоби около началото на интерфейсна дъга показва, че дъгата не е наследена от функционалния родителски блок и се появява (от „тунела“) само на тази диаграма.

На свой ред, същото обозначение около края (стрелка) на дъгата на интерфейса в непосредствена близост до приемния блок означава факта, че тази дъга няма да бъде показана или разгледана в дъщерната диаграма на този блок. Най-често се случва отделни обекти и съответните им интерфейсни дъги да не се разглеждат на някои междинни нива на йерархията - в този случай те първо се „потапят в тунела“ и след това, ако е необходимо, „се връщат от тунела“.

Обикновено IDEF0 моделите съдържат сложна и концентрирана информация и за да се ограничи тяхното претоварване и да ги направи четими, стандартът приема подходящи ограничения за сложност.

На диаграмата се препоръчва да се представят от три до шест функционални блока, докато броят на интерфейсните дъги, подходящи за един функционален блок (излизащ от един функционален блок), се приема не повече от четири.

Обикновено процесът на разработка е итеративен и се състои от следните конвенционални етапи: Създаване на модел от група специалисти, свързани с различни области на предприятието. Тази група се нарича Автори в термините на IDEF0. Изграждането на първоначалния модел е динамичен процес, по време на който авторите интервюират компетентни лица за структурата на различни процеси, създавайки модели на дейности на отдела.

В същото време те се интересуват от отговори на следните въпроси:

Какво получава отделът като вход?

Който функциии в каква последователност се извършват в отдела?

Кой е отговорен за изпълнението на всяка от функции?

От какво се ръководи изпълнителят при изпълнение на всяка от функции?

Какъв е резултатът от работата на отдела (резултат)?

Въз основа на съществуващи разпоредби, документи и резултати от проучването се създава модел на проект на модела.

Разпространение на проекта за преглед, одобрение и коментар. На този етап проектът на модела се обсъжда с широк кръг от компетентни лица (по IDEF0 - читатели) в предприятието. В този случай всяка от диаграмите на проектомодела се критикува и коментира писмено, след което се предава на автора. Авторът от своя страна също се съгласява писмено с критиката или я отхвърля, като очертава логиката на решението и връща преработения проект за доразглеждане. Този цикъл продължава, докато автори и читатели не постигнат консенсус.

Официално одобрение на модела. Съгласуваният модел се одобрява от ръководителя на работната група, ако авторите на модела и читателите нямат разногласия относно неговата адекватност. Крайният модел е съгласуван изглед на предприятието (системата) от дадена гледна точка и за дадена цел.

Яснотата на графичния език IDEF0 прави модела напълно четим дори за хора, които не са участвали в проекта по създаването му, както и ефективен за показвания и презентации. В бъдеще на базата на конструирания модел могат да се организират нови проекти, насочени към промени в модела.

Моделът IDEF0 се препоръчва за използване в предприятие, когато се описват бизнес процеси на най-високо ниво. При изготвянето на функционален модел на бизнес процес (IDEF0), изпълняваните функции и входните и изходните потоци от материали, финансови ресурсии информация (документи, файлове).

Символите на формат IDEF0 са представени в таблици 2 и 3.

Таблица 2. - Графични символи на IDEF0 нотация

Символ	Изображение	Описание
Блокирайте		Блокът описва процеса. Типичен блок е показан на фиг. 1. Във всеки блок се поставя неговото име и номер. Името трябва да е активен глагол, глаголна фраза или отглаголно съществително. Номерът на блока се намира в долния десен ъгъл. Номерата на блоковете се използват за идентификация в диаграмата и свързания текст.
Стрелка		Стрелките представляват обекти (данни), които влизат и излизат от процеса. Всяка страна на функционален блок има стандартно значение от гледна точка на връзката блок-стрелка. На свой ред, страната на блока, към която е прикрепена стрелката, уникално определя неговата роля. Стрелките, влизащи в лявата страна на блока, са входове. Стрелките, влизащи в блока отгоре, са контроли. Стрелките, излизащи от процеса вдясно, са изходи, т.е. данни или материални обекти, произведени от процеса. Стрелките, свързани към долната страна на блока, представляват механизмите.
Тунелирана стрела		Тунелирани стрелки показват, че данните, представени от стрелките, не се вземат предвид в родителската диаграма и/или дъщерната диаграма. Стрелка, поставена в тунела, където се свързва с блок, означава, че данните, изразени от тази стрелка, не са необходими на следващото ниво на разлагане. Стрелка, поставена в тунел в свободния край, означава, че данните, които представлява, не присъстват в родителската диаграма.
Външна справка		Външна препратка - място, обект или субект, който е извън границите на моделираната система. Използва се за указване на източника или дестинацията на стрелките извън модела. В диаграмите външната връзка се изобразява като квадрат, до който е показано името на външната връзка.
Връзка към Interchart		Елемент, представляващ друга диаграма. Служи за указване на прехода на стрелки към диаграма на друг бизнес процес, без да се показва стрелка върху горната диаграма (когато се използват йерархични модели).

Таблица 3. - Графични символи на IDEF0 нотация