Adesea, dezvoltatorilor li se cere nu numai să identifice și să rezolve o problemă în activitatea companiei, ci și să determine ce rol joacă aceasta în structura companiei. Pentru că este mai important să înțelegeți modul în care o unitate care funcționează defectuos interacționează cu ceilalți decât să înțelegeți pur și simplu de ce funcționează defectuos. Prin urmare, identificarea oricărei probleme începe cu studierea activității companiei și elaborarea modelului funcțional al acesteia.
Adesea, dezvoltatorilor li se cere nu numai să identifice și să rezolve o problemă în activitatea companiei, ci și să determine ce rol joacă aceasta în structura companiei. Pentru că este mai important să înțelegeți modul în care o unitate care funcționează defectuos interacționează cu ceilalți decât să înțelegeți pur și simplu de ce funcționează defectuos. Prin urmare, identificarea oricărei probleme începe cu studierea activității companiei și elaborarea modelului funcțional al acesteia.
Veți spune că managerul ar trebui să aibă un model funcțional al companiei, indiferent de ce fel de companie vorbește. Dar, după cum arată practica, în majoritatea cazurilor acest model este absent.
Avantaj grafic
Ce sunt modelele IDEF0? Scheme grafice cu caracteristici proprii și reguli de construcție a acestora. De ce grafică? Pentru că este eficient. Acest lucru poate fi văzut în mai multe exemple.
Să ne imaginăm că planul militar al operațiunilor militare a fost explicat în cuvinte, și nu cu ajutorul hărților cu simboluri grafice aplicate acestora. Acum pare imposibil, dar până în a doua jumătate a secolului al XIX-lea a fost exact așa. Grafica ajută să înțelegeți ce să explicați și, în consecință, să înțelegeți ce este suficient de dificil.
Același lucru este și cu procesele de afaceri: multe sarcini tehnice pot fi întocmite sub formă de notații grafice, care vor simplifica foarte mult sarcina pentru dezvoltatori și vor economisi bani pentru clienți.
Beneficiile IDEF0 pentruACEASTA-specialisti
Activitățile dezvoltatorilor, fie că este, de exemplu, instalarea unui CRM sau crearea unui ERP eficient, este asociată cu efectuarea de modificări la un sistem deja stabilit. Și pentru a o face corect, mai întâi trebuie să studiați cum funcționează acest sistem. După ce o studiază, dezvoltatorul scrie o propunere comercială în care își expune viziunea asupra situației, acțiunile necesare pentru rezolvarea problemei, precum și rezultatul așteptat. Un astfel de document poate dura mai mult de o duzină de pagini. Acest lucru, pe de o parte, este bun, deoarece clientul primește maximum de informații care îl interesează. Pe de altă parte, este nevoie de timp pentru a studia un text lung. om de afaceri de succes adesea nu.
Deci, cum este posibil să transmitem esența fără a recurge la texte voluminoase? Grafică! Ea este cea care vă permite să scurtați ceea ce este scris, demonstrând clar informatie necesara... La urma urmei, o imagine poate înlocui sute de cuvinte. Și în legătură cu utilizarea graficelor în descrierea proceselor de afaceri, acest lucru este 100% adevărat.
Să înțelegem mai întâi ce sunt notația și IDEF0 și pentru ce sunt acestea.
Notație pentru descrierea proceselor de afaceri: ce este
Notația este un format în care procesele de afaceri sunt reprezentate sub formă de obiecte grafice utilizate în modelare și reguli de modelare directă. Notația este un fel de limbaj grafic care vă permite să reprezentați funcționarea unei companii, demonstrând relația dintre departamente și divizii. Adică, notația poate fi considerată un fel de limbaj de programare în business intelligence.
IDEF0 este...
IDEF0 este o metodă de modelare funcțională și o notație grafică care este utilizată pentru a descrie și formaliza procesele de afaceri. Particularitatea IDEF0 este că această metodologie se concentrează pe subordonarea obiectelor. IDEF0 a fost dezvoltat pentru automatizarea întreprinderilor încă din 1981 în Statele Unite.
Modelul functional al companiei
Modelul funcțional IDEF0 este blocuri, fiecare cu mai multe intrări și ieșiri. Fiecare bloc are comenzi și mecanisme detaliate până la nivelul cerut... Cea mai importantă funcție este situată în colțul din stânga sus. Se conectează la restul săgeților și la descrierile blocurilor funcționale. Fiecare săgeată sau activitate are propriul său sens. Din acest motiv, un astfel de model este utilizat pentru a descrie orice procese administrative și organizaționale.
Tipuri de săgeți
Sosire sarcinile sunt stabilite.
De ieșire afișează rezultatul activității.
Managerii(săgețile de sus în jos) sunt mecanisme de control.
Mecanisme(săgeți de jos în sus) sunt folosite pentru a efectua lucrările necesare.
Când se lucrează cu un model funcțional, se adoptă următoarele reguli. De exemplu, săgețile sunt denumite cu substantive (reguli, plan etc.), blocuri - cu verbe (ține evidența, încheie un acord).
IDEF0 vă permite să faceți schimb de informații, în timp ce, datorită versatilității și vizibilității sale, participanții la schimb se vor înțelege cu ușurință. IDEF0 a fost dezvoltat și îmbunătățit cu atenție, puteți lucra cu IDEF0 folosind diverse instrumente, de exemplu, ERWIN, VISIO, Bussines studio.
IDEF0 are și un avantaj incontestabil. Această tehnică a fost dezvoltată cu relativ mult timp în urmă și de peste trei decenii a suferit o șlefuire și o ajustare amănunțită. Prin urmare, este posibil să se creeze un model funcțional al unei companii rapid și cu o probabilitate minimă de eroare.
Desigur, există și alte metodologii, așa că de ce recomandăm IDEF0? Puteți tăia o bucată de țeavă metalică cu un ferăstrău, dar, vedeți, este mult mai ușor să faceți acest lucru cu o râșniță. Așa este și cu IDEF0: nu mai există un instrument funcțional pentru modelare, cu el puteți obține ușor și rapid rezultatul de care aveți nevoie.
Cum este creat un model funcțional
Să analizăm crearea unui model funcțional folosind exemplul scrierii unui articol.
Unitatea principala va fi așa numită „Scrierea articolului”.
Ceea ce este necesar pentru a scrie un articol se reflectă în săgețile de intrare- „Experiență”, „Lectură ulterioară”.
Săgețile de control pentru scrierea unui articol - „Schitul articolului”, „Cerințe pentru înregistrare”, „Regulile limbii ruse”.
Mecanismele sunt direct autorul însuși, copywriter, editor, software. Cum sunt organizate aceste mecanisme? Autorul creează textul înregistrând versiunea audio a acestuia. Copywriter-ul transferă textul în format text, concentrându-se pe planul de publicare, respectând cerințele editorului și regulile limbii ruse. Apoi editorul este conectat la lucrare, care verifică articolul, corectând greșelile de vorbire, ortografie și punctuație. Software-ul reprezintă programele și instrumentele pe care participanții la proces le-au folosit pentru a crea articolul.
Toate cele de mai sus sunt doar o schemă generală de lucru, așa că trebuie detaliată.
Să ne întoarcem la modelul nostru și să descompunăm blocul comun în mai multe elemente înrudite.
Deci, întregul proces de scriere a unui articol poate fi împărțit în 4 etape:
- Pregătiți o versiune audio.
- Pregătiți textul tipărit.
- Editarea și pregătirea textului pentru tipărire.
- Publicarea articolului.
Diagrama reflectă informații despre controalele și mecanismele implicate în ce etapă. De exemplu, pentru a crea text de înaltă calitate, autorul folosește propria experiențăși cunoștințe, folosește planul de publicare și cerințele editorului ca ghid. Copywriterul, care creează versiunea tipărită a textului, și editorul, atunci când îl corectează, folosesc regulile limbii ruse. Pentru a publica un articol, de exemplu, într-o publicație online, este necesar un software special.
La pregătirea unui model funcțional, interpretul este ghidat de scopul creării acestuia și de punctul său de vedere.
Modelarea funcțională este utilizată eficient atunci când se realizează diverse decizii de management... În exemplul nostru al procesului de scriere a articolelor, există doi specialiști - un copywriter și un editor. Și cu optimizarea necesară a finanțării proiectelor conform schemei, nu este dificil să determinați cum să faceți acest lucru. Copywriter-ul și corectorul au metode de lucru similare, așa că toată munca poate fi oferită copywriter-ului, deoarece lucrează direct cu textul audio, ceea ce editorul nu poate face. În acest caz, copywriter-ului i se poate oferi să facă această lucrare pentru jumătate din suma care era destinată editorului. Da, din aceasta, calitatea textului se poate pierde, dar sarcina de optimizare a fost finalizată cu succes. Și ar fi mai dificil să faci asta fără o diagramă vizuală.
Procesul de creare a notațieiIDEF0
Există multe programe pentru crearea de notații. Unele sunt concepute pentru a crea modele funcționale, în timp ce altele vă permit să lucrați cu orice obiect grafic. Și pentru cineva, la prima etapă, o foaie de hârtie, un creion și o radieră sunt suficiente.
Înainte de a trece la descrierea activității companiei, adică direct la crearea notării proceselor de afaceri, ar trebui să studiem principiile de funcționare a companiei. Pentru aceasta, un interviu este realizat de un specialist terț. În primul rând răspunde la întrebare șeful companiei, apoi specialiștii care supraveghează alte etape de lucru.
Prima etapă de lucru are ca rezultat două notații. Unul va reflecta procesele de afaceri în forma lor originală. Această notație va fi creată pe baza rezultatelor interviurilor, fiecare detaliu urmând a fi convenit cu șeful companiei și cu angajații acesteia. Este imperativ ca înțelegerea dumneavoastră a proceselor de afaceri existente în companie să coincidă cu realitatea, aceasta necesită confirmare la toate nivelurile.
A doua notație poate fi numită „Așa cum ar trebui să fie”. Este creat pe baza primului cu modificările făcute în conformitate cu sarcina în cauză.
Standardul IDEF0 și cerințele acestuia
Am vorbit despre cerințele de bază ale IDEF0 chiar mai sus.
- Elementul principal este în colțul din stânga sus.
- Fiecare element trebuie să aibă săgeți de intrare și de ieșire. Mai mult, săgețile de intrare sunt în stânga, în dreapta - cele de ieșire.
- Elementele de control sunt situate în partea de sus, mecanismele în partea de jos.
- Când plasați mai multe blocuri pe o singură foaie sau ecran, cele ulterioare sunt plasate în dreapta jos a celui precedent.
- Schemele ar trebui create astfel încât săgețile să se intersecteze cantitate minimă o singura data.
Erori la lucrul cu IDEF0
Ca și în cazul oricărei activități, apar erori la efectuarea modelării funcționale. Să le analizăm pe cele mai tipice.
Folosind mai multe culori
Este important de reținut că în modelarea funcțională toate elementele sunt importante, nu există altele mai importante sau mai puțin importante. Atunci când modelează pe hârtie sau într-unul dintre programele de calculator, utilizatorii încearcă să facă diagrama mai vizuală colorând blocurile și săgețile în culori diferite. Cu toate acestea, în practică, acest lucru nu numai că nu face diagrama mai vizuală, ci, dimpotrivă, duce la confuzie și la faptul că percepția a ceea ce este descris este distorsionată.
Prin urmare, opțiunea ideală este o schemă alb-negru fără utilizarea unor opțiuni suplimentare de culoare. Acest lucru nu numai că va ajuta la eliminarea neînțelegerilor, ci și la disciplinarea directă a creatorului modelului, ceea ce afectează favorabil lizibilitatea și claritatea modelului.
Număr mare de blocuri
Atunci când compun un model funcțional al muncii unei companii, autorii acesteia încearcă adesea să reflecte totul, chiar și cele mai mici detalii. Rezultă o diagramă cu un număr mare de blocuri și săgeți. Ca urmare, lizibilitatea și claritatea acestuia sunt reduse.
Pentru a evita această eroare, utilizați detaliile care vor fi suficiente pentru a înțelege problema. Detaliile detaliate sunt pregătite numai dacă sunt într-adevăr necesare pentru a rezolva o problemă importantă.
Modificarea structurii la remedierea erorilor
Atunci când creați o diagramă, este important ca mai multe procese să nu fie lăsate fără intrare, ieșire sau altele elemente importante... De exemplu, dacă doriți să eliminați un autor din schemă, atunci trebuie să eliminați toate elementele și săgețile legate direct de el. Dacă rămân în schemă, atunci va exista neînțelegere și confuzie, deoarece în timpul detalierii vor duce la nimeni unde nu știe.
Aceeași situație apare și cu adăugarea unui bloc. Dacă trebuie să completați orice informație, verificați dacă ați furnizat atributele necesare. Acest lucru ar trebui monitorizat îndeaproape, deoarece atunci când modelați procese de afaceri complexe, chiar și o mică schimbare într-o parte va atrage modificări în alta.
Numele blocurilor și comenzilor
Regulile de denumire a elementelor modelului sunt destul de simple, dar este extrem de important să le reținem: săgețile de control sunt numite substantive, blocurile sunt numite verbe. Această regulă este scrisă în standardul IDEF0 și ajută la evitarea confuziei și erorilor.
Beneficiile utilizării IDEF0
Vizibilitate. Reprezentând activitatea companiei sub forma unei diagrame, devine clar cum funcționează compania, unde pot apărea problemele și cum să preveniți apariția lor.
Înțelegerea reciprocă, excluderea posibilității de interpretare greșită a schemei. Vizibilitatea și accesibilitatea modelului funcțional, reprezentând munca companiei sub formă de blocuri și elemente de control, vă vor ajuta atunci când discutați cu conducerea funcționării companiei lor. Apropo, dacă este necesar, se creează un glosar pentru modelul funcțional, care conține toți termenii și convențiile. Astfel, posibilitatea unei neînțelegeri între dumneavoastră și manager, angajații companiei, este minimizată.
Simplitate și economie de timp la crearea unui model. Desigur, este nevoie de mult timp pentru a fi bun la modelarea funcțională. În primul rând, trebuie să învățați cum să prezentați o cantitate imensă de informații sub forma unei scheme laconice, de exemplu. să poată filtra și comprima datele originale. Dar timpul și efortul petrecut pentru antrenament sunt mai mult decât răsplătiți mai târziu. La urma urmei, nu va dura mult timp pentru a crea un model funcțional și a-l prezenta într-un mod accesibil.
Probabilitate minimă de eroare. Lucrul conform standardului IDEF0 necesită respectarea strictă a regulilor acestuia. Acest lucru disciplinează executantul și elimină posibilitatea erorilor. În plus, orice nerespectare a standardului devine imediat vizibilă.
Și, în sfârșit
Pentru doi analiști de afaceri, modelele funcționale pot fi aceleași doar dacă structura companiei este extrem de simplă. În alte cazuri, modelele vor diferi unele de altele. Acest lucru este firesc, pentru că fiecare analist are propria sa anumită experiență, propria înțelegere a funcționării companiei, propriul punct de vedere asupra modului de rezolvare a sarcinilor care îi sunt atribuite. Un analist de afaceri dezvoltă un model funcțional din punctul de vedere al unui manager, își imaginează cum ar rezolva sarcinile atribuite.
În opinia noastră, instrumentul IDEF0 va fi util nu numai pentru analiștii de afaceri profesioniști, ci și pentru cei care își analizează direct afacerea și se străduiesc să construiască sistem eficient management.
Descrierea diagramelor proceselor de afaceri „Contabilitatea echipamentelor informatice ale întreprinderii”
Descrierea diagramei IDEF0
Pentru a construi un proces de afaceri, a fost folosită o diagramă IDEF0. Metodologia IDEF0 prescrie construirea unui sistem ierarhic de diagrame - descrieri unice ale fragmentelor de sistem. În primul rând, se realizează o descriere a sistemului în ansamblu și a interacțiunii acestuia cu lumea exterioară (diagrama contextului). Au fost construite trei niveluri ale diagramei:
1. Contextual
2. Descompunerea functionala
Figura 1 - Diagrama de context „Contabilitatea tehnologia calculatoarelor intreprinderi"
Figura 1 prezintă o diagramă de context a procesului de afaceri „Contabilitatea echipamentelor informatice ale întreprinderii”. Afișează sistemul ca întreg și interacțiunea acestuia cu principalele fluxuri externe de informații.
Săgețile sunt indicate în diagrama de context.
Tipuri de săgeți:
Intrare (materiale de intrare: computere și accesorii)
Ieșire (ieșirea este un raport)
Săgețile de control sunt documente și manageri
Săgețile mecanismelor sunt angajați și echipamente
Informații de intrare pentru procesare:
Calculatoare - PC-uri (calculatoare personale) situate în întreprindere
Componente - materiale necesare pentru modernizarea calculatoarelor (placi video, placi de baza, procesoare, carcase, surse de alimentare, module de memorie)
Fluxuri de ieșire:
Raport - un raport gata făcut cu privire la contabilitatea echipamentelor informatice ale întreprinderii
Comenzi de intrare:
Reguli - conditii care trebuie indeplinite pentru atingerea scopului.
Comenzi - sarcina atribuită întreprinderii (să țină evidența echipamentelor informatice la întreprindere folosind anumite sisteme informatice)
Managerii sunt directori și directori generali ai întreprinderii.
Resurse de intrare:
PC - calculatoare cu ajutorul cărora se realizează contabilitatea.
Angajații sunt specialiști care execută instrucțiunile atribuite de conducere. După construirea modelului conceptual, a fost efectuată o descompunere funcțională - sistemul este împărțit în subsisteme și fiecare subsistem este descris separat (diagrame de descompunere).
Figura 2 prezintă o descompunere funcțională a patru locuri de muncă.
Figura 2 - Descompunerea funcțională „Contabilitatea echipamentelor informatice ale întreprinderii”
Au fost identificate următoarele tipuri de lucrări:
1) Înregistrarea livrărilor - procesul în care se atribuie id-ul produsului, se trimite la depozitare, la depozit și se introduc în program informații despre produs.
Lucrarea Înregistrarea proviziilor include șapte săgeți de delimitare (intrare, control, mecanism) și o săgeată interioară frunze (conexiune la intrare).
Comunicare sageata la intrarea intre lucrari Inregistrarea livrarilor si intretinerea calculatorului (calculatorului);
Săgețile de intrare, ieșire, control sunt repetate în lucrările ulterioare.
2) Întreținerea calculatoarelor - procesul în care are loc asamblarea, repararea și modernizarea calculatoarelor.
Lucrarea de întreținere a computerului include patru săgeți de delimitare (intrare, control, mecanism, ieșire) și mai multe săgeți interne (comunicare de intrare, Părere la intrare).
Control cu săgeți - reguli, ordine, lider;
Conexiune săgeată la intrarea între locurile de muncă Întreținere computer și Plasament (introducerea datelor în baza de date), între locurile de muncă Întreținere calculatoare și Raportare (introducerea datelor în baza de date);
3) Plasament - procesul în care are loc amplasarea calculatoarelor în birouri (birouri).
Controlul săgeților - reguli, ordine, lider;
Mecanism săgeată - angajați;
Legătură săgeată la intrare între Spreading și Raportare (atribuirea unui id);
4) Întocmirea unui raport - etapa finală a procesului contabil, care constă în rezumarea totalurilor obţinute prin efectuarea datelor anterioare ale contabilităţii curente.
Apoi, fiecare subsistem este defalcat în descompuneri mai mici și așa mai departe, până când este atins nivelul dorit de detaliu.
Figura 3 este o diagramă care arată activitatea Procesului de achiziție mai detaliat.
Ca urmare a detalierii, au fost evidențiate principalele funcții. Secțiunea „Înregistrarea proviziilor” include șapte săgeți principale (intrare, ieșire, control, mecanism).
Sageata de intrare - calculatoare si accesorii;
Săgețile de control sunt reguli, ordine și un lider. Săgeți bifurcate;
Săgeți mecanism, ramificare - PC, angajați;
Săgețile pentru intrare, control, mecanisme se repetă în toate lucrările.
1) Atribuirea numerelor - atribuirea numerelor individuale calculatoarelor și accesoriilor.
Săgeți de intrare - computere și accesorii. Calculatoarele cu săgeți se repetă în lucrările ulterioare, cu excepția întocmirii raportului;
Săgeți de control - reguli, ordine și lider;
Mecanism Arrows - PC și angajați;
Legătură săgeată la intrarea între lucrări Atribuire număr și Trimitere mărfuri la depozit (transfer), între Atribuire număr și Punere la echilibru (intrare în bază);
2) Trimiterea mărfurilor la depozit - trimiterea mărfurilor cu numărul atribuit la depozit.
Săgeată de ieșire - Computer;
Săgețile de control - reguli, ordine și lider.
Legătură săgeată la intrarea între lucrările „Trimiterea mărfurilor la depozit” și „Setarea în bilanţ” (cantitate);
3) Echilibrare - introducerea de informații într-un computer.
Săgeți de control - reguli, ordine și lider;
Mecanism Arrows - PC și angajați;
Figura 4 este o diagramă care detaliază întreținerea computerului în detaliu.
Ca urmare a detalierii, au fost evidențiate principalele funcții îndeplinite în procesul de deservire a unui computer.
Lucrarea de întreținere a computerului include 4 săgeți de delimitare (intrare, ieșire, control, mecanism). Săgeți interne (feedback de intrare, comunicare de intrare).
1) Asamblarea calculatoarelor - configurarea calculatoarelor pentru comenzile individuale ale managerilor.
Sageata de intrare - calculatoare;
Săgeți de control - reguli, ordine și lider;
Mecanism Arrows - Angajati;
Legătură săgeată la intrarea între lucrări: „Asamblare calculatoare” și „Reparare calculatoare” (calculator);
2) Reparatie calculatoare - montaj calculatoare aprobate pentru perfectionare.
Sageata de intrare - calculatoare;
Săgeată de ieșire - intrare în bază;
Săgeți de control - reguli, ordine și lider;
Mecanism Arrows - Angajati;
Săgețile de intrare, ieșire, control, mecanism se ramifică;
Legătură săgeată la intrarea între lucrări: „Reparație computer” și „Upgrade” (accesorii);
3) Upgrade - îmbunătățire, îmbunătățire, upgrade a computerului.
Săgeată de ieșire - intrare în bază;
Săgeți de control - reguli, ordine și lider;
Mecanism Arrows - Angajati;
Săgețile de control, mecanismul se ramifică;
Figura 5 prezintă diagrama de raportare mai detaliat. Descompunerea lucrării Raportarea include 4 săgeți de delimitare (intrare, ieșire, control, mecanisme). Săgeți interne (feedback de intrare, comunicare de intrare).
În urma lucrărilor, au fost derivate următoarele funcții:
1) Colectarea datelor - colectarea de informatii pentru analiza si luarea deciziilor.
Introduceți săgeata - atribuire id;
Săgeți de control - reguli, ordine și lider;
Săgețile de intrare, control, mecanism se ramifică;
Legătură săgeată la intrarea între locuri de muncă: Colectarea datelor și validarea datelor (înregistrări);
2) Verificarea datelor - verificarea informatiilor si transmiterea acestora la intocmirea unui raport.
Săgeată de autentificare - atribuirea unui id, introducerea datelor în baza de date;
Săgeată de ieșire - Raport;
Săgeți de control - reguli, ordine și lider;
Mecanism Arrows - Angajati, PC;
Săgețile de intrare (atribuirea id-ului), control, mecanism sunt bifurcate;
Introduceți săgeata de feedback de la „Verificarea datelor” la „Achiziția datelor” (verificare repetată).
Descrierea diagramei DFD
În descompunerea lucrării „Întreținerea computerului” Figura 1, patru munca internă, două entități externe și două depozite de date.
Figura 1 - Întreținerea computerului
1) Asamblare computer - procesul de asamblare a unui computer din componentele existente.
2) Întocmirea unui raport - proces care constă în rezumarea indicatorilor finali obţinuţi prin efectuarea lucrărilor contabilităţii curente.
3) Diagnosticare - verificarea performantei
4) Upgrade - îmbunătățire, îmbunătățire, upgrade a computerului.
Entități externe: calculatoare și componente
Depozitele de date:
1) Depozit - un loc unde sunt stocate computerele asamblate și modernizate.
2) DB - o bază de date care stochează toate rapoartele și toate informațiile despre munca depusă.
Colectăm informații despre computer și selectăm componente pentru asamblarea acestuia. Apoi asamblam computerul si il trimitem la depozit pentru depozitare, dar in afara de asta, dupa asamblare, il putem trimite mai intai pentru diagnosticare, verifica operabilitatea, si apoi doar la depozit. După diagnosticarea computerului asamblat, trimitem datele pentru a întocmi un raport despre munca depusă și introducem informațiile în Baza de date.
Avem și o altă entitate externă, acesta este un computer. Îl trimitem spre modernizare, apoi pentru diagnosticare pentru a-i verifica performanța, apoi întocmim un raport și introducem informații despre munca depusă în Baza de date. Sau, dupa modernizare, trimitem marfa la depozit, iar apoi efectuam diagnostice, intocmim raport si introducem informatiile in Baza de date.
Descompunerea lucrărilor „Raportare” Figura 2 definește trei activități interne, trei entități externe și două depozite de date.
1) Colectarea datelor - colectarea de informații despre calculatoare și componente.
2) Validare - verificarea acurateței datelor.
3) Raport - redactarea unui raport asupra muncii efectuate.
Entități externe: componente, calculatoare, manager.
Depozit de date - Date despre computere și componente, date din raport.
Colectarea de informații despre computere și accesorii, apoi trimiterea acestora pentru stocare. După aceea, verificăm exactitatea datelor, întocmim un raport și îl trimitem înapoi pentru stocare la primul depozit de date (Figura 2) sau trimitem datele raportului la al doilea depozit de date (Figura 2) și apoi le trimitem către manager pentru verificare.
Managerul verifică, face note, corectează și trimite spre reverificare. După aceea, raportul este trimis pentru stocare până când managerul este din nou verificat.
Descrierea diagramei IDEF3
În descompunerea lucrărilor Întreținerea calculatoarelor (Fig. 1), sunt definite mai multe intersecții care leagă unul sau mai multe joburi, mai multe joburi interne.
1) Reparatie - asamblarea calculatorului cu componente prefabricate
2) Asamblare - readucerea calculatorului la normal
3) Upgrade - upgrade computer
4) Calculatoare - un produs după asamblare și modernizare
5) Trimiteți la depozit - trimiteți la depozitare după îmbunătățire (asamblare)
6) Diagnosticare - verificarea performantei.
7) Raport - informații despre munca depusă.
Intersecții - Conectori:
1) J2 - toate acțiunile încep în același timp.
2) J6 - Joncțiunea de confluență. Un nod care adună multe săgeți într-unul singur, indicând necesitatea condiției de finalizare a surselor de lucru de săgeți pentru a continua procesul.
3) J7 - se arata ca aceste conditii nu pot fi indeplinite simultan.
4) J9 - aceste actiuni se incheie in acelasi timp dupa care se intocmeste un proces-verbal de munca depusa.
Diagrama IDEF3 arată că joncțiunea J2 are două săgeți de ramificare pentru lucru (build și upgrade) care încep în același timp. Abia după finalizarea acestor lucrări iese produsul finit (calculatorul), leagă intersecția J6. După aceea, există o legătură la intersecția J7, care arată că două lucrări (trimiterea mărfurilor la depozit și diagnosticare) nu pot fi efectuate simultan. După finalizarea lucrărilor anterioare, este în derulare procesul de întocmire a unui proces-verbal de lucru, care este conectat prin nodul J9.
Obiectiv:
- studierea principiilor de bază ale metodologiei IDEF0,
- crearea unui nou proiect în BPWin,
- formarea unei diagrame de context,
- a face legături.
Descrierea unui sistem folosind IDEF0 se numește model funcțional. Modelul funcțional are scopul de a descrie procesele de afaceri existente în care sunt utilizate atât limbaje naturale, cât și limbaje grafice. Pentru a transmite informații despre un anumit sistem, sursa limbajului grafic este însăși metodologia IDEF0.
Metodologia IDEF0 prescrie construirea unui sistem ierarhic de diagrame - descrieri unice ale fragmentelor de sistem. În primul rând, sistemul în ansamblu și interacțiunea acestuia cu lumea exterioară sunt descrise (diagrama contextului), după care se realizează descompunerea funcțională - sistemul este împărțit în subsisteme și fiecare subsistem este descris separat (diagramele de descompunere). Apoi, fiecare subsistem este împărțit în altele mai mici și așa mai departe până când este atins nivelul dorit de detaliu.
Fiecare IDEF0-diagrame a conține blocuri și arce. Blocurile reprezintă funcțiile sistemului simulat. 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 în timp și au rezultate recunoscute. Numele postului trebuie exprimat printr-un substantiv verbal care denotă o acțiune.
IDEF0 necesită ca o diagramă să aibă cel puțin trei și nu mai mult de șase blocuri. Aceste constrângeri mențin complexitatea diagramelor și modelelor la un nivel care este lizibil, înțeles și utilizabil.
Fiecare parte a blocului are un scop specific, bine definit. 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 conversiilor, mecanismele arată ce și cum funcționează o funcție.
Blocurile din IDEF0 sunt aranjate în ordinea importanței, așa cum o înțelege 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 unei diagrame poate fi fie primul dintr-o secvență de funcții cerută, fie o funcție de planificare sau control care le afectează pe toate celelalte.
Blocul cel mai dominant este de obicei situat în colțul din stânga sus al diagramei, iar cel mai puțin dominant în colțul din dreapta.
Dispunerea blocurilor pe pagină reflectă definiția autorului a dominantei. Astfel, topologia diagramei arată care caracteristici au cel mai mare impact asupra celorlalte. Pentru a sublinia acest lucru, analistul poate renumerota blocurile în funcție de ordinea lor de dominanță. Ordinea dominantă poate fi indicată printr-un număr plasat în colțul din dreapta jos al fiecărui dreptunghi: 1 va indica cea mai mare dominanță, 2 va indica următorul etc.
Interacțiunea lucrărilor cu lumea exterioară și între ele este descrisă sub formă de săgeți, reprezentate prin linii unice cu săgeți la capete. Săgețile reprezintă un fel de informații și sunt denumite cu substantive.
Tipuri de săgeți
IDEF0 distinge între cinci tipuri de săgeți.
Intrare- obiecte folosite și transformate prin muncă pentru a obține un rezultat (ieșire). Se presupune că lucrarea poate să nu aibă săgeți de intrare. Săgeata de intrare este desenată ca intrând în partea stângă a lucrării.
Control-.informaţii care reglementează activităţile postului. În mod obișnuit, săgețile de control poartă informații care indică faptul că lucrarea urmează să fie efectuată. Fiecare job trebuie să aibă cel puțin o săgeată de control, care este descrisă ca intrând în partea superioară a jobului.
Ieșire- obiectele la care sunt convertite intrările. Fiecare job trebuie să aibă cel puțin o săgeată de ieșire, care este desenată ca venind din marginea dreaptă a jobului.
Mecanism- resursele care fac 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 apară pe model.
Apel- o săgeată specială care indică un alt model de lucru. 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 simulat.
Orez. 2.1 Tipuri de săgeți
În metodologia IDEF0, sunt necesare 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. Legăturile de control și de intrare sunt cele mai simple, deoarece reflectă acțiuni directe intuitive și foarte simple.
Orez. 2.2. Ieșiți din comunicare
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 sunt iterații sau recursive. Și anume, rezultatele unui loc de muncă afectează performanțele viitoare ale altor locuri de muncă, care ulterior vor afecta postul inițial.
Feedback-ul managementului are loc atunci; când ieșirea unui bloc afectează blocul cu o dominantă mare.
Relațiile cu mecanismul de ieșire 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 intrare
Orez. 2.5. Feedback de management
Relațiile dintre mecanismele de ieșire sunt obișnuite în alocarea resurselor (de exemplu, instrumentele necesare, personal instruit, spațiu fizic, echipamente, finanțare, materiale).
În IDEF0, un arc rareori descrie un singur obiect. De obicei simbolizează o colecție de obiecte. Deoarece arcurile reprezintă colecții de caracteristici, ele pot avea mai multe puncte de început (surse) și puncte de sfârșit (destinații). Prin urmare, arcurile se pot ramifica și se pot conecta. căi diferite... Întregul arc sau o parte a acestuia poate ieși dintr-unul sau mai multe blocuri și se poate termina în unul sau mai multe blocuri.
Arcurile de bifurcare, prezentate ca linii divergente, înseamnă că tot sau o parte din conținutul arcelor poate apărea în fiecare ramură. Arcul este întotdeauna marcat înainte de bifurcare pentru a da un nume întregului set. În plus, fiecare ramură a unui arc poate fi marcată sau nemarcată conform următoarelor reguli:
- ramurile nemarcate conțin greutatea obiectelor specificate în eticheta arcului înainte de ramură;
- ramurile marcate după punctul de bifurcare conţin toate sau o parte din obiectele specificate în eticheta arcului înainte de bifurcare.
Îmbinarea arcelor în IDEFO, reprezentate ca linii care converg împreună, indică faptul că conținutul fiecărei ramuri formează o etichetă pentru arcul rezultat din îmbinarea arcelor originale. După o îmbinare, arcul rezultat este întotdeauna marcat pentru a indica un nou set de caracteristici după îmbinare. În plus, fiecare ramură poate fi sau nu semnalizată înainte de a fi fuzionată conform următoarelor reguli:
Orez. 2.6. Comunicare ieșire-mecanism
- ramurile nemarcate conțin greutatea obiectelor specificate în eticheta partajată după îmbinare;
- ramurile marcate înainte de îmbinare conțin toate sau unele dintre obiectele enumerate în marcajul general după îmbinare,
Analiza cantitativă a graficelor
Pentru a efectua o analiză cantitativă a diagramelor, enumerăm indicatorii modelului:
- numărul de blocuri din diagramă - N;
- nivelul de descompunere grafic - L;
- diagrama echilibrului - V;
- numărul de săgeți care se conectează la bloc - A
Acest set de factori se aplică fiecărei diagrame din model. Recomandările pentru valorile dorite ale factorilor de diagramă vor fi enumerate mai jos.
Este necesar să ne străduim să ne asigurăm că numărul de blocuri din diagramele nivelurilor inferioare ar fi mai mic decât numărul de blocuri din diagramele părinte, adică odată cu creșterea nivelului de descompunere, coeficientul ar scădea. Astfel, scăderea acestui coeficient sugerează că. că pe măsură ce modelul este descompus, funcțiile ar trebui simplificate, prin urmare, numărul de blocuri ar trebui să scadă.
Graficele trebuie echilibrate. Aceasta înseamnă că, în cadrul unei diagrame, situația prezentată în Fig. 2.7: lucrarea 1 are mult mai multe săgeți de intrare și 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 produsului și o săgeată se poate stinge - produsul finit.
Orez. 2.7. Un exemplu de grafic dezechilibrat
Să introducem factorul de echilibru al diagramei
Este necesar să ne străduim să Kh a fost minim pentru diagramă.
În afară de analiză elemente grafice diagramele trebuie să ia în considerare denumirile blocurilor. Pentru a evalua denumirile, este alcătuit un dicționar de funcții elementare (triviale) ale sistemului modelat. De fapt, funcțiile nivelului inferior de descompunere a diagramei ar trebui să intre în acest dicționar. De exemplu, pentru un model de bază de date, funcțiile „găsiți o înregistrare”, „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 vocabularului și compilarea unui pachet de diagrame de sistem, este necesar să se ia în considerare nivelul inferior al modelului. Dacă există coincidențe ale numelor blocurilor de diagrame și cuvinte din dicționar pe el, atunci acest lucru indică faptul 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 prin 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 coincidențele sunt mai valoroase.
Setul de instrumente BPWin
Când BPWin este lansat, 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).
Figura 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ă un model poate conține atât IDEF0, cât și IDEF3 și diagrame DFD în același timp. Compoziția paletei de instrumente se schimbă automat la trecerea de la o notație la alta.
Un model în BPWin este privit ca o colecție de activități, fiecare dintre ele funcționând pe un anumit set de date. Dacă faceți clic pe orice obiect al modelului cu butonul stâng al mouse-ului, apare un meniu contextual pop-up, fiecare articol corespunzător editorului unei proprietăți a obiectului.
Exemplu
Construirea unui model al unui sistem ar trebui să înceapă cu un studiu al tuturor documentelor care îl descriu. funcţionalitate... Unul dintre aceste documente este termenii de referință, și anume secțiunile „Scopul dezvoltării”, „Obiectivele și obiectivele sistemului” și „ Caracteristici funcționale sisteme”.
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 de angajare în cadrul Universității”, ale cărui principale capacități au fost descrise în munca de laborator nr. 1.
Să formulăm scopul modelării: de a descrie 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ă contextuală IDEF0 - Conform descrierii sistemului, funcția principală este de a-și servi clienții prin procesarea cererilor de la aceștia. Astfel, să definim singura lucrare a diagramei de context ca „Servește clientul de sistem”. În continuare, definim datele de intrare și de ieșire, precum și mecanismele și controalele.
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 interogări duce fie la primirea de informații din sistem, fie la modificarea conținutului bazei de date (de exemplu, la întocmirea evaluărilor experților), prin urmare, datele de ieșire vor fi „rapoarte” și „bază de date modificată”. Procesul de procesare a cererilor va fi efectuat de monitorul sistemului sub controlul administratorului.
Diagrama de context
Astfel, definim diagrama de context a sistemului (Fig. 2.9).
Fig 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ă finalizarea descompunerii diagramei de context, treceți la descompunerea diagramei de nivel următor. În mod obișnuit, când se uită la nivelul al treilea și inferior, modelele revin la diagramele părinte și le ajustează.
Orez. 2.10. Descompunerea lucrării „Serviciul, clientul sistemului”
Descompunem secvenţial toate blocurile diagramei rezultate. Primul pas în determinarea nivelului de acces la sistem este determinarea categoriei utilizatorului. Numele clientului este căutat în baza de utilizatori, definindu-i categoria. Potrivit unei anumite categorii, se clarifică autorizațiile acordate utilizatorului sistemului. În continuare, se efectuează procedura de accesare a sistemului, verificând numele și parola de acces. Prin combinarea informațiilor despre autoritate și nivelul de acces la sistem, se formează un set de acțiuni permise pentru utilizator. Astfel, definiția nivelului de acces la sistem va arăta așa cum se arată în Fig. 2.11.
Orez. 2.11. Descompunerea lucrării „Determinarea nivelului de acces la sistem”
După parcurgerea procedurii de acces la sistem, monitorul analizează solicitarea clientului, alegând un subsistem care va procesa cererea. Descompunerea lucrării „Adresarea unui 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 sa, prin urmare descompunerea apelului la subsistem nu va face decât să complice modelul.
Să descompunem lucrarea „Procesarea cererilor client” efectuată de subsistemul de procesare a cererilor, definind categoriile de utilizatori și permisiunile. Înainte de a căuta un răspuns la o solicitare, trebuie să deschideți baza de date (conectați-vă la aceasta). Î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ă definim succesiunea lucrărilor:
- Deschiderea bazei de date.
- Executarea cererii.
- Generarea de rapoarte.
După deschiderea bazei de date, este necesar să se informeze sistemul despre stabilirea unei conexiuni cu baza de date, apoi se execută cererea și se generează rapoarte pentru utilizator (Fig. 2.12).
Trebuie remarcat faptul că „Executarea unei cereri” include activitatea diferitelor subsisteme. De exemplu, dacă cererea include testarea, atunci aceasta va fi executată printr-un subsistem de teste profesionale și psihologice. În etapa de execuție a interogării, poate fi necesară modificarea conținutului bazei de date, de exemplu, la elaborarea evaluărilor experților. Prin urmare, diagrama trebuie să prevadă o astfel de posibilitate.
Orez. 2.12.
Ajustarea diagramei
La analiza diagramei rezultate se pune întrebarea, care sunt regulile de generare a rapoartelor? Este necesar să existe șabloane preformate, în funcție de care se va face selecția din baza de date, iar aceste șabloane trebuie să corespundă solicitărilor și să fie predeterminate. În plus, clientului ar trebui să i se ofere posibilitatea de a alege forma raportului.
Să corectăm diagrama adăugând săgețile „Șabloane de raport” și „Solicitări de modificare a bazei de date” și săgeata de tunel „Client de sistem”. Tunnelarea „Clientului de sistem” se aplică 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-l afișa pe diagrama părinte.
Schimbarea diagramei va duce la ajustarea tuturor diagramelor părinte (Fig. 2.13 - 2.15).
Este recomandabil să descompuneți lucrarea „Executarea unei interogări” folosind diagrama DFD (lucrare de laborator nr. 3), deoarece metodologia IDEF0 consideră sistemul ca un set de lucrări interconectate, care reflectă slab procesele de prelucrare a informațiilor.
Orez. 2.13. Descompunerea lucrării „Prelucrarea solicitării clientului”
Orez. 2.14. Descompunerea lucrării „Serviciul client de sistem” (opțiunea 2)
Orez. 2.15. Diagrama contextului sistemului (opțiunea 2)
Să trecem la descompunerea ultimului bloc „Modificarea bazei de date”. Din punctul de vedere al clientului, aceste sisteme sunt situate într-o singură bază de date. Există de fapt șase baze de date în sistem:
- Baza de date utilizatori,
- DB de studenți, (opțiunea 2)
- DB de posturi vacante,
- baza de date de performanta,
- DB de teste,
- DB de evaluări de experți,
- Rezumat 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 se vor modifica informațiile.
- Operatorul formează un set de date temporar și îl furnizează administratorului.
- Administratorul controlează datele și le introduce în baza de date.
Acest model poate fi implementat într-un mod diferit, 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 controlul integrității bazei de date pentru a evita deteriorarea acesteia. În acest caz, diagrama va arăta astfel (Fig. 2.17).
Orez. 2.16. Descompunerea lucrării „Modificarea 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 niciunul Informații suplimentare asupra activității sistemului de servicii de ocupare a forței de muncă. Este recomandabil să descompuneți această lucrare în procesul de proiectare a unui sistem de baze de date în etapa creării unui model de bază de date logică.
Descompunerea lucrării de execuție a interogărilor va fi efectuată în laboratorul următor, ilustrând utilizarea diagramelor DFD pentru a descrie procesele de procesare a informațiilor.
Vom duce la îndeplinire analiza cantitativa modelele prezentate în fig. 2.12 și 2.13, conform procedurii de mai sus. Să luăm în considerare comportamentul coeficientului ^ pentru aceste modele. Diagrama părinte „Procesarea cererii client” are un coeficient de 4/2 = 2, iar o diagramă de descompunere este 3/3 = 1. Valoarea coeficientului scade, ceea ce indică o simplificare a descrierii funcțiilor cu o scădere a nivelul modelului.
Luați în considerare modificarea coeficientului K bîn două variante de model.
pentru a doua varianta
Coeficient K 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 funcțiile elementare (din punctul de vedere al utilizatorului sistemului) sunt folosite ca titluri de lucru pe diagramele de nivel inferior. .
Rezumând exemplul luat în considerare, este necesar să remarcăm importanța luării în considerare a mai multor opțiuni pentru diagrame la modelarea unui sistem. Astfel de variante pot apărea la ajustarea diagramelor, așa cum s-a 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”). Luarea în considerare a opțiunilor vă permite să alegeți cea mai bună și să o includeți în pachetul de diagrame pentru o analiză ulterioară.
Întrebări de control
Listă Întrebări de testare:
- Ce este un model în notația IDEF0?
- Ce înseamnă joburile IDEF0?
- Care este ordinea denumirii lucrărilor?
- Câte locuri de muncă ar trebui să fie pe o diagramă?
- Ce se numește ordin de dominație?
- Cum sunt aranjate lucrările după principiul dominației?
- Care este scopul laturilor dreptunghiurilor de lucru din diagrame?
- Enumerați tipurile de săgeți.
- Care sunt tipurile de relații.
- Ce sunt săgețile de delimitare?
- Explicați convenția de denumire pentru ramificarea și îmbinarea săgeților.
- Ce metodologii sunt acceptate de BPWin?
- Enumerați elementele principale ale ferestrei principale BPWin.
- Descrieți procesul de creare a unui nou model în BPWin.
- Cum se face o legătură între lucrări?
- Cum să setați numele jobului.
- Descrieți procesul de defalcare a muncii.
- Cum adaug lucru la o diagramă?
- Cum să rezolvi săgețile tunelizate?
- Poate un model BPWin să conțină diagrame de metodologii multiple?
Știați,
ce este un experiment de gândire, un experiment gedanken?
Aceasta este o practică inexistentă, o experiență de altă lume, imaginația a ceea ce nu este în realitate. Experimentele gândirii sunt ca niște vise trezite. Ei dau naștere monștrilor. Spre deosebire de un experiment fizic, care este un test experimental al ipotezelor, un „experiment de gândire” înlocuiește în mod viclean verificarea experimentală cu concluzii dorite, netestate în practică, manipulând construcții logice care încalcă de fapt logica însăși prin utilizarea premiselor nedemonstrate ca fiind dovedite, adică prin substituţie. Astfel, sarcina principală a solicitanților pentru „experimente de gândire” este de a înșela ascultătorul sau cititorul prin înlocuirea unui experiment fizic real cu „păpușa” sa – raționament fictiv în eliberare condiționată fără verificarea fizică în sine.
Umplerea fizicii cu „experimente de gândire” imaginare a dus la apariția unei imagini suprareale absurde, confuze și confuze a lumii. Un adevărat cercetător trebuie să distingă astfel de „împachetări de bomboane” de valorile reale.
Relativiștii și pozitiviștii susțin că „experimentul gândirii” este un instrument foarte util pentru testarea coerenței teoriilor (care apar și în mintea noastră). În aceasta, ei înșală oamenii, deoarece orice verificare poate fi efectuată doar de o sursă independentă de obiectul verificării. Reclamantul însuși al ipotezei nu poate fi un test al propriei afirmații, întrucât motivul în sine a acestei afirmații este absența contradicțiilor în afirmație vizibilă reclamantului.
Vedem acest lucru pe exemplul SRT și GRT, care s-au transformat într-un fel de religie care guvernează știința și opinie publica... Nici o cantitate de fapte care le contrazic nu poate depăși formula lui Einstein: „Dacă un fapt nu corespunde teoriei, schimbați faptul” (Într-o altă versiune, „- Faptul nu corespunde teoriei? - Cu atât mai rău pentru fapt").
Maximul pe care un „experiment de gândire” îl poate pretinde este doar consistența internă a ipotezei în cadrul propriei logici a solicitantului, adesea deloc adevărată. Acest lucru nu testează adecvarea practicii. Acest test poate avea loc numai într-un experiment fizic valabil.
Un experiment este un experiment în sensul că nu este o rafinare a gândirii, ci un test al gândirii. Un gând care este auto-consecvent în sine nu se poate verifica singur. Acest lucru este dovedit de Kurt Gödel.
Ghenadi Vernikov
În prezent, în Rusia, interesul pentru standardele de management general acceptate în Occident a crescut brusc, cu toate acestea, în practica reală de management, există un moment foarte indicativ. 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 manageri care citesc periodic periodice economice, de regulă, încep să deseneze diagrame ierarhice care sunt de înțeles doar pentru ei, dar chiar și în acest proces ajung de obicei rapid într-o fundătură. Același lucru este valabil și pentru angajații și managerii diferitelor servicii și unități funcționale. În cele mai multe cazuri, singurul set de reguli stabilite în conformitate cu care o întreprindere trebuie să opereze este un set de prevederi individuale și descrierea postului... Cel mai adesea, aceste documente au fost întocmite cu mai bine de un an în urmă, sunt prost structurate și nu sunt interconectate ș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ță ruse, conceptul de concurență a fost practic absent și nu era nevoie în mod special de a lua în considerare costurile - profitul a fost gigantic. Drept urmare, am văzut o imagine destul de ușor de înțeles în ultimii doi ani: 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ă întreprinderea nu a implementat standarde de management, conceptul de model funcțional de activitate și misiune a fost complet absent. Cu ajutorul modelării diverselor domenii de activitate, 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, la orice întreprindere, doar acele proiecte care aduc profit direct sunt de cea mai mare prioritate, prin urmare, de obicei, doar în timpul unei crize tangibile în managementul companiei vorbim despre studiul activităților și al acesteia. reorganizare.
La sfârșitul anilor 90, când piața era suficient de competitivă și profitabilitatea întreprinderilor a început să scadă brusc, managerii au simțit dificultăți enorme în încercarea de a optimiza costurile astfel încât produsele să rămână atât profitabile, cât și competitive. Chiar în acest 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 de zi cu zi a majorității analiștilor concomitent cu apariția pe piață a unor produse software complexe concepute pentru automatizare integrată managementul î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 paragrafele individuale sunt făcute recomandări 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, și firește, o echipă care s-a dezvoltat de-a lungul anilor este întotdeauna greu de forțat să „gândească într-un mod nou”. Astfel de anchete complexe ale întreprinderilor sunt întotdeauna complexe și semnificativ diferite de la sarcinile de la caz la caz. Există metodologii și standarde bine încercate pentru rezolvarea unor astfel de probleme de modelare a sistemelor complexe. Aceste standarde includ metodologiile familiei IDEF. Cu ajutorul lor, este posibil să afișați și să analizați eficient modelele activității unei game largi de sisteme complexe în diferite secțiuni. În același timp, amploarea ș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 limbajului grafic vizual IDEF0, sistemul studiat se prezintă dezvoltatorilor și analiștilor sub forma unui set de funcții interdependente (blocuri funcționale – în termenii IDEF0). De obicei, modelarea IDEF0 este primul pas în învățarea despre orice sistem;
IDEF1 este o metodologie de modelare a fluxurilor de informații din cadrul sistemului, care vă permite să afișați și să analizați structura și relațiile acestora;
IDEF1X (IDEF1 Extended) este o metodologie pentru construirea structurilor relaționale. IDEF1X este un tip de metodologie Entitate-Relație (ER) și este utilizat în mod obișnuit pentru a modela baze de date relaționale relevante pentru sistemul în cauză;
IDEF2 este o metodologie pentru modelarea dinamică a evoluției sistemelor. Din cauza dificultăților foarte serioase de analiză a 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 computerizate care fac posibilă transformarea unui set de diagrame IDEF0 statice în modele dinamice bazate pe „rețele Petri colorate” (CPN - Color Petri Nets);
IDEF3 este o metodologie de documentare a proceselor care au loc în sistem, care este utilizată, de exemplu, în cercetare procese tehnologice la intreprinderi. IDEF3 descrie scenariul și fluxul de lucru pentru fiecare proces. IDEF3 are o relație directă cu metodologia IDEF0 - fiecare funcție (bloc funcțional) poate fi reprezentată ca proces separat prin intermediul 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 vocabular specific de termeni și reguli, pe baza căruia se pot forma declarații de încredere despre starea sistemului luat în considerare la un anumit moment în timp. Pe baza acestor afirmații, se formează concluzii despre dezvoltarea ulterioară a sistemului și se realizează optimizarea acestuia.
În acest articol, ne vom uita la 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, a fost publicată în Rusia o mică ediție a cărții cu același nume, care a fost dedicată descrierii principiilor de bază ale construirii diagramelor SADT. Din punct de vedere istoric, IDEF0 ca standard a fost dezvoltat în 1981 ca parte a unui program extins de automatizare industrială numit ICAM (Integrated Computer Aided Manufacturing) și a fost propus de Forțele Aeriene ale SUA. Familia de standarde IDEF însăși ș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 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 metodă trebuia să ofere lucru în 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 de natură limitativă, iar ultima sa revizuire a fost lansată în decembrie 1993 de Institutul Național pentru Standarde și Tehnologie din SUA (NIST).
Elemente și concepte de bază ale IDEF0
Limbajul grafic IDEF0 este surprinzător de simplu și armonios. Metodologia se bazează pe patru concepte principale.
Primul este conceptul de cutie de activități. Un bloc funcțional este reprezentat grafic sub forma unui dreptunghi (vezi Fig. 1) și personifică o anumită funcție în cadrul sistemului în cauză. Conform cerințelor standardului, numele fiecărui bloc funcțional trebuie formulat în modul verbal (de exemplu, „produce servicii”, nu „producție de servicii”).
Fiecare dintre cele patru laturi ale unui bloc funcțional are propriul său sens specific (rol), în timp ce:
Fiecare bloc funcțional din cadrul unui singur sistem considerat 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. Arcul de interfață afișează 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). După cum prevede standardul, numele trebuie să fie un substantiv turnover.
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, mașini, angajați etc.) sau fluxuri de date și informații (documente, date, instrucțiuni etc.).
În funcție de care dintre laturile se potrivește acest arc de interfață, se numește „inbound”, „outbound” sau „control”. În plus, numai blocurile funcționale pot fi „sursa” (începutul) și „chiuveta” (sfârșitul) fiecărui arc funcțional, în timp ce „sursa” poate fi doar partea de ieșire a blocului, iar „chiuveta” poate fi orice dintre cele trei rămase.
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ă urmeze niște reguli (afișate de arcul de control) și trebuie să producă un rezultat (arc de ieșire), altfel nu are sens să îl luăm în considerare.
Când construiți IDEF0 - diagrame, este important să separați corect arcurile 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”.
Într-un proces real, lucrătorului care efectuează prelucrarea i se oferă o piesă de prelucrat și instrucțiuni tehnologice pentru prelucrare (sau reguli de siguranță atunci când lucrează cu mașina). Poate părea în mod eronat că atât piesa de prelucrat, cât și documentul cu instrucțiuni tehnologice sunt obiecte primite, dar nu este așa. De fapt, în acest proces, piesa de prelucrat este prelucrată conform regulilor reflectate în instrucțiunile tehnologice, care ar trebui, respectiv, afișate de arcul interfeței de control.
Figura 2.
Este o altă problemă când instrucțiunile tehnologice sunt procesate de tehnologul șef și le sunt aduse modificări (Fig. 3). În acest caz, ele sunt afișate ca un arc de interfață deja primit, iar obiectul de control este, de exemplu, noi standarde industriale, pe baza cărora se fac aceste modificări.
Figura 3.
Exemplele de mai sus subliniază natura aparent similară a arcurilor de interfață de intrare și de ieșire, dar există întotdeauna anumite distincții pentru sistemele din aceeași clasă. De exemplu, în cazul luării în considerare a întreprinderilor și organizațiilor, există cinci tipuri principale de obiecte: fluxuri 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, intenție, instrucțiuni orale etc.) și resurse (angajați, mașini, mașini etc.). În același timp, în diverse cazuri, toate tipurile de obiecte pot fi afișate prin arcuri de interfață de intrare și de ieșire, care controlează doar pe cele legate de fluxurile de documente și informații, iar doar resursele pot fi afișate prin arcuri-mecanisme.
Prezența obligatorie a arcurilor de interfață de control este una dintre principalele diferențe ale standardului IDEF0 față de alte metodologii ale claselor DFD (Data Flow Diagram) și WFD (Work Flow Diagram).
Al treilea concept de bază al standardului IDEF0 este Descompunerea. Principiul de descompunere este utilizat atunci când descompune un proces complex î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 aglomerat și ușor de digerat.
Modelul IDEF0 începe întotdeauna cu prezentarea sistemului ca întreg - un singur bloc funcțional cu arcuri de interfață care se extind dincolo de zona considerată. O astfel de diagramă cu un bloc funcțional se numește diagramă de context și este notă cu identificatorul "A-0".
Textul explicativ pentru diagrama de context trebuie să indice Scopul construirii diagramei în formular descriere scurta iar punctul de vedere (Punctul de vedere) este fix.
Definirea și formalizarea obiectivului de dezvoltare a IDEF0 - modelul este extrem de punct important... De fapt, scopul identifică zonele relevante din sistemul studiat pe care ar trebui să se concentreze mai întâi. De exemplu, dacă modelăm activitățile unei întreprinderi cu scopul de a construi mai departe pe baza acestui model Sistem informatic, atunci acest model va diferi semnificativ de cel pe care l-am dezvolta pentru aceeași întreprindere, dar cu scopul de a optimiza lanțurile de aprovizionare.
Punctul de vedere definește direcția principală de dezvoltare a modelului și nivelul de detaliu necesar. O fixare clară a punctului de vedere vă permite să descărcați modelul, 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 cele din urmă, CFO nu este interesat de aspectele prelucrării materiilor prime pe mașini de producție, iar tehnologul șef nu are nevoie de scheme desenate 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 forat într-o altă diagramă. Diagrama de nivel al doilea rezultată conține blocuri funcționale care afișează principalele subfuncții ale blocului funcțional al diagramei de context și se numește diagramă Child în raport cu acesta (fiecare dintre blocurile funcționale aparținând unei diagrame copil se numește, respectiv, Child Box). . La rândul său, blocul funcțional părinte se numește bloc părinte în raport cu diagrama copil (Parent Box), iar diagrama căreia îi aparține se numește diagramă părinte (Parent Diagram). Fiecare dintre sub-funcțiile diagramei copil poate fi detaliată în continuare printr-o descompunere similară a blocului 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 în diagrama copil. Acest lucru realizează integritatea structurală a modelului IDEF0. Principiul descompunerii este prezentat clar în Figura 4. Trebuie acordată atenție relației dintre numerotarea blocurilor funcționale și diagramele - fiecare bloc are propriul său unic număr de serie pe diagramă (numărul din colțul din dreapta jos al dreptunghiului), iar simbolul din colțul din dreapta indică numărul diagramei copil pentru acest bloc. Absența acestei denumiri înseamnă că nu există nicio descompunere pentru acest bloc.
Există adesea cazuri în care arcele individuale de interfață nu au sens să fie luate în considerare în continuare în diagramele copil sub un anumit nivel în ierarhie sau invers - arcele individuale nu au sens practic peste un anumit nivel. De exemplu, un arc de interfață care înfățișează un „detaliu” la intrarea în „Procesul pornit strung„nu are sens să reflectăm asupra diagramelor de la niveluri superioare - va supraîncărca diagramele și le va face dificil de înțeles. Pe de altă parte, devine necesar să scăpăm de arcuri de interfață „conceptuale” separate și să nu le detaliem mai profund decât un anumit nivel.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 în această diagramă.întoarce, aceeași denumire în jurul capătului (săgeților) arcului de interfață în imediata apropiere a blocului receptor înseamnă că acest arc nu va fi afișat și vizualizat la copil diagrama acestui bloc.arcurile de interfaţă nu sunt considerate la unele niveluri intermediare ale ierarhiei – inclusiv În acest caz, ei „se plonjează mai întâi în tunel” și apoi, dacă este necesar, „se întorc din tunel”.
Conceptul final din 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 relevante, cuvinte cheie, narațiuni etc. care caracterizează obiectul afișat de acest element. Acest set se numește glosar și este o descriere a esenței acestui element. De exemplu, pentru arcul de interfață de control „ordin de plată”, glosarul poate conține o listă de câmpuri ale documentului corespunzătoare arcului, setul necesar de vize etc. Glosarul completează armonios limbajul grafic, oferind diagramelor informațiile suplimentare necesare.
Figura 4. Descompunerea blocurilor funcționale.
Principiile limitării complexității diagramelor IDEF0
De obicei, modelele IDEF0 transportă informații complexe și concentrate, iar pentru a limita aglomerația lor și a le face lizibile, limitele de complexitate corespunzătoare sunt adoptate în standardul corespunzător:
Limitarea numărului de blocuri funcționale din diagramă la trei până la șase. Limita superioară (șase) forțează proiectantul să folosească ierarhii atunci când descrie elemente complexe, iar limita inferioară (trei) asigură că există suficiente detalii pe diagrama corespunzătoare pentru a justifica crearea acesteia;
Limitarea numărului de arcuri de interfață potrivite pentru un bloc funcțional (lăsând un bloc funcțional) la patru.
Desigur, nu este deloc necesar să respectați cu strictețe aceste restricții, cu toate acestea, după cum arată experiența, ele sunt foarte practice în munca reală.
Disciplina lucru de grup asupra dezvoltării modelului IDEF0
Standardul IDEF0 conține un set de proceduri care permit unui grup mare de oameni din diferite zone ale sistemului modelat să dezvolte și să convină asupra unui model. De obicei, procesul de dezvoltare este iterativ și constă din următoarele etape condiționate:
Crearea unui model de către un grup de specialiști în legătură cu diverse domenii ale întreprinderii. Acest grup se numește Autori în ceea ce privește IDEF0. Construirea unui model inițial este un proces dinamic în timpul căruia autorii întreabă oamenii competenți despre structura diferitelor procese. Pe baza prevederilor existente, a documentelor și a rezultatelor sondajului, este creată o schiță de model a modelului.
Distribuirea proiectului spre revizuire, aprobări și comentarii. În această etapă, se discută despre proiectul de model 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 subliniind logica luării deciziilor și returnează proiectul revizuit pentru o analiză ulterioară. Acest ciclu continuă până când autorii și cititorii ajung la un consens.
Aprobare model. Aprobarea modelului agreat are loc de către ș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 organizarea de spectacole ș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 prin intermediul IDEF0
V anul trecut interesul pentru metodologiile familiei IDEF crește constant în Rusia. Observ în mod constant acest lucru, uitându-mă la statisticile apelurilor către 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 destul de practic justificat. De fapt, primele instrumente Case care permit construirea diagramelor DFD și IDEF0 au apărut pe piața rusă în 1996, simultan cu lansarea cărții populare despre principiile modelării în standardele SADT.
Cu toate acestea, majoritatea directorilor încă consideră aplicarea practică a modelării în standardele IDEF ca un tribut adus modei, mai degrabă decât cale eficientă optimizare sistemul existent managementul afacerilor. Acest lucru se datorează cel mai probabil unei lipse pronunțate de informații despre aplicație practică aceste metodologii și cu indispensabila părtinire software a majorității absolute a publicațiilor.
Nu este un secret pentru nimeni că aproape toate proiectele pentru sondajul și analiza financiară și activitate economicăîntreprinderile de acum în Rusia sunt într-un fel sau altul legate de construcții sisteme automatizate management. Datorită acestui fapt, standardele IDEF în înțelegerea majorității au devenit 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 ajutorul unui creion și hârtie.
Atunci când desfășurați proiecte complexe de anchetă de întreprinderi, dezvoltarea modelelor în standardul IDEF0 vă permite să afișați vizual și eficient întregul mecanism al activității întreprinderii în contextul dorit. Cea mai importantă este însă colaborarea pe care IDEF0 o oferă. In al meu activitati practice au existat destul de multe cazuri când construcția modelului a fost realizată cu asistența directă a angajaților diferitelor 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 să lucreze cu aplicațiile corespunzătoare. software... Drept urmare, angajații diferitelor departamente au creat diagrame IDEF ale activităților unității lor funcționale, care urmau să răspundă la următoarele întrebări:
Ce merge la unitatea „la intrare”?
Ce funcții și în ce ordine sunt îndeplinite în cadrul unității?
Cine este responsabil pentru fiecare dintre funcții?
După ce se ghidează executantul atunci când îndeplinește fiecare dintre funcții?
Care este rezultatul muncii (ieșirii) unității?
După ce s-au convenit asupra schițelor de diagrame în cadrul fiecărui departament specific, acestea sunt asamblate de către consultant într-un proiect de model de întreprindere, în care toate elementele de intrare și de ieșire sunt legate. În această etapă, sunt înregistrate toate discrepanțele diagramelor individuale și locurile lor controversate. În plus, acest model trece din nou departamente functionale pentru un acord în continuare și efectuarea ajustărilor necesare. Drept urmare, într-un timp destul de scurt și cu atracția minimului resurse umane din partea unei companii de consultanță (și aceste resurse, după cum știți, sunt foarte costisitoare), se obține un model IDEF0 al unei întreprinderi conform principiului „Așa cum este” și, ceea ce este important, reprezintă întreprinderea din poziția angajaților care lucrează în ea și cunosc în detaliu toate nuanțele, inclusiv informale. În viitor, acest model va fi transferat pentru analiză și procesare către analiștii de afaceri care vor căuta blocajele în managementul companiei și vor optimiza procesele principale, transformând modelul „Așa cum este” în vederea corespunzătoare „Așa cum ar trebui să fie”. 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 atribuirea unor responsabilități suplimentare unor angajați în stăpânirea și aplicarea practică a noilor metodologii. Cu toate acestea, în cele din urmă, acest lucru dă roade, deoarece o oră suplimentară sau două de muncă a angajaților individuali pe parcursul mai multor zile poate economisi în mod semnificativ bani pentru plata serviciilor de consultanță către o companie terță (care, în orice caz, va smulge de munca aceloraș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 lor.
Concluzia din toate acestea se poate face astfel: nu este deloc necesar să se vină cu soluții pentru problemele standard de fiecare dată. Ori de câte ori te confrunți cu nevoia de a analiza un anumit sistem funcțional (de la un sistem de proiectare a unei nave spațiale până la procesul de pregătire a unei cine complexe), folosește metode care au fost dovedite și testate de-a lungul anilor. Una dintre aceste metode este IDEF0, care vă permite să rezolvați probleme complexe de viață cu ajutorul instrumentelor sale simple și ușor de înțeles.
