Как да създадете диаграма idef0. Курсова работа: Разработване на корпоративен модел на оранжерия, използвайки методологии за проектиране IDEF0, DFD и IDEF3. Диаграма на разлагане А3

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

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

Графично предимство

Какви са моделите IDEF0? Графични схеми със собствени характеристики и правилата за тяхното изграждане. Защо графики? Защото е ефективен. Това може да се види в няколко примера.

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

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

Предимствата на IDEF0 заТО-специалисти

Дейностите на разработчиците, независимо дали става въпрос например за инсталиране на CRM или създаване на ефективна ERP, са свързани с извършване на промени във вече създадена система. И за да го направите правилно, първо трябва да проучите как работи тази система. След като го проучи, разработчикът пише търговско предложение, в което излага визията си за ситуацията, действията, необходими за решаване на проблема, както и очаквания резултат. Такъв документ може да отнеме повече от дузина страници. От една страна, това е добре, защото клиентът получава максималното количество информация, която го интересува. От друга страна, отнема време за изучаване на дълъг текст. успешен бизнесменчесто не.

И така, как е възможно да се предаде същността, без да се прибягва до обемни текстове? Графика! Тя е тази, която ви позволява да съкратите написаното, ясно демонстрирайки необходимата информация. В края на краищата едно изображение може да замени стотици думи. А във връзка с използването на графики при описване на бизнес процесите това е 100% вярно.

Нека първо разберем какво са нотация и IDEF0 и за какво са.

Нотация за описание на бизнес процесите: какво е това

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

IDEF0 е ...

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

Функционален модел на компанията

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

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

Входящизадават се задачи.

Изходящпоказва резултата от дейността.

Мениджъри(стрелки отгоре надолу) са механизми за управление.

Механизми(стрелки отдолу нагоре) се използват за извършване на необходимата работа.

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

IDEF0 ви позволява да обменяте информация, докато поради своята гъвкавост и видимост, участниците в обмена лесно ще се разберат. IDEF0 е внимателно разработен и подобрен, можете да работите с IDEF0, като използвате различни инструменти, например ERWIN, VISIO, Bussines studio.

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

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

Как се създава функционален модел

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

Главна единицаще бъде така наречен "Написване на статии".

Това, което е необходимо за писане на статия, е отразено в входящи стрелки- „Опит“, „Допълнително четене“.

Стрелки за управлениеза писане на статия - "Очертание на статията", "Изисквания за регистрация", "Правила на руския език".

Механизмите са директно самият автор, копирайтър, редактор, софтуер. Как са организирани тези механизми? Авторът създава текста, като записва аудио версията му. Копирайтърът прехвърля текста в текстов формат, като се фокусира върху плана за публикуване, спазвайки изискванията на издателя и правилата на руския език. След това към работата се свързва редакторът, който проверява статията, коригира речта, правописните и пунктуационните грешки. Софтуерът е програмите и инструментите, които участниците в процеса са използвали за създаването на статията.

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

Да се върнем към нашия модел и да разложим общия блок на няколко свързани елемента.

Така че целият процес на писане на статия може да бъде разделен на 4 етапа:

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

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

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

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

Процес на създаване на нотацияIDEF0

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

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

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

Втората нотация може да се нарече "Както трябва". Той се създава въз основа на първия с промени, направени в съответствие със задачата.

Стандартът IDEF0 и неговите изисквания

Говорихме за основните изисквания на IDEF0 малко по -горе.

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

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

Грешки при работа с IDEF0

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

Използване на множество цветове

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

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

Голям брой блокове

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

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

Промяна на структурата при отстраняване на грешки

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

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

Имена на блокове и контроли

Правилата за именуване на елементите на модела са доста прости, но е изключително важно да ги запомните: контролните стрелки се наричат съществителни, блоковете се наричат глаголи. Това правило е написано в стандарта IDEF0 и помага да се избегне объркване и грешки.

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

Видимост.Изобразявайки работата на компанията под формата на диаграма, става ясно как работи компанията, къде могат да възникнат проблеми и как да ги предотвратим.

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

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

Минимална вероятност за грешка.Работата съгласно стандарта IDEF0 изисква стриктно спазване на неговите правила. Това дисциплинира изпълнителя и елиминира възможността за грешки. Освен това всяко несъответствие със стандарта става веднага забележимо.

И накрая

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

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

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

Понастоящем в Русия интересът към общоприетите стандарти на управление на Запад рязко се е увеличил, но в реалната управленска практика има един много показателен момент. Много лидери все още могат да бъдат объркани от директния въпрос за организационна структуракомпания или относно схемата на съществуващите бизнес процеси. Най -напредналите мениджъри, които редовно четат икономически периодични издания, като правило започват да рисуват йерархични диаграми, които са разбираеми само за тях, но в този процес те обикновено бързо стигат до задънена улица. Същото се отнася и за служители и ръководители на различни услуги и функционални звена. В повечето случаи единственият набор от правила, определени в съответствие с които едно предприятие трябва да оперира, е набор от отделни разпоредби и длъжностни характеристики... Най -често тези документи са съставени преди повече от година, не са добре структурирани и не са свързани помежду си и в резултат просто събират прах по рафтовете. Засега такъв подход беше оправдан, тъй като по време на формирането на руската пазарна икономика концепцията за конкуренция практически липсваше и нямаше особена нужда да се вземат предвид разходите - печалбата беше гигантска. В резултат на това през последните две години видяхме напълно разбираема картина: големите компании, които се разрастваха в началото на 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) и олицетворява някаква специфична функция в рамките на разглежданата система. Съгласно изискванията на стандарта, името на всеки функционален блок трябва да бъде формулирано в глаголното настроение (например „произвежда услуги“, а не „производство услуги“).

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

Горната страна е Control;

Лявата страна е настроена на “Input”;

Дясната страна е настроена на “Output”;

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

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

Фигура 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 е първата методология за стандартизиране на работата по бизнес процесите. Той е разработен в средата на миналия век като част от аерокосмически проект в Съединените щати и след като показа своята ефективност, се е превърнал във федерален стандарт. У нас през 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 процесМодел и бизнес студио. Планирам да отделя отделни статии за прегледа на тези системи.

Функционален блок

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

Задължителни елементи на функционален блок в IDEF0

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

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

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

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

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

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

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

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

Целта е специфична формулировка на целта на модела, която може да се използва за проверка на точността на изграждането на модела в бъдеще.
Гледна точка - на чието лице е изграден моделът, тъй като моделът винаги зависи от своя автор и фокус на внимание. Ако изградим общ модел на предприятие, той обикновено се представя от гледна точка на неговия директор.
Типът модел е индикация за това каква информация се показва на диаграмите. Тук може да има 2 основни опции: КАКВО Е ("както е") или БЪДЕ ("както ще бъде"). Това разделяне е необходимо, тъй като можем да изградим модели както за анализ на дейността, така и за нейната трансформация. Трябва ясно да осъзнаваме какво правим, както и да предаваме тази информация на другите.

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

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

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

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

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

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

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

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

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

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

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

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

Разлагане

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.2. Цел и състав на методологията SADT (IDEF0)

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

Разработването на тази методология е инициирано от Дъглас Рос (САЩ) в средата на 60-те години. XX век Оттогава системните анализатори от SofTech, Inc. подобри SADT и го използва за решаване на широк спектър от проблеми. Софтуер за телефонна мрежа, диагностика, дългосрочно и стратегическо планиране, автоматизирано производствои проектирането, конфигурацията на компютърната система, обучението на персонала, управлението на финансите и обществените поръчки са някои от областите, в които SADT може да се прилага ефективно. Широкият диапазон от области показва универсалността и силата на методологията SADT. В програмата „Интеграция на компютър и индустриални технологииИнтегрираното компютърно производство (ICAM) на Министерството на отбраната на САЩ е признато за полезно от SADT. Това доведе до публикуването на част от него през 1981 г. IDEF0 (Icam DEFinition), като федерален стандартразвивам, разработвам софтуер... Под това име SADT е бил използван от хиляди професионалисти във военни и промишлени организации. Последната редакция на стандарта IDEF0 е публикувана през декември 1993 г. Национален институт по стандарти и технологии (NIST).

Тази методология се конкурира с методите, ориентирани към потока от данни (DFD) при описването на функционалния аспект на информационната система. За разлика от това, IDEF0 позволява:

Опишете всякакви системи, а не само информационни (DFD е предназначен за описване на софтуер);

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

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

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

Моделът (такъв, какъвто е, TO-BE или SHOULD-BE) може да съдържа 4 вида диаграми [ , ]:

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

Диаграми на разлагане;

Диаграми на възелово дърво;

Само за експониране (FEO) диаграми.

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

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

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

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

6.3. Елементи на графичната нотация IDEF0

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

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

Ориз. 6.1. Елементи на графичната нотация IDEF0

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

Взаимодействието на произведения между тях и външния свят е описано под формата на стрелки. IDEF0 отличава 5 вида стрели :

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

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

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

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

- повикване (Английски разговор) - стрелката показва, че част от работата се извършва извън въпросния блок. Стрелките за излизане са изтеглени от долния ръб на произведението.

6.4. Видове връзки между работните места

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

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

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

Ориз. 6.2. Йерархична връзка

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

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


Ориз. 6.5. Директна връзка на входа	Ориз. 6.6. Входна обратна връзка

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

Ориз. 6.7. Потребителска комуникация

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

Ориз. 6.8. Логическа връзка

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

Ориз. 6.9. Методична връзка

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

Ориз. 6.10. Ресурсна връзка

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

Ориз. 6.11. Информационна комуникация

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

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

Ориз. 6.12. Временна връзка

10. Случайна връзка възниква, когато има малка или никаква специфична връзка между функциите.

Ориз. 6.13. Случайна връзка

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

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

IDEF0 има конвенции (правила и насоки) за създаване на диаграми, за да улесни четенето и изследването на модела [,]. Някои от тези правила се обработват автоматично от инструменти CASE, докато други трябва да се прилагат ръчно.

1. Преди изграждането на модел е необходимо да се реши кой (ите) модел (и) на системата ще бъде изграден. Това означава дефиниране на неговия тип AS-IS, TO-BE или SHOULD-BE, както и определяне на позицията, от която е изграден моделът. „Гледната точка“ се мисли най -добре като място (позиция) на човек или обект, в което човек трябва да застане, за да види системата в действие. Например, когато изграждате модел за работа на магазин за хранителни стоки, можете да изберете продавач, касиер, счетоводител или директор сред възможните кандидати от гледна точка на кого се разглежда системата. Обикновено се избира една гледна точка, която най -пълно обхваща всички нюанси на работата на системата, а при необходимост се изграждат FEO диаграми за някои диаграми на разлагане, показващи алтернативна гледна точка.

2. Контекстната диаграма показва един блок, показващ предназначението на системата. Препоръчително е да показва 2–4 стрелки, влизащи и излизащи от всяка страна.

3. Броят на блоковете на диаграмите за разлагане се препоръчва в диапазона 3–6. Ако в диаграмата за разлагане има два блока, това обикновено няма смисъл. С голям брой блокове диаграмата става пренаситена и трудна за четене.

4. Блоковете на диаграмата за разлагане трябва да бъдат подредени отляво надясно и отгоре надолу. Тази подредба ви позволява да отразявате по -ясно логиката и последователността на работата. Освен това маршрутите със стрелки ще бъдат по -малко объркващи и ще имат минимален брой пресичания.

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

Ориз. 6.14. Функция без контрол и вход

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

На фиг. 6.7–6.12, показващи фрагменти от диаграми IDEF0, има блокове без вход и контрол. Това не трябва да се разглежда като грешка, тъй като предполага, че една от тези стрелки трябва да бъде.

6. Всеки блок трябва да има поне един изход.

Ориз. 6.15. Няма функция за излизане

Работите без резултати са безсмислени и не трябва да се моделират. Изключение е работата, показана в модела AS-IS. Тяхното присъствие показва неефективността и несъвършенството на технологичните процеси. В модела TO-BE тези произведения трябва да отсъстват.

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

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

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

Ориз. 6.16. Разклоняващи се стрелки

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

И така, на фиг. 6.16 контроли, включени в блоковете „Производство на части“ и „Сглобяване на продукта“ имат изясняващи значения и са част отПовече ▼ общо управление„Чертежи“. Всички чертежи се използват за работата на блока "Контрол на качеството".

Не е позволено да рисувате стрелки в диаграмата, когато те не са кръстени преди и след разклоняване. На фиг. 6.17 стрелката, включена в блока "Генериране на стандартни списъци", няма име преди и след разклоняване, което е грешка.

Ориз. 6.17. Погрешно наименуване на стрелките

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

Ориз. 6.18. Тунелни стрели

V този примерпри изграждане на модел на провеждане Новогодишно партимеханизмът "две оси" няма да се показва на диаграмите на горните нива, при четене на който може да възникне справедлив въпрос: "Защо имаме нужда от две оси на новогодишното парти?"

По същия начин можете да тунелирате с обратната цел - да не позволявате стрелката да се показва на диаграми от по -ниско ниво. В този случай скобите се поставят в края на стрелката. На контекстната диаграма (виж фиг. 6.21) е тунелиран механизмът "Path Service Engineer", който е включен в блока "Определяне на допустимите скорости". Това решение е взето, тъй като инженерът е пряко ангажиран с цялата работа, показана на диаграмата на разлагане на този блок (виж фиг. 6.22). За да не се покаже тази връзка и да не се затрупа диаграмата на разлагане, стрелката беше тунелирана.

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

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

Ориз. 6.19. Обединяване на връзки

13. Всеки блок в диаграмите трябва да има свой собствен номер. За да се посочи позицията на която и да е диаграма или блок в йерархията, се използват номера на диаграмата. Блокът на диаграмата от най -високо ниво се обозначава с 0, блоковете на диаграмите от второ ниво - с числа от 1 до 9 (1, 2, ..., 9), блоковете на трето ниво - с две числа , първият от които показва номера на подробния блок от родителската диаграма, а вторият номер на блока по ред на текущата диаграма (11, 12, 25, 63) и т.н. Контекстната диаграма има обозначението "A - 0 ", диаграмата за разлагане на първото ниво е" A0 ", диаграмите за разлагане на следващите нива се състоят от буквата" A ", последвана от номера на блока, който трябва да се разложи (например" A11 "," A12 "," A25 "," A63 "). Фигурата показва типично дърво на диаграма (диаграма на възел) с номериране.

Ориз. 6.20. Йерархия на диаграмите

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

6.6. Пример за изграждане на модел IDEF0 за система за определяне на допустими скорости

Изчисляването на допустимите скорости на влака е трудна инженерна задача. Когато влак минава през който и да е участък действителна скоростдвижението на влака не трябва да надвишава максимално допустимото. Тази максимално допустима скорост се определя въз основа на експлоатационен опит и специално проведени тестове върху динамиката на движение и въздействието върху подвижния състав върху коловоза. Непревишаването на тази скорост гарантира безопасността на движението на влаковете, комфортни условия за пътниците и пр. Те се определят в зависимост от вида подвижен състав (марка локомотив и тип вагони), параметри на надстройката (като релси, баласт, траверси) ) и план (радиусни криви, преходни криви, кота на външната релса и др.). Като правило, за да се установят допустимите скорости, е необходимо да се определят най -малко две (по прави линии) и пет (по криви) скорости, от които се избира крайната допустима скорост, като най -ниската от всички изчислени. Изчисляването на тези скорости е регламентирано със Заповед на Министерството на железниците на Русия № 41 от 12 ноември 2001 г. „Стандарти за допустимите скорости на подвижния състав на железопътни релси 1520 (1524) мм на Федералния железопътен транспорт“.

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

Контекстната диаграма за проблема с определянето на допустимите скорости е показана на фигура 6.21. За изграждането на модела е използван продуктът BPwin 4.0 от Computer Associates.

Ориз. 6.21. Контекстна диаграма на системата за определяне на допустимите скорости (методология IDEF0)

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

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

Подробен надлъжен профил (съдържа информация, подобна на тази, обсъдена по -горе);

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

Данни за резултатите от проучването на плана на коловоза от автомобила за измерване на коловоза;

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

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

Контролни данниса:

Инструкции на началника на железопътната служба на пътя или на отдела за релси и конструкции на руските железници за изчислението;

Заповед No 41, съдържаща нормативна и справочна информация, процедура и формули за определяне на допустими скорости;

Информация за текущия или планирания трафик на влаковете (данни за марките на циркулиращите локомотиви и видовете използвани вагони);

Информация за планираните ремонти на коловоза, реконструкция и реорганизация на конструкции и устройства.

Резултатътработата на системата трябва да бъде:

Листове с допустими скорости, съдържащи всички видове изчислени скорости и позволяващи да установите причината за тяхното ограничение;

Бюлетин на заповедта на началника на пътя за установяване на допустими скорости по коловозите и отделните точки (заповед "N") в съответствие с формуляра, приет на пътя. Одобрената заповед „N“ официално определя допустимите скорости на влака;

Стандартни формуляри No 1, 1а и 2, съдържащи планираните допустими скорости за разработване на разписание на влаковете.

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

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

Диаграмата на разлагане на първото ниво за разглеждания проблем е показана на фигура 6.22. Като правило, при изграждането на диаграма за разлагане, оригиналната функция (за декомпозиция) се разделя на 3–8 подфункции (блокове). В този случай се препоръчва блоковете на диаграмата за разлагане да се поставят отляво надясно, отгоре надолу, така че последователността и логиката на взаимодействие на подфункциите да са по -добре видими.

Ориз. 6.22. Диаграма на разлагане на ниво 1 (методология IDEF0)

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

Въвеждане и коригиране на справочна информация и данни за пътни участъци (блокове 1 и 2);

Изготвяне на задание за изчисление (блок 3). Той посочва за кой участък и коловоз, както и марката на локомотива и вида вагони, трябва да се извърши изчислението;

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

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

Формиране и подготовка на проекта на заповед „N“ и стандартни листове (блокове 6 и 7).

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

6.7. ICOM кодове

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

ICOM кодове (съкращение за вход, контрол, изход и механизъм) са за идентифициране на гранични стрелки. ICOM кодът съдържа префикс, съответстващ на типа стрелка (I, C, O или M) и пореден номер (вижте фигурата).

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

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

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

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

2. Функционално разлагане

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Въвеждане със стрелка - компютри и аксесоари;

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

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

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

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.