Notații de modelare a proceselor de afaceri UML. BPMN (notație): descrierea procesului. Modelarea proceselor de afaceri - Diagramă de flux
BPMN (Business Process Management Notation) este un limbaj de modelare a proceselor de afaceri care este o legătură intermediară între formalizarea/vizualizarea și implementarea unui proces de afaceri.
Pentru a spune simplu, această notație este o descriere a elementelor grafice utilizate pentru a construi o diagramă a fluxului unui proces de afaceri.
Cel puțin, o astfel de schemă este necesară pentru a construi un proces de afaceri în conformitate cu acesta și pentru a-l reglementa în mod clar pentru toți participanții.
Ca maxim, vă permite să automatizați ulterior procesele de afaceri în conformitate cu schema existentă.
Istoria BPMN
Prima versiune a notației BPMN a fost lansată în mai 2004 (BPMN 1.0). Următoarea versiune a apărut în ianuarie 2011 (BPMN 2.0). În cele din urmă, în ianuarie 2013, OMG a lansat versiunea care este cea mai utilizată astăzi - BPMN 2.0.2.Grafică BPMN de bază
Un proces BPMN este orice proces de afaceri reflectat folosind notație. Procesele constau din elemente, fiecare dintre acestea fiind indicat pe diagramă cu o pictogramă specială.Elementele de notație BPMN sunt elemente ale unei diagrame grafice, dar și elemente ale procesului de afaceri în sine.
Notarea se bazează pe următoarele elemente grafice de bază:
- Piscină și Alei
- Acțiuni
- Gateways sau Forks
- Evenimente
- Fluxuri
- Artefacte
Elementele BPMN „Pool” și „Track”
Întregul proces de afaceri este format din pool-uri: un set de operațiuni + persoane care efectuează aceste operațiuni.
De exemplu, pool-ul va fi întregul set de acțiuni pentru încărcarea mărfurilor și trimiterea acestora către client.
În acest caz, sunt identificate așa-numitele „urme”, care alcătuiesc orice bazin. Pentru exemplul nostru, una dintre piste va fi pregătirea documentelor referitoare la încărcarea și expedierea mărfurilor, a doua cale va fi încărcarea fizică a lotului necesar pe mașină și călătoria mașinii la client. Ambele căi se completează reciproc, rulează în paralel, dar în general servesc la finalizarea aceleiași etape a procesului de afaceri.
Elementul BPMN „Acțiune”
O „acțiune” este o unitate de lucru efectuată în timpul execuției unui proces de afaceri. Acțiunile pot fi fie elementare (sarcină), fie complexe (sub-proces). Există mai multe tipuri de acțiuni elementare care diferă în condițiile lor de execuție:
- Executarea repetată a unei acțiuni în cadrul unui singur proces. De exemplu, aceeași acțiune poate fi efectuată în paralel pentru fiecare articol dintr-o comandă de vânzare.
- Acțiunea ciclică este executată în mod repetat atâta timp cât condiția specificată este adevărată.
 |
Problemă abstractă | Folosit pentru a desemna o acțiune sau o operațiune simplă care nu are nicio descompunere ulterioară în cadrul procesului de afaceri curent. |
 |
Subproces | Folosit pentru a afișa un proces descompus inclus în procesul în cauză. Subprocesul este descris mai detaliat în diagrama acestuia. |
 |
Legătura de proces | Folosit pentru a indica o referire la unul dintre procesele cele mai frecvent repetate. |
 |
Sarcina utilizatorului | Folosit pentru a arăta sarcina pe care o îndeplinește o persoană. |
 |
Sarcina de execuție a scriptului | Folosit pentru a afișa un pas de proces la atingerea căruia scriptul este executat automat. |
 |
Sarcina de apel de service | Folosit pentru a ilustra o etapă a procesului în care este apelat un serviciu web sau un script C#. |
 |
Carcasă încorporată | Folosit pentru a reprezenta o sarcină non-rutină supravegheată de o persoană responsabilă sau de un grup de persoane. Cazurile sunt folosite atunci când trebuie să organizați rapid activitatea nestructurată sau semistructurată în cadrul unui proces. |
Elemente BPMN „Fork” sau „Gateway”
Gateway-urile sunt înțelese ca elemente care determină ramificarea și îmbinarea fluxurilor de lucru.BPMN descrie 7 tipuri de furci. Există 2 tipuri principale:
| Exclusiv-sau poarta | Folosit pentru a crea fluxuri de proces alternative sau fluxuri de control convergente. | |
| Poarta paralelă | Folosit pentru a crea căi paralele fără a evalua nicio condiție sau pentru fire convergente și sincronizare fire paralele de execuție a procesului. |
Un exemplu de utilizare a unei porți exclusive sau pentru a crea fire de procese alternative:
- Etapa 7. Apelarea clientului pentru a evalua calitatea serviciului.
- 1. Dacă clientul este mulțumit, înregistrați o evaluare pozitivă, închideți procesul de afaceri.
- 2. Daca clientul este nemultumit, afla motivul.
Schema ulterioară se poate ramifica foarte mult: dacă clientul este nemulțumit de livrare, atunci trebuie să contacteze șeful acestui serviciu; iar dacă este vorba despre calitatea produsului, atunci următoarea etapă va fi transferarea reclamației către departamentul de producție sau escaladarea (ridicarea nivelului ierarhic) pentru a transmite informații despre o astfel de reclamație către conducerea superioară. De fapt, gateway-urile sunt una dintre cele mai critice și complexe etape ale proceselor de afaceri. Eficiența întregului sistem depinde în mare măsură de cât de competent sunt precizate toate condițiile și consecințele conform principiului „Dacă... atunci”.
Elementul BPMN „Eveniment”
Un „eveniment” este unul dintre elementele principale ale BPMN și servește pentru a descrie ceva care ar trebui să se întâmple (spre deosebire de o sarcină, în care ar trebui făcut ceva). Un eveniment ar putea fi, de exemplu, semnarea unui contract sau o conversație cu un client.
Grafica evenimentelor din BPMN sunt clasificate în două moduri:
- În funcție de poziția evenimentului pe diagrama procesului:
| Evenimentul de pornire (inițializarea unui proces de afaceri) | |
| Eveniment intermediar | |
| Încheierea evenimentului (încheierea unui proces de afaceri). |
- Clasificarea după tipul de eveniment este următoarea:
| Eveniment simplu | Reprezintă un eveniment netipificat. | |
| Eveniment mesaj | Indică dacă un mesaj a fost trimis sau primit. | |
| Eveniment cu temporizator | Folosit pentru a modela evenimente obișnuite. Cronometrul poate fi folosit și pentru a simula momente în timp, intervale de timp și depășirea unei limită de timp. |
Elemente BPMN „Fluxuri”
Un flux este o secvență de acțiuni, care este indicată de o săgeată. Elementul „flux” arată ce acțiune trebuie efectuată după care. |
Controlul fluxului | Fluxul de control standard nu este afectat de condiții și nu trece prin gateway-uri, de ex. este incontrolabil. |
 |
Flux de control condiționat | Folosit pentru a arăta că execuția ulterioară a unui proces va avea loc de-a lungul unui anumit fir numai dacă este îndeplinită o condiție specificată. Un diamant la baza săgeții este adăugat dacă fluxul de control condiționat este dintr-un proces. Diamantul nu este adăugat dacă fluxul de control condiționat este de la gateway. |
| Flux de control implicit | Este folosit atunci când este necesar să se arate că execuția ulterioară a unui proces va avea loc de-a lungul unui anumit fir numai dacă nu este îndeplinită nici una dintre condițiile specificate. | |
 |
Fluxul de mesaje | Folosit pentru a afișa comunicarea între procese - afișează transferul de mesaje sau obiecte de la un proces la altul proces sau referință externă. |
 |
Asociere | Folosit pentru a vizualiza relația dintre elementele de flux și obiectele care nu sunt elemente de flux (artefacte). |
Elemente BPMN „Artefact”
În BPMN, artefactele sunt înțelese ca obiecte care nu afectează direct execuția unui proces de afaceri. Acestea pot fi documente, date, informații.Principalele tipuri de artefacte:
 |
Grup de obiecte | Folosit pentru a grupa elemente grafice aparținând aceleiași categorii și pentru a face diagrama mai ușor de citit. |
 |
Adnotare text | Folosit pentru clarificări ale diagramei - comentarii și explicații care vor crește lizibilitatea diagramei. |
| Obiect de date | Folosit pentru a afișa informații despre datele care sunt procesate în timpul procesului. |
Beneficiile BPMN
Descrierea BPMN a unui proces de afaceri are mai multe avantaje.Prima este ușurința de a traduce diagramele în modele executabile folosind un limbaj pentru descrierea formală a proceselor de afaceri.
Descrierea elementelor BPMN este clară pentru majoritatea participanților la procesele de afaceri și adesea nu necesită nicio explicație suplimentară. Folosind o expresie grafică simplă, puteți crea reglementări specifice care vor fi respectate de angajați.
Alături de faptul că descrierea notației BPMN 2.0 permite angajaților să înțeleagă cum apar procesele de afaceri, această notație este susținută de majoritatea instrumentelor moderne de modelare a afacerii, care permite importul de diagrame de procese de afaceri gata făcute în sistemele BPM.
Elena Gaidukova, analist de marketing, brand manager de soluții bazate pe , specialist în relații de parteneriat.
Modelarea proceselor de afaceri a devenit munca clasică a multor analiști de afaceri ca parte a optimizării proceselor de afaceri și a standardizării activităților companiilor rusești. Există multe notații care sunt folosite în anumite cazuri. Acest articol este dedicat unei revizuiri a notațiilor de modelare a proceselor de afaceri.
VAD (vdiagramă de lanț ală adăugată)
Notația VAD, introdusă de Michael Porter în munca sa privind strategia corporativă, se concentrează pe modelarea proceselor de afaceri care „creează valoare” sub formă de servicii sau produse pentru client. Un model de proces de afaceri construit în notație VAD oferă o vedere generală, nedetaliată a proceselor de afaceri.
Folosind notația VAD, puteți descrie lista și relația proceselor de afaceri la nivelul superior, deoarece această notație vă permite să afișați toate procesele de afaceri ale companiei pe un singur model. În notația VAD, puteți utiliza relații care arată relația proceselor de afaceri unul față de celălalt, în timp ce fluxul de proces din această notație este direcționat în mare măsură de la stânga la dreapta.
Există multe variante ale notației VAD implementate în diverse instrumente și fiecare cu propriul set de simboluri, dar toate arată aproximativ la fel - un set de procese de afaceri, adesea interconectate prin legături „predecesor-succesor”.
De exemplu, extinderea acestei notații în setul de instrumente ARIS vă permite să prezentați performanți, riscuri, documente, date și multe, multe altele pe un model de proces de afaceri.
Pe lângă modelarea hărții proceselor de afaceri a unei organizații, notația VAD vă permite să modelați procesele de afaceri end-to-end atunci când sunt definite inițial. Dar trebuie să înțelegeți că VAD nu este destinat să modeleze condiții logice într-un proces și, prin urmare, este perceput perfect de către management. În practică, după modelarea proceselor de afaceri la nivelul superior în notația VAD, urmează modelarea mai detaliată a proceselor de afaceri în alte notații, pe care le vom analiza în detaliu mai jos.
Modelul de notație VAD poate fi desenat într-o varietate de instrumente, cum ar fi MS Visio și multe alte instrumente de modelare a proceselor de afaceri.
Modelarea proceselor de afaceri – EPC (lanțul de procese bazat pe evenimente)
Notația EPC a fost dezvoltată de profesorul August Wilhelm Scheer în cadrul metodologiei setului de instrumente ARIS. Folosind un proces de afaceri, acesta este modelat ca o listă de pași ai procesului declanșați de evenimente. Notația este convenabilă pentru reglementarea ulterioară a unui proces de afaceri, precum și pentru analiza fluxului de informații al unui proces de afaceri (documente de intrare/ieșire).
Libertatea notației EPC vă permite să descrieți obiecte suplimentare în cadrul modelării proceselor de afaceri, cum ar fi riscuri operaționale, proceduri de control, formulare de ecran, sisteme de informații, indicatori și multe altele.
În cadrul notației EPC, procesul este modelat de sus în jos, iar ordinea de execuție a pașilor/funcțiilor/acțiunilor/operațiilor unui proces de afaceri este determinată printr-un sistem de evenimente și condiții logice. Începutul și finalizarea etapelor procesului, precum și evenimentele externe care necesită un răspuns din partea organizației, sunt considerate evenimente în notația EPC.
Modelul procesului de afaceri este format din secvențe „eveniment-funcție-eveniment” și operatori logici „ȘI”, „SAU”, „SAU exclusiv” care afișează deciziile, verificarea condițiilor, paralelizarea și convergența fluxurilor procesului de afaceri modelat.
Există multe opțiuni pentru notația EPC, în format coloană, rând, precum și cu diferite liste de obiecte utilizate, totuși, toate aceste opțiuni sunt disponibile numai în setul de instrumente ARIS, în timp ce în alte instrumente, de exemplu, MS Visio sau Business Studio , Modelarea proceselor de afaceri EPC este disponibilă numai într-un format clasic.
Modelarea unui proces de afaceri în notația EPC vă permite să obțineți ulterior un text sau o reglementare tabelară a proceselor de afaceri, deoarece un model EPC desenat corect poate fi convertit într-o secvență de propoziții în limbaj obișnuit, care devine baza reglementării. De aceea, această notație este considerată cea mai convenabilă pentru modelarea proceselor de afaceri în scopul analizei și reglementării ulterioare.
Modelare Afaceri— proceselor– BPMN (Business Process Model and Notation 2.0)
Notația BPMN a fost creată de consorțiul Object Management Group (OMG) și este destinată modelării proceselor de afaceri în scopul automatizării lor ulterioare. Notația BPMN este utilizată pentru modelarea detaliată a unui proces de afaceri, iar numărul de obiecte din această notație depășește 100, ceea ce vă permite să descrieți toate nuanțele comportamentului proceselor de afaceri, astfel încât sistemul informațional să poată converti modelul creat în executabil. cod.
Deschiderea notației BPMN și suportul de către majoritatea instrumentelor de modelare și automatizare a proceselor de afaceri au făcut din această notație un lider în modelarea proceselor de afaceri.
În notația BPMN, pe lângă pașii unui proces de afaceri, puteți modela evenimentele de început, intermediare și finale ale procesului, fluxurile de informații și fluxurile de mesaje. Printre caracteristicile notației, se poate evidenția utilizarea implicită a stilului de modelare Swim Lane, atunci când executantul este afișat ca o dungă verticală sau orizontală, care amintește de benzile dintr-o piscină, și tocmai pe această bandă se desfășoară acțiunile. /operațiunile efectuate de acest executant sunt localizate.
Eficientizarea unui proces de afaceri în formatul Swim Lane face posibilă transferul clar a responsabilității și a fluxului de muncă între participanții la proces, dar, în același timp, face dificilă modelarea în cazul mai multor co-executori într-o singură operațiune .
Modelele desenate în notația BPMN sunt adesea dificil de asamblat într-o ierarhie coerentă, deoarece metodologia a fost creată inițial pentru a automatiza procesele de afaceri „end-to-end”.
Aplicarea notației BPMN necesită o anumită experiență, ceea ce limitează adesea numărul de creatori ai acestor modele la sisteme și analiști de afaceri. Reprezentanții unităților de afaceri modelează procesele de afaceri în notație BPMN destul de rar.
În ciuda diferențelor grafice, notațiile BPMN și EPC sunt foarte asemănătoare între ele, iar în trusa de instrumente ARIS pot fi deja convertite una în alta, deși cu anumite limitări metodologice.
Modelarea proceselor de afaceri - Diagramă de flux
Numele notației Flow Charting este cel mai ușor tradus ca diagrame flux. Această notație a apărut inițial în standardul ANSI în 1970 și conține un set foarte simplu de caractere.
De-a lungul anilor de existență a notației Flow Charting, s-au desenat multe variante de diagrame de flux care conțin simboluri pentru rezolvarea diverselor probleme, de exemplu, pentru descrierea fluxurilor de materiale, roluri și locuri de muncă, echipamente, pentru analiza intrărilor și ieșirilor de funcții.
De fapt, diagramele de flux au fost predecesorii notațiilor moderne pentru modelarea proceselor de afaceri și până acum au fost predate în majoritatea instituțiilor de învățământ în cadrul disciplinelor dedicate tehnologiei informației.
Notația Flow Charting nu are un standard rigid, care vă permite să modelați procesele de afaceri din diferite puncte de vedere, adăugând anumite obiecte la model după cum este necesar. În acest fel, această notație este foarte asemănătoare cu EPC, dar are și mai multă libertate în aplicare. Libertatea opțiunilor de aplicare pentru diagrame de flux și suportul celor mai ieftine și chiar gratuite instrumente de modelare a proceselor de afaceri au făcut această notație aplicabilă multor companii.
Unul dintre dezavantajele diagramei de flux este lipsa unei liste standard de obiecte și atribute, care este cealaltă parte a „libertății” acestei notații. Acest lucru vă permite să modelați același proces de afaceri în această notație, astfel încât modelele să fie semnificativ diferite unele de altele.
În ciuda faptului că modelele de procese de afaceri în notația Flow Charting pot fi găsite destul de des, cel mai probabil va deveni un lucru din trecut, dând loc unor „notații mai stricte”
Modelare Afaceri— proceselor– IDEF (Limbaj de definiție integrat)
Notația IDEF a apărut în anii 70 ca un standard guvernamental american care se concentrează pe intrările, ieșirile, mecanismele și controalele unui proces de afaceri și leagă procesele unei organizații într-o ierarhie. Elementul cheie al acestei notații este funcția, în timp ce toate celelalte obiecte și interacțiuni sunt modelate folosind relații.
Notația folosește un set foarte simplu de simboluri: dreptunghiuri de proces și săgeți care ilustrează intrări, ieșiri, controale și mecanisme, această notație se distinge printr-un sistem de numerotare „încorporat” pentru etapele procesului de afaceri, care vă permite să urmăriți relațiile dintre părinte. și procesele copil.
Având în vedere istoria acestui standard și utilizarea sa destul de răspândită, acesta este implementat în multe instrumente de modelare, dar totuși această notație poate fi atribuită generației de ieșire, deoarece are din ce în ce mai puțini susținători, iar reprezentanții afacerilor tratează adesea aceste „cipuri” cu scepticism.
UML (Unificat Modelare Limbi)
Unified Modeling Language (UML) este un set de notații și metode de modelare concepute pentru a descrie cerințele pentru sistemele informaționale, dar printre notațiile UML există și o notație specializată concepută special pentru modelarea proceselor de afaceri. UML este susținut de Object Management Group (OMG), care a făcut această metodologie destul de comună în rândul profesioniștilor IT.
Această notație este foarte asemănătoare cu EPC și BPMN, singura diferență este în afișarea operatorilor logici și a evenimentelor și, deși există multe cărți despre notația UML și este susținută de multe instrumente de modelare, Diagrama UML Activiti este utilizată în principal pentru analiza și proiectarea sistemelor și doar un număr mic de companii utilizează UML pentru a modela procesele de afaceri
VSM (Valoare Curent Cartografiere)
Numele notației VSM poate fi tradus în rusă ca mapare a fluxului de valoare pentru clienți. Numele inițial al acestei notații a fost la Toyota Corporation, unde se crede că a fost inventat - Harta fluxului de materiale și informații.
Notația VSM a fost dezvoltată ca parte a metodologiei Lean Manufacturing și folosește un set de simboluri specifice pentru a reprezenta elementele de intrare de resurse și timp pentru analiza performanței procesului de afaceri în proiectele Lean 6Sigma. O hartă a fluxului de valoare descrie mediul fizic și fluxul de materiale și produse în producție și este utilizată pentru a asocia resursele și timpul intrărilor unui proces și, astfel, oferă o perspectivă asupra productivității
Scopul acestei notații este de a implica participanții săi în analiza unui proces de afaceri pentru a-i încuraja să caute în mod independent oportunități de optimizare. De regulă, modelele VSM sunt desenate în proiecte pe Flip Chart și nu necesită instrumente serioase pentru modelarea proceselor de afaceri, deoarece deciziile se iau pe baza acestuia, iar modelul în sine nu devine baza nici pentru reglementări, nici pentru soluții IT.
Principalul lucru la crearea unui model în notația VSM este completarea atributelor temporare pentru procesul de căutare a „gâturilor de sticlă” și a locurilor de stocare excesivă a stocurilor.
Această notație are un cerc restrâns de adepți și nu va fi larg răspândită în rândul publicului larg al analiștilor de afaceri în viitorul apropiat datorită specificului problemelor rezolvate cu ajutorul ei. Dar, în același timp, multe instrumente de modelare a proceselor de afaceri, de exemplu, ARIS, au dezvoltat deja extensii pentru a sprijini modelarea proceselor de afaceri în această notație.
SIPOC
Abrevierea SIPOC înseamnă: Furnizor, Intrare, Proces, Ieșire, Client. Acesta este un șablon de documentare a procesului adoptat în metodologia Six Sigma de fapt, nu este nici măcar o notație de model, ci un format de tabel care vă permite să descrieți un proces de afaceri la nivel superior; Modelul SIPOC este cel mai eficient utilizat la definirea limitelor unui proces de afaceri, a părților care interacționează și a intrărilor/ieșirilor procesului.
Nu există nicio notație pentru SIPOC, deoarece este un tabel simplu cu titluri adecvate care vă permite să structurați procesul de afaceri selectat pentru analiza și optimizarea ulterioară.
Utilitatea SIPOC, spre deosebire de alte diagrame, constă în posibilitatea utilizării sale de către angajații unităților de afaceri, deoarece nu conține o logică complexă și multe obiecte, cum ar fi notațiile EPC sau BPMN.
Modelarea proceselor de afaceri – concluzii
Așadar, m-am uitat la câteva notații de modelare a proceselor de afaceri care pot fi găsite pe piața rusă (sunt descrise mai detaliat în capitolul BPM CBOK dedicat modelării proceselor de afaceri). Ce notație să alegeți pentru utilizare este o întrebare deschisă, de exemplu, pentru a modela procesele de afaceri ale unei organizații la nivel superior, folosesc notația VAD pentru modelarea primară a unui proces de afaceri selectat pentru optimizare, este mai ușor de utilizat SIPOC sau VAD. Pentru a crea modele detaliate ale proceselor de afaceri - BPMN simplificat pentru modelarea interacțiunii interfuncționale sau EPC pentru modelarea detaliată în scopul formalizării fluxului de informații și a multor obiecte asociate unui proces de afaceri. Ei bine, dacă trebuie să automatizați un proces de afaceri într-un sistem BPMS, atunci nu vă puteți descurca fără notația BPMN.
Instrument BPMN gratuit
Cawemo este un instrument online gratuit pentru dezvoltarea, discutarea și partajarea diagramelor BPMN cu echipa ta.
Instrument BPMN gratuitRevizuire
Am predat BPMN la mii de oameni și am folosit notația în munca noastră zilnică de proiect din 2007. Mai jos puteți găsi multe exemple BPMN de probleme comune de modelare. Indiferent de proiectul dvs. specific sau de industria dvs., există multe întrebări frecvente despre utilizarea BPMN. Din experiența noastră, majoritatea exemplelor BPMN de mai jos sunt utile pentru orice utilizator BPMN.
Ne-am alăturat OMG în 2009 ca membru influent. De atunci am fost implicați în dezvoltarea BPMN 2.0.
Exemple BPMN
Regulile de afaceri și BPMN
Scenariul de simulare
Să presupunem că vrem să modelăm un proces în BPMN și procesul invocă unele reguli de afaceri. Vom folosi exemplul creării unei facturi. Pentru a crea o factură, trebuie să calculați reducerea. Suma comenzii și tipul de client sunt criteriile relevante pentru calcularea reducerii.
Acesta este un exemplu foarte simplu care ne va arăta unde să folosim BPMN și unde să nu folosim.
Roluri ale motorului Creare factură Solicitare factură Calculare reducere Creare factură Factură creată
Explicaţie
În timpul simulării, ne concentrăm asupra fluxului procesului. În acest exemplu, procesul are două etape. Reducerea se calculează înainte de crearea facturii. Rezultatul este un proces foarte simplu.
Nu are sens să modelezi calculul reducerii în sine într-un model BPMN (vezi exemplul de mai jos). Pentru un arbore decizional de reguli, pentru fiecare criteriu suplimentar, puterile vor crește exponențial. Acest lucru nu este ceea ce ne dorim într-un model BPMN.
Prin urmare, este logic să se separe procesele și regulile de afaceri.
Creați o factură Faceți o reducere de 2% Adăugați o reducere de 1% Cine este cumpărătorul? Solicitare factura suma solicitata? Tipul de cumpărător? Creați o factură Factura a fost creată Faceți o reducere de 3% Faceți o reducere de 4% Cine este cumpărătorul? adăugați 1% reducere adăugați 1% reducere 1000 - 1500 500 - 999 >2000< 500 Тип A Тип A Тип A обычный обычный обычный
Instanțele dependente
Scenariul de simulare
Să presupunem că vrem să modelăm un proces cu instanțe care se potrivesc. Vom folosi un exemplu simplu. Dacă se efectuează o verificare a creditului asupra unui client, nu dorim ca o altă verificare a creditului pentru același client să fie efectuată în același timp.
Motivul poate fi că numărul total de verificări de credit efectuate afectează rezultatul verificării.
Să presupunem că efectuăm o verificare a creditului pentru un client și primim o a doua cerere pentru același client în același timp.
Ceea ce toate soluțiile au în comun este că fiecare instanță nouă trebuie să verifice, de exemplu, potrivirea la nivel de date înainte de a începe verificarea reală a creditului.
Soluție pentru evenimente de semnal
Verificarea bonității Vizualizați interogările Vizualizați evenimentele declanșate (cu acestea) care rulează instanțe ale aceluiași client? si acelasi client? Verificare credit Verificare finalizată Verificare finalizată Intrare în baza de date nu da
Explicaţie
Un eveniment semnal este cel mai simplu și mai compact mod de a modela interacțiunile dintre diferite instanțe. Problema semnalului este că funcționează ca o transmisie și nu se adresează niciunei instanțe specifice. Deci, strict vorbind, clientul este ignorat și toate cazurile de așteptare îl prind.
Soluție pentru evenimente de mesaje
Verificarea creditului Solicitări de verificare Verificarea proceselor care rulează același client) care rulează instanțe ale aceluiași client? verificare credit credit confirmat așteptați evenimentul cumpărătorului? verificați cazurile în așteptare (de la același client) pornirea instanței finalizată informați instanța în așteptare Bază de date Baza de date nu nu da da
Explicaţie
Această soluție este puțin mai complicată, deoarece trebuie să determinați destinatarul (o instanță) a mesajului. Acest lucru determină o a doua cerere de date înainte de sfârșitul instanței. Cu toate acestea, aceasta este modalitatea corectă de a rezolva problema care apare în rezolvarea unui eveniment semnal.
Soluție cu temporizator și buclă
Verificarea bonității Solicitările de verificare verifică procesele care rulează (un utilizator) care rulează instanțe ale unui client? efectuați verificarea creditului așteptați puțin timp verificați baza de date de credit nu da
Explicaţie
În acest exemplu, nu avem nevoie de o conexiune între instanțe. Instanța în sine verifică frecvența dacă poate trece la verificarea creditului. Dezavantajul este că acest lucru poate cauza întârzieri și supraîncărcări din cauza buclei.
Principiul Patru Ochi
Scenariul de simulare
Dorim să modelăm următoarea situație folosind BPMN 2.0. O solicitare (cum ar fi o plată) necesită două permisiuni de la două persoane diferite. Motorul de proces trebuie să se asigure că ambele aprobări sunt satisfăcute înainte ca cererea să fie aprobată. Pașii manuali executați de doi autorizatori ar trebui, de asemenea, modelați în diagrama BPMN. Decizia de aprobare este luată folosind un portal de listă de sarcini.
Cazuri de utilizare
Cazurile de utilizare pentru acest șablon sunt numeroase. Aici sunt cateva exemple:
- Aprobarea plății
- Aprobarea facturii
- Aprobarea contractului
Soluție ca diagramă BPMN 2.0
Primul aprobator Aprobare solicitată Evaluați cererea citită și comentată Sarcina finalizată Procese din motor Confirmați cererea confirmați sau de acord (prima linie) Confirmat? Cerere respinsă (prima linie) respingere sau confirmare (a doua linie) Confirmată? Solicitare respinsă (linia a 2-a) Cerere confirmată Al doilea aprobator confirmă rata cererii Cerere de citire și comentare finalizată nu da da nu
Explicaţie
Folosim pool-uri separate pentru Process Engine, pentru primul aprobator și pentru al doilea. Astfel putem defini clar cine controlează ce proces.
Grupul de motoare utilizează sarcini personalizate. Aceste sarcini personalizate corespund sarcinilor care sunt afișate în lista de sarcini de aprobare prima și a doua.
Interacțiunea dintre sarcinile utilizatorului din motor și între procesul manual al aprobatorilor este modelată folosind fluxuri de mesaje. Aceste fluxuri de mesaje încapsulează pașii de documentare pe care un afirmator trebuie să îi parcurgă pentru a finaliza o sarcină de utilizator.
Lista de sarcini în sine nu este modelată pentru a reduce complexitatea.
Variante
Aprobare ca bazine dărâmate
Primul reconciliator Al doilea reconciliator Motorul de proces confirmare cerere respingere sau confirmare (prima linie) Confirmat? Solicitare respinsă (prima linie) respingere sau confirmare (a doua linie) Confirmată? Cerere respinsă (linia a 2-a) Cerere confirmată nu da da nu
Definirea unei destinații folosind LDAP
Primul aprobator confirmă cererea evaluează cererea de citire și comentare sarcină finalizată LDAP Motor de proces confirmare cerere respingere sau confirmare (prima linie) Confirmat? Cerere respinsă (prima linie) respingere sau confirmare (a doua linie) Confirmată? Cerere respinsă (linia a 2-a) Cerere confirmată determinați primul și al doilea aprobator Al doilea aprobator confirmarea ratei cererii de citire și comentare sarcină finalizată nu da da nu
Facturare lunară
Scenariul de simulare
Acest exemplu explică o luptă foarte comună cu structurarea diagramelor BPMN 2.0. Să presupunem că există un avocat care oferă consultanță juridică clienților săi. Serviciul funcționează astfel: clienții pot solicita consultanță juridică ori de câte ori au nevoie. Avocatul oferă sfatul solicitat și plasează ore facturabile pe foaia de pontaj a clientului. Când luna se termină, CPA determină orele facturabile pe baza programului și creează o factură.
Acest exemplu ilustrează un scenariu de modelare foarte general. Nu pașii procesului sunt complexi, ci structura diagramei.
Soluție ca diagramă BPMN 2.0
Consultație avocat Solicitare consultație Oferă sfaturi Înregistrează timp Solicitare procesată Contor client Client Înregistrează venit lunar Prima zi a lunii Stabilește orele facturabile Creați și trimiteți factură primiți bani Factură finalizată 14 zile Trimiteți memento Doar unul pe lună Mai multe pe lună
Explicaţie
Cel mai important aspect al unei diagrame este structura acestuia.
Procesul de furnizare de consultanță juridică are loc de mai multe ori pe lună. Procesul de facturare lunară rulează doar o dată pe lună. Prin urmare, aceste două procese trebuie modelate ca grupuri separate.
Desigur, aceste două bazine nu sunt complet independente unele de altele. Pentru ce? Ei lucrează pe aceleași date - foaia de pontaj a clientului. Capacitatea noastră de a modela o astfel de conectivitate legată de date este foarte limitată în BPMN. Acest lucru se datorează faptului că BPMN este orientat mai degrabă asupra fluxului de control decât a fluxului de date.
Cu toate acestea, putem folosi un element de depozit de date pentru a modela această conexiune la nivel de date.
Mod greșit de a modela
Consultație avocat Solicitare consultație Oferiți sfaturi Înregistrați ora 1 luna viitoare stabiliți orele facturabile creați și trimiteți factură Primiți bani Factură finalizată 14 zile Trimiteți memento Client
Explicație de ce este greșit
În acest exemplu, ambele procese sunt amestecate într-unul singur. Acesta este - în cel mai bun caz - un mod foarte implicit de modelare. Acest lucru ar însemna că pentru fiecare consiliere juridică acordată, s-ar trimite o factură o dată pe lună. Această metodă de modelare este incorectă în majoritatea cazurilor.
Informații suplimentare necesare după sarcina utilizatorului
Scenariul de simulare
Să presupunem că vrem să modelăm următorul scenariu: Vrem să realizăm o sarcină personalizată care este efectuată de un utilizator pe portal. Pot fi necesare informații suplimentare după finalizarea sarcinii utilizatorului. În acest caz, procesatorul trimite o cerere de informații către alt utilizator (soluția 1) sau serviciul tehnic (soluția 2).
Soluția 1: Solicitați informații de la alt utilizator
Utilizatorul este autentificat. Utilizatorul este autentificat. Motor de proces. Sarcină pentru utilizator. Sunt necesare informații suplimentare. informație? Solicitați informații (de la utilizator) ... nu da
Soluția 2: Solicitați informații de la serviciul tehnic
Utilizatorul s-a autentificat Unele motor de proces de service tehnic Sarcină pentru utilizator Necesită suplimentar. informație? Trimiteți cerere Informații primite... nu da
Procesarea unui lot de comenzi de pe piață
Situatie
Dorim să modelăm următorul scenariu folosind BPMN 2.0: Să presupunem că o companie primește comenzi de la diferite canale de distribuție. Unul dintre aceste canale este piața. La anumite intervale, comenzile din piata sunt acceptate in loturi. Fiecare comandă din acest lot trebuie verificată înainte de a intra în sistemul ERP.
Soluție ca diagramă BPMN 2.0
Sistem ERP Piață Importați comenzi în ERP La fiecare 10 minute Colectați toate comenzile de pe piață Procesul comenzii Comandă unică nouă Verificați datele comenzii Sunt datele corecte? Importarea unei comenzi în sistemul ERP O comandă în proces Data comenzii este incorectă Toate comenzile în proces sunt separate Comanda nu da
Explicaţie
Acest exemplu arată un scenariu de modelare foarte general. Uneori numim asta problema 1-la-n. O instanță de proces (importul comenzilor) duce la multe instanțe de proces separate ale altui proces (sistem ERP). Design-urile tipice sunt mai multe instanțe sau bucle care pornesc alte procese folosind mesaje (fluxuri de mesaje).
Reatribuirea sarcinilor utilizatorului
Scenariul de simulare
Să presupunem că trebuie să ne asigurăm că o anumită sarcină de utilizator este finalizată cu siguranță. Prin urmare, sarcinile utilizatorului trebuie reatribuite de îndată ce persoana desemnată actuală nu este disponibilă, de exemplu din cauza vacanței sau a unei boli.
Soluția 1: Serviciu de mesagerie și redirecționare
Nota
Acest lucru are sens dacă motorul cheamă un serviciu pentru a determina un nou cesionar.
Soluția 2: Reguli de transmitere a mesajelor și reguli de redirecționare
Utilizatorul s-a autentificat. Motorul de proces determină destinatarul sarcinii utilizatorului... responsabilul nu este disponibil
Nota
Acest lucru are sens dacă motorul apelează motorul de reguli pentru a determina un nou cesionar.
Soluția 3: Evenimentul limită mesajului și redirecționarea implicită
Utilizator autentificat. Sarcina utilizatorului motorului de proces... destinatarul nu este disponibil
Nota
Acest lucru are sens dacă motorul determină cel mai nou cesionar, de exemplu folosind o expresie.
Escaladare în două etape
Scenariul de simulare
Vom folosi următorul exemplu pentru a ilustra cum să modelăm escaladarea în doi pași folosind BPMN 2.0. Când vrem pizza, o comandăm. Uneori, livrarea pizza durează mai mult și durează mai mult de 20 de minute să ajungă. Apoi ne plângem de serviciul de livrare. După aceea, le mai acordăm încă 30 de minute să livreze pizza. Dacă nu fac acest lucru în timp util, vom refuza și vom anula comanda.
Soluția 1: Două gateway-uri bazate pe evenimente
Se dorește pizza Comandă pizza Pizza livrată Mănâncă pizza Pizza consumată 30 minute Reclama la serviciul de livrare Pizza livrată 20 minute Comanda anulată Comanda anulată
Beneficiile acestei soluții
Această soluție arată foarte clar cum funcționează escaladarea în doi pași. Temporizatoarele sunt modelate separat și apoi acțiunile lor de escaladare corespunzătoare.
Dezavantajele acestei soluții
Gateway-ul bazat pe evenimente nu este un simbol BPMN intuitiv al standardului BPMN, este necesară experiență.
Utilizarea a două gateway-uri bazate pe evenimente mărește modelul și duce la un mesaj de eveniment Pizza duplicat.
Soluția 2: Acceptați lucrarea cu cronometrele activate
Se dorește pizza Comandă pizza Mănâncă pizza Pizza consumată Reclamați serviciul de livrare Comanda anulată Comanda anulată Așteptați pizza Reclamați comanda 50 minute 30 minute
Beneficiile acestei soluții
Acest model este mai mic decât prima soluție și este probabil modul în care majoritatea dezvoltatorilor vor rezolva problema din motor. Deoarece folosim un eveniment cronometru atașat neîntreruptibil, această soluție este mai flexibilă atunci când ne ocupăm de reclamații multiple (de exemplu, vrem să ne plângem la fiecare 5 minute până la expirarea 50 de minute).
Dezavantajele acestei soluții
Sarcina de primire nu este de obicei intuitivă pentru „băieții de afaceri” care ar prefera să folosească evenimentele de primire a mesajelor pentru o astfel de stare de așteptare.
Modul în care funcționează temporizatoarele cu întreruperi și fără întreruperi necesită o înțelegere profundă a evenimentelor atașate.
Soluția 3: un gateway bazat pe evenimente cu un temporizator comun
Vreau pizza Comanda pizza Pizza livrata Mananca pizza Mananca pizza Timpul a trecut! Reclamați-vă despre livrare Comanda anulată Comanda anulată Sarcina este finalizată? Cronometrul a arătat mai multe da nu
Beneficiile acestei soluții
Acest model oferă o soluție compactă și generală a problemei. Dacă vorbiți despre escaladarea în n pași, veți avea nevoie de această abordare generală pentru a evita diagramele uriașe.
Dezavantajele acestei soluții
Soluția generală este mai puțin evidentă decât alte soluții. Nu vedem duratele reale ale cronometrelor, deoarece același cronometru este folosit pentru ambele durate.
Această metodă de modelare nu este potrivită pentru înțelegerea rapidă a escaladării în două etape.
Stiluri de modelare BPMN
Încercați să evitați pe cât posibil traversarea pârâurilor. Acest lucru va crește înțelegerea modelelor de proces BPMN - atât pentru utilizatorii BPMN cu experiență, cât și pentru cei neexperimentați.
Desigur, nu este întotdeauna posibil să evitați complet această problemă. Rețineți că este întotdeauna logic să investiți ceva timp suplimentar în optimizarea aspectului, astfel încât majoritatea fluxurilor încrucișate să fie eliminate.
Exemplele de mai jos ilustrează problema cu un exemplu abstract.
Bun exemplu de manipulare a firelor
Procesul început, efectuați prima sarcină Acțiune necesară? finalizați sarcina a doua Procesul finalizat executați sarcina trei ok? da Planul A Planul B nu
Contra exemplu
Procesul a început. Sarcina 1 Acțiune necesară? executa sarcina a doua Proces finalizat Sarcina trei Ok? da Planul A Planul B nu
Cel mai important, fiecare simbol BPMN trebuie să aibă o etichetă.
Evenimentele trebuie marcate folosind participiul „obiect + trecut”. Evenimentele de pornire ar trebui să fie întotdeauna marcate cu un declanșator de proces. Evenimentele de sfârșit trebuie să fie marcate cu starea finală a procesului.
Procesul (pool) în sine trebuie să fie întotdeauna marcat. Această etichetă trebuie să indice numele procesului și rolul care îl rulează.
Sarcinile trebuie etichetate folosind obiect + verb. Acest lucru forțează persoana model să se concentreze pe ceea ce se face de fapt în timpul sarcinii.
Gateway-urile X-OR trebuie marcate cu o întrebare. Fluxurile de secvență de ieșire trebuie să fie etichetate cu posibile răspunsuri la aceste întrebări (condiții).
Bun exemplu de numire
Verificați data comenziia Serviciul de comandă Comanda primită Verificați comanda Verificați comanda Data comenzii este corectă. Data comenzii este corectă? Data comenzii este incorectă da nu
Versiune generală
Nume proces Rol care execută procesul Procesul declanșator Obiect + verb Obiect + Participiu Prima stare finală după încheierea procesului Întrebări? A doua stare finală după încheierea procesului răspuns 1 răspuns 2
Contra exemplu
Comandă plasată Start Verificare Scriere stare în baza de date Sfârșit Eroare Ok
Acest exemplu BPMN este despre crearea unui aspect bun al modelelor de proces. Cu cât aspectul este mai bun, cu atât este mai mare gradul de înțelegere. Acesta este ceea ce vrem să realizăm atunci când creăm modele de proces.
Am stabilit că structurile simetrice măresc înțelegerea modelelor de proces BPMN - atât pentru utilizatorii BPMN cu experiență, cât și pentru cei neexperimentați.
Un bun exemplu de model simetric
Pregătiți o salată Simțiți-vă foame Selectați o rețetă Ce fel de mâncare? Gătiți paste Mănâncă mâncare Foamea este satisfăcută Gătiți friptură Care sunt ingredientele? Selectați: - Salată - Paste - Friptură Friptură Salată de paste Mâncare caldă
Contra exemplu
Pregătiți salata A apărut foamea Selectați rețeta Ce fel de mâncare? Gătiți paste Mănâncă mâncare Foamea este satisfăcută Gătiți friptură Care sunt ingredientele? Selectati: - Salata - Paste - Friptura Friptura Pasta Salata mancare calda
Exemplu bun de model simetric 2
Produs proaspăt Comanda livrat produs vechi folosit Suma comandă peste 25.000 €? Procesul de comandă Organizarea livrării Ambalarea mărfurilor Livrarea comenzii Procesul de comandă da nu
Contraexemplul 2
Produse proaspete Comandați mărfuri vechi în stoc livrate. Valoarea comenzii este mai mare de 25.000 €? Comanda Efectuează livrarea Produs Comanda livrare Procesul de comandă da nu
Motivul este simplu. Oamenii tind să interpreteze dimensiunile sarcinilor chiar dacă nu au semantică în standardul BPMN.
Unii oameni cred că sarcinile mai mari sunt mai importante decât sarcinile mai mici - conform BPMN, acest lucru este incorect.
Unii oameni cred că sarcinile mari durează mai mult decât sarcinile mai mici - acest lucru nu este adevărat conform BPMN.
Puteți evita cu ușurință această confuzie folosind aceleași dimensiuni de sarcini.
Un bun exemplu de dimensiuni egale ale sarcinilor
Primul aprobator confirmă solicitarea de citire a ratei cererii și sarcina de comentare finalizată
Contra exemplu
Primul aprobator Confirmați cererea Solicitarea documentului făcut și sarcina ștearsă a comentariului a fost finalizată
Modelul AS-IS sau modelul „așa cum este” este un model de procese de afaceri la momentul studiului întreprinderii și este construit cu scopul de a înțelege cum funcționează o anumită întreprindere din punctul de vedere al analizei sistemului. Acest model este construit cu scopul de a identifica erorile și blocajele, precum și de a formula propuneri de îmbunătățire a situației.
În al doilea capitol al acestui workshop, când studiem metodologiile și tehnologiile de proiectare, am construit deja un model al acestui proces de afaceri. Prin urmare, în această parte a manualului vom clarifica acest model doar folosind informațiile obținute în timpul procesului de colectare.
Model de context:
Titlu: Vanzarea produselor finite din depozit.
Scop: Creșterea vânzărilor.
Punct de vedere: sef departament vanzari.
Date de intrare: copie a facturii, copie a contractului, comanda.
Date de ieșire: cerere, factură, extras jurnal, raport, refuz de a onora comanda.
Management: gama de elemente de fixare, prețul curent al elementelor de fixare, statutul întreprinderii, reglementări privind departamentul de vânzări.
Mecanisme: angajat departament vanzari.
Modelul contextului este prezentat în Figura 18.
Fig. 18. Diagrama de context
Să trecem la construirea unei diagrame de descompunere. După procesarea chestionarelor, putem identifica principalele funcții: verificarea gradului de pregătire a comenzii, organizarea plății, organizarea livrării, întocmirea rapoartelor. Diagrama de descompunere este prezentată în Figura 19.
Fig. 19. Diagrama de descompunere
Să analizăm interviul și să ne uităm la tehnologia reală a muncii angajatului de vânzări. Pe baza acestor date, funcțiile principale pot fi descompuse. Funcția principală „Verificarea pregătirii comenzii” poate fi descompusă în următoarele acțiuni: selectarea contractelor pentru data curentă, acceptarea comenzilor pentru data curentă, reconcilierea cu jurnalul de produs finit. Descompunerea este prezentată în Figura 20.
Funcția principală „Organizarea plății” poate fi descompusă în următoarele acțiuni: calcularea sumei plății, emiterea unei facturi, plata facturii. Descompunem funcția principală „Organizarea emiterii” astfel: emiterea unei cerințe, notificarea depozitului despre pregătirea mărfurilor, pregătirea unui extras pentru departamentul de contracte, schimbarea jurnalului de vânzări. Descompunem funcția principală „Pregătirea rapoartelor” în următoarele acțiuni: analiza datelor, eșantionarea datelor, tipărirea rapoartelor. Diagramele corespunzătoare sunt prezentate în Figura 21, 22, 23.
Fig.20. Diagrama de descompunere A1
Fig.21. Diagrama de descompunere A2
Fig.22. Diagrama de descompunere A3
Fig.23. Diagrama de descompunere A4
Deoarece designerii se confruntă cu scopul de a automatiza fluxul de documente, înainte de a descompune procesele, este logic să luăm în considerare modelul fluxului de documente. În acest caz, puteți merge în două moduri: luați în considerare un model separat de flux de documente și descompuneți procesele individuale de afaceri prin construirea de diagrame DFD.
⇐ Anterior567891011121314Următorul ⇒
Informații conexe:
Cauta pe site:
Notație ARIS Value-added Chain Diagram (ARIS VAD).
În fig. 2.30 prezintă una dintre cele mai importante notații ARIS - notația ARIS VAD. O diagramă a lanțului de procese care adaugă valoare este utilizată pentru a descrie procesele de afaceri ale unei organizații la nivel superior. De regulă, consultanții care folosesc ARIS recomandă identificarea a șase până la opt procese de afaceri de nivel superior și descrierea lor în notația ARIS VAD. Apoi procesele de nivel superior rezultate sunt descompuse în notația ARIS VAD sau ARIS eEPC.
Modelele AS-IS și TO-BE
Să luăm în considerare obiectele notației ARIS VAD prezentate în Fig. 2.30.
Obiectul principal al notației ARIS VAD este Lanțul de valoare adăugată - un proces sau un grup de funcții organizaționale care servește la obținerea valorii adăugate. Obiectele sunt conectate între ele printr-o săgeată punctată, care are tipul este predecesor („este un predecesor”). Acest tip de comunicare arată că un proces este predecesorul altuia. Este evident însă că, în practică, toate procesele de bază sunt ciclice. În plus, au link-uri de feedback. Prin urmare, termenul este predecesorul, în opinia noastră, este regretabil.
Între procesele prezentate în Fig. 2.30 pot fi afișate fluxuri de resurse materiale și informații, pentru descrierea cărora se pot folosi obiecte de tipul de termeni Cluster și, respectiv, Tehnic. Pentru a descrie infrastructura necesară pentru a executa procesul, în acest exemplu sunt selectate tipurile de obiecte Produs/Servicii și Servicii Informații. Alegerea tipurilor de obiecte pentru afișarea fluxurilor reale este destul de arbitrară. Este foarte important la începutul lucrărilor de modelare a proceselor să decideți ce tipuri de obiecte vor fi utilizate și ce obiecte din lumea reală vor reprezenta. Deci, în cazul exemplului prezentat în fig. 2.30, s-ar putea afișa toate fluxurile (informații și materiale) folosind obiecte de tipul Termen tehnic.
În fig. În figura 2.30 sunt prezentate și obiectele unităților organizaționale, afișând unitățile care efectuează procesele corespunzătoare.
Obiectele sunt conectate între ele folosind conexiuni de un anumit tip (vezi Fig. 2.30). De exemplu, fluxul de informații afișat de obiectul Cluster este introdus în primul proces și este asociat cu acesta folosind o săgeată de tipul pentru care este introdus. Un alt exemplu este tipul de conexiune execută între lanțul cu valoare adăugată și obiectele unității organizaționale. Este utilizat după tipul de relație indică faptul că produsul/serviciul este utilizat de un proces etc. Astfel, în metodologia ARIS, cea mai importantă cerință este selectarea corectă și utilizarea ulterioară a conexiunilor și obiectelor de un anumit tip.
În fig. Figura 2.31 prezintă un exemplu de model de nivel superior, executat în notația ARIS VAD. Sunteți deja familiarizat cu acest proces. Mai sus, în fig. 2.16, același proces este reprezentat în notația IDEF0.
88____________________________ BB. Repin, V.G. Eliferov
Capitolul 2 Alegerea unei metodologii pentru descrierea proceselor de afaceri________________________________ 89
Principiile construirii unei diagrame de proces de nivel superior în notația ARIS VAD diferă semnificativ de notația IDEF0. Asa de. în notația ARIS VAD, săgețile pot merge în orice parte a obiectului Lanț de valoare adăugată. (Reamintim că în notația IDEF0, fiecare parte a unui obiect Activitate (funcție) are profunzime și semnificație). În fig. Figura 2.32 prezintă o situație posibilă în notația ARIS VAD. când diagrama de proces conține multe feedback-uri care sunt de înțeles doar analistul care a creat modelul.
Acest dezavantaj al notației ARIS VAD poate fi eliminat prin stipularea în prealabil a posibilității utilizării speciale a legăturilor de feedback, ca, de exemplu, în Fig. 2.33. Rețineți că această abordare poate provoca critici în rândul specialiștilor ARIS, deoarece contrazice notația. Dar aderăm la punctul de vedere că acest lucru este destul de acceptabil, deoarece modelele de nivel superior din notația ARIS VAD pot fi folosite într-adevăr doar ca cel mai simplu mod de a descrie grafic un lanț de proces.
Încheind revizuirea notației ARIS VAD, subliniem încă o dată că această notație este în mare măsură ilustrativă și nu este destinată creării de modele complexe de procese la nivelul superior al unei organizații.
90 V.V. Repin, V.G. Eliferov. Abordarea procesuala a managementului
2.7.2. Notația ARIS eEPC - o extensie a notației IDEF3
Notația ARIS eEPC (Extended Event Driven Process Chain) este un lanț de proces extins bazat pe evenimente.
Notația a fost elaborată de specialiști de la IDS Scheer AG, Germania, în special, profesorul Scheer. În tabel 2.2 prezintă principalele obiecte utilizate în notație.
Tabelul 2.2 Principalele obiecte utilizate în construirea diagramelor eEPC
Pe lângă obiectele principale indicate în tabel. 2.2, multe alte obiecte pot fi folosite la construirea unei diagrame eEPC. În practică, utilizarea unui număr mare de obiecte de diferite tipuri este nepractică, deoarece acest lucru crește semnificativ dimensiunea modelului și îl face dificil de citit.
91
Pentru a înțelege semnificația notației ARJS cEPC, luați în considerare principalele tipuri de obiecte și relații utilizate (Fig. 2.34-2.38). În fig. Figura 2.34 prezintă cel mai simplu model ARIS eERS, care descrie un fragment din procesul de afaceri al unei întreprinderi.
Din fig. Figura 2.34 arată că conexiunile dintre obiecte au o anumită semnificație și reflectă succesiunea funcțiilor din cadrul procesului. Săgeata care conectează Evenimentul 1 și Funcția 1 „activează” sau inițiază execuția Funcției 1. Funcția 1 „creează” Evenimentul 2, urmat de simbolul operatorului logic „ȘI”, „declanșează” execuția Funcțiilor 2 și 3.
O analiză atentă a notației ARIS eEPC arată că practic nu este diferită de notația IDEF3. Cea mai importantă diferență între ARIS eEPC este prezența unui obiect „eveniment”. Acest obiect este folosit pentru a afișa în model rezultatele posibile ale executării funcțiilor, în funcție de care se execută una sau alta ramură ulterioară a procesului. Notația ARIS eEPC este în mod evident numită extinsă tocmai din cauza prezenței unui obiect „eveniment” în ea (nu există un astfel de obiect în IDEF3). În fig. 2.35 oferă exemple de utilizare a simbolurilor logice și de evenimente la construirea modelelor în notația ARIS eEPC.
La construirea modelelor în ARIS eERS, trebuie respectate următoarele reguli:
1. Fiecare funcție trebuie să fie declanșată de un eveniment și încheiată
eveniment;
2. Fiecare funcție nu poate include mai mult de o săgeată, „I launch
„shchi” execuția sa și nu ar trebui să existe mai mult de o săgeată care să descrie
finalizarea functiei.
Pe lângă aceste reguli, există și alte cerințe importante pentru crearea modelelor în ARIS. Ele pot fi studiate folosind materialul metodologic „Metode ARIS”. care este instalat pe computer simultan cu versiunea demo a produsului, precum și în .
În fig. Figura 2.36 arată utilizarea diferitelor obiecte ale notației ARIS eEPC la crearea unui model de proces de afaceri.
92____________________________ BB. Repin, V.G. Eliferov.Abordarea procesuala a managementului
Din fig. 2.35 și 2.36 este clar că un proces de afaceri în notația ARIS eEPC este o secvență de proceduri aranjate în ordinea executării lor. Trebuie remarcat faptul că durata reală a procedurilor în ARIS eERS nu poate fi reflectată vizual. Acest lucru duce la faptul că, atunci când se creează modele, sunt posibile situații în care unui interpret i se va încredința responsabilitatea
Capitolul 2 Alegerea unei metodologii pentru descrierea proceselor de afaceri___________________________________________ 93
îndeplinirea a două sarcini în același timp. Logica folosită în construirea modelului SIM-YULA ne permite să reflectăm ramificarea și fuzionarea unui proces de afaceri. Pentru a obține informații despre durata reală a proceselor și pentru a afișa vizual volumul de muncă al personalului din proces, puteți utiliza alte instrumente de descriere, de exemplu diagramele Gantt în sistemul MS Project.
Să ne uităm la exemple de utilizare a notației ARIS eEPC pentru a descrie procesele de afaceri. În fig. 2.37. Este prezentat procesul de afaceri de procesare a unei comenzi de client. Același proces este descris în notația IDEF3 din Fig. 2.23.
Procesul începe cu evenimentul „Comandă client primită”. Acest eveniment inițiază funcția „Postează comandă în sistem”, care este realizată de managerul Departamentului de Vânzări. El folosește un „Sistem de contabilitate a comenzilor” pentru a finaliza lucrarea. Rezultatul execuției funcției este afișat prin evenimentul „Contabilitatea comenzii finalizată”. După aceasta, managerul Departamentului de vânzări efectuează funcția „Efectuați o analiză pentru conformitatea produsului”. Rezultatul executării funcției sunt două evenimente alternative: „Comanda se potrivește cu articolul” și „Comanda nu se potrivește cu articolul”. Procesul se ramifică. Pentru a afișa ramificarea unui proces, se folosește simbolul unui operator logic - exclusiv „SAU”.
Funcția „Anunțați clientul că comanda nu poate fi îndeplinită” poate fi efectuată în două cazuri: 1) comanda nu corespunde articolului și 2) producția este imposibilă. Pentru a afișa aceste opțiuni pe diagrama procesului, se folosește simbolul operator logic „SAU”, etc.
După cum se poate observa din fig. 2.37, diagrama procesului din ARIS eERS diferă de diagrama din IDEF3 în prezența obiectelor: evenimente, documente, sisteme de aplicații și poziții. Diagrama din ARIS eEPS este vizual mai informativă și este percepută mai bine, dar dimensiunea acestei diagrame este semnificativ mai mare decât dimensiunea diagramei din IDEF3.
Procesul discutat mai sus poate fi prezentat și în notația ARIS PCD (Process Chain Diagram) - o variație a ARIS eEPC. În fig. Figura 2.38 prezintă procesul de afaceri de procesare a unei cereri de client în notație ARIS PCD. La descrierea acestui proces se folosesc toate obiectele care alcătuiesc procesul prezentat în Fig. 1. 2.37, dar sunt dispuse sub formă de coloane de tabel. Prima coloană prezintă evenimente și câteva simboluri logice, a doua - funcții, a treia - documente de intrare și ieșire, a patra - tipuri de aplicații software, iar a cincea - poziții ale angajaților implicați în proces. Această reprezentare a procesului este mai „standard”. Este mai potrivit pentru scopuri de documentare a procesului. Cu toate acestea, reprezentarea în notația ARIS PCD are un dezavantaj semnificativ - poate fi utilizată eficient pentru procese simple (nu mai mult de cinci până la opt funcții), de preferință liniare. Este incomod să afișați procese complexe cu logică ramificată folosind notații ARIS PCD, așa cum se poate observa clar în Fig. 2.38.
94_________________________________ BB. Repin. V.G. Eliferov. Abordarea procesuala a managementului
Orez. 2.37. Exemplu de model de proces
Capitolul 2 Alegerea unei metodologii pentru descrierea proceselor de afaceri________________________________ 95
în notația AR1S eEPC.
96____________________________ V.V., Repin, V.G. Eliferov.La sută ABORDAREA ESENȚIALĂ A MANAGEMENTULUI
Orez. 2.38. Exemplu de procesare
Capitolul 2 Alegerea unei metodologii pentru descrierea proceselor de afaceri 9 7
Aplicații și notații AR1S PCD.
98 V.V. Repin,În G. Eliferov Abordarea procesuala a managementului
Notarea organigramei AR1S
Notația ARIS Organizational Chan este una dintre principalele notații ARIS și este destinată construcției de diagrame ale structurii organizaționale a unei întreprinderi. De obicei, acest model este construit la începutul unui proiect de modelare a proceselor de afaceri. Modelul reflectă diviziunile existente ale întreprinderii sub forma unei structuri ierarhice, așa cum se arată în Fig.
Modelul este construit din obiectele Unitate organizatorică, Poziție, Persoană internă etc.
Tipurile de conexiuni incluse în notație fac posibilă reflectarea diferitelor tipuri de relații între obiectele structurii organizaționale. În cel prezentat în Fig. În exemplul 2.39, întreprinderea este gestionată de un director, iar tipul de conexiune este Organization Manager pentru. Ierarhia departamentelor este construită folosind link-uri de tipul din care este compusă. În plus, se pot indica posturile - Funcția și numele salariaților efectivi care le ocupă - Persoană internă, tip de legătură ocupa.
Pe lângă modele ale ierarhiei departamentelor, se pot construi modele ale ierarhiei subordonării în echipe de proiect, grupuri etc. Toate obiectele reflectate în modele pot fi folosite în viitor la crearea modelelor de procese de afaceri. La construirea unor structuri ierarhice complexe, se poate folosi descompunerea, de exemplu, structura unui departament poate fi prezentată mai detaliat.
Capitolul 2 Alegerea unei metodologii pentru descrierea proceselor de afaceri_________________________________ 99
Anterior78910111213141516171819202122Următorul
Model AS-IS– acesta este un model „ca atare”, adică modelul unui proces/funcție deja existent. Sondajele de proces sunt o parte esențială a oricărui proiect de creare sau dezvoltare a sistemului. Construcția unui model funcțional AS-IS vă permite să înregistrați în mod clar ce procese sunt efectuate la întreprindere, ce obiecte de informații sunt utilizate atunci când executați funcții la diferite niveluri de detaliu.
Pe baza modelului Așa cum este se ajunge la un consens între diferitele etape ale procesului cu privire la „cine a făcut ce” și ce adaugă fiecare etapă procesului. Modelul funcțional AS-IS este punctul de plecare pentru a analiza nevoile întreprinderii, identificarea problemelor și blocajelor și dezvoltarea unui proiect de îmbunătățire a proceselor de afaceri. Modelul AS-IS ne permite să ne dăm seama „ce și cum facem acum” înainte de a determina „ce și cum vom face mâine”. Analiza modelului funcțional AS-IS ne permite să înțelegem unde se află situația problemă, care vor fi avantajele noilor procese și ce modificări vor fi aduse structurii existente a organizării procesului. E nevoie de cercetare restructurare(identificarea și eliminarea deficiențelor) în procesele existente se realizează prin utilizarea descompunerii (analizei), realizată chiar și acolo unde funcționalitatea este evidentă la prima vedere.
Model funcțional AS-IS
Deci, de exemplu, semne ineficiența proceselor existente poate fi:
- funcții inutile, ingestionabile și duplicative;
- flux de documente ineficient (documentul potrivit nu este la locul potrivit la momentul potrivit);
- lipsa feedback-ului asupra controlului (funcția nu este afectată de rezultatul acesteia), intrare (obiectele sau informațiile sunt folosite irațional) etc.
La crearea unui model AS-IS, un analist neexperimentat poate face o greșeală destul de comună - crearea unui model idealizat, mai ales atunci când modelul este creat sub influența cunoștințelor (punctului de vedere) managerului. De obicei, un manager este familiarizat cu modul în care o funcție ar trebui să fie îndeplinită în manuale și fișele postului și adesea nu este conștient de modul în care subordonații îndeplinesc de fapt funcțiile necesare. Prin urmare, modelele numite AR TREBUI SĂ FIE(așa cum ar trebui să fie) și purtând informații false și care nu pot fi utilizate în continuare pentru analiză.
Dacă vă confruntați cu sarcina de a descrie activitatea unei organizații, aveți o cantitate imensă de informații dezorganizate pe mâini. Dacă sunteți în situație de pierdere și nu știți în ce mod să abordați toate acestea, vă recomand următoarea secvență de acțiuni:
2. Determinați ce tip de model de proces de afaceri aveți nevoie pentru a construi și selectați o listă de metodologii care pot fi utilizate în modelare (utilizați ghidul descris mai jos);
3. Comparați metodologiile și notațiile de modelare pentru tipul dvs. de model și alegeți metodologia potrivită pentru dvs.:
- Metodologii pentru modelarea proceselor de afaceri de nivel superior și a fluxurilor de date;
- Metodologii de modelare a fluxurilor de lucru;
- Metodologii de modelare a structurii informaţiei.
4. Construiește un model.
Un ghid pentru notații și metodologii
Pentru a nu ne confunda în tot felul de metodologii și notații care sunt folosite pentru construirea celor mai comune modele organizaționale (modele de management - procese de afaceri la nivel superior, modele de flux de lucru și modele de informații - structura informațională), ofer un ghid și detaliile sale suplimentare.
Dacă cel puțin un nume al metodologiei sau al notației nu vă este familiar, citiți mai departe dacă totul este familiar, dar interesant și doriți să vă reîmprospătați memoria, atunci aruncați o privire rapidă.Metodologii clasice
În ciuda diferențelor lor, asociate în principal cu numele diagramelor și tipurile de obiecte utilizate, metodologiile moderne de descriere a proceselor de afaceri sunt aproape identice și reprezintă modificări minore la standardele clasice.
