Curs: Dezvoltarea unui model de întreprindere cu efect de seră folosind metodologiile de proiectare IDEF0, DFD și IDEF3. Crearea modelului IDEF0 Metodologia IDEF0 pe exemplul de testare

15.05.2020

Deschideți proiectul în care doriți să creați modelul. Dacă nu ați creat încă niciun proiect, puteți utiliza proiectul DEMO, care este disponibil imediat după instalarea Cradle, sau puteți crea propriul proiect.

Pentru a intra în DEMO utilizarea proiectului Nume de utilizator — ADMINISTRATOR, parola - MANAGER

Cum să vă creați proiectul este prezentat în detaliu în acest videoclip

După crearea unui proiect nou, puteți utiliza și pentru a vă autentifica Nume de utilizator — MANAGER și parola - MANAGER

Crearea modelului

Pentru a crea un model IDEF0, activați Panoul de proiectși mergeți la secțiunea de simulare Domeniul esențial

Notă : În mod similar, puteți crea modele în secțiunea de modelare a domeniului de implementare, precum și în orice secțiune configurată de utilizator. Secțiunea de modelare este de fapt un spațiu de nume în care firele de execuție pot fi reutilizate.

Pentru a crea un model de context IDEF0, faceți clic dreapta pe secțiunea IDEF0 și selectați Nou->Element

Vă rugăm să rețineți că acesta este numele întregului model, nu blocul funcțional de pe A0.

Aceasta deschide zona de desen și puteți începe să creați modelul de context.

Crearea unui bloc funcțional

Pentru a face acest lucru, selectați simbolul blocului funcțional de pe paletă

și faceți clic o dată pe zona de lucru în care doriți să creați blocul funcțional.

Va apărea o casetă de dialog în care trebuie să introduceți numele blocului funcțional, apoi faceți clic pe OK.

Ca rezultat, va fi creat un bloc funcțional cu numele specificat de dvs.

Puteți selecta marginea unui bloc și puteți modifica scara acestuia

Crearea de fire

Pentru a crea fluxuri, selectați simbolul fluxului din paletă (fără tunel sau cu tunel)

apoi faceți clic pe partea blocului funcțional cu care doriți să creați un flux și faceți clic pe orice zonă a blocului funcțional

după aceea, va apărea o casetă de dialog pentru introducerea numelui fluxului. Introduceți un nume de flux scurt și faceți clic pe OK

Notă: Vei putea intra descriere detaliata curge apoi în specificația sa.

După aceea, prin analogie, puteți crea toate fluxurile necesare

Salvați modelul apăsând butonul de pe dischetă sau apăsând CTRL+S. Când salvați, vor fi create specificații de simbol pe care le puteți edita pentru a oferi o descriere mai detaliată a elementelor modelului.

După salvarea modelului, veți putea vedea specificațiile create în panoul de proiect în aceeași secțiune în care ați creat modelul. Vor fi create două tipuri de specificații - Funcție și Flux.

Descompunerea modelului

în caseta de dialog care apare, lăsați setările implicite și faceți clic pe OK

După aceea, va fi creată o diagramă copil A1 și toate fluxurile din diagrama A0 vor fi transferate în ea.

Acum puteți redenumi blocul funcțional creat gol (cu o întrebare în loc de nume) și să creați altele suplimentare, în același mod în care le-am creat mai devreme.

Pentru a redenumi o presetare a unui bloc funcțional, selectați-o și selectați Redenumire din meniul contextual

și introduceți numele dorit

Prin analogie, creați alte blocuri funcționale corespunzătoare acestui nivel de descompunere

Pentru a crea fluxuri între aceste blocuri funcționale, trebuie mai întâi să faceți clic pe sursă, apoi pe punctul intermediar pentru a crea o curbă și apoi pe destinație, de exemplu, astfel:

Ca rezultat, veți obține un flux cu două coturi.

Puteți ajusta poziția curbelor selectând fluxul și trăgând punctele de îndoire în locația dorită

Urmărește videoclipul pentru a-l vedea în acțiune

Pentru a elimina (sau a adăuga) un punct de îndoire, apăsați tasta SHIFT de pe tastatură și faceți clic pe punctul pe care doriți să îl eliminați sau unde doriți să-l creați în flux

Salvați diagrama și asigurați-vă că sunt create specificațiile corespunzătoare

Prin analogie, este posibil să se descompună blocurile funcționale A1.

Cunoscută astăzi nu numai în cercuri înguste, abrevierea IDEF0 este prima metodologie care standardizează lucrul 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, un document „ IDEF0 Metodologia de modelare funcțională. Document de orientare Metodologia de modelare funcțională IDEF0 Ghid Document. Ediție oficială. Standard de stat al Rusiei RD IDEF0 - 2000. Dezvoltat de Centrul de Cercetare pentru CALS - tehnologii „Logistică aplicată”. Adoptat și pus în aplicare prin Decretul Standardului de Stat al Rusiei 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 de modelare grafică a proceselor de afaceri din țara noastră. În acest articol, vă sugerez să luați în considerare modelul IDEF0 și să evaluați relevanța acestei abordări în prezent.

Concepte de bază și abrevieri

Să ne ocupăm puțin de denumirile elementelor cheie ale metodologiei. Standardul grafic IDEF0 face parte din metodologia SADT (Structured Analysis and Design Technique). IDEF este o abreviere pentru ICAM Definition, iar ICAM este derivat din Integrated Computer Aided Manufacturing, care se traduce prin computerizarea integrată a producției. Metodologia SADT este o întreagă familie de 15 diferite modele, care într-un complex ar fi trebuit să permită studierea structurii, parametrilor și caracteristicilor sistemelor de producție, tehnice și organizatorice și economice.

IDEF0 este un model funcțional, care este nucleul construirii tuturor celorlalte structuri, leagă între ele informațiile și fluxurile de materiale, structura organizatorica, actiunile de control si insasi activitatile companiei. Un standard grafic pentru modelarea proceselor este, de asemenea, denumit în mod obișnuit 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, IDEF0 este potrivit pentru a apela notația care face parte din metodologia SADT.

Notația IDEF0 este o tehnică destul de riguroasă care a fost dezvoltată inițial, ca standardele de proiectare inginerească, 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 o mulțime de scheme, iar sistematizarea fără ambiguitate și navigarea prin toate elementele modelului este necesară. Acum o fac mai ales sisteme informatice, susținând modelarea în această notație. Sistemele AllFusion Process Modeler și Business Studio sunt cele mai faimoase și disponibile astăzi pe teritoriul Rusiei. Plănuiesc să dedic articole separate revizuirii acestor sisteme.

Bloc funcțional

Elementul central al modelului IDEF0 este funcția , care este afișată în 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ă ca scară - de la activitățile companiei în general și până la manipularea specifică în special. Exemple: „Producție și vânzare de vase ceramice” și „Desen pe produs”.

Elementele blocului funcțional necesare în IDEF0

Indiferent de scara acțiunilor, toate funcțiile sunt afișate uniform și conțin neapărat 4 fluxuri cheie care sunt alocate rigid părților laterale ale blocului funcțional:

în stânga - intrări sau resurse utilizate pentru executarea funcției;
în dreapta - ieșiri sau rezultate ale execuției funcției;
de sus - acțiuni de control care determină cât și câte rezultate trebuie produse;
mai jos - mecanisme care reflectă cine și cu ce ar trebui să facă această muncă.

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

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

Intrările sunt resurse care își transferă valoarea către ieșiri complet, adică sunt cheltuite complet pentru crearea rezultatului, iar mecanismele sunt resurse care își transferă valoarea doar parțial (echipamente prin amortizare și oameni prin salarii).
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 unei funcții. Adesea, acest flux este tratat formal, dar, în același timp, schema își pierde rigoarea și, uneori, chiar și sensul.
Fiecare bloc funcțional trebuie să aibă cel puțin o săgeată pe fiecare parte (din moment ce nu poate exista nicio muncă fără resurse sau rezultate, iar o instrucțiune fără executant sau instrucțiune va fi incompletă).

Schema luată în considerare este „cărămida” abordării IDEF0. Modelarea funcțională implică o tranziție treptată de la general la particular prin descompunere. Descompunerea este o „aprofundare” a funcției luate în considerare, împărțind-o în funcții mai mici. În același timp, atunci când funcția de nivel superior este prezentată într-un mod generalizat și apoi descompusă, este potrivit să o numim proces.

Diagrama de context

La cel mai înalt nivel, compania este văzută ca o „cutie neagră” în care se desfășoară o anumită activitate care traduce intrările în ieșiri. Acest nivel se numește de obicei „”, adică o diagramă care descrie contextul activităților companiei. În plus, se afișează diagrama de context caracteristici cheieîntregul model.

Scopul este o formulare specifică a scopului modelului, conform căreia acuratețea construirii modelului poate fi verificată în viitor.
Punct de vedere - din a cărui față este construit modelul, deoarece modelul este întotdeauna dependent de autorul său și de centrul atenției. Dacă construim model generalîntreprindere, este de obicei prezentată din punctul de vedere al directorului acesteia.
Tipul de model este o indicație a informațiilor afișate pe diagrame. Pot exista 2 opțiuni fundamentale aici: AS IS ("Așa cum este") sau A FI ("Așa cum 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 clari cu privire la ceea ce facem și să comunicăm aceste informații altora.

Astfel, diagrama de context contine in cea mai generalizata forma o descriere a activitatilor firmei, care sunt impregnate de fluxurile care leaga firma de lumea exterioara. Cred că ar trebui să fie și un pic mai detaliate.

Fluxuri principale

Experiența a arătat că, în ciuda simplității și formalității aparente a acestui nivel, este adesea necesar să zăboviți mult timp pe el, deoarece toate rezultatele care sunt semnificative pentru proprietar și piață ar trebui să se reflecte aici. O eroare poate duce la crearea unor modele care nu îndeplinesc sarcinile stabilite pentru afacere. Pentru a verifica dacă sunt afișate fluxuri semnificative, asigurați-vă că toate cele 4 tipuri principale de fluxuri sunt prezente în diagramă.

Material: materiale și componente la intrare și produse terminate la iesire.
Client: un potential client la intrare si unul multumit la iesire.
Financiar: la intrare sunt de obicei investiții, plăți ale clienților (venituri), împrumuturi și alte venituri; rezultatul este plăți către furnizori, impozite, plăți pentru împrumuturi și profituri.
Informațional: la intrare, acestea sunt toate fluxurile de informații despre Mediul extern(condițiile pieței, comportamentul concurenților, inovațiile tehnologice etc.), iar rezultatul este fluxul de informații pe care compania îl raportează lumii despre ea însăși (toate informațiile publicitare, precum și toate tipurile de raportare către autoritățile de reglementare).

Vă rugăm să rețineți că compania este sistem deschis, și nimic nu apare sau nu dispare în ea. Compania poate converti doar fluxurile de intrare în fluxuri de ieșire și, dacă face acest lucru bine, atunci există o fluxul de numerar(profit), reflectând într-un anumit sens calitatea întregului sistem.

(click pentru a mari)

Este bine dacă scoți în evidență fiecare dintre aceste tipuri de fluxuri cu o culoare diferită, astfel încât să poți distinge cu ușurință mișcarea resurselor și să nu ratezi 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 rezidual - clientul se simte adesea ca o piedică pentru angajații companiei, ale căror sarcini sunt concentrate pe procesarea fluxul de documente.

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

legi și reglementări;
comenzi, comenzi;
instructiuni si regulamente;
planuri;
documentatia de proiectare etc.

Al doilea este informațiile nedocumentate, care includ cel mai adesea cerințele proprietarilor.

Și, în sfârșit, mecanisme - există doar 2 tipuri de fluxuri: echipamente (material) și executanți (divizii și oameni). Nu pot exista documente aici, la fel cum nu pot fi oameni pe săgețile de control!

Numerotarea continuă este prevăzută pentru navigarea în model. Diagrama de context este numerotată „A-0”. Pe viitor, fiecare bloc funcțional primește propriul său număr, indiferent cât de adâncă este descompunerea.

Descompunere

După elaborarea fluxurilor diagramei de context, putem trece la descompunere. Mergând cu un nivel mai jos, parcă deschidem o „cutie neagră”, vedem mai întâi Foaie albă cu săgeți care au fost atașate blocului funcțional.

(click pentru a mari)

Și de aici începe modelarea funcțională reală - trebuie să înțelegem ce set de acțiuni poate 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 și avem dreptul de a afișa nu mai mult de 9 funcții pe diagramă, altfel diagrama va deveni ilizibilă și, în consecință, inutilă.

Nu este întotdeauna ușor să aranjați o activitate complexă în așa fel încât să rămână vizuală, lizibilă și în același timp completă. Cel mai adesea, recurg la împărțirea întregii varietăți de procese în blocuri mari principale, dintre care cele mai semnificative sunt următoarele.

Crearea unui produs (rezultat).
Promovare și vânzare - lucrați cu un flux de clienți.
Asigurarea că activitățile de dezvoltare a produselor sunt procese secundare care sunt necesare pentru conformitate cerințele statului sau comoditatea muncii (personal și contabilitate, servicii de transport, curățare spații etc.).
Crearea fluxurilor de control - activitati de dezvoltare decizii de management, care va determina cerințele pentru toate procesele companiei.

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

(click pentru a mari)

În diagramă, procesele ar trebui să fie localizate în diagonală - se numește acest lucru principiul dominantei, care presupune 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 - se realizează descompunerea fiecărui bloc funcțional al primului nivel. Numerotarea blocului va conține numărul primului nivel: A1.1 ... A1.n, A2.1 ... A2.n etc.

Concluzii despre relevanța notației

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

Modelul are un bun potențial de vizualizare, dar, după părerea mea, valoarea sa mai mare este în efectul disciplinar. Regulile și restricțiile prevăzute în metodologie fac necesară dezvoltarea unei atitudini sistematice și stricte față de modele, care are un efect foarte bun asupra calității rezultatului final.
Modelul vă permite să construiți fluxuri de comunicare între lucruri externe care nu sunt strâns legate: să conectați subsistemele din front și back office cu managementul, ceea ce este mult mai rău pentru alte notații.
Abordarea este simplă și de înțeles pentru majoritatea participanților la proiect. Construirea și citirea diagramelor în această notație este limitată doar de dorința de a aprofunda în complexitatea fluxurilor de afaceri.

Unele dintre argumentele de mai sus ne fac să credem că această abordare este cea mai bună și singura pentru modelarea completă a activității. Dar nu trebuie să uităm că modelul funcțional este conceput doar pentru nivelul superior de modelare. Utilizarea notației IDEF0 pentru a proiecta lucrări la nivelul interpreților duce la faptul că schemele sunt pur ilustrative și este imposibil să se construiască un regulament explicativ pe baza lor, deoarece nu conțin:

specificarea evenimentelor de pornire și oprire ale procesului;
conditii pentru trecerea de la o actiune la alta;
capacitatea de a afișa vizual toate resursele și performanții fără a supraîncărca schema 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.

În managementul proiectelor, acest standard de modelare este cel mai aplicabil acolo unde trebuie să legați diferite proiecte sau procese în fluxuri vizuale. În același timp, modelul grafic va permite o distribuție mai rațională a responsabilităților și resurselor între sarcini. Logica sarcinilor proiectului, reflectată în diagrame, va ajuta la pregătirea unei mai bune plan calendaristic sub forma unei diagrame Gantt.

Învață să vezi și să înțelegi structură funcțională treaba ta!

În prezent, interesul pentru standardele de management general acceptate în Occident a crescut brusc în Rusia, cu toate acestea, în practica reală de management, există un moment foarte semnificativ. Mulți lideri pot fi încă derutați de întrebarea directă a structura organizationala companie sau despre schema proceselor de afaceri existente. Cei mai avansați și care citesc în mod regulat manageri de periodice economice, de regulă, încep să deseneze diagrame ierarhice care pot fi înțelese numai pentru ei, dar în acest proces, de obicei, se opresc rapid. Același lucru este valabil și pentru angajații și șefii diferitelor servicii și unități funcționale. În cele mai multe cazuri, singurul set de reguli declarate în temeiul căruia o întreprindere trebuie să funcționeze este un set de reglementări separate și descrierea postului. Cel mai adesea, aceste documente au fost întocmite cu mai bine de un an în urmă, sunt prost structurate și nu au legătură între ele și, ca urmare, pur și simplu adună praf pe rafturi. Deocamdată, o astfel de abordare a fost justificată, deoarece în timpul formării economiei de piață rusă conceptul de concurență a fost practic absent și nu a fost nevoie în mod special de a număra costurile - profitul a fost gigantic. Drept urmare, în ultimii doi ani am văzut o imagine destul de ușor de înțeles: companii mari, care au crescut la începutul anilor '90, își pierd treptat pozițiile, până la o retragere completă de pe piață. Acest lucru se datorează parțial faptului că standardele de management nu au fost introduse în întreprindere, conceptul de model funcțional de activitate și misiune a fost complet absent. Prin simulare diverse zone activități, este posibil să se analizeze eficient „gâturile de sticlă” în management și să se optimizeze schema generală de afaceri. Dar, după cum știți, în orice întreprindere, doar acele proiecte care generează direct profit au cea mai mare prioritate, așa că de obicei este vorba de examinarea activităților și reorganizarea acesteia doar în timpul unei crize tangibile în managementul companiei.

La sfârșitul anilor 1990, când piața a început să devină competitivă și profitabilitatea întreprinderilor a început să scadă, managerii au simțit mari dificultăți în a încerca să optimizeze costurile astfel încât produsele să rămână atât profitabile, cât și competitive. Chiar în acel moment s-a manifestat clar nevoia de a avea în fața ochilor un model al activității întreprinderii, care să reflecte toate mecanismele și principiile de interconectare a diferitelor subsisteme în cadrul unei singure afaceri.

Însuși conceptul de „modelare a proceselor de afaceri” a intrat în viața majorității analiștilor odată cu apariția pe piață a complexului. produse software conceput pentru automatizarea complexă a managementului întreprinderii. Astfel de sisteme implică întotdeauna o analiză profundă înainte de proiect a activităților companiei. Rezultatul acestui sondaj este o opinie de specialitate, în care recomandări sunt făcute în paragrafe separate pentru a elimina „gâturile de sticlă” în managementul 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 este, desigur, o echipă care s-a dezvoltat de-a lungul anilor este întotdeauna greu de făcut să „gândească într-un mod nou”. Astfel de anchete cuprinzătoare ale întreprinderilor sunt întotdeauna complexe și diferă semnificativ de la caz la caz. Există metodologii și standarde bine stabilite pentru rezolvarea unor astfel de probleme de modelare a sistemelor complexe. Aceste standarde includ familia de metodologii IDEF. Cu ajutorul lor, puteți afișa și analiza eficient modelele de activitate ale unei game largi de sisteme complexe în diferite secțiuni. În același timp, lărgimea și profunzimea examinării proceselor din sistem sunt determinate de însuși dezvoltatorul, ceea ce permite să nu supraîncărcați modelul creat cu date inutile. În prezent, următoarele standarde pot fi atribuite familiei IDEF:

IDEF0 este o metodologie de modelare funcțională. Cu ajutorul unui limbaj grafic vizual IDEF0, sistemul studiat le apare dezvoltatorilor și analiștilor ca un set de funcții interdependente (blocuri funcționale – în termenii IDEF0). De obicei, modelarea IDEF0 este primul pas în învățarea oricărui sistem;

IDEF1 - metodologia de modelare fluxurile de informațiiîn cadrul sistemului, permițând afișarea și analizarea structurii și relațiilor acestora;

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

IDEF2 este o metodologie pentru modelarea dinamică a evoluției sistemelor. În legătură cu dificultățile foarte serioase în analiza sistemelor dinamice, acest standard a fost practic abandonat, iar dezvoltarea lui a fost suspendată chiar în stadiul inițial. Cu toate acestea, în prezent există algoritmi și implementările lor pe computer care permit transformarea unui set de diagrame statice IDEF0 în modele dinamice construite pe baza „rețelelor Petri colorate” (CPN – Color Petri Nets);

IDEF3 este o metodologie de documentare a proceselor care au loc într-un sistem, care este utilizată, de exemplu, în studiul proceselor tehnologice din întreprinderi. IDEF3 descrie scenariul și secvența operațiunilor pentru fiecare proces. IDEF3 are o relație directă cu metodologia IDEF0 - fiecare funcție (bloc funcțional) poate fi reprezentată ca proces separat folosind instrumentele IDEF3;

IDEF4 este o metodologie pentru construirea de sisteme orientate pe obiecte. Instrumentele IDEF4 vă permit să afișați vizual structura obiectelor și principiile de bază ale interacțiunii lor, permițându-vă astfel să analizați și să optimizați sisteme complexe orientate pe obiecte;

IDEF5 este o metodologie pentru studiul ontologic al sistemelor complexe. Folosind metodologia IDEF5, ontologia unui sistem poate fi descrisă folosind un anumit vocabular de termeni și reguli, pe baza căruia se pot forma declarații de încredere despre starea sistemului luat în considerare la un moment dat. Pe baza acestor afirmații, se trag concluzii cu privire la dezvoltarea ulterioară a sistemului și se realizează optimizarea acestuia.
În cadrul acestui articol, vom lua în considerare cea mai frecvent utilizată metodologie de modelare funcțională IDEF0.

Istoria standardului IDEF0

Metodologia IDEF0 poate fi considerată următoarea etapă în dezvoltarea cunoscutului limbaj grafic pentru descrierea sistemelor funcționale SADT (Structured Analysis and Design Teqnique). În urmă cu câțiva ani, în Rusia a fost publicată o mică ediție a unei cărți cu același nume, 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 program extins de automatizare întreprinderile industriale, care purta denumirea ICAM (Integrated Computer Aided Manufacturing) și a fost propus de Departamentul Forțelor Aeriene din SUA. Familia de standarde IDEF în sine și-a moștenit denumirea de la numele acestui program (IDEF=ICAM DEFinition). În procesul 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 noului standard a fost disponibilitatea unei metodologii eficiente de interacțiune în cadrul „analistului-specialist”. Cu alte cuvinte, noua metoda trebuia să asigure lucrul de grup la crearea modelului, cu participarea directă a tuturor analiștilor și specialiștilor implicați în proiect.

Ca urmare a căutării soluțiilor adecvate, a luat naștere metodologia de modelare funcțională IDEF0. Din 1981, standardul IDEF0 a suferit mai multe modificări minore, majoritatea restrictive, iar ultima sa revizuire a fost lansată în decembrie 1993 de către Institutul Național de Standarde și Tehnologie din SUA (NIST).

Elemente și concepte de bază ale IDEF0

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

Primul dintre acestea este conceptul de cutie de activități. Blocul funcțional este reprezentat grafic ca un dreptunghi (vezi Fig. 1) și reprezintă o funcție specifică în cadrul sistemului considerat. Conform cerințelor standardului, numele fiecărui bloc funcțional trebuie formulat în mod verbal (de exemplu, „a produce servicii”, și nu „a produce servicii”).

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

Partea de sus este „Control”;

Partea stângă este „Intrare”;

Partea dreaptă este setată la „Ieșire”;

Partea de jos are semnificația „Mecanism” (Mecanism).

Fiecare unitate funcțională din cadrul sistemului unic în cauză trebuie să aibă propriul său număr unic de identificare.

Figura 1. Bloc funcţional.

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

Afișarea grafică a arcului de interfață este o săgeată unidirecțională. Fiecare arc de interfață trebuie să aibă propriul nume unic (Arrow Label). Conform standardului, numele trebuie să fie o cifră de afaceri a unui substantiv.

Cu ajutorul arcurilor de interfață sunt afișate diverse obiecte care, într-o măsură sau alta, determină procesele care au loc în sistem. Astfel de obiecte pot fi elemente ale lumii reale (piese, vagoane, angajați etc.) sau fluxuri de date și informații (documente, date, instrucțiuni etc.).

În funcție de ce parte se apropie arcul de interfață dat, se numește „incoming”, „outgoing” sau „controlling”. În plus, „sursa” (începutul) și „receptorul” (sfârșitul) fiecărui arc funcțional pot fi numai blocuri funcționale, în timp ce „sursa” poate fi doar partea de ieșire a blocului, iar „receptorul” poate fi orice dintre cele trei rămase.

De menționat 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ă aibă loc conform unor reguli (afișate de arcul de control) și trebuie să producă un rezultat (arc de ieșire), altfel luarea în considerare a acestuia nu are sens.

Când construiți diagrame IDEF0, este important să separați corect arcurile interfeței de intrare de arcurile de control, ceea ce adesea nu este ușor. De exemplu, Figura 2 prezintă blocul funcțional „Procesează piesa de prelucrat”.

Într-un proces real, lucrătorului care efectuează prelucrarea i se oferă o piesă de prelucrat și instrucțiuni tehnologice pentru prelucrare (sau reglementări de siguranță atunci când lucrează cu mașina). Poate părea în mod eronat că atât piesa de prelucrat, cât și documentul cu instrucțiuni tehnologice sunt obiecte de intrare, dar nu este așa. De fapt, în acest proces, piesa de prelucrat este prelucrată conform regulilor reflectate în instrucțiunile tehnologice, care ar trebui, respectiv, reprezentate 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, ele sunt deja afișate de arcul de interfață de intrare, 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 de control, 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 de materiale (piese, 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, comenzi verbale etc.) și resurse (angajați, mașini, mașini etc.). În acest caz, în diverse cazuri, arcurile de interfață de intrare și de ieșire pot afișa toate tipurile de obiecte care le gestionează doar pe cele legate de fluxul de documente și informații, și doar resursele pot fi afișate ca arcuri-mecanisme.

Prezența obligatorie a arcurilor de interfață de control este una dintre principalele diferențe între standardul IDEF0 și alte metodologii ale claselor DFD (Diagrama fluxului de date) și WFD (Diagrama fluxului de lucru).

Al treilea concept de bază al standardului IDEF0 este Descompunerea. Principiul descompunerii se aplică la partiționare proces complex la funcţiile sale componente. În acest caz, nivelul de detaliu al procesului este determinat direct de dezvoltatorul modelului.

Descompunerea vă permite să reprezentați treptat și structurat modelul de sistem în formă structura ierarhica diagrame individuale, făcându-l mai puțin aglomerat și mai ușor de digerat.

Modelul IDEF0 începe întotdeauna cu o vedere a sistemului ca întreg - o singură unitate 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 notă cu identificatorul "A-0".

În textul explicativ pentru diagrama de context, scopul (Scopul) construcției diagramei în formă scurta descriereși punct de vedere fix (Viewpoint).

Definirea și formalizarea obiectivului de dezvoltare IDEF0 - modele este extrem de punct important. De fapt, scopul determină zonele relevante din sistemul studiat, care trebuie concentrate 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 determină 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, refuzând să detaliați și să studiați elementele individuale care nu sunt necesare, pe baza punctului de vedere ales asupra sistemului. De exemplu, modele funcționale ale aceleiași întreprinderi din punctul de vedere al tehnologului șef și director financiar vor diferi semnificativ în direcția detalierii lor. Acest lucru se datorează faptului că, în final, directorul financiar nu este interesat de aspectele procesării materiilor prime pe mașini de producție, iar tehnologul șef nu este interesat de schemele trasate ale fluxurilor financiare. Alegerea potrivita punct de vedere reduce semnificativ timpul petrecut pentru construirea modelului final.

În procesul de descompunere, blocul funcțional, care în diagrama de context afișează sistemul ca întreg, este detaliat î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 de context și se numește diagramă copil (Diagrama copil) în raport cu acesta (fiecare dintre blocurile funcționale aparținând diagramei copil este respectiv numit bloc copil - Child Box). La rândul său, blocul funcțional - strămoșul este numit bloc părinte în raport cu diagrama copil (Parent Box), iar diagrama căreia îi aparține se numește diagramă părinte (Parent Diagram). Fiecare dintre subfuncțiile diagramei copil poate fi detaliată în continuare printr-o descompunere similară a blocului său funcțional corespunzător. Este important de menționat 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 pe diagrama copil. Acest lucru realizează integritatea structurală a modelului IDEF0. Principiul descompunerii este prezentat clar în Figura 4. Ar trebui să acordați atenție relației dintre numerotarea blocurilor funcționale și diagramele - fiecare bloc are propriul său număr de serie unic pe diagramă (numărul din colțul din dreapta jos al dreptunghiului) , iar denumirea din colțul din dreapta indică numărul diagramei copil pentru acest bloc . Absența acestei denumiri indică faptul că nu există nicio descompunere pentru acest bloc.

Adesea există cazuri în care nu are sens să se ia în continuare în considerare arcuri individuale de interfață în diagramele copil sub un anumit nivel în ierarhie sau invers - arcuri individuale nu au sens practic peste un anumit nivel. De exemplu, un arc de interfață care înfățișează un „detaliu” la intrarea în „Proces pornit strung” nu are sens să reflectăm asupra topurilor mai mult decât niveluri înalte- acest lucru va supraîncărca diagramele și le va face dificil de citit. Pe de altă parte, este nevoie de a scăpa de arcuri de interfață „conceptuale” separate și de a nu le detalia mai profund decât un anumit nivel. Pentru a rezolva astfel de probleme, standardul IDEF0 prevede conceptul de tunel. Desemnarea „tunelului” (Arrow Tunnel) sub forma a două paranteze în jurul începutului arcului de interfață înseamnă că acest arc nu a fost moștenit din blocul părinte funcțional și a apărut (din „tunel”) doar pe această diagramă. La rândul său, aceeași desemnare în jurul capătului (săgeata) arcului de interfață în imediata apropiere a blocului receptor înseamnă că acest arc nu va fi afișat și nu va fi luat în considerare în diagrama copil a acestui bloc. 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, mai întâi „se plonjează în tunel”, apoi, dacă este necesar, „se întorc din tunel”.

Ultimul dintre conceptele IDEF0 este Glosarul. Pentru fiecare dintre elementele IDEF0: diagrame, blocuri funcționale, arcuri de interfață, standardul existent presupune crearea și menținerea unui set de definiții adecvate, Cuvinte cheie, enunţuri narative 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 interfața de control arc „ordin de plată”, glosarul poate conține o listă de câmpuri corespunzătoare arcului documentului, setul necesar de vize etc. Glosarul completează armonios limbajul grafic vizual, oferind diagramelor informațiile suplimentare necesare.

Figura 4. Descompunerea blocurilor funcționale.

Principii pentru limitarea complexității diagramelor IDEF0

De obicei, modelele IDEF0 transportă informații complexe și concentrate, iar pentru a limita aglomerația lor și a le face lizibile, restricțiile 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) obligă proiectantul să folosească ierarhii atunci când descrie subiecte complexe, iar limita inferioară (trei) asigură că diagrama corespunzătoare are suficiente detalii pentru a justifica crearea acesteia;

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

Disciplina muncii în grup privind dezvoltarea unui model IDEF0

Standardul IDEF0 conține un set de proceduri care vă permit să dezvoltați și să conveniți asupra unui model grup mare persoane aparţinând diferitelor domenii de activitate ale sistemului modelat. De obicei, procesul de dezvoltare este iterativ și constă din următorii pași condiționati:

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 termenii IDEF0. Construirea modelului inițial este un proces dinamic în timpul căruia autorii întreabă persoane competente despre structura diferitelor procese. Pe baza prevederilor existente, a documentelor și a rezultatelor sondajului, se creează o schiță (Model Draft) a modelului.

Distribuirea proiectului spre examinare, aprobări și comentarii. În această etapă, se discută cu proiectul de model o gamă largă persoane competente (din punct de vedere al cititorilor IDEF0) din intreprindere. În același timp, fiecare dintre diagramele proiectului de model este criticată și comentată în scris, apoi transferată autorului. Autorul, la rândul său, este de acord cu critica în scris sau o respinge cu o declarație a logicii deciziei și returnează din nou proiectul corectat pentru o analiză ulterioară. Acest ciclu continuă până când autorii și cititorii ajung la un consens.

Aprobare model. Modelul omologat este aprobat de șef grup de lucruîn cazul în care autorii modelului și cititorii nu au dezacorduri cu privire la adecvarea acestuia. Modelul final este o vedere consistentă a întreprinderii (sistemului) dintr-un punct de vedere dat și pentru un scop dat.
Vizibilitatea limbajului grafic IDEF0 face ca modelul să fie destul de lizibil pentru persoanele care nu au luat parte la proiectul de creare a acestuia, precum și eficient pentru demonstrații și prezentări. Pe 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 folosind instrumente IDEF0

În ultimii ani, interesul față de Rusia față de metodologiile familiei IDEF a crescut constant. Observ în mod constant acest lucru când mă uit la statisticile accesărilor pe pagina mea web personală (http://www.vernikov.ru), care descrie pe scurt principiile de bază ale acestor standarde. În același timp, aș numi interesul pentru astfel de standarde precum IDEF3-5 teoretic, iar în IDEF0 este destul de practic justificat. De fapt, primele Case-tools care permit construirea diagramelor DFD și IDEF0 au apărut pe piața rusă în 1996, simultan cu lansarea unei cărți populare despre principiile modelării în standardele SADT.

Cu toate acestea, majoritatea managerilor încă consideră aplicarea practică a modelării în standardele IDEF mai mult ca un tribut adus modei decât ca o modalitate eficientă de optimizare a sistemului existent de management al afacerii. Acest lucru se datorează cel mai probabil unei lipse pronunțate de informații despre aplicație practică a acestor metodologii și cu o părtinire software indispensabilă a marii majorități a publicațiilor.

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

Atunci când desfășurați proiecte complexe de sondaj ale întreprinderilor, dezvoltarea modelelor în standardul IDEF0 vă permite să afișați vizual și eficient întregul mecanism al activităților întreprinderii în secțiunea potrivită. Cel mai important, însă, este capacitatea de colaborare pe care o oferă IDEF0. In al meu activitati practice au fost destul de multe cazuri când modelul a fost construit cu ajutorul direct al angajaților din diverse departamente. În același timp, consultantul le-a explicat într-un timp destul de scurt principiile de bază ale IDEF0 și i-a învățat cum 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 trebuiau să răspundă la următoarele întrebări:

Ce intră în unitate „la intrare”?

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

Cine este responsabil pentru fiecare funcție?

Ce ghidează executantul în îndeplinirea fiecărei funcții?

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

După coordonarea schițelor de diagrame în cadrul fiecărui departament specific, acestea sunt asamblate de către un consultant într-un proiect de model de întreprindere, în care toate elementele de intrare și de ieșire sunt legate. În această etapă, toate inconsecvențele diagramelor individuale și locurile lor controversate sunt remediate. În plus, acest model trece din nou prin departamentele funcționale pentru coordonarea ulterioară și efectuarea ajustărilor necesare. Ca urmare, într-un timp destul de scurt și cu implicarea unui minim de resurse umane din partea companiei de consultanță (și aceste resurse, după cum știți, sunt foarte costisitoare), se obține un model IDEF0 al unei întreprinderi conform „As este” principiul și, important, reprezintă o întreprindere cu funcții de angajați care lucrează în ea și cunosc temeinic toate nuanțele, inclusiv cele informale. În viitor, acest model va fi transferat pentru analiză și procesare către analiștii de afaceri care vor căuta „gâtele de sticla” în managementul companiei și vor optimiza procesele principale, transformând modelul „Așa cum este” în modelul „Așa cum ar trebui să fie” corespunzător. ” reprezentare. 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ă presupune impunerea unor angajați a unor responsabilități suplimentare pentru dezvoltarea și aplicarea practică a noilor metodologii. Cu toate acestea, în cele din urmă se justifică, deoarece încă o oră sau două de muncă angajati individualiîn câteva zile, pot economisi în mod semnificativ banii la plata serviciilor de consultanță ale unei companii terțe (care, în orice caz, va întrerupe aceiași angajați de la lucru cu chestionare și întrebări). Cât despre angajații întreprinderii înșiși, într-un fel sau altul, nu am întâlnit nicio opoziție exprimată din partea acestora în practica mea.

Concluzia din toate acestea se poate trage după cum urmează: nu este absolut necesar să se vină cu soluții pentru problemele standard de fiecare dată. Ori de câte ori vă confruntați cu necesitatea de a analiza un anumit sistem funcțional (din sistemul de proiectare nava spatiala, înainte de procesul de pregătire a unei cine complexe) - folosiți metode care au fost încercate și testate de ani de zile. Una dintre aceste metode este IDEF0, care permite utilizarea setului său de instrumente simplu și ușor de înțeles pentru a rezolva probleme complexe de viață.

O imagine valorează cât o mie de cuvinte

înțelepciunea populară

Desigur, în teorie, managerul ar trebui să aibă un model funcțional al activității companiei și nu contează dacă vorbim despre organizarea depozitului sau a sistemului IT (de la lead la cerere). Dar, în realitate, aproape niciodată nu se dovedește a fi și, prin urmare, în procesul de studiu și căutare a unei soluții la sarcina stabilită de client, creez și un model funcțional al companiei sau un anumit proces (funcție) pe a mea.

Câteva cuvinte despre beneficiile graficii

După cum știți, modelele funcționale IDEF0 sunt întotdeauna diagrame grafice. Au propriile caracteristici și reguli de compilare. Vom vorbi despre asta puțin mai târziu. Și acum aș dori să dau câteva exemple despre eficiența graficii. De ce mă concentrez pe asta? Cel mai probabil, după declarația mea despre necesitatea unui model funcțional al activității companiei, mulți oameni au crezut că acest lucru nu este necesar și a fost posibil să explic în cuvinte cum funcționează cutare sau cutare funcție în companie. Despre asta vreau să vorbesc.

Și, pentru început, să facem o scurtă digresiune în istorie. Să ne întoarcem la îndepărtatul 1877, în timpul războiului ruso-turc. Atunci imprimanta Sytin a folosit pentru prima dată grafica în descrierea operațiunilor militare. Acum toate acestea ne sunt familiare, atunci când descriem orice bătălie, în fața ochilor noștri apar cărți cu săgeți, care arată clar cursul bătăliei. Și în acele zile, operațiunile militare erau descrise în cuvinte. Pentru fiecare luptă - multe, multe cuvinte. Și a fost foarte greu de înțeles până la urmă ce se întâmplă.

Acesta este motivul pentru care ideea lui Sytin a fost cu adevărat revoluționară - a început să imprime copii litografice ale hărților cu desemnarea fortificațiilor și a locațiilor unităților militare. Aceste carduri au fost numite „Pentru cititorii de ziare. Beneficiu". Ideea s-a dovedit a fi atât de relevantă încât primul tiraj al „Help” s-a epuizat instantaneu. Și atunci astfel de aplicații au fost la mare căutare. Motivul este evident. Grafica a ajutat la înțelegerea a ceea ce era aproape imposibil de deslușit doar cu ajutorul cuvintelor.

De asemenea, pot cita un exemplu similar de neputință a descrierilor verbale din propria mea practică. Unul dintre clienții mei mi-a cerut să îmi asum implementarea unui sistem ERM pentru compania sa. Când am întrebat dacă au un fel de sarcină tehnică, am primit răspunsul: „Da, au. Dar are 400 de pagini.” În același timp, clientul s-a plâns foarte mult că colegii mei, pe care i-a contactat anterior, fie au refuzat cu totul proiectul, fie au cerut prețuri vădit umflate. După ce am văzut că termenii de referință aveau într-adevăr 400 de pagini și constau doar într-o descriere textuală, am înțeles motivele comportamentului dezvoltatorilor. Citirea unui astfel de volum de text, adâncirea în el, înțelegerea tuturor nuanțelor doar pentru a înțelege sarcina și a numi prețul este cu adevărat foarte dificilă.

I-am oferit acestui client o variantă alternativă - să descrie tot ceea ce este posibil grafic sub formă de notații. I-a arătat exemple de modeling. Drept urmare, acum își regândesc dorințele și designul termenilor de referință.

Cunosc și multe alte exemple când modelarea grafică a proceselor de afaceri i-a ajutat atât pe colegii mei, consultanții și dezvoltatorii de afaceri, cât și pe oamenii de afaceri înșiși.

De ce este acest lucru important pentru munca mea

Munca mea este întotdeauna legată de modificarea sistemului existent. Și pentru a face modificări și a obține rezultatul dorit, trebuie să studiați ceea ce există deja. Și nu contează exact ce facem – instalăm sau instalăm un sistem CRM de la zero, creăm un sistem ERP eficient, integrăm diverse sisteme pentru a crește automatizarea muncii în general. În orice caz, pentru început, este necesar să vă faceți o idee despre schema de lucru existentă și numai după aceea este posibil să propuneți unele modificări și să vă gândiți la opțiuni pentru rezolvarea sarcinii.

După ce am studiat status quo-ul, eu, ca orice alt specialist terță parte, creez oferi, în care vă dezvălui cât mai detaliat viziunea mea asupra situației actuale, precum și acțiunile care trebuie întreprinse pentru rezolvarea sarcinii și, bineînțeles, rezultatul așteptat.

Astfel de rapoarte de anchetă de muncă sunt voluminoase, ocupând mai mult de o pagină, ceea ce, pe de o parte, este necesar, dar, pe de altă parte, complică percepția. La început, la fel ca mulți alții, am crezut că rapoartele voluminoase sunt bune, pentru că o persoană plătește pentru muncă și trebuie să îi oferi informații cât mai detaliate.

De fapt, este important să nu oferi volum, ci să transmită esența cât mai rapid și complet posibil. Volumele mari de text necesită timp, pe care oamenii de afaceri îl au adesea foarte puțin. Iar grafica îmi permite să reduc volumul propunerii mele și să arăt clar, într-o formă de înțeles, soluția. Drept urmare, propunerile mele au fost reduse semnificativ, grafica a apărut în ele și deciziile privind începerea cooperării au început să fie luate mai rapid.

Din acest motiv folosesc modele vizuale. După cum știți, o imagine valorează cât o mie de cuvinte. Și în cazul descrierii proceselor de afaceri și a opțiunilor de modernizare a activității unei afaceri, acest lucru este adevărat. Și notațiile IDEF0 sunt foarte potrivite aici.

Dar mai întâi, să înțelegem conceptele de bază despre ce sunt notațiile, de ce sunt necesare, ce este IDEF0, care sunt caracteristicile și avantajele acestei metode

Ce este notația de descriere a procesului de afaceri

O notație este un format pentru descrierea unui proces de afaceri, care este un set de obiecte grafice utilizate în modelare, precum și reguli de modelare.

De fapt, notațiile sunt un limbaj grafic special care vă permite să descrieți munca unei companii, să demonstrați vizual interacțiunea dintre diferite departamente, de exemplu. descrie procesele de afaceri. Notațiile pot fi folosite pentru modelarea proceselor sau funcționale.

În general, notațiile pot fi numite un limbaj de programare în analiza de afaceri.

Ce este IDEF0?

IDEF0 este o metodologie de modelare funcțională și o notație grafică concepută pentru a formaliza și descrie procesele de afaceri. Trăsătură distinctivă IDEF0 pune accentul pe subordonarea obiectelor. IDEF0 ia în considerare relațiile logice dintre joburi, nu secvența lor temporală (flux de lucru). Wikipedia

Standardul IDEF0 a fost dezvoltat în 1981 de către Departamentul Forțelor Aeriene din SUA pentru automatizarea industrială. În stadiul de dezvoltare software dezvoltatorii se confruntă cu nevoia de a dezvolta noi metode de analiză a proceselor de afaceri. Ca urmare, a apărut metodologia de modelare funcțională IDEF0, în care se folosesc notații speciale IDEF0 pentru analiză.

Modelul funcțional al companiei

Modelul funcțional IDEF0 este un set de blocuri, fiecare dintre acestea fiind o „cutie neagră” cu intrări și ieșiri, controale și mecanisme care sunt detaliate (descompuse) la nivelul necesar. Cea mai importantă funcție este situată în colțul din stânga sus. Și funcțiile sunt conectate între ele cu ajutorul săgeților și descrierilor blocurilor funcționale. Mai mult, fiecare tip de săgeată sau activitate are propriul său sens. Acest model vă permite să descrieți toate tipurile principale de procese, atât administrative, cât și organizatorice.

Săgețile pot fi:

Inbox - introductiv, care stabilește o anumită sarcină.
Outgoing - afișarea rezultatului activității.
Managerii (de sus în jos) - mecanisme de control (poziții, instrucțiuni etc.).
Mecanisme (de jos în sus) - ceea ce este folosit pentru a produce munca necesară.

Ar fi mai corect să apelați la intrare și la ieșire săgețile de intrare și de ieșire, deoarece în engleză se numesc Input și, respectiv, Output. Dar caracteristicile traducerii și denumirile obișnuite arată deja așa cum au. Și totuși, pentru o înțelegere corectă a termenilor, este important să ne amintim sensul lor în acest caz. Acest lucru este confirmat și de faptul că această notație a fost creată în primul rând pentru dezvoltarea de software și este mai corect să traducem termenii din acest punct de vedere.

Săgețile sunt semnate folosind substantive (experiență, plan, reguli), iar blocurile sunt semnate folosind verbe, de ex. ele descriu acțiunile care sunt efectuate (crearea unui produs, încheierea unui contract, efectuarea unei expedieri).

IDEF0 este un limbaj foarte simplu și în același timp vizual pentru descrierea proceselor de afaceri. Cu ajutorul acestui standard este posibil transferul de informații între dezvoltatori, consultanți și utilizatori. Standardul a fost dezvoltat foarte atent, este convenabil pentru design, universal. Există multe instrumente pentru a lucra cu el, de exemplu, VISIO, BPWIN, ERWIN, Bussines studio etc.

În plus, utilizarea IDEF0 pentru a crea modele de afaceri nu este doar convenabilă, ci este și corectă. Acest instrument a fost conceput pentru business intelligence, a suferit o lungă și amănunțită depanare și lustruire. Prin urmare, utilizarea IDEF0 pentru a crea un model funcțional fără erori este mult mai ușoară decât fără utilizarea acestui standard.

După cum știți, cel mai bine este să bateți cuiele cu un ciocan. Desigur, puteți folosi și alte unelte pentru asta, dar un ciocan este cel mai funcțional și cel mai ușor este să bateți cu el un cui frumos și precis. Deci, cu utilizarea IDEF0 - acest instrument a fost creat pentru modelarea funcțională, iar cu ajutorul lui puteți obține rezultatul dorit mult mai rapid și mai precis.

Un exemplu de creare a unui model funcțional IDEF0

Pentru a înțelege cum să lucrați cu modelarea funcțională, voi da un exemplu al procesului de scriere a unui articol.

Blocul principal este „Scrieți un articol”.

Săgețile primite - „Experiență”, „Informații din surse terțe”. Acestea sunt intrările de care aveți nevoie pentru a începe.

Ghidurile pentru scrierea unui articol sunt „Planul de publicare”, „Cerințele editorilor”, „Regulile limbii ruse”.

Iar în rolul de „Mecanisme” se află autorul, redactorul, corectorul și software-ul. În acest caz, autorul creează un material audio în care adună toate gândurile și ideile care ar trebui să se reflecte în articol. Un copywriter este o persoană care creează, pe baza acestui material, ghidată de cerințele editorului, planul de publicare și regulile limbii ruse, textul final al articolului. Correctorul verifică materialul pentru erori. Iar software-ul este instrumentele pe care toți participanții la proces le folosesc în munca lor.

Astfel, am setat principalii parametri ai procesului, intrarea, ieșirea acestuia, precum și tot ceea ce este necesar de succes proces. Dar acesta este doar cadrul de bază al procesului. Aceasta descrie schema generală a companiei în ansamblu.

De fapt, procesul de creare a unui articol, ca orice proces de afaceri, poate și ar trebui să fie detaliat. Pentru a face acest lucru, descompun blocul general „scrieți un articol” în elemente interconectate.

În cazul nostru, munca este împărțită în 4 etape principale:

Pregătiți audio.
Pregătiți textul
Pregătiți textul pentru publicare.
Plasați un articol într-o publicație.

Diagrama arată clar în ce etapă ce elemente de control și ce mecanisme sunt implicate.

Deci, atunci când creează audio, autorul își folosește cunoștințele și experiența, fiind ghidat de planul de publicare și de cerințele editorului. Copywriterul primește o înregistrare audio ca intrare, din care, ghidat de regulile limbii ruse, creează un text. Correctorul primește textul și îl verifică, ghidându-se tot de regulile limbii ruse. Pentru a plasa un articol într-o publicație, este necesar un software special.

La crearea unui model funcțional parametri cheie sunt scopul și punctul de vedere. Pe baza acestora, modelarea acelorași procese poate arăta oarecum diferită. De exemplu, în cazul meu, scopul este „să vorbesc despre procesul de scriere a unui articol”. Iar punctul de vedere al copywriter-ului este „scrierea și publicarea unui articol din punctul de vedere al managerului de proces”.

Deci, dacă același proces ar fi descris din punctul de vedere al unui copywriter, atunci intrarea ar fi o experiență și un fișier audio de la autor. Mai mult, în acest caz, Experiență ar însemna experiența unui copywriter, dar nu a unui lider sau autor. Prin urmare, primul lucru pe care trebuie să îl determinați atunci când creați un model de proces de afaceri este să alegeți un punct de vedere și să articulați clar scopul.

O astfel de modelare nu este doar vizuală, ci și foarte convenabilă pentru a lua decizii eficiente de management. De exemplu, în procesul de afaceri descris mai sus, există doi specialiști separați - un redactor și un corector. Dacă îmi stabilesc sarcina de a optimiza finanțarea proiectelor, atunci datorită schemei, voi vedea imediat unde este și cum se poate face. Deci, un redactor și un corector folosesc aproximativ aceleași reguli, dar redactorul primește audio și dă rezultatul sub formă de text, în timp ce corectorul acceptă și dă text. Și, prin urmare, dacă este necesar, pot, să zicem, pentru jumătate din costul sarcinilor unui corector, să ofer un copywriter. Așa că voi economisi bani și timp în interacțiunea diferiților specialiști. Desigur, înțeleg toate meritele corectorilor și de ce este mai bine să lucrezi cu specialiști individuali. Dar vă reamintesc că am o sarcină: optimizarea costurilor.

Fără un astfel de instrument vizual, ar fi mai dificil să se determine care dintre blocuri poate fi îndepărtat și astfel să se optimizeze munca.

Cum se creează notații IDEF0

Există multe produse software diferite care pot fi folosite pentru a crea notații. Unele sunt concepute special pentru modelare funcțională, altele sunt concepute pentru orice lucrare cu elemente grafice. Unde și cum construiți aceste modele depinde de dvs.

Personal cred ca la prima etapa nu este nimic mai bun decat hartia obisnuita, un simplu creion si o radiera pentru a face ajustari in caz de greseli.

Pentru a crea o notație pentru procesele de afaceri existente, de ex. pentru a descrie cum funcționează compania acum, este necesar să se studieze principiile muncii. Un specialist terț (consultant, dezvoltator) efectuează un interviu pentru aceasta. În prima etapă, șeful companiei răspunde întrebărilor, apoi, în procesul de detaliere a notării, se desfășoară interviuri cu angajații responsabili pentru diferite etape de lucru.

Este important să înțelegeți că, ca urmare, vor fi necesare 2 notații. Primul va afișa procesele de afaceri așa cum sunt. Il creezi pe baza unui interviu si coordonezi fiecare detaliu cu angajatii companiei si managerul. Este foarte important ca viziunea ta asupra proceselor existente să coincidă cu realitatea, iar aceasta este ceea ce necesită confirmare la toate nivelurile.

A doua notație este „cum ar trebui să fie”. Este creat pe baza primei și a acelor modificări pe care vă propuneți să le aduceți structurii de lucru pentru a optimiza și automatiza activitatea companiei ca parte a sarcinii.

Cerințe IDEF0

Cerințele de bază ale standardului IDEF0, în principiu, le-am descris mai sus și am arătat cu un exemplu.

În colțul din stânga sus este întotdeauna elementul principal.
Toate elementele trebuie să aibă săgeți de intrare și de ieșire, deoarece pentru execuție este necesar să primiți ceva la intrare (comandă, sarcină), iar după procesare la ieșire, este necesar să transferați produsul finit. Săgețile de intrare sunt întotdeauna în stânga, săgețile de ieșire sunt întotdeauna în dreapta.
Mai sus sunt elementele de control, mai jos sunt mecanismele necesare finalizarii procesului.
Dacă există mai multe blocuri pe o foaie (ecran), fiecare bloc următor este situat în dreapta și sub cel anterior.
Este necesar să ne străduim să creați scheme în așa fel încât intersecția săgeților să fie redusă la minimum necesar.

Greșeli comune

Modelarea funcțională se realizează folosind o varietate de instrumente, inclusiv cele care nu sunt destinate modelării. În acest din urmă caz, nu există nicio verificare pentru erori și limitări ale standardului. Dorința de a crește vizibilitatea și lipsa de experiență se termină adesea în erori.

Utilizarea diferitelor culori

Toate elementele din diagramă sunt la fel de importante. În modelarea funcțională nu există elemente mai mult sau mai puțin importante. Dispariția oricăruia va duce la o întrerupere a procesului și la un defect de fabricație.

Adesea, atunci când modelează pe hârtie sau în diferite programe, utilizatorii încearcă să mărească vizibilitatea folosind culori diferite. Aceasta este una dintre cele mai frecvente greșeli. De fapt, utilizarea de săgeți și blocuri multicolore introduce doar confuzie suplimentară și, de asemenea, distorsionează percepția schemei.

Modelul dvs. ar trebui să fie lizibil în alb și negru, fără alte scheme de culori. Această abordare ajută simultan la evitarea neînțelegerilor și disciplinează creatorul modelului, ca urmare, crește lizibilitatea și alfabetizarea modelului.

Prea multe blocuri

Atunci când alcătuiesc un model, ei încearcă adesea să afișeze pe o singură foaie toate nuanțele muncii companiei cu toate detaliile. Rezultatul este un număr foarte mare de blocuri cu un număr mare de săgeți de control. Lizibilitatea este pierdută.

Cea mai bună opțiune este detalierea suficientă pentru a înțelege problema și nimic mai mult. Detaliile detaliate ale activității fiecărui departament sau chiar ale unui angajat pot fi dezvăluite atunci când alegeți o vizualizare detaliată a unui anumit proces. Și o astfel de structură este creată numai dacă este cu adevărat necesară pentru muncă sau luarea deciziilor.

Încălcarea structurii la efectuarea ajustărilor

Urmăriți cu atenție pentru a evita confuzia sau procesele fără elemente de intrare, de ieșire și alte elemente importante. De exemplu, dacă în exemplul de mai sus, consider de cuviință să schimb punctul de vedere la copywriter, voi elimina autorul din schemă. Și atunci controalele „experiența autorului și a surselor terțe”, precum și planul de publicare devin inutile. La urma urmei, autorul le folosește. Copywriter-ul lucrează cu fișierul audio. Și dacă rămân în schema generală, atunci când vor detalia, vor duce de neînțeles unde și vor introduce confuzie.

La fel, dacă decid să adaug un bloc, este important să mă asigur că are și toate atributele necesare. Atenția este foarte importantă aici, deoarece atunci când modelați procese complexe de afaceri, schimbările într-o parte a modelului pot duce la schimbări în alta. Ele trebuie introduse.

Reguli pentru denumirea controalelor și blocurilor

Este important să rețineți o regulă simplă: săgețile de control sunt numite substantive, blocurile sunt numite verbe. Acest lucru este acceptat în standardul IDEF0 și această abordare ajută la evitarea confuziei și erorilor.

Cel mai adesea, greșelile sunt făcute la denumirea blocurilor. De exemplu, în loc de „Creează un articol” se scrie „Creează un articol”. Blocuri înăuntru această abordare sunt acțiuni și, prin urmare, trebuie să fie întotdeauna verbe.

Beneficiile utilizării IDEF0

Primul beneficiu este evident - este vizibilitatea. Tu însuți începi să înțelegi cum funcționează acest sau acel sistem și, de asemenea, poți explica clar unde există „puncte subțiri” în acest sistem și cum soluțiile tale vor ajuta să scapi de ele.
Înțelegere reciprocă și lipsă de dezacord. Când discutați despre munca companiei folosind modelul funcțional, aveți blocuri de sarcini vizuale și intuitive cu controale. În plus, modelarea funcțională presupune crearea, dacă este necesar, a unui glosar în care sunt dezvăluite simboluri și termeni. Drept urmare, dumneavoastră și clientul, managerul și alți angajați vorbiți aceeași limbă atunci când discutați o problemă.
Simplitate și de mare viteză crearea modelului. Desigur, să înveți să modelezi nu este atât de ușor pe cât pare. La urma urmei, o schemă este, de fapt, o prezentare super-densă a informațiilor, care este foarte bună pentru înțelegere, dar este necesară o abordare specială pentru a implementa o astfel de prezentare. Creierul analistului acționează în acest caz ca o presă foarte puternică, pe de o parte, și ca un filtru, pe de altă parte. Dar cu experiență, acest proces devine foarte rapid. Ca rezultat, obțineți un instrument care vă va ajuta să vă dați seama ce se întâmplă într-un anumit sistem și cu ajutorul instrumentului creat în timp scurt ajutoare vizuale pentru a ilustra puncte importante colegilor sau clienților.
Disciplina si fara greseli. Standardul IDEF0 presupune cadre și reguli stricte. Această abordare disciplinează, iar obiceiul de a acționa în cadrul standardului ajută la evitarea greșelilor datorate neatenției. Orice încălcare a standardului devine imediat vizibilă.

Care este dificultatea utilizării IDEF0

Este important de înțeles că doar în cele mai simple cazuri doi analiști de afaceri vor crea exact aceleași modele funcționale pentru a descrie activitatea companiei. Orice model este o reflectare a experienței analistului, a profunzimii de înțelegere a afacerii pe care el încearcă să o descrie și, de asemenea, într-un fel, punctul său de vedere personal asupra acestei afaceri. Acestea. o persoană dezvoltă un model de afaceri din punctul de vedere al liderului, de parcă ar fi liderul.

În același timp, cred că un analist de afaceri nu este chiar o profesie, fiecare manager de afaceri sau dezvoltator al unor sisteme este angajat în analiza de afaceri, care analizează afacerea și se străduiește să construiască cel mai mult sistem eficient. Pentru acești oameni și pentru aceste scopuri este destinat instrumentul IDEF0.

Prin urmare, este foarte important să se consulte în mod constant cu șeful companiei atunci când se elaborează un model de afaceri funcțional „ca atare”, pentru a nu face greșeli care vor atrage automat erori în etapele de descompunere. De asemenea, în etapele ulterioare, pot fi necesare aprobări suplimentare din partea managerilor. diviziuni structurale si angajati. Numai dacă modelul tău funcțional „ca atare” va reflecta într-adevăr starea reală a lucrurilor, poți face câteva modificări și sugestii. Și pentru a realiza rezultate de calitate o astfel de muncă necesită, în primul rând, experiență practică și cunoaștere a caracteristicilor unui anumit tip de afacere.

Ghenadi Vernikov

În prezent, interesul pentru standardele de management general acceptate în Occident a crescut brusc în Rusia, cu toate acestea, în practica reală de management, există un moment foarte semnificativ. Mulți manageri pot fi încă derutați de o întrebare directă despre structura organizatorică a companiei sau despre schema proceselor de afaceri existente. Cei mai avansați și care citesc în mod regulat manageri de periodice economice, de regulă, încep să deseneze diagrame ierarhice care pot fi înțelese numai pentru ei, dar în acest proces, de obicei, se opresc rapid. Același lucru este valabil și pentru angajații și șefii diferitelor servicii și unități funcționale. În cele mai multe cazuri, singurul set de reguli declarate conform cărora o întreprindere trebuie să funcționeze este un set de reglementări și fișe de posturi separate. Cel mai adesea, aceste documente au fost întocmite cu mai bine de un an în urmă, sunt prost structurate și nu au legătură între ele și, ca urmare, pur și simplu adună praf pe rafturi. Deocamdată, o astfel de abordare a fost justificată, deoarece în timpul formării economiei de piață rusă conceptul de concurență a fost practic absent și nu a fost nevoie în mod special de a număra costurile - profitul a fost gigantic. Drept urmare, în ultimii doi ani am văzut o imagine destul de de înțeles: marile companii care au crescut la începutul anilor 90 pierd treptat teren, până la o retragere completă de pe piață. Acest lucru se datorează parțial faptului că standardele de management nu au fost introduse în întreprindere, conceptul de model funcțional de activitate și misiune a fost complet absent. Prin modelarea diferitelor domenii de activitate, este posibil să se analizeze eficient „gâturile de strângere” în management și să se optimizeze schema generală de afaceri. Dar, după cum știți, în orice întreprindere, doar acele proiecte care generează direct profit au cea mai mare prioritate, așa că de obicei este vorba de examinarea activităților și reorganizarea acesteia doar în timpul unei crize tangibile în managementul companiei.

Însuși conceptul de „modelare a proceselor de afaceri” a intrat în viața majorității analiștilor concomitent cu apariția pe piață a unor produse software complexe concepute pentru automatizarea complexă a managementului întreprinderii. Astfel de sisteme implică întotdeauna o analiză profundă înainte de proiect a activităților companiei. Rezultatul acestui sondaj este o opinie de specialitate, în care se fac recomandări în paragrafe separate pentru eliminarea „gâturilor de sticlă” în managementul 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 este, desigur, o echipă care s-a dezvoltat de-a lungul anilor este întotdeauna greu de făcut să „gândească într-un mod nou”. Astfel de anchete cuprinzătoare ale întreprinderilor sunt întotdeauna complexe și diferă semnificativ de la caz la caz. Există metodologii și standarde bine stabilite pentru rezolvarea unor astfel de probleme de modelare a sistemelor complexe. Aceste standarde includ familia de metodologii IDEF. Cu ajutorul lor, puteți afișa și analiza eficient modelele de activitate ale unei game largi de sisteme complexe în diferite secțiuni. În același timp, lărgimea și profunzimea examinării proceselor din sistem sunt determinate de însuși dezvoltatorul, ceea ce permite să nu supraîncărcați modelul creat cu date inutile. În prezent, următoarele standarde pot fi atribuite familiei IDEF:

IDEF1 - o metodologie de modelare a fluxurilor de informații în cadrul unui sistem care vă permite să afișați și să analizați structura și relațiile acestora;

IDEF1X (IDEF1 Extended) - o metodologie pentru construirea structurilor relaționale. IDEF1X aparține tipului de metodologie Entity-Relationship (ER) și este utilizat în mod obișnuit pentru modelarea bazelor de date relaționale relevante pentru sistemul în cauză;

IDEF2 este o metodologie pentru modelarea dinamică a evoluției sistemelor. În legătură cu dificultățile foarte serioase în analiza sistemelor dinamice, acest standard a fost practic abandonat, iar dezvoltarea lui a fost suspendată chiar în stadiul inițial. Cu toate acestea, în prezent există algoritmi și implementări computerizate ale acestora care permit transformarea unui set de diagrame IDEF0 statice în modele dinamice construite pe baza „rețelelor Petri colorate” (CPN - Color Petri Nets);

Istoria standardului IDEF0

Metodologia IDEF0 poate fi considerată următoarea etapă în dezvoltarea cunoscutului limbaj grafic pentru descrierea sistemelor funcționale SADT (Structured Analysis and Design Teqnique). În urmă cu câțiva ani, în Rusia a fost publicată o mică ediție a unei cărți cu același nume, 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 program extins de automatizare industrială, care a purtat denumirea ICAM (Integrated Computer Aided Manufacturing) și a fost propus de Departamentul Forțelor Aeriene din SUA. Familia de standarde IDEF în sine ș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 necesitatea dezvoltării de 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 de descriere a proceselor de afaceri, una dintre cerințele noului standard a fost disponibilitatea unei metodologii eficiente de interacțiune în cadrul „analistului-specialist”. Cu alte cuvinte, noua metodă trebuia să ofere lucru în grup la crearea modelului, cu participarea directă a tuturor analiștilor și specialiștilor implicați în proiect.

Elemente și concepte de bază ale IDEF0

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

Primul dintre acestea este conceptul de cutie de activități. Blocul funcțional este reprezentat grafic ca un dreptunghi (vezi Fig. 1) și reprezintă o funcție specifică în cadrul sistemului considerat. Conform cerințelor standardului, denumirea fiecărui bloc funcțional trebuie formulată în mod verbal (de exemplu, „a produce servicii” și nu „a produce servicii”).

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

Partea de sus este „Control”;

Partea stângă este „Intrare”;

Partea dreaptă este setată la „Ieșire”;

Partea de jos are valoarea „Mecanism” (Mecanism).

Fiecare unitate funcțională din cadrul sistemului unic în cauză trebuie să aibă propriul său număr unic de identificare.

Figura 1. Bloc funcţional.

De menționat 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ă respecte niște reguli (afișate de arcul de control) și trebuie să producă un rezultat (arc de ieșire), altfel luarea în considerare a acestuia nu are sens.

Când construiți IDEF0 - diagrame, este important să separați corect arcurile interfeței de intrare de cele de control, ceea ce adesea nu este ușor. De exemplu, Figura 2 prezintă blocul funcțional „Procesează piesa de prelucrat”.

Figura 2.

Figura 3

Al treilea concept de bază al standardului IDEF0 este Descompunerea. Principiul descompunerii se aplică atunci când un proces complex este defalcat în funcțiile sale constitutive. În acest caz, nivelul de detaliu 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 de diagrame individuale, ceea ce îl face mai puțin supraîncărcat și ușor de digerat.

Modelul IDEF0 începe întotdeauna cu o vedere a 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 notă cu identificatorul "A-0".

În textul explicativ pentru diagrama de context trebuie indicat scopul (Scopul) construcției diagramei sub forma unei scurte descrieri și trebuie fixat punctul de vedere (Punctul de vedere).

Definirea și formalizarea scopului dezvoltării unui model IDEF0 este un punct extrem de important. De fapt, scopul determină zonele relevante din sistemul studiat, care trebuie concentrate mai întâi. De exemplu, dacă modelăm activitățile unei întreprinderi pentru a construi un sistem informațional bazat pe acest model în viitor, 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 determină 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, refuzând să detaliați și să studiați elementele individuale care nu sunt necesare, pe baza punctului de vedere ales asupra sistemului. 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 detalierii lor. Acest lucru se datorează faptului că, în final, directorul financiar nu este interesat de aspectele procesării materiilor prime pe mașini de producție, iar tehnologul șef nu este interesat de schemele trasate ale fluxurilor 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 de context afișează sistemul ca întreg, este detaliat î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 de context și se numește diagramă copil (Diagrama copil) în raport cu acesta (fiecare dintre blocurile funcționale aparținând diagramei copil este respectiv numit bloc copil - Child Box). La rândul său, blocul funcțional - strămoșul se numește blocul părinte în raport cu diagrama copil (Parent Box), iar diagrama căreia îi aparține - diagrama părinte (Parent Diagram). Fiecare dintre subfuncțiile diagramei copil poate fi detaliată în continuare printr-o descompunere similară a blocului său funcțional corespunzător. Este important de menționat 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 pe diagrama copil. Acest lucru realizează integritatea structurală a modelului IDEF0. Principiul descompunerii este prezentat clar în Figura 4. Ar trebui să acordați atenție relației dintre numerotarea blocurilor funcționale și diagramele - fiecare bloc are propriul său număr de serie unic pe diagramă (numărul din colțul din dreapta jos al dreptunghiului) , iar denumirea din colțul din dreapta indică numărul diagramei copil pentru acest bloc . Absența acestei denumiri indică faptul că nu există nicio descompunere pentru acest bloc.

Adesea există cazuri în care nu are sens să se ia în continuare în considerare arcuri individuale de interfață în diagramele copil sub un anumit nivel în ierarhie sau invers - arcuri individuale nu au sens practic peste un anumit nivel. De exemplu, un arc de interfață care ilustrează un „detaliu” la intrarea în blocul funcțional „Prelucrare pe strung” nu are sens să reflectăm asupra diagramelor de niveluri superioare - acest lucru va supraîncărca diagramele și le va face dificil de citit. Pe de altă parte, este nevoie de a scăpa de arcuri de interfață „conceptuale” separate și de a nu le detalia mai profund decât un anumit nivel. Pentru a rezolva astfel de probleme, standardul IDEF0 prevede conceptul de tunel. Denumirea „tunel” (Arrow Tunnel) sub forma a două paranteze în jurul începutului arcului de interfață înseamnă că acest arc nu a fost moștenit din blocul părinte funcțional și a apărut (din „tunel”) doar pe această diagramă. La rândul său, aceeași desemnare în jurul capătului (săgeata) arcului de interfață în imediata apropiere a blocului receptor înseamnă că acest arc nu va fi afișat și nu va fi luat în considerare în diagrama copil a acestui bloc. 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 „se plonjează mai întâi în tunel”, apoi, dacă este necesar, „se întorc din tunel”.

Ultimul dintre conceptele IDEF0 este Glosarul. Pentru fiecare dintre elementele IDEF0: diagrame, blocuri funcționale, arcuri de interfață, standardul existent presupune crearea și menținerea unui set de definiții corespunzătoare, cuvinte cheie, enunțuri narative 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 interfața de control arc „instrucțiune de plată”, glosarul poate conține o listă de câmpuri corespunzătoare arcului documentului, setul necesar de vize etc. Glosarul completează armonios limbajul grafic vizual, oferind diagramelor informațiile suplimentare necesare.

Figura 4. Descompunerea blocurilor funcționale.

Principii pentru limitarea complexității diagramelor IDEF0

Disciplina muncii în grup privind dezvoltarea unui model IDEF0

Standardul IDEF0 conține un set de proceduri care permit elaborarea și aprobarea unui model de către un grup mare de persoane aparținând diferitelor domenii de activitate ale sistemului care se modelează. De obicei, procesul de dezvoltare este iterativ și constă din următorii pași condiționati:

Distribuirea proiectului spre examinare, aprobări și comentarii. În această etapă, proiectul de model este discutat cu o gamă largă de persoane competente (în ceea ce privește cititorii IDEF0) din întreprindere. În același timp, fiecare dintre diagramele proiectului de model este criticată și comentată în scris, apoi transferată autorului. Autorul, la rândul său, este de acord cu critica în scris sau o respinge cu o declarație a logicii deciziei și returnează din nou proiectul corectat pentru o analiză ulterioară. Acest ciclu continuă până când autorii și cititorii ajung la un consens.

Aprobare model. 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 vedere consistentă a întreprinderii (sistemului) dintr-un punct de vedere dat și pentru un scop dat.
Vizibilitatea limbajului grafic IDEF0 face ca modelul să fie destul de lizibil pentru persoanele care nu au luat parte la proiectul de creare a acestuia, precum și eficient pentru demonstrații și prezentări. Pe 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 folosind instrumente IDEF0

Cu toate acestea, majoritatea managerilor încă consideră aplicarea practică a modelării în standardele IDEF mai mult ca un tribut adus modei decât ca o modalitate eficientă de optimizare a sistemului existent de management al afacerii. Cel mai probabil, acest lucru se datorează unei lipse pronunțate de informații cu privire la aplicarea practică a acestor metodologii și a părtinirii software indispensabile a marii majorități a publicațiilor.

Nu este un secret pentru nimeni că aproape toate proiectele de anchetă și analiză a activităților financiare și economice ale întreprinderilor din Rusia sunt acum legate într-un fel sau altul de construirea sistemelor de control automatizate. Datorită acestui fapt, standardele IDEF în înțelegerea majorității au devenit condițional inseparabile de introducerea tehnologiei informației, deși cu ajutorul lor este uneori posibil să se rezolve eficient chiar și mici probleme locale, literalmente cu un creion și hârtie.

Atunci când desfășurați proiecte complexe de sondaj ale întreprinderilor, dezvoltarea modelelor în standardul IDEF0 vă permite să afișați vizual și eficient întregul mecanism al activităților întreprinderii în secțiunea potrivită. Cel mai important, însă, este capacitatea de colaborare pe care o oferă IDEF0. Î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 într-un timp destul de scurt principiile de bază ale IDEF0 și i-a învățat cum 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 trebuiau să răspundă la următoarele întrebări:

Ce intră în unitate „la intrare”?

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

Cine este responsabil pentru fiecare funcție?

Ce ghidează executantul în îndeplinirea fiecărei funcții?

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

După coordonarea schițelor de diagrame în cadrul fiecărui departament specific, acestea sunt asamblate de către un consultant într-un proiect de model de întreprindere, în care toate elementele de intrare și de ieșire sunt legate. În această etapă, toate inconsecvențele diagramelor individuale și locurile lor controversate sunt remediate. În plus, acest model trece din nou prin departamentele funcționale pentru coordonarea ulterioară și efectuarea ajustărilor necesare. Ca urmare, într-un timp destul de scurt și cu implicarea unui minim de resurse umane din partea companiei de consultanță (și aceste resurse, după cum știți, sunt foarte scumpe), se obține un model IDEF0 al unei întreprinderi conform " Principiul așa cum este și, cel mai important, reprezintă o întreprindere cu posturi de angajați care lucrează în ea și cunosc temeinic toate nuanțele, inclusiv cele informale. În viitor, acest model va fi transferat pentru analiză și procesare către analiștii de afaceri care vor căuta „bloc-urile” în managementul companiei și vor optimiza procesele principale, transformând modelul „Așa cum este” în modelul „Așa cum ar trebui să fie” corespunzător. „reprezentare. 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ă presupune impunerea unor angajați a unor responsabilități suplimentare pentru dezvoltarea și aplicarea practică a noilor metodologii. Cu toate acestea, în cele din urmă, acest lucru se justifică de la sine, deoarece încă una sau două ore de muncă de către angajații individuali pe parcursul mai multor zile poate economisi în mod semnificativ bani pentru plata serviciilor de consultanță de la o companie terță (care, în orice caz, va întrerupe activitatea de aceiași angajați cu chestionare și întrebări). Cât despre angajații întreprinderii înșiși, într-un fel sau altul, nu am întâlnit nicio opoziție exprimată din partea acestora în practica mea.

Concluzia din toate acestea se poate trage după cum urmează: nu este absolut necesar să se vină cu soluții pentru problemele standard de fiecare dată. Ori de câte ori vă confruntați cu necesitatea de a analiza un anumit sistem funcțional (de la sistemul de proiectare a navei spațiale până la procesul de pregătire a unei cine complexe) - utilizați metode dovedite și de rulare de-a lungul anilor. Una dintre aceste metode este IDEF0, care permite utilizarea setului său de instrumente simplu și ușor de înțeles pentru a rezolva probleme complexe de viață.

ultimele articole

2022-06-08 17:49:00
Tarife și echipamente pentru Skylink Internet Echipamente pentru conectarea la Internet de la SkyLink
2022-05-28 07:46:52
Rezolvarea unor probleme versiunea Android a mortal kombat x mobile
2022-05-28 07:46:52
Cum să faci un papagal îmblânzit?

Articole populare

Alegerea editorilor

2022-05-16 11:43:03

Ce este necesar pentru a deschide o întreprindere unică?
Salutări, dragi cititori! Astăzi vom vorbi despre cum să deschideți un IP pe cont propriu în 2020 rapid și ușor. În acest articol, vă voi oferi pas cu pas...
2022-05-16 11:43:03

Evaluarea productivității muncii a managerilor și specialiștilor în managementul personalului Reguli de bază de remunerare
Activitatea de muncă este un efort îndreptat în mod oportun către obținerea unui anumit rezultat. Aceasta este caracteristica principală a lucrării. El intotdeauna...
2022-05-16 11:43:03

Cerințe de calitate
Putem spune că cerințele de bază pentru calitatea produselor sau serviciilor oferite sunt o combinație a caracteristicilor și proprietăților sale, care în ...
2022-05-16 11:43:03

Resurse de turbă Măcinarea extracției turbei
Tolkacheva Elizaveta Sergeevna 9 MOU clasa „G” „Școala secundară nr. 58” Relevanța subiectului Multe țări străine au o economie dezvoltată, datorită unei puternice ...
2022-05-07 03:07:16

Societate pe acțiuni închisă Transtelecom
TTK este unul dintre cei cinci principali operatori de telecomunicații ruși. Principalul acționar al TTK este Russian Railways, care deține 99,99% din acțiunile Companiei. Companie...