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, în fața ochilor noștri apar cărți cu săgeți, care arată clar cursul bătăliei. Și în acele zile, 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ă exact ce facem - configurați sau instalați un sistem CRM de la zero, creați un sistem ERP eficient, faceți integrare diverse 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 din afară, creez Ofertă comercială, în care vă dezvălui cât mai detaliat viziunea mea asupra situației actuale, precum și acțiunile care trebuie efectuate pentru rezolvarea sarcinii și, bineînțeles, 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 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 crescute a modelului.

Prea multe blocuri

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 schemă. Ș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ăuntru schema generala, apoi la detaliere va duce la o direcție neclară și va 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.Începeți să înțelegeți cum funcționează acest sau acel sistem și, de asemenea, puteți explica clar unde sunt „punctele subțiri” din acest sistem și cum soluțiile dvs. 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 care să dezvăluie simboluri si termeni. Drept urmare, dumneavoastră și clientul, managerul și alți angajați vorbiți aceeași limbă atunci când discutați o problemă.
• Simplitate și de mare viteză crearea unui model. 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 colegi sau clienți.
• 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 tocmai o profesie; fiecare manager de afaceri sau dezvoltator de sisteme care analizează afacerea și se străduiește să construiască cel mai mult sistem eficient. Pentru acești oameni și în aceste scopuri este conceput instrumentul IDEF0.

Prin urmare, atunci când se elaborează un model de business funcțional „așa cum este”, 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 cu managerii. diviziuni structurale si angajati. 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.

Abrevierea IDEF0, cunoscută astăzi nu numai în cercuri înguste, este prima metodologie care standardizează lucrul asupra proceselor de afaceri. A fost dezvoltat la mijlocul secolului trecut ca parte a unui proiect aerospațial din SUA și, după ce și-a demonstrat eficacitatea, a devenit un standard federal. La noi, în anul 2000, a fost întocmit un document „ Metodologia modelării funcționale IDEF0. Document de orientare Metodologia de modelare funcțională IDEF0 Ghid Document. Publicație oficială. Standard de stat al Rusiei RD IDEF0 – 2000. Dezvoltat de Centrul de Cercetare CALS – Tehnologii Logistice Aplicate. Adoptat și pus în aplicare prin Decretul Standardului de Stat al Rusiei în 2000, Moscova„, dar nu a fost niciodată aprobat ca standard. Deși acest lucru nu a împiedicat această metodologie să devină unul dintre cele mai populare instrumente de modelare grafică a proceselor de afaceri din țara noastră. În acest articol, vă invit să luați în considerare modelul IDEF0 și să evaluați relevanța acestei abordări în prezent.

Concepte de bază și abrevieri

Să ne uităm puțin la numele elementelor cheie ale metodologiei. Standardul grafic IDEF0 face parte din metodologia SADT (Structured Analysis and Design Technique). IDEF este o abreviere pentru ICAM Definition, iar ICAM este derivat din Integrated Computer Aided Manufacturing, care se traduce prin computerizarea integrată a producției. Metodologia SADT este o întreagă familie de 15 modele diferite, care împreună ar fi trebuit să facă posibilă studierea structurii, parametrilor și caracteristicilor sistemelor de producție, tehnic și organizatoric-economic.

IDEF0 este un model funcțional, care este nucleul construcției tuturor celorlalte structuri; el leagă între ele fluxurile de informații și materiale, structura organizațională, influențele de control și însăși activitățile companiei. Standardul grafic pentru procesele de modelare se mai numește și notație. Adică, notația este un sistem de cerințe și reguli pentru construirea unui model de activitate într-o formă sau alta. Prin urmare, IDEF0 este numită în mod corespunzător o notație care face parte din metodologia SADT.

Notația IDEF0 este o metodologie destul de strictă care a fost dezvoltată inițial, ca standardele de proiectare tehnică, pentru modelarea manuală. Prin urmare, conține cerințe pentru plasarea săgeților, formatul tuturor elementelor, conținutul cadrului de informații pentru diagrama IDEF0 etc. Deoarece activitățile companiei sunt un sistem complex de acțiuni pe mai multe niveluri, există întotdeauna multe diagrame, iar sistematizarea fără ambiguitate și navigarea prin toate elementele modelului este necesară. În zilele noastre, acest lucru se face în mare parte sisteme informatice, susținând modelarea în această notație. În Rusia, cele mai faimoase și accesibile sisteme de astăzi sunt AllFusion Process Modeler și Studio de afaceri. Plănuiesc să dedic articole separate unei revizuiri a acestor sisteme.

Bloc funcțional

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

Elementele blocului funcțional necesare în IDEF0

Indiferent de scara acțiunilor, toate funcțiile sunt afișate uniform și conțin în mod necesar 4 fluxuri de taste, care sunt alocate rigid pe părțile laterale ale blocului funcțional:

• în stânga sunt intrările sau resursele utilizate pentru îndeplinirea funcției;
• în dreapta sunt ieșirile sau rezultatele executării funcției;
• deasupra sunt acțiunile de control care determină cum și câte rezultate trebuie produse;
• mai jos sunt mecanismele care reflectă cine ar trebui să facă această muncă și cu ce ajutor.

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

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

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

Schema luată în considerare este „componenta de bază” a abordării IDEF0. Modelarea funcțională presupune o trecere treptată de la general la specific prin descompunere. Descompunerea se „aprofundează” în funcția luată în considerare, împărțind-o în funcții mai mici. Mai mult, atunci când o funcție de nivel superior este prezentată într-o manieră generalizată și apoi descompusă, este potrivit să o numim proces.

Diagrama de context

La cel mai înalt nivel, compania este reprezentată ca o „cutie neagră” în care au loc anumite activități care traduc intrările în ieșiri. Acest nivel se numește de obicei „”, adică o diagramă care descrie contextul activităților companiei. În plus, diagrama de context afișează caracteristicile cheie ale întregului model.

1. Scopul este o formulare specifică a scopului modelului, față de care acuratețea modelului poate fi verificată în viitor.
2. Punct de vedere - în numele căruia este construit modelul, deoarece modelul depinde întotdeauna de autorul său și de focalizarea atenției. Dacă construim un model general al unei întreprinderi, atunci acesta este de obicei prezentat din punctul de vedere al directorului acesteia.
3. Tipul de model este o indicație a informațiilor afișate pe diagrame. Pot exista 2 opțiuni fundamentale: AS IS (“Așa cum este”) sau A FI (“Așa cum va fi”). Această împărțire este necesară, deoarece putem construi modele atât pentru analiza activităților, cât și pentru transformarea acestora. Trebuie să fim clari cu privire la ceea ce facem și, de asemenea, să transmitem aceste informații și altora.

Astfel, diagrama de context conține în cea mai generală formă o descriere a activităților companiei, care sunt pătrunse de fluxuri care leagă compania de lumea exterioară. Cred că ar trebui să ne uităm și la ele puțin mai detaliat.

Fire principale

Experiența a arătat că, în ciuda aparentei simplități și formalități a acestui nivel, de multe ori trebuie să zăboviți mult timp, deoarece toate rezultatele care sunt semnificative pentru proprietar și piață trebuie să fie reflectate aici. O eroare poate duce la crearea de modele care nu îndeplinesc obiectivele de business. Pentru a verifica dacă fluxurile semnificative sunt reflectate, asigurați-vă că toate cele 4 tipuri principale de fluxuri sunt prezente în diagramă.

1. Material: materiale și componente la intrare și produse finite la ieșire.
2. Client: potential client la intrare si multumit la iesire.
3. Financiar: inputul este de obicei investiții, plăți ale clienților (venituri), împrumuturi și alte venituri; Rezultatul este plățile către furnizori, impozitele, plățile pentru împrumuturi și profiturile.
4. Informațional: intrarea este toate fluxurile de informații despre mediul extern (condițiile pieței, comportamentul concurenților, inovațiile tehnologice etc.), iar rezultatul este fluxul de informații pe care compania îl comunică lumii despre ea însăși (toate informațiile publicitare, precum și toate tipurile de raportare în fața autorităților de reglementare).

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

(click pentru a mari)

Este o idee bună să evidențiați fiecare dintre aceste tipuri de fluxuri cu o culoare diferită, astfel încât să puteți distinge cu ușurință mișcarea resurselor și să nu ratați punctele importante. De exemplu, puteți observa adesea absența unui client în fluxurile companiei, așa că lucrul cu el se bazează pe principiul rezidual - clientul se simte adesea ca o piedică pentru angajații companiei ale căror sarcini sunt concentrate pe procesarea fluxului de documente.

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

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

Al doilea este informațiile nedocumentate, care se referă cel mai adesea la cerințele proprietarilor.

Și, în sfârșit, mecanisme - există doar 2 tipuri de fluxuri: echipamente (material) și performeri (divizii și oameni). Aici nu pot exista documente, la fel cum nu pot fi oameni pe comutatoarele de control!

Pentru navigare, modelul oferă numerotare continuă. Diagrama de context este numerotată „A-0”. Pe viitor, toată lumea bloc funcţionalîși obține numărul, indiferent cât de adâncă este descompunerea.

Descompunere

După ce am lucrat prin fluxurile diagramei de context, putem trece la descompunere. Trecând la un nivel inferior, ca și cum am deschide o „cutie neagră”, vedem mai întâi Foaie albă cu săgeți care au fost atașate blocului funcțional.

(click pentru a mari)

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

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

1. Crearea unui produs (rezultat).
2. Promovare și vânzări – lucrul cu fluxul de clienți.
3. Asigurarea că activitățile de creare a produselor sunt procese secundare care sunt necesare pentru a respecta cerințele guvernamentale sau ușurința în muncă (personal și contabilitate, serviciu de transport, curatenie spatii etc.).
4. Crearea fluxurilor de control - Activități de dezvoltare decizii de management, care va determina cerințele pentru toate procesele companiei.

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

(click pentru a mari)

Pe diagramă, procesele ar trebui să fie localizate în diagonală - acest lucru se numește principiul dominantei, care presupune aranjarea blocurilor funcționale de la stânga la dreapta și de sus în jos - în ordinea importanței sau în ordine cronologică. Numerotarea blocurilor are loc în același mod.

Lucrările ulterioare asupra modelului sunt similare cu prima etapă - se realizează descompunerea fiecărui bloc funcțional al primului nivel. Numerotarea blocului va conține numărul primului nivel: A1.1 ... A1.n, A2.1 ... A2.n etc.

Concluzii despre relevanța notației

În cadrul acestui articol, am putut afișa doar conceptele de bază ale notației IDEF0 folosind un exemplu scurt de IDEF0, din care, desigur, este dificil să judecăm metodologia în ansamblu. Dar destul experiență grozavă Folosirea acestei notații în practică îmi permite să trag următoarele concluzii.

1. Modelul are un bun potențial de vizualizare, dar, în opinia mea, importanța sa mai mare constă în efectul său disciplinar. Regulile și restricțiile încorporate în metodologie ne obligă să dezvoltăm o atitudine sistematică și strictă față de modele, ceea ce are un efect foarte bun asupra calității rezultatului final.
2. Modelul vă permite să construiți fluxuri de comunicare între lucruri aparent nu foarte conectate: să conectați subsistemele front și back office cu management, ceea ce este mult mai rău realizat de alte notații.
3. Abordarea este simplă și de înțeles pentru majoritatea participanților la proiect. Construirea și citirea diagramelor în această notație este limitată doar de dorința de a aprofunda în complexitatea fluxurilor de afaceri.

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

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

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

În managementul proiectelor, acest standard de modelare este cel mai aplicabil acolo unde este necesar să se conecteze cu fluxurile vizuale diverse proiecte sau procese. Modelul grafic va permite o distribuție mai rațională a responsabilităților și resurselor între sarcini. Logica de finalizare a sarcinilor proiectului, reflectată în diagrame, va ajuta la pregătirea unei mai bune plan calendaristic sub forma unei diagrame Gantt.

16 septembrie 2010 13:08

„Divide et impera”
Maxima Senatului Roman

Era 1981, iar Forțele Aeriene ale SUA dezvoltau un program de automatizare. întreprinderile industriale, care a fost numit pe scurt ICAM (Fabricare integrată asistată de calculator). Pentru derularea cu succes a proiectului, a fost necesar ca toți participanții să poată simula o întreprindere automatizată în paralel. Un set de standarde a fost dezvoltat special pentru aceste scopuri IDEF (DEFINIȚIA ICAM). Unul dintre standardele stabilite a fost o notație de modelare funcțională cu nume de cod IDEF0, care s-a modificat ușor de-a lungul timpului, iar specificația pentru acesta din urmă este acest moment versiunea a fost lansată în decembrie 1993.
Vă voi spune puțin despre caracteristicile procesului de modelare funcțională a unui proces de afaceri folosind notație IDEF0și în același timp îl voi ajuta pe Aristarkh Grigorievich, pe care l-am menționat în articolul anterior: voi descrie procesul de afaceri de preparare a borșului.

Modelarea funcțională începe prin identificarea sarcinii principale care se rezolvă prin executarea acestui proces de afaceri. În cazul nostru, această sarcină este formulată după cum urmează: „Pregătiți borșul”. Mi se pare că este mai eficient să începem procesul de modelare determinând ce date și materiale avem înainte de a executa procesul de afaceri (Input), precum și înțelegerea clară a ceea ce dorim să obținem ca urmare a executării procesului de afaceri ( Ieșire / Ieșire). Acest lucru va face posibilă identificarea cerințelor clare pentru procesul de afaceri și eliminarea speranțelor nerealiste: având doar o mână de pietre de origine dubioasă, este imposibil să obțineți lingouri de aur. În cazul pregătirii borșului, există, de exemplu, legume și carne la intrare (desigur, ele pot să nu fie acolo, dar să presupunem că toate produsele au fost achiziționate cu prudență). La ieșire ar trebui logic să luăm borș.

Notația IDEF0 presupune, de asemenea, că pentru a realiza modelarea funcțională este necesar să se identifice așa-numitul mecanism (mecanism), adică. acelor interpreți care vor fi implicați în procesul de afaceri. În exemplul nostru, mecanismul este însuși Aristarkh Grigorievich și, să zicem, fiul său cel mare Kolya. Execuția corectă a procesului trebuie să fie controlată de ceva (unele standarde, metode, tehnologii etc.). Acest lucru în notația IDEF0 se numește „control” și trebuie să apară pe diagrama funcțională.

Odată ce analistul de afaceri a identificat intrările și ieșirile și a stabilit mecanismul și controalele, toate aceste informații pot fi rezumate într-o primă diagramă numită diagramă de context. Va arăta ca în Figura 1.

Orez. 1. Diagrama de context

Scopul principal al unei diagrame de context este de a identifica sarcina principală, singura și singura funcție pe care execuția unui proces de afaceri o rezolvă. O diagramă de context este deosebit de importantă atunci când punem împreună o vedere generală a problemei de afaceri care se rezolvă: de ce avem nevoie și în ce cantitate, ce vom obține ca rezultat, cine este implicat în procesul de afaceri, ce documente de reglementare avem nevoie pentru a rezolva corect problema.

O diagramă de context nu oferă o vedere completă a procesului, ci doar o vedere generală. Pentru a vizualiza secvența procesului, trebuie să rotiți roata microscopului: descompuneți diagrama, adică. oferiți o descriere puțin mai detaliată a procesului. Întotdeauna mi-a fost mai convenabil să împart o sarcină generală gigantică în 4-5 altele mai mici, cu aproximativ același nivel de detaliu. Aceste sarcini pot fi fie secvențiale, fie paralele în timpul lor de execuție. De exemplu, în cazul pregătirii borșului, aceste sarcini se rezumă la: pregătirea bulionului, pregătirea legumelor, de fapt gătitul și servirea preparatului. Este clar că puteți găti bulionul și puteți pregăti legumele în același timp, dar servirea borșului înainte de a fi condimentat va ieși prost. Să obținem o diagramă, de exemplu, ca cea prezentată în Figura 2.

Orez. 2. Diagrama de descompunere a primului nivel

În același mod, puteți descompune fiecare dintre aceste mici funcții până când este atins nivelul necesar de detaliu.

Văd un avantaj foarte mare al descompunerii în faptul că, atunci când descrieți un proces tehnologic greu, de exemplu, puteți indica un întreg atelier, de exemplu, un atelier de turnare, ca principal executant al procesului în diagrama de context și apoi selectați echipe individuale, de exemplu, pe diagrama de descompunere acest atelier, responsabile pentru o direcție sau alta în execuția procesului. Este deosebit de important ca pentru fiecare bloc de descompunere, la fel ca întreaga diagramă de context în ansamblu, să fie indicate atât datele de intrare, cât și datele de ieșire. Acestea. putem controla fluxul de resurse, distribuindu-le, reducându-le în unele locuri, mărindu-le în altele, putem înțelege că este necesar să amânăm o parte din muncă, deoarece, de exemplu, nu este posibil să folosim aceeași mașină în același timp. În colțul din stânga jos al blocurilor de descompunere este indicat costul aproximativ al efectuării unei operații, ceea ce vă permite să evidențiați operațiunile mai costisitoare care trebuie elaborate mai detaliat. Și invers: sarcinile mici sunt mai ușor de evaluat decât cele mari. După ce a găsit costul finalizării fiecăreia dintre sarcinile mici, costul sarcinii mari poate fi calculat prin simpla adunare a costurilor sarcinilor mici.

Marele dezavantaj al notației IDEF0 este, în opinia mea, că nu reflectă bine și, în general, deloc, reacția participanților la proces la evenimentele de mediu. Prin urmare, este imposibil să se evalueze riscurile asociate cu schimbările din mediul extern și, de asemenea, este imposibil să se modeleze opțiunile de rollback. De aceea, în opinia mea, notația IDEF0 este perfect potrivită pentru a descrie nu procese de afaceri, ci procese tehnologice în care influența mediu inconjurator, deoarece operațiunile se desfășoară conform planului. Desigur, defecțiunile echipamentelor nu pot fi excluse. Dar, dacă te gândești bine, defecțiunea echipamentului duce doar la necesitatea reparației sau a schimbării echipamentului. În cele mai multe cazuri, acest lucru are ca rezultat fie o întârziere, fie anularea procesului la o anumită etapă, dar nu o retrocedare (imaginați-vă cum, atunci când un cuptor se defectează, cărămizile se dezintegrează din nou în nisip și lut), în timp ce atunci când apar situații excepționale într-o afacere. mediu, În cele mai multe cazuri, sunt necesare acțiuni de rollback. De aceea, notația IDEF0 pare mai acceptabilă pentru descrierea proceselor tehnologice.

În episoadele următoare veți găsi povești interesante despre notațiile BPMN, EPC și UML.

(4,77 - evaluat de 43 de persoane)

1. Modelare funcțională Sistem informatic folosind tehnologia IDEF CASE.
2. Descrierea logicii interacțiunii și a succesiunii de lucru.

2. Planul de lecție

1. Controlul cunoștințelor prin testare (test ISE002).
2. Dezvoltarea unui model pe mai multe niveluri de activitate a sistemului informatic (model AS - IS) folosind instrumentul BPwin CASE folosind tehnologii IDEF 0Și IDEF 3 :
   • Descrierea proprietăților modelului (Proprietăți model).
   • Crearea primului nivel al modelului funcțional - elaborarea unei diagrame de context.
   • Crearea celui de-al doilea nivel al modelului funcțional - detalierea lucrării contextuale și elaborarea unei diagrame de descompunere.
   • Crearea celui de-al treilea nivel al modelului funcțional - detalierea activității celui de-al doilea nivel care implementează funcția Contabilitatea activității organizatii. Această etapă de dezvoltare permite crearea unei diagrame de descompunere folosind una dintre cele două metodologii - IDEF 0 (prima opțiune) sau IDEF 3 (a doua opțiune). Pentru opțiunea 2, crearea unui script și diagramă a secvenței de execuție lucrări individuale (Diagrama fluxului de lucru) în procesul de contabilizare a activităților se realizează folosind metodologia IDEF 3.
3. Dezvoltarea unui dicționar de lucrări și a unui dicționar de săgeți care vă permit să afișați o descriere a fragmentelor corespunzătoare ale modelului.

1. Modelarea funcțională a unui sistem informațional folosind tehnologie IDEF trebuie efectuată cu ajutorul unui instrument CASE BPwin, care este încărcat de comandă Start/Programe/Computer Associates/BPwin 4.0/BPwin4.0 . Procesele tehnologice ale modelării IDEF sunt prezentate în secțiunea 4 „Informații teoretice pentru lecția practică”.
2. La elaborarea unei diagrame de context, trebuie luat în considerare faptul că proprietățile modelului pot fi formatate după cum urmează, folosind informații corespunzătoare modelului domeniul subiectului:
   • Numele modelului : Activitățile companiei „Nume”;
   • Proiect (numele proiectului): Modelul de activitate al companiei „Nume”;
   • Nume complet, grup;
   • Domeniul de aplicare (zona de modelare care include scopul modelării, adică întrebări la care modelul construit ar trebui să răspundă) - De exemplu, " Management general afaceri ale companiei: cercetare de piață, achiziție de componente, testare și vânzare de produse” sau „Tehnologic, financiar și aspecte de management activitățile companiei”;
   • Interval de timp (tip de model) : Așa cum este;
   • Definiție , scopul modelului) : Model educațional care descrie activitățile companiei „Nume”;
   • Punct de vedere (Punct de vedere – persoană al cărei punct de vedere este adoptat în timpul dezvoltării) : Șeful întreprinderii și directorul general;
   • stare : FUNCTIONARE;
   • Scop : Modelarea proceselor de afaceri curente ale companiei „Nume” în vederea reglementării activităților acesteia;
   • Sursă (sursă informație): Analiza domeniului si analiza documentelor de intrare;
   • Numele autorului : NUMELE COMPLET.
3. Facand descompunerea diagramei de context trebuie avut în vedere că ea, fiind al doilea nivel descompunerea modelului de sistem, reprezintă subproces sau munca copilului , implementate în formă lucrare contextuală, care în acest caz acționează ca munca parentală, implementat în formular Diagrama parentală) . Diagrama de descompunere al doilea nivel trebuie să conțină cel puțin trei blocuri funcționale, dintre care unul trebuie să îndeplinească funcția de modelare contabilitatea activitatii organizație, iar restul ar trebui să îndeplinească funcția de modelare procesele de afaceri implementate în sistem.
4. La fiecare pas de descompunere, ar trebui să monitorizați procesul de mișcare automată a arcurilor de interfață (săgeți) la nivelurile inferioare ale modelului și să încercați să evitați crearea de săgeți tunelizate în mod inutil. Dacă apar, tunelurile ar trebui îndepărtate.
5. La implementare al treilea nivel descompunere, trebuie avut în vedere că fiecare dintre diagramele de descompunere elaborate este al treilea nivel de descompunere a lucrărilor de al doilea nivel și reprezintă subproces sau munca subsidiara implementate în formă Diagrama copilului lucrări relevante de nivel al treilea. Toate lucrările de al doilea nivel în acest caz acționează ca munca parentală, implementat în formular diagrame părinte(Diagrame parentale).
6. Descompunerea lucrării de nivel al doilea, modelarea funcției contabile și crearea unui scenariu pentru interacțiunea muncii ar trebui efectuate folosind tehnologia IDEF 3 care folosește ca blocuri funcționale unitatimuncă (Unitatea de lucru, UOW) , precum și cele necesare obiecte de referință (referenți) , care poate fi fie implementat în script din dicționarul cu săgeți, fie creat din nou.
7. Un dicționar de locuri de muncă și un dicționar de săgeți sunt create la fiecare nivel de descompunere a modelului și o conditie necesara dezvoltarea lor este prezenţa unei fişe de post (activitate)și descrieri ale datelor înregistrate pe arcul de interfață ( săgeată) .
8. Salvați rezultatele lucrării într-un fișier Function_model IS_Name_ IDEF.bp1 în folderul dvs EU VAD.
9. Un exemplu de model funcțional generalizat este dat în

4. Informații teoretice pentru lecția practică

4.1. IDEF 0-tehnologie

Metodologia IDEF0 este concepută pentru a modela activitățile unei organizații. Pe stadiul inițial dezvoltarea proiectului, se creează un model conceput pentru a descrie procesele de afaceri și procesele tehnologice existente la întreprindere conform principiului „AS - AS” (“As Is”) și, important, reprezintă întreprinderea din poziția de angajați. care lucrează la el și îl cunosc în detaliu toate nuanțele, inclusiv cele informale. AS-IS este „ceea ce facem astăzi”, înainte de a trece la „ce vom face mâine”.

Model de activitate sau, cu alte cuvinte, model functional. Model functional tratează sistemul ca pe un set actiuni, in care fiecare acțiune transformă pe unele un obiect sau set de obiecte . Tehnologie IDEF 0 folosește principiul descompunere functionala sisteme (împărțirea sistemului în fragmente). Principiul de descompunereînseamnă că modelul funcțional trebuie construit conform regulii "de sus în jos" , din general tip de model la privat modele. Prin urmare, de obicei, modelul funcțional pentru rezolvarea unei probleme este un set de modele funcționale private .

Modelele funcționale evidențiază acțiunile reprezentându-le ca un element special - bloc. bloc – de bază element structural model funcțional, a cărui reprezentare grafică este diagramă . Numele acțiunii – substantiv verbal sau verb . Ca rezultat al descompunerii modelului, este creat un set de diagrame ordonate ierarhic și interconectate. Fiecare diagramă este o unitate de descriere a sistemului și se află pe o foaie separată.

Metodologie IDEF 0 se bazează pe patru concepte de bază: bloc funcțional (nod), arc de interfață, descompunere, glosar.

Bloc funcțional

Conceptul fundamental de tehnologie IDEF 0 este conceptul bloc funcţional. Este destinat să reprezinte un anumit tip Activitate , care reprezintă unele specifice funcţie în cadrul sistemului în cauză. Această funcție înseamnă, la rândul său, o anumită acțiune (set de acțiuni), având un scop fix și conducând la un rezultat final.

Bloc funcțional este reprezentat printr-un dreptunghi, ale cărui laturi au următoarele valori:

• Partea de sus este managementul.
• Partea de jos este mecanismul.
• Partea dreaptă este ieșirea.
• Partea stângă este intrarea.

Un bloc funcțional are un nume, care este specificat în modul verbal sau un substantiv verbal. Interacțiunea dintre acțiuni iar lumea din jurul lui, inclusiv alte acțiuni, este afișată folosind arce de interfață (săgeți).

Arc de interfață

Arc de interfață afişează un element de sistem care sau prelucrate bloc funcțional sau are un efect diferit la activitatea (funcţia) afişată de acest bloc funcţional. Arc de interfață descris ca o săgeată care indică purtător , asigurand transferul de date sau obiecte de la o activitate la alta. Săgețile descriu interacțiunea lucrărilor cu lumea exterioară și între ele, reprezintă unele informații și sunt numite substantive .

Numele săgeții îl indică rol (setul de roluri posibile este notat cu – ICOM ):

Intrare bloc funcțional – eu nput .

management - C Control .

Ieșire bloc funcțional – O ieșire .

Mecanism - M mecanism .

Intrare) este materialul sau informația care este folosită sau transformată de muncă pentru a produce un rezultat (ieșire). Este posibil să nu existe săgeată de intrare.

Control– reguli, politici, proceduri sau standarde care ghidează munca. Ea influențează munca, dar nu este transformată de muncă. Săgeata este desenată ca intrând în marginea superioară a lucrării. Fiecare bloc funcțional trebuie să aibă cel puțin o săgeată de control.

Este adesea dificil de determinat dacă datele sunt introduse sau controlate. Dacă datele din lucrare sunt modificate sau procesate, atunci aceasta este cel mai probabil intrare, iar dacă nu, este control. Dacă este dificil să determinați starea unei săgeți, se recomandă să desenați o săgeată de control.

Ieșire– materialul sau informația care este produsă de lucrare. Este necesară cel puțin o săgeată de ieșire, care emană din partea dreaptă a lucrării.

Mecanism de execuție (Mecanism)– resursele care efectuează munca (de exemplu, personal, mașini, dispozitive etc.). Săgeata este desenată ca intrând în marginea de jos a lucrării. Este posibil ca săgețile pentru mecanism să nu fie afișate. În general, blocul funcțional este prezentat în Fig. 2.1.

În fig. 2.1 toate arcurile de interfață sunt afișate ca săgeți denumite. Conform cerințelor standardului, fiecare bloc funcțional trebuie să aibă cel puțin o ieșire și un control, deoarece fiecare sarcină (proces) trebuie să aibă cel puțin o ieșire și cel puțin o regulă pentru rezolvarea acesteia. Este posibil ca arcul de interfață „Mecanism” să nu fie reprezentat.

Din mai multe blocuri funcționale conectate prin arcuri de interfață în modul cerut, a model functional.

Vă rugăm să rețineți că săgețile se pot ramifica pentru a realiza conexiunile necesare între blocurile funcționale.

Log in blocul funcțional poate fi nu numai Ieșire un alt bloc funcțional, dar și al acestuia Control sau chiar mecanism. Ca urmare, modelul funcțional poate conține procese diverse, destul de complexe și neobișnuite pentru rezolvarea problemelor din sistemul informațional.

Crearea de diagrame folosind tehnologia IDEF0

Atunci când se dezvoltă modelul de afaceri al unei organizații, trebuie utilizate trei tipuri de diagrame:

• Diagrama tip I – Diagrama context (nu poate fi decât unul) – vârful structurii arborescente, care reprezintă cel mai abstract nivel de descriere a sistemului și a interacțiunii acestuia cu mediul extern. Ea definește funcția de context;
• II tip diagramă – Diagrama de descompunere .

Diagramele de defalcare sunt concepute pentru a detalia lucrul și a conține legate de munca, adica filiale munca care are un comun părintească muncă. Munca de nivel inferior este aceeași cu munca de nivel superior, dar mai detaliat. Diagramele sunt create de un analist pentru a conduce o sesiune de examinare, adică pentru a discuta diagrama cu un specialist în materie.

După fiecare sesiune de descompunere, se desfășoară sesiuni de examinare - experții în materie indică conformitatea proceselor reale de afaceri cu diagramele create. Neconcordanțele găsite sunt corectate și numai după promovarea examenului fara comentarii puteți trece la următoarea sesiune de descompunere. Acest lucru asigură că modelul se potrivește cu procesele de afaceri reale la orice nivel al modelului.

Este necesar să setați numărul de lucrări la cel mult șase (3–6), altfel diagrama este greu de citit (suprasaturată). Limita superioară (șase) forțează proiectantul să folosească ierarhii atunci când descrie obiecte complexe, iar limita inferioară (trei) asigură că diagrama corespunzătoare are suficiente detalii pentru a justifica crearea acesteia.

Într-o diagramă de defalcare, lucrarea care este cea mai importantă și finalizată mai întâi este situată în stânga sus. Lucrarea care este mai puțin importantă sau finalizată mai târziu scade secvenţial.

• III tip de diagramă – Diagrama arborescentă a nodurilor arată dependența ierarhică a locurilor de muncă, dar nu și relațiile dintre joburi (pot fi atât de multe dintre aceste diagrame, câte doriți, deoarece arborele poate fi construit la orice adâncime și nu neapărat de la rădăcină).

4.2. Procesul tehnologic de modelare IDEF0:

Orez. 2.2

Instrumentul BPWin CASE are o interfață de utilizator simplă și intuitivă pentru construirea modelelor și scenariilor funcționale necesare. Depinde de tehnologia folosită. În fig. 2.2 arată fereastra BPWin ( Computer Associates B.P.Win ).

Bara de instrumente a ferestrei principale Computer Associates BPwin conține următoarele butoane:

	– crearea unui nou model,
	– deschiderea unui model existent,
	– salvarea modelului construit,
	- imprimare model,
	- alegerea scalei,
	- scalare,
	- verificarea ortografiei,
	– porniți/dezactivați navigatorul modelului,
	– porniți/dezactivați Model Mart.

Navigatorul de modele arată compoziția modelului în funcție de nivelul de dezvoltare. Cu ajutorul lui, puteți trece ușor și rapid de la un nivel la altul. Lucrul cu navigatorul de model este similar cu lucrul cu Windows Explorer.

Bara de instrumente specială conține următoarele butoane principale:

Fereastra model este locul pentru crearea unui model funcțional al sistemului studiat. În acesta, blocurile funcționale sunt construite și editate, săgețile sunt desenate și editate și se realizează descompunerea.

Pregătirea modelului

1. Faceți clic pe butonul de creare a modelului pentru a deschide caseta de dialog B.P.Win(Fig. 2.3):

În caseta de dialog B.P.Win efectuați următoarele acțiuni:

• alege Proces de afaceri (IDEF0);
• setați numele modelului și apăsați butonul Bine;
• La fereastră Proprietăți pentru modelul nou înregistrați numele autorului modelului;
• apasa butonul Bine .

1. Echipă Model/Proprietăți model caseta de dialog apel Proprietățile modelului (Fig. 4), în care să aranjeze proprietățile modelului în conformitate cu recomandări metodologice, prevăzute în secțiunea 2.

Primul nivel de modelare

1. Proiectați un bloc funcțional în fereastra modelului, parcurgând următorii pași:
   • selectați comanda din meniul contextual al blocului funcțional Nume… ;
   • în caseta de dialog Proprietățile activității (Fig. 2.5) în tab Nume a stabilit Nume lucru (scurt) plasat în acest bloc funcțional, și în fila Definițieîn câmp Definiție Descriere muncă;
   • în marcaj Font setați fontul Arial Cyr și bifați casetele pentru a permite ca acest font să fie utilizat în toate blocurile funcționale ale diagramei ( Toate activitățile din această diagramă, Toate activitățile din acest model Și Schimbați toate aparițiile acestui font în model ), apoi apăsați butonul Bine.

• în caseta de dialog Proprietăți săgeți (Fig. 2.7), în tab Nume setați numele săgeții (scurt), iar în filă Definițieîn câmp Definiție introduceți suficiente detalii Descriere scopul acestei săgeți;

• selectați o comandă din meniul contextual săgeată Font… ;
• în caseta de dialog Proprietăți săgeți (Fig. 2.8), în tab Font setați fontul Arial Cyrși bifați casetele pentru a utiliza acest font pentru toate săgețile din diagramă ( Toate săgețile din această diagramă, Toate săgețile din acest model, Toate instanțele acestei săgeți Și Schimbați toate aparițiile acestui font în model );

1. Proiectați o săgeată Ieșire, stânga frontiere dreapta;
2. Proiectați o săgeată Control , de ce repetați pasul 2, înlocuind stânga frontiere top;
3. Proiectați o săgeată Mecanism, de ce repeta pasul 2, inlocuind stânga frontiere inferior.

Al doilea nivel de modelare

Orice nivel de modelare

Pentru a crea o descompunere a modelului la orice nivel de modelare, ar trebui să efectuați următorii pași:

• activați un anumit bloc funcțional făcând clic;
• repetați pasul 3 pentru nivelul actual al modelului.

1. Tipul și stilul de design al săgeții pot fi selectate în caseta de dialog Arrow Properties (Fig. 2.9), apelată de comanda Style din meniul contextual săgeată.

1. Pentru instalare împachetarea cuvintelor Ar trebui, prin evidențierea numelui, să reduceți dimensiunea dreptunghiului, după care acesta va crește automat în jos.
2. Fiecare săgeată desenată pe o diagramă de nivel superior trebuie să fie prezentă pe o diagramă de nivel inferior.
3. Săgeată nouă desenată pe diagrama de nivel scăzut (nerezolvată ( nerezolvată) săgeată), plasate între paranteze drepte (tunele), care subliniază absența unei astfel de săgeți pe mai multe nivel inalt. Pentru a elimina tunelurile:
   • selectați elementul de meniu Arrow Tunnel ;
   • în caseta de dialog Editor săgeată chenar(Editor săgeată limită) selectați opțiunea Rezolvați-l la Border Arrow (Permiteți ca săgeată la margine). Ca urmare, tunelul de la nivelul actual va fi eliminat, iar săgeata va apărea la nivelul anterior, iar dacă nu este primul, atunci este tunelizat (Fig. 2.10).

1. Pentru a copia săgețile tunelizate de la nivelul inferior în cel superior:
   • faceți clic dreapta pe paranteze pătrate;
   • selectați elementul de meniu Referință în afara paginii;
   • în caseta de dialog Referință săgeată în afara paginii selectați diagrama pe care să plasați săgeata și setați comutatorul de tip săgeată necesar (Fig. 2.11);

• apăsați unul dintre butoanele: OK și mergeți la diagramă (mergi la diagrama selectată) sau OK și rămâneți în diagrama curentă (Rămâneți în diagrama curentă).

Este inacceptabil să lăsați săgeți de delimitare neconectate ( săgeată de frontieră neconectată) – săgețile transferate automat în diagrama de descompunere din diagrama părinte (mod migrație trăgător). Aceste săgeți nu se referă la joburi și trebuie să fie asociate cu joburi în modul Creare săgeți ( Instrumentul săgeată de prioritate – ).

Proiectarea locației și stilului corect al săgeților în mod implicit:

• executa comanda Model/Proprietăți model;
• La fereastră Proprietățile modelului(Fig. 2.12) selectați un marcaj Aspect ;
• bifați caseta (opțional) Spațiează automat săgețile in grup Săgeți

1. Când creați o săgeată părere asupra managementului ar trebui să setați opțiunea pentru a indica direcția săgeții Extra Arrowhead (din meniul contextual).
2. Dacă etichetele de pe săgeți sunt prost plasate (foarte departe, etc.), ar trebui să bifați caseta de selectare Squiggle (în meniul contextual) pentru liderul etichetei.

1. În diagrama de descompunere, în stânga sus este un bloc funcțional, care conține cea mai importantă lucrare care este efectuată mai întâi. Lucrarea care este mai puțin importantă sau finalizată mai târziu scade secvenţial.
2. Împachetarea cuvintelorîn interiorul lucrării se desfășoară în modul Editor de nume... prin apăsarea unei taste introduce.
3. O diagonală în colțul din stânga sus al dreptunghiului înseamnă că lucrarea corespunzătoare nu este descompusă.
4. Pentru a afișa nu numai numărul de joburi secundare care apar automat, ci și prefixele (A), ar trebui să selectați comanda Model/Proprietăți model, marcaj Numerotare caseta de selectare (optional) Afișează prefixul(Fig. 2.13).

1. Pentru a afișa numerele de lucru și numerele de nivel (numere cu două, trei, patru cifre) pentru locurile de muncă pentru copii, selectați comanda Model/Proprietăți model, marcaj Numerotare caseta de selectare (optional) Utilizați formatul de numerotare diagramă (Fig. 2.13).
2. Pentru a face distincția între diferitele versiuni ale aceleiași diagrame, versiunilor individuale ar trebui să li se atribuie numere (C - număr), care pot fi setate liber în meniu Proprietăți diagramă pe marcaj Kit.

Construirea unui arbore model

• echipă Diagramă/Adăugați/Arbore de noduri caseta de dialog apel Node Tree Wizard_Pasul 1 din 2 (Fig. 2.14);
• conduceți un dialog selectând numărul necesar de niveluri de arbore de noduri ( Numărul de niveluri );
• apasa butonul Gata.

4.3. Tehnologia IDEF3

Tehnologie IDEF3 este o metodologie de descriere a procesului care ia în considerare secvență de execuțieȘi relații cauză-efectîntre situaţii şi evenimente. Folosind IDEF3, ele descriu logica executării lucrărilor, ordinea în care sunt începute și finalizate.

Tehnologia IDEF3 folosește categoria scenarii pentru a simplifica structura descrierilor unui proces complex în mai multe etape. Scenariu (Scenariu) – este o secvență repetată de situații sau acțiuni care descriu o clasă tipică de probleme prezente într-o organizație sau sistem și este, de asemenea, o descriere a secvenței de proprietăți ale unui obiect în cadrul procesului luat în considerare. Modelele IDEF0 sunt legate de scenariile IDEF3, deoarece fiecare model IDEF0 poate fi reprezentat ca unul sau mai multe scenarii IDEF3.

Tehnologia IDEF3 este concepută pentru a oferi colectarea datelor de proces și permite:

• documentează datele disponibile cu privire la tehnologia de desfășurare a procesului, identificate, să zicem, în cadrul unui sondaj al specialiștilor din domeniu;
• analizează procesele existente și dezvoltă altele noi;
• simuleaza situatii prin identificarea situatiilor in care este necesar luarea deciziilor , afectând ciclu de viață proces, de exemplu, modificarea designului, proprietăților tehnologice sau operaționale ale produsului final;
• facilitează adoptarea deciziilor optime la reorganizarea procesului.

Scenariu în tehnologia IDEF3

Diagrame de scenarii descrie acțiuni și evenimente care trebuie procesate într-o anumită perioadă de timp. Scriptul este însoțit de o descriere a proceselor și poate fi folosit pentru a documenta fiecare funcție a sistemului. În consecință, scenariile fac parte din analiza sistemului, deoarece fac posibilă analiza în timp a unei situații și descrierea obiectelor care participă la un proces în același timp.

Când se utilizează tehnologia IDEF3, toate construcțiile se bazează pe două tipuri de diagrame:

1. Diagrama care descrie succesiunea etapelor procesului.
2. Diagrama stării obiectului.

Sunt utilizate următoarele convenții standard:

	Element funcțional al comportamentului,
	Transferul acțiunii de la un element funcțional al comportamentului (precedent) la altul (ulterior) ( Precedenta ),
	Tranziția fluxului de date de la job la job ( Fluxul obiectelor ),
	Conectarea datelor la locul de muncă ( Referent ),
	Relația dintre lucrări ( Relațional ),
	Starea obiectului.

Reglarea secvenței de execuție a unităților de lucru se realizează prin introducerea în diagramă intersecții (Joncţiune) în diverse scopuri.

Simbol J intersecția poate lua una dintre următoarele valori:

• & – fuziune rezultatele tuturor acțiunilor dacă săgețile intră în intersecție; lansa toate acțiunile dacă săgețile îl părăsesc;
• DESPRE - fuziune acțiunea rezultă dacă cel puțin una dintre acțiunile de intrare este finalizată; lansa cel puțin o acțiune;
• X - fuziune o singură acțiune dintr-un număr dintre cei care intră în intersecție; lansa doar una dintre acţiunile care ies din ea.

O ilustrare a utilizării unei răscruce în diagrame care descriu succesiunea etapelor procesului este fig. 2.15. Din aceasta rezultă că o răscruce este un mijloc de construire a unor procese tehnologice ramificate complexe.

Descrierea tehnologiei care este dezvoltată sau cercetată mai întâi sub formă diagrame care descriu succesiunea etapelor procesului tehnologic , și apoi în formă diagrame de stare a obiectelor oferă o imagine completă a acțiunilor efectuate și a rezultatelor aplicării acestora.

	Job 3 apare atunci când Job 1 și Job 3 sunt terminate
	Iov 1 și Iov 2 apar împreună
	Lucrarea 3 apare atunci când Lucrarea 1 sau Lucrarea 2 sau ambele sunt terminate
	Job 1 și Job 2 apar împreună sau separat
	Lucrarea 3 apare atunci când Lucrarea 1 sau Lucrarea 2 este încheiată
	Are loc Job 1 sau Job 2

În consecință, managerii și dezvoltatorii de sisteme informatice au în mâinile lor un instrument puternic pentru crearea de scenarii pentru procese complexe de management care necesită studiu și automatizare.

4.4. Procesul tehnologic de modelare IDEF3

Pregătirea modelului

1. Faceți clic pe butonul de creare a modelului.
2. În caseta de dialog B.P.Win urmează următoarele instrucțiuni:
   • alege Fluxul procesului (IDEF3);
   • setați numele modelului;
   • apasa butonul Bine;
   • în caseta de dialog Proprietăți pentru modelul nou confirmați proprietățile specificate acolo.

Formalizarea actiunii

1. Faceți clic pe butonul de acțiune de creare ( Instrumentul casetei de activități ).
2. Faceți clic pe butonul stâng al mouse-ului în locația dorită din fereastra modelului.
3. În meniul contextual de acțiune, selectați comanda Nume…
4. În caseta de dialog Proprietățile activității, în marcaj Nume setați numele acțiunii (Fig. 2.16).

1. În caseta de dialog Proprietățile activitățiiîn marcaj Font a stabilit Arial Cyr, Bine.

Formatarea datelor

1. Faceți clic pe butonul de creare a datelor. ( Instrument de referință ).
2. La locul potrivit pe fereastră Referent faceți clic stânga pentru a încorpora numele datelor din dicționarul de entități create (opțiune Entitate) sau din dicționarul creat de săgeți (opțiunea Săgeată), sau creați-le din nou (opțiune Alte) (Fig. 2.17).

1. În dialog Fereastra Proprietăți referitor (Fig. 2.18), în tab Font a stabilit Arial Cyr bifați casetele de selectare necesare și faceți clic pe butonul Bine.

5. Temele pentru următoarea lecție

1. Gândiți și identificați obiectele materiale sau indivizii, reprezentând surse sau receptori de informații (entități externe).
2. Gândiți și dezvoltați un model relațional al datelor procesate de sistemul informațional:
   • faceți o listă de entități și atributele acestora,
   • arata relatiile dintre entitati.
3. Pe baza specificațiilor tehnice elaborate, gândiți și propuneți profesorului denumirile lucrărilor individuale implementate în sistem în procesul de realizare a fiecăreia dintre lucrările cheie plasate în diagrama de descompunere de nivelul doi.
4. Executarea paragrafelor 1–3 teme pentru acasă salvați-l într-un fișier numit " Informații pentru lecția 3.doc „, realizat în Cuvânt, și prezentat profesorului.
5. Lucrați prin secțiunea „ Informații teoretice pentru pregătirea practică» atelier la a 3-a lecție.

1.6. Fragment din diagrama arborelui nodului la efectuarea descompunerii blocului de contabilitate a activității conform celei de-a doua opțiuni (IDEF3)

Dicţionar de activitate

Nume	Definiție
	Analiza informațiilor citite din baza de date pentru a satisface criteriile specificate
Analiza documentelor	Analiza documentelor însoțitoare și primite pentru conformitatea cu standardele
Întreținerea bazei de date	Efectuarea operațiunilor de actualizare a datelor
ÎN CURS LOC DE MUNCA	Numele funcției de context care definește SCOPUL și LIMITELE simulării
Prelucrare finală	Luarea si formularea unei decizii (POZITIV daca datele indeplinesc criteriile specificate si NEGATIV in caz contrar), precum si crearea si prelucrarea documentelor necesare
Control de calitate și testare	Lucrări care finalizează un proces de fabricație sau dezvoltare
Procesarea datelor	Efectuarea de operațiuni de căutare și analiză a datelor și luarea deciziilor pe baza analizei efectuate
Prelucrarea rezultatelor controlului calității	Sistematizarea si analiza rezultatelor pentru conformitatea cu standardul
Prelucrarea rezultatelor testelor	Analiza rezultatelor pentru funcționalitate, fiabilitate și supraviețuire
Hârtii	Primirea documentelor și selectarea informațiilor pentru a fi introduse în baza de date
	Căutarea datelor în tabelele bazei de date pe baza interogărilor create de utilizator
Reumplerea bazei de date	Introducerea de noi date în tabelele bazei de date
Recepția și înregistrarea documentelor	Recepția și înregistrarea documentelor de însoțire primite
Productie sau dezvoltare	Numele procesului cheie de afaceri al companiei (modelul părții de producție a domeniului subiect)
Lucrul în prima etapă a procesului de afaceri1	O acțiune care rezumă operațiunile tehnologice din prima etapă a procesului de producție
Lucrul în etapa a 2-a a procesului de afaceri1	O acțiune care rezumă operațiunile tehnologice din a doua etapă a procesului de producție
Lucrul în etapa a 3-a a procesului de afaceri1	O acțiune care rezumă operațiunile tehnologice din a treia etapă a procesului de producție
Prelucrarea rezultatelor activitati de productie	Recepția și analiza documentelor pe baza rezultatelor muncii și controlului în curs
Editarea bazei de date	Modificarea înregistrărilor în tabelele bazei de date
CONTABILITATE DE ACTIVITATE	Prelucrarea documentației și raportarea (modelul părții de non-producție a domeniului de studiu)

Dicţionar Arrow

Nume	Definiție
	Obiecte care nu îndeplinesc cerințele standardului
DATE DE INTRARE	Documente primite și obiecte de procesare
Date de intrare DB	Datele care urmează să fie scrise în tabelele bazei de date
Documentele primite	Documente care însoțesc obiectele de procesare și documentele care inițiază un proces de afaceri
IEȘIRE	Documente trimise, obiecte noi și modificate
Documente de ieșire	Documente (formulare, rapoarte, instrucțiuni, declarații, contracte etc.) create în timpul procesului de contabilitate
Standard de stat	Standard de stat pentru documentare
Datele din tabelul bazei de date	Date citite din tabelele bazei de date
Date obținute în urma analizei	Informații destinate procesării documentelor emise și utilizate la luarea deciziilor
Date care caracterizează rezultatele lucrului cu documente	Informații care reflectă detaliile (caracteristicile calitative și cantitative) ale obiectelor prelucrate
Documente privind rezultatele testării și controlului	Documente care reflectă datele obținute în etapa finală a procesării obiectului
Descrierea postului	Instrucțiuni care reflectă responsabilitatile locului de munca interpret
Cererile utilizatorilor
Obiecte noi și schimbate	Obiecte create și modificate în timpul ciclului de producție
Obiecte baze de date	Tabele, formulare, interogări, rapoarte, macrocomenzi și module
Prelucrarea obiectelor	Obiecte care se modifică în diferite etape ale procesului de producție
Obiecte procesate la etapa 1	Obiecte modificate la prima etapă a procesului de producție
Obiecte procesate în etapa 2	Obiecte modificate la a 2-a etapă a procesului de producție
Obiecte procesate în etapa 3	Obiecte modificate în etapa a 3-a a procesului de producție
	Departament control tehnic, care verifică obiectul creat pentru a îndeplini cerințele standardului
Divizii de companie și profesioniști	Entități implicate în procesul de producție sau dezvoltare
REGULI DE EXECUTARE	Reguli pentru transformarea proceselor și a datelor
Reguli contabile	Un sistem de înregistrare și procesare a documentației care însoțește procesul de producție sau dezvoltare
DECIZIE	O decizie pozitivă sau negativă luată în funcție de dacă datele analizate îndeplinesc criteriile specificate
Documente acceptate	Documente care au fost înregistrate
Software	Platforma pe care baza de date în curs de dezvoltare este implementată
Rezultatele analizei documentului	Rezultate obținute în urma analizării documentelor primite și însoțitoare pentru conformitatea cu standardele
Rezultate controlul calității
rezultatele căutării	Informații din tabelele bazei de date obținute din solicitările utilizatorilor
Rezultatele testului	Datele obținute în etapa finală a prelucrării
Manualul utilizatorului	Instrucțiuni și reguli pentru lucrul cu baza de date
Serviciu de contabilitate	Departamentele implicate în procesul de contabilitate și documentare
Documente însoțitoare	Documente care însoțesc obiectele de procesare primite
Specialisti profesionisti	Subiecții implicați în activități de producție
Instructiuni tehnologice	Secvența operațiilor proceselor tehnologice
Cererile utilizatorilor	Interogări create de utilizator pentru a prelua informațiile necesare din baza de date și pentru a crea documente de ieșire
MECANISMUL DE EXECUTARE	Resurse care transformă datele de intrare în date de ieșire
Intrări noi	Înregistrări în tabelele bazei de date care au apărut după introducerea datelor noi
Corecţie
	Subiectul care efectuează examenul

versiune tipărită

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

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

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

Metodologia IDEF0 se bazează pe următoarele principii:

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

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

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

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

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

Exemple de probleme rezolvate pe baza metodologiei de modelare IDEF0:

Analiza si reinginerirea proceselor de afaceri.

Dezvoltarea unui sistem informatic pentru managementul calitatii datelor.

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

Proiecta infrastructura informaţională, proceduri și reglementări pentru interacțiunea informațiilor.

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

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

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

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