Cap 4.

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 esenial s nelegem de ce este nevoie de modelare.
Modelele pe care le producem vor arata diferit n funcie de motivul pentru care se creeaz modelul,
n primul rnd. Exist multe motive pentru modelarea unui proces. Primul dintre ele este pur i simplu
de a nelege procesul i de a mprti nelegerea noastr cu cei care sunt implicai n procesul
respectiv n viaa de zi cu zi. ntr-adevr, participanii la un proces de obicei efectueaz activiti
detaliate/specializate din respectivul proces, astfel nct acestea nu se confrunt cu complexitatea
ntregului proces. Prin urmare, procesul de modelare i ajut s neleag mai bine procesul n scopul
de a identifica i pentru a preveni problemele de execuie ale acestuia. Acest pas spre o nelegere
aprofundat este prima condiie care trebuie ndeplinit pentru a efectua analize de proces, re-design
sau automatizare.
n acest suport de curs sunt prezentate elementele eseniale necesare familiarizrii cu ingredientele
de baz ale procesului de modelarea folosind limbajul Business Process Modeling Notation (BPMN).
Cu aceste concepte, vei fi capabili s producei modele de procese de afaceri care surprind relaiile
temporale i logice simple, ntre activiti, obiecte, resurse (de ex. angajai), respectiv ntre date. n
primul rnd, vom descrie concepte eseniale legate de modelele de proces, i anume modul n care
modelele de proces se leag de instanele 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, execuia n paralel, deciziile inclusive i repetiiile. n cele din urm, vom acoperi artefactele
de informaii/date respectiv resursele implicat ntr-un proces.
Un limbaj de modelare este format din trei pri: sintaxa, semantica, i notaia. 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 neles clar, fr
ambiguiti. Notaia definete un set de simboluri grafice pentru vizualizarea elementelor. De
exemplu, sintaxa BPMN include activiti, evenimente, gateway-uri, i secvena activitilor. Un
exemplu de reguli sintactice BPMN este faptul c evenimentele de tip start au numai secvene de ieire
n timp ce evenimentele finale au doar secvene 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 privete fluxul de activiti. De exemplu, un element care
denot o sincronizare a unor ramuri paralele ale procesului impune ateptarea pn cnd fiecare din
ramurile de intrare sunt finalizate, nainte de a permite trecerea la ramurile de ieire din acesta. Un
exemplu de notaie BPMN este utilizarea unor dreptunghiuri cu marginile rotunjite pentru a reprezenta
activitile procesului.
n acest suport de curs am prezentat elementele de baz ale procesului de modelare prin limbajul
BPMN. Alte limbaje rspndite care pot fi utilizate pentru a modela procese de afaceri sunt Diagramele
de Activiti 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, construciile de tip OR-join nu sunt acceptate. O bun imagine de ansamblu a acestei limbi i
de aplicarea acesteia de a modelarea procesului de afaceri este prezentat n [1].
Notaia EPC a fost dezvoltat iniial pentru proiectarea proceselor de referin incluse n SAP R/3. A
fost adoptat pe scar larg de ctre diverse organizaii, atunci cnd a devenit limba de modelare de
baz a setului de instrumente ARIS. Mai trziu, au fost utilizate de ctre ali furnizori pentru proiectarea
de modele de referin, independent de SAP, cum ar fi ITIL i SCOR. Notaia EPC include elemente de
modelare corespunztoare activitilor din BPMN, precum i pentru gateway-uri AND, XOR i OR,
respectiv pentru evenimente i obiecte de date. O introducere la EPC este disponibil n [2].
WS - BPEL (BPEL pe scurt), versiunea 2.0, este un standard al Organizaiei pentru Promovarea
Standardelor Referitoare la Informaia Structurat (OASIS). O privire de ansamblu a BPEL este
disponibil n [3]. BPEL este un limbaj de execuie 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 specificaia BPMN. Cu toate acestea, aceast mapare nu este complet deoarece BPEL ofer
un set restrns de construcii 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 corespunztor i nu se pot suprapune. Un bloc este format dintr-un singur nod de
intrare, i un singur nod de ieire (care corespunde cu tipul de nod de intrare i colecteaz toate
ramurile de ieire de la nodul de intrare). De exemplu, n cazul n care nodul de intrare este un ANDsplit, nodul de ieire trebuie s fie un AND-join. Mai mult dect att, BPEL nu este dotat cu un standard
de notaie, din moment ce acest lucru a fost considerat a fi n afara domeniului de aplicare de ctre
OASIS, dei diferiii vnztori ofer notaii proprietare personalizate pentru acest limbaj. n timp ce
BPMN 1.2 a avut scopul de a fi omologul conceptual al BPEL, i maprile 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 reelelor
Petri pentru modelarea proceselor de afaceri. Sintaxa lor este n mod intenionat simpl i se nvrte
n jurul a dou elemente: place-uri i tranziii. Place-urile corespund aproximativ evenimentelor BPMN,
n timp ce tranziiile corespund activitilor BPMN. Un bun prezentare a Workflow Nets este realizat
n [3].
YAWL este un succesor al Workflow Nets, la care se adaug construcii specifice pentru a face posibil
reprezentarea comportamentului OR-join, activitilor multi-instane, sub-proceselor i regiunilor de
anulare. YAWL pstreaz simplitatea i intuitivitatea Workflow Nets, dei ofer un limbaj mult mai
expresiv. YAWL i mediul su de sprijin sunt prezentate n detaliu n [4].
O comparaie dintre limbajele menionate mai sus, n ceea ce privete expresivitatea lor pentru
reprezentarea secvenelor de activiti, a perspectivelor de date i de resurse, pot fi gsite pe websiteul Workflow Patterns [www.workflowpatterns.org]. n timp, aceast iniiativ a colectat un depozit de
abloane de procese observate des n practic i implementate n cadrul unor aplicaii dedicate
modelrii proceselor de afaceri.

4.1. Introducere n Business Process Model and Notation

(BPMN)
Cu peste 100 de simboluri, BPMN este un limbaj destul de complex. Dar numrul mare de simboluri nu
este un motiv de panic, deoarece o mic parte din acestea acoper nevoile de modelare a marii
majoriti a utilizatorilor. Dup ce stpnii acest nucleu de simboluri BPMN, restul elementelor vor fi
nvate natural, din practic. Deci, n loc s descriem n detaliu fiecare simbol BPMN, vom introduce
simbolurile i conceptele BPMN treptat, prin intermediul unor exemple.
Confirma
comanda

Scrie adresa de
expediere

Expediaza
produsul

Emite factura

Incaseaza
factura

Arhiveaza
comanda
Comanda
expediata si
incasata

Fig. 1 Diagrama BPMN a unui proces simplu pentru onorarea unei comenzi de cumprare

n acest capitol, sunt prezentate simbolurile de baz ale BPMN. Un proces de afaceri implic
evenimente i activiti. Evenimentele reprezint lucruri care se ntmpl instantaneu (de exemplu, o
factur a fost primit) n timp ce activitile reprezint uniti de lucru care au o durat (de exemplu,
plata unei facturi). De asemenea, un proces nseamn c evenimentele i activitile sunt n mod logic
legate. Forma cea mai elementar de relaie ntre dou elemente (fie ele evenimente sau activiti)
este secvena, 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, activitile, i arcele.
Evenimentele sunt reprezentate de cercuri, activiti de dreptunghiuri rotunjite, i arcele (numite
fluxuri de secven n BPMN) sunt reprezentate de sgei.
Exemplu 3.1 Fig. 1 prezint modul in care este modelat folosind notaia BPMN o simpl secven de
activiti aferent unei comenzi de cumprare. Acest proces ncepe ori de cte ori un ordin de
cumprare a fost primit de la un client. Prima activitate care se desfoar este confirm comand.
Apoi, este nregistrat adresa de destinaie, astfel nct produsul s poat fi livrat clientului. Ulterior,
factura este emis. Dup ce suma facturii este ncasat, ordinul este arhivat, finalizndu-se astfel
procesul.
Din exemplul de mai sus se observ c cele dou evenimente (de start i de stop) sunt descrise cu dou
simboluri uor diferite. Se folosesc cercuri cu o margine subire 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 cnd instanele procesului ncep, n timp ce evenimentul final indic atunci cnd instana
(denumit i caz) este complet. De exemplu, o nou instan (sau un nou caz) a(l) procesului de
onorare a comenzilor este declanat ori de cte ori o comand de achiziie este primit, i se
finalizeaz atunci cnd comanda este onorat.

Confirma
comanda

Scrie adresa de
expediere

Expediaza
produsul

Emite factura

Incaseaza
factura

Arhiveaza
comanda
Comanda
expediata si
incasata

Fig. 2 Reprezentarea a 3 instane (comenzi) aflate n execuie

S ne imaginm c procesul de onorare a comenzilor este realizat de o firm de distribuie de produse.

n fiecare zi aceast organizaie 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 noiune 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 pn cnd sunt distruse n un eveniment de sfrit. Putem reprezenta
aceste jetoane ca puncte colorate suprapuse peste un model de proces. De exemplu Fig.2 arat starea
de trei instane 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 rou 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 neles s dai un nume (de asemenea numit etichet) fiecrei activiti, nu
trebuie s omitei s etichetai i evenimentele, de asemenea. De exemplu, dnd un nume pentru
fiecare eveniment de pornire ne permite s comunicm ce declaneaz o instan a procesului sau
cnd ar trebui s nceap o nou instan a procesului. n mod similar, dnd o etichet pentru fiecare
eveniment de sfrit putem s comunicm n ce condiie o instan a procesului se finalizeaz, sau care
este rezultatul procesului.
Se recomand urmtoarele convenii de numire. Pentru activiti, 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 ctre 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 aciunea se face (de exemplu, Rennoiete permisul de
conducere). Cu toate acestea, vom ncerca s evitm etichete lungi, deoarece acest lucru poate
ngreuna lizibilitatea modelului. Ca o regul general, vom evita etichete cu mai mult de cinci cuvinte
(cu excepia prepoziiilor i conjunciilor). 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
ntmplat. Similar cu etichetele activitilor, substantivul poate fi precedat sau urmat de un adjectiv
(de exemplu, Comand urgent trimis). Se vor capitaliza (scrie cu litere mari) primul cuvnt al
etichetei att pentru activiti ct i pentru evenimente.
Verbe generale, cum ar fi "a face", "a efectua" sau "a realiza" ar trebui s fie nlocuit cu verbe
semnificative care s surprind specificul activitii efectuate sau evenimentului care are loc. Cuvinte
ca "proces" sau "comand" sunt, de asemenea, ambiguu n ceea ce privete partea lor de exprimare.
Ambele pot fi folosite ca verb ("a procesa", "a comanda") i ca substantiv ("un proces", "o comand").

V recomandm s folosii 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
obinut prin nominalizarea verbului care descrie aciunea principal a unui proces de afaceri (de
exemplu, "Onoreaz comand" (aciunea principal) devine "onorare comenzi" (numele procesului).
Substantivele compuse din mai multe cuvinte, cum ar fi "comand-la-ncasare" i "achiziie-la-plat",
indicnd secvenele de aciuni principale ale procesului, sunt de asemenea admise. Nu se capitalizeaz
primul cuvnt dintr-un nume de proces.
Aplicnd conveniile de denumire prezentate mai sus modele construite vor fi unitare i consistente,
fiind astfel mai uor de neles n cazul comunicrii cu alte persoane i mai uor de reutilizat.
Exemplul din Fig. 1 reprezint un posibil mod de a modela procesul de onorare a comenzilor. Cu toate
acestea, pot fi uor produse modele destul de diferite care s descrie acelai proces real. De exemplu,
am putea fi neglijat anumite activiti sau extins altele, n funcie de intenia specific de modelare.
Sub-seciunea Mic introducere n teoria modelrii" reflect pe proprietile care stau la baza un
model n general i se refer i la cazul specific al modelelor de procese.
Opional: Mic introducere n teoria modelrii
Un model este caracterizat prin trei proprieti: reprezentativitate, abstractizare, i adaptarea la scop.
n primul rnd, un model presupune reprezentarea unui fenomen din lumea real subiectul
modelrii/modelului. De exemplu, o cldire rezidenial care urmeaz s fie construit ar putea fi
modelat printr-o miniatur de lemn. n al doilea rnd, 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 cldirii abstractizeaz n mod clar de la materialele din
care va fi construit cldirea. n al treilea rnd, un model servete unui obiectiv bine determinat, care
influeneaz alegerea aspectelor realitii care se omit atunci cnd se creeaz un model. Fr un scop
specific, nu am avea nici o indicaie asupra a ceea ce trebuie s se omit. Gndii-v din nou la modelul
de lemn. Acesta servete scopului de a ilustra modul n care cldirea 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 cldirii. Deci, putem spune c modelul este un mijloc de a abstractiza pe
baza subiect real, cu intenia de a captura doar cteva dintre aspecte eseniale ale acestuia.
O modalitate de a determina scopul unui model este de nelege publicul int al modelului. n cazul
modelului de lemn, publicul int ar putea fi un potenial cumprtor al cldirii. Astfel, modelarea este
important s se concentreze pe aspectul cldirii, nu pe aspectele tehnice ale construciei. 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 hrtie al cldirii ar fi mai potrivit. Astfel, atunci cnd 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
organizaiei respectiv proiectarea sistemului informaional al companiei. Modele de procese de
management al organizaiei sunt orientate spre afaceri. Acestea sunt construite de ctre analitii de
afaceri i utilizate n principal pentru nelegere i comunicare n rndul conducerii si angajailor, dar i
pentru msurarea i mbuntirea activitilor. Ca atare, ele trebuie s fie suficient de intuitive pentru

a fi nelese de ctre diverse pri interesate, i va abstractiza de obicei, aspectele legate de IT. Publicul
int include manageri, executani ai activitilor din procese i analiti de afaceri. Modele de procese
pentru proiectarea sistemului informaional al organizaiei sunt orientate spre construirea de
software. Acestea sunt construite de ctre ingineri i dezvoltatori de sisteme informatice, i folosite
pentru automatizarea activitilor realizate n organizaie. Astfel, modelele trebuie s conin 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

4.2. Ramificarea i unirea cilor de execuie ale unui proces

Activitile i evenimente nu pot fi (nu trebuie s fie) neaprat executate secvenial. De exemplu, n
contextul unui proces de procesare a unei cereri, aprobarea i respingerea cererii sunt dou activiti
care se exclud reciproc. Deci, aceste activiti nu pot fi efectuate n secven, deoarece intr-o execuie
(o instan) a acestui proces se va efectua doar una din aceste dou activiti. Atunci cnd dou sau
mai multe activiti sunt alternative care pot fi alese n urma unei decizii, le numim mutual exclusive.
S lum n considerare o alt situaie. 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 activiti care sunt de obicei efectuate de ctre dou resurse diferite ale
organizaiei (de ex. dou persoane diferite cum ar fi secretar i casier), prin urmare, ele sunt
independente una de alta. Ca urmare, cele dou activiti nu trebuie s fie efectuate n secven, ele
putnd fi efectuate n paralel, n acelai timp. Atunci cnd dou sau mai multe activiti nu sunt
interdependente, spunem c ele sunt concurente (se realizeaz n paralel).
Pentru a modela aceste comportamente trebuie s introducem noiunea de portal (n englez
gateway). Termenul gateway implic faptul c exist un mecanism de control al fluxului de activiti,
care permite sau nu permite trecerea de token-uri. Cnd token-urile ajung la un gateway, ele pot fi
fuzionate la intrare, sau clonate la ieire, n funcie 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 execuie. Un gateway de tip split reprezint un punct n care fluxul
de activiti al procesului trebuie sau se poate mpri pe mai multe ramuri (procesul diverge din acel
gateway). Un gateway de tip join reprezint un punct n care fluxul de activiti al procesului provenind
de pe mai multe ramuri se unete (procesul converge n acel gateway). Split-urile au un singur arc de
intrare i mai multe arce de ieire (reprezentnd ramurile divergente). Join-urile au mai multe arce de
intrare (reprezentnd ramuri convergente) i un singur arc de ieire.

4.2.1. Deciziile exclusive

Pentru a modela relaia dintre dou sau mai multe activiti alternative, cum ar fi n cazul aprobrii sau
respingerii unei cereri, se folosete un gateway de tip split exclusiv (denumit i XOR-split). Se folosete
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 conine 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 ctre
un client, aceasta trebuie s fie verificat pentru conformitate/nepotriviri. Verificarea poate duce la
oricare dintre aceste trei opiuni: 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 activiti este efectuat, factura este ndosariat i procesul
se termin.
Pentru a modela procesule din Exemplul 2, vom ncepe prin a modela un eveniment declanator (de
start) etichetat "primire notificare de emitere factura". Urmeaz o activitate de decizie, i anume
"Verificai 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 bifurcaie care trimite fluxul
de activiti n una din cele trei ramuri. Prin urmare, trei arce vor iei din acest gateway, unul care duce
la activitatea "Trimite factura" (activat n cazul n care nu exist neconcordane), altul spre activitatea
"Re-trimite factura la client " (activat n cazul n care exist neconcordane, dar pot fi corectate), i un
al treilea arc spre activitatea "Blocheaz factura" (activat n cazul n care exist neconcordane 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 ieire (adic doar o ramur de ieire din gateway poate fi activat).
Atunci cnd se utilizeaz un XOR-split, asigurai-v c fiecare arc de ieire este adnotat cu o etichet
care specific condiia care trebuie s fie ndeplinit pentru ca ramur respectiv s fie activat. Mai
mult dect att, folosii ntotdeauna condiii care se exclud reciproc, adic doar una dintre ele poate fi
adevrat de fiecare dat cnd XOR-split este atins de un token. Aceasta este caracteristica principal
a unui XOR-split. n exemplul nostru, o factur poate fi corect, sau conine nepotriviri care pot fi
corectate, sau poate conine nepotriviri care nu pot fi corectate; i numai una dintre aceste trei condiii
este adevrat pentru orice factur emis.
n Fig. 3 arcul etichetat "exist nepotriviri, dar nu pot fi corectate" este marcat cu o linie oblic. Aceast
notaie este opional i este folosit pentru a indica arcul implicit, adic arcul care va fi folosit de ctre

token-urile care ajung la XOR-split n cazul n care condiiile aferente tuturor celorlalte arce de ieire
din gateway sunt evaluate ca false. ntruct acest arc are semnificaia de n orice alt situaie, acesta
poate fi lsat neetichetat cu o condiie. Cu toate acestea, se recomand etichetarea n continuare a
acestui arc cu o condiie, pentru a spori lizibilitatea i a uura nelegerea modelului de ctre alte
persoane.
Odat ce oricare dintre cele trei activiti 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 situaii ale unei facturi. Pentru a modela acest lucru, vom folosi un XOR-join. Un gateway
de acest tip acioneaz ca un portal, n sensul c se ateapt un token care s soseasc de-a lungul
unuia dintre arcele de intrare, iar de ndat ce acesta sosete este trimis de-a lungul arcului de ieire.
Cu alte cuvinte, execuia activitilor trece de un XOR-join de fiecare dat cnd 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 sfrit denumit
"Factura emis". Asigurai-v c ntotdeauna un model de proces se finalizeaz cu eveniment de sfrit,
chiar dac este evident modul n care procesul se termin.

4.2.2. Execuia paralel

Atunci cnd dou sau mai multe activiti nu au dependene 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 execuia de pe dou sau mai multe ramuri paralele.
Un Gateway de tip AND este descris ca un diamant care conine 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 ct i cel
al bagajelor de mn. Dup aceea, pasagerii pot merge la poarta de mbarcare.
Acest proces const din patru activiti. Modelul ncepe cu activitatea "Mergi la verificarea de
securitate" continu cu activitile Realizare verificare personal, Realizare verificare bagaje i se
termin cu activitatea "Mergi la poarta de plecare". Aceste dou activiti 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 aflm n situaia de a efectua dou activiti 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 situaie, vom folosi un AND-split care
leag activitatea "Mergi la verificarea de securitate" de cele dou activiti de verificare. De asemenea,
vom folosi un AND-join care sincronizeaz cele dou ramuri cu activitile de verificare astfel nct
activitatea "Mergi la poarta de plecare" s nu se poat executa naintea finalizrii celor dou verificri
(vezi Fig. 4).

Fig. 4 Exemplu de folosire a unei ramificri 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 ntlnirea AND-join-ului. Cu alte cuvinte atunci cnd ntlnii un AND-split ntr-un
model trebuie s executai toate ramurile care ies din acesta, indiferent cte sunt (reinei c pot fi
mai mult de dou arce de ieire). Aa cum am spus nainte, un token este utilizat pentru a indica starea
unei anumite execuii (instane) a procesului iar culoarea token-ului face diferena dintre mai multe
instane care se execut n acelai timp. Exist situaii cnd mai multe token-uri de aceeai culoare sunt
distribuite pe un model de proces (de exemplu, ca rezultat al executrii unui AND-split), i colectiv
reprezint starea n care se afl instana. De exemplu, n cazul n care un token este pe arcul dintre
activitatea "Realizare verificare personal" i AND-join iar un alt token de aceeai 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 mn nu a
trecut nc de controlul de securitate.
AND-join din exemplul nostru ateapt 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 execuia
activitilor doar atunci cnd 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 ateptare a ajungerii
unui numr de token-uri care apoi fuzioneaz ntr-unul singur se numete sincronizare.
Exemplul 4: S extindem exemplul de onorare a comenzilor din Fig. 1 prin constrngerea c o comand
de cumprare 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 acelai 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 cteva remarci. n primul rnd, acest model are
dou activiti care se exclud reciproc: "Confirm comanda" i "Respinge comanda". Astfel, acestea
trebuie s fie precedate de un XOR-split (amintii-v s plasai 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 rnd, cele dou secvene "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 activiti
sunt de obicei executate de resurse diferite din cadrul organizaiei (de ex. un gestionar pentru
expediere i un ofier financiar pentru factur) i, astfel, pot fi executate n paralel. Remarcai cuvntul
"ntre timp", din descrierea procesului, deoarece acesta indic faptul c dou sau mai multe activiti
pot fi efectuate n acelai timp.
S comparm versiunea din Fig. 5 a procesului de onorare a comenzilor cu Fig. 1 n ceea ce privete
evenimentele. Noua versiune dispune de dou evenimente de sfrit n timp ce prima versiune dispune
de un singur eveniment de sfrit. ntr-un model BPMN putem avea mai multe evenimente finale,
fiecare capturnd un rezultat diferit al procesului (de exemplu, comand confirmat fa de comand
respins). BPMN adopt aa-numita terminare semantic implicit, ceea ce nseamn c o instan de
proces se finalizeaz numai atunci cnd 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 declanator diferit pentru a ncepe o instan a procesului. De exemplu, am
putea ncepe procesul de onorare a comenzilor, fie atunci cnd o nou comand de achiziie este
primit fie atunci cnd o comand revizuit este retrimis de un client. n cazul n care o comand
revizuit este retrimis, se pot regsi n primul rnd 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 declanat de primul eveniment
care apare (remarcai 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 declanatoare diferite

Exist dou situaii 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 cnd urmeaz dup o activitate sau un
eveniment. n acest caz, arcele de ieire ale AND-split-ului vor porni direct din activitatea sau
evenimentul precedent.

4.2.3. Deciziile inclusive

Cteodat e nevoie s se execute una sau mai multe dintre ramurile care pleac dintr-un split.
Exemplul 5 (Procesul de distribuire a mrfurilor): O companie are dou depozite care stocheaz diferite
produse: unul la Amsterdam i altul la Hamburg. Cnd o comand este primit, acesta este distribuit
din aceste depozite. Dac unele dintre produsele comandate sunt stocate n Amsterdam, o subcomand 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 combinaie de gateway-uri AND i/sau XOR? Rspunsul
este da, cu unele probleme. Figurile 7 i 8 arat dou soluii posibile. n primul, vom folosi un XORsplit cu trei ramuri alternative: una urmat n cazul n care ordinul conine doar produse aflate n
Amsterdam (unde sub-comanda este transmis la depozitul de la Amsterdam), o alta urmat n cazul
n care comanda conine doar produse aflate n Hamburg (n mod similar, n aceast ramur subcomanda este transmis la depozitul Hamburg), i o a treia ramur care trebuie urmat n cazul n care
comanda conine produse din ambele depozite (caz n care sub-comenzile sunt transmise ctre 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 activiti de transmitere a sub-comenzilor
ctre cele dou depozitele. i dac am fi avut mai mult de dou depozite, numrul de activiti duplicat
ar crete. De exemplu, dac am avea trei depozite, am avea nevoie de un XOR-split, cu apte brae de
ieire, i fiecare activitate ar trebui s fie duplicat de patru ori. n mod clar aceast soluie nu este
scalabil.

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

n cea de a doua soluie folosim un AND-split, cu dou arce de ieire, fiecare ducnd la cte un XORsplit cu dou ramuri alternative. Una este urmat in cazul n care comanda conine 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 conine nici un produs din Amsterdam/Hamburg, caz n
care nu se face nimic pn la XOR-join-ul care mbin cele dou ramuri alternative. Apoi, un AND-join
unete cele dou ramuri paralele i procesul se termin prin nregistrarea comenzii.

Care este problema cu aceast a doua soluie? Scenariul din exemplu permite trei cazuri: produsele
sunt doar n Amsterdam, doar n Hamburg, sau n ambele depozite. Dar aceast soluie permite mai
mult cu un caz: atunci cnd produsele nu sunt n nici unul din cele dou depozite. Apare acest caz,
atunci cnd cele dou ramuri goale ale celor dou XOR-split-uri sunt urmate, astfel neexecutndu-se
nici o activitate ntre "Verific produsele comandate" i "nregistreaz comanda". Astfel aceast
soluie, n ciuda faptului c este mai compact dect prima, este greit.
Pentru a modela situaiile n care o decizie poate conduce la alegerea uneia sau a mai multor opiuni,
avem nevoie s lum o decizie inclusiv (OR). Un OR-split este similar cu XOR-split, dar condiiile de pe
ramurile de ieire nu trebuie s se exclud reciproc (adic mai mult de una dintre ele poate fi adevrat
n acelai timp). Cnd execuia procesului ajunge la un OR-split se pot urma una sau mai multe ramuri
de ieire, n funcie de care condiii sunt adevrate. n ceea ce privete semantica token-urilor, acest
lucru nseamn c OR-split-ul consum un token de-a lungul arcului de intrare i genereaz un numr
variabil de token-uri, echivalent cu numrul de condiii de ieire care sunt adevrate. Acest numr
poate fi cel puin unu i cel mult numrul total ramuri de ieire din OR-split. Similar cu un XOR-split, un
OR-split poate fi, de asemenea, urmat de un arc de ieire prestabilit (care este urmat numai atunci
cnd toate celelalte condiii sunt evaluate ca false).

Fig. 9 Soluie corect folosind gateway-uri de tip XOR

Figura 9 prezint soluia 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 cnd toate activitile aflate pe
ramurile de intrare active au fost finalizate. Dup ce toate token-urile distribuite pe ramuri de ctre 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 ieire (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 insistm pe conceptul de ramur activ. Privii modelul din Fig. 10, care conine un gateway de tip
nedefinit (cel gri cu un semn de ntrebare). Ce tip ar trebui s-i atribuim? S ncercm un AND-join care
s fie n concordan cu AND-split-ul precedent. Ne amintim c un AND-join-ul ateapt un token dea lungul fiecrui arc de intrare. n timp ce token-ul din ramura de activitatea "C" va ajunge mereu la
AND-join, token-ul din ramura care ncepe cu activitatea "B" nu poate ajunge n cazul n care fluxul este
direcionat ctre "E" de XOR-split-ul intermediar. Deci, n cazul n care activitatea de "D" nu este

executat, AND-join-ul va atepta la nesfrit un token, i n consecin instana respectiv a procesului

nu se va finaliza niciodat. Aceast anomalie de comportament se numete punct mort (deadlock) i
trebuie evitat.

Fig. 10 De ce tip ar trebui sa fie join-ul astfel nct instanele procesului sa se execute corect?

S ncercm un XOR-join n locul gateway-ului enigmatic. Amintim c XOR-join-ul funcioneaz prin

transmiterea de-a lungul arcului de ieire a fiecrui 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
funcie de modul n care XOR-split-ul intermediar direcioneaz token-ul de pe ramura care ncepe cu
activitatea B ctre 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 soluie poate funciona,
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 dect att, n acest caz am putea semnala ncheierea
instanei procesului de dou ori. i aceasta, din nou, este ceva ce ne dorim s evitm.
Singurul tip de gateway rmas este OR-join. Un OR-join va atepta 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 ctre "E", OR-join-ul nu va mai atepta un token de pe ramura
respectiv. Astfel, se va trece la Execuia activitii F imediat ce token-ul de pe ramura cu activitatea
"C" ajunge. Pe de alt parte, dac XOR-split-ul intermediar trimite token-ul ctre activitatea "D", ORjoin va atepta 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 ctre activitatea "F" care poate fi executat o dat i procesul
poate finaliza n mod normal.
Deci, cnd ar trebui folosit un gateway OR-join?
Deoarece semantica OR-join nu este simpl, prezena acestui element ntr-un model BPMN poate
confuza cititorul. Astfel, este recomandat folosirea lui numai atunci cnd este strict necesar. n mod
evident, un OR-join trebuie s fie utilizat ori de cte 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 acelai
tip). Modelul poate arata mai degrab ca cel din Fig. 10, n cazul n care pot fi mai multe puncte de
intrare, sau de ieire dintr-un bloc de structur. n aceste cazuri, jucai jocul token-urilor pentru a

nelege corect tipul de gateway necesar pentru a modela realitatea. ncepei cu un XOR-join, ncercai
pe urm un AND-join i n cazul n care ambele gateway conduc la modele incorecte utilizai un ORjoin.
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 preferai ofer diferite tipuri de materii prime. n funcie 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 iniial este cel din figura urmtoare.

Fig. 11 Modelul de proces care include producia produselor

4.2.4. Reluarea unei activiti i repetarea unei pri din proces

Pn acum am vzut structuri care sunt liniare, adic fiecare activitate poate s fie executat cel mult
odat. Cu toate acestea, uneori, realitatea ne poate cere s repetm una sau mai multe activiti (de
exemplu din cauza unei verificri care a euat de mai multe ori).
Exemplul 7: n biroul ministrului Trezoreriei, o dat o anchet ministerial a fost declanat, aceasta
este n primul rnd nregistrat n sistem. Apoi, cazul este investigat astfel nct un rspuns ministerial
s poat fi pregtit. Finalizarea anchetei include scrierea rspunsului de ctre eful de cabinet i o

revizuire a rspunsului de ctre registratorul principal. Dac registratorul nu aprob rspunsul, acesta
din urm trebuie s fie rescris de ctre eful de cabinet. Procesul se termin numai dup ce rspunsul
a fost aprobat de registrator.
Pentru a modela reluare sau repetarea avem nevoie n primul rnd s identificm activitile, (sau mai
mult, ntreg fragmentul de proces) care pot fi repetate. n exemplul nostru aceasta const din secvena
de activiti "Pregtete rspunsul ministerial" i " Revizuiete rspunsul ministerial". S numim acest
fragment al procesului bloc de repetiie. 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 repetiie (astfel nct activitile din acesta s poat fi repetate), sau s
continum cu restul procesului. Ca atare, aceast activitate de decizie ar trebui s aib dou rezultate.
n exemplul nostru, activitatea de decizie este "Review rspuns ministerial" i rezultatele sale sunt:
"rspuns aprobat" (n acest caz, se continu cu restul activitilor din proces) i "rspuns neaprobat"
(se execut din nou activitile din blocul de repetiie). Pentru a modela aceste dou posibile rezultate,
vom folosi un XOR-split, cu dou ramuri de ieire: una care ne permite s continum 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 "Pregtete rspunsul
ministerial". Vom folosi un XOR-join pentru a reconecta aceast ramur de revenire la restul modelul
de proces, chiar nainte de blocul de repetiie. Modelul pentru exemplul nostru este ilustrat n Fig. 12.

Fig. 12 Model cu un bloc de repetiie

n acest capitol, ai nvat cum s combinai activiti, evenimente, i gateway-uri pentru a crea un
model de baz. Pentru fiecare element enumerat, am artat 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.

Exerciii recapitulative:
4.2.1. Creai un model BPMN pe baza urmtoarei descrieri: Odat ce o cerere de mprumut este primit
de ctre 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 informaiile lips i trimite napoi cererea la banc. Acest proces
se repet pn cnd se constat c cererea este completat corespunztor.
4.2.2. Creai un model BPMN pe baza urmtoarei descrieri: O cerere de mprumut este aprobat dac
trece dou controale: (i) de evaluare a riscului de credit al solicitantului, realizat automat de ctre un
sistem, i (ii) evaluarea proprietii pentru care mprumutul a fost solicitat, efectuat de ctre un
evaluator. Evaluarea riscurilor necesit o verificare a istoricului de creditare a solicitantului, care este

efectuat de ctre un ofier financiar. Dup ce att evaluarea riscului de credit ct i evaluarea
bunurilor au fost efectuate, un ofier de credit poate evalua eligibilitatea solicitantului. n cazul n care
solicitantul nu este eligibil, cererea este respins, n caz contrar documentele de credit sunt pregtite
i transmise solicitantului.

4.3. Perspectiva de date a modelelor de procese

Dup cum am artat n capitolul precedent, un proces de afaceri presupune diferite aspecte
organizaionale cum ar fi funcii, artefacte de afaceri, oameni, i sisteme software. Aceste aspecte sunt
capturate de perspective diferite de modelare a proceselor. Pn acum am vzut punct de vedere
funcional, care indic ce activiti ar trebui s se ntmple n acest proces, i perspectiva control-flow,
care indic ordinea n care activitile i evenimentele ar trebui s apar. Un alt punct de vedere
important care ar trebui luat n considerare atunci cnd 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 efecturii unei activiti.
S mbogim 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 executrii sale. De exemplu, prima activitate a procesului de
onorare a comenzilor este "Consultai stocurile disponibile". Acest lucru necesit un datele existente
ntr-un document comand de cumprare ca intrare, n scopul de a afla care produsul comandat si a
putea verifica dac este n stoc sau nu este. Acelai artefact (comanda de cumprare) 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 cumprare, sunt numite
obiecte de date n BPMN. Obiectele de date reprezint informaii care curg n i din activiti. Ele pot
fi artefacte fizice, cum ar fi o factur sau o scrisoare pe o bucat de hrtie, sau artefacte electronice,
cum ar fi un e-mail sau un fiier. Le reprezentm grafic ntr-un model BPMN ca un document cu colul
din dreapta-sus pliat, i le legm la activiti cu o linie punctat terminat cu un vrf de sgeat deschis
(aceasta este numit asociaie de date n BPMN). Figura 13 prezinta un model n care obiectele de
date sunt implicate n realizarea procesului.
Se folosete direcia asociaiei de date pentru a stabili dac un obiect de date este o intrare sau o ieire
pentru o anumit activitate. O asociaie de intrare, cum ar fi cea care leag obiectul de date Purchase
Order de activitatea "Check stock availability" indic faptul c o comand de cumprare este
obligatorie pentru a putea realiza aceast activitate. O asociaie de ieire, 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 executrii acestei activiti. Pentru a evita aglomerarea
modelului BPMN cu asocieri de date care s ntretaie arcele care modeleaz ordinea activitilor, am
putea repeta un obiect de date de mai multe ori n cadrul aceluiai model de proces. De aceea,
convenia este c toate apariiile unui anumit obiect se refer conceptual la acelai 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 activiti sunt departe una de alta n modelul.

Fig. 13 Modelul de onorare a unei comenzi, mbogit 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 obinute Materii prime (obiectul de date Raw materials),
acestea sunt folosite de activitatea "Manufacture product", pentru a crea un produs. Produsele, la
rndul lor, sunt ambalate i trimise clientului n cadrul activitii "Ship product". n mod eficient,
obiecte de date ne permit s modelm fluxul de informaii ntre activitile din proces. inei minte, cu
toate acestea, c obiecte de date i asociaiile acestora cu activiti nu pot nlocui secvena de flux a
activitilor. 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 secvena de activiti A -> B. O notaie 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 activiti consecutive, printr-o asociaie neorientat. A se
vedea, de exemplu, modul n care e modelat asocierea obiectului de date Shipment address cu arcul
care unete activitile "Get shipment address" i "Ship product". Aceasta este o prescurtare care
indic faptul c adresa de expediere este o ieire a activitii "Get shipment address" i o intrare a
activitii Ship product".

Uneori, am putea avea nevoie s reprezentm starea unui obiect de date. De exemplu, activitatea de
confirmare a comenzii "Confirm order" are un ordin de cumprare ca intrare, i returneaz tot un ordin
de cumprare dar n starea confirmat. n mod similar, activitatea "Receive payment" are ca intrare
tot o comand de cumprare confirmat i o transform ntr-una pltit. Un obiect poate trece
printr-o serie de stri. De exemplu, o factur este prima dat "deschis", apoi "aprobat" sau
"respins" i n final "arhivat". Indicarea strii obiectelor de date este opional. Putem face acest
lucru prin adugarea numele strii ntre paranteze ptrate, de exemplu, "Comand [confirmat]",
"produs [ambalat]".
Un depozit de date este un loc care conine 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. Activitile din proces pot citi/scrie obiecte de date din/n baze
de date. De exemplu, activitatea "Verificai disponibilitate stoc" preia valoarea stocului pentru
produsul comandat de la baza de date, care conine informaii 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 activiti. Un exemplu de
depozit de date folosit ca ieire este baza de date Orders BD, care este utilizat de activitate "Archive
order" pentru a stoca comanda de cumprare 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 activiti prin intermediul asociaiilor de date.
ntrebare: Afecteaz perspectiva de date secvena de execuie a activitilor?
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 activiti, ea nu poate fi executat pn cnd
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 finalizrii unei activiti anterioare, sau pentru c este o
intrare a ntregului proces (cum ar fi ordinul de cumprare n exemplu de mai sus).
ntrebare: Trebuie ntotdeauna modelat perspectiva de date?
Obiectele de date ajut cititorul s neleag fluxul de date de la o activitate la alta. Cu toate acestea,
preul includerii perspectivei de date n model este o complexitate crescut a diagramei. Astfel, v
sugerm s le folosii numai atunci cnd acestea sunt necesare pentru un anumit scop, de exemplu,
pentru a evidenia potenialele probleme n procesul de analizat sau pentru automatizare. Uneori, am
putea avea nevoie s furnizm informaii suplimentare pentru cititor, n scopul mbuntirii nelegerii
modelului. De exemplu, n procesul de onorare a comenzilor am putea dori s precizm c activitatea
de expediere a produselor "Ship product" include ambalarea produsului.
De asemenea, ne-am putea dori s clarificm ce regul de afaceri este urmat n cazul alegerii de
materii prime de la furnizori. Astfel de informaii suplimentare pot fi furnizate prin intermediul
adnotrilor textuale. O adnotare este desenat ca un dreptunghi deschis care conine un text, i care
este legat de un element al modelului printr-o linie punctat (denumit tot asociere) - vezi Fig. 13
pentru un exemplu. Adnotri de text nu poart nici o semantic, prin urmare, ele nu afecteaz fluxul
de token-uri prin modelul de proces.

Exerciii recapitulative:
4.3.1. Alturai 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: examinai cu atenie evenimentele start i stop ale fragmentelor, pentru a putea determina
modul n care acestea se leag ntre ele.
4.3.2. mbogii modelul creat la problema anterioar cu perspectiva de date, conform cunotinelor
voastre generale legate de acest domeniu.

4.4. Perspectiva resurselor unui proces de afaceri

Un alt aspect, care trebuie luat n considerare atunci cnd se modeleaz procesele de afaceri este
perspectiva resurselor. Aceast perspectiv, numit, i perspectiv organizaional, indic cine sau ce
desfoar o activitate din proces. Resurs este un termen generic pentru a ne referi la cineva sau
ceva implicat n executare unei activiti 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 aplicaie software.

Un echipament, cum ar fi o imprimant sau o instalaie de fabricare.

Exist resurse active, adic resurse care pot autonom s execute o activitate, i resurse pasive, adic
resurse care sunt doar implicate n desfurarea unei activiti. 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 desfoar 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 conine 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 organizaie ntreag, o unitate organizaional sau un rol/funcie ndeplinit/
de angajai.
Exemplul 8: Procesul de onorare a comenzilor este efectuat de ctre organizaia vnztoare, care
include dou departamente: departamentul de vnzri; i departamentul de depozitare i distribuie.
Comanda de achiziie este primit de departamentul de depozitare i de distribuie, unde este i
realizat verificarea stocului. Aceast operaiune este efectuat n mod automat de ctre 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 vnzri s confirme comanda. Dup care,
departamentul de vnzri emite o factur i ateptat ncasarea. n acelai timp, produsul este livrat
de departamentul de depozitare i distribuie. Procesul se termin prin arhivarea comenzii n
departamentul de vnzri. n cazul n care produsul nu este n stoc, sistemul ERP al departamentului de
depozitare i distribuie verific disponibilitatea materiilor prime prin accesarea catalogului de
furnizori. Odat ce materiile prime au fost obinute, departamentul de depozitare i distribuie
realizeaz fabricarea produsului. Procesul se termin cu confirmarea comenzii de achiziie i arhivarea
acesteia de ctre departamentul de vnzri.
BPMN conine 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 mpri un pool n sub-clase sau resurse unice. Nu exist restricii cu privire la resursele
specifice pe care un pool sau un swimlane ar trebui s le modeleze. Se folosete, de obicei, un pool

pentru a modela o afacere parte ca o organizaie ntreag (cum ar fi vnztorul n exemplul nostru), i
un swimlane pentru a modela un departament, unitate, echipa sau sistem software/echipament n
cadrul acestei organizaii. n exemplul nostru, am mpri pool-ul firmei vnztoare n dou swimlaneuri: una pentru departamentul de depozitare si distribuie, cealalt pentru departamentul de vnzri.
Swimlane-urile pot fi imbricate una n alta n mai multe niveluri. De exemplu, dac e nevoie s modelm
att un departament ct 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 activiti, evenimente,
gateway-uri, precum i obiecte de date. De obicei, se modeleaz aceste dreptunghiuri orizontal, dei
modelarea lor pe vertical este de asemenea posibil. Numele pool-ului/ swimlane-ului este afiat
vertical n partea stng a unui dreptunghi orizontal (sau orizontal n cazul n care piscina / banda este
vertical), pentru pool-uri, i pentru swimlane-uri care conin swimlane-uri imbricate, numele este
nchis ntr-o formaie. Figura 14 prezinta exemplul de onorare a unei comenzi de achiziie n care este
modelat i perspectiva de resurse.

Fig. 14 Modelul procesului de onorare a unei comenzi care include secvena activitilor 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 corespunztor n cadrul
swimlane-urilor. n exemplul nostru am plasat evenimentul "Ordin cumprare 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 vnzri 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 activitile de care sunt i nu au
un executor. n cazul gateway-urilor, trebuie s plasm (X)OR-split-urile n acelai swimlane ca i
activitatea de decizie imediat precedent. Pe de alt parte, un gateway ANDsplit poate fi plasat n
orice swimlane, deoarece aceste elemente sunt pasive (n sensul c ele se comport n funcie de
contextul lor).
Se pot organiza swimlane-uri ntr-un pool sub forma unei matrice n cazul n care avem nevoie s
modelm structuri organizaionale complexe. De exemplu, dac avem o organizaie 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. inei
minte, totui, c n BPMN fiecare activitate poate fi efectuat de ctre o singur resurs. Astfel, n cazul
n care o activitate se afl n intersecia unui swimlane orizontal cu un swimlane vertical, ea va fi
efectuat prin resursa care ndeplinete caracteristicile ambelor swimlane-uri, de exemplu, o resurs
care are rolul respectiv dar i aparine acelui departament.
Deseori, exist mai mult pri implicate ntr-un proces de afaceri. De exemplu, n procesul de onorare
a comenzilor, exist patru pri: vnztorul, clientul i cei doi furnizori ai vnztorului. Fiecare parte
poate fi modelat printr-un pool. n exemplul nostru, putem folosi, astfel, un pool pentru client, unul
pentru vnztor i unul pentru fiecare furnizor. Fiecare dintre aceste pool-uri va conine activiti,
evenimente, gateway-uri, precum i obiectele de date care modeleaz respectiva organizaie. Sau
altfel spus, fiecare pool va modela acelai proces de afaceri din punctul de vedere al unei anumite
organizaii. De exemplu, evenimentul "Ordin cumprare primit", care se afl n pool-ul Vnztorului,
va avea o activitate corespunztoare "Trimite ordin de cumprare", care se afl n pool-ul Clientului.
n mod similar, activitatea de "Experiaz produs" din pool-ul Vnztorului vor avea n contrapartid
activitatea "Primete produs" n pool-ul clientului. Deci, cum putem modela interaciunile dintre poolurile a dou organizaii care colaboreaz? Nu putem folosi un flux de secven pentru a conecta
activiti care aparin diferitelor pool-uri deoarece secvena flux nu poate trece grania unui pool.
Pentru aceasta, avem nevoie s utilizm un element specific numit flux de mesaje.
Un flux de mesaje reprezint fluxul de informaii 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 vrf de sgeat gol, i
poart o etichet care indic coninutul mesajului (de exemplu un fax, o comand de cumprare, dar,
de asemenea, o scrisoare sau un apel telefonic). Adic, fluxul de mesaje modeleaz curgerea oricrui
tip de comunicare ntre cele dou organizaii, nu conteaz dac acest lucru este electronic (cum ar fi
trimiterea unui ordin de cumprare prin e-mail sau transmiterea unui fax), sau manual (efectuarea
unui apel telefonic sau predarea unei scrisori pe hrtie).
Figura 15 prezinta modelul complet pentru onorarea unei comenzi de cumprare, inclusiv pool-uri
pentru client i cei doi furnizori. Aici putem vedea c fluxurile mesaj sunt etichetate informaiile 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 ctre activitatea care primete mesajul. De exemplu,
mesajul "Materii prime" este primit de activitate "Obinerea de materii prime de la Furnizor 1", care
apoi creeaz obiectul de date "Materii prime". Acesta este i cazul comenzii de cumprare, care este
generat de evenimentul de start "Comand de cumprare primit" din coninutul fluxului de mesaje
primite. Nu e nevoie s creai un obiect de date pentru fiecare flux de mesaje recepionat, numai atunci
cnd informaiile 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 reprezentm n mod explicit obiectul de date folosit ntr-un mesaj de ieire, 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 ctre o alt activitate n pool-ul Vnztorului.
O diagram BPMN care dispune de dou sau mai multe pool-uri poate fi numit i diagram de
colaborare. Figura 15 arat diferite utilizri ale unui pool ntr-o diagram de colaborare. Un pool (cum
ar fi cel al Vnztorului) se numete proces privat, sau white box pool, din moment ce arat cum
organizaia vnztorului particip efectiv la procesul de onorare a comenzilor n ceea ce privete
activitile, evenimentele, gateway-urile, precum i obiectele de date. Dimpotriv, un pool cum este
cel al clientului sau cele ale celor doi furnizori se numete proces public, sau black box pool, deoarece
ascunde modul n care aceste organizaii particip efectiv n onorarea comenzilor. Pentru a economisi
spaiu, 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. Cnd se
modeleaz o diagram de colaborare, o organizaie poate decide dac i expune sau nu
comportamentul ei intern, n funcie de cerinele proiectului. De exemplu, dac modelm procesului
de onorare a comenzilor din perspectiva vnztorului, ar putea fi relevant s expunem procesul de
afaceri doar al vnztorului, dar nu i cel al clientului i furnizorilor. Adic, comportamentul intern al
clientului i cel al furnizorilor nu sunt relevante pentru nelegerea modul n care vnztorul ar trebui
s onoreze comenzile de cumprare, i, ca atare, acestea pot fi ascunse. Pe de alt parte, n cazul n
care avem nevoie s mbuntim modul n care vnztorul i onoreaz comenzile de cumprare, near putea interesa, de asemenea, ce trebuie s fac un furnizor s livreze materii prime, pentru c o
ntrziere n furnizarea de materii prime va ncetini fabricarea produselor n organizaia vnztorului.
n acest caz, ar trebui s reprezentm, 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 grania 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 cumprare se termin la
evenimentul de start n pool-ul Vnztor. 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. inei cont de
faptul c un flux de mesaje este utilizat doar pentru a conecta dou pool-uri i nu pentru a conecta
dou activiti n acelai pool (n acest caz folosim o sgeat care indic secvena).
O activitate care este sursa unui mesaj, cum ar fi "Emite factur" din pool-ul Vnztor se numete o
activitate de trimitere. Mesajul este trimis la finalizarea execuiei activitii. Pe de alt parte, o
activitate care primete un mesaj - cum ar fi "Preia adresa de livrare" este activitate receptor. Execuia
unei astfel de activiti nu va fi ncepe pn cnd mesajul de intrare nu a fost primit. O activitate poate

att s primeasc dar i s trimit mesaje, atunci cnd aceasta are att un flux de mesaje de intrare ct
i unul de ieire (de exemplu, "Pltete factura"). Executarea acestei activiti va ncepe atunci cnd
att token-ul aferent fluxului de control ct i mesajul de intrare este receptat. La finalizarea activitii,
un token va fi trimis de-a lungul arcului de ieire dar i mesajul va fi trimis. n cele din urm, atunci
cnd un flux de mesaje este receptat de un eveniment de start (ca i "Comand de cumprare 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, modelndu-se astfel
stocarea coninutului mesajului de intrare.

Fig. 15 Modelul procesului de onorare a unei comenzi care include i colaborarea (mesajele) ntre vnztor,
cumprtor i doi furnizori

n exemplul de onorare a comenzilor am folosit pool-uri pentru a reprezenta prile implicate ntr-un
proces de afaceri i swimlane-uri pentru a reprezenta departamentele i sistemele n cadrul
organizaiei vnztorului. Am ales acest mode de modelare pentru c am vrut s ne concentrm asupra
interaciunilor dintre vnztor, client i cei doi furnizori. Aa cum am menionat 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 interaciunile dintre departamente
ale unei organizaii, putem modela fiecare departament ca un pool, i putem folosi swimlane-urile
pentru a detalia resursele din cadrul fiecrui departament (de exemplu, n uniti sau roluri). n orice
caz, ar trebui s evitm s folosim pool-urile i swimlane-urile pentru a modela participanii cu numele
lor (deoarece persoanele tind s se schimbe frecvent n cadrul unei organizaii), i mai degrab ar trebui

s folosim rolul participantului (de exemplu, funcionar financiar). Pe de alt parte, putem folosi poolurile i swimlane-urile pentru a reprezenta software-ul specific, sisteme sau echipamente (de exemplu,
un sistem ERP), deoarece acestea schimba mai rar ntr-o organizaie.
Exerciii recapitulative:
4.4.1. Extindei modelul de proces aferent evalurii unei cereri de acordare a unui credit prin
adugarea perspectivei resurselor pe baza urmtoarei descrieri:
Procesul de evaluare a cererilor de credit este executat de patru roluri din cadrul unei bnci: un
funcionar financiar verific istoricul de credit al solicitantului, un evaluator de proprieti este
responsabil pentru evaluarea garaniilor imobiliare, un funcionar de la departamentul asigurri trimite
solicitantului oferta de asigurare n cazul n care acest lucru este necesar. Toate celelalte activiti sunt
efectuate de ctre consultantul de credite, care este principalul punct de contact cu solicitantul.
4.4.2. Extindei modelul de proces de la exerciiul precedent prin modelarea interaciunii (schimbului
de mesaje) ntre banc i client.

Recapitulare
La sfritul acestui curs, ar trebui s fii n msur s citii, s nelegei i s putei 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: activiti simple, evenimente, gateway-uri, obiecte de date, pool-uri, i
swimlane-uri. Activitile modeleaz lucrul din cadrul unui proces. Evenimente definesc nceputul i
sfritul unui proces, i semnalizeaz dac ceva ce se ntmpl n timpul executrii sale. Gateway-urile
modeleaz: decizii exclusive sau inclusive urmate de unirea ramurilor, paralelism urmat de
sincronizare, respectiv repetiie.
S-a mai explicat diferena 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 execuie specific a unui proces din toate modurile de execuie posibile.
Progresul execuiei, sau starea, unei instane de proces este reprezentat de distribuia token-urilor n
model. Folosind token-uri putem defini comportamentul gateway-urilor.
Ai mai nvat cum s folosii obiectele de date pentru a modela fluxul de informaii ntre activiti i
evenimente. Un obiect de date captureaz un artefact fizic sau electronic: necesar pentru a executa o
activitate sau a declana un eveniment; sau care rezult din execuia unei activiti sau din declanarea
unui eveniment. Obiecte de date pot fi stocate ntr-un depozit de date (cum ar fi o baz de date sau
dulap fizic) astfel nct s poat fi stocate n afara procesului n care acestea sunt/au fost create.
De asemenea, ai vzut c pool-urile i swimlane-urile pot fi folosite pentru a modela att resursele
umane ct i cele non-umane, care desfoar activiti din proces. Pool-urile sunt clase de resurse, n
general, n timp ce swimlane-urile sunt folosite pentru a mpri pool-urile n sub-componente.
Interaciunea dintre pool-uri este modelat prin fluxuri de mesaje. Fluxurile de mesaje pot fi conectate
direct de marginile unui pool, dac detaliile interaciunii ntre transmitor i receptor nu sunt
relevante.
Activitile, evenimentele, gateway-urile, artefactele, i resursele aparin celor 3 perspective principale
de modelare ale unui proces de afaceri. Punctul de vedere funcional surprinde activitile care sunt
efectuate ntr-un proces de afaceri, n timp ce perspectiva control-flow combina aceste activiti i
evenimentele conexe stabilind necesitatea desfurrii acestora ntr-o anumit ordine. Perspectiva de
date acoper artefactele create i manipulate n timpul execuiei procesului. Perspectiva de resurse
acoper resursele (umane i non-umane) care efectueaz diverse activiti.

Exerciii Recapitulative
ER1: Ce fel de tipuri de split-uri i join-uri pot fi modelate ntr-un model de proces? Creai un model,
bazat pe un exemplu din lumea real, pentru fiecare din ele.

ER2: Creai o descriere textual a urmtorului model:

ER3: Modelai urmtorul proces pentru gestionarea avansurilor de la clieni:

Procesul de gestionare al ncasrilor n avans de la clieni ncepe atunci cnd o cerere de plat a uni
avans este considerat necesar. Aceasta implic introducerea cererii de plat n sistemul ERP al
ntreprinderii, nregistrarea automat a ncasrii avansului n evidenele contabile ale ntreprinderii,
emiterea facturii de vnzare i procesarea produselor comandate de client. Procesarea produselor
poate duce la apariia unor diferene de ncasat suplimentar sau de returnat sumele ncasate n avans.
n caz apariiei unei restituiri comanda este livrat, altfel se ateapt ncasarea soldului rmas nepltit.

ER4: Modelai urmtorul proces pentru evaluarea riscului acordrii unui credit:
Atunci cnd 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 evalurii, iar ntre timp plata sumei creditate este organizat. Pentru simplificare,
presupunem c rezultatul unei evaluri este ntotdeauna pozitiv.

ER5: Modelai urmtorul proces pentru obinerea unei despgubiri de asigurare:

Dup ce o cerere este nregistrat, acesta este examinat de ctre un inspector de daune care scrie
apoi o evaluare a pagubelor. Aceast evalaure este apoi verificat de ctre 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 plii daunelor.

ER6: Modelai urmtorul proces pentru compensarea daunelor:

n cazul n care un chiria este evacuat din cauza daunelor aduse unui imobil, un proces trebuie s fie
iniiat de tribunal, n scopul de a organiza o audiere pentru evaluarea valorii compensaiei pe care
chiriaul o datoreaz proprietarului. Acest proces ncepe atunci cnd un grefier al tribunalului primete

o cerere pentru despgubiri de la proprietar. Grefierul scoate din arhiva imobiliar datele imobilului
respectiv i controleaz att dac cererea este completat acceptabil pentru depunere, ct i dac este
n conformitate cu datele din arhiva imobiliar. Stabilirea unei date pentru audiere reclam plata unor
taxe de ctre proprietar. S-ar putea c proprietarul a pltit deja taxele odat cu cererea, caz n care
casierul stabilete o data de audiere i procesul se termin. Dar se poate c sunt necesare costuri
suplimentare, iar proprietarul a pltit deja, de asemenea, aceste taxe. n acest caz, casierul genereaz
o chitan pentru taxe i venituri suplimentare i stabilete data audierii. n cele din urm, n cazul n
care proprietarul nu are achitate taxele necesare, casierul emite o notificare de plat i ateapt ca
proprietarul s plteasc taxele nainte de a reevalua conformitatea cererii de despgubire.

ER7: Poate fi executat n mod corect urmtorul model? Daca nu, de ce? Cum poate fi corectat fr a
afecta faptul c F, G i E trebuie s rmn ntr-o revenire.

ER8: Extindei modelul din exerciiul ER6 prin adugarea perspectivei de date.
ER9: Extindei modelul din exerciiul ER8 prin adugarea perspectivei resurselor. Exist resurse nonumane?

ER10: Modelai urmtorul 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 edina de judecat din acea
zi. n cazul n care unele documente lipsesc, se iniiaz o cutare. n caz contrar, documentele sunt duse
fizic n sala de judecat. Dup ce toate documentele sunt gata, acestea sunt predate ctre grefier. ntre
timp ordinea de zi a judectorului este distribuit persoanelor implicate n procesele judecate. Ulterior,
audierile se desfoar.

ER11: Modelai urmtorul proces, din toate cele 3 perspective:

Procesul de revendicare a daunelor auto ncepe atunci cnd un client depune o cerere cu documentaia
relevant. Departamentul de Relaii cu Publicul de la asiguratorul auto verific documentele pentru
conformitatea completrii i nregistreaz cererea. Urmtor, 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 reparaiilor 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 ctre client i procesul este considerat ncheiat.

ER11: Modelai urmtorul proces, din toate cele 3 perspective:

Atunci cnd o cerere este primit, un inspector verific n primul rnd dac solicitantul este asigurat.
Dac nu, solicitantul este informat c cererea trebuie s fie respins prin trimiterea unei notificri
automate prin-un sistem SAP. n caz contrar, un inspector superior evalueaz gradul de severitate al
cererii. Bazat pe rezultatul evalurii se clasific cererile n simple sau complexe, iar formularele
corespunztoare sunt trimise solicitantului, din nou folosind sistemul SAP. Odat ce formularele sunt
returnate, ele sunt verificate de ctre inspector. n cazul n care formularele conin toate detaliile
relevante, cererea este nregistrat n sistemul de management al cererilor de despgubire 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
ctre inspector pentru a vedea dac toate detaliile au fost furnizate, i aa mai departe.