În diagrama idef0, se folosește un tunel. IDEF0: modelarea funcțională a proceselor de afaceri. Istoricul standardului IDEF0

Metodologia IDEF0

Metodologia IDEF0 prescrie construirea unui sistem ierarhic de diagrame - descrieri unice ale fragmentelor sistemului. În primul rând, se realizează o descriere a sistemului în ansamblu și a interacțiunii sale cu lumea exterioară (diagrama de context), după care se efectuează o descompunere funcțională - sistemul este împărțit în subsisteme și fiecare subsistem este descris separat (diagrame de descompunere) . Apoi fiecare subsistem este împărțit în altele mai mici și așa mai departe până când se atinge nivelul dorit de detaliu.

Fiecare Diagramele IDEF0A conţine blocuri şi arce. Blocurile descriu funcțiile sistemului modelat. Arcurile leagă blocurile între ele și reprezintă interacțiunile și relațiile dintre ele.

Blocurile funcționale (lucrul) din diagrame sunt reprezentate prin dreptunghiuri, reprezentând procese, funcții sau sarcini numite care apar într-o perioadă de timp și au rezultate recunoscute. Numele lucrării trebuie exprimat ca un substantiv verbal care denotă acțiunea.

IDEF0 necesită ca diagrama să aibă cel puțin trei și nu mai mult de șase blocuri. Aceste constrângeri mențin complexitatea diagramelor și a modelului la un nivel care este lizibil, înțeles și utilizabil.

Fiecare parte a blocului are un scop special, foarte specific. Partea stângă a blocului este pentru intrări, partea de sus este pentru control, dreapta este pentru ieșiri, iar partea de jos este pentru mecanisme. Această desemnare reflectă anumite principii de sistem: intrările sunt convertite în ieșiri, limitele de control sau prescriu condițiile pentru efectuarea transformărilor, mecanismele arată ce și cum funcționează o funcție.

Blocurile din IDEF0 sunt plasate în ordinea importanței, așa cum a înțeles autorul diagramei. Această ordine relativă se numește dominanță. Dominanța este înțeleasă ca influența pe care o are un bloc asupra altor blocuri din diagramă. De exemplu, cel mai dominant bloc al diagramei poate fi fie primul dintr-o succesiune de funcții cerute, fie o funcție de planificare sau control care le influențează pe toate celelalte.

Blocul cel mai dominant este de obicei plasat în colțul din stânga sus al diagramei, iar cel mai puțin dominant este în colțul din dreapta.

Dispunerea blocurilor pe pagină reflectă definiția autorului a dominației. Astfel, topologia diagramei arată care caracteristici au un impact mai mare asupra altora. Pentru a sublinia acest lucru, analistul poate renumerota blocurile în funcție de ordinea lor de dominanță. Ordinea dominantei poate fi indicata printr-un numar plasat in coltul din dreapta jos al fiecarui dreptunghi: 1 ar indica cea mai mare dominatie, 2 urmatorul etc.

Interacțiunea lucrărilor cu lumea exterioară și între ele este descrisă sub formă de săgeți, reprezentate ca linii unice cu săgeți la capete. Săgețile reprezintă unele informații și se numesc substantive.

IDEF0 distinge între cinci tipuri de săgeți.

Intrare- obiecte folosite și transformate prin muncă pentru a obține un rezultat (ieșire). Este permis ca lucrarea să nu aibă o singură săgeată de intrare. Săgeata de intrare este desenată ca intrând în marginea stângă a lucrării.

Control-.informaţii care controlează acţiunile lucrării. De obicei, săgețile de control poartă informații care indică ceea ce ar trebui să facă un loc de muncă. Fiecare job trebuie să aibă cel puțin o săgeată de control, care este descrisă ca intrând în marginea superioară a jobului.

Ieșire- obiecte în care sunt convertite intrările. Fiecare job trebuie să aibă cel puțin o săgeată de ieșire, care este desenată ca emanând din marginea dreaptă a jobului.

Mecanism- resursele care execută munca. Săgeata mecanismului este desenată ca intrând în marginea inferioară a lucrării. La discreția analistului, săgețile mecanismului pot să nu fie reprezentate pe model.

Apel- o săgeată specială care indică un alt model de operare. Săgeata de apel este desenată ca venind din partea de jos a lucrării și este folosită pentru a indica faptul că unele lucrări sunt efectuate în afara sistemului care este modelat.

Orez. 2.1 Tipuri de săgeți

Metodologia IDEF0 necesită doar cinci tipuri de interacțiuni între blocuri pentru a descrie relațiile lor: control, intrare, feedback de control, feedback de intrare, mecanism de ieșire. Conexiunile de control și intrare sunt cele mai simple, deoarece reflectă influențe directe intuitive și foarte simple.

Orez. 2.2. Comunicare de ieșire

Orez. 2.3. Comunicarea managementului

O relație de control apare atunci când ieșirea unui bloc afectează direct blocul mai puțin dominant.

Feedback-ul de control și feedback-ul de intrare sunt mai complexe deoarece implică iterație sau recursivitate. Și anume, rezultatele unui job influențează execuția viitoare a altor joburi, care ulterior afectează jobul inițial.

Feedback-ul de control are loc atunci; când ieșirea unui bloc afectează un bloc cu dominanță mai mare.

Relațiile de ieșire-mecanism sunt rare. Ele reflectă o situație în care rezultatul unei funcții devine un mijloc pentru un scop pentru alta.

Orez. 2.4. Feedback de conectare

Orez. 2.5. Feedback de management

Relațiile producție-mecanism sunt caracteristice alocării surselor de resurse (de exemplu, instrumente necesare, personal instruit, spațiu fizic, echipamente, finanțare, materiale).

În IDEF0, un arc rareori reprezintă un singur obiect. De obicei simbolizează un set de obiecte. Deoarece arcurile reprezintă colecții de obiecte, ele pot avea mai multe puncte de plecare (surse) și puncte de sfârșit (destinații). Prin urmare, arcurile se pot ramifica și se pot conecta în diferite moduri. Întregul arc sau o parte a acestuia se poate extinde de la unul sau mai multe blocuri și se poate termina în unul sau mai multe blocuri.

Arcurile de ramificare, reprezentate ca linii radiante, înseamnă că tot sau o parte din conținutul arcelor poate apărea în fiecare ramură. Un arc este întotdeauna etichetat înaintea unei ramuri pentru a da un nume întregului set. În plus, fiecare ramură a unui arc poate fi sau nu etichetată conform următoarelor reguli:

ramurile neetichetate conțin greutatea obiectelor specificate în eticheta arcului înainte de ramură;

ramurile etichetate după punctul de ramificare conțin toate sau o parte din obiectele specificate în eticheta arcului înainte de ramificare.

Îmbinările arcului în IDEFO, reprezentate ca linii care converg împreună, indică faptul că conținutul fiecărei ramuri formează o etichetă pentru arcul care rezultă din îmbinarea arcurilor originale. După o îmbinare, arcul rezultat este întotdeauna marcat pentru a indica noul set de obiecte rezultat în urma îmbinării. În plus, fiecare ramură poate fi sau nu marcată înainte de fuzionare, conform următoarelor reguli:

Orez. 2.6. Conexiune ieșire-mecanism

ramurile neetichetate conțin greutatea obiectelor specificate în eticheta comună a arcului după îmbinare;

ramurile marcate înainte de îmbinare conțin toate sau unele dintre obiectele enumerate în eticheta comună după îmbinare,

numărul de blocuri pe diagramă - N;

nivel de descompunere a diagramei - L;

echilibrul diagramei - ÎN;

numărul de săgeți care se conectează la bloc - A

Acest set de factori se aplică fiecărei diagrame model. Următoarele vor enumera recomandări cu privire la valorile dorite ale factorilor din diagramă.

Este necesar să ne străduim să ne asigurăm că numărul de blocuri de pe diagramele nivelurilor inferioare este mai mic decât numărul de blocuri de pe diagramele părinte, adică, pe măsură ce nivelul de descompunere crește, coeficientul scade. Astfel, scăderea acestui coeficient indică faptul că. că pe măsură ce modelul este descompus, funcțiile ar trebui simplificate, prin urmare, numărul de blocuri ar trebui să scadă.

Diagramele trebuie să fie echilibrate. Aceasta înseamnă că într-o diagramă nu ar trebui să apară situația prezentată în Fig. 2.7: lucrarea 1 are mult mai multe săgeți de intrare și săgeți de control decât cele care ies. Trebuie remarcat faptul că această recomandare poate să nu fie urmată în modelele care descriu procesele de producție. De exemplu, atunci când descrieți o procedură de asamblare, un bloc poate include multe săgeți care descriu componentele unui produs și o săgeată care iese - produsul finit.

Orez. 2.7. Exemplu de grafic dezechilibrat

Să introducem coeficientul de echilibru al diagramei

Este necesar să ne străduim să Q a fost minim pentru diagramă.

Pe lângă analiza elementelor grafice ale diagramei, este necesar să se ia în considerare denumirile blocurilor. Pentru a evalua numele, este compilat un dicționar de funcții elementare (triviale) ale sistemului modelat. De fapt, acest dicționar ar trebui să includă funcțiile nivelului inferior de descompunere a diagramei. De exemplu, pentru un model de bază de date, funcțiile „găsiți o înregistrare” și „adăugați o înregistrare în baza de date” pot fi elementare, în timp ce funcția „înregistrare utilizator” necesită o descriere suplimentară.

După formarea unui dicționar și compilarea unui pachet de diagrame de sistem, este necesar să se ia în considerare nivelul inferior al modelului. Dacă există potriviri între numele blocurilor de diagramă și cuvintele din dicționar, aceasta înseamnă că a fost atins un nivel suficient de descompunere. Coeficientul care reflectă cantitativ acest criteriu poate fi scris ca L*C- produsul nivelului de model și numărul de potriviri ale numelor de bloc cu cuvintele din dicționar. Cu cât nivelul modelului este mai scăzut (L mai mare), cu atât potrivirile sunt mai valoroase.

Când porniți BPWin, bara de instrumente principală, paleta de instrumente și Model Explorer apar în mod implicit.

La crearea unui model nou, apare un dialog în care trebuie să indicați dacă modelul va fi creat din nou sau va fi deschis din depozitul ModelMart, introduceți numele modelului și selectați metodologia în care va fi construit modelul ( Fig. 2.8).

Fig.2.8 Dialog de creare a modelului

BPWin acceptă trei metodologii - IDEF0, IDEF3 și DFD. În BPWin este posibil să se construiască modele mixte, adică modelul poate conține simultan atât diagrame IDEF0, cât și IDEF3 și DFD. Compoziția paletei de instrumente se schimbă automat când treceți de la o notație la alta.

Un model în BPWin este considerat un set de lucrări, fiecare dintre ele funcționând cu un anumit set de date. Dacă faceți clic pe orice obiect model cu butonul stâng al mouse-ului, apare un meniu contextual pop-up, fiecare articol corespunzător editorului unei proprietăți a obiectului.

Construirea unui model de sistem ar trebui să înceapă cu studierea tuturor documentelor care descriu funcționalitatea acestuia. Unul dintre aceste documente este specificația tehnică, și anume secțiunile „Scopul dezvoltării”, „Scopul și obiectivele sistemului” și „Caracteristicile funcționale ale sistemului”.

După studierea documentelor sursă și intervievarea clienților și utilizatorilor sistemului, este necesar să se formuleze scopul modelării și să se determine punctul de vedere asupra modelului. Să luăm în considerare tehnologia construcției sale folosind exemplul sistemului „Serviciul universitar de ocupare a forței de muncă”, ale cărui capacități principale au fost descrise în munca de laborator nr. 1.

Să formulăm scopul modelării: să descriem funcționarea sistemului, care ar fi de înțeles utilizatorului său, fără a intra în detalii legate de implementare. Vom construi modelul din punctul de vedere al utilizatorilor (elev, profesor, administrator, decanat, companie).

Să începem prin a construi o diagramă de context IDEF0. Conform descrierii sistemului, funcția principală este de a-și servi clienții prin procesarea cererilor primite de la aceștia. Astfel, definim singura sarcină a diagramei de context ca „Servește clientul sistemului”. În continuare, definim datele de intrare și de ieșire, precum și mecanismele și controlul.

Pentru a deservi un client, este necesar să îl înregistrați în sistem, să deschideți accesul la baza de date și să procesați cererea acestuia. Datele de intrare vor fi „nume client”, „parolă client”, „bază de date sursă”, „cerere client”. Executarea unei cereri duce fie la primirea de informații din sistem, fie la modificarea conținutului bazei de date (de exemplu, la compilarea evaluărilor experților), astfel încât datele de ieșire vor fi „rapoarte” și „bază de date modificată”. Procesul de procesare a cererii va fi efectuat de monitorul sistemului sub controlul administratorului.

Astfel, definim diagrama de context a sistemului (Fig. 2.9).

Figura 2.9. Diagrama contextului sistemului

Să descompunăm diagrama de context, descriind secvența serviciului clienți:

Determinarea nivelului de acces la sistem.

Selectarea subsistemului.

Acces la subsistem.

Modificarea bazei de date (dacă este necesar).

Obținem diagrama prezentată în fig. 2.10.

După ce ați finalizat descompunerea diagramei de context, treceți la descompunerea diagramei de nivel următor. În mod obișnuit, atunci când se iau în considerare al treilea și cel mai jos nivel, modelele revin la diagramele părinte și le ajustează.

Orez. 2.10. Descompunerea lucrării „Serviciul, clientul de sistem”

Descompunem secvenţial toate blocurile diagramei rezultate. Primul pas în determinarea nivelului de acces la sistem este determinarea categoriei de utilizatori. Numele clientului este căutat în baza de date a utilizatorilor, determinându-se categoria acestuia. După o anumită categorie sunt determinate puterile acordate utilizatorului sistemului. În continuare, se efectuează procedura de accesare a sistemului, verificând numele și parola de acces. Prin combinarea informațiilor despre autorități și nivelul de acces la sistem, se formează un set de acțiuni permise pentru utilizator. Astfel, determinarea nivelului de acces la sistem va arăta ca în fig. 2.11.

Orez. 2.11. Descompunerea lucrării „Determinarea nivelului de acces la sistem”

După finalizarea procedurii de acces la sistem, monitorul analizează cererea clientului, selectând subsistemul care va procesa cererea. Descompunerea lucrării „Apel la un subsistem” nu corespunde scopului și punctului de vedere al modelului. Utilizatorul sistemului nu este interesat de algoritmii interni ai funcționării acestuia. În acest caz, este important pentru el ca alegerea subsistemului să se facă automat, fără intervenția lui, așa că descompunerea accesului la subsistem nu va face decât să complice modelul.

Descompunem lucrarea „Procesarea unei cereri client”, realizată de subsistemul de procesare a cererilor, determinând categoriile și puterile utilizatorilor. Înainte de a căuta un răspuns la o interogare, trebuie să deschideți baza de date (conectați-vă la ea). În general, baza de date poate fi localizată pe un server la distanță, așa că poate fi necesară stabilirea unei conexiuni la acesta. Să determinăm succesiunea lucrărilor:

Deschiderea bazei de date.

Executarea cererii.

Generarea de rapoarte.

După deschiderea bazei de date, trebuie să informați sistemul că a fost stabilită o conexiune la baza de date, apoi să executați cererea și să generați rapoarte pentru utilizator (Fig. 2.12).

Trebuie remarcat faptul că „Execuția interogărilor” include munca diferitelor subsisteme. De exemplu, dacă cererea include testarea, atunci aceasta va fi executată de subsistemul de teste profesionale și psihologice. În etapa de execuție a interogării, poate fi necesară modificarea conținutului bazei de date, de exemplu, la compilarea evaluărilor experților. Prin urmare, este necesar să se prevadă această posibilitate în diagramă.

Orez. 2.12.

Când se analizează diagrama rezultată, se pune întrebarea: ce reguli sunt folosite pentru a genera rapoarte? Este necesar să existe șabloane pregenerate care vor fi folosite pentru a selecta din baza de date, iar aceste șabloane trebuie să corespundă interogărilor și să fie predefinite. În plus, clientului ar trebui să i se ofere posibilitatea de a alege forma raportului.

Să ajustăm diagrama adăugând săgețile „Șabloane de raport” și „Solicitări de modificare a bazei de date” și săgeata tunel „Client de sistem”. Tunnelarea „Clientului de sistem” este utilizată pentru a nu plasa săgeata pe diagrama de sus, deoarece funcția de selectare a formularului de raport nu este suficient de importantă pentru a fi afișată pe diagrama părinte.

Schimbarea diagramei va avea ca rezultat ajustări la toate diagramele părinte (Fig. 2.13 - 2.15).

Este recomandabil să descompuneți lucrarea „Execuție interogări” folosind o diagramă DFD (lucrare de laborator nr. 3), deoarece metodologia IDEF0 consideră sistemul ca un set de lucrări interconectate, care nu reflectă bine procesele de prelucrare a informațiilor.

Orez. 2.13. Descompunerea lucrării „Prelucrarea cererii unui client”

Orez. 2.14. Descompunerea lucrării „Serviciul pentru clienți de sistem” (opțiunea 2)

Orez. 2.15. Diagrama contextului sistemului (opțiunea 2)

Să trecem la descompunerea ultimului bloc „Schimbarea bazei de date”. Din punctul de vedere al clientului, datele sistemului se află într-o singură bază de date. În realitate, există șase baze de date în sistem:

baza de date a utilizatorilor,

baza de date a studentilor, (opțiunea 2)

baza de date a posturilor vacante,

baza de date a performantelor academice,

baza de date de testare,

DB de evaluări de experți,

CV DB.

Conform scopului modelării, este important ca clientul să înțeleagă că datele primite nu sunt actualizate imediat în sistem, ci trec printr-o etapă suplimentară de prelucrare și control. Algoritmul de schimbare poate fi formulat după cum urmează:

Este determinată baza de date în care vor fi modificate informațiile.

Operatorul generează un set de date temporar și îl furnizează administratorului.

Administratorul controlează datele și le introduce în baza de date.

Acest model poate fi implementat într-un alt mod, oferind posibilitatea de a actualiza baza de date direct la solicitări, ocolind procesul de control al datelor. În acest caz, este necesar să se asigure controlul integrității bazei de date pentru a evita deteriorarea acesteia. În acest caz, diagrama va arăta astfel (Fig. 2.17).

Orez. 2.16. Descompunerea lucrării „Schimbarea bazei de date”

Orez. 2.17. Descompunerea lucrării „Modificarea bazei de date” (opțiunea 2) Pentru prima opțiune, prezentată în Fig. 2.12

Descompunerea ulterioară a „Modificărilor bazei de date” va complica modelul, explicând modul în care se realizează modificarea fizică a bazei de date în sistem. În acest caz, utilizatorul nu va primi informații suplimentare despre funcționarea sistemului de servicii de ocupare a forței de muncă. Este recomandabil să descompuneți această lucrare în timpul procesului de proiectare a unui sistem de baze de date în etapa creării unui model logic al bazei de date.

O descompunere a lucrării de execuție a interogărilor va fi efectuată în laboratorul următor, ilustrând utilizarea diagramelor DFD pentru a descrie procesele de procesare a informațiilor.

Să efectuăm o analiză cantitativă a modelelor prezentate în Fig. 2.12 și 2.13, conform metodei descrise mai sus. Să luăm în considerare comportamentul coeficientului ^ pentru aceste modele. Diagrama părinte „Procesarea unei cereri client” are un coeficient de 4/2 = 2, iar diagrama de descompunere are 3/3 = 1. Valoarea coeficientului scade, ceea ce indică o simplificare a descrierii funcțiilor ca nivelul de modelul scade.

Să luăm în considerare modificarea coeficientului LA b au două opțiuni de model.

pentru a doua varianta

Coeficient LA b nu își modifică valoarea, prin urmare, echilibrul diagramei nu se modifică.

Vom presupune că nivelul de descompunere a diagramelor luate în considerare este suficient pentru a reflecta scopul modelării, iar în diagramele de nivel inferior, funcțiile elementare sunt folosite ca nume de lucrări (din punctul de vedere al utilizatorului de sistem) .

Rezumând exemplul luat în considerare, este necesar să remarcăm importanța luării în considerare a mai multor opțiuni de diagramă la modelarea unui sistem. Asemenea opțiuni pot apărea la ajustarea diagramelor, așa cum sa făcut cu „Procesarea unei cereri de client” sau la crearea unor implementări alternative ale funcțiilor sistemului (descompunerea lucrării „Modificarea bazei de date”). Revizuirea opțiunilor vă permite să o selectați pe cea mai bună și să o includeți într-un pachet de diagrame pentru o analiză suplimentară.

În această secțiune, metodologia de definire, clasificare și identificare a proceselor (secțiunea ____) este implementată pe baza metodologiei de modelare funcțională IDEF0.

1. Definirea proceselor de afaceri sub forma unui model IDEF0

1.1. Definirea unui proces de afaceri.

În prima etapă a descrierii, este necesar să se definească procesele de afaceri din organizație. Elementul cheie în definirea unui proces de afaceri este declarația de scop, care reflectă motivul creării modelului (descrierea) procesului de afaceri și determină scopul acestuia.

Note:

1 Scopul modelului este de a fixa un anumit unghi din care sunt privite și descrise activitățile organizației. În scopuri diferite, unghiurile de vedere pot fi diferite, iar modelele de proces vor fi diferite.

De exemplu, la descrierea proceselor la o fabrică de îmbrăcăminte se pot formula diverse scopuri: optimizarea structurii organizatorice a fabricii, formarea unui sistem de management al calității, extinderea activităților etc.

2 Scopul general al modelelor din cadrul acestui document este de a crea un sistem de management al calității care să îndeplinească cerințele STB ISO 9000-2001, STB ISO 9001-2001 și STB ISO 9004-2001.

Pentru a identifica procesele de afaceri, este necesar să se determine următoarele:

consumatorii produselor și/sau serviciilor organizației;
produse și/sau servicii produse de organizație și furnizate consumatorilor;
tipuri de materii prime și furnizorii acestora.

NOTĂ Pot fi luate în considerare diferite procese de afaceri pentru diferite tipuri de produse sau diferite categorii de clienți.

De exemplu, o fabrică de îmbrăcăminte produce (coase) paltoane de damă prin încheierea de contracte cu consumatorii. Consumatorii produselor sunt magazinele de îmbrăcăminte pentru femei și companiile comerciale și intermediare. Fabrica achiziționează materii prime de la întreprinderile textile, precum și de la firme comerciale și intermediare.

Fabrica este o societate pe acțiuni închisă. Scopul construirii modelului este de a crea un sistem de management al calitatii. Pe baza acestor informații, un proces de afaceri poate fi distins în activitățile unei fabrici de îmbrăcăminte - „Produceți paltoane pentru femei”. Intrările acestui proces sunt: a) informații externe, inclusiv cerințele consumatorilor (magazine și companii); b) materii prime si materiale; c) resurse. Ieșirile procesului sunt: a) loturi de produse finite destinate consumatorilor; b) informare pentru consumatorii externi. Controlul procesului se realizează pe baza documentelor de reglementare care reglementează procesele de producție din fabrică. Având în vedere că suntem interesați de proces din punct de vedere al managementului calității, vom considera ca control extern documentele de reglementare care reglementează acest domeniu, inclusiv cerințele STB ISO 9000. Este prezentată o hartă a procesului de afaceri la o fabrică de confecții. în fig. 3.

Orez. 3 Procesul de afaceri într-o fabrică de confecții

1.2. Descrierea structurii procesului de afaceri

În a doua etapă a definirii unui proces de afaceri, este necesar să se descrie structura sa internă. Pentru a face acest lucru, trebuie să definiți:

din ce procese constă procesul de afaceri modelat;
modul în care aceste procese interacționează între ele.

Modelarea IDEF0 folosește un mecanism de descompunere pentru a descrie structura internă a unui proces.

În conformitate cu cerințele metodologiei IDEF0, pentru a descompune un proces de afaceri, este necesară crearea unei diagrame copil. Această diagramă ar trebui să reprezinte procesele care alcătuiesc un proces de afaceri în cadrul unui sistem de management al calității (QMS).

Să luăm în considerare descompunerea procesului de afaceri „Produceți paltoane pentru femei” (Fig. 3).

Ținând cont de obiectivele modelării - conformitatea procesului de afaceri cu cerințele STB ISO 9001 - 2001, descompunerea procesului de afaceri include 4 blocuri de procese prezentate în Fig. 4.

În conformitate cu cerințele STB ISO 9000, procesul de afaceri „Produceți haine pentru femei” include următoarele procese:

– să realizeze responsabilitatea managementului de vârf pentru managementul calității;

– efectuează managementul resurselor;

– implementarea proceselor ciclului de viață;

– efectuează măsurători, analize și îmbunătățiri ale SMC.

Notă – Figura 4 nu prezintă interacțiunile dintre blocurile funcționale reprezentând descompunerea procesului „Produceți haine femei” 1.3.Descrierea interacțiunilor dintre procese

Al treilea pas în definirea unui proces de afaceri este de a descrie interacțiunile dintre procese. Interacțiunea dintre procese în IDEF0 este descrisă folosind arcuri de interfață și denotă transferul de materiale și/sau informații de la ieșirile unui proces la intrările (controale, mecanisme) ale altui proces.

În metodologia IDEF0, sunt permise 5 (cinci) tipuri de interacțiuni între blocuri dintr-o diagramă (Tabelul 1):

Control;
ieșire – intrare;
feedback-ul managementului;
feedback de intrare;
ieșire – mecanism.

tabelul 1

	Relația de control: rezultatul unui proces afectează execuția altui proces, adică arcul de ieșire al blocului 1 este arcul de control pentru blocul 2. În STB ISO 9001, o astfel de interacțiune definește funcția de control „responsabilitatea managementului” în raport cu alte procese
	Relația de intrare: ieșirea unui proces este intrarea pentru altul, adică arcul de ieșire al blocului 1 este arcul de intrare pentru blocul 2. Această interacțiune este tipică pentru orice proces din organizație, de exemplu, pentru procesele ciclului de viață
	Feedback de control: Ieșirile dintr-un proces afectează execuția altor procese, a căror execuție afectează, la rândul său, execuția procesului original. Arcul de ieșire al blocului 1 este arcul de control pentru blocul 2, iar arcul de ieșire al blocului 2 este arcul de control pentru blocul 1. În STB ISO 9001, o astfel de interacțiune poate determina: – funcția de conducere „responsabilitatea managementului”; – funcția de management „managementul procesului ciclului de viață”; – funcția de management „măsurare, analiză și îmbunătățire”
	Feedback de intrare: ieșirea unui proces este intrarea unui alt proces, a cărui ieșire este intrarea acestuia, adică. arcul de ieșire al blocului 2 este arcul de intrare pentru blocul 1, a cărui ieșire este intrarea acestuia. În STB ISO 9001-2001, o astfel de interacțiune poate defini funcția de management „managementul procesului ciclului de viață”
	Relația „ieșire-mecanism”: rezultatul unui proces este un mecanism pentru altul, adică. arcul de ieșire al blocului 1 este arcul mecanismului pentru blocul 2. Acest tip de conexiune se referă cel mai adesea la procesele de furnizare a resurselor. În STB ISO 9001, o astfel de interacțiune poate determina funcția de management „managementul resurselor”

Practica arată că cele cinci tipuri de interacțiuni enumerate sunt suficiente pentru a determina interacțiunile dintre procese de orice complexitate.

Descrierea interacțiunilor din cadrul modelului de proces funcțional va fi completă atunci când arcuri de interfață ale acestuia sunt definite pentru fiecare bloc funcțional.

Notă – Metodologia IDEF0 prevede că fiecare bloc din model trebuie să conțină cel puțin un arc de intrare, ieșire, control și mecanism. Există o scurtă listă de excepții de la această regulă.

Să luăm în considerare interacțiunile dintre procesele care alcătuiesc procesul de afaceri „Produceți haine de femei” (Fig. 5).

Procesul „Implementează responsabilitatea managementului de vârf pentru managementul calității” este procesul de conducere pentru toate celelalte procese. În consecință, rezultatul acestui proces - „Politică, obiective, management al calității, programe de calitate” este intrarea de control pentru toate celelalte procese prezentate în diagramă (Fig. 5).

Procesul „Efectuați managementul resurselor” are o legătură „mecanism-ieșire” cu procesele „Implementarea proceselor ciclului de viață” și „Efectuați măsurători, analize și îmbunătățiri ale SMC”.

Diagrama arată bucla de feedback: rezultatul procesului „Măsurați, analizați și îmbunătățiți SMC” cu intrarea procesului „Implementați responsabilitatea managementului de vârf pentru managementul calității”

Notă – Regula de completitudine a modelului funcțional IDEF0 corespunde exact cerințelor STB ISO 9001 în ceea ce privește faptul că fiecare proces trebuie să fie prevăzut cu resurse (arcuri de mecanisme în modelul IDEF0), controlate (arcuri de control), produce produse de ieșire (arcuri de ieșire), materiale de procesare și/sau informații care ajung la intrările sale (arcuri de intrare).

Fig.5 - Interacțiuni între procese

Numărul de niveluri de detaliere a procesului este determinat de obiectivele modelării și de specificul activității organizației modelate. În cadrul acestei metodologii, scopul principal al modelării procesului este de a analiza conformitatea procesului cu cerințele sistemului de management al calității.

În diagrama A0 (Fig. 5), procesul de afaceri „Produceți haine pentru femei” este prezentat sub forma a 4 procese. Diagrama A0 este primul nivel de descompunere (detaliu) pentru acest proces. Fiecare dintre cele 4 procese prezentate poate fi la rândul său descompus. În fig. Figura 6 prezintă descompunerea procesului „Implementează procesele ciclului de viață”.

În diagrama A3 (Fig. 6), procesul „Implementează procesele ciclului de viață” este prezentat sub forma a șase procese, inclusiv „Efectuează achiziția”, care poate fi, de asemenea, descompus (Fig. 7).

Orez. 6.- Descompunerea procesului „Implementarea proceselor ciclului de viață”

Glosarul de proces include o listă de procese, obiecte procesate în cadrul proceselor și definițiile acestora.

Glosarul oferă o listă de termeni organizată alfabetic. Fiecare termen din această listă corespunde unei definiții sau unei legături către definiția corespunzătoare dată în documentele de reglementare ale organizației sau autorități superioare, reglementări etc.

De exemplu, pentru diagrama A34 (Fig. 7), un fragment din glosar va arăta astfel.

În continuare, vom lua în considerare metodele standard de analiză structurală a sistemului descrise de o serie de standarde federale din SUA „ Definiția Icam", în conformitate cu . Informații detaliate despre toate standardele din această serie pot fi găsite la http://www.idef.com.

Standard IDEF0(FIPS183) este destinat să creeze un model funcțional care descrie structura și funcțiile unui sistem, precum și fluxurile de informații și obiecte materiale care conectează aceste funcții. Acest document este un design (la inițiativa Departamentului de Apărare al SUA) sub forma unui standard tehnologic pentru analiza sistemelor complexe SADT(Structured Analysis and Design Technique), dezvoltat de un grup de analiști americani condus de Douglas Ross în 1973.

Metoda propusă de standardul IDEF0 este destinată modelării funcționale, adică modelării performanței funcțiilor unui obiect, prin realizarea unui model grafic descriptiv care să arate ce, cum și de către cine se realizează în cadrul funcționării întreprinderii. Un model funcțional este o reprezentare structurată a funcțiilor unui sistem sau mediului de producție, a informațiilor și a obiectelor care conectează aceste funcții. Modelul este construit folosind metoda de descompunere: de la structuri mari compozite la cele mai mici, mai simple. Elementele fiecărui nivel de descompunere reprezintă acțiuni de prelucrare a informațiilor sau a resurselor materiale în anumite condiții folosind mecanisme specificate. Fiecare acțiune este descompusă în operațiuni mai mici de prelucrare a unei anumite părți a informațiilor sau a resurselor materiale în anumite condiții folosind o parte din mecanismele specificate. Operațiunile sunt prezentate într-un mod similar. Ultimul pas de descompunere ar trebui să aibă ca rezultat un model al cărui nivel de detaliu satisface cerințele specificate chiar la începutul procesului de creare a modelului.

Metodologia IDEF0 se bazează pe următoarele principii:

1. Sistem și model. Un model este un obiect artificial care este o reprezentare (imagine) a unui sistem și a componentelor sale. M modele A, Dacă M răspunde la întrebări referitoare la A. Aici M- model, A– obiect modelat (original). Modelul este dezvoltat pentru a înțelege, analiza și lua decizii cu privire la reconstrucția (reproiectarea) sau înlocuirea unui sistem existent sau proiectarea unui nou sistem. Un sistem este o colecție de părți interconectate și care interacționează care efectuează unele lucrări utile. Părțile (elementele) unui sistem pot fi orice combinație de diferite entități, inclusiv oameni, informații, software, echipamente, produse, materii prime sau energie. Modelul descrie ce se întâmplă în sistem, cum este controlat, ce entități transformă, ce instrumente folosește pentru a-și îndeplini funcțiile și ce produce.

2. Modelarea blocurilor și reprezentarea sa grafică. Principiul conceptual principal al metodologiei IDEF este reprezentarea oricărui sistem studiat ca un set de blocuri interconectate și interconectate care afișează procesele, operațiunile și acțiunile care au loc în sistemul studiat. În IDEF0, tot ceea ce se întâmplă în sistem și elementele sale se numește funcții. Fiecărei funcții i se atribuie un bloc. Pe o diagramă IDEF0 (numită mai des diagramă SADT), documentul principal în analiza și proiectarea sistemelor, blocul este un dreptunghi. Interfețele prin care un bloc interacționează cu alte blocuri sau cu mediul extern sistemului care se modelează sunt reprezentate de săgeți care intră sau ies din bloc. Săgețile de intrare indică condițiile care trebuie îndeplinite simultan pentru ca funcția descrisă de bloc să apară.

3. Rigurozitate și formalism. Dezvoltarea modelelor IDEF0 necesită aderarea la o serie de reguli formale stricte care asigură beneficiile metodologiei în ceea ce privește neambiguitatea, acuratețea și integritatea modelelor complexe pe mai multe niveluri. Aceste reguli sunt descrise mai jos în ceea ce privește tehnologia SADT. Aici se notează doar cea principală: toate etapele și etapele dezvoltării și ajustării modelului trebuie să fie strict, formal documentate, astfel încât în timpul funcționării acestuia să nu apară întrebări legate de incompletitudinea sau incorectitudinea documentației.

4. Modelare iterativă. Dezvoltarea modelului în IDEF0 este o procedură iterativă pas cu pas. La fiecare pas de iterație, dezvoltatorul propune o versiune a modelului, care este supusă discuției, revizuirii și editării ulterioare, după care ciclul se repetă. Această organizare a muncii contribuie la utilizarea optimă a cunoștințelor unui analist de sisteme care este competent în metodologia și tehnica IDEF0, precum și a cunoștințelor specialiștilor - experți în domeniul căruia îi aparține obiectul de modelare.

5. Separarea „organizației” de „funcții”. La elaborarea modelelor, trebuie evitat inițial „legarea” funcțiilor sistemului studiat de structura organizatorică existentă a obiectului modelat (întreprindere, firmă). Acest lucru ajută la evitarea unui punct de vedere subiectiv impus de organizație și managementul acesteia. Structura organizatorică trebuie să fie rezultatul utilizării (aplicarii) modelului. Compararea rezultatului cu structura existentă permite, în primul rând, evaluarea adecvării modelului, iar în al doilea rând, propunerea de soluții care vizează îmbunătățirea acestei structuri.

Exemple de probleme rezolvate pe baza metodologiei de modelare IDEF0:

Analiza si reinginerirea proceselor de afaceri.

Dezvoltarea unui sistem informatic pentru managementul calitatii datelor.

Elaborarea de reglementări și proceduri pentru asigurarea calității produselor și crearea sistemelor de prelucrare a datelor de calitate. Modelul funcțional vă permite să înlocuiți manualele tradiționale de calitate sub formă de documente de tip text descriptiv pe hârtie cu modele electronice standardizate, a căror integritate și consistență este menținută automat. Dacă este necesar, puteți obține întotdeauna un raport pe hârtie de la ei în forma obișnuită.

Proiectarea infrastructurii informaționale, procedurilor și reglementărilor pentru interacțiunea informațională.

Sarcini de analiză a riscurilor în ceea ce privește securitatea informațiilor.

Să luăm în considerare, în conformitate cu lucrarea, principiile construcției diagramelor folosind tehnologia SADT (IDEF0).

Limbajul grafic al SADT este simplu și armonios. Metodologia se bazează pe patru concepte principale.

Primul dintre acestea este conceptul „ bloc funcţional" Un bloc funcțional este reprezentat grafic ca un dreptunghi (vezi Fig. 3.23) și reprezintă o funcție specifică în cadrul sistemului luat în considerare. Conform cerințelor standardului, numele fiecărui bloc funcțional trebuie formulat în starea verbală (de exemplu, „ produce servicii", dar nu " producerea de servicii"). Fiecare dintre cele patru laturi ale blocului funcțional are propriul său sens specific (rol), în timp ce: partea de sus are semnificația „ Control" (cont r ol); partea stângă are sensul " Intrare» ( intrare); partea dreaptă înseamnă " Ieșire» ( ieșire); partea de jos înseamnă " mecanism» ( mecanism). Fiecare bloc funcțional dintr-un singur sistem luat în considerare trebuie să aibă propriul său număr de identificare unic.

Scopul lucrării:

studierea principiilor de bază ale metodologiei IDEF0,
crearea unui nou proiect în BPWin,
formarea unei diagrame de context,
a face legături.

Descrierea unui sistem care utilizează IDEF0 se numește model funcțional. Modelul funcțional este conceput pentru a descrie procesele de afaceri existente, care utilizează atât limbaje naturale, cât și limbaje grafice. Pentru a transmite informații despre un anumit sistem, sursa limbajului grafic este însăși metodologia IDEF0.

Fiecare Diagramele IDEF0 a conține blocuri și arce. Blocurile descriu funcțiile sistemului modelat. Arcurile leagă blocurile între ele și reprezintă interacțiunile și relațiile dintre ele.

Blocul cel mai dominant este de obicei plasat în colțul din stânga sus al diagramei, iar blocul cel mai puțin dominant este în colțul din dreapta.

Tipuri de săgeți

IDEF0 distinge între cinci tipuri de săgeți.

Ieșire- obiecte în care sunt convertite intrările. Fiecare job trebuie să aibă cel puțin o săgeată de ieșire, care este desenată ca emanând din marginea dreaptă a jobului.

Orez. 2.1 Tipuri de săgeți

Orez. 2.2. Comunicare de ieșire

Orez. 2.3. Comunicarea managementului

O relație de control apare atunci când ieșirea unui bloc afectează direct blocul mai puțin dominant.

Feedback-ul de control are loc atunci; când ieșirea unui bloc afectează un bloc cu dominanță mai mare.

Relațiile de ieșire-mecanism sunt rare. Ele reflectă o situație în care rezultatul unei funcții devine un mijloc pentru un scop pentru alta.

Orez. 2.4. Feedback de conectare

Orez. 2.5. Feedback de management

Relațiile producție-mecanism sunt caracteristice alocării surselor de resurse (de exemplu, instrumente necesare, personal instruit, spațiu fizic, echipamente, finanțare, materiale).

ramurile neetichetate conțin greutatea obiectelor specificate în eticheta arcului înainte de ramură;
ramurile etichetate după punctul de ramificare conțin toate sau o parte din obiectele specificate în eticheta arcului înainte de ramificare.

Orez. 2.6. Conexiune ieșire-mecanism

ramurile neetichetate conțin greutatea obiectelor specificate în eticheta arcului comun după îmbinare;
ramurile marcate înainte de îmbinare conțin toate sau unele dintre obiectele enumerate în eticheta comună după îmbinare,

Analiza grafică cantitativă

Pentru a efectua o analiză cantitativă a diagramelor, listăm indicatorii modelului:

numărul de blocuri pe diagramă - N;
nivel de descompunere a diagramei - L;
echilibrul diagramei - ÎN;
numărul de săgeți care se conectează la bloc - A

Acest set de factori se aplică fiecărei diagrame model. Următoarele vor enumera recomandări cu privire la valorile dorite ale factorilor din diagramă.

Orez. 2.7. Exemplu de grafic dezechilibrat

Să introducem coeficientul de echilibru al diagramei

Este necesar să ne străduim să Q a fost minim pentru diagramă.

Setul de instrumente BPWin

Când porniți BPWin, bara de instrumente principală, paleta de instrumente și Model Explorer apar în mod implicit.

Fig.2.8 Dialog de creare a modelului

Exemplu

Să începem prin a construi o diagramă de context IDEF0.Conform descrierii sistemului, funcția principală este de a-și servi clienții prin procesarea cererilor de la aceștia. Astfel, definim singura sarcină a diagramei de context ca „Servește clientul sistemului”. În continuare, definim datele de intrare și de ieșire, precum și mecanismele și controlul.

Diagrama de context

Astfel, definim diagrama de context a sistemului (Fig. 2.9).

Figura 2.9. Diagrama contextului sistemului

Să descompunăm diagrama de context, descriind secvența serviciului clienți:

Determinarea nivelului de acces la sistem.
Selectarea subsistemului.
Acces la subsistem.
Modificarea bazei de date (dacă este necesar).

Obținem diagrama prezentată în fig. 2.10.

Orez. 2.10. Descompunerea lucrării „Serviciul, clientul de sistem”

Orez. 2.11. Descompunerea lucrării „Determinarea nivelului de acces la sistem”

Deschiderea bazei de date.
Executarea cererii.
Generarea de rapoarte.

Orez. 2.12.

Ajustarea graficului

Schimbarea diagramei va avea ca rezultat ajustări la toate diagramele părinte (Fig. 2.13 - 2.15).

Orez. 2.13. Descompunerea lucrării „Prelucrarea cererii unui client”

Orez. 2.14. Descompunerea lucrării „Serviciul pentru clienți de sistem” (opțiunea 2)

Orez. 2.15. Diagrama contextului sistemului (opțiunea 2)

baza de date a utilizatorilor,
baza de date a studentilor, (opțiunea 2)
baza de date a posturilor vacante,
baza de date a performantelor academice,
baza de date de testare,
DB de evaluări de experți,
CV DB.

Este determinată baza de date în care vor fi modificate informațiile.
Operatorul generează un set de date temporar și îl furnizează administratorului.
Administratorul controlează datele și le introduce în baza de date.

Orez. 2.16. Descompunerea lucrării „Schimbarea bazei de date”

Orez. 2.17. Descompunerea lucrării „Modificarea bazei de date” (opțiunea 2) Pentru prima opțiune, prezentată în Fig. 2.12

O descompunere a lucrării de execuție a interogărilor va fi efectuată în laboratorul următor, ilustrând utilizarea diagramelor DFD pentru a descrie procesele de procesare a informațiilor.

Să luăm în considerare modificarea coeficientului K b au două opțiuni de model.

pentru a doua varianta

Coeficient K b nu își modifică valoarea, prin urmare, echilibrul diagramei nu se modifică.

Întrebări de control

Listă Intrebari de securitate:

Ce este un model în notația IDEF0?
Ce înseamnă joburile din IDEF0?
Care este ordinea denumirii lucrărilor?
Câte lucrări ar trebui să fie prezente pe o diagramă?
Care este ordinea dominației?
Cum sunt aranjate lucrările după principiul dominației?
Care este scopul laturilor dreptunghiurilor de lucru pe diagrame?
Enumerați tipurile de săgeți.
Numiți tipurile de relații.
Cum se numesc săgețile de delimitare?
Explicați principiul denumirii săgeților de ramificare și îmbinare.
Ce metodologii sunt acceptate de BPWin?
Enumerați elementele principale ale ferestrei principale BPWin.
Descrieți procesul de creare a unui nou model în BPWin.
Cum se face conexiuni între lucrări?
Cum să setați un nume de job.
Descrieți procesul de defalcare a muncii.
Cum se adaugă lucru la o diagramă?
Cum să rezolvi săgețile tunelizate?
Poate un model BPWin să conțină diagrame de metodologii multiple?

IDEF0 este astăzi principalul standard pentru modelarea proceselor de afaceri. Este apelată descrierea unui sistem care utilizează IDEF0 model functional . Modelul descrie ce se întâmplă în sistem, cum este controlat, ce entități transformă, ce instrumente folosește pentru a-și îndeplini funcțiile și ce produce.

La construirea unui model, trebuie precizat scopul modelării, răspunzând la următoarele întrebări:

· de ce ar trebui modelat acest proces?

Ce ar trebui să arate modelul?

· ce poate obține cititorul?

Exemple de definire a obiectivelor: „identifică și definește problemele curente, face posibilă analiza potențialelor îmbunătățiri”, „identifică rolurile și responsabilitățile angajaților pentru scrierea fișelor postului”, „determina posibilitatea de automatizare...”, „reglementează procesul ...”, etc.

Punct de vedere este, de asemenea, unul dintre elementele cheie la construirea unui model. Un punct de vedere poate fi reprezentat ca punctul de vedere al unei persoane care vede sistemul în aspectul necesar modelării. Punctul de vedere trebuie să corespundă scopului modelării.

Principiul conceptual principal al metodologiei IDEF este reprezentarea oricărui sistem studiat ca un set de blocuri interconectate și interconectate care afișează procesele, operațiunile și acțiunile care au loc în sistemul studiat. În IDEF0, tot ceea ce se întâmplă în sistem și elementele sale este de obicei numit funcții. Fiecare funcție este atribuită bloc.

Blocurile funcționale din diagrame sunt reprezentate prin dreptunghiuri, reprezentând procese, funcții, locuri de muncă sau operațiuni numite care au loc într-o perioadă de timp și au rezultate recunoscute. În interiorul fiecărui bloc se află numele și numărul acestuia. Numele blocului trebuie să fie un verb activ, o expresie verbală sau un substantiv verbal care denotă o acțiune.

Blocurile din IDEF0 sunt plasate în ordinea importanței, așa cum a înțeles autorul diagramei. Această ordine relativă se numește dominanță. Dominanța este înțeleasă ca influența pe care o are un bloc asupra altor blocuri din diagramă. Blocul cel mai dominant este de obicei plasat în colțul din stânga sus al diagramei, iar cel mai puțin dominant este în colțul din dreapta.

Sunt reprezentate interfețele prin care un bloc interacționează cu alte blocuri sau cu un mediu extern sistemului care se modelează săgeți, intrarea sau ieșirea din bloc. Fiecare parte a unui bloc funcțional are o semnificație standard în ceea ce privește relația bloc/săgeată. Aranjamentul standard al săgeților este prezentat în Fig. 1.

Orez. 1. Contextul IDEF0.

Săgeți descrieți interacțiunea blocurilor cu lumea exterioară și între ele. Săgețile reprezintă unele informații și sunt numite substantive sau expresii ale unui substantiv.

Există cinci tipuri de săgeți în IDEF0:

1. Intrare - material sau informație care este folosită sau transformată de un bloc funcțional pentru a produce un rezultat (ieșire). Este permis ca lucrarea să nu aibă o singură săgeată de intrare.

2. Guvernare - regulile, politicile, procedurile sau standardele care guvernează unitatea. Controlul afectează blocul, dar nu este transformat de acesta.

3. Ieșire - material sau informație care este produsă de bloc. Un bloc fără rezultat este lipsit de sens și nu trebuie modelat.

4. Mecanism - resurse care efectuează blocul, de exemplu, personalul întreprinderii, mașinile, dispozitivele etc. La discreția analistului, săgețile mecanismului pot să nu fie descrise în model.

5. Apel - o săgeată specială care indică un alt model de lucru. O săgeată de apel este folosită pentru a indica faptul că unele lucrări sunt efectuate în afara sistemului care este modelat.

Săgețile de pe diagrama de context sunt folosite pentru a descrie interacțiunea sistemului cu lumea exterioară. Săgeți de delimitare- săgeți care încep la marginea diagramei și se termină la lucru sau invers. Săgeți interioare conectați blocurile între ele. Există cinci tipuri de conexiuni de lucru.

1. Comunicare prin intrare - săgeata de ieșire a blocului superior este îndreptată către intrarea celui de jos (Fig. 2).

Orez. 2. Relația ieșire-intrare.

2. Comunicare de control - ieșirea blocului de nivel superior este trimisă la controlul celui de nivel inferior (Fig. 3).

Orez. 3. Relația ieșire-control.

3. Feedback de control - ieșirea blocului de nivel inferior este trimisă la controlul celui de nivel superior (Fig. 4).

Orez. 4. Control Feedback

4. Feedback de intrare - ieșirea blocului de nivel inferior este trimisă la intrarea celui de nivel superior (Fig. 5).

Orez. 5. Raportul de feedback de intrare

5. Conexiune ieșire-mecanism - ieșirea unui bloc este direcționată către mecanismul altuia (Fig. 6).

Orez. 6 Conexiune ieșire-mecanism.

În notația IDEF0, descrierea (modelul) sistemului este organizată sub formă de diagrame ordonate ierarhic și interconectate. În primul rând, se realizează o descriere a sistemului în ansamblu și a interacțiunii acestuia cu lumea exterioară (diagrama contextului). Diagrama de context include un singur bloc care caracterizează întregul set de procese modelate, fără detalii.

Orez. 7 Exemplu de diagramă de context IDEF0.

După care se efectuează o descompunere funcțională (Fig. 8) - acest bloc de activitate (proces mare) este împărțit în subprocese mari - și fiecare subproces este descris separat (diagrame de descompunere). Apoi fiecare subproces este descompus în altele mai mici - și așa mai departe până când se obține detaliul necesar al descrierii.

Fig.8 Exemplu de diagramă de descompunere IDEF0.