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

Sa

r

r

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.