Descrierea notației ARIS eEPC. Modelarea proceselor de afaceri folosind ARIS (express și cloud)

notarea modelului de afaceri

Notație ARIS eEPC

Notația ARIS eEPC înseamnă lanțul de proces condus de evenimente extins - notație extinsă pentru a descrie lanțul unui proces condus de evenimente. Notația a fost elaborată de specialiști de la IDS Scheer AG (Germania), în special de profesorul Scheer. Masa 1 prezintă principalele obiecte utilizate în cadrul notației.

Tabelul 1. Obiecte de notație eEPC

Nume	Descriere	Reprezentare grafică
	Obiectul „Funcție” este folosit pentru a descrie funcțiile (proceduri, lucrări) îndeplinite de departamentele/angajații întreprinderii
	Obiectul „Eveniment” este folosit pentru a descrie stările reale ale sistemului care afectează și controlează performanța funcțiilor
Unitate organizationala	Un obiect care reflectă diferitele unități organizaționale ale întreprinderii (de exemplu, management sau departament)
Document	Un obiect care reflectă medii reale, cum ar fi un document de hârtie
Sistem de aplicare	Obiectul reflectă un sistem de aplicație real utilizat în cadrul tehnologiei de îndeplinire a unei funcții
Cluster de informații	Un obiect caracterizează datele ca un set de entități și relații dintre ele. Folosit pentru a crea modele de date
Legătură săgeată între obiecte	Un obiect descrie tipul de relație dintre alte obiecte, de exemplu, activarea execuției unei funcții de către un eveniment
„ȘI” logic
„SAU” logic	Un operator logic care definește relațiile dintre evenimente și funcții din cadrul unui proces. Vă permite să descrieți ramificarea unui proces
„SAU” exclusiv logic	Un operator logic care definește relațiile dintre evenimente și funcții din cadrul unui proces. Vă permite să descrieți ramificarea unui proces

Pe lângă cele indicate în tabel. 1 dintre obiectele principale, multe alte obiecte pot fi folosite la construirea unei diagrame eEPC. Utilizarea unui număr mare de obiecte diferite conectate prin diferite tipuri de legături mărește semnificativ dimensiunea modelului și îngreunează citirea. Pentru a înțelege semnificația notației eEPC, este suficient să luăm în considerare principalele tipuri de obiecte și legături utilizate. În fig. 1 prezintă cel mai simplu model eEPC care descrie un fragment al unui proces de afaceri al întreprinderii.

Orez. 1.

În fig. 1 arată că legăturile dintre obiecte au un anumit sens ș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 un simbol logic „ȘI”, „începând” execuția Funcțiilor 2 și 3. Notația eEPC se bazează pe anumite reguli de descriere semantică:

1.Fiecare funcție trebuie să fie declanșată de un eveniment și trebuie să se încheie cu un eveniment;
2. Fiecare funcție nu poate conține mai mult de o săgeată, „începând” execuția funcției și din cel mult o săgeată care descrie finalizarea funcției.

Pe lângă aceste reguli, există și altele reguli importante formând modele în ARIS. Aceste reguli pot fi studiate folosind materialul de instruire „Metode ARIS”, care este instalat pe computer simultan cu versiunea demo a produsului.

În fig. 2 prezintă utilizarea diferitelor obiecte ARIS la crearea unui model de proces de afaceri.

Orez. 2.

Fiecare obiect din setul de instrumente ARIS care acceptă metoda de descriere a procesului de afaceri ARIS are un set specific de atribute. Utilizatorului i se cere să folosească atribute standard pentru a descrie obiecte sau număr limitat atribute personalizate.

Smochin. 1 arată că un proces de afaceri în notație eEPC este o secvență de proceduri aranjate în ordinea executării lor. Trebuie remarcat faptul că durata reală a procedurilor din eEPC 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 va fi desemnat să execute simultan două sarcini. Simbolurile logice utilizate în construirea modelului vă permit să reflectați ramificarea și îmbinarea unui proces de afaceri. Pentru a obține informații despre durata reală a proceselor, trebuie să utilizați alte instrumente de descriere, de exemplu diagramele Gantt în sistemul Microsoft Project.

Astfel, folosind notația eEPC ARIS, este posibil să se descrie un proces de afaceri ca un flux de lucru executat secvențial (proceduri, funcții). Exemple de modele generate folosind ARIS eEPC sunt prezentate în Fig. 3 și 4.

Orez. 3.

Orez. 4. Descrierea procesului de analiză și aprobare a cererii clientului

V. Repin, S. Maklakov

Analiza activităților întreprinderilor și reorganizarea proceselor de afaceri este o sarcină extrem de dificilă care necesită sprijin metodologic și instrumental. Recent, instrumentele CASE BPwin (Computer Associates) și ARIS Toolset (ARIS) au devenit din ce în ce mai populare în rândul analiștilor de afaceri. Acest articol oferă un scurt analiza comparativa aceste instrumente și recomandări pentru utilizarea lor.

Introducere. Sarcini tipice descrieri ale proceselor de afaceri

În stadiile incipiente ale proiectelor care vizează reorganizarea și implementarea proceselor de afaceri sisteme de informare, managerii și specialiștii au cel mai adesea următoarele întrebări:

ce rezultate în ceea ce privește îmbunătățirea performanței organizației pot fi obținute folosind tehnologii de descriere și reorganizare a proceselor de afaceri;
care software utilizarea în proiect („ARIS este mai bun decât BPwin?”, „ERwin este mai bun decât ARIS?” etc.);
cum se modelează procesele folosind produsul „X”;
cum să analizezi și să identifici problemele folosind produsul „X”;
ce metodologie să folosiți pentru a descrie procesele;
ce să facă în continuare cu modelele rezultate ale proceselor de afaceri.

Momentan activat piata ruseasca sunt prezentate un număr destul de mare de sisteme CASE, dintre care multe permit într-un mod sau altul să creeze descrieri (modele) proceselor de afaceri ale întreprinderilor. În același timp, există sisteme care se concentrează în primul rând pe crearea de modele de proces și sunt incomode sau deloc destinate creării de modele de date și reglarii unui DBMS. Î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:

obiectivele proiectului;
cerințe pentru informații care caracterizează procesele de afaceri și necesare analizei și luării deciziilor în cadrul unui anumit proiect;
capacitățile sistemelor CASE pentru descrierea proceselor ținând cont de cerințele clauzei 2;
caracteristicile sistemului informatic dezvoltat/implementat.

Nu are sens să vorbim despre avantajul 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ă. În articolul nostru, am încercat să comparăm cele mai populare notații (sisteme de notație adoptate în modelare) folosite pentru a descrie procesele de afaceri și două sisteme care suportă aceste notații. Se presupune că acest material va servi drept bază pentru o discuție dedicată problemelor utilizării eficiente a sistemelor CASE pentru descrierea și analiza proceselor de afaceri ale întreprinderilor.

Descrierea proceselor de afaceri este realizată în scopul analizei și reorganizării lor ulterioare. Scopul reorganizarii poate fi introducerea unui sistem informatic, reducerea costurilor de productie, imbunatatirea calitatii serviciului clientilor, crearea de instructiuni de munca si de lucru la implementarea standardelor ISO 9000 etc. Pentru fiecare astfel de sarcină, există anumiți parametri care determină setul de cunoștințe critice asupra procesului de afaceri. Cerințele pentru descrierea proceselor de afaceri pot varia de la sarcină la sarcină. V caz general modelul de proces de afaceri ar trebui să ofere răspunsuri la următoarele întrebări:

ce proceduri (funcții, lucru) trebuie efectuate pentru a obține un rezultat final dat;
în ce secvență sunt efectuate aceste proceduri;
ce mecanisme de control și management există în cadrul procesului de afaceri luat în considerare;
roluri și responsabilități - cine realizează procedurile de proces;
ce documente/informații de intrare folosește fiecare procedură a procesului;
ce documente/informații de ieșire generează procedura procesului;
ce resurse sunt necesare pentru a finaliza fiecare procedură din proces;
ce documentație/condiții guvernează procedura;
ce parametri caracterizează execuția procedurilor și procesul în ansamblu;
Există o secvență de procese care minimizează costurile (inclusiv costul, timpul etc.);
în ce măsură procesul este/va fi susținut de sistemul informațional.

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

Notație ARIS eEPC

Tabelul 1. Obiecte de notație eEPC

	Nume	Descriere
1	Funcţie	Obiectul „Funcție” este folosit pentru a descrie funcțiile (proceduri, lucrări) îndeplinite de departamentele/angajații întreprinderii
2	Eveniment	Obiectul „Eveniment” este folosit pentru a descrie stările reale ale sistemului care afectează și controlează performanța funcțiilor
3	Unitate organizationala	Un obiect care reflectă diferitele unități organizaționale ale întreprinderii (de exemplu, management sau departament)
4	Document	Un obiect care reflectă medii reale, cum ar fi un document de hârtie
5	Sistem de aplicare	Obiectul reflectă un sistem de aplicație real utilizat în cadrul tehnologiei de îndeplinire a unei funcții
6	Cluster de informații	Un obiect caracterizează datele ca un set de entități și relații dintre ele. Folosit pentru a crea modele de date
7	Legătură săgeată între obiecte	Un obiect descrie tipul de relație dintre alte obiecte, de exemplu, activarea execuției unei funcții de către un eveniment
8	„ȘI” logic
9	„SAU” logic	Un operator logic care definește relațiile dintre evenimente și funcții din cadrul unui proces. Vă permite să descrieți ramificarea unui proces
10	„SAU” exclusiv logic	Un operator logic care definește relațiile dintre evenimente și funcții din cadrul unui proces. Vă permite să descrieți ramificarea unui proces

Orez. 1. Un exemplu de model în notație eEPC

fiecare funcție trebuie să fie declanșată de un eveniment și trebuie să se încheie cu un eveniment;
fiecare funcție nu poate conține mai mult de o săgeată, „începând” execuția funcției și nu se stinge mai mult de o săgeată, care descrie finalizarea execuției funcției.

Pe lângă aceste reguli, există și alte reguli importante pentru generarea modelelor în ARIS. Aceste reguli pot fi studiate folosind tutorialul ARIS Methods, care este instalat pe computer împreună cu versiunea demo a produsului.

În fig. 2 prezintă utilizarea diferitelor obiecte ARIS la crearea unui model de proces de afaceri.

Orez. 2. Un exemplu de utilizare a obiectelor ARIS pentru a descrie procesele de afaceri

Fiecare obiect din setul de instrumente ARIS care acceptă metoda de descriere a procesului de afaceri ARIS are un set specific de atribute. Utilizatorului i se solicită să folosească atribute standard pentru a descrie obiecte sau un număr limitat de atribute personalizate.

Orez. 3. Descrierea procesului de deservire a clienților

Orez. 4. Descrierea procesului de analiza si aprobare a cererii clientului

Notarea organigramei ARIS

Notarea organigramei este una dintre principalele notații 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.

Orez. 5. Modelul structurii organizatorice a întreprinderii

Modelul este construit din obiectele „Unitate organizatorică”, „Poziție”, „Persoană internă”, etc. Tipurile de legături încorporate în notație permit reflectarea tipuri diferite relaţiile dintre obiectele structurii organizatorice. În diagrama prezentată în fig. Exemplul 5 „Întreprinderea” este gestionată de „Director” utilizând tipul de relație „este Manager organizație pentru”. Ierarhia subdiviziunilor este construită folosind legături de tipul „este compus din”. În plus, pot fi indicate posturi - „Poziție” și nume de familie angajați adevărați ocupându-le: „Persoană internă”, precum și tipul de legătură „ocupă”.

Pe lângă modelele 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 proceselor 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ă.

Notarea fluxului de informații ARIS

Notația Flux de informații este analogă cu notația DFD (a se vedea mai jos) și este utilizată pentru a construi diagrame ale fluxurilor de date sau documentelor între funcțiile proceselor de afaceri ale întreprinderii, așa cum se arată în Fig. 6.

Orez. 6. Fragment de diagramă de flux de informații ARIS

Simplitatea notării limitează sfera acesteia aplicații utile... Obiectele principale ale notației sunt „Funcția” (utilizată și pentru a construi modele de procese de afaceri) și „Fluxul de informații” - un flux de informații (Fig. 7).

Orez. 7. Notarea fluxului de informații ARIS

Atunci când se construiesc modele de procese de afaceri, mai întâi se poate construi un model eEPC, iar apoi, folosind funcțiile definite în proces, un model de fluxuri de informații.

Notații acceptate BPwin 4.0

Descrierea notațiilor IDEF0 și IDEF3

Notația IDEF0 a fost dezvoltată pe baza analizei structurale și a metodologiei de proiectare a SADT, aprobată ca standard american și este utilizată cu succes în multe proiecte legate de descrierea activităților întreprinderii. IDEF0 este extrem de răspândit și este, în special, un standard în organizațiile internaționale 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 notațiilor IDEF0 și IDEF3 sunt prezentate în tabel. 2 și 3.

Tabelul 2. Obiecte de notație eEPC

	Nume	Descriere
Notație IDEF0
1	Activitate	Obiectul este folosit pentru a descrie funcțiile (proceduri, lucrări) îndeplinite de departamentele/angajații întreprinderii. Este reprezentat ca un dreptunghi. Numele jobului ar trebui să reflecte procesul, acțiunea. Pentru ca lucrarea să fie modelată, trebuie să treacă ceva timp de la începutul până la sfârșitul lucrării și unele resurse trebuie cheltuite
2	Sageata de intrare	Săgeata este desenată ca parte a lucrării din stânga și descrie documentele primite, informațiile, resursele materiale necesare îndeplinirii funcției și modificate de lucrare
3	Săgeata de ieșire	Săgeata este trasă de ieșire din lucrare din dreapta și descrie rezultatele lucrării - documente de ieșire, informații, resurse materiale. În notația IDEF0, fiecare procedură trebuie să aibă cel puțin o săgeată de ieșire
4	Săgeata de control	Săgeata este desenată ca intrând în lucrare de sus și descrie o acțiune de control, de exemplu, o comandă, document normativ etc. În notația IDEF0, fiecare procedură trebuie să aibă cel puțin o săgeată de control
5	Mecanism săgeată	Săgeata este desenată ca parte a lucrării de jos și descrie așa-numitele mecanisme, adică resursele necesare pentru a finaliza procedura, dar nu își schimbă starea în cursul executării acesteia. Exemple: angajat, mașină etc.
6	săgeată de apel	Săgeata este trasă în jos din lucrare și este o legătură către un alt model de lucru. BPwin folosește această săgeată pentru a îmbina și a împărți modelele.

Tabelul 3. Obiecte cu notația IDEF3

	Nume	Descriere
Notație DFD
1	Muncă	Obiectul este folosit pentru a descrie funcțiile (proceduri, lucrări) îndeplinite de departamentele/angajații întreprinderii. Este reprezentat ca un dreptunghi. Numele jobului ar trebui să reflecte procesul, acțiunea
2	Link obiect (referent)	Obiect folosit 1) pentru a descrie legături către alte diagrame; 2) link-uri către alte lucrări; 3) referiri la obiecte; 4) pentru a clarifica logica săgeților de ramificare la intersecții; 5) diverse comentarii despre funcții și intersecții
3	Răscruce de drumuri	Operatori logici (5 tipuri - sincron și asincron „ȘI”, sincron și asincron „SAU”, excluzând „SAU”), care definesc relația dintre funcțiile din cadrul procesului. Vă permite să descrieți ramificarea unui proces
4	Săgeți	Trei tipuri de săgeți care vă permit să descrieți secvența de execuție a proceselor, precum și fluxul de informații și obiecte

Semantica construirii modelelor IDEF0 și IDEF3 presupune 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).

Orez. 8. Un exemplu de descriere a unui proces de afaceri în notație IDEF0

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 dominanței - 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 munca făcută prima. Săgețile leagă lucrările și există cinci tipuri de legături. O săgeată direcționată de la ieșirea unui job de nivel superior la intrarea sau controlul unui job de nivel inferior este o legătură directă; o săgeată direcționată de la ieșirea lucrării de nivel inferior la intrarea sau controlul lucrării de nivel superior este un feedback. Lipsa feedback-ului, munca fără ieșire sau management, munca duplicată indică procese de afaceri imperfecte.

În fig. 9 prezintă un exemplu de descriere a unui proces de afaceri în notația IDEF3 (corespunde procesului prezentat în Fig. 4).

Orez. 9. Un exemplu de descriere a unui proces de afaceri în notație IDEF3

În notația IDEF3, precum și în Notație ARIS eEPC, simbolurile logice sunt folosite pentru a reprezenta ramificarea procesului. O diagramă în notația IDEF3 vă permite să reprezentați întregul proces și să urmăriți 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 chestionată. Obiectele de notație DFD sunt afișate î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 lucru și cerințele pentru sistemul informațional.

Tabelul 4. Obiecte de notație DFD

	Nume	Descriere
Notație DFD
1	Activitate	Obiectul este folosit pentru a descrie funcțiile de prelucrare a informațiilor efectuate de departamentele/angajații întreprinderii
2	Obiect de referință	Obiectul de referință modelează un obiect care afectează sistemul din exterior
3	Magazin de date	Depozitul de date modelează locul unde sunt stocate informațiile - arhivă, bază de date, depozit etc.
4	Săgeată	Săgeata arată fluxul de informații, mișcarea documentelor deplasându-se împreună ca un singur lot. Săgeata poate fi bidirecțională, adică arată fluxul de informații de-a lungul unui traseu dat în ambele direcții

În fig. 10 prezintă un exemplu de diagramă DFD.

Orez. 10. Un exemplu de descriere a fluxului de documente în notație DFD

Pentru o descriere mai detaliată și proiectarea unui sistem informațional, împreună cu BPwin, poate fi folosit ERwin - un instrument CASE care vă permite să creați și să recreați un model de date. Legătura dintre modelul de proces BPwin și modelul de date ERwin se realizează prin importul dicționarului de entități și atribute din ERwin în BPwin. În modelul de proces, fiecărei săgeți i se poate atribui un set de entități și atribute, iar fiecărei lucrări i se poate atribui un set de reguli de utilizare a datelor. O astfel de interconectare a modelelor de proces și a datelor vă permite să descrieți în detaliu corespondența datelor și a consumatorilor acestora și, prin urmare, să eliminați erorile care pot apărea în timpul creării și implementării sistemelor informatice.

Organigrame în BPwin 4.0

Organigramele BPwin (Figura 11) sunt analoge cu organigramele ARI și, la fel ca ARIS, au scopul de a descrie ierarhia raportării în organizații.

Orez. 11. Exemplu de organigramă în BPwin

Pentru a crea o organigramă în BPwin, trebuie mai întâi să introduceți următoarele informații în dicționare.
Bitmaps, dacă pictogramele vor fi utilizate în organigrama.
Grupuri de roluri - se pot potrivi unitate structurală... În exemplul din fig. 10 prezintă grupurile de roluri „Management”, „Contabilitate” și „Magazinul nr. 1”.
Roluri – pot corespunde postului. În exemplul din fig. 10 arată rolurile „Gen. director "," Contabil "," Tehnolog ", etc.
Resurse - pot corespunde numelui de familie al unei anumite persoane.

Odată ce vocabularul a fost creat, BPwin folosește ghiduri pentru a crea o ierarhie de subordonare care include grupuri de roluri, roluri și resurse. În diagramele IDEF0, IDEF3 și DFD, fiecărui job i se poate atribui o resursă-executor din dicționarul de resurse. Rolurile și resursele pot fi, de asemenea, folosite pentru a crea o diagramă Swim Lane, o variație a diagramei IDEF3 care arată responsabilitățile angajaților din fabrică ca bare separate pentru operațiunile de proces.

Analiza comparativă a notațiilor ARIS și IDEF este dată în tabel. 5.

Tabelul 5. Obiectele notațiilor ARIS, IDEF0 și IDEF3

	Criterii de comparare
1	Principiul diagramei / logica procesului		Principiul dominantei (vezi standardul IDEF0)	Secvența de timp a procedurilor
2	Descrierea procedurii de proces	Obiect din diagramă	Obiect din diagramă	Obiect din diagramă
3	Document de intrare
4	Informații primite		Introducere săgeată, control săgeată	Un obiect separat este utilizat pentru descriere (Obiect de referință de tip Object sau arrow Object flux)
5	Document de ieșire	Un obiect separat este folosit pentru a descrie ("document")	Săgeata de ieșire	Un obiect separat este utilizat pentru descriere (Obiect de referință de tip Object sau arrow Object flux)
6	Informații de ieșire	Un obiect separat este folosit pentru a descrie ("cluster", "termen tehnic")	Săgeata de ieșire	Un obiect separat este utilizat pentru descriere (Obiect de referință de tip Object sau arrow Object flux)
7	Efectuarea procedurii	Un obiect separat este folosit pentru a descrie („poziție”, „unitate organizațională”)	Mecanism săgeată
8	Echipamentul folosit	Un obiect separat este folosit pentru a descrie	Mecanism săgeată	Nu (poate fi reflectat în model doar prin legarea obiectului de referință)
9	Managementul procedurii	Nu. Poate fi reflectat doar prin simboluri ale logicii și evenimentelor (secvența executării procedurilor) și/sau prin indicarea documentelor primite	Săgeata de control	Doar succesiunea temporală a executării procedurilor și logica procesului
10	Controlul procedurii	Nu. Poate fi reflectat prin specificarea documentelor primite	Săgeata de control	Nu (poate fi reflectat doar în model prin legarea obiectului de referință).
11	Feedback de management/control		Săgeata de control	Nu
12	Feedback de intrare	Nu. Poate fi reflectat doar prin simboluri ale logicii (secvența de execuție a procedurilor)	Sageata de intrare	Nu

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 unei proceduri poate fi reflectat doar prin specificarea documentelor de intrare care guvernează executarea procedurii și a succesiunii de execuție a procedurilor în timp (evenimente declanșante). 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ăgeata de sus). Dacă, la crearea unui model în eEPC, este indicată doar succesiunea procedurilor, fără a vă face griji cu privire la reflectarea acțiunilor de control (de exemplu, documente și informații), modelele rezultate vor avea valoare scăzută din punct de vedere al analizei și al utilizării ulterioare. Din păcate, aceasta este cea mai frecventă greșeală în practică. Este creat un model de flux de lucru (flux de lucru), care reflectă o succesiune 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.

În fig. 12 funcția 4 este o funcție de control și servește la verificarea rezultatelor muncii efectuate de funcțiile 2 și 3. Dar acest model nu raspunde la intrebari:

cum se efectuează efectul de control asupra funcțiilor 2 și 3? Se arată doar faptul că, în cursul procesului, este posibil să reveniți și să repetați execuția funcțiilor 2 și 3; informații despre acest feedback pot fi
dezvăluite doar ca descriere în atributele obiectelor model;
Ce documente (de exemplu, standarde), comenzi, condiții externe (de exemplu, umiditatea aerului din cameră) reglementează îndeplinirea funcțiilor?

Orez. 12. Dezavantaje ale descrierii procesului de afaceri în ARIS eEPC

Dacă încercați să reflectați toate condițiile și constrângerile care determină performanța funcțiilor, atunci va trebui să descrieți un număr mare de evenimente și informații primite (de exemplu, comenzi verbale de la manageri), iar modelul va deveni complex și greu de citit ( aceste neajunsuri sunt și inerente notației IDEF3). Dezavantajele indicate sunt absente în notația IDEF0. În același timp, modelele din IDEF0 nu prevăd utilizarea simbolurilor logice de proces.

Astfel, notația ARIS eEPC este o extensie a notației IDEF3 destul de simple. Pentru o descriere adecvată a procesului de management în notația eEPC, este necesar să se convină în prealabil asupra modului în care documentele (informațiile) care guvernează implementarea procedurilor procesului vor fi reflectate în model.

Funcționalitatea produselor ARIS și BPwin

Funcționalitatea sculelor Modelare ARIS Toolset și BPwin pot fi comparate corect doar cu o gamă specifică de sarcini. V acest studiu se are în vedere problema formării modelelor (descrierilor) proceselor de afaceri ale întreprinderii. Fiecare dintre sistemele luate în considerare are propriile sale avantaje și dezavantaje. În funcție de sarcinile de rezolvat, aceste avantaje pot atât să crească, cât și, dimpotrivă, să slăbească. Același lucru se poate spune și despre dezavantaje: lipsa unui sistem într-un proiect poate să nu fie așa în altul. De exemplu, lipsa unor acorduri clare privind modelarea acțiunilor de control în cadrul eEPC ARIS poate duce la crearea de modele care nu răspund la întrebările puse, în timp ce notația IDEF0 a sistemului BPwin vă permite să rezolvați această problemă. Pe de altă parte, o procedură cu o singură persoană poate fi descrisă mai adecvat cu eEPC ARIS decât cu IDEF0 sau IDEF3 BPwin. Comparația capacităților funcționale ale sistemelor este dată în tabel. 6.

Tabelul 6. Comparația dintre funcționalitatea ARIS Toolset 5.0 și BPwin 4.0

	Capacități / Mediu instrument	ARIS Toolset 5.0	BPwin 4.0
1	Standard acceptat	(parțial - DFD, ERM, UML)	IDEF0, IDEF3, DFD
2	Stocarea datelor modelului	Baza de date cu obiecte	Modelele sunt stocate în fișiere. Este posibil să creați un depozit bazat pe un SGBD relațional folosind ModelMart
3	Limita de dimensiune a bazei de date		Nu. Dimensiunea bazei de date este limitată de resursele de calcul
4	Oportunitate de lucru în grup	Există. Folosit de ARIS Server	Există. Folosit de ModelMart
5	Limitați numărul de obiecte din diagramă	Nu	Pentru DFD și IDEF3, nr. Pentru IDEF0 limitat la liniile directoare de notare
6	Capacitate de descompunere	Descompunere nelimitată. Este posibilă descompunerea în diferite tipuri de modele	Descompunere nelimitată. Este posibilă trecerea la o altă notație în timpul descompunerii
7	Format de prezentare model	Nereglementat	Formular standard (cadru) IDEF cu posibilitatea de a-l dezactiva
8	Ușurință în lucru la crearea modelelor	Panou de control complex, există alinierea obiectelor, există anulare	Panou de control simplu, fără aliniere a obiectelor, fără anulare
9	UDP - Proprietăți obiect definite de utilizator	Un număr mare, dar limitat de proprietăți; numărul de tipuri este limitat	Numărul de UDP nu este limitat. Numărul de tipuri este limitat (18)
10	Capacitatea de analiză a costurilor de proces	Există. Abilitatea de a utiliza ARIS ABC	ABC simplificat - Analiza costurilor în funcție de frecvența de utilizare într-un proces. Exportați în Easy ABC
11	Generarea de rapoarte	Creați rapoarte bazate pe macrocomenzi Visual Basic standard și personalizate	RPTwin, abilitatea de a personaliza vizual rapoartele, inclusiv calculul folosind formule folosind UDP
12	Complexitatea dezvoltării rapoartelor personalizate	Greu	Doar
13	Exportați rapoarte		Export implementat de rapoarte către MS Office, fișier text, RTF, HTML
14	Conectarea la modelul de date	Posibilitatea de a construi diagrame ERD, este necesar un software suplimentar pentru export	Legătura cu modelul de date ERwin a fost implementată. Fiecărei săgeți i se poate atribui un set de entități și atribute
15	Descrierea accesului la date	Nu	Drepturile de utilizare a datelor pot fi descrise pentru fiecare lucrare. Obiectul model de date poate fi creat direct în mediul BPwin
16	Descrierea documentației însoțitoare	Da, suport OLE	Cu comanda de tip UDP, fiecare săgeată este asociată cu orice document care poate fi încărcat folosind o aplicație Windows. Aplicația este lansată direct din mediul BPwin

Comparând cele două sisteme, trebuie remarcat imediat că un SGBD obiect este folosit pentru a stoca modele în ARIS, iar pentru fiecare proiect este creată o nouă bază de date. Pentru comoditatea utilizatorului, modelele (obiectele model) pot fi stocate in diverse grupuri, organizate in functie 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 utilizează DBMS relațional Oracle, Informix, MS SQLServer, Sybase). Acesta prevede administrarea, inclusiv diferențierea drepturilor de acces la nivelul obiectului model, compararea versiunilor, fuzionarea modelelor etc.

Susținătorii ARIS citează adesea limitarea numărului de obiecte din diagramă drept unul dintre dezavantajele BPwin. Totuși, experiența proiectelor reale arată că pentru un proiect ale cărui rezultate pot fi cu adevărat utilizate (criteriu - vizibilitate), numărul de obiecte din baza de date ARIS sau modelul BPwin este de 150-300. Aceasta înseamnă că, cu 8 obiecte într-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) cu peste 500 de obiecte sunt practic imposibil de utilizat. Trebuie subliniat faptul că modelul este creat pentru identificarea și analiza problemelor, 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ă descrierile detaliate ale procesului sunt valoroase în sine și pot 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 în același timp determină succesul unui proiect de modelare a proceselor de afaceri.

ARIS oferă mult mai multe oportunități de lucru cu obiecte individuale ale modelului, dar tocmai datorită numărului excesiv de setări, munca de creare a unui model ar trebui reglementată de documentație complexă, multidimensională - așa-numitele acorduri de modelare. Elaborarea acestor acorduri este în sine o sarcină complexă, costisitoare și consumatoare de timp (1-3 luni) și calificată. Dacă un proiect care utilizează ARIS începe fără elaborarea 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 se distinge prin ușurința sa de utilizare și reglementarea destul de strictă la crearea diagramelor (standard IDEF și recomandări pentru utilizarea sa, formular IDEF pentru crearea unei diagrame, un număr limitat de câmpuri obligatorii, limitarea numărului de obiecte într-o diagramă, etc.). ARIS este cu siguranță un instrument „mai greu” în comparație cu BPwin, dar în cele din urmă se dovedește a fi dificultăți semnificative și costuri mari pentru funcționarea acestuia.

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

Tabelul 7. Evaluarea aplicabilității ARIS Toolset 5.0 și BPwin 4.0 pentru sarcinile de modelare a proceselor de afaceri

Mediu Sarcină / Instrument	ARIS Toolset 5.0
Un proiect unic pentru a descrie procesele de afaceri, de exemplu: descrierea unui proces de afaceri din punct de vedere al controlului și managementului; descrierea funcționalității sistem nou management la nivel superior	3	5
Proiect pe termen lung (continuu) pentru a descrie activitățile companiei din diverse puncte de vedere (structură organizațională, structura documentelor, volum mare de baze de date de proces etc.)	5	4
Dezvoltarea unui sistem de automatizare: o descriere a funcționalității sistemului; crearea unui model de date logic; legarea modelului de proces la modelul de date; crearea unui model fizic de date; generarea codului aplicației.	3 3 - -	5 BPwin + ERwin + Paradigm Plus

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

Orez. 13. Evaluarea eficacității ARIS Toolset și BPwin

Astfel, este rațional să se utilizeze BPwin pentru a gestiona proiecte la scară mică (întreprinderi mici și mijlocii, 2-5 persoane într-un grup de consultanți) și de durată (2-3 luni). Pentru proiecte 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ă ARIS Toolset este incomod de creat modele informaţionale, iar proiectarea și configurarea bazelor de date nu sunt furnizate. În acest caz, lucrările pregătitoare pentru crearea documentației de reglementare pot dura 1-3 luni, dar acesta este un element necesar pentru munca ulterioară de succes.

Site-ul www.finexpert.ru
site web
Site-ul web www.idef.com
S.V. Maklakov. BPwin și ERwin. CASE-instrumente pentru dezvoltarea sistemelor informatice. Moscova: Dialogue-MEPhI, 2000, 256s.
DA. Mark, K. McGowan Metodologia de analiză structurală și proiectare. Moscova, 1993.
„Metode ARIS”. Fișier PDF, mai mult de 1000 de pagini. Furnizat cu o versiune demo a sistemului ARIS Toolset.
August-Wilhelm Scheer. Procese de afaceri: concepte de bază, teorii, metode. Moscova: Enlightener, 1999.

Fiecare lucru este o formă de manifestare a diversității nelimitate.
Kozma Prutkov

Introducere în notația eEPC

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

Sarcini diferite. Nu toate notațiile sunt la fel de convenabile pentru rezolvarea diferitelor probleme. De exemplu, notația poate fi convenabilă pentru un proces de afaceri de nivel superior și deloc convenabilă pentru descrierea unui flux de lucru.
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-o din bune intenții, când în practică s-au confruntat cu o situație în care notația pe care o foloseau nu putea reflecta subtilitățile necesare (sau nu în mod clar). Uneori, în procesul evoluției, astfel de notații au devenit, parcă, paralele, adică. arată diferit, dar rezolvă aceleași probleme.
Străduindu-ne să iasă în evidență. Acesta este momentul în care, dintr-un motiv necunoscut, 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 mai întâmplă.

Scopul acestui articol nu este să ia în considerare toate tipurile de notații (nu le numesc în mod deliberat), ci să mă opresc pe o descriere detaliată a notației pe care am ales-o pentru proiectele mele în procesul unei lungi căutări a celei mai optime opțiuni. .
Dacă cineva este interesat să știe ce sunt alte notații și la ce sunt folosite, am de gând să o fac într-un alt articol, care se va numi „Hai să vorbim despre notații”, dar asta este încă în planuri.
Este timpul să începem povestea noastră despre o notație foarte interesantă, simplă și practică eEPC (tradus: o descriere extinsă a lanțului de procese de evenimente). Traducerea sa literală dezvăluie și scopul său principal: descrierea lanțului de procese de afaceri. Principalul „truc” al notației este principiul „evenimentului”, pe care îl vom analiza în detaliu.
Care sunt avantajele notației eEPC:

În primul rând, nu este chiar o notație pură. Acestea. dacă în unele notații există un set rigid 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 după care se construiește schema și după care se citește apoi. În plus, puteți adăuga propriul element, 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! Acesta este un punct foarte important. În plus, orice alte restricții și reguli pot fi stabilite în standardul dvs. corporativ.
eEPC conține elemente de logică. Acest lucru vă permite să construiți scheme cu condiții, care sunt necesare pentru a descrie activitatea ("dacă acordul este de acord, atunci ...., În caz contrar ...")
Simplitatea elementelor vă permite să desenați diagrame ca în produse software, și în orice alt mod, chiar și pe hârtie, nu te vei încurca.
eEPC este atât de ușor de învățat și de înțeles încât poate fi folosit în viața reală, nu doar pentru a aduna praf într-un dulap. Învățarea regulilor va dura aproximativ 2 ore (dacă studentul dorește).

Bineînțeles, ca orice pe lumea asta, are și dezavantaje. Dar utilizarea rațională le menține 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 (este necesar 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 pentru modelarea proceselor complexe de afaceri costă sume foarte impresionante, iar proiectul care le folosește este măsurat în milioane. Și astfel avem un instrument foarte economic și ușor de înțeles. Pentru a fi mai precis, acest neajuns se referă în mod specific la metoda de descriere pe care o iau în considerare, adică. 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...

Pivotul principal al notației eEPC

După cum am menționat deja, traducerea literală a abrevierei eEPC ascunde conceptul de evenimente. Acesta este un punct foarte important pe care se construiește întregul principiu al construirii unui circuit. Deci sunt două concept cheie: „Eveniment” și „Funcție”. Prima dată când cineva încearcă să-și deseneze procesul sub forma unei diagrame eEPC, apare adesea întrebarea, care este diferența dintre un eveniment și o funcție? Acest lucru trebuie să fie clar pentru tine, altfel vei obține un rezultat imprevizibil. Deci: un eveniment este un fapt al realizării a ceva, și nu are o durată în timp, sau acest timp tinde spre zero (sau nu contează). Mai mult, un eveniment provoacă întotdeauna nevoia de a executa o funcție, 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. Conversatie telefonica Este o funcție. Conversația s-a încheiat (închis) - eveniment din nou. Astfel, se observă un lanț de evenimente: Apel - conversație - sfârșitul unui apel. Și terminarea apelului va necesita probabil o nouă funcție: î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ă trebuie să spun câteva cuvinte despre culorile folosite. Dacă ați întâlnit o descriere a proceselor în alte notații, de regulă, acestea erau alb-negru. Și acest lucru este corect, nu ar trebui să existe o dependență explicită a conținutului de culoare, deoarece diagrama poate fi desenată cu un creion pe hârtie, imprimată pe o imprimantă alb-negru etc. În acest caz (în notația eEPC) s-a întâmplat istoric ca elementele să aibă anumite culori. Ca să nu spun că era necesar, dar obiceiul este dezvoltat, iar percepția în în format electronic mai bine - puteți vedea imediat care este care. Aceste culori pot fi văzute ca un ghid. De ce sunt așa? Nu sunt sigur exact, dar mi se pare că firma ARIS, când a făcut suport pentru notația eEPC în produsul său, le-a dat astfel de culori, s-au „lipit”. 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 software-ul său de modelare a proceselor de afaceri. În general, recomand folosirea culorilor. Principalul lucru este că însăși forma elementelor nu este aceeași (adică diferă doar prin culoare), deoarece în alb și negru acest lucru poate fi confuz. Există și alte reguli care vă permit să dați „armonie” diagramei eEPC, despre ele vom vorbi.
Deci există un eveniment, există o funcție. Cum sunt ele legate?
Noi vedem asta eveniment1 a dus la necesitatea îndeplinirii unei anumite funcţii care s-a încheiat eveniment2... Dacă se aplică exemplului cu un apel telefonic, atunci va fi astfel:

Un eveniment - o funcție - este obișnuit să afișați un eveniment de sus în jos pe o 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 descriptivă, notația prevede mai multe elemente standard:

Poziţie(executor testamentar). Cel care îndeplinește această funcție
informație... Orice informație utilizată pentru a îndeplini o funcție, alta decât informațiile documentare. De exemplu, un apel telefonic, instrucțiuni despre cum să efectuați o operație etc.
Document... Elementul „Document” este destinat pentru afișarea suporturilor de informații (pe 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ă niciun obstacol în a adăuga propriile elemente. Principalul lucru este să remediați acest lucru în standardul intern, astfel încât să existe o înțelegere comună a modului în care arată și de ce sunt utilizate. O astfel de extensie nu încalcă cerințele, dacă linkul 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 în orice specific al industriei. Am adăugat propriul meu set de elemente, despre care voi discuta mai jos.
De asemenea, este necesar să se afle cum trebuie amplasate elementele luate în considerare. Toate aceste elemente trebuie să fie asociate cu o funcție într-un fel sau altul. aceasta regula generala: Niciun element nu este asociat cu evenimentul, cu excepția unei funcții. 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 de transfer de informații, atunci este afișată o linie în locul unei săgeți. Dacă informația intră (ajunge la 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 puteți redesena diagrama noastră specificând execuția funcției de gestionare a apelurilor. Nu există cerințe stricte pentru aranjarea elementelor, dar este obișnuit să le afișați în toate diagramele în același mod (pentru uniformitatea și armonia diagramei). Pentru a unifica aspectul vizual al diagramelor grafice ale proceselor de afaceri, astfel de reguli trebuie să fie consacrate în standardul intern și să le respecte. Puțin mai târziu, voi da câteva recomandări în acest sens.
Acum să ne redesenăm schema:

Vedem că operatorul efectuează procesarea unui apel primit, acționând în conformitate cu regulile de procesare a apelurilor primite și folosește pentru aceasta programul „CRM”. În acest caz, nu se utilizează nici documentele de intrare, nici de ieșire.
După cum am menționat, 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, mai întâi voi da un exemplu și apoi ne vom ocupa separat de elementele logicii.
Să fie așa în exemplul nostru: dacă clientul este interesat, managerul de vânzări lucrează în continuare cu el și expune oferi, care este trimis prin poștă folosind clientul de e-mail „MS Outlook”. Dacă nu există interes, atunci procesarea apelului este finalizată. În viața reală, ar fi bine să folosești regulile pentru încheierea unui apel, dar eu sunt, apropo, deocamdată o vom simplifica. Iată ce primești:

Elemente logice în schemele de notație eEPC

Elementele logicii sunt simple, dar există particularități și reguli pentru ca schema să fie logică și interpretată fără ambiguitate. Cea mai importantă regulă care trebuie urmată 100% este: deciziile logice pot fi luate numai la îndeplinirea funcţiilor ui. Acestea. nu poate exista ramificare după un eveniment. De ce? Pentru că în acest caz contrazice însuși conceptul de eveniment - este simplu și instantaneu, fără timp de execuție. De exemplu, dacă telefonul a sunat și o persoană stă și se gândește dacă să ridice sau nu telefonul, teoretic aceasta va fi deja o funcție în care va lua o decizie. Și practic, inclusiv din bun simț, încalcă regulile de gestionare a apelurilor, tk. el este plătit cu un salariu pentru a gestiona aceste apeluri și nu este nimic de argumentat aici (în general, așa cum se arată în diagramă).
În total, există 3 elemente de logică:

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

Unele dintre ele arată astfel:

După cum puteți vedea, există două opțiuni pentru prezentarea grafică a elementelor logice. Nu sunt diferite, complet alternative. Le-am adus pe amândouă, pentru că în practică în diverse surse poti vedea ambele optiuni. Pe care să-l folosiți depinde de dvs. Imi place mai mult primul.
Acum trebuie să vă dați seama de utilizarea elementelor de logică. Să luăm în considerare mai întâi opțiunile întâlnite, apoi să trecem la un exemplu. Să aruncăm o privire la fiecare element separat.
Element logic „ȘI”.

Când o funcție necesită mai multe evenimente pentru a rula simultan:

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

Conectarea elementelor, dacă în timpul executării unei funcții au loc mai multe evenimente:

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

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

Conectarea elementelor, dacă în timpul executării mai multor funcții are loc un eveniment:

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

Conectarea elementelor, dacă apariția unui eveniment duce la executarea mai multor funcții:

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

Element logic „SAU”.
Conectarea elementelor, dacă unul dintre evenimente poate determina executarea funcției:

Exemplu: O aplicație a fost primită prin telefon (evenimentul 1) sau o aplicație a fost primită de e-mail(evenimentul 2) va duce la necesitatea de a o gestiona.
Elemente de conectare, dacă o funcție poate declanșa cel puțin un eveniment:

Exemplu: Intocmirea si expedierea facturii de marfa pentru transmitere 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: A fost furnizat un serviciu (funcția 1) sau a fost vândut un produs (funcția 2), a apărut o datorie de la un client (evenimentul 1).

Element logic „SAU EXCLUSIV”.

Conectarea elementelor, atunci când unul și numai unul dintre evenimente este necesar pentru a executa o funcție:

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

Conectarea elementelor, dacă în urma execuției funcției are loc cel mult unul dintre 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: Livrarea mărfurilor a fost efectuată (evenimentul 1) fie prin transport propriu (Funcția 1), fie companie de transport(funcția 2)

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

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

Extinderea notației cu propriile elemente

După cum am spus, eEPC nu este cu adevărat 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 există un document în care sunt fixate astfel de extensii de elemente. De exemplu, folosesc următoarele elemente suplimentare care au apărut treptat în procesul de descriere a proceselor reale pentru diverse sarcini, de la descrieri simple până la setarea sarcinilor pentru automatizare.

Fișier de date... Folosit atunci când un fișier de date este creat ca rezultat al unei operații sau fișierul este utilizat pentru a efectua o operație.
Bază de date. Folosit la descrierea fluxurilor de informații între sisteme automatizate.
Fișier card. 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 indica informații structurate (reprezentarea entității). Diagrama poate fi folosită pentru a se referi la documente generate programatic folosind aplicații personalizate. Î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.

Convenții despre cum să plasați forme într-o diagramă

Prin ea însăși, notația eEPC nu impune cerințe stricte în 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 apărea un fel de „vinaigretă”. Pentru a evita acest lucru, se recomandă să dezvoltați și să vă 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 denotă executanții sunt situate în dreapta funcțiilor;
Documente primite în partea stângă sus a funcțiilor; direcția săgeții de la documente la funcție;
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ă nu există suficient spațiu, este permisă o aranjare arbitrară, cât mai aproape de funcție;
Elementul Aplicație este situat în partea dreaptă sus a funcțiilor. (dacă stocarea fișierelor care nu sunt rapoarte sunt utilizate pentru aceasta, acestea sunt afișate în același mod). Comunicare fără săgeată.
Elementele „Bază de date” și „Fișier card” sunt localizate în mod arbitrar;
Elementul „Flux de materiale” este situat în stânga documentelor însoțitoare cu referire la document printr-o linie fără săgeată;
Elementul „Cluster”, dacă este utilizat în combinație cu forma „Document”, pentru a desemna un document în formă electronică, este situat în partea stângă a documentului corespunzător.

De exemplu: Calculatorul de salarii calculează salariile pe baza documentelor „Ținuta de brigadă” furnizate acestuia. Totodată, el se ghidează după documentul „Regulamente privind salariile", Calculul se face î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 prevede identificarea acestora, de exemplu. 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.
Cifrele „Document” și „Funcție” fac obiectul unei identificări obligatorii pe diagramă.
Documentul se identifică prin indicarea în colțul din stânga sus al raportului sau codului documentului în conformitate cu registrul. Documentele primite de la furnizorii de bunuri și servicii (incoming) sunt identificate numai după nume.
O funcție este identificată prin specificarea numărului de secvență al funcției pentru acest grup de procese. Acestea. numărul funcției începe întotdeauna cu codul grupului de procese. Problemele identificării grupurilor de procese depășesc domeniul de aplicare al acestui articol, le vom analiza separat. Mai mult, ar trebui să înveți să identifici procesele înainte de a începe să le descrii, altfel poate exista dorința de a descrie toate activitățile companiei într-o singură diagramă, așa cum încearcă să facă uneori.
Prin urmare, acum voi arăta doar cu un exemplu cum poate fi reprezentat acest lucru în diagramă. Să revenim la exemplul de gestionare a apelurilor. Să presupunem că am atribuit codul „04” departamentului de vânzări, codul „VK” procesului de procesare a unui contact primit. Apoi diagrama va lua următoarea formă (identificarea este evidențiată cu roșu pentru claritate). Totodată, 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 management al documentelor).

Afișare feedback

La construirea modelelor, este adesea necesar să se efectueze un proces ciclic în funcție de o anumită condiție sau de necesitatea de a afișa activitățile factorilor de decizie. În acest caz, vorbim despre feedback.

Pentru a afișa feedback-ul de control, se utilizează principiul „includerii directe” în procesul unei funcții de control suplimentare cu ramificare ulterioară (este folosit elementul logic „SAU exclusiv”). De exemplu:

Descrierea textuală a proceselor

Indiferent cât de mult am încerca să afișam un proces de afaceri pe o diagramă, nu va fi posibil să obținem detalii complete, altfel vă puteți bloca în lanțuri nesfârșite de elemente și condiții. Pentru a evita acest lucru, precum și pentru a adăuga la descrierea procesului informații care nu pot fi afișate grafic, descrierea este completată cu acompaniament textual. Pentru aceasta, sunt dezvoltate diverse șabloane de text, care sunt completate în timpul descrierii. Formele unui astfel de șablon pot fi diferite, includ secțiuni separate cu o descriere a intrărilor și ieșirilor, resursele consumate, software-ul utilizat etc.
În cel mai simplu caz, un șablon de descriere a procesului de afaceri poate arăta astfel:

Procesul de afaceri:	Gestionarea unui contact primit	04.VK
Funcții de proces:
Nume	Descriere	Numărul de pe diagramă
Procesarea apelurilor primite	Când sosește un apel de intrare, operatorul procesează apelul în conformitate cu regulile de procesare a apelurilor primite. Identifică interesul clientului, oferă informații despre servicii	04. ВК.01
Formarea unei propuneri comerciale	Dacă există interesul unui client, operatorul transmite contactul managerului de vânzări. Managerul de vanzari pregateste o propunere comerciala si o trimite clientului prin e-mail	04.VK.02
Indicatori de proces:
Nume	Metoda de evaluare/măsurare
Numărul de refuzuri	Statisticile bazei de date

În afara domeniului de aplicare al acestui articol, există așa ceva subiecte importante, precum colectarea de informații, evidențierea proceselor de afaceri, descompunerea, evidențierea indicatorilor. Cu siguranță vom studia aceste întrebări în numerele viitoare.

Introducere. Sarcini tipice de descriere a proceselor de afaceri

În stadiile incipiente ale proiectelor care vizează reorganizarea proceselor de afaceri și introducerea sistemelor informaționale, managerii și specialiștii au cel mai adesea următoarele întrebări:

ce rezultate în ceea ce privește îmbunătățirea performanței organizației pot fi obținute folosind tehnologii de descriere și reorganizare a proceselor de afaceri;
ce software ar trebui utilizat în proiect („ARIS este mai bun decât BPwin?”, „ERwin este mai bun decât ARIS?” etc.);
cum se modelează procesele folosind produsul „X”;
cum să analizezi și să identifici problemele folosind produsul „X”;
ce metodologie să folosiți pentru a descrie procesele;
ce să facă în continuare cu modelele rezultate ale proceselor de afaceri.

Î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 întreprinderilor. În același timp, există sisteme care se concentrează în primul rând pe crearea de modele de proces și sunt incomode sau deloc destinate creării de modele de date și reglarii unui DBMS. Î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:

obiectivele proiectului;
cerințe pentru informații care caracterizează procesele de afaceri și necesare analizei și luării deciziilor în cadrul unui anumit proiect;
capacitățile sistemelor CASE pentru descrierea proceselor ținând cont de cerințele clauzei 2;
caracteristicile sistemului informatic dezvoltat/implementat.

Nu are sens să vorbim despre avantajul unui anumit sistem/notație până când nu au fost determinate tipul și domeniul de aplicare al proiectului, precum și principalele sarcini pe care proiectul ar trebui să le rezolve. În articolul nostru, am încercat să comparăm cele mai populare notații (sisteme de notație adoptate în modelare) folosite pentru a descrie procesele de afaceri și două sisteme care suportă aceste notații. Se presupune că acest material va servi drept bază pentru o discuție dedicată problemelor utilizării eficiente a sistemelor CASE pentru descrierea și analiza proceselor de afaceri ale întreprinderilor.

Descrierea proceselor de afaceri este realizată în scopul analizei și reorganizării lor ulterioare. Scopul reorganizarii poate fi introducerea unui sistem informatic, reducerea costurilor de productie, imbunatatirea calitatii serviciului clientilor, crearea de instructiuni de munca si de lucru la implementarea standardelor ISO 9000 etc. Pentru fiecare astfel de sarcină, există anumiți parametri care determină setul de cunoștințe critice asupra procesului de afaceri. Cerințele pentru descrierea proceselor de afaceri pot varia de la sarcină la sarcină. În general, un model de proces de afaceri ar trebui să ofere răspunsuri la următoarele întrebări:

ce proceduri (funcții, lucru) trebuie efectuate pentru a obține un rezultat final dat;
în ce secvență sunt efectuate aceste proceduri;
ce mecanisme de control și management există în cadrul procesului de afaceri luat în considerare;
roluri și responsabilități - cine realizează procedurile de proces;
ce documente/informații de intrare folosește fiecare procedură a procesului;
ce documente/informații de ieșire generează procedura procesului;
ce resurse sunt necesare pentru a finaliza fiecare procedură din proces;
ce documentație/condiții guvernează procedura;
ce parametri caracterizează execuția procedurilor și procesul în ansamblu;
Există o secvență de procese care minimizează costurile (inclusiv costul, timpul etc.);
în ce măsură procesul este/va fi susținut de sistemul informațional.

Notarea organigramei ARIS

Notația Organigramă este una dintre notațiile principale ale 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. 5 .

Modelul este construit din obiectele „Unitate organizatorică”, „Poziție”, „Persoană internă” etc. Tipurile de legături încorporate în notație permit reflectarea diferitelor tipuri de relații între obiectele structurii organizatorice. În diagrama prezentată în fig. Exemplul 5 „Întreprinderea” este gestionată de „Director” utilizând tipul de relație „este Manager organizație pentru”. Ierarhia subdiviziunilor este construită folosind legături de tipul „este compus din”. În plus, se pot preciza posturi - „Poziție” și numele angajaților reali care îi ocupă: „Persoană internă”, precum și tipul de conexiune „ocupă”.

Notații acceptate BPwin 4.0

Descrierea notațiilor IDEF0 și IDEF3

Notația IDEF0 a fost dezvoltată pe baza analizei structurale și a metodologiei de proiectare a SADT, aprobată ca standard american și este utilizată cu succes în multe proiecte legate de descrierea activităților întreprinderilor. IDEF0 este extrem de răspândit și este, în special, un standard în organizațiile internaționale 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 notațiilor IDEF0 și IDEF3 sunt prezentate în tabel. 2 și.

Semantica construirii modelelor IDEF0 și IDEF3 presupune 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).

Notația IDEF3, ca și notația ARIS eEPC, utilizează simboluri logice pentru a reprezenta ramificarea procesului. O diagramă în notația IDEF3 vă permite să reprezentați întregul proces și să urmăriți 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 chestionată. Obiectele de notație DFD sunt afișate î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 lucru și cerințele pentru sistemul informațional.

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

În tabel sunt prezentate diverse situații de aplicare 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 efectuată în raport cu rezolvarea problemei modelării proceselor de afaceri (Fig. 13).

Astfel, este rațional să se utilizeze BPwin pentru a gestiona proiecte la scară mică (întreprinderi mici și mijlocii, 2-5 persoane într-un grup de consultanți) și de durată (2-3 luni). Pentru proiecte 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 a crea modele de informații, iar proiectarea și configurarea bazelor de date nu este furnizată. În acest caz, lucrările pregătitoare pentru crearea documentației de reglementare pot 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

Notația ARIS eEPC reprezintă lanțul extins de proces condus de evenimente - o notație extinsă pentru a descrie lanțul 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)

Ar putea fi util să citiți: