Specializari: IE, CIG, FB, MG

INFORMATICĂ
MANAGERIALĂ ŞI
DE GESTIUNE
ANUL III Semestrul 2
 INTRODUCERE

Modele de procese de afaceri sunt importante în diferite etape ale ciclului de viață al
BPM. Înainte de a începe pentru modelarea unui proces, este esențial să înțelegem de ce este
nevoie de modelare. Modelele pe care le producem vor arata diferit în funcție de motivul pentru
care se creează modelul, în primul rând. Există multe motive pentru modelarea unui proces.
Primul dintre ele este pur și simplu de a
înțelege procesul și de a împărtăși înțelegerea noastră cu cei care sunt implicați în procesul
respectiv în viaţa de zi cu zi. Într-adevăr, participanții la un proces de obicei efectuează activităţi
detaliate/specializate din respectivul proces, astfel încât acestea nu se confruntă cu
complexitatea întregului proces. Prin urmare, procesul de modelare îi ajută să înțeleagă mai bine
procesul în scopul de a identifica și pentru a preveni problemele de execuţie ale acestuia. Acest
pas spre o înțelegere aprofundată este prima condiție care trebuie îndeplinită pentru a efectua
analize de proces, re-design sau automatizare.
În acest suport de curs sunt prezentate elementele esenţiale necesare familiarizării cu
ingredientele de bază ale procesului de modelarea folosind limbajul Business Process Modeling
Notation (BPMN). Cu aceste concepte, veţi fi capabili să produceţi modele de procese de afaceri
care surprind relațiile temporale și logice simple, între activități, obiecte, resurse (de ex. angajaţi),
respectiv între date. În primul rând, vom descrie concepte esențiale legate de modelele de
proces, și anume modul în care modelele de proces se leagă de instanţele de proces. Apoi, vom
explica principalele patru blocuri structurale de ramificare și fuzionare care pot fi folosite în
modelele de proces. Acestea definesc decizii exclusive, execuția în paralel, deciziile inclusive și
repetițiile. În cele din urmă, vom acoperi artefactele de informații/date respectiv resursele
implicat într-un proces.
Un limbaj de modelare este format din trei părți: sintaxa, semantica, și notația. Sintaxa
oferă un set de elemente de modelare și un set de reguli care guvernează modul în care pot fi
combinate aceste elemente. Semantica leagă elementele sintactice și descrierile lor textuale într-
un înţeles clar, fără ambiguităţi. Notaţia definește un set de simboluri grafice pentru vizualizarea
elementelor. De exemplu, sintaxa BPMN include activități, evenimente, gateway-uri, și secvența
activităţilor. Un exemplu de reguli sintactice BPMN este faptul că evenimentele de tip start au
numai secvențe de ieșire în timp ce evenimentele finale au doar secvențe de intrare. Semantica
BPMN descrie ce fel de comportament este reprezentat prin diferite elemente. În esență, aceasta
se referă la întrebarea cum elementelor pot fi executate în ceea ce privește fluxul de activităţi.
De exemplu, un element care denotă o sincronizare a unor ramuri paralele ale procesului impune
așteptarea până când fiecare din ramurile de intrare sunt finalizate, înainte de a permite trecerea
la ramurile de ieșire din acesta. Un exemplu de notație BPMN este utilizarea unor dreptunghiuri
cu marginile rotunjite pentru a reprezenta activitățile procesului.
În acest suport de curs am prezentat elementele de bază ale procesului de modelare prin
limbajul BPMN. Alte limbaje răspândite care pot fi utilizate pentru a modela procese de afaceri
sunt Diagramele de Activităţi UML (UML AD), Event-driven Process Chains (EPC) și Web Services
Business Process Execution Language (WS-BPEL).
Diagramele UML AD sunt un alt standard OMG (Object Management Group). Ele sunt
aplicate în principal în ingineria software, unde pot fi folosite pentru a descrie comportamentul
software și pot fi legate de alte tipuri de diagrame UML (de exemplu, diagrame de clase, pentru
a genera automat cod software). Diagramele UML AD oferă un subset al elementelor de
modelare prezente în BPMN. De exemplu, construcţiile de tip OR-join nu sunt acceptate.
Notaţia EPC a fost dezvoltată inițial pentru proiectarea proceselor de referință incluse în
SAP R/3. A fost adoptată pe scară largă de către diverse organizații, atunci când a devenit limba
de modelare de bază a setului de instrumente ARIS. Mai târziu, au fost utilizate de către alți
furnizori pentru proiectarea de modele de referință, independent de SAP, cum ar fi ITIL și SCOR.
Notaţia EPC include elemente de modelare corespunzătoare activităților din BPMN, precum şi
pentru gateway-uri AND, XOR și OR, respectiv pentru evenimente și obiecte de date.
WS - BPEL (BPEL pe scurt), versiunea 2.0, este un standard al Organizației pentru
Promovarea Standardelor Referitoare la Informația Structurată (OASIS). BPEL este un limbaj de
execuție a modelelor de procese care se bazează tehnologia serviciilor Web pentru a realiza o
comunicare între procese. O ‚traducere’ din BPMN în BPEL este inclusă în specificația BPMN. Cu
toate acestea, această mapare nu este completă deoarece BPEL oferă un set restrâns de
construcții comparativ cu BPMN, precum și pentru că este în esență un limbaj orientat-bloc, în
timp ce BPMN este orientat-graf. BPEL este structurat în blocuri care trebuie să fie imbricate în
mod corespunzător și nu se pot suprapune. Un bloc este format dintr-un singur nod de intrare, și
un singur nod de ieșire (care corespunde cu tipul de nod de intrare și colectează toate ramurile
de ieșire de la nodul de intrare). De exemplu, în cazul în care nodul de intrare este un AND-split,
nodul de ieșire trebuie să fie un AND-join. Mai mult decât atât, BPEL nu este dotat cu un standard
de notație, din moment ce acest lucru a fost considerat a fi în afara domeniului de aplicare de
către OASIS, deși diferiţii vânzători oferă notații proprietare personalizate pentru acest limbaj. În
timp ce BPMN 1.2 a avut scopul de a fi omologul conceptual al BPEL, și mapările au fost create
pentru a trece de la una la alta. Însă, BPMN 2.0 poate fi folosit singur pentru a specifica procesele
executabile. Astfel, BPMN 2.0 poate să înlocuiască BPEL în acest sens.
Alte limbaje de modelare a proceselor provin din eforturile de cercetare. Două dintre ele
sunt Workflow Nets și Yet Another Workflow Language (YAWL). Workflow Nets sunt o extensie a
rețelelor Petri pentru modelarea proceselor de afaceri. Sintaxa lor este în mod intenționat simplă
și se învârte în jurul a două elemente: place-uri și tranziții. Place-urile corespund aproximativ
evenimentelor BPMN, în timp ce tranziţiile corespund activităților BPMN.
YAWL este un succesor al Workflow Nets, la care se adaugă construcții specifice pentru a
face posibilă reprezentarea comportamentului OR-join, activităților multi-instanțe, sub-
proceselor și regiunilor de anulare. YAWL păstrează simplitatea și intuitivitatea Workflow Nets,
deși oferă un limbaj mult mai expresiv.
O comparație dintre limbajele menţionate mai sus, în ceea ce privește expresivitatea lor pentru
reprezentarea secvenţelor de activităţi, a perspectivelor de date și de resurse, pot fi găsite pe
website-ul Workflow Patterns [www.workflowpatterns.org]. În timp, această inițiativă a colectat
un depozit de şabloane de procese observate des în practică şi implementate în cadrul unor
aplicaţii dedicate modelării proceselor de afaceri.

Capitol 1: Introducere în Business Process Model and Notation (BPMN)

Cu peste 100 de simboluri, BPMN este un limbaj destul de complex. Dar numărul mare de
simboluri nu este un motiv de panică, deoarece o mică parte din acestea acoperă nevoile de
modelare a marii majorităţi a utilizatorilor. După ce stăpâniţi acest nucleu de simboluri BPMN,
restul elementelor vor fi învățate natural, din practică. Deci, în loc să descriem în detaliu fiecare
simbol BPMN, vom introduce simbolurile și conceptele BPMN treptat, prin intermediul unor
exemple.

Fig. 1 – Diagrama BPMN a unui proces simplu pentru onorarea unei comenzi de cumpărare

În acest capitol, sunt prezentate simbolurile de bază ale BPMN. Un proces de afaceri
implică evenimente şi activităţi. Evenimentele reprezintă lucruri care se întâmplă instantaneu (de
exemplu, o factură a fost primită) în timp ce activitățile reprezintă unități de lucru care au o
durată (de exemplu, plata unei facturi). De asemenea, un proces înseamnă că evenimentele și
activitățile sunt în mod logic legate. Forma cea mai elementară de relaţie între două elemente
(fie ele evenimente sau activităţi) este secvenţa, ceea ce implică faptul că un eveniment sau
activitatea A este urmat de un alt eveniment sau activitate B. Prin urmare, trei concepte de bază
ale BPMN sunt evenimentele, activităţile, și arcele. Evenimentele sunt reprezentate de cercuri,
activități de dreptunghiuri rotunjite, și arcele (numite ‚fluxuri de secvenţă’ în BPMN) sunt
reprezentate de săgeți.
Exemplu 3.1 Fig. 1 prezintă modul in care este modelată folosind notaţia BPMN o simplă
secvență de activități aferentă unei comenzi de cumpărare. Acest proces începe ori de câte ori
un ordin de cumpărare a fost primit de la un client. Prima activitate care se desfășoară este
‚confirmă comandă’. Apoi, este înregistrată adresa de destinație, astfel încât produsul să poată fi
livrat clientului. Ulterior, factura este emisă. După ce suma facturii este încasată, ordinul este
arhivat, finalizându-se astfel procesul.
Din exemplul de mai sus se observă că cele două evenimente (de start şi de stop) sunt descrise
cu două simboluri ușor diferite. Se folosesc cercuri cu o margine subțire pentru a reprezenta
evenimente de pornire și cercuri, cu o margine groasă pentru a reprezenta evenimentele finale.
Evenimentele de început şi cele finale au un rol important într-un model de proces: evenimentul
de start indică momentul când instanțele procesului încep, în timp ce evenimentul final indică
atunci când instanţa (denumită şi caz) este completă. De exemplu, o nouă instanță (sau un nou
caz) a(l) procesului de onorare a comenzilor este declanșată ori de câte ori o comandă de achiziție
este primită, și se finalizează atunci când comanda este onorată.

Fig. 2 – Reprezentarea a 3 instanţe (comenzi) aflate în execuţie

Să ne imaginăm că procesul de onorare a comenzilor este realizat de o firmă de distribuţie

de produse. În fiecare zi această organizație va rula o serie de cazuri ale acestui proces, fiecare
caz fiind independent de celelalte. Odată ce o instanță de proces a fost generată, vom folosi
noțiune de jeton (în engleză token) pentru a identifica progresul (sau starea) comenzii despre
care este vorba în respectiva instanță. Jetoanele (token-urile) sunt create într-un eveniment de
start, şi după aceea curg de-a lungul modelul de proces până când sunt distruse în un eveniment
de sfârșit. Putem reprezenta aceste jetoane ca puncte colorate suprapuse peste un model de
proces. De exemplu Fig.2 arată starea de trei instanțe ale procesului de onorare a comenzilor: o
comandă nouă tocmai a fost primită deci un caz tocmai a început (token-ul este simbolul negru
pe eveniment de start), o altă comandă (un alt caz) este în curs de expediere (un token roșu este
plasat pe activitatea ‚expediază produsul’), iar o altă comandă (un al treilea caz) tocmai a fost
încasată și este pe cale de a începe arhivarea ei (un token verde pe arcul care leagă ‚încasează
factura’ și ‚arhivează comanda’).
Dacă este de la sine înţeles să daţi un nume (de asemenea numită etichetă) fiecărei
activităţi, nu trebuie să omiteţi să etichetaţi şi evenimentele, de asemenea. De exemplu, dând
un nume pentru fiecare eveniment de pornire ne permite să comunicăm ce declanşează o
instanță a procesului sau când ar trebui să înceapă o nouă instanță a procesului. În mod similar,
dând o etichetă pentru fiecare eveniment de sfârșit putem să comunicăm în ce condiție o instanță
a procesului se finalizează, sau care este rezultatul procesului.
Se recomandă următoarele convenții de numire. Pentru activități, eticheta ar trebui să înceapă
cu un verb în forma imperativă, urmat de un substantiv, de obicei referindu-se la un obiect care
ţine de contextul modelat. De exemplu, este corect ca o activitate să fie denumită ‚Aprobă
comandă’ şi nu este corect etichetată ‚Comandă’ sau ‚Aprobare de către manager’. Substantivul
poate fi precedat de un adjectiv (de exemplu, ‚Eliberează permisul de conducere’). De asemenea,
verbul poate fi urmat de un complement pentru a explica modul în care acțiunea se face (de
exemplu, ‚Reînnoieşte permisul de conducere’). Cu toate acestea, vom încerca să evităm etichete
lungi, deoarece acest lucru poate îngreuna lizibilitatea modelului. Ca o regulă generală, vom evita
etichete cu mai mult de cinci cuvinte (cu excepția prepozițiilor și conjuncțiilor). Articolele sunt de
obicei evitate pentru a scurta etichetele. În cazul evenimentelor, eticheta ar trebui să înceapă cu
un substantiv (din nou, acest lucru ar fi de obicei un obiect din contextul afacerii modelate), și se
încheie cu un verb în forma participiu trecut (de exemplu, .Factură emisă’), verbul fiind la timpul
participiu trecut pentru a indica ceva ce tocmai s-a întâmplat. Similar cu etichetele activităţilor,
substantivul poate fi precedat sau urmat de un adjectiv (de exemplu, ‚Comandă urgentă trimisă’).
Se vor capitaliza (scrie cu litere mari) primul cuvânt al etichetei atât pentru activităţi cât şi pentru
evenimente.
Verbe generale, cum ar fi "a face", "a efectua" sau "a realiza" ar trebui să fie înlocuite cu
verbe semnificative care să surprindă specificul activității efectuate sau evenimentului care are
loc. Cuvinte ca "proces" sau "comandă" sunt, de asemenea, ambiguu în ceea ce privește partea
lor de exprimare. Ambele pot fi folosite ca verb ("a procesa", "a comanda") și ca substantiv ("un
proces", "o comandă"). Vă recomandăm să folosiți astfel de cuvinte în mod constant, doar într-
un sens, de exemplu, "Comandă" întotdeauna ca un substantiv.
Pentru a denumi un model de proces ar trebui să folosim un substantiv, eventual precedat sau
urmat de un adjectiv (de exemplu, "onorare comenzi" sau „procesare sugestii"). Această etichetă
poate fi obținut prin nominalizarea verbului care descrie acțiunea principală a unui proces de
afaceri (de exemplu, "Onorează comandă" (acțiunea principală) devine "onorare comenzi"
(numele procesului). Substantivele compuse din mai multe cuvinte, cum ar fi "comandă-la-
încasare" și "achiziţie-la-plată", indicând secvențele de acțiuni principale ale procesului, sunt de
asemenea admise. Nu se capitalizează primul cuvânt dintr-un nume de proces.
Aplicând convențiile de denumire prezentate mai sus modele construite vor fi unitare şi
consistente, fiind astfel mai ușor de înțeles în cazul comunicării cu alte persoane și mai uşor de
reutilizat.
Exemplul din Fig. 1 reprezintă un posibil mod de a modela procesul de onorare a
comenzilor. Cu toate acestea, pot fi uşor produse modele destul de diferite care să descrie acelaşi
proces real. De exemplu, am putea fi neglijat anumite activități sau extins altele, în funcție de
intenția specifică de modelare. Subsecţiunea „Mică introducere în teoria modelării" reflectă pe
proprietățile care stau la baza un model în general și se referă şi la cazul specific al modelelor de
procese.

Opţional: Mică introducere în teoria modelării

Un model este caracterizat prin trei proprietăți: reprezentativitate, abstractizare, și

adaptarea la scop. În primul rând, un model presupune reprezentarea unui fenomen din lumea
reală – subiectul modelării/modelului. De exemplu, o clădire rezidențială care urmează să fie
construită ar putea fi modelată printr-o miniatură de lemn. În al doilea rând, un model
documentează doar aspectele relevante ale subiectului modelat, adică este o formă care
abstractizează faţă de anumite detalii care sunt considerate irelevante. Modelul lemn a clădirii
abstractizează în mod clar de la materialele din care va fi construită clădirea. În al treilea rând,
un model servește unui obiectiv bine determinat, care influenţează alegerea aspectelor realității
care se omit atunci când se creează un model. Fără un scop specific, nu am avea nici o indicație
asupra a ceea ce trebuie să se omită. Gândiţi-vă din nou la modelul de lemn. Acesta servește
scopului de a ilustra modul în care clădirea va arata. Astfel, se neglijează aspectele care sunt
considerate irelevante pentru a judeca aspectul, cum ar fi modul în care este construit sistemul
electric al clădirii. Deci, putem spune că modelul este un mijloc de a abstractiza pe baza subiect
real, cu intenția de a captura doar câteva dintre aspecte esenţiale ale acestuia.
O modalitate de a determina scopul unui model este de înțelege publicul ţintă al
modelului. În cazul modelului de lemn, publicul țintă ar putea fi un potențial cumpărător al
clădirii. Astfel, modelarea este important să se concentreze pe aspectul clădirii, nu pe aspectele
tehnice ale construcției. Pe de altă parte, modelul de lemn ar fi de folos unui muncitor care are
sarcina de a realiza fizic sistemul electric. În acest caz, un plan desenat pe hârtie al clădirii ar fi
mai potrivit. Astfel, atunci când se realizează modelarea unui proces de afaceri, trebuie să ținem
cont de scop specific și publicul țintă pentru care se creează modelul. Există două motive
principale pentru modelarea procesului: managementul organizaţiei respectiv proiectarea
sistemului informaţional al companiei. Modele de procese de management al organizaţiei sunt
orientate spre afaceri. Acestea sunt construite de către analiștii de afaceri și utilizate în principal
pentru înțelegere și comunicare în rândul conducerii si angajaţilor, darşi pentru măsurarea și
îmbunătățirea activităţilor. Ca atare, ele trebuie să fie suficient de intuitive pentru a fi înțelese
de către diverse părți interesate, și va abstract de obicei, aspecte legate de IT. Publicul țintă
include manageri, executanţi ai activităţilor din procese și analiști de afaceri. Modele de procese
pentru proiectarea sistemului informaţional al organizaţiei sunt orientate spre construirea de
software. Acestea sunt construite de către ingineri și dezvoltatori de sisteme informatice, și
folosite pentru automatizarea activităţilor realizate în organizaţie. Astfel, modelele trebuie să
conțină detalii de implementare, în scopul de a fi utilizate la un configurarea unui Sistem de
Management al Proceselor de Afaceri (Business Process Management System – BPMS), sau
folosite ca planuri de dezvoltare de software.
 Capitol 2: Ramificarea şi unirea căilor de execuţie ale unui proces

Activitățile și evenimente nu pot fi (nu trebuie să fie) neapărat executate secvențial. De

exemplu, în contextul unui proces de procesare a unei cereri, aprobarea și respingerea cererii
sunt două activități care se exclud reciproc. Deci, aceste activități nu pot fi efectuate în secvenţă,
deoarece intr-o execuţie (o instanță) a acestui proces se va efectua doar una din aceste două
activități. Atunci când două sau mai multe activități sunt alternative care pot fi alese în urma unei
decizii, le numim mutual exclusive.
Să luăm în considerare o altă situație. În procesul de procesare a unei cereri de
rambursare, odată ce cererea a fost aprobată, solicitantul este notificat cu privire la rezultat,
după care se efectuează plata. Notificarea și plata sunt două activități care sunt de obicei
efectuate de către două resurse diferite ale organizaţiei (de ex. două persoane diferite cum ar fi
secretară şi casieră), prin urmare, ele sunt independente una de alta. Ca urmare, cele două
activităţi nu trebuie să fie efectuate în secvenţă, ele putând fi efectuate în paralel, în același timp.
Atunci când două sau mai multe activități nu sunt interdependente, spunem că ele sunt
concurente (se realizează în paralel).
Pentru a modela aceste comportamente trebuie să introducem noțiunea de portal (în
engleză gateway). Termenul gateway implică faptul că există un mecanism de control al fluxului
de activităţi, care permite sau nu permite trecerea de token-uri. Când token-urile ajung la un
gateway, ele pot fi fuzionate la intrare, sau clonate la ieșire, în funcție de tipul de gateway.
Gateway-urile sunt desenate sub forma unor romburi şi se împart în gateway-uri care realizează
ramificarea (în engleză split) sau unirea (în engleză join) fluxului de execuţie. Un gateway de tip
split reprezintă un punct în care fluxul de activităţi al procesului trebuie sau se poate împărţi pe
mai multe ramuri (procesul diverge din acel gateway). Un gateway de tip join reprezintă un punct
în care fluxul de activităţi al procesului provenind de pe mai multe ramuri se uneşte (procesul
converge în acel gateway). Split-urile au un singur arc de intrare și mai multe arce de ieșire
(reprezentând ramurile divergente). Join-urile au mai multe arce de intrare (reprezentând ramuri
convergente) și un singur arc de ieșire.

2.1. Deciziile exclusive

Pentru a modela relația dintre două sau mai multe activități alternative, cum ar fi în cazul
aprobării sau respingerii unei cereri, se foloseşte un gateway de tip split exclusiv (denumit şi XOR-
split). Se foloseşte un gateway de tip join exclusiv (denumit şi XOR-join) pentru a îmbina două
sau mai multe ramuri alternative, care au fost în prealabil bifurcate cu un XOR-split. Un gateway
XOR este indicat în BPMN printr-un diamant gol sau printr-un diamant care conţine în interior un
"X". În toate exemplele care urmează de acum înainte, vom folosi mereu "X" în interiorul unui
diamant pentru a marca un gateway de tip XOR-split sau XOR-join.
Fig. 3 – Exemplu de folosire a unui gateway exclusiv

Exemplul 2 (Procesul de verificare al unei facturi): De îndată ce se decide ca o factură să

fie trimisă către un client, aceasta trebuie să fie verificată pentru conformitate/nepotriviri.
Verificarea poate duce la oricare dintre aceste trei opțiuni: i) nu există nepotriviri, în care cazul
în care factura este trimisă clientului, ii) există nepotriviri, dar acestea pot fi corectate, în care
cazul în care factura este re-trimisă clientului, și iii) există nepotriviri, iar acestea nu pot fi
corectată, în cazul în care emiterea factura este blocată. După ce oricare dintre aceste trei
activități este efectuată, factura este îndosariată și procesul se termină.
Pentru a modela procesele din Exemplul 2, vom începe prin a modela un eveniment
declanşator (de start) etichetat "primire notificare de emitere factura". Urmează o activitate de
decizie, și anume "Verificați factura pentru nepotriviri", modelată printr-un gateway. Această
activitate de decizie este o activitate care poate duce la rezultate diferite. În exemplul nostru,
această are trei rezultate posibile, care se exclud reciproc. Deci, e nevoie de un XOR-split care
este de fapt o bifurcaţie care trimite fluxul de activităţi în una din cele trei ramuri. Prin urmare,
trei arce vor ieşi din acest gateway, unul care duce la activitatea "Trimite factura" (activat în cazul
în care nu există neconcordanțe), altul spre activitatea "Re-trimite factura la client " (activat în
cazul în care există neconcordanțe, dar pot fi corectate), şi un al treilea arc spre activitatea
"Blochează factura" (activat în cazul în care există neconcordanțe care nu pot fi corectate) (vezi
Fig. 3). Din punct de vedere al token-urilor care ‚circulă’ prin model, într-un gateway de tip XOR-
split, token-ul care vine de-a lungul arcului de intrare în gateway este trimis de-a lungul unui
singur arc de ieșire (adică doar o ramură de ieşire din gateway poate fi activată).
Atunci când se utilizează un XOR-split, asigurați-vă că fiecare arc de ieșire este adnotat cu
o etichetă care specifică condiţia care trebuie să fie îndeplinită pentru ca ramură respectivă să
fie activată. Mai mult decât atât, folosiți întotdeauna condiții care se exclud reciproc, adică doar
una dintre ele poate fi adevărată de fiecare dată când XOR-split este atins de un token. Aceasta
este caracteristica principală a unui XOR-split. În exemplul nostru, o factură poate fi corectă, sau
conține nepotriviri care pot fi corectate, sau poate conţine nepotriviri care nu pot fi corectate; şi
numai una dintre aceste trei condiții este adevărată pentru orice factură emisă.
 În Fig. 3 arcul etichetat "există nepotriviri, dar nu pot fi corectate" este marcat cu o linie
oblică. Această notație este opțională și este folosită pentru a indica arcul implicit, adică arcul
care va fi folosit de către token-urile care ajung la XOR-split în cazul în care condițiile aferente
tuturor celorlalte arce de ieșire din gateway sunt evaluate ca false. Întrucât acest arc are
semnificația de „în orice altă situaţie”, acesta poate fi lăsat neetichetat cu o condiţie. Cu toate
acestea, se recomandă etichetarea în continuare a acestui arc cu o condiție, pentru a spori
lizibilitatea şi a uşura înțelegerea modelului de către alte persoane.
Odată ce oricare dintre cele trei activități alternative a fost executată, e nevoie ca cele 3
ramuri ale procesului să se unească. Astfel, se va executa activitatea "Arhivează factură", care
este comună pentru toate cele trei situaţii ale unei facturi. Pentru a modela acest lucru, vom
folosi un XOR-join. Un gateway de acest tip acționează ca un portal, în sensul că se așteaptă un
token care să sosească de-a lungul unuia dintre arcele de intrare, iar de îndată ce acesta soseşte
este trimis de-a lungul arcului de ieșire. Cu alte cuvinte, execuţia activităţilor ‚trece’ de un XOR-
join de fiecare dată când se ajunge la acesta de pe o ramură de intrare care a fost executată în
totalitate.
Revenind la exemplul nostru, vom completa modelul de proces cu un eveniment de sfârșit
denumit "Factura emisă". Asigurați-vă că întotdeauna un model de proces se finalizează cu
eveniment de sfârşit, chiar dacă este evident modul în care procesul se termină.

2.2. Execuţia paralelă

Atunci când două sau mai multe activități nu au dependențe de ordine de la una la alta
(adică o activitate nu are nevoie să fie urmată de alta, nici nu o exclude pe cealaltă) ele pot fi
executate simultan, sau în paralel. O poartă paralelă (AND gateway) este folosit pentru a modela
acest raport special. În mod specific, vom folosi un AND-split pentru a modela executarea
paralelă a două sau mai multe ramuri, și un AND-join pentru a sincroniza execuția de pe două sau
mai multe ramuri paralele. Un Gateway de tip AND este descris ca un diamant care conţine un
semn "+".
Exemplul 3 (Verificarea de securitate la un aeroport): După ce cartea de îmbarcare a fost
emisă, pasagerii trebuie să se prezinte la controlul de securitate. Aici se realizează controlul
personal cât şi cel al bagajelor de mână. După aceea, pasagerii pot merge la poarta de îmbarcare.
Acest proces constă din patru activități. Modelul începe cu activitatea "Mergi la
verificarea de securitate" continuă cu activităţile „Realizare verificare personală”, „Realizare
verificare bagaje” și se termină cu activitatea "Mergi la poarta de plecare". Aceste două activități
au o dependență clară: un pasager poate merge la poarta de plecare doar după efectuarea
ambelor controale de securitate. După prima activitate, iar înainte de ultima nea aflăm în situaţia
de a efectua două activități care pot fi executate în orice ordine, adică care nu depind unele de
altele: „Realizare verificare personală”, respectiv „Realizare verificare bagaje”. Pentru a modela
această situație, vom folosi un AND-split care leagă activitatea "Mergi la verificarea de securitate"
de cele două activități de verificare. De asemenea, vom folosi un AND-join care sincronizează cele
două ramuri cu activităţile de verificare astfel încât activitatea "Mergi la poarta de plecare" să nu
se poată executa înaintea finalizării celor două verificări (vezi Fig. 4).

Fig. 4 – Exemplu de folosire a unei ramificări paralele

AND-split-ul ‚consumă’ token-ul care vine de la activitatea "Mergi la verificarea de

securitate" şi ‚produce’ alte două token-uri. Fiecare dintre acestea ‚curge’ independent prin una
din cele două ramuri, oprindu-se la întâlnirea AND-join-ului. Cu alte cuvinte atunci când întâlniţi
un AND-split într-un model trebuie să executaţi toate ramurile care ‚ies’ din acesta, indiferent
câte sunt (rețineți că pot fi mai mult de două arce de ieșire). Așa cum am spus înainte, un token
este utilizat pentru a indica starea unei anumite execuţii (instanțe) a procesului iar culoarea
token-ului face diferența dintre mai multe instanţe care se execută în acelaşi timp. Există situaţii
când mai multe token-uri de aceeași culoare sunt distribuite pe un model de proces (de exemplu,
ca rezultat al executării unui AND-split), şi colectiv reprezintă starea în care se află instanța. De
exemplu, în cazul în care un token este pe arcul dintre activitatea "Realizare verificare personală"
şi AND-join iar un alt token de aceeași culoare este pe arcul dintre AND-split şi activitatea
"Realizare verificare bagaje", acest lucru indică că un pasager (o instanță a procesului de control
de securitate) a trecut de verificarea individuală, dar bagajul lui de mână nu a trecut încă de
controlul de securitate.
AND-join din exemplul nostru așteaptă un token de la fiecare din cele două arce de
intrare, și odată ce acestea sunt disponibile, le îmbină înapoi într-un singur token. Un singur token
este apoi trimis la activitatea "Mergi la poarta de plecare". Aceasta înseamnă că vom putea trece
mai departe cu execuţia activităţilor doar atunci când toate ramurile de intrare aufost finalizate
(trebuie avut în vedere faptul că un AND-join poate avea mai multe arce de intrare). Acest
comportament de așteptare a ajungerii unui număr de token-uri care apoi fuzionează într-unul
singur se numește sincronizare.
Exemplul 4: Să extindem exemplul de onorare a comenzilor din Fig. 1 prin constrângerea
că o comandă de cumpărare poate fi confirmat numai în cazul în care produsul este în stoc, altfel
procesul se finalizează prin respingerea comenzii. Mai mult, dacă ordinul este confirmat, adresa
de expediere este primită și produsul solicitat este livrat. În acelaşi timp, factura este emisă iar
plata este primită. Ulterior, comanda este arhivată și procesul se finalizează.
Modelul rezultat este prezentat în Fig. 5. şi necesită câteva remarci. În primul rând, acest
model are două activități care se exclud reciproc: "Confirmă comanda" și "Respinge comanda".
Astfel, acestea trebuie să fie precedate de un XOR-split (amintiți-vă să plasaţi o activitate înainte
de un XOR-split, pentru a permite luarea unei decizii, cum ar fi o verificare (ca în acest caz), sau
o aprobare).

Fig. 5 – O versiune extinsă a procesului de onorare a unei comenzi

În al doilea rând, cele două secvențe "Preia adresa de expediere" - "Expediază produsul"
și "Emite factură" - "Înregistrează plata", pot fi efectuate în mod independent una de cealaltă. Ca
urmare ele sunt incluse într-un bloc între un AND-split și un AND-join. În realitate, aceste două
seturi de activități sunt de obicei executate de resurse diferite din cadrul organizaţiei (de ex. un
gestionar pentru expediere și un ofițer financiar pentru factură) și, astfel, pot fi executate în
paralel. Remarcaţi cuvântul "între timp", din descrierea procesului, deoarece acesta indică faptul
că două sau mai multe activități pot fi efectuate în același timp.
Să comparăm versiunea din Fig. 5 a procesului de onorare a comenzilor cu Fig. 1 în ceea
ce privește evenimentele. Noua versiune dispune de două evenimente de sfârşit în timp ce prima
versiune dispune de un singur eveniment de sfârșit. Într-un model BPMN putem avea mai multe
evenimente finale, fiecare capturând un rezultat diferit al procesului (de exemplu, comandă
confirmată faţă de comandă respinsă). BPMN adoptă așa-numita terminare semantică implicită,
ceea ce înseamnă că o instanță de proces se finalizează numai atunci când fiecare token care
curge prin model atinge un eveniment terminal. În mod similar, putem avea mai multe
evenimente de start într-un model BPMN, fiecare eveniment capturează un declanșator diferit
pentru a începe o instanţă a procesului. De exemplu, am putea începe procesul de onorare a
comenzilor, fie atunci când o nouă comandă de achiziție este primită fie atunci când o comandă
revizuită este retrimisă de un client. În cazul în care o comandă revizuită este retrimisă, se pot
regăsi în primul rând detaliile comenzii precedente din baza de date de comenzi, și apoi continua
cu restul procesului. Această variantă a modelului de onorare a comenzilor este prezentat în Fig.
6. O instanţă a acestui model de proces este declanșată de primul eveniment care apare
(remarcaţi utilizarea unui XOR-join pentru a fuziona ramuri care provin din două evenimente de
pornire).
 Fig. 6 – O variantă a procesului de onorarea a unei comenzi, cu două evenimente declanşatoare diferite

Există două situații în care un gateway poate fi omis. Un XOR-join poate fi omis înainte de
o activitate sau un eveniment. În acest caz, arcele de intrare în XOR-join sunt conectate direct la
activitate sau la eveniment. Un AND-split poate fi, de asemenea, omis, atunci când urmează după
o activitate sau un eveniment. În acest caz, arcele de ieșire ale AND-split-ului vor porni direct din
activitatea sau evenimentul precedent.

2.3. Deciziile inclusive

Câteodată e nevoie să se execute una sau mai multe dintre ramurile care pleacă dintr-un
split. Exemplul 5 (Procesul de distribuire a mărfurilor): O companie are două depozite care
stochează diferite produse: unul la Amsterdam și altul la Hamburg. Când o comandă este primită,
acesta este distribuită din aceste depozite. Dacă unele dintre produsele comandate sunt stocate
în Amsterdam, o sub-comandă este trimisă acolo, şi reciproc, în cazul în care unele dintre
produsele comandate sunt stocate în Hamburg, o sub-comandă este trimisă acolo. După aceea,
comanda este înregistrată și procesul se termină.
Putem modela scenariul de mai sus, folosind o combinație de gateway-uri AND şi/sau
XOR? Răspunsul este „da, cu unele probleme”. Figurile 7 și 8 arată două soluții posibile. În primul,
vom folosi un XOR-split cu trei ramuri alternative: una urmată în cazul în care ordinul conține
doar produse aflate în Amsterdam (unde sub-comanda este transmisă la depozitul de la
Amsterdam), o alta urmată în cazul în care comanda conține doar produse aflate în Hamburg (în
mod similar, în această ramură sub-comanda este transmisă la depozitul Hamburg), și o a treia
ramură care trebuie urmată în cazul în care comanda conține produse din ambele depozite (caz
în care sub-comenzile sunt transmise către ambele depozite). Aceste trei ramuri converg într-un
XOR-join care duce la înregistrarea comenzii.
 Fig. 7 – Prima încercare de a modela o decizie inclusivă

În timp ce acest model surprinde scenariul nostru corect, diagrama rezultată este
oarecum complicată, din moment ce avem nevoie de duplicate pentru cele două activități de
transmitere a sub-comenzilor către cele două depozitele. Și dacă am fi avut mai mult de două
depozite, numărul de activități duplicat ar crește. De exemplu, dacă am avea trei depozite, am
avea nevoie de un XOR-split, cu șapte brațe de ieșire, și fiecare activitate ar trebui să fie duplicată
de patru ori. În mod clar această soluție nu este scalabilă.

Fig. 8 – A doua încercare de a modela o decizie inclusivă

În cea de a doua soluție folosim un AND-split, cu două arce de ieșire, fiecare ducând la
câte un XOR-split cu două ramuri alternative. Una este urmată in cazul în care comanda conține
produse din Amsterdam/Hamburg, caz în care activitatea de transmitere a sub-comenzii se
efectuează; cealaltă ramură este urmată în cazul în care ordinul nu conține nici un produs din
Amsterdam/Hamburg, caz în care nu se face nimic până la XOR-join-ul care îmbină cele două
ramuri alternative. Apoi, un AND-join unește cele două ramuri paralele și procesul se termină
prin înregistrarea comenzii.
Care este problema cu această a doua soluție? Scenariul din exemplu permite trei cazuri:
produsele sunt doar în Amsterdam, doar în Hamburg, sau în ambele depozite. Dar această soluție
permite mai mult cu un caz: atunci când produsele nu sunt în nici unul din cele două depozite.
Apare acest caz, atunci când cele două ramuri goale ale celor două XOR-split-uri sunt urmate,
astfel neexecutându-se nici o activitate între "Verifică produsele comandate" și "Înregistrează
comanda". Astfel această soluție, în ciuda faptului că este mai compactă decât prima, este
greșită.
Pentru a modela situațiile în care o decizie poate conduce la alegerea uneia sau a mai
multor opțiuni, avem nevoie să luăm o decizie inclusivă (OR). Un OR-split este similar cu XOR-
split, dar condițiile de pe ramurile de ieșire nu trebuie să se excludă reciproc (adică mai mult de
una dintre ele poate fi adevărat în același timp). Când execuţia procesului ajunge la un OR-split
se pot urma una sau mai multe ramuri de ieşire, în funcție de care condiții sunt adevărate. În
ceea ce privește semantica token-urilor, acest lucru înseamnă că OR-split-ul consumă un token
de-a lungul arcului de intrare și generează un număr variabil de token-uri, echivalent cu numărul
de condiții de ieșire care sunt adevărate. Acest număr poate fi cel puțin unu și cel mult numărul
total ramuri de ieșire din OR-split. Similar cu un XOR-split, un OR-split poate fi, de asemenea,
urmat de un arc de ieşire prestabilit (care este urmat numai atunci când toate celelalte condiții
sunt evaluate ca false).

Fig. 9 – Soluție corectă folosind gateway-uri de tip OR

Figura 9 prezintă soluția la exemplul nostru folosind un OR-split. După ce sub-comanda a

fost transmisă la una dintre cele două depozite sau la ambele, vom folosi un OR-join pentru a
sincroniza fluxul și a continua cu înregistrarea ordinului. Un OR-join este executat atunci când
toate activităţile aflate pe ramurile de intrare active au fost finalizate. După ce toate token-urile
distribuite pe ramuri de către un OR-split au ajuns la OR-join, acesta din urmă consumă toate
aceste token-uri şi produce unul singur trimis de-a lungul arcului de ieşire (similar cu
sincronizarea realizată de un AND-join). Acest comportament se nume sincronizare unificatoare
(syncronizing merge) spre deosebire de simpla unificare realizată de un XOR-join și de
sincronizarea realizată de un AND-join.
Să insistăm pe conceptul de ramură activă. Priviţi modelul din Fig. 10, care conţine un
gateway de tip nedefinit (cel gri cu un semn de întrebare). Ce tip ar trebui să-i atribuim? Să
încercăm un AND-join care să fie în concordanţă cu AND-split-ul precedent. Ne amintim că un
AND-join-ul aşteaptă un token de-a lungul fiecărui arc de intrare. În timp ce token-ul din ramura
de activitatea "C" va ajunge mereu la ANDjoin, token-ul din ramura care începe cu activitatea "B"
nu poate ajunge în cazul în care fluxul este direcționat către "E" de XOR-split-ul intermediar. Deci,
în cazul în care activitatea de "D" nu este executată, AND-join-ul va aștepta la nesfârșit un token,
şi în consecinţă instanța respectivă a procesului nu se va finaliza niciodată. Această anomalie de
comportament se numește punct mort (deadlock) și trebuie evitată.

Fig. 10 – De ce tip ar trebui sa fie join-ul astfel încât instanţele procesului sa se execute corect?

Să încercăm un XOR-join în locul gateway-ului enigmatic. Amintim că XOR-join-ul

funcționează prin transmiterea de-a lungul arcului de ieșire a fiecărui token care ajunge prin unul
din arcele de intrare. În exemplul nostru, acest lucru înseamnă că putem executa activitatea "F"
o dată sau de două ori, în funcție de modul în care XOR-split-ul intermediar direcţionează token-
ul de pe ramura care începe cu activitatea „B” către activitatea "E" (adică, dacă se execută „E”,
"F" se execută o singură dată;iar dacă se execută "D", activitatea "F" este executată de două ori).
În timp ce această soluție poate funcţiona, avem problema că nu știm dacă activitatea "F" va fi
executat o dată sau de două ori, și probabil nu am vrea să fie executată de două ori. Mai mult
decât atât, în acest caz am putea semnala încheierea instanţei procesului de două ori. Și aceasta,
din nou, este ceva ce ne dorim să evităm.
Singurul tip de gateway rămas este OR-join. Un OR-join va aștepta token-uri de-a lungul
tuturor ramurilor active pentru a fi executat. În cazul în care XOR-split-ul intermediar ca trimite
token-ul de pe ramura care începe cu activitatea „B” către "E", OR-join-ul nu va mai aştepta un
token de pe ramura respectivă. Astfel, se va trece la Execuţia activităţii F imediat ce token-ul de
pe ramura cu activitatea "C" ajunge. Pe de altă parte, dacă XOR-split-ul intermediar trimite token-
ul către activitatea "D", OR-join va aștepta un token si de la această ramură. O dată cele două
jetoane au ajuns, le va consuma și produce un nou token de-a lungul arcului către activitatea "F"
care poate fi executată o dată și procesul poate finaliza în mod normal.
Deci, când ar trebui folosit un gateway OR-join?
Deoarece semantica OR-join nu este simplă, prezența acestui element într-un model
BPMN poate confuza cititorul. Astfel, este recomandată folosirea lui numai atunci când este strict
necesară. În mod evident, un OR-join trebuie să fie utilizat ori de câte ori avem nevoie de
sincronizarea ramurilor care pornesc de la un OR-split precedent. În mod similar, ar trebui să
folosim un AND-join pentru a sincroniza ramurile care pornesc de la un AND-split precedent și un
XOR -join să fuzioneze un set de ramuri care se exclud reciproc. In multe cazuri reale, modelul nu
va avea o structură simplă (ca în exemplele precedente în care modelul este format din blocuri
delimitate de un split şi un join de același tip). Modelul poate arata mai degrabă ca cel din Fig.
10, în cazul în care pot fi mai multe puncte de intrare, sau de ieşire dintr-un bloc de structură. În
aceste cazuri, jucaţi jocul token-urilor pentru a înțelege corect tipul de gateway necesar pentru
a modela realitatea. Începeți cu un XOR-join, încercați pe urmă un ANDjoin și în cazul în care
ambele gateway conduc la modele incorecte utilizaţi un OR-join.
Dat fiind că am parcurs cele trei gateway-uri de bază, putem să extindem procesul de onorare a
comenzilor. Să presupunem că în cazul în care produsul nu este in stoc, acesta poate fi fabricat.
În acest fel, o comandă nu va mai fi respinsă.
Exemplul 6: În cazul în care produsul solicitat nu se află în stoc, acesta trebuie să fie produs înainte
de a continua procesarea comenzii. Pentru fabricarea unui produs, materiile prime necesare
trebuie să fie comandate. Doi furnizori preferaţi oferă diferite tipuri de materii prime. În funcție
de produsul care urmează a fi fabricat, materiile prime pot fi comandate doar de la furnizorul 1
sau doar ce la furnizorul 2, sau de la ambii. Doar după ce materiile prime sunt disponibile,
produsul poate fi fabricat și comanda poate fi confirmată. Pe de altă parte, în cazul în care
produsul este în stoc, acesta este preluat din depozit înainte de confirmarea comenzii. Apoi
procesul continuă în mod normal.
Modelul pentru această extensie a modelului iniţial este cel din figura următoare.

Fig. 11 – Modelul de proces care include producţia produselor

2.4. Reluarea unei activităţi şi repetarea unei părţi din proces

 Până acum am văzut structuri care sunt liniare, adică fiecare activitate poate să fie
executată cel mult odată. Cu toate acestea, uneori, realitatea ne poate cere să repetăm una sau
mai multe activități (de exemplu din cauza unei verificări care a eșuat de mai multe ori).
Exemplul 7: În biroul ministrului Trezoreriei, o dată o anchetă ministerială a fost
declanşată, aceasta este în primul rând înregistrată în sistem. Apoi, cazul este investigat astfel
încât un răspuns ministerial să poată fi pregătit. Finalizarea anchetei include scrierea răspunsului
de către şeful de cabinet și o revizuire a răspunsului de către registratorul principal. Dacă
registratorul nu aprobă răspunsul, acesta din urmă trebuie să fie rescris de către şeful de cabinet.
Procesul se termină numai după ce răspunsul a fost aprobat de registrator.
Pentru a modela reluare sau repetarea avem nevoie în primul rând să identificăm activitățile,
(sau mai mult, întreg fragmentul de proces) care pot fi repetate. În exemplul nostru aceasta
constă din secvența de activități "Pregăteşte răspunsul ministerial" și " Revizuieşte răspunsul
ministerial". Să numim acest fragment al procesului ‚bloc de repetiție’. Proprietatea unui bloc de
repetare este că ultima activitate trebuie să fie o activitate de decizie. De fapt, acest lucru ne
permite să decidem dacă să ne întoarcem la începutul blocului de repetiție (astfel încât
activităţile din acesta să poată fi repetate), sau să continuăm cu restul procesului. Ca atare,
această activitate de decizie ar trebui să aibă două rezultate. În exemplul nostru, activitatea de
decizie este "Review răspuns ministerială" și rezultatele sale sunt: "răspuns aprobat" (în acest
caz, se continuă cu restul activităţilor din proces) și "răspuns neaprobat" (se execută din nou
activităţile din blocul de repetiţie). Pentru a modela aceste două posibile rezultate, vom folosi un
XOR-split, cu două ramuri de ieșire: una care ne permite să continuăm cu restul procesului (în
exemplul nostru, aceasta este pur și simplu evenimentul final "anchetă ministerială finalizată"),
şi cealaltă ramură care merge înapoi înainte de activitatea "Pregăteşte răspunsul ministerial".
Vom folosi un XOR-join pentru a reconecta această ramură de revenire la restul modelul de
proces, chiar înainte de blocul de repetiție. Modelul pentru exemplul nostru este ilustrat în Fig.
12.

Fig. 12 – Model cu un bloc de repetiţie

În acest capitol, aţi învățat cum să combinaţi activități, evenimente, și gateway-uri pentru a crea
un model de bază. Pentru fiecare element enumerat, am arătat care este reprezentarea grafică,
am introdus regulile pentru combinarea cu alte elemente de modelare și am explicat
comportamentul în termeni de reguli simbolice. Toate aceste aspecte se încadrează în termenul
generic de „componente ale unui limbaj de modelare”.
Exerciţii recapitulative:
2.1. Creați un model BPMN pe baza următoarei descrieri: Odată ce o cerere de împrumut este
primită de către o bancă, și înainte de a începe evaluarea ei, cererea trebuie să fie verificată dacă
a fost completată corect. În cazul în care cererea este incompletă/incorect completată, acesta
este returnată solicitantului. Acesta poate completa informațiile lipsă și trimite înapoi cererea la
bancă. Acest proces se repetă până când se constată că cererea este completată corespunzător.
2.2. Creaţi un model BPMN pe baza următoarei descrieri: O cerere de împrumut este aprobată
dacă trece două controale: (i) de evaluare a riscului de credit al solicitantului, realizată automat
de către un sistem, și (ii) evaluarea proprietății pentru care împrumutul a fost solicitat, efectuată
de către un evaluator. Evaluarea riscurilor necesită o verificare a istoricului de creditare a
solicitantului, care este efectuată de către un ofițer financiar. După ce atât evaluarea riscului de
credit cât și evaluarea bunurilor au fost efectuate, un ofițer de credit poate evalua eligibilitatea
solicitantului. În cazul în care solicitantul nu este eligibil, cererea este respinsă, în caz contrar
documentele de credit sunt pregătite și transmise solicitantului.
 Capitol 3: Perspectiva de date a modelelor de procese

După cum am arătat în capitolul precedent, un proces de afaceri presupune diferite

aspecte organizaționale cum ar fi funcții, artefacte de afaceri, oameni, și sisteme software. Aceste
aspecte sunt capturate de perspective diferite de modelare a proceselor. Până acum am văzut
punct de vedere funcțional, care indică ce activități ar trebui să se întâmple în acest proces, și
perspectiva control-flow, care indică ordinea în care activitățile și evenimentele ar trebui să
apară. Un alt punct de vedere important care ar trebui luat în considerare atunci când se
modelează procesele de afaceri este perspectiva de date. Perspectiva de date indică ce artefacte
de date (de exemplu elemente de date, documente, baze de date, etc.) sunt necesare pentru a
efectua o activitate și cele care sunt produse ca urmare a efectuării unei activități.
Să îmbogățim procesul de onorare a comenzilor de la exemplul 3.6 cu artefacte de date.
Se începe prin identificarea artefactele pe care fiecare activitate le necesită pentru a putea fi
executată, și cele care fiecare activitate le creează ca urmare a executării sale. De exemplu, prima
activitate a procesului de onorare a comenzilor este "Consultați stocurile disponibile". Acest lucru
necesită un datele existente într-un document ‚comandă de cumpărare’ ca intrare, în scopul de
a afla care produsul comandat si a putea verifica dacă este în stoc sau nu este. Același artefact
(comanda de cumpărare) este cerută și de activitatea "Verifică disponibilitatea materiilor prime"
pentru a verifica dacă produsul solicita de client trebuie produs sau este deja fabricat.
Artefactele, cum ar fi comanda de cumpărare, sunt numite obiecte de date în BPMN. Obiectele
de date reprezintă informații care ‚curg’ în și din activități. Ele pot fi artefacte fizice, cum ar fi o
factură sau o scrisoare pe o bucată de hârtie, sau artefacte electronice, cum ar fi un e-mail sau
un fișier. Le reprezentăm grafic într-un model BPMN ca un document cu colțul din dreapta-sus
pliat, și le legăm la activități cu o linie punctată terminată cu un vârf de săgeată deschis (aceasta
este numită ‚asociație de date’ în BPMN). Figura 13 prezinta un model în care obiectele de date
sunt implicate în realizarea procesului.
Se folosește direcția asociației de date pentru a stabili dacă un obiect de date este o
intrare sau o ieșire pentru o anumită activitate. O asociație de intrare, cum ar fi cea care leagă
obiectul de date „Purchase Order” de activitatea "Check stock availability" indică faptul că o
comandă de cumpărare este obligatorie pentru a putea realiza această activitate. O asociație de
ieșire, cum ar fi cea care leagă obiectul de date „Raw materials” de activitatea "Obtain raw
materials from supplier 1", indică că o listă a materiilor prime este creată în urma executării
acestei activități. Pentru a evita aglomerarea modelului BPMN cu asocieri de date care să
întretaie arcele care modelează ordinea activităților, am putea repeta un obiect de date de mai
multe ori în cadrul aceluiași model de proces. De aceea, convenția este că toate aparițiile unui
anumit obiect se referă conceptual la același artefact. De exemplu, în Figura 13 „Purchase Order”
se repetă de două ori ca intrare pentru "Check stock availability" și "Confirm Order" deoarece
aceste două activități sunt departe una de alta în modelul.
 Fig. 13 – Modelul de onorare a unei comenzi, îmbogăţit cu perspectiva de date

Adesea datele produse într-o activitate coincid cu cele de care e nevoie ca intrare într-o activitate
ulterioară. De exemplu, odată ce au fost obținute Materii prime (obiectul de date „Raw
materials”), acestea sunt folosite de activitatea "Manufacture product", pentru a crea un produs.
Produsele, la rândul lor, sunt ambalate și trimise clientului în cadrul activității "Ship product". În
mod eficient, obiecte de date ne permit să modelăm fluxul de informații între activitățile din
proces. Țineți minte, cu toate acestea, că obiecte de date și asociațiile acestora cu activități nu
pot înlocui secvența de flux a activităților. Cu alte cuvinte, chiar dacă un obiect este trecut de la
o activitate la A la o activitate B, avem încă nevoie pentru a modela secvența de activități A -> B.
O notație prescurtată pentru trecerea unui obiect dintr-o activitate în alta este prin conectarea
directă a obiectelor de date direct cu arcul care reprezintă fluxul de secvență între două activități
consecutive, printr-o asociație neorientată. A se vedea, de exemplu, modul în care e modelată
asocierea obiectului de date „Shipment address” cu arcul care unește activitățile "Get shipment
address" și "Ship product". Aceasta este o prescurtare care indică faptul că adresa de expediere
este o ieșire a activității "Get shipment address" și o intrare a activității „Ship product".
Uneori, am putea avea nevoie să reprezentăm starea unui obiect de date. De exemplu,
activitatea de confirmare a comenzii "Confirm order" are un ordin de cumpărare ca intrare, și
returnează tot un ordin de cumpărare dar în starea ‚confirmat’. În mod similar, activitatea
"Receive payment" are ca intrare tot o comandă de cumpărare ‚confirmată’ și o transformă într-
una ‚plătită’. Un obiect poate trece printr-o serie de stări. De exemplu, o factură este prima dată
"deschisă", apoi "aprobată" sau "respinsă" și în final "arhivată". Indicarea stării obiectelor de date
este opțională. Putem face acest lucru prin adăugarea numele stării între paranteze pătrate, de
exemplu, "Comandă [confirmată]", "produs [ambalat]".
Un depozit de date este un loc care conține obiecte de date care trebuie să fie persistente
(să existe si după ce o instanță a procesului s-a finalizat). De exemplu, o bază de date pentru date
electronice sau un dulap de arhivare pentru cele fizice. Activitățile din proces pot citi/scrie
obiecte de date din/în baze de date. De exemplu, activitatea "Verificați disponibilitate stoc" preia
valoarea stocului pentru produsul comandat de la baza de date, care conține informații cu
valoarea stocurilor pentru diverse produse. În mod similar, activitatea "Verifică disponibilitate
materii prime", consultă catalogul de furnizori pentru a returna care furnizor trebuie contactat.
Baza de date Warehouse DB sau Supplier Catalog sunt exemple de baze de date în care se
stochează date produse de activități. Un exemplu de depozit de date folosit ca ieșire este baza
de date Orders BD, care este utilizată de activitate "Archive order" pentru a stoca comanda de
cumpărare confirmată. Bazele de date sunt reprezentate ca un cilindru gol (simbolul tipic pentru
o bază de date), cu marginea de sus triplă. Similar cu obiectele de date, acestea sunt conectate
la activități prin intermediul asociațiilor de date.
Întrebare: Afectează perspectiva de date secvenţa de execuţie a activităţilor?
Obiectele de date de intrare sunt necesare pentru o activitate care urmează să fie executată.
Chiar dacă un token este disponibil pe arcul de intrare a acestei activități, ea nu poate fi executată
până când toate obiectele de date de intrare sunt de asemenea disponibile. Un obiect de date
este disponibil în cazul în care acesta a fost creat ca urmare a finalizării unei activități anterioare,
sau pentru că este o intrare a întregului proces (cum ar fi ordinul de cumpărare în exemplu de
mai sus).
Întrebare: Trebuie întotdeauna modelată perspectiva de date?
Obiectele de date ajută cititorul să înțeleagă fluxul de date de la o activitate la alta. Cu toate
acestea, prețul includerii perspectivei de date în model este o complexitate crescută a diagramei.
Astfel, vă sugerăm să le folosiți numai atunci când acestea sunt necesare pentru un anumit scop,
de exemplu, pentru a evidenția potențialele probleme în procesul de analizat sau pentru
automatizare. Uneori, am putea avea nevoie să furnizăm informații suplimentare pentru cititor,
în scopul îmbunătățirii înțelegerii modelului. De exemplu, în procesul de onorare a comenzilor
am putea dori să precizăm că activitatea de expediere a produselor "Ship product" include
ambalarea produsului.
De asemenea, ne-am putea dori să clarificăm ce regulă de afaceri este urmată în cazul
alegerii de materii prime de la furnizori. Astfel de informații suplimentare pot fi furnizate prin
intermediul adnotărilor textuale. O adnotare este desenată ca un dreptunghi deschis care
conține un text, și care este legat de un element al modelului printr-o linie punctată (denumită
tot asociere) - vezi Fig. 13 pentru un exemplu. Adnotări de text nu poartă nici o semantică, prin
urmare, ele nu afectează fluxul de token-uri prin modelul de proces.

Exerciţii recapitulative:
3.1. Alăturaţi cele patru fragmente de modele de proces create la problemele anterioare pentru
a constitui perspectiva completă asupra procesului de evaluare a unei cereri de creditare.
Sugestie: examinaţi cu atenţie evenimentele start şi stop ale fragmentelor, pentru a putea
determina modul în care acestea se leagă între ele.
3.2. Îmbogăţiţi modelul creat la problema anterioară cu perspectiva de date, conform
cunoştinţelor voastre generale legate de acest domeniu.
 Capitol 4: Perspectiva resurselor unui proces de afaceri

Un alt aspect, care trebuie luat în considerare atunci când se modelează procesele de
afaceri este perspectiva resurselor. Această perspectivă, numită, și perspectivă organizațională,
indică cine sau ce desfășoară o activitate din proces. ‚Resursă’ este un termen generic pentru a
ne referi la cineva sau ceva implicat în executare unei activități din proces. O resursă poate fi:
• Un participant la proces, adică o persoană fizică cum ar fi angajatul John Smith.
• Un sistem software, de exemplu, un server sau o aplicație software.
• Un echipament, cum ar fi o imprimantă sau o instalație de fabricare.
Există resurse active, adică resurse care pot autonom să execute o activitate, și resurse
pasive, adică resurse care sunt doar implicate în desfășurarea unei activități. De exemplu, un
fotocopiator este utilizat de un contabil pentru a face o copie unui document, dar contabilul este
cel care efectuează activitatea de copiere. Deci, fotocopiator este o resursă pasivă în timp ce
contabilul este o resursă activă. Un buldozer este un alt exemplu al unei resurse pasive, deoarece
șoferul desfășoară activitatea de demolare.
Perspectiva de resurse a unui proces este interesată de modelarea resurselor active, deci
vom folosi termenul "resursa" pentru a ne referi la o "resursă activă". Frecvent, într-un model de
proces nu ne referim în mod explicit la o singură resursă, cum ar fi de exemplu un angajat John
Smith, ci ne referim la un grup de resurse, de exemplu contabil, care conține indivizi care sunt
interschimbabili, în sensul că orice membru al grupului poate realiza o anumită activitate. Astfel
de grupuri sunt numite clase de resurse. Exemple sunt o organizație întreagă, o unitate
organizațională sau un rol/funcție îndeplinit/ă de angajați.
Exemplul 8: Procesul de onorare a comenzilor este efectuat de către organizația
vânzătoare, care include două departamente: departamentul de vânzări; și departamentul de
depozitare și distribuție. Comanda de achiziție este primită de departamentul de depozitare și
de distribuție, unde este și realizată verificarea stocului. Această operațiune este efectuată în
mod automat de către un sistem ERP care interoghează baza de date a depozitului. În cazul în
care produsul este în stoc, acesta este preluat din depozit înainte ca departamentul de vânzări
să confirme comanda. După care, departamentul de vânzări emite o factură și așteptată
încasarea. În același timp, produsul este livrat de departamentul de depozitare și distribuție.
Procesul se termină prin arhivarea comenzii în departamentul de vânzări. În cazul în care
produsul nu este în stoc, sistemul ERP al departamentului de depozitare și distribuție verifică
disponibilitatea materiilor prime prin accesarea catalogului de furnizori. Odată ce materiile prime
au fost obținute, departamentul de depozitare și distribuție realizează fabricarea produsului.
Procesul se termină cu confirmarea comenzii de achiziție și arhivarea acesteia de către
departamentul de vânzări.
BPMN conține două elemente pentru modelarea resurselor: ‚pools’ (piscine) și ‚swimlanes’ (benzi
de înot). Pool-urile sunt în general folosite pentru a modela clase de resurse, swimlane-urile sunt
utilizate pentru a împărți un pool în sub-clase sau resurse unice. Nu există restricții cu privire la
resursele specifice pe care un pool sau un swimlane ar trebui să le modeleze. Se folosește, de
obicei, un pool pentru a modela o afacere parte ca o organizație întreagă (cum ar fi vânzătorul în
exemplul nostru), și un swimlane pentru a modela un departament, unitate, echipa sau sistem
software/echipament în cadrul acestei organizații. În exemplul nostru, am împărți pool-ul firmei
vânzătoare în două swimlane-uri: una pentru departamentul de depozitare si distribuție, cealaltă
pentru departamentul de vânzări.
Swimlane-urile pot fi imbricate una în alta în mai multe niveluri. De exemplu, dacă e
nevoie să modelăm atât un departament cât și rolurile în acest departament, putem folosi un
swimlane exterior pentru departament, și un swimlane interior pentru fiecare rol din cadrul
respectivului departament. În exemplul de mai sus, am inclus în swimlane-ul Warehouse &
Distribution un alt swimlane pentru a reprezenta Sistemul ERP din acest departament.
Pool-urile și swimlane-urile sunt descrise ca dreptunghiuri în care putem plasa activități,
evenimente, gateway-uri, precum și obiecte de date. De obicei, se modelează aceste
dreptunghiuri orizontal, deși modelarea lor pe verticală este de asemenea posibilă. Numele pool-
ului/ swimlane-ului este afișat vertical în partea stângă a unui dreptunghi orizontal (sau orizontal
în cazul în care piscina / banda este verticală), pentru pool-uri, și pentru swimlane-uri care conțin
swimlane-uri imbricate, numele este închis într-o formație. Figura 14 prezinta exemplul de
onorare a unei comenzi de achiziție în care este modelată și perspectiva de resurse.

Fig. 14 – Modelul procesului de onorare a unei comenzi care include secvenţa activităţilor si perspectiva resurselor
 Este important ca fiecare activitate să fie plasată în interiorul swimlane-ului corect. De
exemplu, am plasat Activitatea "Verifică disponibilitate stoc", în swimlane-ul Sistem-ului ERP din
Departamentul Warehouse & Distribution pentru a indica faptul că această activitate se
realizează automat de acest sistem. De asemenea, este important să se plaseze evenimentele în
mod corespunzător în cadrul swimlane-urilor. În exemplul nostru am plasat evenimentul "Ordin
cumpărare primit" în swimlane-ul sistemului ERP pentru a indică faptul că procesul începe în
sistemul ERP din Departamentul Warehouse & Distribution. De asemenea. am plasat
evenimentul "Comandă finalziată" în pool-ul Departamentului de vânzări pentru a indica faptul
că procesul de finalizează în acest departament. Nu are importanță în ce swimlane sunt plasate
obiectele de date, deoarece ele depind de activitățile de care sunt și nu au un executor. În cazul
gateway-urilor, trebuie să plasăm (X)OR-split-urile în același swimlane ca și activitatea de decizie
imediat precedentă. Pe de altă parte, un gateway AND–split poate fi plasat în orice swimlane,
deoarece aceste elemente sunt pasive (în sensul că ele se comportă în funcție de contextul lor).
Se pot organiza swimlane-uri într-un pool sub forma unei matrice în cazul în care avem
nevoie să modelăm structuri organizaționale complexe. De exemplu, dacă avem o organizație în
care rolurile cuprind diferite departamente, am putea folosi swimlane-uri orizontale pentru a le
modela. Dar, am putea folosi și swimlane-uri verticale pentru a modela rolurile în cadrul acestor
departamente. Țineți minte, totuși, că în BPMN fiecare activitate poate fi efectuată de către o
singură resursă. Astfel, în cazul în care o activitate se află în intersecția unui swimlane orizontal
cu un swimlane vertical, ea va fi efectuată prin resursa care îndeplinește caracteristicile ambelor
swimlane-uri, de exemplu, o resursă care are rolul respectiv dar și aparține acelui departament.
Deseori, există mai mult părți implicate într-un proces de afaceri. De exemplu, în procesul
de onorare a comenzilor, există patru părți: vânzătorul, clientul și cei doi furnizori ai vânzătorului.
Fiecare parte poate fi modelată printr-un pool. În exemplul nostru, putem folosi, astfel, un pool
pentru client, unul pentru vânzător și unul pentru fiecare furnizor. Fiecare dintre aceste pool-uri
va conține activități, evenimente, gateway-uri, precum și obiectele de date care modelează
respectiva organizație. Sau altfel spus, fiecare pool va modela același proces de afaceri din
punctul de vedere al unei anumite organizații. De exemplu, evenimentul "Ordin cumpărare
primit", care se află în pool-ul Vânzătorului, va avea o activitate corespunzătoare "Trimite ordin
de cumpărare", care se află în pool-ul Clientului. În mod similar, activitatea de "Experiază produs"
din pool-ul Vânzătorului vor avea în contrapartidă activitatea "Primește produs" în pool-ul
clientului. Deci, cum putem modela interacțiunile dintre pool-urile a două organizații care
colaborează? Nu putem folosi un flux de secvență pentru a conecta activități care aparțin
diferitelor pool-uri deoarece secvența flux nu poate trece granița unui pool. Pentru aceasta,
avem nevoie să utilizăm un element specific numit flux de mesaje.
Un flux de mesaje reprezintă fluxul de informații între două clase de resurse separate
(pool-uri). Acesta este descris ca o linie întreruptă, care începe cu un cerc gol și se termină cu un
vârf de săgeată gol, și poartă o etichetă care indică conținutul mesajului (de exemplu un fax, o
comandă de cumpărare, dar, de asemenea, o scrisoare sau un apel telefonic). Adică, fluxul de
mesaje modelează curgerea oricărui tip de comunicare între cele două organizații, nu contează
dacă acest lucru este electronic (cum ar fi trimiterea unui ordin de cumpărare prin e-mail sau
transmiterea unui fax), sau manual (efectuarea unui apel telefonic sau predarea unei scrisori pe
hârtie).
Figura 15 prezinta modelul complet pentru onorarea unei comenzi de cumpărare, inclusiv
pool-uri pentru client și cei doi furnizori. Aici putem vedea că fluxurile mesaj sunt etichetate
informațiile pe care le transmit (de exemplu, "Materii prime" sau "Expediere adresa". Un flux de
mesaje de intrare poate conduce la crearea unui obiect de date de către activitatea care primește
mesajul. De exemplu, mesajul "Materii prime" este primit de activitate "Obținerea de materii
prime de la Furnizor 1", care apoi creează obiectul de date "Materii prime". Acesta este și cazul
comenzii de cumpărare, care este generat de evenimentul de start "Comandă de cumpărare
primită" din conținutul fluxului de mesaje primite. Nu e nevoie să creați un obiect de date pentru
fiecare flux de mesaje recepționat, numai atunci când informațiile vehiculate prin mesaj sunt
necesare în altă parte în proces. În cazul nostru, obiectul de date "materii prime", este consumat
de activitate "Fabricare produse". În mod similar, nu avem nevoie să reprezentăm în mod explicit
obiectul de date folosit într-un mesaj de ieșire, dacă acest obiect de date nu este necesar în altă
parte în proces. De exemplu, activitatea "Emite factură" generează o factură care este trimisă
clientului, dar nu este modelat nici un obiect de date "factură", deoarece acesta nu este
consumat de către o altă activitate în pool-ul Vânzătorului.
O diagramă BPMN care dispune de două sau mai multe pool-uri poate fi numită și
diagramă de colaborare. Figura 15 arată diferite utilizări ale unui pool într-o diagramă de
colaborare. Un pool (cum ar fi cel al Vânzătorului) se numește proces privat, sau ‚white box pool’,
din moment ce arată cum organizația vânzătorului participă efectiv la procesul de onorare a
comenzilor în ceea ce privește activitățile, evenimentele, gateway-urile, precum și obiectele de
date. Dimpotrivă, un pool cum este cel al clientului sau cele ale celor doi furnizori se numește
proces public, sau ‚black box pool’, deoarece ascunde modul în care aceste organizații participă
efectiv în onorarea comenzilor. Pentru a economisi spațiu, putem reprezenta un proces public
printr-un dreptunghi gol care poartă numele la mijloc.
Întrebare: Black-box (proces public) sau White-box (proces privat)?
Modelarea unui pool ca un proces public sau unul privat este o chestiune de relevanță.
Când se modelează o diagramă de colaborare, o organizație poate decide dacă își expune sau nu
comportamentul ei intern, în funcție de cerințele proiectului. De exemplu, dacă modelăm
procesului de onorare a comenzilor din perspectiva vânzătorului, ar putea fi relevant să expunem
procesul de afaceri doar al vânzătorului, dar nu și cel al clientului și furnizorilor. Adică,
comportamentul intern al clientului și cel al furnizorilor nu sunt relevante pentru înțelegerea
modul în care vânzătorul ar trebui să onoreze comenzile de cumpărare, și, ca atare, acestea pot
fi ascunse. Pe de altă parte, în cazul în care avem nevoie să îmbunătățim modul în care vânzătorul
își onorează comenzile de cumpărare, ne-ar putea interesa, de asemenea, ce trebuie să facă un
furnizor să livreze materii prime, pentru că o întârziere în furnizarea de materii prime va încetini
fabricarea produselor în organizația vânzătorului. În acest caz, ar trebui să reprezentăm, de
asemenea, furnizorii, folosind procese private.
Tipul de pool afectează modul în care folosim fluxul de mesaje pentru a ne conecta la
pool. Un mesaj poate trece granița unui pool ‚white box’ și se poate conecta direct la o activitate
sau un eveniment în cadrul acestui pool. De exemplu, mesajul prin care se transmite comanda
de cumpărare se termină la evenimentul de start în pool-ul Vânzător. Pe de altă parte, deoarece
un pool black-box este gol, fluxurile de mesaje trebuie să se oprească la graniță sau să pornească
de la aceasta. Țineți cont de faptul că un flux de mesaje este utilizat doar pentru a conecta două
pool-uri și nu pentru a conecta două activități în același pool (în acest caz folosim o săgeată care
indică secvența).
O activitate care este sursa unui mesaj, cum ar fi "Emite factură" din pool-ul Vânzător se
numește o activitate de trimitere. Mesajul este trimis la finalizarea execuției activității. Pe de altă
parte, o activitate care primește un mesaj - cum ar fi "Preia adresa de livrare" este activitate
receptor. Execuția unei astfel de activități nu va fi începe până când mesajul de intrare nu a fost
primit. O activitate poate atât să primească dar și să trimită mesaje, atunci când aceasta are atât
un flux de mesaje de intrare cât și unul de ieșire (de exemplu, "Plătește factura"). Executarea
acestei activități va începe atunci când atât tokenul aferent fluxului de control cât și mesajul de
intrare este receptat. La finalizarea activității, un token va fi trimis de-a lungul arcului de ieșire
dar și mesajul va fi trimis. În cele din urmă, atunci când un flux de mesaje este receptat de un
eveniment de start (ca și "Comandă de cumpărare primită") acest eveniment va fi marcat cu un
plic deschis (vezi Fig. 15). Acest tip de eveniment este numit eveniment mesaj. Un eveniment
mesaj poate fi legat la un obiect de date, modelându-se astfel stocarea conținutului mesajului de
intrare.

Fig. 15 – Modelul procesului de onorare a unei comenzi care include şi colaborarea (mesajele) între vânzător, cumpărător şi doi furnizori
 În exemplul de onorare a comenzilor am folosit pool-uri pentru a reprezenta părțile
implicate într-un proces de afaceri și swimlane-uri pentru a reprezenta departamentele și
sistemele în cadrul organizației vânzătorului. Am ales acest mode de modelare pentru că am vrut
să ne concentrăm asupra interacțiunilor dintre vânzător, client și cei doi furnizori. Așa cum am
menționat mai înainte, astfel se utilizează în mod tipic pool-urile și swimlane-urile. Cu toate
acestea, din moment ce BPMN nu prescrie ce tipuri de resurse ar trebui să fie asociate cu pool-
urile și swimlane-urile, am putea folosi aceste elemente diferit. De exemplu, în cazul în care se
pune accent pe interacțiunile dintre departamente ale unei organizații, putem modela fiecare
departament ca un pool, și putem folosi swimlane-urile pentru a detalia resursele din cadrul
fiecărui departament (de exemplu, în unități sau roluri). În orice caz, ar trebui să evităm să folosim
pool-urile și swimlane-urile pentru a modela participanții cu numele lor (deoarece persoanele
tind să se schimbe frecvent în cadrul unei organizații), și mai degrabă ar trebui să folosim rolul
participantului (de exemplu, funcționar financiar). Pe de altă parte, putem folosi pool-urile și
swimlane-urile pentru a reprezenta software-ul specific, sisteme sau echipamente (de exemplu,
un sistem ERP), deoarece acestea schimba mai rar într-o organizație.
Exerciţii recapitulative:
4.6. Extindeţi modelul de proces aferent evaluării unei cereri de acordare a unui credit prin
adăugarea perspectivei resurselor pe baza următoarei descrieri:
„Procesul de evaluare a cererilor de credit este executat de patru roluri din cadrul unei bănci: un
funcționar financiar verifică istoricul de credit al solicitantului, un evaluator de proprietăți este
responsabil pentru evaluarea garanțiilor imobiliare, un funcționar de la departamentul asigurări
trimite solicitantului oferta de asigurare în cazul în care acest lucru este necesar. Toate celelalte
activități sunt efectuate de către consultantul de credite, care este principalul punct de contact
cu solicitantul.”
4.7. Extindeţi modelul de proces de la exerciţiul precedent prin modelarea interacţiunii
(schimbului de mesaje) între bancă şi client.
 Bibliografie curs

1. Dumas, M., La Rosa, M., Mendling, J., Reijers, H.A., Fundamentals of Business Process
Management, Springer, Berlin, 2013
2. Grosskopf, A., Decker, G., Weske, M., The process: business process modeling using
BPMN, Meghan Kiffer Press, 2009
3. Havey, M., Essential business process modeling, O'Reilly Media, Incorporated, 2005
4. Weske, M., Business Process Management: Concepts, Languages, Architectures, Springer,
Berlin, 2012
5. Wohed, P., van der Aalst, W.M.P., Dumas, M. and terHofstede, A.H.M., Pattern-based
Analysis of BPMN-An extensive evaluation of the Control-flow, the Data and the Resource
Perspectives, BPM Center Report BPM-05-26, 2005
6. *** Lucrări științifice jBoss, http://www.jboss.org/research/papers/
7. *** Documentație online Optaplanner,
https://docs.optaplanner.org/7.6.0.Final/optaplannerdocs/html_single/index.html#whatIsOpta
Planner
8. *** Documentație online jBPM, https://docs.jboss.org/jbpm/release/7.6.0.Final/jbpm-
docs/html_single/
9. *** Documentație online Drools,
https://docs.jboss.org/drools/release/7.6.0.Final/drools-docs/html_single/index.html
10. *** Documentație online Șabloane ale fluxurilor de lucru,
http://www.workflowpatterns.com/
 Recapitulare

La sfârșitul acestui curs, ar trebui să fiţi în măsură să citiţi, să înțelegeţi și să puteţi construi
un model de proces de afaceri folosind elementele de modelare de bază ale BPMN. Elementele
de bază ale unui model de proces BPMN includ: activități simple, evenimente, gateway-uri,
obiecte de date, pool-uri, și swimlane-uri. Activitățile modelează lucrul din cadrul unui proces.
Evenimente definesc începutul și sfârșitul unui proces, și semnalizează dacă ceva ce se întâmplă
în timpul executării sale. Gateway-urile modelează: decizii exclusive sau inclusive urmate de
unirea ramurilor, paralelism urmat de sincronizare, respectiv repetiție.
S-a mai explicat diferența între un model de proces și o instanță a procesului. Un model de proces
descrie toate modurile posibile, prin care un proces de afaceri poate fi executat. Pe de altă parte,
o instanță de proces denotă o execuție specifică a unui proces din toate modurile de execuţie
posibile. Progresul execuţiei, sau starea, unei instanțe de proces este reprezentată de distribuţia
token-urilor în model. Folosind token-uri putem defini comportamentul gateway-urilor.
Aţi mai învățat cum să folosiţi obiectele de date pentru a modela fluxul de informații între
activități și evenimente. Un obiect de date capturează un artefact fizic sau electronic: necesar
pentru a executa o activitate sau a declanșa un eveniment; sau care rezultă din execuția unei
activităţi sau din declanşarea unui eveniment. Obiecte de date pot fi stocate într-un depozit de
date (cum ar fi o bază de date sau dulap fizic) astfel încât să poată fi stocate în afara procesului
în care acestea sunt/au fost create.
De asemenea, aţi văzut că pool-urile și swimlane-urile pot fi folosite pentru a modela atât
resursele umane cât și cele non-umane, care desfășoară activități din proces. Pool-urile sunt clase
de resurse, în general, în timp ce swimlane-urile sunt folosite pentru a împărţi pool-urile în sub-
componente. Interacțiunea dintre pool-uri este modelată prin fluxuri de mesaje. Fluxurile de
mesaje pot fi conectate direct de marginile unui pool, dacă detaliile interacțiunii între
transmiţător şi receptor nu sunt relevante.
Activitățile, evenimentele, gateway-urile, artefactele, și resursele aparțin celor 3
perspective principale de modelare ale unui proces de afaceri. Punctul de vedere funcțional
surprinde activitățile care sunt efectuate într-un proces de afaceri, în timp ce perspectiva control-
flow combina aceste activități și evenimentele conexe stabilind necesitatea desfăşurării acestora
într-o anumită ordine. Perspectiva de date acoperă artefactele create şi manipulate în timpul
execuţiei procesului. Perspectiva de resurse acoperă resursele (umane şi non-umane) care
efectuează diverse activități.

Exerciţii Recapitulative

ER1: Ce fel de tipuri de split-uri şi join-uri pot fi modelate într-un model de proces? Creaţi un
model, bazat pe un exemplu din lumea reală, pentru fiecare din ele.
ER2: Creaţi o descriere textuală a următorului model:

ER3: Modelaţi următorul proces pentru gestionarea avansurilor de la clienţi:

Procesul de gestionare al încasărilor în avans de la clienţi începe atunci când o cerere de plată a
uni avans este considerată necesară. Aceasta implică introducerea cererii de plată în sistemul
ERP al întreprinderii, înregistrarea automată a încasării avansului în evidenţele contabile ale
întreprinderii, emiterea facturii de vânzare și procesarea produselor comandate de client.
Procesarea produselor poate duce la apariţia unor diferenţe de încasat suplimentar sau de
returnat sumele încasate în avans. În caz apariţiei unei restituiri comanda este livrată, altfel se
aşteaptă încasarea soldului rămas neplătit.
ER4: Modelaţi următorul proces pentru evaluarea riscului acordării unui credit:
Atunci când o nouă cerere de credit este primită, riscul presupus de acordarea respectivului
credit este evaluat. Dacă riscul este peste un anumit prag, o evaluare avansată a riscului trebuie
să fie efectuată. Altfel o evaluare simplă a riscurilor este suficientă. Dacă evaluarea a fost
finalizată, clientul este notificat cu rezultatul evaluării, iar între timp plata sumei creditate este
organizată. Pentru simplificare, presupunem că rezultatul unei evaluări este întotdeauna pozitiv.
ER5: Modelaţi următorul proces pentru obţinerea unei despăgubiri de asigurare:
După ce o cerere este înregistrată, acesta este examinată de către un inspector de daune care
scrie apoi o evaluare a pagubelor. Această evalaure este apoi verificată de către un inspector
superior de daune care poate marca cererea ca "OK" sau "Not OK". În cazul în care cererea este
marcat ca "Nu este OK", acesta este trimisă înapoi la inspectorul de daune care trebuie să re-
evalueze pagubele. În cazul în care cererea este "OK", începe procesarea plăţii daunelor.
ER6: Modelaţi următorul proces pentru compensarea daunelor:
În cazul în care un chiriaș este evacuat din cauza daunelor aduse unui imobil, un proces trebuie
să fie inițiat de tribunal, în scopul de a organiza o audiere pentru evaluarea valorii compensației
pe care chiriașul o datorează proprietarului. Acest proces începe atunci când un grefier al
tribunalului primește o cerere pentru despăgubiri de la proprietar. Grefierul scoate din arhiva
imobiliară datele imobilului respectiv și controlează atât dacă cererea este completată acceptabil
pentru depunere, cât și dacă este în conformitate cu datele din arhiva imobiliară. Stabilirea unei
date pentru audiere reclamă plata unor taxe de către proprietar. S-ar putea că proprietarul a
plătit deja taxele odată cu cererea, caz în care casierul stabileşte o data de audiere și procesul se
termină. Dar se poate că sunt necesare costuri suplimentare, iar proprietarul a plătit deja, de
asemenea, aceste taxe. În acest caz, casierul generează o chitanță pentru taxe și venituri
suplimentare şi stabileşte data audierii. În cele din urmă, în cazul în care proprietarul nu are
achitate taxele necesare, casierul emite o notificare de plată și așteaptă ca proprietarul să
plătească taxele înainte de a reevalua conformitatea cererii de despăgubire.
ER7: Poate fi executat în mod corect următorul model? Daca nu, de ce? Cum poate fi corectat
fără a afecta faptul că F, G şi E trebuie să rămână într-o revenire.

ER8: Extindeţi modelul din exercițiul ER6 prin adăugarea perspectivei de date.
ER9: Extindeţi modelul din exerciţiul ER8 prin adăugarea perspectivei resurselor. Există resurse
nonumane?
ER10: Modelaţi următorul proces, din toate cele 3 perspective:
Într-un tribunal, în fiecare dimineață actele aferente cauzelor care nu au fost judecate în ziua
precedentă sunt verificate pentru a se asigura că ele sunt în ordine pentru ședința de judecată
din acea zi. În cazul în care unele documente lipsesc, se iniţiază o căutare. În caz contrar,
documentele sunt duse fizic în sala de judecată. După ce toate documentele sunt gata, acestea
sunt predate către grefier. Între timp ordinea de zi a judecătorului este distribuită persoanelor
implicate în procesele judecate. Ulterior, audierile se desfășoară.
ER11: Modelaţi următorul proces, din toate cele 3 perspective:
Procesul de revendicare a daunelor auto începe atunci când un client depune o cerere cu
documentația relevantă. Departamentul de Relaţii cu Publicul de la asiguratorul auto verifică
documentele pentru conformitatea completării și înregistrează cererea. Următor,
Departamentul de Evaluare a Daunelor preia cererea și verifică asigurarea. Apoi, se face o
evaluare a daunelor fizice. Dacă evaluarea are un rezultat pozitiv, un garaj este sunat pentru
autorizarea reparațiilor și plata este programata (în această ordine). În caz contrar, cererea este
fost respinsă. În orice caz (dacă rezultatul este pozitiv sau negativ), un mesaj este trimis către
client și procesul este considerat încheiat.
ER11: Modelaţi următorul proces, din toate cele 3 perspective:
Atunci când o cerere este primită, un inspector verifică în primul rând dacă solicitantul este
asigurat. Dacă nu, solicitantul este informat că cererea trebuie să fie respinsă prin trimiterea unei
notificări automate prin-un sistem SAP. În caz contrar, un inspector superior evaluează gradul de
severitate al cererii. Bazat pe rezultatul evaluării se clasifică cererile în simple sau complexe, iar
formularele corespunzătoare sunt trimise solicitantului, din nou folosind sistemul SAP. Odată ce
formularele sunt returnate, ele sunt verificate de către inspector. În cazul în care formularele
conţin toate detaliile relevante, cererea este înregistrată în sistemul de management al cererilor
de despăgubire și procesul se termină. În caz contrar, solicitantul este informat că trebuie să
actualizeze formularele prin intermediul sistemului SAP. După primirea formularelor actualizate,
ele sunt verificate din nou, de către inspector pentru a vedea dacă toate detaliile au fost
furnizate, și așa mai departe.