Apar scheme. Descrierea textului proceselor

Notația de flux de informații este analogă cu notația DFD (a se vedea mai jos) și este utilizată atunci când se construiesc diagrame de flux de date sau documente între funcțiile proceselor de afaceri ale întreprinderii, așa cum se arată în Fig. 6.

Orez. 6.

Simplitatea notației îi limitează aplicațiile utile. Obiectele principale ale notației sunt „Funcție” (utilizată și la construirea modelelor de procese de afaceri) și „Fluxul de informații” - fluxul de informații (Fig. 7).

Orez. 7.

La construirea modelelor de proces de afaceri, se poate construi mai întâi un model eEPC, iar apoi, folosind funcțiile definite în proces, un model de flux de informații.

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 3.

Tabelul 2. Obiecte de notație eEPC

	Nume	Descriere	Reprezentare grafică
Notație IDEF0
	Activitate	Obiectul este folosit pentru a descrie funcțiile (proceduri, muncă) îndeplinite de departamentele/angajații întreprinderii. Înfățișat ca dreptunghi. Numele postului ar trebui să reflecte procesul, acțiunea. Pentru ca un job să fie simulat, trebuie să treacă ceva timp de la începutul până la sfârșitul jobului și unele resurse trebuie cheltuite
	Săgeata de intrare	Săgeata este trasă intrând în lucrare din stânga și descrie documentele primite, informațiile, resursele materiale necesare îndeplinirii funcției și modificate de lucrare
	săgeată de ieșire	Săgeata este desenată emanând din lucrarea 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
	Săgeată de control	Este desenată o săgeată care intră î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
	Săgeată mecanism	Săgeata este trasă intrând în lucrare de jos și descrie așa-numitele mecanisme, adică resursele necesare efectuării procedurii, dar care nu își schimbă starea în timpul executării acesteia. Exemple: angajat, mașină etc.
	Săgeată de apel	Săgeata este desenată venind de la lucrare în jos și este o legătură către un alt model de lucru. În BPwin, această săgeată este folosită pentru a îmbina și a împărți modelele

Tabelul 3. Obiecte de notație IDEF3

	Nume	Descriere	Reprezentare grafică
Notație DFD
		Obiectul este folosit pentru a descrie funcțiile (proceduri, muncă) îndeplinite de departamentele/angajații întreprinderii. Înfățișat ca dreptunghi. Numele postului ar trebui să reflecte procesul, acțiunea
		Un obiect folosit 1) pentru a descrie legături către alte diagrame; 2) link-uri către alte lucrări; 3) link-uri către obiecte; 4) să explice logica săgeților de ramificare la intersecții; 5) diverse comentarii despre funcții și intersecții
	Răscruce de drumuri	Operatori logici (5 tipuri - sincron și asincron „ȘI”, sincron și asincron „SAU”, exclusiv „SAU”), care definesc relația dintre funcțiile din cadrul procesului. Vă permite să descrieți ramificarea procesului
		Trei tipuri de săgeți care vă permit să descrieți secvența proceselor, precum și fluxul de informații și obiecte

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).

Orez. 8.

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. Absența părere, munca fără rezultate sau management, munca duplicată indică imperfecțiuni în procesele de afaceri.

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

Orez. 9.

În notația IDEF3, precum și în Notație ARIS eEPC, simbolurile logice sunt folosite 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.

V. Repin, S. Maklakov

Analiza activităților întreprinderilor și reorganizarea proceselor de afaceri este o sarcină extrem de complexă care necesită suport metodologic și instrumental. ÎN În ultima vreme Instrumentele CASE BPwin (Computer Associates) și ARIS Toolset (ARIS) devin din ce în ce mai populare în rândul analiștilor de afaceri. Acest articol oferă un scurt analiza comparativa aceste fonduri și recomandări pentru utilizarea lor.

Introducere. Sarcini tipice pentru descrierea proceselor de afaceri

În fazele incipiente ale proiectelor, al căror scop este reorganizarea proceselor de afaceri și implementarea acestora 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 activităților organizației pot fi obținute folosind tehnologii pentru descrierea și reorganizarea proceselor de afaceri;
care software utilizarea într-un proiect („Este ARIS mai bun decât BPwin?”, „Este ERwin mai bun decât ARIS?” etc.);
modul de modelare a proceselor 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 de proces de afaceri rezultate.

Momentan activat piata ruseasca Există 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 î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:

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 de a descrie procesele ținând cont de cerințele de la paragraful 2;
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 reorganizarii poate fi introducerea unui sistem informatic, reducerea costurilor de productie, imbunatatirea calitatii serviciului clienti, crearea de locuri de munca si instructiuni de lucru in timpul implementarii Standardele 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:

ce proceduri (funcții, lucrări) trebuie efectuate pentru a obține rezultatul final specificat;
î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 procesului;
ce documente/informații de intrare folosește fiecare procedură de proces;
ce documente/informații de ieșire generează procedura de proces;
ce resurse sunt necesare pentru a efectua fiecare procedură de proces;
ce documentație/condiții guvernează implementarea procedurii;
ce parametri caracterizează implementarea procedurilor și a procesului î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 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.

Notație ARIS eEPC

Notația ARIS eEPC reprezintă următoarele: lanț de proces condus de evenimente extins - o notație extinsă pentru descrierea lanțului 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 1 prezintă principalele obiecte utilizate în notație.

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 influențează și controlează execuția funcțiilor
3	Unitate organizationala	Un obiect care reflectă diferite unități organizaționale ale unei întreprinderi (de exemplu, management sau departament)
4	Document	Un obiect care reprezintă medii de stocare din viața reală, cum ar fi un document de hârtie
5	Sistem de aplicare	Obiectul reflectă sistemul de aplicație real utilizat în tehnologia de execuție a funcției
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	Conexiune săgeată între obiecte	Un obiect descrie tipul de relație dintre alte obiecte, cum ar fi activarea 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 procesului
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 procesului

Pe lângă cele indicate în tabel. 1 obiecte 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 conexiuni creș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 relații utilizate. În fig. Figura 1 prezintă cel mai simplu model eEPC, care descrie un fragment din procesul de afaceri al unei întreprinderi.

Orez. 1. Exemplu de model în notație eEPC

În fig. 1 arată că conexiunile 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” care „declanșează” execuția Funcțiilor 2 și 3. Notația eEPC este construit pe anumite reguli de descriere semantică:

fiecare funcție trebuie să fie inițiată de un eveniment și trebuie să se încheie cu un eveniment;
fiecare funcție nu poate include mai mult de o săgeată care „începe” execuția funcției și nu poate ieși din mai mult de o săgeată care descrie finalizarea funcției.

Pe lângă aceste reguli, există și altele reguli importante formarea modelelor în ARIS. Aceste reguli pot fi învățate folosind material metodologic„ARIS Methods”, care este instalat pe computer simultan cu versiunea demo a produsului.

În fig. Figura 2 arată 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 sistemul ARIS Toolset, care acceptă metoda ARIS de descriere a proceselor de afaceri, are un set specific de atribute. Utilizatorului i se oferă să folosească atribute standard pentru a descrie obiecte sau un număr limitat de atribute personalizate.

Din fig. 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 în 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 folosite pentru a construi modelul vă permit să reflectați ramificarea și fuzionarea unui proces de afaceri. Pentru a obține informații despre durata reală a proceselor, este necesar să utilizați alte instrumente de descriere, de exemplu diagramele Gantt în sistemul Microsoft Project.

Astfel, folosind notația eEPC ARIS, puteți descrie un proces de afaceri sub forma unui flux de lucrări executate secvențial (proceduri, funcții). Exemple de modele generate folosind ARIS eEPC sunt prezentate în Fig. 3 și 4.

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

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

Notarea ARIS pentru organigramă

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.

Orez. 5. Modelul structurii organizatorice a întreprinderii

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ă.

Notarea fluxului de informații ARIS

Orez. 6. Fragment din diagrama fluxului de informații ARIS

Orez. 7. Notarea fluxului de informații ARIS

La construirea modelelor de proces de afaceri, se poate construi mai întâi un model eEPC, iar apoi, folosind funcțiile definite în proces, un model de flux de informații.

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 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 cu notațiile 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, muncă) îndeplinite de departamentele/angajații întreprinderii. Înfățișat ca dreptunghi. Numele postului ar trebui să reflecte procesul, acțiunea. Pentru ca un job să fie simulat, trebuie să treacă ceva timp de la începutul până la sfârșitul jobului și unele resurse trebuie cheltuite
2	Săgeata de intrare	Săgeata este trasă intrând în lucrare din stânga și descrie documentele primite, informațiile, resursele materiale necesare îndeplinirii funcției și modificate de lucrare
3	săgeată de ieșire	Săgeata este desenată emanând din lucrarea 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ăgeată de control	Săgeata este desenată intrând în lucrare de sus și descrie acțiunea de control, de exemplu, o comandă, un document de reglementare etc. În notația IDEF0, fiecare procedură trebuie să aibă cel puțin o săgeată de control
5	Săgeată mecanism	Săgeata este trasă intrând în lucrare de jos și descrie așa-numitele mecanisme, adică resursele necesare efectuării procedurii, dar fără schimbarea stării acestora în timpul executării acesteia. Exemple: angajat, mașină etc.
6	Săgeată de apel	Săgeata este desenată venind de la lucrare în jos și este o legătură către un alt model de lucru. În BPwin, această săgeată este folosită pentru a îmbina și a împărți modelele

Tabelul 3. Obiecte de notație IDEF3

	Nume	Descriere
Notație DFD
1	Loc de munca	Obiectul este folosit pentru a descrie funcțiile (proceduri, muncă) îndeplinite de departamentele/angajații întreprinderii. Înfățișat ca dreptunghi. Numele postului ar trebui să reflecte procesul, acțiunea
2	Obiect referent	Un obiect folosit 1) pentru a descrie legături către alte diagrame; 2) link-uri către alte lucrări; 3) link-uri către obiecte; 4) să explice 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”, exclusiv „SAU”), care definesc relația dintre funcțiile din cadrul procesului. Vă permite să descrieți ramificarea procesului
4	Săgeți	Trei tipuri de săgeți care vă permit să descrieți secvența proceselor, precum și fluxul de informații și obiecte

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).

Orez. 8. Un exemplu de descriere a unui proces de afaceri în notația 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 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.

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

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

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.

Tabelul 4. Obiecte de notație DFD

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

În fig. Figura 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, ERwin poate fi folosit împreună cu BPwin - 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 unui dicționar de entități și atribute din ERwin în BPwin. Într-un model de proces, fiecare săgeată poate fi asociată cu un set de entități și atribute, iar fiecare job poate fi asociat cu un set de reguli de utilizare a datelor. Această relație dintre proces și modele de date face posibilă descrierea în detaliu a corespondenței datelor și a consumatorilor acestora și, prin urmare, eliminarea erorilor care pot apărea în timpul creării și implementării sistemelor informaționale.

Organigrama în BPwin 4.0

Organigramele BPwin (Fig. 11) sunt analoge cu organigramele ARI și, ca și în ARIS, au scopul de a descrie ierarhia subordonă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.
Imagini (biți), dacă sunt activate Organigrama Pictogramele ar trebui să fie folosite.
Grupuri de roluri - se pot potrivi unitate structurală. În exemplul din fig. În figura 10 sunt prezentate grupurile de roluri „Direcție”, „Contabilitate” și „Atelierul 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.

După crearea dicționarului, BPwin vă permite să creați o ierarhie de subordonare, inclusiv grupuri de roluri, roluri și resurse, folosind dialoguri de ghidare. În diagramele IDEF0, IDEF3 și DFD, fiecărui job i se poate atribui un lucrător de resurse 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ă zonele de responsabilitate ale angajaților întreprinderii atunci când efectuează operațiuni de proces sub formă de dungi separate.

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

Tabelul 5. Obiecte ale 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 procesului	Obiect pe diagramă	Obiect pe diagramă	Obiect pe diagramă
3	Document de intrare
4	Informații primite		Săgeată de intrare, săgeată de control	Pentru descriere este utilizat un obiect separat (Obiect de referință de tip Object sau săgeată Flux de obiect)
5	Document de ieșire	Un obiect separat este folosit pentru descriere („document”)	săgeată de ieșire	Pentru descriere este utilizat un obiect separat (Obiect de referință de tip Object sau săgeată Flux de obiect)
6	Informații de ieșire	Folosește un obiect separat pentru descriere („cluster”, „termen tehnic”)	săgeată de ieșire	Pentru descriere este utilizat un obiect separat (Obiect de referință de tip Object sau săgeată Flux de obiect)
7	Efectuarea procedurii	Un obiect separat este folosit pentru descriere („poziție”, „unitate organizațională”)	Săgeată mecanism
8	Echipamentul folosit	Folosește un obiect separat pentru descriere	Săgeată mecanism	Nu (poate fi reflectat în model numai prin legarea obiectelor de referință)
9	Managementul procedurii	Nu. Poate fi reflectat numai prin simboluri ale logicii și evenimentelor (secvența procedurilor) și/sau indicarea documentelor primite	Săgeată de control	Doar succesiunea de timp a procedurilor și logica procesului
10	Monitorizarea executării procedurii	Nu. Poate fi reflectat prin indicarea documentelor primite	Săgeată de control	Nu (poate fi reflectat în model numai prin legarea obiectelor de referință).
11	Feedback de management/control		Săgeată de control	Nu
12	Feedback de conectare	Nu. Poate fi reflectat doar de simboluri logice (secvența de proceduri)	Săgeata de intrare	Nu

Unul dintre cele mai importante aspecte descrierile modelelor de procese de afaceri sunt reflectate pe modelul acțiunilor de control, feedback-ul privind controlul și managementul 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.

Î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 răspunde la întrebările:

Cum se realizează influența controlului asupra funcțiilor 2 și 3? Se arată doar faptul că în timpul procesului este posibil să se întoarcă și să reexecută funcțiile 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 interior) reglementează îndeplinirea funcțiilor?

Orez. 12. Dezavantajele descrierii unui proces de afaceri în ARIS eEPC

Dacă încercați să reflectați toate condițiile și restricțiile care determină îndeplinirea 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 de asemenea inerente notației IDEF3). Notația IDEF0 nu are aceste dezavantaje. În același timp, modelele din IDEF0 nu prevăd utilizarea simbolurilor logice de execuție a procesului.

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

Funcționalitatea produselor ARIS și BPwin

Funcționalitatea instrumentelor de modelare ARIS Toolset și BPwin poate fi comparată corect doar în raport cu o anumită gamă de sarcini. Acest studiu examinează 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 care se rezolvă, aceste avantaje pot fie să crească, fie, dimpotrivă, să slăbească. Același lucru se poate spune despre deficiențe: o deficiență a unui sistem în cadrul unui proiect poate să nu fie așa în cadrul altuia. De exemplu, lipsa unor convenții clare pentru modelarea acțiunilor de control în cadrul eEPC ARIS poate duce la crearea unor modele care nu răspund la întrebările puse, în timp ce notația IDEF0 a sistemului BPwin ne permite să rezolvăm această problemă. Pe de altă parte, o procedură efectuată de o persoană poate fi descrisă mai adecvat utilizând eEPC ARIS decât folosind IDEF0 sau IDEF3 BPwin. Comparaţie funcţionalitate sistemele sunt date în tabel. 6.

Tabelul 6. Comparația funcționalității ARIS Toolset 5.0 și BPwin 4.0

	Caracteristici/Mediul de lucru	ARIS Toolset 5.0	BPwin 4.0
1	Standard acceptat	(parțial - DFD, ERM, UML)	IDEF0, IDEF3, DFD
2	Model de sistem de stocare a datelor	Baza de date obiect	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	Posibilitate de lucru in grup	Mânca. Folosit de ARIS Server	Mânca. Folosit de ModelMart
5	Limitați numărul de obiecte din diagramă	Nu	Pentru DFD și IDEF3 - nr. Pentru IDEF0, limitat de liniile directoare de notare
6	Posibilitate de descompunere	Descompunere nelimitată. Este posibilă descompunerea în diferite tipuri de modele	Descompunere nelimitată. Este posibilă trecerea la o altă notație în timpul procesului de descompunere
7	Format de prezentare model	Nereglementat	Formular standard (cadru) IDEF cu posibilitatea de a-l dezactiva
8	Ușurință în utilizare 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	Număr mare, dar limitat de proprietăți; numărul de tipuri este limitat	Numărul de UDP-uri nu este limitat. Număr limitat de tipuri (18)
10	Abilitatea de a analiza costurile de proces	Mânca. Posibilitatea de a utiliza ARIS ABC	ABC simplificat - analiza costurilor in functie de frecventa de utilizare intr-un proces. Posibilitatea de a exporta în Easy ABC
11	Generarea de rapoarte	Creați rapoarte bazate pe macrocomenzi Visual Basic standard și personalizate de utilizator	RPTwin, capacitatea de a personaliza vizual rapoartele, inclusiv calculul folosind formule folosind UDP
12	Dificultate în elaborarea rapoartelor personalizate	Dificil	Doar
13	Exportați rapoarte		Export implementat de rapoarte către MS Office, fișier text, RTF, HTML
14	Comunicarea cu modelul de date	Abilitatea de a construi diagrame ERD, software suplimentar necesar pentru export	Implementarea conexiunii cu modelul de date ERwin. Fiecare săgeată poate fi asociată cu 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 justificative	Da, suport OLE	Folosind tipul de comandă 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

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.

Î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.

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

Sarcină/Banc de lucru	ARIS Toolset 5.0
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 de nivel superior	3	5
Un 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 sistemelor de automatizare: descrierea funcționalității sistemului; crearea unui model de date logic; legătura dintre modelul de proces și 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 realizată în raport cu rezolvarea problemei modelării proceselor de afaceri (Fig. 13).

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

Astfel, pentru proiectele la scară mică (întreprinderi mici și mijlocii, 2-5 persoane într-un grup de consultanți) și cu durată (2-3 luni), este rațional să se utilizeze BPwin. 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 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.

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, 256 p.
DA. Marka, K. McGowan Metodologia analizei structurale si proiectarii. 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.

Introducere. Sarcini tipice pentru descrierea proceselor de afaceri

În stadiile incipiente ale proiectelor al căror scop este reorganizarea proceselor de afaceri și implementarea 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 activităților organizației pot fi obținute folosind tehnologii pentru descrierea și reorganizarea proceselor de afaceri;
ce software să folosești în proiect („ARIS este mai bun decât BPwin?”, „ERwin este mai bun decât ARIS?” etc.);
modul de modelare a proceselor 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 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:

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 de a descrie procesele ținând cont de cerințele de la paragraful 2;
caracteristici ale sistemului informatic în curs de dezvoltare/implementare.

Este inutil să vorbim despre avantajele 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 acest proiect trebuie să le rezolve. 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:

ce proceduri (funcții, lucrări) trebuie efectuate pentru a obține rezultatul final specificat;
î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 procesului;
ce documente/informații de intrare folosește fiecare procedură de proces;
ce documente/informații de ieșire generează procedura de proces;
ce resurse sunt necesare pentru a efectua fiecare procedură de proces;
ce documentație/condiții guvernează implementarea procedurii;
ce parametri caracterizează implementarea procedurilor și a procesului î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 ARIS pentru organigramă

Notația Organigramă este una dintre principalele notații ARIS și este destinată construcției de diagrame ale structurii organizaționale a unei întreprinderi. De obicei, acest model este construit la începutul unui proiect de modelare a proceselor de afaceri. Modelul reflectă diviziunile existente ale întreprinderii sub forma unei structuri ierarhice, așa cum se arată în Fig. 5 .

Modelul este construit din obiectele „Unitate organizatorică”, „Poziție”, „Persoană internă”, etc. Tipurile de conexiuni incluse în notație fac posibilă reflectarea diferitelor tipuri de relații între obiectele structurii organizaționale. În cel prezentat în Fig. În exemplul 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ă”.

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 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 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.

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.

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).

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

ComputerPress 1"2002

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 utilizate 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.

Structura generală a metodologiei ARIS

http://rudocs.exdat.com/docs/index-62596.html?page=3

Notația ARIS eEPC reprezintă următorul - lanțul de proces condus de evenimente extins - un lanț de proces extins, condus de evenimente. Notația a fost elaborată de specialiști de la IDS Scheer AG (Germania), în special de profesorul Scheer. Următorul tabel 2.3.1 prezintă principalele obiecte utilizate în notație.

Tabelul 2.3.1 Obiecte pentru descrierea proceselor de afaceri în notația ARIS eEPC.

În plus față de principalele obiecte enumerate în Tabelul 2.3.1, multe alte obiecte pot fi utilizate 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. Pentru a înțelege semnificația notației eEPC, să ne uităm la principalele tipuri de obiecte și relații utilizate. În figura 2.3.5. este prezentat cel mai simplu model eEPC, care descrie un fragment din procesul de afaceri al unei întreprinderi.

Orez. 2.3.5. Cel mai simplu model în notația eEPC

Din figura 2.3.5. este clar că legăturile dintre obiecte au un anumit sens și reflectă succesiunea funcțiilor din cadrul procesului. O săgeată 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 AND „declanșează” execuția Funcției 2 și 3. O analiză atentă a notației eEPC arată că practic nu este diferit de notația IDEF3. Cea mai importantă diferență între 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 eEPC este în mod evident numită extinsă tocmai pentru că conține un obiect „eveniment” - nu există un astfel de obiect în IDEF3. Când construiți un model în ARIS eEPC, trebuie respectate următoarele reguli:

fiecare funcție trebuie să fie inițiată de un eveniment și trebuie să se încheie cu un eveniment;

fiecare funcție nu poate include mai mult de o săgeată care „începe” execuția funcției și nu poate ieși din mai mult de o săgeată care descrie finalizarea funcției.

Figura 2.3.7 arată utilizarea diferitelor obiecte de notație ARIS eEPC la crearea unui model de proces de afaceri.

Orez. 2.3.7. Utilizarea diferitelor obiecte la crearea unui model în notație eEPC

Din figurile 2.3.6. și 2.3.7. Se poate observa 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 nu poate fi reflectată vizual în eEPC. Acest lucru duce la faptul că atunci când se creează modele, sunt posibile situații în care unui executant va fi desemnat să execute două sarcini simultan. Simbolurile logice folosite pentru a construi modelul vă permit să reflectați 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 aplicația MS Project.

În figura 2.3.8. Este prezentat procesul de afaceri de procesare a unei comenzi de client. 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 de vânzări realizează funcția „Efectuează analiza conformității produsului”. Rezultatul executării funcției sunt două evenimente alternative: „Comanda se potrivește cu articolul” și „Comanda nu se potrivește cu articolul”. Procesul se ramifică. Pentru a afișa ramificarea unui proces, se folosește simbolul logic exclusiv „SAU”. Funcția „Anunțați clientul despre imposibilitatea onorării comenzii” poate fi efectuată în două cazuri: dacă comanda nu corespunde articolului sau producția este imposibilă. Pentru a afișa aceste opțiuni pe diagrama procesului, se folosește simbolul logic „SAU” etc. După cum se poate observa din Figura 2.3.8., diagrama procesului din ARIS eEPC diferă de diagrama din IDEF3 în prezența obiectelor: evenimente, documente, sisteme de aplicații și poziții. Diagrama din ARIS este vizual mai informativă și este percepută mai bine, dar dimensiunea acestei diagrame este semnificativ mai mare decât dimensiunea diagramei în notația IDEF3.
Orez. 2.3.8. Un exemplu de descriere a procesului în notația ARIS eEPC