IDEF0. Запознаване с нотацията и пример за нейното използване. BPwin (AllFusion Process Modeler) софтуер за компютърно моделиране idef0 софтуер за разработка на модели

Известна днес не само в тесни кръгове, абревиатурата IDEF0 е първата методология за стандартизиране на работата по бизнес процесите. Той е разработен в средата на миналия век като част от аерокосмически проект в Съединените щати и, след като показа своята ефективност, стана федерален стандарт... У нас през 2000 г. беше изготвен документ " Методология за функционално моделиране IDEF0. Ръководен документ Методология за функционално моделиране IDEF0 Ръководство. Официално издание. Държавен стандарт на Русия RD 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 основни опции: КАКВО Е ("както е") или БЪДЕ ("както ще бъде"). Това разделяне е необходимо, тъй като можем да изградим модели както за анализиране на дейностите, така и за тяхното трансформиране. Трябва ясно да осъзнаваме какво правим, както и да предаваме тази информация на другите.

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

Основни потоци

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

1. Материал: материали и компоненти на входа и Завършени продуктина изхода.
2. Клиент: потенциален клиент на входа и доволен на изхода.
3. Финансови: на входа обикновено това са инвестиции, плащания на клиенти (приходи), заеми и други приходи; продукцията е плащания към доставчици, данъци, плащания по заеми и печалби.
4. Информационен: на входа това са всички потоци от информация за външната среда (пазарни условия, поведение на конкурентите, технологични иновациии т.н.), а изходът е потокът от информация, която компанията съобщава за себе си на света (цялата рекламна информация, както и всички видове отчитане до регулаторните органи).

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

(щракнете, за да увеличите)

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

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

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

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

И накрая, механизми - има само 2 вида потоци: оборудване (материал) и изпълнители (отдели и хора). Тук не може да има документи, както не може да има хора на стрелките за управление!

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

Разлагане

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

(щракнете, за да увеличите)

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

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

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

Фигурата по -долу показва диаграмата на разлагане на нашия пример.

(щракнете, за да увеличите)

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

По -нататъшната работа по модела е подобна на първата стъпка - всеки функционален блок от първо ниво се разлага. Номерацията на блока ще съдържа номера на първото ниво: A1.1… A1n, A2.1… A2.n и т.н.

Изводи относно уместността на нотацията

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IDEF4 е методология за изграждане на обектно-ориентирани системи. Инструментите IDEF4 ви позволяват визуално да покажете структурата на обектите и основните принципи на тяхното взаимодействие, като по този начин ви позволяват да анализирате и оптимизирате сложни обектно-ориентирани системи;

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

Историята на стандарта IDEF0

Методологията IDEF0 може да се счита за следващ етап от разработването на добре познатия графичен език за описание на функционални системи SADT (Structured Analysis and Design Teqnique). Преди няколко години в Русия беше публикувано малко издание на едноименната книга, посветено на описанието на основните принципи за изграждане на диаграми SADT. В исторически план IDEF0 като стандарт е разработен през 1981 г. като част от обширна програма за автоматизация индустриални предприятия, носещ обозначението ICAM (Интегрирано компютърно подпомагано производство) и е предложен от ВВС на САЩ. Самата фамилия стандарти на IDEF наследи обозначението си от името на тази програма (IDEF = ICAM DEFinition). В процеса на практическо внедряване участниците в програмата ICAM се сблъскаха с необходимостта от разработване на нови методи за анализ на процесите на взаимодействие в индустриалните системи. В същото време, в допълнение към подобрения набор от функции за описание на бизнес процесите, едно от изискванията за новия стандарт беше наличието на ефективна методология за взаимодействие в рамките на „анализатор-специалист“. С други думи, новият метод трябваше да осигури групова работа по създаването на модела, с прякото участие на всички анализатори и специалисти, участващи в проекта.

В резултат на търсенето на подходящи решения се роди методологията за функционално моделиране IDEF0. От 1981 г. стандартът IDEF0 е претърпял няколко незначителни промени, предимно с ограничаващ характер, а последната му редакция е публикувана през декември 1993 г. от Националния институт за стандарти и технологии на САЩ (NIST).

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

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

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

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

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

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

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

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

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

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

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

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

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

Фигура 2.

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

Фигура 3.

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

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

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

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

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

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

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

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

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

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

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

Фигура 4. Разлагане на функционални блокове.

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

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

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

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

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

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

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

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

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

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

V последните годиниинтересът към методологиите на семейството IDEF нараства непрекъснато в Русия. Непрекъснато наблюдавам това, разглеждайки статистиката на обажданията към моята лична уеб страница (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 показва контекстна диаграма на бизнес процеса "Счетоводство за компютърно оборудване на предприятието". Той показва системата като цяло и нейното взаимодействие с основните външни потоци от информация.

Стрелките са посочени в контекстната диаграма.

Типове стрелки:

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

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

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

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

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

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

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

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

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

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

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

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

Мениджърите са директори и общи мениджъри на предприятието.

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

PC - компютри, с помощта на които се извършва счетоводство.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Връзка със стрелка при въвеждане между Разпространение и Отчитане (присвояване на идентификатор);

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

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

Фигура 3 е диаграма, показваща по -подробно работата на обществените поръчки.

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

Arrow entry - компютри и аксесоари;

Стрелките за управление са правила, заповеди и лидер. Вилични стрели;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3) Надстройка - подобрение, подобрение, надграждане на компютъра.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стрелки на механизма - Служители, компютър;

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

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

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

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

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

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

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

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

4) Надстройка - подобрение, подобрение, надграждане на компютъра.

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

Магазини за данни:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2) Монтаж - връщане на компютъра към нормално състояние

3) Надстройка - надстройка на компютър

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

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

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

7) Доклад - информация за извършената работа.

Пресечни точки - конектори:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Създаване на потоци

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

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

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

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

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

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

След като запазите модела, ще можете да видите създадените спецификации в панела за проекти в същия раздел, където сте създали модела. Ще бъдат генерирани два вида спецификации - Функция и Поток.

Разлагане на модела

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

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

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

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

и въведете необходимото име

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

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

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

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

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

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

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

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