Introducere. Sarcini tipice pentru descrierea proceselor de afaceri

și în stadiile incipiente ale proiectelor, al căror scop este reorganizarea și implementarea proceselor de afaceri sisteme de informare, managerii și specialiștii au cel mai adesea următoarele întrebări:

1. ce rezultate în ceea ce privește îmbunătățirea activităților organizației pot fi obținute folosind tehnologii pentru descrierea și reorganizarea proceselor de afaceri;
2. ce software să folosești în proiect („ARIS este mai bun decât BPwin?”, „ERwin este mai bun decât ARIS?” etc.);
3. modul de modelare a proceselor folosind produsul „X”;
4. cum să analizezi și să identifici problemele folosind produsul „X”;
5. ce metodologie să folosiți pentru a descrie procesele;
6. ce să facă în continuare cu modelele de proces de afaceri rezultate.

În prezent, pe piața rusă sunt prezentate un număr destul de mare de sisteme CASE, dintre care multe permit într-un mod sau altul să creeze descrieri (modele) ale proceselor de afaceri ale întreprinderii. În același timp, există sisteme care se concentrează în primul rând pe crearea modelelor de proces și sunt incomode sau deloc concepute pentru crearea modelelor de date și configurarea unui SGBD. În mod evident, alegerea sistemului este determinată de obiectivele proiectului și afectează semnificativ întregul său curs ulterioară. O alegere rațională a sistemului este posibilă dacă conducerea companiei și specialiștii acesteia înțeleg mai multe aspecte:

1. obiectivele proiectului;
2. cerințe pentru informații care caracterizează procesele de afaceri și necesare analizei și luării deciziilor în cadrul unui anumit proiect;
3. capacitățile sistemelor CASE de a descrie procesele ținând cont de cerințele de la paragraful 2;
4. caracteristici ale sistemului informatic în curs de dezvoltare/implementare.

Este inutil să vorbim despre avantajele unui anumit sistem/notație până la tipul și domeniul de aplicare al proiectului, precum și sarcinile principale care acest proiect trebuie să decidă. Articolul nostru face o încercare de a compara cele mai populare notații (sisteme de notație adoptate pentru modelare) folosite pentru a descrie procesele de afaceri și două sisteme care suportă aceste notații. Este de așteptat ca acest material să servească drept bază pentru o discuție cu privire la problemele utilizării eficiente a sistemelor CASE pentru descrierea și analiza proceselor de afaceri ale întreprinderii.

Descrierea proceselor de afaceri este realizată în scopul analizei și reorganizării lor ulterioare. Scopul reorganizării poate fi introducerea unui sistem informatic, reducerea costurilor de producție, îmbunătățirea calității serviciului clienți, crearea de instrucțiuni de muncă și de lucru la implementarea standardelor ISO 9000 etc. Pentru fiecare astfel de sarcină, există anumiți parametri care determină un set de cunoștințe critice despre procesul de afaceri. De la sarcină la sarcină, cerințele pentru descrierea proceselor de afaceri se pot schimba. În general, un model de proces de afaceri ar trebui să ofere răspunsuri la următoarele întrebări:

1. ce proceduri (funcții, lucrări) trebuie efectuate pentru a obține rezultatul final specificat;
2. în ce secvență sunt efectuate aceste proceduri;
3. ce mecanisme de control și management există în cadrul procesului de afaceri luat în considerare;
4. roluri și responsabilități - cine realizează procedurile procesului;
5. ce documente/informații de intrare folosește fiecare procedură de proces;
6. ce documente/informații de ieșire generează procedura de proces;
7. ce resurse sunt necesare pentru a efectua fiecare procedură de proces;
8. ce documentație/condiții guvernează implementarea procedurii;
9. ce parametri caracterizează implementarea procedurilor și a procesului în ansamblu;
10. există o secvență de procese care minimizează costurile (inclusiv costul, timpul etc.);
11. în ce măsură procesul este/va fi susţinut de sistemul informaţional.

Descrierea unui proces de afaceri se formează folosind notație și un mediu de instrumente care vă permite să reflectați toate aspectele de mai sus. Numai în acest caz modelul procesului de afaceri va fi util pentru întreprindere, deoarece poate fi analizat și reorganizat.

Notarea organigramei ARIS

Notarea organigramei este una dintre principalele notații ale ARIS și este destinată construirii diagramelor structura organizationalaîntreprinderilor. 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. 5 .

Modelul este construit din obiectele „Unitate organizațională”, „Poziție”, „Persoană internă”, etc. Tipurile de conexiuni incluse în notație fac posibilă reflectarea tipuri diferite relaţiile dintre obiectele structurii organizatorice. În cel prezentat în Fig. În exemplul 5, „Enterprise” este gestionat de „Director”, iar tipul de conexiune „este Organization Manager for” este utilizat. Ierarhia departamentelor este construită folosind conexiuni de tipul „este compus din”. În plus, pot fi indicate posturi - „Poziție” și numele angajaților reali care îi ocupă: „Persoană internă”, precum și tipul de conexiune „ocupă”.

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 construirea modelelor de procese de afaceri. Atunci când se construiesc structuri ierarhice complexe, se poate folosi descompunerea, de exemplu, structura unui departament poate fi reflectată într-o diagramă mai detaliată.

Notații acceptate de BPwin 4.0

Descrierea notațiilor IDEF0 și IDEF3

Notația IDEF0 a fost dezvoltată pe baza metodologiei de proiectare și analiză structurală SADT, aprobată ca standard american și utilizată cu succes în multe proiecte legate de descrierea activităților întreprinderii. IDEF0 a devenit extrem de răspândit și este, în special, un standard în acest sens organizatii internationale precum NATO și FMI. Notația IDEF3 a fost dezvoltată pentru a descrie mai convenabil fluxurile de lucru, pentru care este important să reflectăm secvența logică a procedurilor. Obiectele cu notațiile IDEF0 și IDEF3 sunt prezentate în tabel. 2 și .

Semantica construirii modelelor IDEF0 și IDEF3 necesită respectarea unor reguli clare. O descriere completă a standardelor IDEF poate fi găsită la http://www.idef.com/.

Un exemplu de descriere a unui proces de afaceri în notația IDEF0 este prezentat în Fig. 8 (corespunde procesului prezentat în Fig. 3).

Una dintre caracteristicile descrierii proceselor în notația IDEF0 este o identificare clară a avantajelor și dezavantajelor proceselor de afaceri. Lucrările pe diagrama IDEF0 sunt aranjate în ordinea dominantei - din colțul din stânga sus al diagramei până în dreapta jos. În colțul din stânga sus este fie cea mai importantă lucrare, fie lucrarea făcută prima. Săgețile conectează lucrările și există cinci tipuri de conexiuni. O săgeată direcționată de la ieșirea unei lucrări superioare la intrarea sau controlul uneia inferioare este o conexiune directă; o săgeată direcționată de la ieșirea unei operații de nivel inferior la intrarea sau controlul uneia de nivel superior este feedback. Lipsa feedback-ului, munca fără rezultate sau management, munca duplicată indică imperfecțiunea proceselor de afaceri.

Notația IDEF3, ca și notația ARIS eEPC, utilizează simboluri logice pentru a reflecta ramificarea procesului. O diagramă în notație IDEF3 vă permite să reprezentați întregul proces, urmărind succesiunea operațiilor și logica procesului.

Descrierea notației DFD

Notația DFD are scopul de a descrie fluxurile de informații din organizația care face obiectul anchetei. Obiectele notației DFD sunt prezentate în tabel. 4 . Prezența obiectelor „depozit de date” și a săgeților bidirecționale vă permite să descrieți cel mai eficient fluxul de documente și cerințele pentru sistemul informațional.

Unul dintre cele mai importante aspecte ale descrierii modelelor de procese de afaceri este reflecția asupra modelului acțiunilor de control, feedback-ul asupra controlului și managementului procedurii. În notația ARIS eEPC, controlul procedurii poate fi reflectat doar prin indicarea documentelor primite care guvernează execuția procedurii și succesiunea în timp a procedurilor (evenimente de declanșare). Spre deosebire de ARIS, în notația IDEF0 fiecare procedură trebuie să aibă cel puțin o acțiune de control (intrare de control - săgeată în sus). Dacă, la crearea unui model în eEPC, specificați doar succesiunea procedurilor, fără să vă faceți griji cu privire la reflectarea acțiunilor de control (de exemplu, documente și informații), modelele rezultate vor avea valoare scăzută în ceea ce privește analiza și utilizarea ulterioară. Din păcate, aceasta este eroarea cea mai frecventă în practică. Este creat un model de flux de lucru, care reflectă o secvență simplă de execuție a procedurilor și a documentelor de intrare/ieșire, în timp ce influențele de control (control) asupra funcțiilor nu sunt reflectate în model.

La compararea celor două sisteme, trebuie imediat remarcat faptul că ARIS folosește un DBMS obiect pentru a stoca modele și este creată o nouă bază de date pentru fiecare proiect. Pentru confortul utilizatorului, modelele (obiectele model) pot fi stocate în diferite grupuri, organizate în funcție de specificul proiectului. Este destul de firesc ca ARIS să ofere diverse funcții pentru administrarea bazei de date: control acces, consolidare etc. În BPwin, datele modelului sunt stocate într-un fișier, ceea ce simplifică foarte mult munca de creare a unui model. Pentru lucrul în grup pe proiecte mari, modelele BPwin sunt stocate în depozitul Model Mart (furnizat separat). Model Mart este un depozit de modele pentru BPwin și ERwin și folosește DBMS relațional Oracle, Informix, MS SQLServer, Sybase). Oferă administrare, inclusiv diferențierea drepturilor de acces la nivelul obiectului modelului, compararea versiunilor, fuzionarea modelelor etc.

Susținătorii ARIS citează adesea limitarea numărului de obiecte de pe diagramă drept unul dintre dezavantajele BPwin. Totuși, experiența proiectelor reale arată că pentru un proiect ale cărui rezultate pot fi efectiv utilizate (criteriul este vizibilitatea), numărul de obiecte din baza de date ARIS sau modelul BPwin este de 150-300. Aceasta înseamnă că, cu 8 obiecte pe o diagramă, numărul total de diagrame (fișe) din model va fi de 20-40. Bazele de date ARIS Toolset (cum ar fi BPwin) care conțin mai mult de 500 de obiecte sunt practic inutilizabile. Trebuie subliniat faptul că modelul este creat pentru a identifica și analiza problemele, adică este necesară o descriere detaliată a celor mai complexe, mai problematice domenii de activitate, și nu o descriere totală a tuturor proceselor. În mod ciudat, există o credință larg răspândită în rândul directorilor de companie că o descriere detaliată a proceselor în sine este valoroasă și poate rezolva multe probleme. Dar acest lucru este departe de adevăr. Înțelegerea a ceea ce trebuie descris și ce aspecte ale funcționării unui sistem real de reflectat determină succesul unui proiect de modelare a proceselor de afaceri.

ARIS oferă mult mai multe oportunități de lucru cu obiecte model individuale, dar tocmai din cauza numărului excesiv de setări, munca la crearea unui model trebuie reglementată de documentație complexă, cu mai multe aspecte - așa-numitele acorduri de modelare. Dezvoltarea acestor acorduri în sine este complexă, costisitoare și necesită timp considerabil (1-3 luni) și specialiști calificați. Dacă un proiect care utilizează ARIS începe fără dezvoltarea detaliată a unor astfel de acorduri, atunci probabilitatea de a crea modele de procese de afaceri care să nu răspundă la întrebările puse este de 80-90%. La rândul său, BPwin este ușor de utilizat și are reglementări destul de stricte la crearea diagramelor (standardul IDEF și recomandările pentru utilizarea acestuia, formularul IDEF pentru crearea unei diagrame, un număr limitat de câmpuri obligatorii, limitarea numărului de obiecte pe o diagramă, etc.). ARIS este cu siguranță un instrument „mai greu” în comparație cu BPwin, dar în cele din urmă acest lucru are ca rezultat dificultăți semnificative și costuri mari pentru funcționarea sa.

Concluzii. Recomandări pentru utilizarea sistemelor în funcție de sarcinile tipice

În tabel sunt prezentate diverse situații de utilizare a instrumentelor de modelare a proceselor de afaceri și evaluarea lor de către experți pe o scară de 5 puncte. 7.

Poziționarea sistemelor poate fi realizată în raport cu rezolvarea problemei modelării proceselor de afaceri (Fig. 13).

Astfel, pentru proiecte la scară mică (întreprinderi mici și mijlocii, 2-5 persoane într-un grup de consultanți) și de durată (2-3 luni), este rațional să se utilizeze BPwin. Pentru proiectele mari și/sau pe termen lung (de exemplu, precum implementarea unui sistem de îmbunătățire continuă a proceselor de afaceri, ISO, TQM), ARIS este mai potrivit. Trebuie remarcat faptul că sistemul ARIS Toolset este incomod pentru crearea modelelor de informații, iar proiectarea și configurarea bazelor de date nu este furnizată. În acest caz, munca pregătitoare pentru crearea documentației de reglementare poate dura 1-3 luni, dar acesta este un element necesar pentru munca ulterioară de succes.

August-Wilhelm Scheer. Procese de afaceri: concepte de bază, teorii, metode. Moscova: Enlightener, 1999.

ComputerPress 1"2002

Î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. 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 termenului 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. Tipul de relație este utilizat de 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 (funcție) Activitate 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 procesului la conducere

2.7.2. Notația ARIS eEPC - extensie a notației IDEF3

Notația ARIS eEPC (Extended Event Driven Process Chain) este un lanț extins de proces condus de evenimente. Notația a fost elaborată de specialiști de la IDS Scheer AG, Germania, în special de 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.

Capitolul 2 Alegerea unei metodologii pentru descrierea proceselor de afaceri 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.

Când construiți modele în ARIS eERS, trebuie să vă conformați urmând reguli:

1. Fiecare funcție trebuie declanșată de un eveniment și terminată
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 altele cerințe importante la formarea modelelor în ARIS. Ele pot fi studiate folosind material 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 succesiune 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 un simbol 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 de proces 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 arată procesul de afaceri de procesare a aplicației unui 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. Procese complexe cu logica ramificată, este incomod să se afișeze 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

Notația ARIS EPC, folosită pentru modelarea proceselor de afaceri în setul de instrumente ARIS, este o secvență de evenimente și funcții care reflectă logica efectuării acțiunilor interconectate care vizează obținerea unui anumit rezultat.

Modelul ARIS EPC este destinat să descrie algoritmul pentru executarea unui proces de afaceri sub forma unei secvențe de funcții bazate pe evenimente. Modelul ARIS EPC se concentrează pe secvența funcțiilor, iar pentru a descrie condițiile din modelul procesului de afaceri sunt folosite evenimente și reguli, care pot descrie algoritmi complecși pentru executarea unui proces de afaceri.

Funcțiile din modelul ARIS EPC sunt declanșate de evenimente, de exemplu, „Factura primită pentru aprobare” și se termină cu evenimente, de exemplu, „Factura este aprobată” sau „Factura nu este aprobată”. Dacă, ca urmare a executării unei funcții, există o singură opțiune pentru execuția ulterioară a procesului de afaceri, adică. Ca rezultat, este generat un singur eveniment, după care urmează următoarea funcție; evenimentul dintre aceste funcții poate să nu fie desenat.

Un model de proces de afaceri cu notație ARIS EPC începe și se termină în mod necesar cu unul sau mai multe evenimente sau interfețe cu alte modele de procese de afaceri. Pentru a reflecta interfețele, sunt folosite obiecte speciale „Interfață de proces” - tipul de obiect „Funcție”.

La crearea unui model ARIS EPC, pot apărea situații în care același document este un document de ieșire pentru o funcție și un document de intrare pentru următoarea. În aceste cazuri, pentru a îmbunătăți ergonomia modelului, este permisă utilizarea unei reprezentări a documentului cu o conexiune de intrare (din funcția în care este creat sau ajustat) și o conexiune de ieșire (la funcția în care este utilizat) .

Modelul EPC nu poate fi deconectat, de exemplu. plasarea pe model a unui obiect care nu este legat de celelalte este o eroare.

Locația documentelor în raport cu funcțiile este de obicei următoarea: în stânga sus sunt documentele primite, în stânga jos sunt documentele trimise, executanții sunt de obicei localizați în dreapta funcției.

Următoarele informații sunt indicate pe modelul ARIS EPC:

• funcții îndeplinite
• resurse de informații ale funcțiilor (documente de intrare/ieșire)
• evenimente
• interfețe de proces
• operatori logici
• performeri (poziții, roluri de afaceri)
• Sisteme de informare

Reguli de denumire a evenimentelor în ARIS EPC

Numele evenimentului trebuie să conțină un substantiv și o descriere verbală a schimbării de stat. Exemplu: „Tranzacție finalizată”.

Reguli de denumire a funcțiilor în ARIS EPC

Pentru a denumi o funcție, trebuie să folosiți numele ei real. Numele trebuie să fie format din două părți - un substantiv verbal care descrie funcția îndeplinită și un substantiv care indică obiectul asupra căruia este îndeplinit. Numele funcției constă din numele scurt al obiectului care începe cu o literă majusculă, de exemplu, „Căutați contactele clienților”.

Reguli pentru denumirea rolurilor/posturilor în ARIS EPC

Denumirea rolului de afaceri (Tipul de persoană) trebuie să corespundă esenței responsabilităților atribuite interpretului. De regulă, titlul conține sintagma „Responsabil pentru...”. Titlurile postului (Poziția) sunt scrise în conformitate cu tabelul de personal.

Reguli de denumire a documentelor

Obiectul corespunde unui document (Transport de informații) (în hârtie și/sau în format electronic). Pentru a denumi documentele (indiferent de simbolul folosit), trebuie să folosiți numele lor real.

Reguli pentru denumirea sistemelor informatice în ARIS EPC

Pentru a denumi sistemele informaționale (Tipul de sistem de aplicație), ar trebui să utilizați numele stabilite ale acestora.

Regulile de denumire a interfeței de proces

Interfața Process arată o legătură către un proces adiacent. Numele interfeței de proces corespunde numelui modelului care descrie partea adiacentă a procesului de afaceri. Interfața poate fi utilizată pentru a face referire la modele de procese de afaceri care nu fac parte din procesul de afaceri care este descris.

chavalah 13 iunie 2012 la 14:19

Utilizarea notației eEPC pentru a descrie grafic procesele de afaceri

• GTD

Fiecare lucru este o formă de manifestare a diversităţii infinite.
Kozma Prutkov

Introducere în notația eEPC

În prezent sunt multe diverse principii reprezentare grafică procese de afaceri numite notații. De ce sunt atât de mulți dintre ei? Această întrebare a fost pusă de toți cei care se confruntă cu nevoia de a descrie procesele de afaceri de zeci de ani. Să ne uităm la motive. Sunt trei dintre ele (după părerea mea):

• Diverse sarcini. Nu toate notațiile sunt la fel de convenabile pentru rezolvare diverse sarcini. De exemplu, o notație poate fi convenabilă pentru un proces de afaceri de nivel superior, dar deloc convenabilă pentru descrierea unui flux de lucru.
• Există diferiți dezvoltatori de astfel de notații. În momente diferite, diferiți dezvoltatori au încercat să vină cu noi principii pentru descrierea circuitelor. Au făcut acest lucru din bune intenții, când în practică au întâlnit o situație în care notația pe care o foloseau nu putea reflecta subtilitățile necesare (sau nu era clară). Uneori, în procesul evoluției, astfel de notații au devenit, parcă, paralele, adică. arată diferit, dar rezolvă aceleași probleme.
• Dorința de a ieși în evidență. Acesta este momentul în care, din motive necunoscute, apare brusc o nouă notație, care nu are nimic remarcabil în sine, dar din anumite motive este promovată de creatorul ei drept cel mai perfect know-how. Acest lucru se întâmplă și astăzi.

Scopul acestui articol nu este să ia în considerare toate tipurile de notații (nu le numesc în mod deliberat numele), ci să mă oprim asupra descriere detaliata notația pe care am ales-o pentru proiectele mele în timpul unei lungi căutări a celei mai optime opțiuni.
Dacă cineva este interesat să afle ce alte notații există și pentru ce sunt folosite, plănuiesc să fac acest lucru într-un alt articol, care se va numi „Hai să vorbim despre notații”, dar aceasta este încă în planuri.
Este timpul să începem povestea noastră despre notația eEPC foarte interesantă, simplă și practică (tradus: descriere extinsă a lanțului de procese de evenimente). Traducerea sa literală dezvăluie, de asemenea, scopul său principal: o descriere a lanțului de procese de afaceri. Principala „trăsătură” a notației este principiul „evenimentului”, pe care îl vom analiza în detaliu.
Ce avantaje are? notația eEPC:

1. În primul rând, aceasta nu este tocmai o notație în formă pură. Acestea. dacă în unele notații există un set strict de elemente și reguli pentru utilizarea lor (altfel totul va deveni confuz), atunci principiul eEPC vă permite să adăugați propriile elemente. Cum se asigură acest lucru? Desigur, există un anumit „nucleu” în jurul căruia este construit totul, adică. un set de reguli clare prin care se construiește o diagramă și după care este apoi citită. În plus, puteți adăuga propriul element, puteți include regulile de utilizare a acestuia în propriul standard corporativ (pentru a exclude activitățile de amatori care pot încurca diagrama și pot complica lizibilitatea acesteia) și atât! Aceasta este foarte punct important. În plus, puteți seta orice alte restricții și reguli în standardul dvs. corporativ.
2. eEPC conține elemente logice. Acest lucru vă permite să construiți diagrame cu condiții, care sunt necesare pentru a descrie activitatea („dacă contractul este convenit, atunci ...., în caz contrar ...”)
3. Simplitatea elementelor vă permite să desenați diagrame atât în ​​software, cât și în orice alt mod, chiar și pe hârtie, nu vă veți încurca.
4. eEPC este atât de ușor de învățat și de înțeles încât poate fi folosit în activități reale și nu doar pentru colectarea prafului în dulap. Va dura aproximativ 2 ore pentru a preda regulile (dacă studentul dorește).

Bineînțeles, ca orice pe lumea asta, are și dezavantajele sale. Dar utilizare rațională le reduce la minimum. Principalul dezavantaj, în opinia mea, este faptul că, dacă folosim instrumente simple (adică programe pentru desenarea diagramelor, și nu pentru modelarea proceselor de afaceri), atunci nu avem o singură bază de date de obiecte. În plus, este dificil să controlați intrările și ieșirile (trebuie să le controlați, adică să veniți cu o modalitate de astfel de control, dacă este necesar). Dar, pe de altă parte, utilizarea instrumentelor complexe de modelare a proceselor de afaceri costă sume foarte impresionante, iar un proiect care le folosește se măsoară în milioane. Și astfel avem un instrument foarte economic și ușor de înțeles. Pentru a fi mai precis, acest dezavantaj se referă în mod specific la metoda de descriere pe care o iau în considerare, i.e. folosind MS Visio sau software similar. Dacă utilizați sisteme specializate pentru descrierea proceselor de afaceri care suportă baze de date cu obiecte, atunci acest dezavantaj poate fi evitat. Ei bine, este timpul să începem...

Principalul „nucleu” al notației eEPC

După cum am menționat deja, traducerea literală a acronimului eEPC conține conceptul de evenimente. Acesta este un punct foarte important pe care se bazează întregul principiu al construirii circuitului. Deci sunt două concept cheie: „Eveniment” și „Funcție”. Când cineva încearcă pentru prima dată să-și deseneze procesul sub forma unei diagrame eEPC, apare adesea întrebarea care este diferența dintre un eveniment și o funcție? Trebuie să înțelegeți clar acest lucru, altfel veți obține un rezultat imprevizibil. Deci: un eveniment este un fapt care se întâmplă ceva și nu are durată în timp, sau acest timp tinde spre zero (sau nu contează). Mai mult, un eveniment determină întotdeauna necesitatea executării unei funcții, iar execuția unei funcții se termină întotdeauna cu un eveniment.Să explic cu un exemplu. Telefonul suna. Managerul a ridicat telefonul pentru o conversație telefonică. În acest caz, „Telefonul sună” este un eveniment. Convorbirea telefonică este o funcție. Conversația sa încheiat (închis) – un alt eveniment. Astfel, se observă un lanț de evenimente: Apel - conversație - sfârșit de apel. Iar terminarea apelului va necesita probabil efectuarea unei noi funcții: înregistrarea rezultatului apelului etc.
Să încercăm să-l desenăm. În primul rând, trebuie să vă dați seama cum sunt afișate elementele Eveniment și Funcție.

Aceste două elemente simple formează baza regulilor de descriere a proceselor de afaceri în notația eEPC. Cred că ar trebui să spun câteva cuvinte despre culorile folosite. Dacă ați întâlnit descrieri ale proceselor în alte notații, de regulă, acestea erau alb-negru. Și acest lucru este corect, nu ar trebui să existe o dependență evidentă a conținutului de culoare, deoarece diagrama poate fi desenată cu un creion pe hârtie, tipărită pe o imprimantă alb-negru etc. În acest caz (în notația eEPC), s-a dezvoltat istoric că elementele au anumite culori. Ca să nu spun că acest lucru este necesar, dar obiceiul este dezvoltat, iar percepția în formă electronică este mai bună - puteți vedea imediat ce este. Aceste culori pot fi considerate o recomandare. De ce sunt așa? Nu sunt sigur exact, dar mi se pare că, deoarece compania ARIS, atunci când a făcut suport pentru notația eEPC în produsul lor, le-a dat aceste culori, ei „au prins rădăcini”. Apropo, uneori această notație este numită și „ARIS”, „ARIS EPC”, ceea ce nu este în întregime corect, deoarece ARIS nu a inventat această notație, ci a susținut-o în programul său de modelare a proceselor de afaceri. În general, recomand folosirea culorilor. Principalul lucru este că forma elementelor în sine nu ar trebui să fie aceeași (adică să difere doar prin culoare), deoarece în alb și negru acest lucru poate provoca confuzie. Există și alte reguli care fac posibilă ca diagrama eEPC să fie „armonioasă”; vom vorbi despre ele.
Deci, există un eveniment, există o funcție. Cum sunt ele conectate?
Noi vedem asta eveniment1 a dus la necesitatea îndeplinirii unei anumite funcţii care s-a încheiat eveniment2. Dacă, de exemplu, cu un apel telefonic, ar fi așa:

Legătura dintre eveniment și funcție este de obicei afișată de sus în jos pe o singură linie sau de la stânga la dreapta. Direcția lanțului este indicată prin linii de legătură cu săgeți.

Pentru a face diagrama mai vizuală, notația oferă mai multe elemente standard:

• Denumirea funcției(executor testamentar). Cel care îndeplinește această funcție
• informație. Orice informație utilizată pentru a îndeplini o altă funcție decât informațiile documentare. De exemplu, un apel telefonic, instrucțiuni pentru efectuarea unei operații etc.
• Document. Elementul „Document” este destinat să afișeze medii de informare (hârtie sau electronice). Acestea. prezentarea informaţiilor într-o anumită structură.
• Program (aplicație). Software-ul folosit pentru a îndeplini funcția.

Toate celelalte elemente sunt auxiliare și practic nu sunt reglementate de cerințele eEPC în sine. Cu toate acestea, nu există nicio barieră în a adăuga propriile elemente. Principalul lucru este să înregistrați acest lucru în standard intern, astfel încât să existe o înțelegere comună a modului în care arată și de ce sunt folosite. O astfel de extensie nu încalcă cerințele dacă conexiunea eveniment-funcție-eveniment nu este încălcată și are scopul doar de a îmbunătăți percepția informațiilor sau de a adapta regulile de descriere la orice specific al industriei. Am adăugat propriul meu set de elemente, pe care le voi discuta mai jos.
De asemenea, este necesar să se afle cum trebuie amplasate elementele luate în considerare. Toate aceste elemente trebuie să fie legate de funcție într-un fel sau altul. Acest regula generala: Niciun alt element decât o funcție nu este asociat cu evenimentul. Acestea. toate aceste elemente trebuie conectate prin săgeți la funcție. În ceea ce privește săgețile și direcțiile acestora: se acceptă în general că, dacă nu există o direcție pentru transmiterea informațiilor, atunci în loc de săgeată, este afișată doar o linie. Dacă informația intră (intră în intrare), atunci direcția săgeții este de la obiect la funcție; dacă iese, atunci invers.
Încă câteva cuvinte despre locația acestor elemente pe diagramă și ne putem redesena diagrama, clarificând execuția funcției de procesare a apelurilor. Nu există cerințe stricte pentru aranjarea elementelor, dar este obișnuit să le afișați în mod egal pe toate diagramele (pentru uniformitatea și armonia diagramei). Pentru a unifica aspectul extern al diagramelor grafice ale proceselor de afaceri, astfel de reguli trebuie să fie consacrate într-un standard intern și respectate. Puțin mai târziu voi da câteva recomandări în acest sens.
Acum să ne redesenăm diagrama:

Vedem că operatorul procesează un apel primit, acționând în conformitate cu regulile de procesare a apelurilor primite și folosește pentru aceasta programul CRM. Nu sunt folosite nici documentele de intrare, nici de ieșire.
După cum am menționat deja, unul dintre punctele forte notațiile sunt elemente de logică. În același timp, acesta este unul dintre cele mai dificile momente de înțeles. Prin urmare, voi da mai întâi un exemplu, apoi ne vom ocupa separat de elementele logicii.
Să fie așa în exemplul nostru: dacă clientul este interesat, lucrează în continuare cu el de către managerul de vânzări și el stabilește Ofertă comercială, care este trimis prin poștă utilizând clientul de e-mail MS Outlook. Dacă nu există interes, atunci procesarea apelului este finalizată. ÎN viata reala Ar fi bine să folosim regulile pentru a încheia un apel, dar ăsta sunt doar eu, apropo, să simplificăm deocamdată. Iată ce se întâmplă:

Elemente logice în diagramele de notație eEPC

Elementele logicii sunt simple, dar există caracteristici și reguli specifice pentru a se asigura că diagrama este logică și interpretată fără ambiguitate. Cea mai importantă regulă pe care trebuie să o respectați 100%: deciziile logice pot fi luate numai la îndeplinirea funcţiilor ii. Acestea. după un eveniment nu mai poate exista ramificare. De ce? Pentru că în acest caz contrazice însăși conceptul de eveniment – ​​este simplu și instantaneu, fără timp de execuție. De exemplu, dacă sună telefonul și o persoană stă gândindu-se dacă să ridice sau nu telefonul, teoretic aceasta va fi deja o funcție în care va lua o decizie. Dar în practică, inclusiv bunul simț, el încalcă regulile de procesare a apelurilor, pentru că... el este plătit cu un salariu pentru a procesa aceste apeluri și nu este nimic de discutat aici (în general, așa cum se arată în diagramă).
În total, există 3 elemente diferite de logică:

• ȘI. Când două sau mai multe evenimente au loc în același timp;
• SAU. Când se pot întâmpla unul sau mai multe evenimente, dar trebuie să se întâmple măcar un lucru;
• EXCLUSIV SAU. Ori unul, ori altul. Acestea. două opțiuni sunt imposibile în același timp.

Iată cum arată unele:

După cum puteți vedea, există două opțiuni pentru reprezentarea grafică a elementelor logice. Nu sunt diferite, complet alternative. Le-am adus pe amândouă pentru că... în practică, ambele opțiuni pot fi văzute în diverse surse. Pe care să-l folosiți depinde de dvs. Imi place mai mult primul.
Acum trebuie să înțelegeți utilizarea elementelor logice. Mai întâi, să ne uităm la opțiunile pe care le întâlnim, apoi trecem la un exemplu. Să ne uităm la fiecare element separat.
Element logic „ȘI”.

Când o funcție necesită mai multe evenimente să apară simultan:

Exemplu: Dacă perioada de raportare este închisă (evenimentul 1) și a sosit termenul limită pentru transmiterea unui raport către manager (evenimentul 2), angajatul întocmește un raport lunar.

Elemente de conectare dacă, la executarea unei funcții, au loc mai multe evenimente:

Exemplu: Am terminat o lucrare cu clientul. Două evenimente au fost înregistrate în același timp: s-au împăcat înțelegeri reciproce (evenimentul 1), actul a fost semnat (evenimentul 2).

În practică, această aplicație nu apare des. De regulă, dacă mai multe acțiuni sunt combinate într-o singură funcție.

Elemente de legătură, dacă, la îndeplinirea mai multor funcții, apare evenimentul:

Exemplu: Depozitarul a ridicat comanda (funcția 1), operatorul a emis documentele (funcția 2), mărfurile sunt gata de expediere (eveniment).

Elemente de conectare dacă apariția unui eveniment duce la executarea mai multor funcții:

Exemplu: A sosit un transport de mărfuri (eveniment). Totodată, încep și expedierea mărfurilor comandate anterior de clienți și plasarea mărfurilor rămase în depozit.

Element logic „SAU”.
Elemente de conectare dacă unul dintre evenimente poate determina executarea funcției:

Exemplu: O cerere a fost primită prin telefon (evenimentul 1) sau o cerere a fost primită de e-mail(evenimentul 2) va duce la necesitatea procesării acestuia.
Elemente de conectare dacă o funcție poate genera cel puțin un eveniment:

Exemplu: Intocmirea si expedierea facturii de marfa pentru expediere catre client. Factura poate fi trimisă prin poștă (evenimentul 1), prin fax (evenimentul 2).

Conectarea elementelor la executarea mai multor funcții va declanșa un eveniment:

Exemplu: Este furnizat un serviciu (funcția 1) sau se vinde un produs (funcția 2) și ia naștere o datorie de la client (evenimentul 1).

Element logic „SAU EXCLUSIV”.

O conexiune de elemente atunci când unul și numai unul dintre evenimente este necesar pentru a îndeplini o funcție:

Exemplu: Clientul a venit personal la magazin (evenimentul 1) sau a făcut o comandă prin Internet (evenimentul 2). Este necesar să expediați mărfurile (funcția 1).

Elemente de conectare dacă, în urma executării funcției, are loc cel mult unul dintre următoarele evenimente:

Exemplu: Decizia este fie luată, fie nu.

Legarea elementelor, dacă cuevenimentul va avea loc după ce una și numai una dintre funcții a fost îndeplinită.

Exemplu: Marfa a fost livrată (eveniment 1) fie prin transport propriu (Funcția 1), fie companie de transport(funcția 2)

Aplicarea corectă a elementelor logice necesită o anumită practică. Dar nu este greu. Trebuie remarcat faptul că nu toate combinațiile luate în considerare sunt utilizate pe scară largă în practică (și în general acest lucru este determinat de modul de gândire al analistului).

Încercați să aplicați elementele de logică în practică. Dacă aveți dificultăți, scrieți-mi, voi încerca să vă ajut.

Extinderea notației cu propriile elemente

După cum am spus deja, eEPC nu este tocmai o notație, ci mai degrabă reguli de descriere. Și aceste reguli nu interzic adăugarea propriilor elemente la diagramă. Principalul lucru este că aceste elemente sunt de înțeles și că există un document în care sunt înregistrate astfel de extinderi ale elementelor. De exemplu, folosesc următoarele elemente suplimentare, care au apărut treptat în procesul de descriere a proceselor reale pentru diverse sarcini, de la descriere simplă pentru stabilirea sarcinilor pentru automatizare.

Fișier de date. Folosit dacă o operație are ca rezultat crearea unui fișier de date sau un fișier este utilizat pentru a efectua o operație.
Bază de date. Folosit pentru a descrie fluxurile de informații între sisteme automatizate.
Indexul cardului. Folosit pentru a afișa un fișier de hârtie sau o arhivă.
Fluxul de materiale. Folosit pentru a indica fluxurile de materiale de intrare și de ieșire, precum și resursele consumate în timpul execuției unui proces. Fluxul de materiale este afișat în stânga documentelor însoțitoare.
Cluster de informații. Folosit pentru a desemna informații structurate (reprezentare entități). Diagrama poate fi utilizată pentru a indica documentele generate programatic atunci când se utilizează aplicații utilizator. În acest caz, elementul Cluster este situat în stânga documentului corespunzător. Acestea. indică faptul că utilizatorul nu numai că a creat un document de hârtie, dar a creat și o copie a acestuia în program.

Acorduri privind regulile de plasare a figurilor pe o diagramă

Notația eEPC în sine nu impune cerințe stricte privind aranjarea elementelor unul față de celălalt, deși este obișnuit să se deseneze o diagramă de sus în jos sau de la stânga la dreapta. Dacă acest lucru nu este unificat în cazul muncii mai multor specialiști, atunci poate rezulta un fel de „vinaigretă”. Pentru a evita acest lucru, se recomandă să dezvoltați și să aprobați propriile reguli de aranjare a elementelor.

• Secvența evenimentelor și funcțiilor este aranjată de sus în jos (mai bine) sau de la stânga la dreapta (dacă nu este suficient spațiu);
• Elementele care indică executanți sunt situate în dreapta funcțiilor;
• Documentele primite sunt în partea stângă sus a funcțiilor; direcția săgeții de la documente la funcții;
• Documente de ieșire în partea stângă jos a funcțiilor; direcția săgeții de la funcție la documente;
• Elementul Informații este situat în partea dreaptă jos a funcției. Dacă spațiul nu este suficient, este permisă o locație arbitrară, cât mai aproape de funcție;
• Elementul Aplicație este situat în partea dreaptă sus a funcțiilor. (dacă pentru aceasta sunt folosite depozite de fișiere care nu sunt rapoarte, acestea sunt afișate în mod similar). Link fără săgeată.
• Elementele „Bază de date” și „Index card” sunt aranjate aleatoriu;
• Elementul „Flux de material” este situat în stânga documentelor însoțitoare și este legat de document printr-o linie fără săgeată;
• Elementul „Cluster”, atunci când este utilizat în combinație cu cifra „Document” pentru a desemna un document în formă electronică, este situat în partea stângă a documentului corespunzător.

De exemplu: Grefierul de salarizare calculează salariile pe baza documentelor „Ordinului Brigăzii” care i-au fost furnizate. În acest sens, el se ghidează după documentul „Regulamente privind salariile", calculul se efectuează în programul "1C: ZiK". Rezultatul calculului este documentul „Declarație”.

Identificarea elementelor dintr-o diagramă

După cum știți, o abordare competentă pentru descrierea proceselor de afaceri implică identificarea acestora, adică când fiecare proces are propriul nume de cod. În consecință, funcțiile individuale din cadrul unui proces au, de asemenea, propriile nume și identificatori.
Figurile „Document” și „Funcție” trebuie identificate pe diagramă.
Documentul se identifică prin indicarea în colțul din stânga sus a codului raportului sau documentului conform registrului. Documentele primite de la furnizorii de bunuri și servicii (incoming) sunt identificate numai prin nume.
O funcție este identificată prin specificarea numărului secvenței funcției pentru un anumit grup de procese. Acestea. Numărul funcției începe întotdeauna cu codul grupului de procese. Problemele de identificare a grupurilor de procese depășesc domeniul de aplicare al acestui articol; le vom analiza separat. Mai mult, ar trebui să învățați să identificați procesele înainte de a începe să le descrieți, altfel poate exista dorința de a descrie toate activitățile companiei pe o singură diagramă, așa cum se încearcă uneori.
Prin urmare, acum voi arăta doar cu un exemplu cum poate fi reprezentat acest lucru în diagramă. Să revenim la exemplul de procesare a apelurilor. Să presupunem că am atribuit codul „04” departamentului de vânzări, iar codul „VK” procesului de procesare a contactelor primite. Apoi circuitul va accepta următoarea vedere(identificarea este evidențiată cu roșu pentru claritate). Codul documentului indică numărul de serie al documentului în registrul general de documente (vom lua în considerare și acest lucru separat când vom ajunge la examinarea sistemului de flux de documente).

Afişa părere

Atunci când se construiesc modele, este adesea nevoia de a efectua un proces ciclic în funcție de o anumită condiție sau necesitatea de a afișa activitățile factorilor de decizie. În acest caz vorbim de feedback.

Pentru a afișa feedback-ul de control, este utilizat principiul „incluziunii directe” în proces functie suplimentara control cu ​​ramificare ulterioară (folosind elementul logic „SAU exclusiv”). De exemplu:

Descrierea textului proceselor

Oricât am încerca să afișam un proces de afaceri pe o diagramă, nu vom reuși să obținem detalii complete, altfel ne putem bloca în lanțuri nesfârșite de elemente și condiții. Pentru a evita acest lucru, precum și pentru a adăuga informații la descrierea procesului care nu pot fi afișate grafic, descrierea este completată cu însoțire de text. În acest scop, sunt dezvoltate diverse șabloane de text, care sunt completate în timpul procesului de descriere. Formele unor astfel de șabloane pot fi diferite și includ secțiuni separate care descriu intrările și ieșirile, resursele consumate, utilizate software etc.
În cel mai simplu caz, un șablon de descriere a procesului de afaceri ar putea arăta astfel:

Procesul de afaceri:	Procesarea unui contact primit	04.VK
Funcții de proces:
Nume	Descriere	Numărul de pe diagramă
Procesarea unui apel primit	Când sosește un apel de intrare, operatorul procesează apelul în conformitate cu regulile de procesare a apelurilor primite. Dezvăluie interesul clienților și oferă informații despre servicii	04.VK.01
Formarea unei oferte comerciale	In cazul in care clientul este interesat, operatorul transfera contactul managerului de vanzari. Managerul de vanzari pregateste o propunere comerciala si o trimite clientului prin email	04.VK.02
Indicatori de proces:
Nume	Metoda de evaluare/măsurare
Numărul de defecțiuni	Statisticile bazei de date

Dincolo de scopul acestui articol sunt subiecte atât de importante precum colectarea de informații, identificarea proceselor de afaceri, descompunerea și identificarea indicatorilor. Cu siguranță vom studia aceste probleme în numerele viitoare.

Notația ARIS eEPC reprezintă următorul - lanțul de proces condus de evenimente extins - o notație extinsă pentru descrierea lanțului unui proces condus de evenimente. Notația a fost dezvoltată de specialiști de la IDS Scheer AG (Germania), în special de profesorul Scheer (vezi)