Cum se creează diagrama idef0. Curs: Dezvoltarea unui model de întreprindere cu efect de seră folosind metodologiile de proiectare IDEF0, DFD și IDEF3. Diagrama de descompunere A3

Adesea, dezvoltatorilor li se cere nu numai să identifice și să rezolve o problemă în activitatea companiei, ci și să determine ce rol joacă în structura companiei. Deoarece este mult mai important să înțelegem cum interacționează o unitate defectuoasă cu alții decât să înțelegem de ce nu funcționează corect. Prin urmare, identificarea oricărei probleme începe cu studierea activității companiei și elaborarea modelului său funcțional.

Adesea, dezvoltatorilor li se cere nu numai să identifice și să rezolve o problemă în activitatea companiei, ci și să determine ce rol joacă în structura companiei. Deoarece este mult mai important să înțelegem modul în care o unitate defectuoasă interacționează cu alții decât să înțelegem de ce nu funcționează corect. Prin urmare, identificarea oricărei probleme începe cu studierea activității companiei și elaborarea modelului său funcțional.

Veți spune că managerul ar trebui să aibă un model funcțional al companiei, indiferent de ce fel de companie vorbește. Dar, după cum arată practica, în cele mai multe cazuri acest model este absent.

Avantaj grafic

Ce sunt modelele IDEF0? Scheme grafice cu propriile caracteristici și regulile pentru construcția lor. De ce grafica? Pentru că este eficient. Acest lucru poate fi văzut în mai multe exemple.

Să ne imaginăm că planul militar al operațiunilor militare a fost explicat în cuvinte și nu cu ajutorul hărților cu simboluri grafice aplicate acestora. Acum pare imposibil, dar până în a doua jumătate a secolului al XIX-lea a fost exact așa. Graficele ajută la înțelegerea a ceea ce trebuie explicat și, în consecință, la înțelegerea a ceea ce este suficient de dificil.

Este la fel cu procesele de afaceri: multe sarcini tehnice poate fi executat sub forma unor notații grafice, care vor simplifica mult sarcina pentru dezvoltatori și vor economisi bani pentru clienți.

Avantajele IDEF0 pentruACEASTA-specialisti

Activitățile dezvoltatorilor, indiferent dacă este, de exemplu, instalarea unui CRM sau crearea unui ERP eficient, este asociată cu modificarea unui sistem deja stabilit. Și pentru a face acest lucru corect, mai întâi trebuie să studiați cum funcționează acest sistem. După ce a studiat-o, dezvoltatorul scrie o propunere comercială în care își expune viziunea asupra situației, acțiunile necesare rezolvării sarcinii, precum și rezultatul scontat. Un astfel de document poate dura mai mult de o duzină de pagini. Pe de o parte, acest lucru este bun, deoarece clientul primește cantitatea maximă de informații de care este interesat. Pe de altă parte, este nevoie de timp pentru a studia un text lung. om de afaceri de succes de multe ori nu.

Deci, cum este posibil să transmitem esența fără a recurge la texte voluminoase? Grafică! Ea este cea care vă permite să scurtați ceea ce este scris, demonstrând clar informațiile necesare. La urma urmei, o singură imagine poate înlocui sute de cuvinte. Și în ceea ce privește utilizarea graficii în descrierea proceselor de afaceri, acest lucru este 100% adevărat.

Să înțelegem mai întâi ce sunt notația și IDEF0 și la ce servesc.

Notare pentru descrierea proceselor de afaceri: ce este

Notarea este un format în care procesele de afaceri sunt reprezentate sub formă de obiecte grafice utilizate în modelare și reguli de modelare directă. Notarea este un fel de limbaj grafic care vă permite să reprezentați funcționarea unei companii, demonstrând relația dintre departamente și divizii. Adică, notația poate fi considerată un fel de limbaj de programare în business intelligence.

IDEF0 este ...

IDEF0 este o metodă funcțională de modelare și notație grafică care este utilizată pentru a descrie și formaliza procesele de afaceri. Particularitatea IDEF0 este că această metodologie este axată pe subordonarea obiectelor. IDEF0 a fost dezvoltat pentru automatizarea întreprinderii în 1981 în Statele Unite.

Modelul funcțional al companiei

Modelul funcțional IDEF0 este blocuri, fiecare cu intrări și ieșiri multiple. Fiecare bloc are controale și mecanisme care sunt detaliate la nivelul cerut. Cea mai importantă funcție se află în colțul din stânga sus. Se conectează la restul săgeților și la descrierile blocurilor funcționale. Fiecare săgeată sau activitate are propriul său sens. Datorită acestui fapt, un astfel de model este utilizat pentru a descrie orice proces administrativ și organizațional.

Tipuri de săgeți

Primite sarcinile sunt stabilite.

De ieșire afișează rezultatul activității.

Managerii(săgețile de sus în jos) sunt mecanisme de control.

Mecanisme(săgețile de jos în sus) sunt utilizate pentru a efectua lucrările necesare.

Când lucrați cu un model funcțional, sunt adoptate următoarele reguli. De exemplu, săgețile sunt denumite cu substantive (reguli, plan etc.), blocuri - cu verbe (țineți evidența, încheiați un acord).

IDEF0 vă permite să faceți schimb de informații, în timp ce datorită versatilității și vizibilității sale, participanții la schimb se vor înțelege cu ușurință. IDEF0 a fost dezvoltat și îmbunătățit cu atenție, puteți lucra cu IDEF0 folosind diverse instrumente, de exemplu, ERWIN, VISIO, studioul Bussines.

IDEF0 are, de asemenea, un avantaj incontestabil. Această tehnică a fost dezvoltată în urmă cu relativ mult timp și, de peste trei decenii, a suferit o rectificare și o reglare aprofundată. Prin urmare, este posibil să creați un model funcțional al unei companii rapid și cu o probabilitate minimă de eroare.

Desigur, există și alte metodologii, deci de ce recomandăm IDEF0? Puteți tăia o bucată de țeavă de metal cu un ferăstrău, dar, vedeți, este mult mai ușor să faceți acest lucru cu un polizor. La fel și cu IDEF0: nu mai există un instrument funcțional pentru modelare, cu acesta puteți obține cu ușurință și rapid rezultatul de care aveți nevoie.

Cum se creează un model funcțional

Să analizăm crearea unui model funcțional folosind exemplul scrierii unui articol.

Unitatea principala va fi așa numită „Scrierea articolelor”.

Ce este necesar pentru a scrie un articol se reflectă în săgeți primite- „Experiență”, „Lecturi suplimentare”.

Săgeți de control pentru scrierea unui articol - „Schița articolului”, „Cerințe de înregistrare”, „Reguli ale limbii ruse”.

Mecanismele sunt direct autorul însuși, redactor, editor, software. Cum sunt organizate aceste mecanisme? Autorul creează textul înregistrând versiunea sa audio. Redactorul transferă textul în format text, concentrându-se pe planul de publicare, respectând cerințele editorului și regulile limbii ruse. Apoi, editorul este conectat la lucru, care verifică articolul, corectând erorile de vorbire, ortografie și punctuație. Software-ul este programele și instrumentele pe care participanții la procesul folosit pentru a crea articolul.

Toate cele de mai sus sunt doar o schemă generală de lucru, deci trebuie să fie detaliate.

Să ne întoarcem la modelul nostru și să descompunem blocul comun în mai multe elemente conexe.

Deci, întregul proces de scriere a unui articol poate fi împărțit în 4 etape:

  1. Pregătiți o versiune audio.
  2. Pregătiți textul tipărit.
  3. Editarea și pregătirea textului pentru tipărire.
  4. Publicarea articolului.

Diagrama reflectă informații despre ce controale și mecanisme sunt implicate în ce etapă. De exemplu, pentru a crea un text de calitate, autorul își folosește propria experiență și cunoștințe, întrucât un ghid folosește planul de publicare și cerințele editorului. Redactorul, creând versiunea tipărită a textului, și editorul, atunci când îl corectează, folosesc regulile limbii ruse. Pentru a publica un articol, de exemplu, într-o publicație online, este necesar un software special.

Atunci când pregătește un model funcțional, interpretul este ghidat de scopul creării sale și de punctul său de vedere.

Modelarea funcțională este utilizată eficient în luarea diferitelor decizii de management. În exemplul nostru de proces de scriere a articolelor, există doi specialiști - un redactor și un editor. Și cu optimizarea necesară a finanțării proiectelor în conformitate cu schema, nu este dificil să se stabilească cum să facă acest lucru. Redactorul și corectorul au metode de lucru similare, astfel încât toată lucrarea poate fi oferită redactorului, deoarece lucrează direct cu textul audio, ceea ce editorul nu poate face. În acest caz, redactorului i se poate oferi acest lucru pentru jumătate din suma care a fost destinată editorului. Da, acest lucru poate duce la pierderea calității textului, dar sarcina de optimizare a fost finalizată cu succes. Și ar fi mai dificil să faci acest lucru fără o diagramă vizuală.

Procesul de creare a notațieiIDEF0

Există multe programe pentru crearea notațiilor. Unele sunt concepute pentru a crea modele funcționale, în timp ce altele vă permit să lucrați cu orice obiecte grafice. Iar pentru cineva, în prima etapă, este suficientă o foaie de hârtie, un creion și o radieră.

Înainte de a trece la descrierea activității companiei, adică direct la crearea notării proceselor de afaceri, ar trebui studiat principiile funcționării companiei. Pentru aceasta, un interviu este realizat de un terț specialist. În primul rând, șeful companiei răspunde la întrebare, apoi specialiștii care supraveghează alte etape de lucru.

Prima etapă de lucru are ca rezultat două notații. Una va reflecta procesele de afaceri în forma lor originală. Această notație va fi creată pe baza rezultatelor interviului, iar fiecare detaliu trebuie convenit cu șeful companiei și angajații săi. Este imperativ ca înțelegerea proceselor de afaceri existente în companie să coincidă cu realitatea, acest lucru necesită confirmare la toate nivelurile.

A doua notație poate fi numită „Așa cum ar trebui să fie”. Este creat pe baza primului cu modificări făcute în conformitate cu sarcina.

Standardul IDEF0 și cerințele sale

Am vorbit despre cerințele de bază ale IDEF0 chiar mai sus.

  1. Elementul principal este în colțul din stânga sus.
  2. Fiecare element trebuie să aibă săgeți de intrare și de ieșire. Mai mult, săgețile de intrare sunt în stânga, în dreapta - cele de ieșire.
  3. Elementele de control sunt situate în partea de sus, mecanismele în partea de jos.
  4. Când plasați mai multe blocuri pe o foaie sau ecran, cele ulterioare sunt plasate în partea dreaptă jos a celei anterioare.
  5. Schemele ar trebui create astfel încât săgețile să se intersecteze de numărul minim de ori.
Bineînțeles, standardul IDEF0 a acceptat în general norme, cerințe și desemnări. Nu ne vom opri în detaliu, dacă doriți, aceste informații sunt ușor de găsit.

Erori la lucrul cu IDEF0

Ca și în cazul oricărei activități, apar erori la efectuarea modelării funcționale. Să le analizăm pe cele mai tipice.

Folosind mai multe culori

Este important să ne amintim că în modelarea funcțională toate elementele sunt importante, nu există altele mai importante sau mai puțin importante. La modelarea pe hârtie sau într-unul din programe de calculator utilizatorii încearcă să facă diagrama mai vizuală colorând blocuri și săgeți în diferite culori... Cu toate acestea, în practică, acest lucru nu numai că nu face diagrama mai vizuală, ci, dimpotrivă, duce la confuzie și la faptul că percepția a ceea ce este descris este distorsionată.

Prin urmare, opțiunea ideală este o schemă alb-negru fără utilizarea opțiunilor suplimentare de culoare. Acest lucru nu numai că ajută la eliminarea neînțelegerilor, ci și disciplinează direct creatorul modelului, ceea ce afectează favorabil lizibilitatea și claritatea modelului.

Număr mare de blocuri

Atunci când compun un model funcțional al operei unei companii, autorii ei încearcă adesea să reflecte totul, chiar și cele mai mici detalii. Rezultă o diagramă cu un număr mare de blocuri și săgeți. Drept urmare, lizibilitatea și claritatea acestuia sunt reduse.

Pentru a evita această eroare, utilizați detaliile care vor fi suficiente pentru a înțelege problema. Detaliile detaliate sunt pregătite numai dacă sunt într-adevăr necesare pentru a rezolva o problemă importantă.

Schimbarea structurii la remedierea erorilor

Atunci când creați o diagramă, este important ca mai mult de un proces să nu rămână fără elemente de intrare, ieșire sau alte elemente importante. De exemplu, dacă trebuie să eliminați un autor din schemă, atunci trebuie să eliminați toate elementele și săgețile legate direct de el. Dacă rămân în schemă, atunci vor exista neînțelegeri și confuzii, deoarece în timpul detaliilor vor duce la nimeni nu știe unde.

Aceeași situație apare și cu adăugarea unui bloc. Dacă trebuie să completați informații, verificați dacă ați furnizat atributele necesare. Acest lucru ar trebui monitorizat îndeaproape, deoarece atunci când se modelează procese de afaceri complexe, chiar și o ușoară modificare într-o parte va atrage după sine schimbări în alta.

Numele blocurilor și comenzilor

Regulile pentru numirea elementelor modelului sunt destul de simple, dar este extrem de important să le amintim: săgețile de control sunt numite substantive, blocurile sunt numite verbe. Această regulă este scrisă în standardul IDEF0 și ajută la evitarea confuziei și a erorilor.

Avantajele utilizării IDEF0

Vizibilitate. Prin descrierea muncii companiei sub forma unei diagrame, devine clar modul în care funcționează compania, unde pot apărea probleme și cum să le prevenim.

Înțelegere reciprocă, excluderea posibilității de interpretare greșită a schemei. Vizibilitatea și accesibilitatea modelului funcțional, reprezentând activitatea companiei sub formă de blocuri și elemente de control, vă vor ajuta atunci când discutați cu conducerea funcționării companiei lor. Apropo, dacă este necesar, se creează un glosar pentru modelul funcțional, care conține toți termenii și convențiile. Astfel, posibilitatea de neînțelegere între dvs. și managerul, angajații companiei este minimizată.

Simplitate și economie de timp la crearea unui model. Desigur, este nevoie de mult timp pentru a fi bun la modelarea funcțională. În primul rând, trebuie să învățați cum să prezentați o cantitate imensă de informații sub forma unei scheme laconice, adică să puteți filtra și comprima datele originale. Însă timpul și efortul cheltuit pentru antrenament sunt mai mult decât rentabile ulterior. La urma urmei, nu va dura mult timp pentru a crea un model funcțional și a-l prezenta într-un mod accesibil.

Probabilitatea minimă de eroare. Lucrul în conformitate cu standardul IDEF0 necesită respectarea strictă a regulilor sale. Aceasta disciplinează interpretul și elimină posibilitatea erorilor. În plus, orice nerespectare a standardului devine imediat vizibilă.

Și, în sfârșit

Pentru doi analiști de afaceri, modelele funcționale pot fi aceleași numai dacă structura companiei este extrem de simplă. În alte cazuri, modelele vor diferi între ele. Acest lucru este firesc, deoarece fiecare analist are propria sa experiență, propria înțelegere a funcționării companiei, propriul său punct de vedere cu privire la modul de a rezolva sarcinile care i-au fost atribuite. Un analist de afaceri dezvoltă un model funcțional din punctul de vedere al unui manager, își imaginează cum ar rezolva sarcinile atribuite.

În opinia noastră, instrumentul IDEF0 va fi util nu numai pentru analiștii de afaceri profesioniști, ci și pentru cei care își analizează direct afacerea și se străduiesc să construiască un sistem de management eficient.


Învață să vezi și să înțelegi structura funcțională a afacerii tale!

În prezent, în Rusia, interesul pentru standardele general acceptate de management din Occident a crescut brusc, cu toate acestea, în practica reală de management, există un moment foarte indicativ. Mulți lideri pot fi încă nedumeriți de întrebarea directă a structura organizationala companiei sau despre schema proceselor de afaceri existente. Cei mai avansați manageri care citesc în mod regulat periodice economice, de regulă, încep să deseneze diagrame ierarhice care să fie ușor de înțeles pentru ei, dar în acest proces ajung, de obicei, rapid la un punct mort. Același lucru se aplică angajaților și managerilor diferitelor servicii și unități funcționale. În majoritatea cazurilor, singurul set de reguli stabilite în conformitate cu care ar trebui să funcționeze o întreprindere este un set de dispoziții individuale și descrierea postului... Cel mai adesea, aceste documente au fost întocmite în urmă cu mai bine de un an, sunt slab structurate și nu sunt interconectate și, ca urmare, adună pur și simplu praf pe rafturi. Deocamdată, o astfel de abordare a fost justificată, întrucât în ​​timpul formării economiei de piață rusești, conceptul de concurență a fost practic absent și nu a fost nevoie specială de a lua în considerare costurile - profitul a fost gigantic. Drept urmare, în ultimii doi ani, am văzut o imagine complet înțeleasă: companiile mari care au crescut la începutul anilor 90 își pierd treptat pozițiile, până la retragerea completă de pe piață. Acest lucru se datorează parțial faptului că întreprinderea nu a implementat standarde de management, conceptul unui model funcțional de activitate și misiune a fost complet absent. Cu ajutorul modelării diferitelor domenii de activitate, este posibilă analiza eficientă a blocajelor în management și optimizarea schemei generale de afaceri. Dar, după cum știți, la orice întreprindere, doar acele proiecte care aduc profit direct sunt de cea mai mare prioritate, prin urmare, de obicei, doar în timpul unei crize tangibile în conducerea companiei, vorbim despre studiul activităților și reorganizare.

La sfârșitul anilor 90, când piața era suficient de competitivă și profitabilitatea întreprinderilor a început să scadă brusc, managerii au simțit dificultăți enorme în încercarea de a optimiza costurile, astfel încât produsele să rămână atât profitabile, cât și competitive. În acest moment s-a manifestat în mod clar nevoia de a avea în fața ochilor un model al activității întreprinderii, care să reflecte toate mecanismele și principiile interconectării diferitelor subsisteme în cadrul unei singure afaceri.

Însăși conceptul de „modelare a proceselor de afaceri” a intrat în viața de zi cu zi a majorității analiștilor concomitent cu apariția pe piață a complexului produse software conceput pentru automatizarea complexă a managementului întreprinderii. Astfel de sisteme implică întotdeauna o profunzime sondaj pre-proiect activitățile companiei. Rezultatul acestui sondaj este o opinie a experților, în care punctele individuale sunt făcute recomandări pentru eliminare " blocaje”În gestionarea activităților. Pe baza acestei concluzii, imediat înainte de implementarea sistemului de automatizare, se realizează așa-numita reorganizare a proceselor de afaceri, uneori destul de gravă și dureroasă pentru companie. Aceasta și, în mod firesc, o echipă care s-a dezvoltat de-a lungul anilor este întotdeauna greu de forțat să „gândească într-un mod nou”. Astfel de anchete complexe ale întreprinderilor sunt întotdeauna sarcini complexe și semnificativ diferite de la caz la caz. Există metodologii și standarde bine încercate pentru rezolvarea unor astfel de probleme de modelare a sistemelor complexe. Aceste standarde includ metodologiile familiei IDEF. Cu ajutorul lor, este posibil să afișați și să analizați în mod eficient modelele activității unei game largi de sisteme complexe în diverse secțiuni. În același timp, amploarea și profunzimea examinării proceselor din sistem sunt determinate de dezvoltatorul însuși, ceea ce permite să nu supraîncărcați modelul creat cu date inutile. V în prezent următoarele standarde pot fi atribuite familiei IDEF:

IDEF0 este o metodologie de modelare funcțională. Cu ajutorul limbajului grafic vizual IDEF0, sistemul în studiu apare dezvoltatorilor și analiștilor sub forma unui set de funcții interdependente (blocuri funcționale - în termeni de IDEF0). De obicei, modelarea IDEF0 este primul pas în învățarea despre orice sistem;

IDEF1 - o metodologie pentru modelarea fluxurilor de informații în cadrul sistemului, care vă permite să afișați și să analizați structura și relațiile acestora;

IDEF1X (IDEF1 Extended) este o metodologie pentru construirea structurilor relaționale. IDEF1X aparține tipului de metodologii „Entitate-relație” (ER - Entitate-Relație) și, de regulă, este utilizat pentru modelarea bazelor de date relaționale legate de sistemul în cauză;

IDEF2 este o metodologie pentru modelarea dinamică a evoluției sistemelor. Datorită dificultăților foarte grave de analiză a sistemelor dinamice, acest standard a fost practic abandonat, iar dezvoltarea acestuia a fost suspendată chiar din stadiul inițial. Cu toate acestea, în prezent există algoritmi și implementările lor de calculator care fac posibilă transformarea unui set de diagrame statice IDEF0 în modele dinamice bazate pe „plase Petri colorate” (CPN - Color Petri Nets);

IDEF3 este o metodologie pentru documentarea proceselor care apar în sistem, care este utilizată, de exemplu, în studiul proceselor tehnologice din întreprinderi. IDEF3 descrie scenariul și fluxul de lucru pentru fiecare proces. IDEF3 are o relație directă cu metodologia IDEF0 - fiecare funcție (bloc funcțional) poate fi reprezentată ca un proces separat prin intermediul IDEF3;

IDEF4 este o metodologie pentru construirea sistemelor orientate pe obiecte. Instrumentele IDEF4 vă permit să afișați vizual structura obiectelor și principiile care stau la baza interacțiunii acestora, permițându-vă astfel să analizați și să optimizați sisteme complexe orientate obiect;

IDEF5 este o metodologie pentru studiul ontologic al sistemelor complexe. Folosind metodologia IDEF5, ontologia unui sistem poate fi descrisă utilizând un vocabular specific de termeni și reguli, pe baza cărora se pot forma afirmații fiabile despre starea sistemului luat în considerare la un moment dat. Pe baza acestor afirmații, se trag concluzii dezvoltare ulterioară sistem și optimizarea acestuia este efectuată.
În acest articol, vom analiza metodologia de modelare funcțională cea mai frecvent utilizată IDEF0.

Istoria standardului IDEF0

Metodologia IDEF0 poate fi considerată următoarea etapă a dezvoltării cunoscutului limbaj grafic pentru descrierea sistemelor funcționale SADT (Structured Analysis and Design Teqnique). Cu câțiva ani în urmă, o mică ediție a cărții cu același nume a fost publicată în Rusia, care a fost dedicată descrierii principiilor de bază ale construirii diagramelor SADT. Din punct de vedere istoric, IDEF0 ca standard a fost dezvoltat în 1981 ca parte a unui vast program de automatizare industrială numit ICAM (Integrated Computer Aided Manufacturing) și a fost propus de Forțele Aeriene ale SUA. Familia de standarde IDEF și-a moștenit denumirea de la numele acestui program (IDEF = ICAM DEFinition). În procesul de implementare practică, participanții la programul ICAM s-au confruntat cu nevoia de a dezvolta noi metode de analiză a proceselor de interacțiune în sistemele industriale. În același timp, pe lângă un set îmbunătățit de funcții pentru descrierea proceselor de afaceri, una dintre cerințele pentru noul standard a fost disponibilitatea unei metodologii eficiente pentru interacțiune în cadrul „analist-specialist”. Cu alte cuvinte, noua metodă trebuia să ofere lucrări de grup la crearea modelului, cu participarea directă a tuturor analiștilor și specialiștilor implicați în proiect.

Ca rezultat al căutării soluțiilor adecvate, s-a născut metodologia de modelare funcțională IDEF0. Din 1981, standardul IDEF0 a suferit câteva modificări minore, majoritatea cu caracter limitativ, iar ultima sa revizuire a fost lansată în decembrie 1993 de Institutul Național pentru Standarde și Tehnologie (NIST) al SUA.

Elemente de bază și concepte ale IDEF0

Limbajul grafic IDEF0 este surprinzător de simplu și armonios. Metodologia se bazează pe patru concepte principale.

Primul este conceptul de casetă de activitate. Un bloc funcțional este reprezentat grafic sub forma unui dreptunghi (a se vedea Fig. 1) și personifică o anumită funcție specifică în cadrul sistemului în cauză. Conform cerințelor standardului, numele fiecărui bloc funcțional trebuie formulat în starea de verb (de exemplu, „produce servicii”, nu „producție de servicii”).

Fiecare dintre cele patru laturi ale unui bloc funcțional are propriul său sens specific (rol), în timp ce:

  • Partea superioară este Control;
  • Partea stângă este setată la „Intrare”;
  • Partea dreaptă este setată la „Ieșire”;
  • Partea inferioară este „Mecanism”.
  • Fiecare bloc funcțional în cadrul unui singur sistem considerat trebuie să aibă propriul număr de identificare unic.

    Figura 1. Bloc funcțional.

    A doua „balenă” a metodologiei IDEF0 este conceptul de arc de interfață (Săgeată). De asemenea, arcurile de interfață sunt adesea numite fluxuri sau săgeți. Arcul de interfață afișează un element de sistem care este procesat de un bloc funcțional sau care afectează în alt mod funcția afișată de acest bloc funcțional.

    Afișarea grafică a arcului interfeței este o săgeată unidirecțională. Fiecare arc de interfață trebuie să aibă propriul nume unic (Etichetă săgeată). După cum prevede standardul, numele trebuie să fie o cifră de afaceri nominală.

    Cu ajutorul arcurilor de interfață, sunt afișate diferite obiecte care, într-un grad sau altul, determină procesele care au loc în sistem. Astfel de obiecte pot fi elemente ale lumii reale (piese, mașini, angajați etc.) sau fluxuri de date și informații (documente, date, instrucțiuni etc.).

    În funcție de care dintre laturi este potrivit acest arc de interfață, se numește „intrare”, „ieșire” sau „control”. În plus, numai blocurile funcționale pot fi „sursa” (începutul) și „chiuveta” (sfârșitul) fiecărui arc funcțional, în timp ce „sursa” poate fi doar partea de ieșire a blocului, iar „chiuveta” poate fi orice dintre cele trei rămase.

    Trebuie remarcat faptul că orice bloc funcțional, conform cerințelor standardului, trebuie să aibă cel puțin un arc de interfață de control și unul de ieșire. Acest lucru este de înțeles - fiecare proces trebuie să urmeze unele reguli (afișate de arcul de control) și trebuie să producă un rezultat (arc de ieșire), altfel nu are sens să îl luăm în considerare.

    Când construiți IDEF0 - diagrame, este important să separați corect arcurile de interfață de intrare de cele de control, ceea ce de multe ori nu este ușor. De exemplu, figura 2 arată blocul funcțional „Procesare piesă”.

    Într-un proces real, lucrătorului care efectuează prelucrarea i se oferă o piesă de prelucrat și instrucțiuni tehnologice pentru prelucrare (sau reguli de siguranță atunci când lucrează cu mașina). Poate fi o greșeală să ne gândim că atât piesa de prelucrat, cât și documentul cu instrucțiuni tehnologice sunt obiecte primite, dar nu este așa. De fapt, în acest proces, piesa de prelucrat este procesată în conformitate cu regulile reflectate în instrucțiunile tehnologice, care ar trebui să fie afișate respectiv de arcul interfeței de control.


    Figura 2.

    Un alt lucru este atunci când instrucțiunile tehnologice sunt procesate de tehnologul șef și le sunt aduse modificări (fig. 3). În acest caz, acestea sunt afișate ca un arc de interfață deja primit, iar obiectul de control este, de exemplu, noi standarde industriale, pe baza cărora se fac aceste modificări.


    Figura 3.

    Exemplele de mai sus subliniază natura aparent similară a arcurilor de interfață de intrare și ieșire, dar există întotdeauna anumite distincții pentru sistemele din aceeași clasă. De exemplu, în cazul luării în considerare a întreprinderilor și organizațiilor, există cinci tipuri principale de obiecte: fluxuri materiale (părți, mărfuri, materii prime etc.), fluxuri financiare (numerar și non-numerar, investiții etc.), document fluxuri (documente comerciale, financiare și organizaționale), fluxuri de informații (informații, date de intenție, instrucțiuni orale etc.) și resurse (angajați, mașini, mașini etc.). În acest caz, în diverse cazuri, tot felul de obiecte pot fi afișate prin arcurile de interfață de intrare și de ieșire, care controlează doar cele legate de fluxurile de documente și informații și numai resursele pot fi afișate prin mecanisme de arce.

    Prezența obligatorie a arcurilor de interfață de control este una dintre principalele diferențe ale standardului IDEF0 față de alte metodologii din clasele DFD (Diagrama fluxului de date) și WFD (Diagrama fluxului de lucru).

    Al treilea concept de bază al standardului IDEF0 este Descompunerea. Principiul descompunerii este utilizat atunci când descompunem un proces complex în funcțiile sale constitutive. În acest caz, nivelul de detaliere al procesului este determinat direct de dezvoltatorul modelului.

    Descompunerea vă permite să reprezentați treptat și structurat modelul de sistem sub forma unei structuri ierarhice a diagramelor individuale, ceea ce îl face mai puțin supraîncărcat și ușor de digerat.

    Modelul IDEF0 începe întotdeauna cu prezentarea sistemului ca întreg - un singur bloc funcțional cu arcuri de interfață care se extind dincolo de zona considerată. O astfel de diagramă cu un bloc funcțional se numește diagramă de context și este notată de identificatorul „A-0”.

    Textul explicativ pentru diagrama contextuală trebuie să indice Scopul construirii diagramei sub forma unei scurte descrieri și să fixeze punctul de vedere (Punct de vedere).

    Definirea și formalizarea scopului dezvoltării unui model IDEF0 este un punct extrem de important. De fapt, obiectivul identifică domeniile relevante din sistemul în studiu pe care ar trebui să se concentreze mai întâi. De exemplu, dacă modelăm activitățile unei întreprinderi pentru a construi în viitor pe baza acestui model Sistem informatic, atunci acest model va diferi semnificativ de cel pe care l-am dezvolta pentru aceeași întreprindere, dar cu scopul de a optimiza lanțurile de aprovizionare.

    Punctul de vedere definește direcția principală de dezvoltare a modelului și nivelul de detaliu necesar. O fixare clară a punctului de vedere vă permite să descărcați modelul, abandonând detaliile și cercetarea elementelor individuale care nu sunt necesare, pe baza punctului de vedere ales pe sistem. De exemplu, modelele funcționale ale aceleiași întreprinderi din punctul de vedere al tehnologului șef și al directorului financiar vor diferi semnificativ în direcția detaliilor acestora. Acest lucru se datorează faptului că, în cele din urmă, directorul financiar nu este interesat de aspectele procesării materiilor prime pe mașinile de producție, iar tehnologul șef nu are nevoie de diagrame desenate. fluxurile financiare... Alegerea corectă a punctului de vedere reduce semnificativ timpul petrecut pentru construirea modelului final.

    În procesul de descompunere, blocul funcțional, care în diagrama contextuală afișează sistemul ca întreg, este forat într-o altă diagramă. Diagrama rezultată a celui de-al doilea nivel conține blocuri funcționale care afișează principalele subfuncții ale blocului funcțional al diagramei contextuale și se numește diagramă Child în raport cu aceasta (fiecare dintre blocurile funcționale aparținând diagramei copil se numește respectiv Child Box ). La rândul său, blocul funcțional părinte se numește bloc părinte în raport cu diagrama copil (Parent Box), iar diagrama căreia îi aparține se numește diagrama părinte (Diagrama părinte). Fiecare dintre funcțiile secundare ale diagramei copil poate fi detaliată în continuare printr-o descompunere similară a blocului funcțional corespunzător. Este important să rețineți că, în fiecare caz de descompunere a unui bloc funcțional, toate arcurile de interfață incluse în acest bloc sau care ies din acesta sunt fixate în diagrama copil. Aceasta realizează integritatea structurală a modelului IDEF0. Principiul descompunerii este clar arătat în Figura 4. Ar trebui să acordați atenție relației dintre numerotarea blocurilor funcționale și a diagramelor - fiecare bloc are propriul număr de serie unic pe diagramă (numărul din colțul din dreapta jos al dreptunghiului) , iar desemnarea în unghi drept indică numărul diagramei copil pentru acest bloc ... Absența acestei desemnări înseamnă că nu există nicio descompunere pentru acest bloc.

    Există adesea cazuri în care arcurile de interfață individuale nu au sens să fie luate în considerare în continuare în diagrame sub un anumit nivel din ierarhie, sau invers - arcurile individuale nu au nicio semnificație practică peste un anumit nivel. De exemplu, un arc de interfață care prezintă un „detaliu” la intrarea în blocul funcțional „Procesare activată” strung”Nu are sens să reflectăm asupra diagramelor nivelurilor superioare - va supraîncărca doar diagramele și le va face dificil de înțeles. Pe de altă parte, este nevoie să scăpați de arcurile de interfață „conceptuale” separate și să nu le detaliați mai adânc decât un anumit nivel. Pentru a rezolva astfel de probleme, standardul IDEF0 prevede conceptul de tunelare. Desemnarea Tunel săgeată sub forma a două paranteze în jurul începutului arcului de interfață denotă faptul că acest arc nu a fost moștenit din blocul funcțional părinte și a apărut (din „tunel”) numai în această diagramă. La rândul său, aceeași denumire în jurul capătului (săgeata) arcului de interfață în imediata vecinătate a blocului receptor înseamnă faptul că în diagrama copil a acestui bloc acest arc nu va fi afișat și nu va fi luat în considerare. Cel mai adesea se întâmplă ca obiectele individuale și arcurile lor de interfață corespunzătoare să nu fie luate în considerare la unele niveluri intermediare ale ierarhiei - în acest caz, ele sunt mai întâi „cufundate în tunel” și apoi, dacă este necesar, „returnate din tunel”.

    Ultimul dintre conceptele IDEF0 este Glosarul. Pentru fiecare dintre elementele IDEF0: diagrame, blocuri funcționale, arce de interfață, standardul existent presupune crearea și menținerea unui set de definiții relevante, cuvinte cheie, narațiuni etc. care caracterizează obiectul afișat de acest element. Acest set se numește glosar și este o descriere a esenței acestui element. De exemplu, pentru un „ordin de plată” al arcului interfeței de control, glosarul poate conține o listă de câmpuri ale documentului corespunzătoare arcului, setul de vize necesar etc. Glosarul completează armonios limbajul grafic, oferind diagramelor informațiile suplimentare necesare.


    Figura 4. Descompunerea blocurilor funcționale.

    Principiile limitării complexității diagramelor IDEF0

    De obicei, modelele IDEF0 transportă informații complexe și concentrate și, pentru a limita congestia și a le face lizibile, limitele de complexitate corespunzătoare sunt adoptate în standardul corespunzător:

    Limitarea numărului de blocuri funcționale din diagramă la trei până la șase. Limita superioară (șase) îl obligă pe proiectant să folosească ierarhii atunci când descrie elemente complexe, iar limita inferioară (trei) asigură că există suficiente detalii pe diagrama corespunzătoare pentru a justifica crearea acesteia;

    Limitarea numărului de arce de interfață adecvate pentru un bloc funcțional (lăsând un bloc funcțional) la patru.
    Desigur, nu este deloc necesar să respectați cu strictețe aceste restricții, totuși, după cum arată experiența, acestea sunt foarte practice în munca reală.

    Disciplina muncii în grup privind dezvoltarea modelului IDEF0

    Standardul IDEF0 conține un set de proceduri care permit unui grup mare de oameni din diferite zone ale sistemului modelat să dezvolte și să convină asupra unui model. De obicei, procesul de dezvoltare este iterativ și constă din următoarele etape condiționale:

    Crearea unui model de către un grup de specialiști în legătură cu diverse domenii ale întreprinderii. Acest grup se numește Autori în ceea ce privește IDEF0. Construirea unui model inițial este un proces dinamic, în timpul căruia autorii întreabă persoanele competente despre structura diferitelor procese. Pe baza dispozițiilor existente, a documentelor și a rezultatelor sondajului, se creează un proiect (Model Draft) al modelului.

    Distribuirea proiectului pentru revizuire, aprobare și comentarii. În această etapă, se discută despre proiectul de model cu o gamă largă de persoane competente (în termeni de cititori IDEF0) din întreprindere. În același timp, fiecare dintre diagramele proiectului de model este criticată și comentată în scris și apoi transferată autorului. La rândul său, autorul este de acord în scris cu critica sau o respinge, subliniind logica luării deciziilor și returnează proiectul revizuit pentru o analiză ulterioară. Acest ciclu continuă până când autorii și cititorii ajung la un consens.

    Aprobarea modelului. Modelul aprobat este aprobat de șeful grupului de lucru în cazul în care autorii modelului și cititorii nu au dezacorduri cu privire la adecvarea acestuia. Modelul final este o viziune consecventă a întreprinderii (sistemului) dintr-un punct de vedere dat și pentru un anumit scop.
    Vizibilitatea limbajului grafic IDEF0 face modelul destul de lizibil pentru persoanele care nu au luat parte la proiectul de creare a acestuia, precum și eficient pentru susținerea de spectacole și prezentări. În viitor, pe baza modelului construit, pot fi organizate noi proiecte menite să facă schimbări în întreprindere (în sistem).

    Caracteristici ale practicii naționale de utilizare a modelării funcționale prin intermediul IDEF0

    V anul trecut interesul pentru metodologiile familiei IDEF crește constant în Rusia. Observ constant acest lucru, analizând statisticile apelurilor către pagina mea personală de internet (http://www.vernikov.ru), care descrie pe scurt principiile de bază ale acestor standarde. În același timp, aș numi interesul pentru standarde precum IDEF3-5 teoretic și destul de practic justificat în IDEF0. De altfel, primele instrumente Case care permit construirea diagramelor DFD și IDEF0 au apărut pe piața rusă încă din 1996, concomitent cu lansarea cărții populare privind principiile modelării în standardele SADT.

    Cu toate acestea, majoritatea directorilor încă consideră aplicarea practică a modelării în standardele IDEF ca o declarație de modă mai degrabă decât o modalitate eficientă de optimizare a sistemului de management al afacerii existent. Cel mai probabil, acest lucru se datorează lipsei pronunțate de informații cu privire la aplicarea practică a acestor metodologii și la tendința indispensabilă a software-ului pentru marea majoritate a publicațiilor.

    Nu este un secret faptul că aproape toate proiectele pentru ancheta și analiza financiară și activitatea economicăîntreprinderile din Rusia sunt într-un fel sau altul legate de construcții sisteme automatizate management. Datorită acestui fapt, standardele IDEF în înțelegerea majorității au devenit inseparabil condiționat de implementare tehnologia Informatiei, deși cu ajutorul lor este uneori posibil să se rezolve eficient chiar și mici probleme locale, literalmente cu ajutorul unui creion și a unei hârtii.

    Atunci când desfășurați proiecte complexe de cercetare a întreprinderii, dezvoltarea de modele în standardul IDEF0 vă permite să afișați vizual și eficient întregul mecanism al activității întreprinderii în contextul dorit. Cea mai importantă este însă colaborarea pe care IDEF0 o oferă. În practica mea, au existat destul de multe cazuri când construcția modelului a fost realizată cu ajutorul direct al angajaților din diferite departamente. În același timp, consultantul le-a explicat principiile de bază ale IDEF0 într-un timp destul de scurt și i-a învățat să lucreze cu aplicația software corespunzătoare. Drept urmare, angajații diferitelor departamente au creat diagrame IDEF ale activităților unității lor funcționale, care urmau să răspundă la următoarele întrebări:

    Ce merge la unitate „la intrare”?

    Ce funcții și în ce secvență sunt îndeplinite în cadrul unității?

    Cine este responsabil pentru fiecare dintre funcții?

    De ce se ghidează executorul atunci când îndeplinește fiecare dintre funcții?

    Care este rezultatul muncii (ieșirii) unității?

    După ce au convenit asupra schițelor de schițe în cadrul fiecărui departament specific, acestea sunt asamblate de consultant într-un schiță de model de întreprindere, în care sunt legate toate elementele de intrare și ieșire. În această etapă, sunt înregistrate toate discrepanțele diagramelor individuale și locurile controversate ale acestora. În plus, acest model trece din nou prin departamentele funcționale pentru o coordonare suplimentară și pentru a face ajustările necesare. Ca urmare, într-un timp destul de scurt și cu implicarea unui minim de resurse umane de la o companie de consultanță (și aceste resurse, după cum știți, sunt foarte scumpe), se obține un model IDEF0 al unei întreprinderi în conformitate cu „ Ca atare ”, și, ceea ce este important, reprezintă o întreprindere cu funcții de angajați care lucrează în ea și cunosc pe deplin toate nuanțele, inclusiv cele informale. În viitor, acest model va fi transferat pentru analiză și procesare analiștilor de afaceri care vor căuta blocaje în managementul companiei și vor optimiza procesele cheie, transformând modelul „În starea actuală” în vizualizarea „Așa cum ar trebui” corespunzătoare. Pe baza acestor modificări, se face o concluzie finală, care conține recomandări pentru reorganizarea sistemului de management.

    Desigur, o astfel de abordare necesită o serie de măsuri organizatorice, în primul rând din partea conducerii întreprinderii chestionate. Acest lucru se datorează faptului că această tehnică implică repartizarea unor angajați responsabilități suplimentare privind dezvoltarea și aplicarea practică a noilor metodologii. Cu toate acestea, în cele din urmă, acest lucru dă roade, deoarece o oră sau două ore suplimentare de muncă ale angajaților individuali pe parcursul mai multor zile pot economisi în mod semnificativ plata serviciilor de consultanță către o companie terță parte (care, în orice caz, va rupe munca ale acelorași angajați cu chestionare și întrebări). În ceea ce privește angajații întreprinderii înșiși, într-un fel sau altul, nu am întâmpinat nicio opoziție exprimată din partea lor.

    Concluzia din toate acestea se poate face după cum urmează: nu este deloc necesar să venim de fiecare dată cu soluții pentru probleme standard. Ori de câte ori vă confruntați cu nevoia de a analiza un anumit sistem funcțional (de la un sistem de proiectare a navei spațiale la procesul de pregătire a unei cine complexe), utilizați metode care au fost dovedite și testate de-a lungul anilor. Una dintre aceste metode este IDEF0, care vă permite să rezolvați probleme de viață complexe cu ajutorul instrumentelor sale simple și ușor de înțeles.

    Cunoscută astăzi nu numai în cercuri înguste, abrevierea IDEF0 este prima metodologie care standardizează activitatea asupra proceselor de afaceri. A fost dezvoltat la mijlocul secolului trecut ca parte a unui proiect aerospațial din Statele Unite și, după ce și-a demonstrat eficacitatea, a devenit un standard federal. La noi în anul 2000, a fost întocmit un document " Metodologia de modelare funcțională IDEF0. Document orientativ Metodologie de modelare funcțională IDEF0 Document de orientare. Ediție oficială. Gosstandart din Rusia RD IDEF0 - 2000. Dezvoltat de Centrul de Cercetare CALS - Tehnologii „Logistică Aplicată”. Adoptat și pus în aplicare prin Rezoluția Gosstandart din Rusia 2000, Moscova”, Dar ca standard nu a fost niciodată aprobat. Deși acest lucru nu a împiedicat această metodologie să devină unul dintre cele mai populare instrumente pentru modelarea grafică a proceselor de afaceri din țara noastră. În acest articol, vă invit să revizuiți modelul IDEF0 și să evaluați relevanța actuală a acestei abordări.

    Concepte de bază și abrevieri

    Să înțelegem puțin despre numele elementelor cheie ale metodologiei. Standardul grafic IDEF0 face parte din metodologia SADT (Structured Analysis and Design Technique). IDEF este o abreviere pentru definiția ICAM, iar ICAM derivă din Integrated Computer Aided Manufacturing, care se traduce prin computerizarea integrată a producției. Metodologia SADT este o întreagă familie de 15 modele diferite, care împreună trebuiau să permită studierea structurii, parametrilor și caracteristicilor sistemelor de producție-tehnice și organizaționale-economice.

    IDEF0 este un model funcțional, care este nucleul tuturor celorlalte structuri, leagă fluxurile de informații și materiale, structura organizațională, acțiunile de control și însăși activitatea companiei. Standardul grafic pentru procesele de modelare se mai numește notație. Adică, notația este un sistem de cerințe și reguli pentru construirea unui model de activitate într-o formă sau alta. Prin urmare, este adecvat să se numească IDEF0 notația care face parte din metodologia SADT.

    Notarea IDEF0 este o tehnică destul de riguroasă care a fost inițial dezvoltată, ca standardele tehnice de proiectare, pentru modelarea manuală. Prin urmare, conține cerințe pentru plasarea săgeților, formatul tuturor elementelor, conținutul cadrului de informații pentru diagrama IDEF0 etc. Deoarece activitățile companiei sunt un sistem complex de acțiuni pe mai multe niveluri, există întotdeauna multe scheme, și este necesară o sistematizare și o navigare fără echivoc prin toate elementele modelului. Acum acest lucru este realizat în principal de sistemele informatice care acceptă modelarea în această notație. Pe teritoriul Rusiei, cele mai faimoase și disponibile astăzi sunt sistemele AllFusion Process Modeler și Business Studio. Plănuiesc să dedic articole separate revizuirii acestor sisteme.

    Bloc funcțional

    Elementul central al modelului IDEF0 este funcția, care este afișată pe diagramă ca bloc funcțional- un dreptunghi, în interiorul căruia acțiunea este indicată sub forma unui substantiv verbal. Acțiunea poate fi foarte diferită la scară - de la activitățile companiei în general și la manipularea specifică în special. Exemple: „Producția și vânzarea de veselă ceramică” și „Utilizarea unui produs”.

    Elemente obligatorii ale blocului funcțional în IDEF0

    Indiferent de scara acțiunilor, toate funcțiile sunt afișate uniform și conțin în mod necesar 4 fluxuri cheie, care sunt atribuite rigid laturilor blocului funcțional:

    • în stânga - intrări sau resurse utilizate pentru îndeplinirea funcției;
    • în dreapta - ieșiri sau rezultate ale executării funcției;
    • pe partea de sus - acțiuni de control care determină cum și câte rezultate trebuie produse;
    • mai jos - mecanisme care reflectă cine și cu ajutorul a ceea ce ar trebui să facă această muncă.

    Această abordare vă permite să economisiți puțin explicațiile din diagrame și să obțineți o ambiguitate în afișarea fluxurilor, ceea ce face ca întregul model să fie subțire.

    Pentru a construi un model funcțional, metodologia IDEF0 necesită respectarea următoarelor reguli.

    1. Intrările sunt resurse care își transferă valoarea completă la ieșiri, adică sunt cheltuite pe crearea unui rezultat în totalitate, iar mecanismele sunt resurse care își transferă valoarea doar parțial (echipamente prin amortizare și oameni prin salarii).
    2. Managementul este un element necesar al modelului, deoarece leagă toate acțiunile de sistemul de reglementări al companiei, indicând în mod clar ce reguli și cerințe trebuie respectate în procesul de îndeplinire a funcției. Adesea acest flux este tratat formal, dar schema își pierde rigoarea și uneori chiar sensul.
    3. Fiecare bloc funcțional trebuie să aibă cel puțin o săgeată pe fiecare parte (deoarece nu poate exista nici o lucrare fără resurse sau rezultate, iar o instrucțiune fără executant sau instrucțiune va fi incompletă).

    Schema considerată este un „element de bază” al abordării IDEF0. Modelarea funcțională implică o tranziție treptată de la general la particular prin descompunere. Descompunerea este „adâncirea” în funcția luată în considerare, împărțind-o în funcții mai mici. În același timp, când funcția de nivel superior este prezentată într-o manieră generalizată și după ce este descompusă, este potrivit să o numim proces.

    Diagrama contextuală

    La cel mai înalt nivel, compania este prezentată ca o „cutie neagră” în care are loc o anumită activitate care traduce intrările la ieșiri. Acest nivel se numește de obicei „”, adică o diagramă care descrie contextul activităților companiei. În plus, diagrama contextuală afișează caracteristicile cheie ale întregului model.

    1. Scopul este o formulare specifică a scopului modelului, prin care acuratețea construcției modelului poate fi verificată în viitor.
    2. Punct de vedere - pe fața căruia este construit modelul, deoarece modelul este întotdeauna dependent de autorul său și de focalizarea atenției. Dacă construim un model general al unei întreprinderi, atunci acesta este de obicei prezentat din punctul de vedere al directorului său.
    3. Tipul modelului indică ce informații sunt afișate pe diagrame. Aici pot fi 2 opțiuni principale: AS IS („așa cum este”) sau TO BE („așa va fi”). Această separare este necesară, deoarece putem construi modele atât pentru analiza activității, cât și pentru transformarea acesteia. Trebuie să fim conștienți în mod clar de ceea ce facem și să transmitem, de asemenea, aceste informații altora.

    Astfel, diagrama contextuală conține în forma cea mai generalizată o descriere a activităților companiei, care este pătrunsă de fluxurile care leagă compania de lumea exterioară. Cred că ar trebui să ne oprim și mai detaliat asupra lor.

    Fluxuri principale

    Experiența a arătat că, în ciuda simplității și formalității aparente a acestui nivel, este adesea necesar să rămânem la el mult timp, deoarece toate rezultatele care sunt semnificative pentru proprietar și piață trebuie reflectate aici. O eroare poate duce la crearea de modele care nu îndeplinesc sarcinile stabilite pentru afacere. Pentru a verifica dacă fluxurile semnificative sunt reflectate, asigurați-vă că toate cele 4 tipuri principale de fluxuri sunt prezente în diagrama dvs.

    1. Material: materiale și componente la intrare și produse terminate la ieșire.
    2. Client: un potențial client la intrare și unul mulțumit la ieșire.
    3. Financiar: la intrare, acestea sunt de obicei investiții, plăți (venituri) clienți, împrumuturi și alte venituri; rezultatul este plăți către furnizori, impozite, plăți de împrumut și profituri.
    4. Informațional: la intrare, toate acestea sunt fluxuri de informații despre mediul extern (condițiile pieței, comportamentul concurenților, inovație tehnologică etc.), iar rezultatul este fluxul de informații pe care compania le comunică despre sine către lume (toate informațiile publicitare, precum și toate tipurile de raportare către autoritățile de reglementare).

    Vă rugăm să rețineți că o companie este un sistem deschis și că nimic nu apare sau nu dispare în ea. O companie este capabilă să transforme fluxurile de intrare numai în fluxurile de ieșire și, dacă o face bine, atunci o suplimentare fluxul de numerar(profit), reflectând, într-un anumit sens, calitatea întregului sistem.

    (faceți clic pentru a mări)

    Este bine dacă evidențiați fiecare dintre aceste tipuri de fluxuri cu propria culoare, astfel încât să puteți distinge cu ușurință mișcarea resurselor și să nu ratați Puncte importante... De exemplu, este adesea posibil să se observe absența unui client în fluxurile companiei, prin urmare, lucrul cu acesta se bazează pe un principiu de resturi - clientul se simte adesea ca un obstacol pentru angajații companiei, ale căror sarcini sunt axate pe procesarea fluxul de documente.

    Săgețile de control pot fi reprezentate doar de un tip de flux - flux de informații, care poate fi împărțit în 2 subspecii. Primul este documentele precum:

    • legi și reglementări;
    • comenzi, comenzi;
    • instrucțiuni și reglementări;
    • planuri;
    • documentația de proiectare etc.

    A doua este informația nedocumentată, care include cel mai adesea cerințele proprietarilor.

    Și, în cele din urmă, mecanisme - există doar 2 tipuri de fluxuri: echipamente (materiale) și interpreți (departamente și oameni). Nu pot exista documente aici, la fel cum nu pot exista persoane pe săgețile de control!

    Modelul oferă numerotare continuă pentru navigație. Diagrama contextuală este numerotată „A-0”. În viitor, fiecare bloc funcțional primește propriul număr, indiferent cât de profundă este descompunerea.

    Descompunere

    După elaborarea fluxurilor diagramei de context, putem trece la descompunere. Trecând la un nivel mai jos, ca și când ar deschide o „cutie neagră”, vedem mai întâi o foaie goală cu săgeți care au fost atașate la blocul funcțional.

    (faceți clic pentru a mări)

    Și aici începe modelarea funcțională efectivă - trebuie să înțelegem ce set de acțiuni pot conecta aceste fluxuri și să ne asigurăm că toate cerințele sunt îndeplinite. Dificultatea constă în faptul că există o mulțime de acțiuni în companie, iar pe diagramă avem dreptul să afișăm nu mai mult de 9 funcții, altfel diagrama va deveni ilizibilă și, în consecință, inutilă.

    Nu este întotdeauna ușor să aranjați activități complexe astfel încât să rămână vizuale, lizibile și în același timp complete. Cel mai adesea, recurg la împărțirea întregii varietăți de procese în blocuri mari, dintre care cele mai semnificative sunt următoarele.

    1. Crearea unui produs (rezultat).
    2. Promovare și vânzare - lucrul cu fluxul de clienți.
    3. Suportul pentru activitățile de creare a produselor sunt procese secundare care sunt necesare pentru a se conforma cerințelor guvernamentale sau pentru a asigura confortul muncii (personal și contabilitate, servicii de transport, curățarea spațiilor etc.).
    4. Crearea fluxurilor de management este activitatea de dezvoltare a soluțiilor de management care vor determina cerințele pentru toate procesele companiei.

    Figura de mai jos prezintă diagrama de descompunere a exemplului nostru.

    (faceți clic pentru a mări)

    În diagramă, procesele trebuie aranjate în diagonală - aceasta se numește principiul dominanței, ceea ce implică aranjarea blocurilor funcționale de la stânga la dreapta și de sus în jos - în ordinea importanței sau în ordine cronologică. Numerotarea blocurilor este aceeași.

    Lucrările ulterioare asupra modelului sunt similare cu primul pas - fiecare bloc funcțional al primului nivel este descompus. Numerotarea blocului va conține numărul primului nivel: A1.1 ... A1n, A2.1 ... A2.n etc.

    Concluzii despre relevanța notației

    În cadrul acestui articol, a fost posibil să se afișeze doar conceptele de bază ale notației IDEF0 folosind un scurt exemplu de IDEF0, prin care, desigur, este dificil să se judece metodologia în ansamblu. Dar destul de multă experiență în utilizarea acestei notații în practică îmi permite să trag următoarele concluzii.

    1. Modelul are un potențial vizual bun, dar, în opinia mea, importanța sa mai mare este în efectul de disciplinare. Regulile și limitările încorporate în metodologie ne obligă să dezvoltăm o atitudine sistematică și strictă față de modele, care are un efect foarte bun asupra calității rezultatului final.
    2. Modelul vă permite să construiți fluxuri de comunicații între lucruri aparent nu puternic conectate: pentru a conecta subsistemele front office și back office cu managementul, ceea ce este mult mai rău pentru alte notații.
    3. Abordarea este simplă și simplă pentru majoritatea participanților la proiect. Construirea și citirea diagramelor în această notație este limitată doar de dorința de a pătrunde în complexitățile fluxurilor de afaceri.

    Unele dintre argumentele de mai sus ne fac să credem că această abordare este cea mai bună și singura pentru o modelare completă a activităților. Dar nu uitați că modelul funcțional este conceput doar pentru nivelul superior de modelare. Utilizarea notației IDEF0 pentru proiectarea lucrărilor la nivel de interpret duce la faptul că diagramele sunt pur ilustrative și pe baza lor este imposibil să se construiască o reglementare sensibilă, deoarece acestea nu conțin:

    • concretizarea evenimentelor de pornire și oprire a procesului;
    • condiții pentru trecerea de la o acțiune la alta;
    • capacitatea de a afișa vizual toate resursele și interpreții fără a supraîncărca diagrama cu săgeți.

    Prin urmare, dacă utilizați această notație pentru sarcinile pentru care este destinată (structurarea activităților de nivel superior), atunci IDEF0 este practic singura notație de astăzi care vă permite să faceți acest lucru în mod semnificativ și precis.

    V management de proiect acest standard de modelare este cel mai aplicabil acolo unde trebuie să legați diferite proiecte sau procese cu fluxuri vizuale. În același timp, modelul grafic va face posibilă distribuirea mai rațională a responsabilității și a resurselor pe sarcini. Logica sarcinilor proiectului, reflectată în diagrame, va ajuta la pregătirea unei calități mai bune plan calendaristic sub forma unei diagrame Gantt.

    6.2. Scopul și compoziția metodologiei SADT (IDEF0)

    Metodologia SADT (Analiza structurată și tehnica de proiectare - metodologia de analiză și proiectare structurală) este un set de metode, reguli și proceduri concepute pentru a construi un model funcțional al unui sistem.

    Dezvoltarea acestei metodologii a fost inițiată de Douglas Ross (SUA) la mijlocul anilor '60. Secolul XX De atunci, analiștii de sistem de la SofTech, Inc. SADT îmbunătățit și folosit pentru a rezolva o gamă largă de probleme. Software de rețea telefonică, diagnosticare, planificare pe termen lung și strategic, producție automatizatăși proiectarea, configurarea sistemului de calculatoare, pregătirea personalului, managementul financiar și al achizițiilor sunt câteva dintre domeniile în care SADT poate fi utilizat în mod eficient. Gama largă de domenii indică versatilitatea și puterea metodologiei SADT. În programul „Integrarea computerului și tehnologii industriale Producția integrată asistată de computer (ICAM) a Departamentului Apărării din SUA a fost recunoscută ca fiind utilă de către SADT. Acest lucru a condus la publicarea unei părți a acestuia, numită în 1981 IDEF0 (Icam DEFinition), ca standard federal a dezvolta software... Sub acest nume, SADT a ajuns să fie folosit de mii de profesioniști din organizațiile militare și industriale. Ultima revizuire a standardului IDEF0 a fost lansată în decembrie 1993. Institutul Național de Standarde și Tehnologie (NIST).

    Această metodologie concurează cu metodele orientate pe fluxul de date (DFD) în descrierea aspectului funcțional al unui sistem informațional. În schimb, IDEF0 permite:

    Descrieți orice sisteme, nu doar sistemele informaționale (DFD este menit să descrie software-ul);

    Creați o descriere a sistemului și a mediului său extern înainte de a defini cerințele finale pentru acesta. Cu alte cuvinte, cu ajutorul acestei metodologii, se poate construi și analiza treptat sistemul chiar și atunci când este încă dificil de imaginat implementarea acestuia.

    Astfel, IDEF0 poate fi aplicat în primele etape ale construirii unei game largi de sisteme. În același timp, poate fi folosit pentru a analiza funcții sisteme existenteși dezvoltarea de soluții pentru îmbunătățirea lor.

    Baza metodologiei IDEF0 este un limbaj grafic pentru descrierea proceselor. Un model în notația IDEF0 este o colecție de diagrame ordonate ierarhic interconectate. Fiecare diagramă este o unitate de descriere a sistemului și este situată pe o foaie separată.

    Modelul (AS-IS, TO-BE sau SHOULD-BE) poate conține 4 tipuri de diagrame [ , ]:

    Diagrama contextuală;

    Diagrame de descompunere;

    Diagramele arborelui nodului;

    Pentru diagrame de expunere (FEO).

    Diagrama contextuală (diagrama de nivel superior), fiind partea de sus a structurii arborescente a diagramelor, arată scopul sistemului (funcția principală) și interacțiunea acestuia cu mediul extern. Fiecare model poate avea o singură diagramă contextuală. După descrierea funcției principale, se efectuează descompunerea funcțională, adică se determină funcțiile care alcătuiesc cea principală.

    Mai mult, funcțiile sunt împărțite în subfuncții și așa mai departe până când se atinge nivelul de detaliu necesar al sistemului în studiu. Diagramele care descriu fiecare astfel de fragment al sistemului sunt numite diagrame de descompunere ... După fiecare sesiune de descompunere, se desfășoară sesiuni de examinare - experții din domeniu indică corespondența proceselor reale cu diagramele create. Inconsistențele constatate sunt eliminate, după care se procedează la detalierea proceselor.

    Diagrama arborelui nodului arată dependența ierarhică de funcții (lucrări), dar nu și relația dintre ele. Pot exista mai multe dintre ele, deoarece arborele poate fi construit la o adâncime arbitrară și dintr-un nod arbitrar.

    Diagramele expunerii sunt construite pentru a ilustra fragmente individuale ale modelului pentru a afișa un punct de vedere alternativ asupra proceselor care au loc în sistem (de exemplu, din punctul de vedere al managementului organizației).

    6.3. Elemente ale notației grafice IDEF0

    Metodologia IDEF0 și-a găsit acceptarea și aplicarea pe scară largă, în principal datorită notației grafice simple utilizate pentru a construi modelul. Principalele componente ale modelului sunt diagrame. Acestea afișează funcțiile sistemului sub formă de dreptunghiuri, precum și conexiunile dintre acestea și mediul extern prin intermediul săgeților. Folosirea doar a două elemente grafice (dreptunghi și săgeată) vă permite să explicați rapid regulile și principiile construirii diagramelor IDEF0 pentru persoanele care nu sunt familiare cu această metodologie. Acest avantaj vă permite să vă conectați și să activați activitatea clientului în descrierea proceselor de afaceri folosind un limbaj grafic formal și vizual.

    Următoarea figură prezintă elementele de bază ale notației grafice IDEF0.

    Orez. 6.1. Elemente ale notației grafice IDEF0

    Dreptunghiul reprezintă muncă (proces, activitate, funcție sau sarcină) , care are un obiectiv fix și duce la un rezultat final. Numele postului trebuie să exprime acțiunea (de exemplu, „Fabricarea unei piese”, „Calculul vitezei admise”, „Formarea listei casei centralizate numărul 3”).

    Interacțiunea lucrărilor dintre ei și lumea exterioară este descrisă sub formă de săgeți. IDEF0 distinge 5 tipuri de săgeți :

    - Intrare (Introducere în limba engleză) - material sau informații care sunt utilizate și transformate prin muncă pentru a obține un rezultat (ieșire). Conectarea răspunde la întrebarea „Ce trebuie procesat?” Introducerea poate fi fie un obiect material (materii prime, o parte, un bilet de examen), fie unul care nu are contururi fizice clare (o interogare către baza de date, o întrebare de la un profesor). Se presupune că lucrarea poate să nu aibă săgeți de intrare. Săgețile de intrare sunt întotdeauna trase ca intrând în partea stângă a lucrării;

    - Control (Control în limba engleză) - date de control, reglementare și reglementare care ghidează activitatea. Departamentul răspunde la întrebarea „În conformitate cu ce se lucrează?” Managementul influențează opera, dar nu este transformat de aceasta, adică acționează ca o limitare. Ca management, pot exista reguli, standarde, reglementări, prețuri, instrucțiuni orale. Săgețile de control sunt desenate ca parte a feței superioare a lucrării. Dacă, atunci când construiți o diagramă, apare întrebarea cum să desenați corect o săgeată de sus sau spre stânga, atunci se recomandă să o desenați ca intrare (săgeată în stânga);

    - ieșire (Ieșire în limba engleză) - material sau informații care reprezintă rezultatul muncii. Rezultatul răspunde la întrebarea „Care este rezultatul muncii?” Rezultatul poate fi fie un obiect material (o piesă, o mașină, documente de plată, o declarație), fie unul necorporal (prelevarea de date dintr-o bază de date, un răspuns la o întrebare, o indicație verbală). Săgețile de ieșire sunt extrase din partea dreaptă a lucrării;

    - mecanism (Mecanism eng.) - resurse care execută lucrări. Mecanismul răspunde la întrebarea „Cine face treaba sau cu ce mijloace?” Mecanismul poate fi personalul întreprinderii, studentul, mașina, echipamentul, programul. Săgețile mecanismului sunt trase ca intrând pe marginea inferioară a lucrării;

    - apel (Apel în limba engleză) - săgeata indică faptul că o parte din lucrări sunt efectuate în afara blocului în cauză. Săgețile de ieșire sunt trase ca venind de la marginea de jos a lucrării.

    6.4. Tipuri de legături între locuri de muncă

    După determinarea compoziției funcțiilor și a relațiilor dintre acestea, apare întrebarea cu privire la compoziția lor corectă (asocierea) în module (subsisteme). Aceasta implică faptul că fiecare funcție separată trebuie să o rezolve, strict o sarcină specifică... În caz contrar, este necesară descompunerea suplimentară sau separarea funcțiilor.

    Atunci când combinați funcții în subsisteme, este necesar să depuneți eforturi pentru ca conectivitatea internă (între funcțiile din cadrul unui modul) să fie cât mai puternică și externă (între funcțiile incluse în diferite module) cât mai slabă posibil. Pe baza semanticii legăturilor metodologice, introducem o clasificare a legăturilor între funcții (lucrări). Această clasificare este o extensie. Tipurile de obligațiuni sunt listate în ordinea importanței descrescătoare (puterea de legare). În exemplele citate, liniile îngroșate evidențiază funcțiile între care există tipul de conexiune considerat.

    1. Relația ierarhică (relația „parte” - „întreg”) are loc între funcția și subfuncțiile din care constă.

    Orez. 6.2. Relația ierarhică

    2. Comunicare de reglementare (control, subordonat) reflectă dependența unei funcții de alta, când ieșirea unui job este trimisă pentru a controla alta. Funcția din care pleacă controlul ar trebui considerată de reglementare sau de control și în care intră - subordonată. Distinge legătură de control direct atunci când controlul este transferat de la o lucrare de nivel superior la una de nivel inferior (Fig.6.3) și feedback-ul managementului când controlul este transferat din aval în amonte (Fig. 6.4).

    3. Comunicare funcțională (tehnologică) apare atunci când ieșirea unei funcții servește ca intrare la următoarea funcție. Din punctul de vedere al fluxului de obiecte materiale, această relație arată tehnologia (secvența de lucru) a procesării acestor obiecte. Distinge conexiune directă la intrare când ieșirea este transferată de la lucrarea de nivel superior la cea de nivel inferior (Fig. 6.5) și feedback de intrare când ieșirea este transferată din aval în amonte (Figura 6.6).



    Orez. 6.5. Conexiune directă la intrare Orez. 6.6. Feedback de intrare

    4. Comunicarea consumatorilor apare atunci când ieșirea unei funcții servește ca mecanism pentru următoarea funcție. Astfel, o funcție consumă resursele generate de cealaltă.

    Orez. 6.7. Comunicarea consumatorilor

    5. Legătură logică observat între funcții logic omogene. Astfel de funcții, de regulă, îndeplinesc aceeași lucrare, dar în moduri diferite (alternative) sau folosind date inițiale (materiale) diferite.

    Orez. 6.8. Legătură logică

    6. Comunicarea colegială (metodică) are loc între funcții al căror algoritm de funcționare este determinat de același control. Un analog al unei astfel de comunicări este munca comună a angajaților unui departament (colegi), subordonat șefului, care dă instrucțiuni și comenzi (semnale de control). O astfel de conexiune apare și atunci când algoritmii pentru funcționarea acestor funcții sunt determinați de același suport metodologic (SNIP, GOST, materiale oficiale de reglementare etc.), care servește ca management.

    Orez. 6.9. Conexiune metodică

    7. Link de resurse apare între funcții care utilizează aceleași resurse pentru munca lor. Funcțiile dependente de resurse, în general, nu pot rula simultan.

    Orez. 6.10. Link de resurse

    8. Comunicarea informațională are loc între funcții folosind aceleași informații ca intrarea.

    Orez. 6.11. Comunicarea informațională

    9. Conexiune temporară apare între funcții care trebuie executate simultan înainte sau concomitent după o altă funcție.

    În plus față de cazurile indicate în figură, această conexiune are loc și între alte combinații de control, intrare și mecanism care intră într-o funcție.

    Orez. 6.12. Conexiune temporară

    10. Conexiune aleatorie apare atunci când există puțină sau deloc conexiune specifică între funcții.

    Orez. 6.13. Conexiune aleatorie

    Dintre tipurile de legături de mai sus, cea mai puternică este legătura ierarhică, care, de fapt, determină combinația de funcții în module (subsisteme). Legăturile de reglementare, funcționale și de consum sunt oarecum mai slabe. Funcțiile cu aceste legături sunt de obicei implementate într-un subsistem. Conexiunile logice, colegiale, de resurse și informaționale sunt printre cele mai slabe. Funcțiile care le posedă, de regulă, sunt implementate în diferite subsisteme, cu excepția funcțiilor logic omogene (funcții conectate prin conexiune logică). Conexiunea temporară indică o dependență slabă a funcțiilor între ele și necesită implementarea lor în module separate.

    Astfel, atunci când combinați funcții în module, primele cinci tipuri de legături sunt cele mai de dorit. Funcțiile asociate cu ultimele cinci link-uri sunt cel mai bine implementate în module separate.

    IDEF0 are convenții (reguli și linii directoare) pentru crearea de diagrame pentru a ușura citirea și examinarea modelului [,]. Unele dintre aceste reguli sunt acceptate CASE automat, altele trebuie aplicate manual.

    1. Înainte de a construi un model, este necesar să decideți ce model (e) ale sistemului vor fi construite. Aceasta implică definirea tipului AS-IS, TO-BE sau SHOULD-BE, precum și definirea poziției din care este construit modelul. „Punctul de vedere” este cel mai bine gândit ca un loc (poziție) al unei persoane sau al unui obiect, în care trebuie să stăm pentru a vedea sistemul în acțiune. De exemplu, atunci când construiți un model pentru funcționarea unui magazin alimentar, puteți alege un vânzător, casier, contabil sau director dintre posibilii solicitanți din punctul de vedere al cărui sistem este luat în considerare. De obicei, se alege un punct de vedere, care acoperă cel mai complet toate nuanțele funcționării sistemului și, dacă este necesar, diagramele FEO sunt construite pentru unele diagrame de descompunere, afișând un punct de vedere alternativ.

    2. Diagrama contextuală afișează un bloc care arată scopul sistemului. Este recomandat să afișeze 2–4 săgeți care intră și ies din fiecare parte.

    3. Numărul de blocuri de pe diagramele de descompunere este recomandat în intervalul 3-6. Dacă există două blocuri în diagrama de descompunere, atunci, de regulă, nu are sens. Cu un număr mare de blocuri, diagrama devine suprasaturată și dificil de citit.

    4. Blocurile de pe diagrama de descompunere trebuie aranjate de la stânga la dreapta și de sus în jos. Acest aranjament vă permite să reflectați mai clar logica și secvența de lucru. În plus, traseele săgeții vor fi mai puțin confuze și vor avea un număr minim de intersecții.

    5. Absența săgeților de control și de intrare pentru funcție nu este permisă. Aceasta înseamnă că lansarea acestei funcții nu este controlată și poate avea loc în orice moment arbitrar sau niciodată.

    Orez. 6.14. Funcție fără control și intrare

    Un bloc cu numai control poate fi vizualizat ca un apel într-un program al unei funcții (procedură) fără parametri. Dacă blocul are o intrare, atunci este echivalent cu apelarea unei funcții cu parametri din program. Astfel, un bloc fără control și intrare este echivalent cu o funcție care nu este apelată niciodată la executare în program.

    În fig. 6.7–6.12, afișând fragmente de diagrame IDEF0, există blocuri fără intrare și control. Acest lucru nu trebuie privit ca o eroare, deoarece implică faptul că una dintre aceste săgeți trebuie să fie.

    6. Fiecare bloc trebuie să aibă cel puțin o priză.

    Orez. 6.15. Fără funcție de ieșire

    Lucrările fără rezultate nu au sens și nu trebuie modelate. O excepție este lucrarea afișată în modelul AS-IS. Prezența lor indică ineficiența și imperfecțiunea proceselor tehnologice. În modelul TO-BE, aceste lucrări ar trebui să lipsească.

    7. Când construiți diagrame, ar trebui să minimizați numărul de intersecții, bucle și rotații de săgeți.

    8. Feedback-urile și iterațiile (acțiuni ciclice) pot fi descrise folosind arcuri înapoi. Feedback-ul la intrare este tras de bucla „inferioară”, feedback-ul la comandă - de „superior” (vezi Fig. 6.4 și 6.6).

    9. Fiecare bloc și fiecare săgeată din diagrame trebuie să aibă un nume. Este permisă utilizarea săgeților de ramificare (descompunere) sau fuzionare (compoziție). Acest lucru se datorează faptului că aceleași date sau obiecte generate de un job pot fi utilizate în mai multe alte joburi simultan. În schimb, datele și obiectele aceleași sau omogene generate de diferite lucrări pot fi utilizate într-un singur loc.

    Orez. 6.16. Săgeți de ramificare

    În acest caz, este permisă atribuirea de nume calificate diferitelor ramuri ale săgeții după ramificare (înainte de îmbinare). Dacă o ramură după ramură nu este denumită, atunci numele acesteia este considerat a corespunde cu numele săgeții înregistrat înaintea ramurii.

    Deci, în fig. 6.16 comenzile incluse în blocurile „Fabricarea pieselor” și „Asamblarea produsului” au semnificații clarificatoare și sunt parte din Mai mult management general„Planuri”. Toate desenele sunt utilizate pentru funcționarea blocului „Controlul calității”.

    Nu este permisă trasarea săgeților în diagramă atunci când acestea nu sunt denumite înainte și după ramificare. În fig. 6.17 săgeata inclusă în blocul „Generarea listelor standard” nu are un nume înainte și după ramificare, ceea ce reprezintă o eroare.

    Orez. 6.17. Denumirea greșită a săgeții

    10. Atunci când construiți diagrame pentru o mai bună lizibilitate, se poate utiliza mecanismul de tunelare a săgeților. De exemplu, pentru a nu aglomera diagramele nivelurilor superioare (părinte) cu detalii inutile, în diagramele de descompunere începutul arcului este plasat în tunel.

    Orez. 6.18. Săgeți de tunel

    V acest exemplu la construirea unui model de dirijare Petrecerea de Anul Nou mecanismul „două axe” nu va fi afișat pe diagramele nivelurilor superioare, atunci când citiți care poate apărea o întrebare corectă: „De ce avem nevoie de două axe la petrecerea de Anul Nou?”

    La fel, puteți tunela cu obiectivul opus - nepermițând săgeții să apară pe diagrame de nivel inferior. În acest caz, parantezele sunt plasate la capătul săgeții. În diagrama contextuală (a se vedea Fig. 6.21), mecanismul "Inginerul de service al căilor" este tunelat, care este inclus în blocul "Determinarea vitezelor permise". Această decizie a fost luată, deoarece inginerul este direct implicat în toate lucrările afișate pe diagrama de descompunere a acestui bloc (vezi Fig. 6.22). Pentru a nu arăta această conexiune și a nu aglomera diagrama de descompunere, săgeata a fost tunelată.

    11. Toate săgețile care intră și ies din bloc, atunci când construiți o diagramă de descompunere pentru acesta, trebuie să fie afișate pe acesta. Excepția este săgețile tunelate. Numele săgeților glisate pe diagrama de descompunere trebuie să se potrivească cu numele afișate în diagrama de nivel superior.

    12. Dacă două săgeți rulează paralel (începeți de la aceeași fațetă a unei lucrări și se termină pe aceeași fațetă a celeilalte lucrări), atunci, dacă este posibil, acestea ar trebui combinate și numite un singur termen.

    Orez. 6.19. Combinarea linkurilor

    13. Fiecare bloc din diagrame trebuie să aibă propriul număr. Pentru a indica poziția oricărei diagrame sau blocuri în ierarhie, se utilizează numerele diagramei. Blocul de pe diagrama de nivel superior este notat cu 0, blocurile de pe diagramele de nivel secundar - cu numere de la 1 la 9 (1, 2, ..., 9), blocurile de pe al treilea nivel - cu două numere , primul dintre care indică numărul blocului detaliat din diagrama părinte și al doilea număr de bloc în ordine pe diagrama curentă (11, 12, 25, 63) etc. Diagrama contextuală are denumirea „A - 0 ", diagrama de descompunere a primului nivel este" A0 ", diagramele de descompunere ale nivelurilor următoare constau din litera" A "urmată de numărul blocului care trebuie descompus (de exemplu," A11 "," A12 "," A25 "," A63 "). Figura prezintă un arbore tipic al diagramei (diagrama arborelui nodului) cu numerotare.

    Orez. 6.20. Ierarhia graficelor

    În instrumentele CASE moderne, mecanismele de numerotare a lucrărilor sunt acceptate automat. Instrumentele CASE oferă, de asemenea, construcția automată a diagramelor arborelui nodurilor care conțin doar legături ierarhice. Partea de sus a unei astfel de diagrame poate fi orice nod (bloc) și poate fi trasată la orice adâncime.

    6.6. Un exemplu de construire a unui model IDEF0 pentru un sistem de determinare a vitezei admise

    Calculul vitezei admise a trenului este o sarcină laborioasă de inginerie. Când un tren trece de orice secțiune viteza reală deplasarea trenului nu trebuie să depășească maximul permis. Această viteză maximă admisibilă este stabilită pe baza experienței de funcționare și a testelor special realizate asupra dinamicii mișcării și impactului asupra liniei materialului rulant. Nedepășirea acestei viteze garantează siguranța circulației trenurilor, condiții confortabile pentru pasageri etc. Acestea sunt determinate în funcție de tipul materialului rulant (marca locomotivei și tipul de vagoane), de parametrii suprastructurii (precum șine, balast, traverse ) și plan (curbe de rază, curbe de tranziție, elevația șinei exterioare etc.). De regulă, pentru a stabili vitezele admise, este necesar să se determine cel puțin două viteze (pe linii drepte) și cinci (în curbe), dintre care se selectează viteza finală admisibilă, ca fiind cea mai mică dintre toate calculate. Calculul acestor viteze este reglementat prin Ordinul Ministerului Căilor Ferate din Rusia nr. 41 din 12 noiembrie 2001 „Standarde pentru viteza admisibilă a materialului rulant pe șinele de cale ferată cu ecartament de 1520 (1524) mm ale Transportului Feroviar Federal”.

    După cum sa menționat, construirea modelului IDEF0 începe cu reprezentarea întregului sistem ca o componentă simplă (diagramă contextuală). Această diagramă arată scopul (funcția principală) a sistemului și datele necesare de intrare și ieșire, informații de control și de reglementare și mecanisme.

    Diagrama contextuală pentru problema determinării vitezelor admise este prezentată în Figura 6.21. Pentru a construi modelul, a fost utilizat produsul BPwin 4.0 de la Computer Associates.


    Orez. 6.21. Diagrama contextuală a sistemului pentru determinarea vitezelor admise (metodologia IDEF0)

    La fel de informații generale, pe baza cărora se efectuează determinarea vitezelor admise, se utilizează:

    Date despre proiectul unei noi linii sau ale unui proiect de reconstrucție (conține toate informațiile necesare pentru implementarea proiectului, și anume, kilometrajul, axele punctelor separate, planul liniei etc.);

    Profil longitudinal detaliat (conține informații similare cu cele discutate mai sus);

    Pașaportul distanței pistei (conține informații similare cu cele discutate mai sus, precum și informații despre structura superioară a pistei (VSP));

    Date privind rezultatele anchetei planului de cale de către autovehiculul care măsoară calea;

    Lista elevațiilor șinei exterioare în curbe (conține informații despre planul căii).

    Unele dintre informațiile originale pot fi preluate de la diferite surse... În special, informații despre plan (parametrii curbelor) pot fi preluate din proiectul unei linii noi sau a unui proiect de reconstrucție, un profil longitudinal detaliat, un pașaport al distanței de cale etc.

    Date de control sunt:

    Instrucțiuni ale șefului serviciului de cale ferată al drumului sau al Departamentului de căi ferate și structuri ale Căilor Ferate Ruse pentru calcul;

    Ordinul nr. 41, care conține informații normative și de referință, procedura și formulele de determinare a vitezei admise;

    Informații despre circulația actuală sau planificată a trenurilor (date privind mărcile locomotivelor circulante și tipurile de mașini utilizate);

    Informații despre reparațiile planificate ale căii, reconstrucția și reorganizarea structurilor și dispozitivelor.

    Rezultatul funcționarea sistemului ar trebui să fie:

    Foi de viteze admise, care conțin toate tipurile de viteze calculate și care vă permit să stabiliți motivul limitării acestora;

    Buletinul Ordinului Capului de Drum privind stabilirea vitezei admise pe șine și puncte separate (Ordinul „N”) în conformitate cu forma adoptată pe drum. Ordinul „N” aprobat stabilește oficial vitezele admise ale trenului;

    Formularele standard nr. 1, 1a și 2, care conțin vitezele admise planificate pentru dezvoltarea orarului trenului.

    Vitezele conținute în comanda „H” și formularele standard pot diferi de cele calculate și prezentate în foile de viteze admise. Acest lucru se datorează faptului că acestea reflectă limitele de viteză nu numai prin proiectarea materialului rulant, parametrii și curbele VSP, ci și prin starea dispozitivelor și structurilor (deformarea patului rutier, înclinarea suporturilor rețelei de contact etc.) .). În plus, acestea sunt ajustate ținând seama de reparațiile planificate ale șinelor, reconstrucția și reorganizarea structurilor și dispozitivelor etc.

    Odată construită, diagrama contextuală este detaliată folosind o diagramă de descompunere de primul nivel. Această diagramă arată funcțiile sistemului care trebuie implementate în cadrul funcției principale. Diagrama pentru care s-a efectuat descompunerea, în raport cu diagramele care o detaliază, se numește mamă ... Se numește diagrama de descompunere în raport cu părintele filială .

    Diagrama de descompunere a primului nivel pentru problema luată în considerare este prezentată în Figura 6.22. De regulă, la construirea unei diagrame de descompunere, funcția originală (care trebuie descompusă) este împărțită în 3-8 subfuncții (blocuri). În acest caz, se recomandă ca blocurile de pe diagrama de descompunere să fie plasate de la stânga la dreapta, de sus în jos, astfel încât succesiunea și logica interacțiunii subfuncțiilor să fie mai bine vizibile.


    Orez. 6.22. Diagrama de descompunere de nivel 1 (metodologia IDEF0)

    Succesiunea funcțiilor de efectuare pentru rezolvarea problemei luate în considerare este următoarea:

    Introducerea și corectarea informațiilor de referință și a datelor pe secțiuni de drum (blocurile 1 și 2);

    Pregătirea unei sarcini pentru calcul (blocul 3). Acesta indică pentru ce secțiune și cale, precum și marca locomotivei și tipul de vagoane, trebuie efectuat calculul;

    Calculul vitezei admisibile în conformitate cu procedura și formulele specificate în Ordinul nr. 41 (blocul 4). Informațiile inițiale sunt datele de-a lungul traseului secțiunii (plan, structura superioară a pistei etc.) și standardele selectate pe baza sarcinii pentru calcul;

    Formarea listelor de viteze admise (blocul 5). Pe baza rezultatelor calculului, sunt create mai multe tipuri de documente de ieșire, care, pe de o parte, permit identificarea motivului limitelor de viteză, pe de altă parte, acționează ca bază pentru pregătirea documentelor reglementate;

    Formarea și pregătirea proiectului de ordine „N” și a declarațiilor standard (blocurile 6 și 7).

    După construirea diagramei de descompunere de primul nivel, sunt construite diagrame separate (diagrame de descompunere de nivel doi) pentru funcțiile indicate pe ea. Apoi procesul de descompunere (schemele de construcție) continuă până când detaliile suplimentare ale funcțiilor își pierd sensul. Pentru fiecare funcție atomică care descrie o operație elementară (adică o funcție care nu are o diagramă de descompunere), se întocmește o specificație detaliată care îi definește caracteristicile și algoritmul de implementare. Diagramele de flux ale algoritmilor pot fi utilizate pentru a completa specificația. Astfel, procesul de modelare funcțională constă în construirea treptată a unei ierarhii a funcțiilor.

    6.7. Coduri ICOM

    Săgețile care intră și ies din bloc în diagrama de nivel superior sunt aceleași cu săgețile care intră și ies din diagrama de nivel inferior, deoarece blocul și diagrama reprezintă aceeași parte a sistemului (vezi Fig. Și ). În consecință, limitele funcției de nivel superior sunt aceleași cu limitele diagramei de descompunere.

    Coduri ICOM (acronim pentru Input, Control, Output și Mechanism) sunt pentru identificarea săgeților de graniță. Codul ICOM conține un prefix corespunzător tipului de săgeată (I, C, O sau M) și un număr de ordine (vezi figura).

    Descrierea diagramelor procesului de afaceri "Contabilitatea echipamentelor informatice ale întreprinderii"

    Descrierea diagramei IDEF0

    Pentru a construi un proces de afaceri, a fost utilizată o diagramă IDEF0. Metodologia IDEF0 prescrie construirea unui sistem ierarhic de diagrame - descrieri unice ale fragmentelor de sistem. În primul rând, se realizează o descriere a sistemului ca întreg și a interacțiunii acestuia cu lumea exterioară (diagramă contextuală). Au fost construite trei nivele ale diagramei:

    1. Contextual

    2. Descompunerea funcțională

    Figura 1 - Diagrama contextuală „Contabilitatea echipamentelor informatice ale întreprinderii”

    Figura 1 prezintă o diagramă contextuală a procesului de afaceri „Contabilitatea echipamentelor informatice ale întreprinderii”. Afișează sistemul în ansamblu și interacțiunea sa cu principalele fluxuri externe de informații.

    Săgețile sunt indicate în diagrama contextuală.

    Tipuri de săgeți:

    Introducere (materiale de intrare: computere și accesorii)

    Ieșire (ieșirea este un raport)

    Săgețile de control sunt documente și manageri

    Săgețile mecanismelor sunt angajați și echipamente

    Informații de intrare pentru procesare:

    Calculatoare - PC-uri (computere personale) situate în întreprindere

    Componente - materiale necesare pentru actualizarea computerelor (plăci video, plăci de bază, procesoare, carcase, surse de alimentare, module de memorie)

    Fluxuri de ieșire:

    Raport - un raport gata făcut despre contabilitatea echipamentelor informatice ale întreprinderii

    Controale de intrare:

    Reguli - condiții care trebuie îndeplinite pentru a atinge obiectivul.

    Comenzi - sarcina atribuită întreprinderii (să țină evidența echipamentelor informatice la întreprindere utilizând anumite sisteme de informații)

    Managerii sunt directori și manageri generali ai întreprinderii.

    Resurse de intrare:

    PC - calculatoare cu ajutorul cărora se realizează contabilitatea.

    Angajații sunt specialiști care îndeplinesc instrucțiunile atribuite de conducere. După construirea modelului conceptual, s-a efectuat o descompunere funcțională - sistemul este împărțit în subsisteme și fiecare subsistem este descris separat (diagrame de descompunere).

    Figura 2 prezintă o descompunere funcțională a patru joburi.


    Figura 2 - Descompunerea funcțională „Contabilitatea echipamentelor informatice ale întreprinderii”

    Au fost identificate următoarele tipuri de lucrări:

    1) Înregistrarea livrărilor - procesul în care ID-ul este atribuit produsului, trimis la depozit, depozit și informații despre produs sunt introduse în program.

    Înregistrarea lucrărilor de bunuri include șapte săgeți de graniță (intrare, control, mecanism) și o săgeată internă (conexiune prin intrare).

    Comunicare săgeată la intrarea între lucrări Înregistrarea livrărilor și Întreținerea computerului (computer);

    Săgețile de intrare, ieșire, control se repetă în lucrările ulterioare.

    2) Întreținerea computerelor - procesul în care are loc asamblarea, repararea și modernizarea computerelor.

    Lucrarea de întreținere a computerului include patru săgeți de graniță (intrare, control, mecanism, ieșire) și mai multe săgeți interne (comunicare de intrare, feedback de intrare).

    Controlul săgeților - reguli, ordine, lider;

    Conexiune săgeată la intrarea dintre lucrările Întreținerea și plasarea computerului (introducerea datelor în baza de date), între lucrările Întreținerea și raportarea computerului (introducerea datelor în baza de date);

    3) Plasare - procesul în care are loc plasarea computerelor în birouri (birouri).

    Controlul săgeților - reguli, ordine, lider;

    Mecanismul săgeții - angajați;

    Legătura săgeată la intrare între Spreading și Reporting (atribuirea unui id);

    4) Întocmirea unui raport - etapa finală a procesului contabil, care constă în rezumarea totalelor obținute prin efectuarea datelor anterioare ale contabilității curente.

    Apoi, fiecare subsistem este împărțit în descompuneri mai mici și așa mai departe, până când se atinge gradul de detaliu dorit.


    Figura 3 este o diagramă care prezintă mai detaliat activitatea Achizițiilor.

    Ca urmare a detaliilor, funcțiile principale au fost evidențiate. Secțiunea „Înregistrarea livrărilor” include șapte săgeți principale (intrare, ieșire, control, mecanism).

    Intrare săgeată - computere și accesorii;

    Săgețile de control sunt reguli, ordine și un lider. Săgeți de furcat;

    Săgeți mecanism, ramificare - PC, angajați;

    Săgețile de intrare, control, mecanisme sunt repetate în toate lucrările.

    1) Alocarea numerelor - atribuirea numerelor individuale către computere și accesorii.

    Săgeți de intrare - computere și accesorii. Calculatoarele săgeți sunt repetate în lucrările ulterioare, cu excepția compilării raportului;

    Săgeți de control - reguli, ordine și lider;

    Săgeți mecanism - PC și angajați;

    Legătură săgeată la intrarea dintre lucrări Atribuirea unui număr și Expedierea mărfurilor către un depozit (transfer), între Atribuirea unui număr și Punerea la balanță (intrarea în bază);

    2) Expedierea mărfurilor la depozit - trimiterea mărfurilor cu numărul atribuit la depozit.

    Săgeată de ieșire - computer;

    Săgeți de control - reguli, ordine și lider.

    Legătură săgeată la intrarea dintre lucrările „Trimiterea mărfurilor la depozit” și „Punerea în bilanț” (cantitate);

    3) Echilibrare - introducerea informațiilor într-un computer.

    Săgeți de control - reguli, ordine și lider;

    Săgeți mecanism - PC și angajați;


    Figura 4 este o diagramă care detaliază întreținerea computerului mai detaliat.

    Ca urmare a detaliilor, au fost evidențiate principalele funcții îndeplinite în procesul de întreținere a computerului.

    Lucrările de întreținere a computerului includ 4 săgeți de delimitare (intrare, ieșire, control, mecanism). Săgeți interne (feedback de intrare, comunicare de intrare).

    1) Asamblarea computerelor - configurarea computerelor pentru comenzi individuale ale managerilor.

    Săgeată de conectare - calculatoare;

    Săgeți de control - reguli, ordine și lider;

    Săgeți mecanism - angajați;

    Legătură săgeată la intrarea dintre lucrări: „Asamblarea computerelor” și „Repararea computerelor” (computer);

    2) Repararea computerelor - asamblarea computerelor aprobate pentru îmbunătățire.

    Săgeată de conectare - calculatoare;

    Săgeată de ieșire - intrare în bază;

    Săgeți de control - reguli, ordine și lider;

    Săgeți mecanism - angajați;

    Săgețile de intrare, ieșire, control, mecanism sunt ramificate;

    Legătură săgeată la intrarea dintre lucrări: „Repararea computerului” și „Upgrade” (accesorii);

    3) Upgrade - îmbunătățire, îmbunătățire, actualizare a computerului.

    Săgeată de ieșire - intrare în bază;

    Săgeți de control - reguli, ordine și lider;

    Săgeți mecanism - angajați;

    Săgețile de control, mecanismul sunt ramificate;


    Figura 5 prezintă diagrama de raportare în detaliu. Descompunerea muncii. Raportarea include 4 săgeți de graniță (intrare, ieșire, control, mecanisme). Săgeți interne (feedback de intrare, comunicare de intrare).

    Ca rezultat al muncii, au fost derivate următoarele funcții:

    1) Colectarea datelor - colectarea informațiilor pentru analiză și luarea deciziilor.

    Introduceți săgeata - atribuirea id-ului;

    Săgeți de control - reguli, ordine și lider;

    Săgețile de intrare, control, mecanism sunt ramificate;

    Legătură săgeată la intrarea dintre joburi: Colectarea datelor și validarea datelor (înregistrări);

    2) Verificarea datelor - verificarea informațiilor și trimiterea acestora la pregătirea unui raport.

    Săgeată de conectare - atribuirea unui id, introducerea datelor în baza de date;

    Săgeată de ieșire - Raport;

    Săgeți de control - reguli, ordine și lider;

    Săgeți mecanism - Angajați, PC;

    Săgețile de intrare (atribuirea id-ului), controlul, mecanismul se bifurcă;

    Introduceți săgeata de feedback de la „Verificare date” la „Achiziție date” (verificare repetată).

    Descrierea diagramei DFD

    Descompunerea lucrărilor de întreținere a computerului Figura 1 definește patru activități interne, două entități externe și două magazine de date.


    Figura 1 - Întreținerea computerului

    1) Asamblarea computerului - procesul de asamblare a unui computer din componentele existente.

    2) Întocmirea unui raport - un proces care constă în rezumarea indicatorilor finali obținuți prin efectuarea lucrărilor de contabilitate curentă.

    3) Diagnostic - verificarea performanței

    4) Upgrade - îmbunătățire, îmbunătățire, actualizare a computerului.

    Entități externe: computere și componente

    Magazin de date:

    1) Depozit - un loc unde sunt stocate computerele asamblate și actualizate.

    2) DB - o bază de date care stochează toate rapoartele și toate informațiile despre munca depusă.

    Colectăm informații despre computer și selectăm componente pentru asamblarea acestuia. Apoi asamblăm computerul și îl trimitem la depozit pentru depozitare, dar pe lângă asta, după asamblare, îl putem trimite mai întâi pentru diagnosticare, verificăm funcționalitatea și apoi doar la depozit. După diagnosticarea computerului asamblat, trimitem datele pentru a compila un raport asupra muncii efectuate și pentru a introduce informațiile în baza de date.

    Avem, de asemenea, o altă entitate externă, acesta este un computer. Îl trimitem spre modernizare, după care este trimis spre diagnostic pentru a verifica operabilitatea acestuia, apoi întocmim un raport și introducem informații despre munca efectuată în baza de date. Sau, după modernizare, trimitem marfa la depozit, apoi efectuăm diagnostice, întocmim un raport și introducem informațiile în baza de date.

    Descompunerea lucrării „Raportare” Figura 2 definește trei activități interne, trei entități externe și două depozite de date.

    1) Colectarea datelor - colectarea informațiilor despre computere și componente.

    2) Validare - verificarea corectitudinii datelor.

    3) Raport - redactarea unui raport privind munca depusă.

    Entități externe: componente, computere, manager.

    Depozit de date - Date despre computere și componente, date de raportare.


    Colectarea informațiilor despre computere și accesorii, apoi trimiterea acestora pentru stocare. După aceea, verificăm datele pentru acuratețe, întocmim un raport și îl trimitem înapoi pentru stocare la primul depozit de date (Figura 2) sau trimitem datele raportului la al doilea depozit de date (Figura 2) și apoi le trimitem la manager pentru verificare.

    Managerul verifică, notează, corectează și trimite spre re-verificare. După aceea, raportul este trimis spre stocare până când managerul este verificat din nou.

    Descrierea diagramei IDEF3

    În descompunerea lucrărilor Întreținerea computerului (Fig. 1), sunt definite mai multe intersecții care conectează una sau mai multe lucrări, mai multe lucrări interne.


    1) Reparare - asamblarea computerului cu componente prefabricate

    2) Asamblare - readucerea computerului la normal

    3) Upgrade - upgrade computer

    4) Calculatoare - un produs după asamblare și modernizare

    5) Trimite la depozit - trimite la depozitare după îmbunătățire (asamblare)

    6) Diagnostic - verificarea performanței.

    7) Raport - informații despre munca depusă.

    Intersecții - Conectori:

    1) J2 - toate acțiunile încep în același timp.

    2) J6 - Joncțiune de confluență. Un nod care colectează multe săgeți într-una singură, indicând necesitatea condiției de completare a surselor de lucru ale săgeților pentru a continua procesul.

    3) J7 - se arată că aceste condiții nu pot fi îndeplinite simultan.

    4) J9 - aceste acțiuni se încheie în același timp după care se întocmește un raport privind munca depusă.

    Diagrama IDEF3 arată că joncțiunea J2 are două săgeți de ramificare pentru lucru (construire și actualizare) care încep în același timp. Doar după finalizarea acestor lucrări, produsul finit (computerul) iese, conectează intersecția J6. Apoi, există o conexiune la intersecția J7, care arată că două lucrări (trimiterea mărfurilor la depozit și diagnosticare) nu pot fi efectuate simultan. După finalizarea lucrării anterioare, este în curs procesul de întocmire a unui raport asupra lucrării, care este conectat de joncțiunea J9.