Bazele metodologiei idef0. Metodologie de descriere a proceselor bazată pe metodologia IDEF0. Metoda funcțională IDEF0

O imagine valorează cât o mie de cuvinte

Înțelepciunea populară

Adesea, în munca mea, este nevoie nu doar de a studia și de a rezolva o anumită problemă, ci de a identifica locația acesteia în modelul general de funcționare al companiei. Nu este suficient să înțelegeți că o anumită unitate nu funcționează corect, este important să înțelegeți cum interacționează cu ceilalți. În caz contrar, este imposibil să identificați toate problemele existente și să alegeți metoda optimă pentru rezolvarea problemei. Și pentru aceasta trebuie să studiați activitatea companiei și să elaborați modelul funcțional al acesteia.

Desigur, în teorie, managerul ar trebui să aibă un model funcțional al activității companiei și nu contează dacă vorbim despre organizarea muncii unui depozit sau a unui sistem IT de la lead la aplicație. Dar, în realitate, aproape niciodată nu se dovedește a fi și, prin urmare, în procesul de studiu și de căutare a unei soluții la problema clientului, creez, de asemenea, un model funcțional al activității companiei sau un anumit proces (funcție) pe cont propriu.

Câteva cuvinte despre avantajele graficii

După cum știți, modelele funcționale IDEF0 sunt întotdeauna diagrame grafice. Au propriile lor caracteristici și reguli de compunere. Vom vorbi despre asta puțin mai târziu. 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ă toate acestea nu sunt necesare, ar putea explica în cuvinte cum funcționează cutare sau cutare funcție în companie. Despre asta vreau să vorbesc.

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

Prin urmare, ideea lui Sytin a fost cu adevărat revoluționară - a început să imprime copii litografice ale hărților care indică fortificațiile și locațiile unităților militare. Aceste carduri au fost numite „Pentru cititorii de ziare. Alocație.” Ideea s-a dovedit a fi atât de relevantă încât prima ediție a „Beneficiilor” s-a vândut 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 înțeles doar cu cuvinte.

De asemenea, pot da un exemplu similar de neputință a descrierilor verbale din propria mea practică. Unul dintre clienții mei mi-a cerut cu adevărat să îmi asum implementarea unui sistem ERP pentru compania sa. Când am întrebat dacă au specificații tehnice, am primit răspunsul: „Da, au. Dar sunt 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 cotat prețuri vădit umflate. După ce am văzut că specificația tehnică avea de fapt 400 de pagini și consta doar dintr-o descriere text, 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 într-adevăr foarte dificilă.

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

Cunosc și multe alte exemple în care 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 implică întotdeauna schimbarea 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ă ce facem exact - configurarea sau instalarea unui sistem CRM de la zero, crearea unui sistem ERP eficient, integrarea diferitelor sisteme pentru a crește automatizarea muncii în general. În orice caz, mai întâi, trebuie să vă faceți o idee despre schema de lucru existentă și numai după aceea puteți propune unele modificări și puteți gândi opțiuni pentru rezolvarea problemei.

După ce am studiat starea actuală, eu, ca orice alt specialist terț, creez o propunere comercială în care îmi dezvălui cât mai detaliat viziunea asupra situației actuale, precum și acțiunile care trebuie efectuate pentru rezolva problema și, desigur, rezultatul așteptat.

Astfel de rapoarte de anchetă de muncă sunt voluminoase și ocupă 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ți cât mai multe informații detaliate.

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 a erorilor și nicio restricție standard. Dorința de a crește vizibilitatea și lipsa de experiență duc adesea la greșeli.

Folosind culori diferite

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 întreruperea procesului și la defecte de fabricație.

Adesea, atunci când modelează pe hârtie sau în diverse 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 adaugă doar confuzie suplimentară și, de asemenea, distorsionează percepția diagramei.

Modelul dvs. ar trebui să poată fi citit în alb și negru, fără alte scheme de culori. Această abordare ajută simultan la evitarea neînțelegerilor și disciplinează creatorul modelului, rezultând o lizibilitate și alfabetizare crescută a modelului.

Prea multe blocuri

Atunci când elaborează 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. În acest caz, lizibilitatea este pierdută.

Cea mai bună opțiune sunt suficiente detalii pentru a înțelege problema și nimic mai mult. Detaliile detaliate ale activității fiecărui departament sau chiar 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 pentru luarea deciziilor.

Încălcarea structurii la efectuarea ajustărilor

Aveți grijă să vă asigurați că nu există confuzii sau procese fără elemente de intrare, ieșire sau alte elemente importante. De exemplu, dacă în exemplul de mai sus, consider că este necesar să mut punctul de vedere la copywriter, voi elimina autorul din diagramă. Și apoi elementele de control „experiența autorului și sursele terțe”, precum și planul de publicare, devin inutile. La urma urmei, autorul le folosește. Un copywriter lucrează cu un fișier audio. Și dacă rămân în schema generală, atunci când sunt detaliate, vor conduce într-o direcție neclară și vor provoca confuzie.

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

Reguli pentru denumirea elementelor de control și a 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 „Creați un articol”, ei scriu „Crearea unui articol”. Blocurile din această abordare sunt acțiuni și, prin urmare, ar trebui să fie întotdeauna verbe.

Beneficiile utilizării IDEF0

Primul beneficiu este evident – vizibilitatea. Tu însuți începi să înțelegi cum funcționează acest sau acel sistem și, de asemenea, poți explica clar unde sunt „punctele subțiri” din acest sistem și cum soluțiile tale vă vor ajuta să scăpați de ele.
Înțelegerea reciprocă și absența discrepanțelor. Când discutați despre munca unei companii folosind un model funcțional, aveți blocuri vizuale și intuitive de sarcini cu elemente de control. În plus, modelarea funcțională presupune crearea, dacă este necesar, a unui glosar în care sunt dezvăluite convențiile și termenii. Ca rezultat, tu și clientul, managerul și alți angajați vorbiți aceeași limbă atunci când discutați o problemă.
Simplitate și viteză mare de creare a modelului. Desigur, să înveți să modelezi nu este atât de ușor pe cât pare. La urma urmei, o diagramă este, în esență, o prezentare super-densă a informațiilor, care este foarte bună pentru înțelegere, dar implementarea unei astfel de prezentări necesită o abordare specială. 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. Drept urmare, obțineți un instrument care vă va ajuta să vă dați seama ce se întâmplă într-un anumit sistem și, folosind un ajutor vizual creat într-un timp scurt, să ilustrați puncte importante colegilor sau clienților.
Disciplina si fara greseli. Standardul IDEF0 oferă cadre și reguli stricte. Această abordare creează disciplină, 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, profundă a înțelegerii afacerii pe care î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 unui manager, de parcă acesta ar fi managerul.

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

Prin urmare, atunci când se elaborează un model de afaceri funcțional „ca atare”, este foarte important să se consulte în permanență cu șeful companiei pentru a nu face greșeli care vor atrage automat erori în fazele de descompunere. De asemenea, în etapele ulterioare, pot fi necesare aprobări suplimentare de la șefii de departamente și angajați. Numai dacă modelul tău funcțional „ca atare” reflectă cu adevărat starea reală a lucrurilor, poți face orice modificări și sugestii. Și pentru a obține rezultate de înaltă calitate într-o astfel de muncă, în primul rând, sunt necesare experiență practică și cunoașterea caracteristicilor unui anumit tip de afacere.

Mai multe articole pe acest subiect.

Metodologia IDEF0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Orez. 2.1 Tipuri de săgeți

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

Orez. 2.2. Comunicare de ieșire

Orez. 2.3. Comunicarea managementului

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

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

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

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

Orez. 2.4. Feedback de conectare

Orez. 2.5. Feedback de management

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

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

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

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

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

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

Orez. 2.6. Conexiune ieșire-mecanism

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

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

numărul de blocuri pe diagramă - N;

nivel de descompunere a diagramei - L;

echilibrul diagramei - ÎN;

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

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

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

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

Orez. 2.7. Exemplu de grafic dezechilibrat

Să introducem coeficientul de echilibru al diagramei

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

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

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

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

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

Fig.2.8 Dialog de creare a modelului

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

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

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

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

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

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

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

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

Figura 2.9. Diagrama contextului sistemului

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

Determinarea nivelului de acces la sistem.

Selectarea subsistemului.

Acces la subsistem.

Modificarea bazei de date (dacă este necesar).

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

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

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

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

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

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

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

Deschiderea bazei de date.

Executarea cererii.

Generarea de rapoarte.

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

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

Orez. 2.12.

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

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

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

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

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

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

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

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

baza de date a utilizatorilor,

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

baza de date a posturilor vacante,

baza de date a performantelor academice,

baza de date de testare,

DB de evaluări de experți,

CV DB.

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

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

Operatorul creează un set de date temporar și îl oferă administratorului.

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

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

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

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

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

În laboratorul următor va fi realizată o descompunere a lucrării de „Execuție a interogărilor”, ilustrând utilizarea diagramelor DFD pentru a descrie procesele de procesare a informațiilor.

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

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

pentru a doua varianta

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

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

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

Majoritatea celor implicați în implementarea proiectelor legate de crearea sau dezvoltarea sistemelor informaționale corporative sunt de acord cu teza conform căreia clientul are nevoie de un sistem informațional care să crească eficiența întreprinderii. Cu toate acestea, clienții și dezvoltatorii de sisteme informatice vorbesc încă limbi diferite: au înțelegeri diferite despre ceea ce înseamnă creșterea eficienței unei întreprinderi.

Dezvoltatorii de sisteme informatice înțeleg foarte adesea eficiența sporită ca o creștere a numărului de stații de lucru în rețeaua de calculatoare locale (LAN) a unei întreprinderi, o creștere a debitului LAN, o creștere a numărului de documente procesate la stațiile de lucru automatizate (AWS) etc. .

Prin creșterea eficienței unei întreprinderi, clienții înțeleg o creștere a productivității muncii, o reducere a costurilor și o creștere a calității produselor și serviciilor produse. Recent, noi condiții și concepte noi pătrund rapid în viața clienților: strategie de dezvoltare, competențe de bază, arhitectură de afaceri, reguli de afaceri și multe altele.

Pentru ca clientul și dezvoltatorul sistemului informatic să se înțeleagă unul pe celălalt, este necesar ca dezvoltatorul să se reorienteze de la rezolvarea problemelor tehnice de creare sau dezvoltare a unui sistem informatic până la rezolvarea problemelor complexe de creștere a eficienței întreprinderii clientului. Cu această abordare, problema unei modalități eficiente de a studia domeniul de activitate al clientului vine în prim-plan:

studiul arhitecturii de afaceri existente, proceselor de afaceri, regulilor de afaceri, fluxurilor de informații;
identificarea problemelor, blocajelor care afectează negativ eficiența întreprinderii;
dezvoltarea și implementarea măsurilor pentru eliminarea problemelor existente și schimbarea arhitecturii de afaceri a întreprinderii, restructurarea proceselor de afaceri;
dezvoltarea unui proiect specific pentru un sistem informatic corporativ, implementarea acestui proiect si suport pe viitor.

Ca parte a acestei abordări, instrumentele concepute pentru modelarea întreprinderii și reproiectarea proceselor de afaceri sunt concepute pentru a crește eficiența dezvoltatorului de sisteme informatice. Unul dintre reprezentanții acestei familii de instrumente este instrumentele CASE pentru modelarea funcțională a proceselor de afaceri.

Acest articol oferă o prezentare generală a unei clase de instrumente pentru modelarea funcțională a proceselor de afaceri, axată pe utilizarea metodologiei IDEF0.

IDEF0 - metodologia de modelare funcțională

În timpul implementării programului Integrated Computerization of Manufacturing (ICAM), propus la un moment dat de către Forțele Aeriene pentru industria aerospațială din SUA, a fost identificată necesitatea dezvoltării unor metode de analiză a interacțiunii proceselor din sistemele de producție. Pentru a răspunde acestei necesități, a fost dezvoltată metodologia IDEF0 (Modelarea funcției de definiție integrată), care este acum adoptată ca standard federal din SUA. Metodologia a fost aplicată cu succes într-o mare varietate de industrii, demonstrându-se ca un mijloc eficient de analiză, proiectare și reprezentare a proceselor de afaceri. În prezent, metodologia IDEF0 este utilizată pe scară largă nu numai în Statele Unite, ci în întreaga lume. În Rusia, IDEF0 a fost utilizat cu succes în agențiile guvernamentale (de exemplu, în Inspectoratul Fiscal de Stat), în industria aerospațială (la proiectarea cosmodromului Plesetsk), în Banca Centrală și băncile comerciale din Rusia, în industria petrolului și gazelor. și în alte industrii.

IDEF0 Concepte de bază

Metodologia IDEF0 se bazează pe conceptul de bloc care reprezintă o anumită funcție de business. Cele patru laturi ale blocului au roluri diferite: partea stângă are sensul de „intrare”, partea dreaptă are sensul de „ieșire”, partea de sus are sensul de „control”, iar partea de jos are sensul de „ mecanism” (vezi Fig. 1).

Interacțiunea dintre funcțiile din IDEF0 este reprezentată ca un arc, care afișează fluxul de date sau materiale care provin de la ieșirea unei funcții la intrarea alteia. În funcție de ce parte a blocului este conectat firul, acesta se numește „intrare”, „ieșire”, respectiv „control”.

IDEF0 Principii de modelare

IDEF0 implementează trei principii de bază de modelare a proceselor:

principiul descompunerii funcționale;
principiul limitării complexității;
principiul contextului.

Principiul descompunerii funcționale este o modalitate de modelare a unei situații tipice când orice acțiune, operație, funcție poate fi descompusă (descompusă) în acțiuni, operații, funcții mai simple. Cu alte cuvinte, o funcție complexă de afaceri poate fi reprezentată ca un set de funcții elementare. Prezentând funcțiile grafic, sub formă de blocuri, puteți privi în interiorul blocului și puteți examina în detaliu structura și compoziția acestuia (vezi Fig. 2).

Principiul limitării complexității. Când lucrați cu diagrame IDEF0, este esențial ca acestea să fie lizibile și lizibile. Esența principiului limitării complexității este că numărul de blocuri din diagramă nu trebuie să fie mai mic de două și nu mai mult de șase. Practica arată că respectarea acestui principiu duce la faptul că procesele funcționale prezentate sub forma unui model IDEF0 sunt bine structurate, de înțeles și ușor de analizat.

Principiul unei diagrame de context. Modelarea unui proces de afaceri începe cu construirea unei diagrame de context. Această diagramă arată un singur bloc - principala funcție de afaceri a sistemului modelat. Dacă vorbim despre modelarea unei întregi întreprinderi sau chiar a unei mari divizii, funcția principală de afaceri nu poate fi formulată ca, de exemplu, „vânzarea produselor”. Funcția principală de afaceri a sistemului este „misiunea” sistemului, semnificația sa în lumea exterioară. Este imposibil să formulați corect funcția principală a unei întreprinderi fără a avea o idee despre strategia acesteia.

Atunci când definiți funcția principală de business, trebuie să aveți întotdeauna în vedere scopul modelării și punctul de vedere al modelului. Aceeași întreprindere poate fi descrisă diferit, în funcție de punctul de vedere din care este privită: directorul întreprinderii și inspectorul fiscal văd organizația cu totul diferit.

Diagrama de context joacă un alt rol în modelul funcțional. Ea „fixează” limitele sistemului de afaceri care este modelat prin definirea modului în care sistemul modelat interacționează cu mediul său. Acest lucru se realizează prin descrierea arcurilor conectate la un bloc reprezentând funcția principală de afaceri.

Aplicarea IDEF0

După ce ne-am familiarizat cu conceptele și principiile de bază ale modelării funcționale a proceselor de afaceri, întrebarea firească este: cum ajută acest lucru la îmbunătățirea eficienței și calității activităților unei întreprinderi.

Construirea modelului CA ESTE. Un sondaj de întreprindere este o parte obligatorie a oricărui proiect pentru crearea sau dezvoltarea unui sistem informațional corporativ. Construirea unui model funcțional AS IS vă permite să înregistrați în mod clar ce procese de afaceri sunt efectuate în întreprindere, ce obiecte de informații sunt utilizate la efectuarea proceselor de afaceri și a operațiunilor individuale. Modelul funcțional AS IS este punctul de plecare pentru analiza nevoilor întreprinderii, identificarea problemelor și blocajelor și dezvoltarea unui proiect de îmbunătățire a proceselor de afaceri.

Reguli de afaceri. Un model de proces de afaceri vă permite să identificați și să definiți cu precizie regulile de afaceri utilizate în activitățile unei întreprinderi.

În fig. Figura 3 prezintă un fragment dintr-un model funcțional al fluxului de documente. La efectuarea operațiunii „sortare documente” se folosește regula de afaceri: „nu sunt supuse înregistrării: documentele transmise în copie pentru informare, telegrame și scrisori de autorizație pentru călătorii de afaceri și vacanțe...”. Această regulă este înregistrată în instrucțiunile de flux de documente. Modelul funcțional permite nu numai identificarea existenței acestei reguli, ci și determinarea în timpul cărei operațiuni și la ce loc de muncă ar trebui aplicată.

În cadrul modelului funcțional, regula de afaceri este următoarea: „dacă la recepție se primește un document destinat gestiunii, acesta este supus sortării, în urma căreia, pe baza instrucțiunilor, se stabilește dacă documentul este supus înregistrării sau nu.”

Dacă această regulă de afaceri nu este luată în considerare la dezvoltarea unui sistem informațional, atunci un astfel de sistem va funcționa inadecvat.

Foarte des, regulile de afaceri la o întreprindere nu sunt scrise în instrucțiuni: par să existe, dar par să lipsească. Ca urmare, încercările de a schimba ceva în activitățile unei întreprinderi sau departament pot eșua doar pentru că aceste modificări contrazic regulile de afaceri stabilite.

Obiecte informaționale. Modelul funcțional vă permite să identificați toate obiectele informaționale pe care întreprinderea le operează în activitățile sale. Spre deosebire de modelele de informații (Diagrame de flux de date, IDEF1X), modelul funcțional IDEF0 reflectă exact modul în care obiectele informaționale sunt utilizate în cadrul proceselor de afaceri.

Construirea unui model despre CUM VA FI. Crearea și implementarea unui sistem informațional corporativ duce la modificări ale condițiilor de efectuare a operațiunilor individuale, ale structurii proceselor de afaceri și ale întreprinderii în ansamblu. Acest lucru duce la necesitatea de a schimba sistemul de reguli de afaceri utilizate în întreprindere și de a modifica fișele posturilor angajaților. Modelul funcțional AS WILL BE ne permite să determinăm aceste modificări deja în faza de proiectare a viitorului sistem informațional. Utilizarea modelului funcțional CUM SĂ FI permite nu numai reducerea timpului de implementare a sistemului informațional, ci și reducerea riscurilor asociate cu insensibilitatea personalului la tehnologia informației.

Alocare resurselor. Modelul funcțional vă permite să definiți clar distribuția resurselor între operațiunile procesului de afaceri, ceea ce face posibilă evaluarea eficienței utilizării resurselor.

Această sarcină este deosebit de relevantă atunci când se creează noi procese de afaceri într-o întreprindere. De exemplu, o companie specializată în dezvoltarea de software personalizat a decis să-și creeze propriul departament de vânzări. Un model funcțional al procesului de afaceri pentru vânzarea de software va permite conducerii companiei să determine clar ce resurse trebuie alocate pentru a asigura funcționarea serviciului de vânzări, câți angajați trebuie recrutați pentru a lucra în noul serviciu, ce responsabilități funcționale pe care trebuie să le îndeplinească acești angajați etc.

Sisteme software IDEF0

În prezent, există multe instrumente CASE care sprijină modelarea funcțională în standardul IDEF0.

CONCLUZIE

Metodologia de modelare funcțională IDEF0 este un instrument destul de simplu care permite dezvoltatorilor de sisteme informaționale corporative să studieze domeniul de activitate al clientului și să rezolve probleme pentru a îmbunătăți eficiența acestei activități.

Utilizarea modelării funcționale face posibilă rezolvarea nu numai a problemelor tehnice ale clientului legate de tehnologia informației, ci și a problemelor legate de domeniul de activitate al clientului. Acest lucru vă permite să transformați un proiect de sistem informatic dintr-un „teanc de hârtie”, pentru care clientul nu dorește să plătească, într-un serviciu care îi poate aduce clientului un efect suplimentar comparabil cu automatizarea ulterioară.

Procesul de modelare a afacerii poate fi implementat în cadrul diferitelor tehnici, care diferă în primul rând prin abordarea lor asupra a ceea ce este organizația modelată. În conformitate cu diferite idei despre organizare, metodele sunt de obicei împărțite în bazate pe obiecte și funcționale (structurale).

Tehnici obiect considera organizatia modelata ca un ansamblu de obiecte care interactioneaza – unitati de productie. Un obiect este definit ca o realitate tangibilă - un obiect sau un fenomen care are un comportament clar definit. Scopul utilizării acestei tehnici este de a identifica obiectele care alcătuiesc organizația și de a distribui responsabilități între ele pentru acțiunile efectuate.

Tehnici funcționale, dintre care cea mai cunoscută este tehnica IDEF, consideră organizația ca un set de funcții care transformă fluxul de informații de intrare într-un flux de ieșire. Procesul de conversie a informațiilor consumă anumite resurse. Diferența principală față de tehnica obiectului constă într-o separare clară a funcțiilor (metodele de prelucrare a datelor) de datele în sine.

Din punct de vedere al modelării de afaceri, fiecare dintre abordările prezentate are propriile sale avantaje. Abordarea obiect vă permite să construiți un sistem care este mai rezistent la schimbări și se potrivește mai bine cu cele existente structuri organizatorice. Modelare funcțională se arată bine în cazurile în care structura organizatorică este în proces de schimbare sau este în general slab formată. Abordarea funcțiilor îndeplinite este intuitiv mai bine înțeleasă de interpreți atunci când primesc informații de la aceștia despre activitatea lor curentă.

Metoda funcțională IDEF0

Metodologia IDEF0 poate fi considerată următoarea etapă în dezvoltarea cunoscutului limbaj grafic pentru descrierea sistemelor funcționale SADT (Structured Analysis and Design Technique). Din punct de vedere istoric, IDEF0 ca standard a fost dezvoltat în 1981, ca parte a unui program extins de automatizare industrială numit ICAM (Integrated Computer Aided Manufacturing). Familia de standarde IDEF și-a moștenit denumirea de la numele acestui program (IDEF = Icam DEFinition), iar cea mai recentă ediție a fost lansată în decembrie 1993 de Institutul Național de Standarde și Tehnologie din SUA (NIST).

Scopul metodologiei este de a construi diagrama functionala sistemul studiat, descriind toate procesele necesare cu o acuratețe suficientă pentru modelarea fără ambiguitate a activității sistemului.

Metodologia se bazează pe patru concepte principale: bloc funcțional, arc de interfață, descompunere, glosar.

(Activity Box) reprezintă o anumită funcție specifică în cadrul sistemului în cauză. În conformitate cu cerințele standardului, numele fiecărui bloc funcțional trebuie formulat în starea verbală (de exemplu, „produce servicii”). În diagramă, blocul funcțional este reprezentat ca un dreptunghi (Fig. 6.1). Fiecare dintre cele patru laturi ale blocului funcțional are propriul său sens specific (rol) și:

partea de sus este setată la „Control”;
partea stângă este setată la „Intrare”;
partea dreaptă este setată la „Ieșire”;
partea de jos are semnificația „Mecanism”.

Orez. 6.1.

Arc de interfață(Săgeată) afișează un element de sistem care este procesat de un bloc funcțional sau afectează în alt mod funcția reprezentată de acel bloc funcțional. Arcurile de interfață sunt adesea numite fluxuri sau săgeți.

Cu ajutorul arcelor 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, mașini, angajați etc.) sau fluxuri de date și informații (documente, date, instrucțiuni etc.).

În funcție de ce parte a blocului funcțional se potrivește acest arc de interfață, se numește „incoming”, „outgoing” sau „control”.

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ă 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.

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).

Descompunere(Descompunerea) este un concept de bază al standardului IDEF0. Principiul descompunerii se aplică atunci când un proces complex este împărțit în funcțiile sale constitutive. în care nivelul de detaliu procesul este determinat direct de dezvoltatorul modelului.

Descompunerea vă permite să prezentaț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 mai ușor de digerat.

Ultimul dintre conceptele IDEF0 este Glosar. Pentru fiecare dintre elementele IDEF0 - diagrame, blocuri funcționale, arcuri de interfață - standardul existent necesită 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 unui element dat. Glosarul completează armonios limbajul grafic vizual, oferind diagramelor informațiile suplimentare necesare.

Modelul IDEF0 începe întotdeauna cu o vedere a sistemului ca un întreg – o unitate funcțională cu arcuri de interfață care se extind dincolo de domeniul luat în considerare. Se numește o astfel de diagramă cu un bloc funcțional diagrama de context.

În textul explicativ la diagrama de context trebuie specificat ţintă(Scopul) de a construi o diagramă sub forma unei scurte descriere și înregistrată Punct de vedere(Punct de vedere).

Definirea și formalizarea obiectivului dezvoltării modelului IDEF0 este un punct extrem de important. De fapt, obiectivul definește zonele relevante din sistemul studiat pe care trebuie să se concentreze mai întâi.

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 detalierea și studierea elementelor individuale care nu sunt necesare, pe baza punctului de vedere ales asupra sistemului. Alegerea corectă a punctului de vedere reduce semnificativ timpul petrecut pentru construirea modelului final.

Identificarea subproceselor. În procesul de descompunere, blocul funcțional, care în diagrama de context afișează sistemul ca întreg și este detaliat într-o altă diagramă. Diagrama de al doilea nivel rezultată conține blocuri funcționale care afișează principalele subfuncții ale blocului funcțional diagrama de context, și se numește diagramă copil în raport cu aceasta (fiecare dintre blocurile funcționale aparținând unei diagrame copil se numește cutie copil). La rândul său, blocul funcțional strămoș se numește 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 unei diagrame copil poate fi detaliată în continuare printr-o descompunere similară a blocului său funcțional corespunzător. În fiecare caz de descompunere a unui bloc funcțional, toate arcurile de interfață care intră sau emană din acest bloc sunt fixate pe diagrama copil. Acest lucru realizează integritatea structurală a modelului IDEF0.

Uneori, nu are sens să se ia în considerare în continuare arcuri individuale de interfață de un nivel superior pe diagramele de un nivel inferior sau invers - să reflecte arcuri individuale de un nivel inferior pe diagramele de niveluri superioare - acest lucru va supraîncărca diagramele și le va face greu de inteles. Pentru a rezolva astfel de probleme, standardul IDEF0 oferă conceptul de tunel. Desemnarea „Arrow Tunnel” a două paranteze în jurul începutului unui arc de interfață indică faptul că arcul nu a fost moștenit de la un bloc părinte funcțional și apare (din „tunel”) doar în 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ă faptul că acest arc nu va fi afișat sau 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 sunt mai întâi „cufundate în tunel”, apoi, dacă este necesar, „întors din tunel” .

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 intervievează persoane competente despre structura diferitelor procese, creând modele de activități departamentale. Sunt interesați de răspunsurile la următoarele întrebări:
Ce primește departamentul ca input?
- Ce funcții și în ce ordine sunt îndeplinite în cadrul departamentului?
- Cine este responsabil pentru îndeplinirea fiecărei funcții?
- După ce se ghidează interpretul atunci când îndeplinește fiecare dintre funcții?
- Care este rezultatul muncii departamentului (ieșire)?
Pe baza reglementărilor existente, a documentelor și a rezultatelor sondajului, este creată o schiță de model a modelului.
Distribuirea proiectului pentru revizuire, aprobare și comentariu. În această etapă, proiectul de model este discutat cu o gamă largă de persoane competente (în ceea ce privește IDEF0 - cititori) din întreprindere. În acest caz, fiecare dintre diagramele proiectului de model este criticată și comentată în scris, apoi transferată autorului. Autorul, la rândul său, este de asemenea în scris de acord cu critica sau o respinge, conturând logica deciziei și returnează proiectul revizuit pentru o analiză ulterioară. Acest ciclu continuă până când autorii și cititorii ajung la un consens.
Aprobarea oficială a modelului. Modelul agreat este aprobat de șeful grupului de lucru dacă autorii modelului și cititorii nu au nicio dezacord cu privire la adecvarea acestuia. Modelul final este o vedere coerentă asupra întreprinderii (sistemului) dintr-un punct de vedere dat și pentru un scop dat.

Claritatea limbajului grafic IDEF0 face ca modelul să fie complet lizibil chiar și pentru persoanele care nu au luat parte la proiectul de creare a acestuia, precum și eficient pentru expoziții și prezentări. Pe viitor, pe baza modelului construit, pot fi organizate noi proiecte menite să facă modificări la model.

Diagramele IDEF0 sunt construite folosind programul BPWin. Acestea sunt destinate modelării grafice a proceselor de afaceri în curs

Despre metodologia IDEF0

Metodologia IDEF0 este utilizată pe scară largă datorită notației sale grafice simple și ușor de înțeles, a cărei utilizare pentru construirea unui model este foarte convenabilă. Locul principal în metodologie este dat diagramelor. Diagramele afișează funcțiile sistemului folosind dreptunghiuri geometrice, precum și conexiunile existente între funcții și mediul extern. Relațiile sunt afișate cu ajutorul săgeților. Puteți vedea acest lucru văzând ce oferă diagrama IDEF0, exemple din care puteți găsi în acest articol.

Faptul că doar două primitive grafice sunt utilizate în modelare face posibilă explicarea rapidă a regulilor actuale de interacțiuni IDEF0 acelor persoane care habar nu au despre asta. Prin diagramele IDEF0, clientul este conectat mai rapid la procesele în curs utilizarea unui limbaj grafic vizual. Puteți vedea ce oferă diagrama IDEF0, dintre care exemple sunt prezentate mai jos.

Elemente utilizate pentru IDEF0

După cum sa menționat deja, sunt utilizate 2 tipuri de primitive geometrice: dreptunghiuri și săgeți. Dreptunghiurile reprezintă anumite procese, funcții, locuri de muncă sau sarcini care au obiective și conduc la un rezultat desemnat. Interacțiunea proceselor dintre ele și mediul extern este indicată prin săgeți. IDEF0 distinge 5 tipuri diferite de săgeți.

Utilizări posibile ale IDEF0

Metodologia IDEF0 poate fi folosită pentru a descrie aspectul funcțional al oricărui sistem informațional.

Tipuri de conexiuni între procese IDEF0

Este în interesul modelului să creeze astfel de conexiuni ale construcțiilor astfel încât conexiunile interne să fie cât mai puternice posibil, iar conexiunile externe să fie cât mai slabe posibil. Acesta este punctul forte al modelării cu IDEF0. Puteți vedea exemple de diagrame pentru dvs. și puteți vedea veridicitatea acestor cuvinte. Pentru a facilita stabilirea conexiunilor, altele similare sunt combinate în module. Conexiunile externe sunt stabilite între module, iar conexiunile interne sunt stabilite în cadrul modulelor. Există mai multe tipuri de conexiuni.

1. Legătura ierarhică („parte” - „întreg”).

2. Manager (reglementare, subordonat):

2) feedback de control.

3. Funcționale sau tehnologice:

2) intrare inversă.

3) consumator;

4) logic;

5) metodologic sau colegial;

6) resursă;

7) informativ;

8) temporar;

9) aleatoriu.

Blocuri de construcție și conexiuni în diagrame

Metodologia IDEF0 oferă o serie de reguli și recomandări pentru utilizarea sa și îmbunătățirea calității utilizării. Deci, diagrama afișează un bloc pe care puteți specifica numele sistemului și scopul acestuia. Există 2-5 săgeți care duc către sau dinspre bloc. Puteți avea mai mult sau mai puțin, dar sunt necesare cel puțin două săgeți pentru intrare/ieșire, iar restul sunt pentru lucrări suplimentare și indicarea lor pe diagramă. Dacă săgeata este mai mare de 5, ar trebui să vă gândiți la construcția optimă a modelului și dacă este posibil să îl faceți și mai detaliat.

Blocuri de construcție în diagramele de descompunere

Numărul de blocuri care vor fi pe o diagramă este recomandat să fie 3-6. Dacă sunt mai puține dintre ele, atunci este puțin probabil ca astfel de diagrame să aibă sens. Dacă numărul de blocuri este mare, atunci citirea unei astfel de diagrame va fi foarte dificilă, având în vedere prezența unor săgeți suplimentare. Pentru a îmbunătăți percepția informațiilor, se recomandă plasarea blocurilor de sus în jos și de la stânga la dreapta. Acest aranjament va reflecta logica de execuție a secvenței de procese. Și, de asemenea, săgețile vor crea mai puțină confuzie, având un număr minim de intersecții între ele.

Dacă lansarea unei anumite funcții nu este controlată în niciun fel, iar procesul poate fi lansat în orice moment, atunci această situație este indicată de absența săgeților care indică controlul și intrarea. Dar prezența unei astfel de situații poate indica potențialilor parteneri o anumită instabilitate și necesitatea de a privi mai atent potențialul partener.

Un bloc care are doar o săgeată de intrare indică faptul că procesul primește parametrii de intrare, dar nu are loc niciun control sau ajustare în timpul execuției. Un bloc care are doar o săgeată de control este folosit pentru a indica lucrul care este apelat numai prin ordine specială a sistemului de control. Sunt gestionați și ajustați în toate etapele lor.

Dar un exemplu de construire a unei diagrame IDEF0 vă poate convinge că cel mai complet și cuprinzător tip este o diagramă cu săgeți de intrare și control.

Denumire

Pentru a îmbunătăți percepția vizuală, fiecare bloc și fiecare săgeată ar trebui să aibă propriul nume, care le va permite să fie identificate printre multe alte blocuri și săgeți. Așa arată exemple de diagrame în IDEF0. Un sistem informatic construit cu ajutorul lor va face posibilă înțelegerea tuturor deficiențelor și complexităților modelelor.

Îmbinarea săgeților este adesea folosită și apar întrebări cu privire la denumirea lor. Dar fuzionarea este posibilă numai dacă sunt transferate date omogene, deci nu sunt necesare nume separate, deși pot fi specificate în programul BPWin. De asemenea, dacă există o divergență de săgeți, atunci acestea pot fi denumite separat pentru a înțelege ce este responsabil pentru ce.

Dacă nu există niciun nume după ramură, atunci numele este considerat a fi exact același cu cel dinainte de ramură. Acesta poate fi cazul dacă două blocuri necesită aceleași informații. Diagrama de context IDEF0, al cărei exemplu poate fi găsit în acest articol, va confirma aceste cuvinte.

Informații cu săgeți

Pe acesta ar trebui să fie afișate săgețile care intră și ies din același bloc atunci când se construiește o diagramă de compoziție. Numele figurilor geometrice transferate în diagramă trebuie să repete exact informațiile de cel mai înalt nivel. Dacă două săgeți sunt paralele una cu arcele celeilalte (adică încep pe marginea unui proces și ambele se termină pe aceeași margine a altui proces), atunci poate că pentru a optimiza modelul ar trebui să li se combine și să li se dea un nume adecvat, care este perfect afișat în IDEF0 (pot fi vizualizate exemple de diagrame în Visio).

Un exemplu de implementare a metodologiei IDEF0 pe un model specific

Ați învățat deja ce este o diagramă IDEF0, ați văzut parțial exemple și reguli pentru construirea unor astfel de diagrame. Acum ar trebui să trecem la practică. Pentru o mai bună înțelegere, explicația nu se va baza pe un model „general”, ci pe un exemplu specific, care vă va permite să înțelegeți mai bine și mai pe deplin caracteristicile lucrului cu IDEF0 în programul BPWin.

Un exemplu va fi viteza unui tren din punctul A la punctul B. Trebuie avut în vedere faptul că trenul nu poate atinge o viteză mai mare decât viteza admisă. Această linie este stabilită pe baza experienței de exploatare și a influenței trenurilor pe calea ferată. Trebuie înțeles că scopul trenului este de a transporta pasageri, care, la rândul lor, au plătit pentru a ajunge la destinație în siguranță și confortabil. O diagramă IDEF0 este utilă, exemple din care pot fi găsite în acest articol.

Informația inițială este:

date despre linia de cale;
pașaport pe toată distanța;
planul de traseu.

Date de control:

Instrucțiuni de la șeful, șeful serviciului de cale.
Informații despre fluxul trenurilor existente.
Informații despre reparațiile planificate, reconstrucții și modificări ale căilor.

Rezultatul modelului este:

Limitarea vitezei admise indicând motivul limitării.
Vitezele admise la deplasarea în puncte separate și în timpul transferului de trenuri.

Odată construită diagrama de context, aceasta trebuie detaliată și apoi se creează o diagramă compozită, care va fi diagrama de prim nivel. Acesta va afișa toate funcțiile principale ale sistemului. Metodologia și diagrama IDEF0 pentru care se face descompunerea se numesc părinte. Descompunerea IDEF0 se numește descompunere copil.

Concluzie

După descompunerea la primul nivel, se efectuează descompunerea la al doilea nivel - și așa mai departe până când descompunerea ulterioară își pierde sensul. Toate acestea sunt realizate pentru a obține cea mai detaliată diagramă grafică a proceselor în curs și planificate. Acesta este un exemplu gata făcut de diagramă IDEF0 pe care o puteți utiliza chiar acum.