proiect
DESCRIPTION
proiectTRANSCRIPT
Platforme informatice pentru productie si servicii
Folosirea workflow-urilor pentru reprezentarea proceselor de afaceri
Coordonator: Conf. Dr. Ing. Brezeanu Iulian
Student: Dragomir Ioana Amalia
An: I Master
Specializarea: Automatică Avansată, Productică și Informatică Aplicată
Facultatea: Inginerie Electrică, Electronică și Tehnologia Informației
Universitatea: „Valahia”, Târgoviste
Folosirea workflow-urilor pentru reprezentarea proceselor de afaceri
Un proces de afaceri reprezintă o colecție de activități sau sarcini conexe,
structurate, ce au un punct de început și unul final, precum și intrări și ieșiri clar
definite. Accentul este pus pe felul în care se desfășoară activitatea într-o
organizație. Un proces de afaceri poate fi descompus în mai multe sub-procese, cu
caracteristici specifice, care împreună contribuie la atingerea scopului procesului de
bază.
1 CONCEPTUL DE PROCES DE AFACERE ÎN CADRUL UNEI
ORGANIZAŢII
Tehnologia informaţiei este considerată inovatoare în raport cu descrierea şi
implementarea unei strategii de afaceri, iar procesele de afaceri au rol catalizator în
creşterea valorii de afaceri a tehnologiei informaţiei. De aceea, pentru orice
întreprindere, procesele de afaceri se concretizează atât în contextul, cât şi în
fundamentul necesar dezvoltării sistemelor informatice pentru întreprinderi.
Procesele din întreprinderi sunt mijloacele prin care orice organizaţie îşi conduce
afacerea, încorporând orice activitate sau grup de activităţi care adaugă o valoare
unei resurse interne, pentru a obţine un produs sau un serviciu destinat unui
beneficiar (intern sau extern organizaţiei). O singură întreprindere execută un număr
mare de procese de afaceri pentru realizarea obiectivelor sale strategice, în acest fel
furnizând oportunitatea utilizării tehnologiei informatice pentru îmbunătăţirea
proceselor şi a performanţelor organizaţionale (Porter & Millar, 1985). Noile
tehnologii informatice permit nu doar îmbunătăţirea proceselor individuale, dar
pot oferi posibilităţi de integrare a proceselor de afaceri între unităţi fizice şi
organizaţionale disipate (Basu & Blanning, 2003).
O clasificare simplistă a proceselor de afaceri le împarte pe acestea în elementare şi
complexe. Deosebirea dintre cele două ar consta în numărul de activităţi pentru care
au fost definite. Astfel, un proces complex implică, de obicei, mai multe funcţii
esenţiale ale întreprinderii, iar operaţiile sale au un impact semnificativ asupra
funcţionalităţii generale a activităţii organizaţionale. Pentru a surprinde întreaga hartă
a activităţilor depuse şi sarcinilor implicate, se procedează, de obicei, la divizarea
proceselor complexe în subprocese, până la obţinerea de procese elementare care
definesc o singură funcţie pe care întreprinderea trebuie să o realizeze prin
activităţile sale. Activităţile sunt elemente componente ale unui proces sau subproces
realizate în mod individual de o singură entitate subdivizionară (de obicei, un
departament al întreprinderii). Orice activitate este definită prin ansamblul de sarcini
din care este alcătuită şi care sunt asignate indivizilor din cadrul departamentului în
responsabilitatea căruia intră realizarea respectivei sarcini (Figura nr. 1.1).
Figura nr. 1.1 Structura ierarhică a proceselor de afaceri din întreprinderi
În opinia majorităţii specialiştilor în managementul organizaţiei, procesele de afaceri
pot fi privite atât ca scopuri în realizarea unei strategii de afaceri, cât şi ca modele de
automatizare a afacerii prin utilizarea tehnologiilor informatice.Totuşi, ei atrag atenţia
cu privire la abordarea proceselor exclusiv prin prisma dezvoltării sistemelor
informatice, fără a ţine cont de realitatea economică ce defineşte activitatea unei
întreprinderi. Aceasta ar pune accentul pe date şi proceduri, având ca principal
obiectiv relaţiile dintre elementele procedurale şi maniera de utilizare a datelor, iar
conceptul de proces de afacere poate fi privit ca mijloc de analiză a modului în care
aplicaţiile unui sistem informatic pot fi integrate în scopul identificării oportunităţilor
oferite de automatizarea proceselor.
În prezent, în dezvoltarea sistemelor informatice pentru întreprinderi, se constată că
paradigma programării încă deţine o influenţă majoră în descrierea proceselor de
afaceri, activitatea întreprinderii fiind alcătuită din procese definite în conformitate cu
funcţiile sistemului informatic. Acest mod de tratare a proceselor de afaceri limitează
funcţiile acestora la ceea ce poate realiza sistemul informatic şi nu ţine cont,
întotdeauna, de întreaga realitate economică. Deşi sistemul informatic din cadrul unei
organizaţii joacă, în prezent, un rol crucial de susţinere a activităţii specifice
întreprinderii, majoritatea proceselor economice nu pot fi complet automatizate. De
fapt, automatizarea completă se poate realiza doar pentru anumite activităţi de
afaceri ce pot fi privite doar ca etape funcţionale ale unui ansamblu mai complex de
alte procese economice.
2 Managementul proceselor de afaceri
În practica de afaceri şi a managementului organizaţional, s-au conturat două
perspective cu privire la organizarea şi conducerea afacerii unei întreprinderi: una
orientată pe funcţii şi cealaltă orientată pe procese.
A Perspectiva funcţională priveşte problemele specifice activităţii de
management din punctul de vedere al resurselor organizaţiei puse la dispoziţia
departamentelor în scopul realizării anumitor funcţii particulare afacerii.
A Perspectiva orientată pe procese este oarecum complementară perspectivei
funcţionale, căutând să optimizeze performanţa întreprinderii pe seama
îmbunătăţirii proceselor cheie care definesc fundamentul afacerii întreprinderii.
Perspectiva funcţională a managementului este utilă pentru optimizarea resurselor
interne, în timp ce perspectiva orientată pe procese priveşte coordonarea activităţilor
complexe ale întreprinderii, care implică şi resurse externe.
Gestionarea acestor procese într-o viziune unitară şi în sensul impus de perspectiva
orientată pe procese a generat un concept des utilizat, acela de management al
proceselor de afaceri (Business Process Management). Deşi este un termen
îndelung disputat în literatura de specialitate, definiţiile pe care diverşi autori le-au
furnizat sunt conturate pe baza aceleiaşi idei de optimizare a proceselor întreprinderii
prin diverse mijloace specifice. În linii mari, termenul Business Process Management
(BPM) desemnează atât o strategie de afaceri, cât şi un segment software, destinate să
gestioneze eficienţa şi randamentul proceselor din cadrul întreprinderii, prin
practici de modelare, automatizare şi monitorizare.
Ca disciplină de management, BMP înlocuieşte perspectiva funcţională a
managementului cu cea orientată pe procese aliniată cu obiective de afaceri de nivel
înalt.
Ca tehnologie sau segment software, BMP furnizează un set de instrumente software
necesare pentru optimizarea performanţei, realizarea obiectivelor concrete de
performanţă, automatizarea şi monitorizarea activităţilor şi sarcinilor aferente
proceselor de afaceri şi furnizarea unei platforme software pentru îmbunătăţirea
performanţei afacerii.
Adresându-se proceselor complexe dintr-o întreprindere, BPM implică nu doar
angajaţii unei organizaţii, ci şi clienţii, furnizorii şi ceilalţi parteneri ai săi.
Implementarea unui sistem de management al proceselor de afaceri furnizează, pe
lângă returnarea investiţiei, şi noi nivele de analiză, vizibilitate, responsabilitate şi
predictibilitate pentru afacere.
Un sistem de management al proceselor din întreprindere priveşte orice proces prin
prisma ciclului de viaţă al acestuia. Sistemul de gestionare a proceselor face referire la
aceste etape ale ciclului de viaţă, de la apariţia procesului în cadrul întreprinderii şi
până la eventuala eliminare a lui din strategia de afaceri. Astfel, sistemele Business
Process Management deţin patru arii principale de activităţi, corespunzătoare
principalelor etape din ciclul de viaţă al proceselor de afaceri: proiectarea şi
modelarea, implementarea sau execuţia, monitorizarea şi optimizarea proceselor.
Aşa cum se descrie şi în Figura nr. 2.1. Ciclul de viaţă a proceselor de afaceri, aceste
arii de activităţi sunt iterative şi trebuie gestionate în orice stadiu al proceselor de
afaceri.
Figura nr. 2.1 Ciclul de viaţă a proceselor
de afaceri
Proiectarea şi modelarea proceselor de afaceri trebuie să surprindă complexitatea
şi dinamica fiecărui proces ce va fi inclus în strategia de afaceri şi să explice modul
în care acesta va afecta activitatea întreprinderii şi va contribui la adăugarea unui plus
de valoare în cadrul lanţului valoric specific.
Implementarea sau execuţia priveşte, pe de o parte, includerea unor noi
procese de afaceri în activitatea specifică întreprinderii, iar pe de altă parte,
adoptarea noilor modele stabilite în cadrul etapei de modelare a proceselor existente,
care necesită îmbunătăţiri sau restructurări. Implementarea trebuie să ţină cont nu
doar de integrarea proceselor noi cu cele existente, dar şi de atribuirea
responsabilităţilor pe roluri asociate proceselor, şi gestionarea acestor roluri.
Monitorizarea este o componentă vitală în abordarea managementului
proceselor de afaceri, în primul rând datorită faptului că o perspectivă a afacerii
orientată pe procese este, de cele mai multe ori, asociată cu nevoia de vizibilitate a
performanţelor şi a conformităţii cu strategia de afaceri, şi în al doilea rând, datorită
nevoii de evidenţiere a eficienţei şi randamentului proceselor. Monitorizarea se referă
la acel set de activităţi care permit descoperirea anumitor elemente, care confirmă
sau infirmă utilitatea unui proces de afaceri, dar şi a anumitor anomalii ce nu ar putea
fi vizibile în etapele anterioare de proiectare şi modelare statică. De aceea,
tehnologia de monitorizare oferă un feedback vital atât managerilor afacerii, cât şi
persoanelor responsabile cu implementarea proceselor, beneficiind de suport tehnic
din aria auditului financiar şi informatic.
Optimizarea este procesul de analiză a informaţiilor colectate prin activitatea de
monitorizare şi de definire a unor posibile direcţii de rafinare a modelelor
proceselor de afaceri şi a implementării acestora. De fapt, optimizarea este
responsabilă de caracterul iterativ al proceselor de afaceri, întrucât ea este cea care
determină reluarea etapelor de modelare, implementare şi optimizare a acestora.
Definirea proceselor de afaceri a devenit nucleul unui limbaj comun între oameni de
afaceri şi specialişti IT. În acest context, Business Process Management rămâne o
disciplină care combină capabilităţile software cu expertiza de afaceri pentru
accelerarea optimizării şi îmbunătăţirii proceselor şi pentru a facilita inovarea afacerii
unei întreprinderi. Acest aspect a fost înţeles de majoritatea companiilor furnizoare
de soluţii informatice integrate pentru întreprinderi, pentru care managementul
proceselor constituie punctul de plecare în definirea unei arhitecturi informaţionale
care să deservească afacerea întreprinderii prin utilizarea tehnologiilor existente şi nu
invers.
3 Modelarea proceselor de afaceri
3.1 Prezentare generală
Ca rezultat al creşterii complexităţii afacerilor şi, implicit, al modificării structurii
proceselor din întreprindere, se manifestă pregnant nevoia de a utiliza metode
formale de reprezentare a fluxului informaţional şi operaţional, prin procedee robuste,
derivate din analiza bazată pe modele. Sub acest aspect, s-a conturat un trend ascendent
în utilizarea de soluţii pentru simplificarea şi reprezentarea explicită a proceselor de
afaceri prin modele inteligibile, care să detalieze înlănţuirea activităţilor şi
constrângerile în executarea lor. Definirea prin modele a proceselor întreprinderii
permite analiza, îmbunătăţirea şi monitorizarea performanţelor de afaceri.
Un model al proceselor de afaceri este de obicei o diagramă prin care se reprezintă
unul sau mai multe procese de afaceri, sub forma unei secvențe de activități
desfășurate cu scopul de a realiza obiectivele pe care o organizație și-a propus să le
atingă. Modelele proceselor de afaceri includ acțiuni și evenimente, fiind arătat felul
în care acestea sunt procesate, precum și persoanele implicate, arătându-se ce
anume fac și cu ce scop. De obicei sunt reprezentate procesele desfășurate în mai
multe departamente ale organizație, uneori fiind incluse și activități aferente
organizațiilor sau sistemelor externe ce au efecte asupra proceselor interne.
Înainte de a începe construirea modelului proceselor de afaceri, este necesară
obținerea următoarelor informații:
• Rezultatul dorit al procesului;
• Punctele de început și de final (cerințele clientului și îndeplinirea cerințelor
clientului);
• Activitățile care sunt desfășurate;
• Ordinea activităților;
• Persoanele care desfășoară activitățile;
• Documentele și formularele schimbate între angajați sau primite/trimise de
la/către clienți și furnizori.
Obținerea unui model care să reprezinte corect procesele de afaceri ce au loc în
cadrul unei organizații se poate realiza doar prin implicarea activă, la elaborarea
acestuia, atât a membrilor echipei de dezvoltatori, cât și a reprezentanților
organizației.
Pentru modelarea proceselor de afaceri pot fi utilizate două standarde de tip limbaj
de notație: Business Process Modeling Notation (BPMN) și Diagramele de Activități
UML. Conform opiniei multor specialişti, BPMN este cel mai utilizat şi inteligibil
limbaj în modelarea proceselor de afaceri din cadrul întreprinderii.
3.2 Modelarea proceselor de afaceri utilizând limbajul BPMN
Business Process Modeling Notation (BPMN) este un limbaj grafic de notație pentru
modelarea proceselor de afaceri, elaborat de către Business Process Management
Initiative (BPMI). Începând cu anul 2005, BPMN este întreținut de către Object
Management Group (OMG), ca urmare a fuziunii între această organizație și BPMI.
În ianuarie 2011 OMG a publicat BPMN versiunea 2.0 care extinde domeniul de
aplicare și capabilitățile versiunii anterioare, BPMN 1.2, în mai multe zone (OMG,
www.omg.org/spec/BPMN/2.0):
• Formalizează execuția semantică a tuturor elementelor BPMN;
• Definește un mecanism de extensibilitate atât pentru extensiile Modelului de
Procese (Process Model), cât și pentru extensiile grafice;
• Rafinează compoziția și corelația Evenimentelor;
• Extinde definirea interacțiunilor umane;
• Definește un Model de Coreografie (Choreography Model).
Principalul scop al BPMN este „să ofere o notație care este uşor de înţeles de către
toţi utilizatorii de afaceri, de la analiștii de afaceri care creează proiectul inițial al
proceselor, până la dezvoltatorii tehnici responsabili pentru implementarea
tehnologiei care va efectua aceste procese şi, în final, pentru oamenii de afaceri care
vor gestiona şi monitoriza aceste procese. Astfel, BPMN creează o punte de legătură
standardizată pentru decalajul dintre proiectarea procesului de afaceri şi procesul de
implementare.” (OMG, www.omg.org/spec/BPMN/2.0)
BPMN definește o mapare a notațiilor sale vizuale pentru execuția semantică a
proceselor de afaceri prin limbaje de execuție, cum ar fi Business Process Modeling
Language (BPML), Business Process Execution Language for Web Services
(BPEL4WS), Web Services Business Process Execution Language (WS-BPEL).
BPMN permite crearea unui proces de afaceri de tip „end-to-end”, fiind conceput să
acopere multe tipuri de modelare, astfel încât să poată comunica o varietate largă de
informații la o varietate largă de audiențe. În cadrul unui model BPMN de tip „end-to-
end” sunt cuprinse trei tipuri de bază de sub-modele:
A Procese – numite și „Orchestrarea” serviciilor, în special în domeniul serviciilor
web. Sunt de două tipuri principale: private și publice. Procesele private sunt cele
interne unei anumite organizații și sunt împărțite în două categorii: executabile și ne-
executabile. Fluxul unui proces de afaceri privat poate fi conținut într-un singur
„Pool”, fără a depăși limitele acestuia. Granițele unui „Pool” pot fi depășite doar de
Flux de Mesaje (Message Flow), ce arată interacțiunile dintre procese private de
afaceri separate.
• Private executabile – sunt modelate cu scopul de a fi executate cu anumite
semantici, care descriu o înţelegere clară şi precisă a funcţionării elementelor;
• Private ne-executabile – nu includ, de regulă, informații necesare execuției,
fiind modelate cu scopul documentării comportamentului procesului;
• Publice – include doar activități care sunt utilizate pentru a comunica cu alți
„participanți”, reprezentând interacțiunea dintre un proces de afaceri privat și
un alt proces sau „participant”.
A Coreografii – spre deosebire de un „Proces”, în cazul unei coreografii nu există
nici un controlor central, entitate responsabilă sau observator al procesului. Este
definit comportamentul așteptat între mai mulți participanți ce interacționează prin
intermediul unui schimb de mesaje.
A Colaborări – sunt descrise interacțiunile dintre două sau mai multe entități de
afaceri, considerate „participanți” la colaborare. Fiecare participant este reprezentat
printr-un „pool”, iar mesajele schimbate între aceștia sunt reprezentate printr-un „flux
de mesaje” (Message Flow).
Combinând cele trei tipuri de bază de sub-modele se poate obține o reprezentare
detaliată a proceselor de afaceri, dar este recomandat ca proiectantul să se
concentreze pe un anumit aspect al analizei proceselor pentru a evita crearea unor
diagrame prea complicate, care să fie dificil de înțeles.
3.2.1 Diagrama proceselor de afaceri (BPD)
În cadrul diagramei proceselor de afaceri (BPD) sunt utilizate următoarele
concepte:
A Obiecte de flux (flow objects)
A Obiecte conectoare (connecting objects)
A Centre de responsabilităţi (swimlane objects)
A Artefacte (artifact objects)
A. Obiectele de flux sunt de trei tipuri:
Evenimentele reprezintă ceva ce se întâmplă pe parcursul unui proces sau a unei
coreografii, afectând fluxul modelului. De obicei, evenimentele au o cauză („trigger”)
si un impact („result”) și sunt împărțite în trei sub-categorii: De Început(Start),
Intermediare(Intermediate) și De Final (End).
• evenimente de start - indică unde (sau ce) va începe un proces. Evenimentele de
start pot fi de mai multe tipuri, pentru a arăta condiţiile în care se iniţiază
procesul.
• evenimente intermediare - sunt acele evenimente care pot apărea după ce un
proces a fost iniţiat, dar înainte de a se termina.
• evenimente finale - indică unde se termină un proces şi modul de finalizare al
acestuia.
Un eveniment poate fi utilizat pentru a „prinde” (catch) sau a „arunca” (throw)
un trigger eveniment.
Există mai multe tipuri de evenimente ce se pot manifesta în cadrul unei
diagrame a proceselor de afaceri. Aceste evenimente1
sunt descrise în tabelul de mai
jos:
Trigger
Descrie
re
Ti
p Start Intermediar Final
Catchi
ng
Catchin
g
Throwin
g
Throwin
g Mesaj Se ref eră la un mesaj
care este primit de la
un participant şi
poate iniţia un proces
(start), poate cauza
continuarea procesului
(intermediar) sau
poate fi expediat la
un participant, ca o
finalizare a procesului
(final).
Timp Se ref eră la un ciclu
specific (de exemplu,
fiecare zi de luni, la ora
12.00). Acest eveniment
poate iniţia un proces,
dar poate fi prezent şi
în decursul derulării
acestuia.
Condiţie Acest tip de eveniment
este declanşat când
este îndeplinită o
condiţie generată de o
regulă de business.
Poate iniţia un proces,
dar poate fi prezent şi
în cursul execuţiei
acestuia.
Semnal
Este utilizat pentru
primirea/trimiterea
unor semnale.
Evenimentul semnal
poate iniţia un proces,
se poate manifesta pe
parcursul execuţiei
Activitatea este un termen generic utilizat pentru a face referire la o etapă din munca efectuată
de către un participant la proces. Activitățile pot fi atomice (nu se mai pot diviza în alte sub-
activități) sau non-atomice (se pot diviza într-un set de sub- activități). Activitățile descrise
în cadrul unei diagrame BPMN pot fi Sub-Procese (Sub-Processes) sau Sarcini (Tasks).
- Sarcini (Tasks) - un task reprezintă o activitate atomică.
Activitate
Figura nr. 3.4 Reprezentarea grafică a unei activităţi
- Subprocese - subprocesul este o activitate compusă care este inclusă într-un
proces.
Un subproces poate conţine activităţi ce se vor executa în mod repetitiv
Punctele de decizie controlează modul în care fluxurile de secvență
interacționează în cadrul unui flux. Pot fi adăugate condiții care să permită efectuarea
unor alegeri condiționale, iar un anumit comportament poate fi reprezentat prin
marcatori interni.
Un punct de decizie se reprezintă grafic sub forma unui romb.
Punctele de decizie pot fi de mai multe tipuri:
- Bazate exclusiv pe date. Acestea sunt bazate pe expresii logice conţinând
atributul <expresie condiţie> specific ieşirii fluxului secvenţial din punctul de
decizie.
a) b)
- Bazate exclusiv pe evenimente. O decizie de acest tip reprezintă un punct de
ramificaţie în cadrul procesului, unde alternativele sunt bazate pe evenimente
ce apar într-un punct din proces.
- Inclusive. O decizie inclusivă reprezintă un punct de ramificaţie unde
alternativele sunt bazate pe expresii condiţionale, conţinute în cadrul fluxului
secvenţial de ieşire. Evaluarea unei expresii condiţionale nu exclude
evaluarea altei expresii condiţionale.
- Complexe. BPMN include punctul de decizie complex, pentru situaţiile în care
este dificil să se reprezinte în întregime celelalte tipuri de puncte de decizii.
Un punct de decizie complex poate fi utilizat pentru fuzionarea sau scindarea
fluxurilor secvenţiale din cadrul unui proces de afaceri.
- Paralele. Punctul de decizie paralel furnizează un mecanism ce sincronizează
fluxuri paralele şi creează fluxuri paralele.
B. Obiectele conectoare
În BPMN există două tipuri de obiecte conectoare:
- fluxul (secvenţial sau mesaj);
- asocierea.
- Flux Secvențial (Sequence Flow) – indică ordinea în care sunt executate
activitatile în interiorul unui proces sau a unei coreografii.
Dacă sursa unui flux secvenţial este o activitate, în locul punctului de decizie se poate
utiliza un mini-romb, care trebuie plasat la începutul fluxului secvenţial (Figura nr.
3.13). Un flux secvenţial, care este generat în urma evaluării unei expresii condiţionale,
poate fi definit ca o alternativă implicită, prin marcarea acestuia cu
„backslash”.
- Flux Mesaj (Message Flow) – arată fluxul de mesaje dintre doi participanți.
- Asociere (Association) – este utilizată pentru a lega informații (sub formă
textuală sau grafică) la obiecte flux.
O asociere dirijată (vezi Figura nr. 3.16) precizează care dintre obiectele de date sunt
de intrare şi care sunt de ieşire dintr-o activitate.
C. Centre de responsabilităţi
BPMN utilizează centrele de responsabilităţi („swimlanes”) pentru separarea
unor zone din cadrul procesului. Centrele de responsabilităţi folosite în cadrul
diagramelor proceselor de afaceri pot fi:
- Pool – reprezintă un participant la o colaborare. Interacțiunea dintre pool-uri se
realizează prin intermediul fluxurilor mesaj.
Lane – subdivizează procesul sau un pool, cu scopul organizării și clasificării
activităților.
De exemplu, o facultate (participant) poate avea următoarele compartimente (partiţii):
Decanat, secretariat, catedre/departamente (Figura nr. 3.18).
D. Artefacte
Artefactele au rolul de a aduce informaţii suplimentare unei diagrame. BPMN
utilizează trei artefacte standard:
- Obiectul-data - precizează datele necesare unei activităţi, precum şi cele
produse de către acestea.
Adnotarea - adaugă informații adiționale, sub formă de text, diagramei BPMN
sau unor părți ale acesteia.
Text
Figura nr. 3.20 Reprezentare grafică pentru
artefactul Adnotare
- Grupul furnizează un mecanism vizual de grupare a elementelor din cadrul
unei diagrame
3.2.2 Studii de caz
3.2.2.1 Modelarea procesului de afaceri privind aprovizionarea cu mărfuri de la
furnizor
În vederea aprovizionării cu mărfuri, societatea încheie un contract cu un furnizor
(activitatea „Încheiere contract”) - Figura nr. 3.22. Contractul este reprezentat printr-
un obiect dată asociat fluxului de mesaj dintre cei doi participanţi la proces: furnizorul
şi societatea.
O primă condiţie pentru ca aprovizionarea să poată fi realizată este legată de
termenul de valabilitate a contractului. În cadrul modelului, punctul de ramnificaţie
pentru alternativele care vor fi urmate în funcţie de îndeplinirea sau neîndeplinirea
acestei condiţii este reprezentat print-un punct de decizie bazat exclusiv pe
evenimente .
În cazul în care termenul de valabilitate a expirat, contractul încetează. Această
situaţie este reprezentată prin activitatea „Încheiere contract”, activitate care
generează obiectul dată „Contract închis”.
În situaţia în care contractul se află în termenul de valabilitate (alternativa implicită
din cadrul modelului, marcată prin caracterul „\”), se verifică o a doua condiţie, legată
de valoarea mărfurilor livrate, valoare care nu trebuie să depăşească valoarea
contractată a mărfurilor:
• Dacă valoarea mărfurilor livrate depăşeşte valoarea contractată, contractul
încetează;
• Dacă valoarea mărfurilor livrate <= valoarea contractată, se realizează
aprovizionarea cu mărfuri (sub-procesul „Aprovizionare mărfuri”).
Pe baza unui contract societatea se poate aproviziona de mai multe ori cu mărfuri de la
furnizor, motiv pentru care sub-procesul „Aprovizionare mărfuri” este repetitiv,
aspect marcat prin poziţionarea simbolului în partea inferioară a sub-procesului.
După ce primeşte mărfurile şi factura de la furnizor, societatea plăteşte factura. Plata
facturii implică desfăşurarea mai multor activităţi, fiind reprezentată în model prin sub-
procesul „Plată factură” care poate fi detaliat în funcţie modalitatea concretă prin care
se realizează plata. Pentru ca plata să se realizeze este necesară atât primirea mărfurilor,
cât şi primirea facturii. Acest aspect este reprezentat printr-un punct de decizie paralel
prin care sunt compuse cele două fluxuri aferente activităţilor
„Primire factură” şi „Primire
mărfuri”.
Procesul de aprovizionare cu mărfuri de la furnizor se încheie atunci când au fost s-a
realizat aprovizionarea cu mărfuri la nivelul valorii contractate sau atunci când
contractul încetează.
3.2.2.2 Modelarea procesului de afaceri privind contractarea creditului
Procesul de contractare a unui credit bancar implică interacţiuni între doi participanţi (Banca şi Antreprenorul), reprezentaţi sub forma unor pool-
uri.
Antreprenorul depune actele necesare obţinerii unui credit bancar (activitatea „Depunere acte dosar credit”). Actele depuse de către
antreprenor la dosarul de credit (cererea de credit, balanţa, bilanţul, garanţiile depuse, fluxul de numerar previzionat pe perioada creditului,
bugetul de venituri şi cheltuieli pe perioada creditului şi proiectul de investiţie pentru suma obţinută prin credit) sunt reprezentate în cadrul
modelului prin de obiecte de date asociate fluxului de mesaj dintre Antreprenor şi Bancă.
Banca înregistrează dosarul de credit (activitatea „Înregistrare dosar credit”) şi apoi desfăşoară o serie de activităţi legate de analiza dosarului,
activităţi care depind de normele care reglementează activitatea fiecărei bănci şi care sunt reprezentate în cadrul modelului prin sub-procesul
Analiză dosar credit.
În urma analizei dosarului de credit:
• banca îi va comunica antreprenorului rezultatul acesteia (evenimentele intermediare de tip mesaj şi ) şi
• va desfăşura o serie de activităţi în funcţie de rezultatul analizei (punctul de decizie bazat exclusiv pe date ):
o în situaţia în care creditul este respins dosarul de credit este arhivat (activitatea „Arhivare dosar credit”) şi procesul se încheie
(evenimentul final );
o atunci când creditul este aprobat banca întocmeşte contractul de credit
(activitatea „Întocmire contract credit”).
Contractul de credit este transmis antreprenorului pentru semnare. Antreprenorul semnează contractul de credit. După ce primeşte contractul de
credit semnat, banca virează în contul antreprenorului suma acordată sub formă de credit (activitatea
„Virare sumă credit”). Suma este încasată de către antreprenor.
Bibliografie
· Cozgarea, G. (2010), Metodologii orientate pe obiecte utilizate in proiectarea sistemelor informatice, Editura Infomega
· OMG (2011), Business Process Model and Notation (BPMN). Version 2.0,
http://www.omg.org/spec/BPMN/2.0
· Havey, M. (2005), Essential Business Process Modeling, Editura O'Reilly
Media
· Basu, A., Blanning, R. W., (2003). “Synthesis and Decomposition of Processes in Organizations”, Information Systems Research.
· Porter, M. E., Millar, V. E., (1985). “How Information Gives You Competitive
Advantage”, Harvard Business Review.
· Ward-Dutton, N., Macehiter, N., (2005) „Business Process Management, a holistic view”, DMReview.