procese de afaceri - bpmn

Modelarea proceselor

de afaceri Suport de curs

1

CUPRINS

1 CONCEPTUL DE PROCES DE AFACERE ÎN CADRUL UNEI ORGANIZAŢII ... 2

2 MANAGEMENTUL PROCESELOR DE AFACERI .............................................. 4

3 MODELAREA PROCESELOR DE AFACERI ...................................................... 6

3.1 PREZENTARE GENERALĂ ...................................................................................... 6

3.2 MODELAREA PROCESELOR DE AFACERI UTILIZÂND LIMBAJUL BPMN ........................ 7

3.2.1 Diagrama proceselor de afaceri (BPD) ...................................................... 9

3.2.2 Exemple ................................................................................................... 17

4 MODELAREA ŞI DOCUMENTAREA PROCESELOR DE AFACERI ÎN

SCOPUL IMPLEMENTĂRII UNUI SISTEM DE MANAGEMENT AL

DOCUMENTELOR ELECTRONICE ÎN CADRUL UNEI COMPANII – STUDII DE

CAZ ........................................................................................................................... 21

2

Modelarea 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) (Tudor, 2013). Orice activitate este definită prin

ansamblul de sarcini din care este alcătuită şi care sunt asignate indivizilor din cadrul

3

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,

4

î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 (Tudor, 2013).

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.

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.

5

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

(adaptare după Ward-Dutton & Macehiter, 2005)

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

6

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

7

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

http://www.omg.org/spec/BPMN/2.0

8

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:

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

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.

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


9

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:

Obiecte de flux (flow objects)

Obiecte conectoare (connecting objects)

Centre de responsabilităţi (swimlane objects)

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.

Figura nr. 3.1 Eveniment start

evenimente intermediare - sunt acele evenimente care pot apărea după ce un

proces a fost iniţiat, dar înainte de a se termina.

Figura nr. 3.2 Eveniment intermediar

evenimente finale - indică unde se termină un proces şi modul de finalizare al

acestuia.

Figura nr. 3.3 Evenimente finale

10

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 Descriere

Tip

Start Intermediar Final

Catching Catching Throwing Throwing

Mesaj Se referă 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 referă 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

acestuia, dar poate şi finaliza un

proces.

Multiple Pot exista multiple căi de iniţiere

a unui proces (start), multiple

mecanisme de declanşare a

unui eveniment (intermediar) şi

consecinţe multiple de a sfârşi

un proces (final).

1 Preluare din Cozgarea Gabriel, Metodologii orientate pe obiecte utilizate in proiectarea sistemelor informatice, Editura Infomega, 2010

11

Trigger Descriere

Tip

Start Intermediar Final

Catching Catching Throwing Throwing

Link Este un mecanism pentru

conexiunea a două secţiuni ale

unui proces.

Compensaţia Fiecare activitate completă care

este subiectul unei compensări,

va fi compensată în ordinea

inversă terminării activităţilor.

Pentru a fi compensată, o

activitate trebuie să aibă ataşat

evenimentul intermediar.

Error Indică apariţia unei erori.

Cancel Acest eveniment semnifică

anularea execuţiei unui

subproces.

Sfârşit Indică sfârşitul procesului de

afaceri

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

Figura nr. 3.4 Reprezentarea grafică a unei activităţi

Pentru a diferenţia tipurile de comportament reprezentate prin sarcini se pot utilza

următoarele notaţii:

Tip sarcină Descriere Notaţie

Sarcină Serviciu (Service Task)

Sarcină care foloseste un fel de serviciu (spre exemplu Serviciu Web sau o aplicaţie automata).

Activitate

12

Tip sarcină Descriere Notaţie

Sarcină Trimitere (Send Task)

Sarcină prin care se trimite un mesaj către un participant extern.

Sarcină Primire (Receive Task)

Sarcină creată să aştepte sosirea unui mesaj de la un participant extern.

Sarcină Utilizator (User Task)

Sarcină executată de o persoană cu ajutorul unei aplicaţii software.

Sarcină Manuală (Manual Task)

Sarcină executată fără ajutorul unui motor de execuţie al unui proces de afaceri sau al unei aplicaţii.

Sarcină Regulă de afaceri (Business Rule Task)

Sarcină care oferă un mecanism prin care se furnizează date de intrare unui Motor de Reguli de Afaceri şi se obţin date de ieşire în urma efectuării unor calcule.

Sarcină Scriere (Script Task)

Sarcină executată de un motor de procese de afaceri.

- Subprocese - subprocesul este o activitate compusă care este inclusă într-un

proces.

Figura nr. 3.5 Reprezentarea grafică a unui subproces

Un subproces poate conţine activităţi ce se vor executa în mod repetitiv (Figura nr.

3.6).

Subproces

13

Figura nr. 3.6 Subproces 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.

Figura nr. 3.7 Variante de reprezentarea grafică a punctului de decizie bazat exclusiv pe date

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

Figura nr. 3.8 Punctul de decizie bazat exclusiv pe evenimente

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

Figura nr. 3.9 Reprezentare grafică a punctului de decizie inclusiv

a) b)

Subproces

14

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

Figura nr. 3.10 Reprezentarea grafică a punctului de decizie complex

- Paralele. Punctul de decizie paralel furnizează un mecanism ce sincronizează

fluxuri paralele şi creează fluxuri paralele.

Figura nr. 3.11 Reprezentarea grafică a punctului de decizie paralel

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.

Figura nr. 3.12 Un flux secvenţial

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

Figura nr. 3.13 Flux secvenţial conditional implicit

15

Flux Mesaj (Message Flow) – arată fluxul de mesaje dintre doi participanți.

Figura nr. 3.14 Flux mesaj

- Asociere (Association) – este utilizată pentru a lega informații (sub formă

textuală sau grafică) la obiecte flux.

Figura nr. 3.15 Asocierea

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.

Figura nr. 3.16 Asociere dirijată

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.

Figura nr. 3.17 Interacţiunea dintre participanţi (pool-uri)

- Lane – subdivizează procesul sau un pool, cu scopul organizării și clasificării

activităților.

Part

icip

ant

2

Part

icip

ant

1

Flux mesaj A Flux mesaj B

16

De exemplu, o facultate (participant) poate avea următoarele compartimente (partiţii):

Decanat, secretariat, catedre/departamente (Figura nr. 3.18).

Figura nr. 3.18 Reprezentarea grafică pentru partiţii (lane-uri)

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.

Figura nr. 3.19 Reprezentarea grafică a unui obiect data

- Adnotarea - adaugă informații adiționale, sub formă de text, diagramei BPMN

sau unor părți ale acesteia.

Figura nr. 3.20 Reprezentare grafică pentru artefactul Adnotare

- Grupul furnizează un mecanism vizual de grupare a elementelor din cadrul

unei diagrame.

Figura nr. 3.21 Reprezentare grafică pentru artefactul Grup

Name [Stare]

Text

Facu

ltate

D

eca

nat

Secr

eta

riat

Cate

dre

/Depart

am

ente

17

3.2.2 Exemple

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

18

Aprovizionare marfuri

Furn

izor

Socie

tate Incheiere

contract

Primire factura

Contract[Deschis]

Primire marfuri

Factura[Primita]

Marfuri[Primite]

Incetarecontract

Contract aflat in termen de valabilitate

Expirare termen de valabilitate

Contract[Inchis]

Valoarea marfurilor livrate<=Valoarea contractata a marfurilor

Valoarea marfurilor livrate>Valoarea contractata a marfurilor

Plata factura

Figura nr. 3.22 Modelarea procesului de afaceri privind aprovizionarea cu mărfuri de la furnizor

19

Exemplul 2. Modelarea procesului de afaceri privind contractarea unui credit bancar

Procesul de contractare a unui credit bancar implică interacţiuni între doi participanţi

(Banca şi Antreprenorul), reprezentaţi sub forma unor pool-uri (Figura nr. 3.23).

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.

20

Banca

Antr

epre

nor

Depunere acte dosar credit

Inregistrare dosar credit

Cerere credit

Balanta

Bilant

Flux de numerar previzionat

Buget de venituri si cheltuieli previzionat

Garantii

Proiect de investitie

Analiza dosar credit

Credit respins

Intocmire contract credit

Creditaprobat

Semnare contract credit

Credit respins

Credit aprobat

ContractCredit

[Nesemnat]Comunicare rezultat analiza dosar credit

Incasare suma credit

Virare suma credit

ContractCredit

[Semnat]

Arhivare dosar credit

Figura nr. 3.23 Modelarea procesului de afaceri privind contractarea unui credit bancar

21

4 Modelarea şi documentarea proceselor de afaceri în

scopul implementării unui sistem de management al

documentelor electronice în cadrul unei companii –

studii de caz

În ultimii ani s-a constatat creştere tot mai mare a interesului companiilor în înlocuirea

documentelor pe hârtie cu documente gestionate în mod electronic. Gestiunea

electronică a documentelor reduce considerabil volumul de muncă implicat de

generarea, transmiterea şi stocarea informaţiilor. Sistemele informatice de

management al documentelor electronice (EDMS – Electronic Document

Management Systems) furnizează instrumente pentru stocarea, indexarea, regăsirea

şi schimbul de documente. Aceste sisteme prezintă o serie de avantaje faţă de

varianta stocării documentelor pe hartie, cum ar fi: reducerea timpului necesar

transmiterii documentelor, editarea facilă a documentelor, urmărirea ciclului de viaţă

a documentelor, accesarea rapidă a documentelor de către orice angajat autorizat,

simplificarea activităţii de securizare a informaţiilor confidenţiale prin criptarea

documentelor electronice cu controale de acces utilizând parole, etc.

Implementarea unui sistem informatic de gestiune al documentelor în cadrul unei

companii presupune analiza proceselor de afaceri ale acesteia şi a fluxului de

documente implicate de acestea. Acest lucru se poate realiza prin modelarea

proceselor desfăşurate în cadrul companiei utilizând un limbaj de modelare a

proceselor de afaceri (spre exemplu BPMN) şi prin descrierea narativă a acestuia. Pe

baza analizei proceselor din cadrul companiei se stabilesc funcţionalităţiile aplicaţiei

informatice care va fi utilizată pentru gestiunea electronica a documentelor.

Documentaţia aferentă sistemului de gestiune electronică a documentelor care

urmează să fie implementat într-o companie include o descriere detaliată a soluţiei

informatice propuse pentru implementarea fiecărui proces desfăşurat în cadrul

companiei. Această descriere include, de regulă, o descriere narativa a soluţiei

informatice propuse, o prezentare a structurii formularelor electronice, precum şi o

descriere a fluxului de evenimente.

În continuare sunt prezentate două studii de caz care cuprind analiza unor procese

desfăşurate în cadrul unei companii şi descrierea soluţiei informatice propuse pentru

gestiunea electronică a documentelor utilizate în cadrul acestor procese.

22

Studiul de caz 1

Denumire proces: Întocmire contracte de muncă angajaţi

Scopul implementării procesului: Intocmirea contractelor de munca pentru

angajatii companiei. Se executa in urma emiterii unei decizii a Consiliului de

administratie.

Descriere sumara a procesului:

In urma sustinerii concursurilor pentru ocuparea unor pozitii din statul de functii,

Consiliul de Administratie intocmeste o decizie de angajare care este comunicata

catre Departamentul Resurse Umane pentru ducere la indeplinire.

Departamentul Resurse Umane intocmeste contractul de munca pe baza deciziei

si dupa ce primeste setul de documente pe care viitorul angajat trebuie sa-l

prezinte inaintea angajarii.

Contractul de munca parcurge un flux prestabilit pentru obtinerea semnaturilor

autorizate.

Dupa obtinerea tuturor semnaturilor, contractul este retrimis la DRU

(Departamentul Resurse Umane) si este arhivat dupa ce este semnat de angajat.

Actori: Director DRU, Serviciu Juridic, Director Economic, CFP (Controlul Financiar

Preventiv), Director General

Initiator: Reprezentant Departament Resurse umane

Descriere narativa solutie propusa:

Aplicatia va pune la dispozitie formularul electronic si elemente de control ce vor

permite crearea unui dosar electronic al angajatului.

Reprezentantul DRU responsabil de ducerea la indeplinire a deciziilor conducerii

privind incheierea contractelor de munca cu diverse categorii de personal, se va

conecta la aplicatie cu credentialele sale.

Aplicatia va pune la dispozitie mecanismul de a crea dosare noi si de a actualiza

informatiile care se refera la angajati.

Dupa completarea formularelor se va crea folderul cu nume_prenume.CNP al

angajatului.

Se va complete un formular cu urmatoarele sectiuni:

Prima sectiune este dedicata completarii datelor din decizia Consiliului de

Administratie.

Sectiunea a doua este dedicata completarii datelor personale ale

angajatului.

Date Personale

Nume

23

Prenume

CNP

Data nasterii

Adresa de domiciliu

Telefon fix

Telefon mobil

Adresa email.

Statut profesional

Ultima forma de invatamant absolvita

Locul de munca

Forma de incadrare

Cont IBAN

Sectiunea a treia este dedicata completarii datelor care vor fi tiparite pe

contractul individual de munca.

Dupa completarea formularului se vor atasa documentele obligatorii solicitate la

angajare.

La salvarea informatiilor din formular se creaza folderul prin care se identifica unic

un angajat.

Numele dosarului electronic asociat angajatului va fi format din

Nume_Prenume.CNP.

Intr-o sectiune separata a folderului angajatului vor fi incarcate toate deciziile

si/sau procesele verbale care au legatura cu angajarea sau cu statutul de angajat.

Salvarea datelor va fi insotita de o notificare prin care reprezentantul

Departamentului Resurse Umane este instiintat ca a fost creat cu succes dosarul

angajatului, urmand ca formularele sa fie trimise pe flux in vederea obtinerii

aprobarilor finale /semnaturilor celor implicati in procesul de angajare.

Dupa obtinerea tuturor semnaturilor si avizelor de pe flux, documentul se intoarce

la DRU pentru tiparire si arhivare.

Se va implementa la nivelul aplicatiei un mecanism de cautare dupa CNP,

MARCA, NUME.

Structura si descrierea formularelor electronice:

Crearea dosarului si incarcarea cu documente va fi realizata de catre un reprezentant

al Departamentului Resurse Umane.

Se va crea un formular cu doua sectiuni: A- datele personale ale angajatului, B-

datele specifice contractului de munca.

Sectiunea A va contine urmatoarele campuri:

Date Personale

Nume

24

Prenume

CNP

Data nasterii

Adresa de domiciliu

Telefon fix

Telefon mobil

Adresa email.

Statut profesional

Ultima forma de invatamant absolvita

Locul de munca

Forma de incadrare

Cont IBAN

Loc viitor de munca

Directie

Serviciu

Birou

Funcţia

Atasamente :

cererea de înscriere la concurs, însoţită de curriculum vitae;

copia cărţii de identitate / buletin de identitate;

copii după documentele care pot atesta nivelul studiilor

alte acte care atestă efectuarea unor specializări,

copiile documentelor care atestă îndeplinirea condiţiilor specifice;

copia carnetului de muncă, conform cu originalul, sau după caz, o

adeverinţă care să ateste vechimea în muncă, în meserie şi/sau în

specialitatea studiilor;

cazier judiciar (original) sau o declaraţie pe propria răspundere că

nu are antecedente care să îl facă incompatibil cu funcţia pentru

care candidează.

adeverinţă medicală (original) care să ateste starea de sănătate

corespunzătoare, eliberată cu cel mult 6 luni anterior derulării

concursului, de catre medicul de familie al candidatului sau de către

unităţile sanitare abilitate (adeverinţa medicală va conţine în clar,

numărul, data şi calitatea acestuia, în formatul standard stabilit de

Ministerul Sănătăţii);

alte documente relevante (calificări, cursuri, diplome).

Dupa completarea tuturor datelor obligatorii din sectiunile formularului se vor salva

datele.

Salvarea va crea si folderul noului angajat ce va avea structura nume_prenume.CNP.

25

Inainte de trimiterea pe fluxul de semnaturi si validari, se pot face corectii sau stergeri

complete ale formularelor si implicit ale folderelor create.

Dupa trimiterea pe flux, nu se mai pot face modificari asupra datelor din formulare

decat daca unul dintre actorii participanti la proces vor retrimite catre initiator

documentele pentru efectuare de modificari.

Fluxul standard de lucru

Repre

zenta

nt

DRU

Directo

r D

RU

Serv

iciu

juridic

Directo

r econom

icCFP

Directo

r genera

l

Primeste o decizie de angajare

Intocmire contract de

munca

Refacere contract

Semnare contract

Verificare incadrare juridica

Semneaza contract

Viza CFP

Semneaza contract

Contract ok

Contract ok

Contract ok

Contract ok

Contract ok

Contract finalizat

26

Descrierea fluxului normal de evenimente:

1. Departamentul Resurse Umane primeste o decizie de angajare a unui angajat.

2. Reprezentantul Departamentului Resurse Umane acceseaza aplicatia folosind un

username, o parola si un cod generat de dispozitiv OTP.

3. Daca autentificarea este corecta se acorda acces la aplicatie in sectiunea

dedicata „Dosare Angajati”

4. Este selectat link-ul/butonul „Creare Dosar Nou Angajat”

5. Este afisat formularul de creare a dosarului.

6. Se completeaza datele din sectiunile A si B.

7. Se incarca toate documentele necesare la angajare (din lista atasamentelor).

8. Se pot face salvari intermediare ale datelor din formulare prin apasarea butonului

„Salvare date” dar fara crearea dosarului angajatului in structura de foldere.

9. Se salveaza datele finale prin apasarea butonului „Creare dosar”; se genereaza

folder-ul din numele, prenumele si codul numeric personal dupa regula

Nume_Prenume.CNP in subfolderul categoriei din care face parte angajatul

(didactic sau administrativ).

10. Se afiseaza mesajul de confirmare a creerii folderului angajatului „ Dosar angajat

„nume_prenume.CNP” a fost creat – Se asteapta validare”.

11. La finalizarea operatiunilor se apasa butonul „Finalizare Operatiune”.

12. Butoane disponibile : „creare dosar nou angajat” „salvare date”, „abandon” ,

„finalizare operatiune”, „Retur pentru corectare /modificare”.

13. Se trimite notificare catre Directorul DRU pentru verificarea si semnarea unui

contract de munca pentru un angajat nou.

14. Directorul DRU acceseaza aplicatia fie printr-un un link incorporat in email sau

prin autentificare in aplicatie folosind autentificarea OTP.

15. Autentificarea este corecta.

16. Directorul DRU nu poate face actualizari ale datelor din formulare. Poate aproba

sau respinge (trimitere pentru refacere catre initiator) formularul/documentul.

17. Directorul DRU verifica completitudinea si corectitudinea datelor

18. Directorul DRU apasa butonul “aprobare”, respectiv “trimitere pe flux”.

19. Documentul trimis pe flux va fi semnat electronic cu semnatura Director DRU.

20. Documentul este trimis pe flux si se trimite unui mesaj de notificare pentru

verificare / aprobare catre Reprezentant Serviciu Juridic.

21. Reprezentant Serviciu Juridic acceseaza aplicatia fie printr-un un link incorporat in

email sau prin autentificare in aplicatie folosind autentificarea OTP.


23. Reprezentant Serviciu Juridic nu poate face actualizari ale datelor din formulare.

Poate aproba sau respinge (trimitere pentru refacere catre initiator)

formularul/documentul.

24. Reprezentant Serviciu Juridic verifica completitudinea si corectitudinea datelor

25. Reprezentant Serviciu Juridic apasa butonul “aprobare”, respectiv “trimitere pe

flux”.

27

26. Documentul trimis pe flux va fi semnat electronic cu semnatura Reprezentant

Serviciu Juridic.


verificare / aprobare catre Director Economic.

28. Director Economic acceseaza aplicatia fie printr-un un link incorporat in email sau



30. Director Economic nu poate face actualizari ale datelor din formulare. Poate

aproba sau respinge (trimitere pentru refacere catre initiator)


31. Director Economic verifica completitudinea si corectitudinea datelor

32. Director Economic apasa butonul “aprobare”, respectiv “trimitere pe flux”.

33. Documentul trimis pe flux va fi semnat electronic cu semnatura Director

Economic.


obtinerea vizei de validare/aprobare catre Reprezentant CFP

35. Reprezentant CFP acceseaza aplicatia fie printr-un un link incorporat in email sau



37. Reprezentant CFP nu poate face actualizari ale datelor din formulare. Poate

aproba sau respinge (trimitere pentru refacere catre initiator)


38. Reprezentant CFP verifica completitudinea si corectitudinea datelor

39. Reprezentant CFP apasa butonul “aprobare”, respectiv “trimitere pe flux” .

40. Documentul trimis pe flux va fi semnat electronic cu semnatura Reprezentant CFP


obtinerea vizei de validare/aprobare catre Director General.

42. Director General acceseaza aplicatia fie printr-un un link incorporat in email sau



44. Director General nu poate face actualizari ale datelor din formulare. Poate aproba

sau respinge (trimitere pentru refacere catre initiator) formularul/documentul.

45. Director General verifica completitudinea si corectitudinea datelor

46. Director General apasa butonul “aprobare”, respectiv “trimitere pe flux” .

47. Documentul trimis pe flux va fi semnat electronic cu semnatura Director General.


Reprezentant DRU.

49. Reprezentant DRU acceseaza aplicatia fie printr-un un link incorporat in email sau



51. Reprezentant DRU verifica existenta semnaturilor electronice pe contract si apasa

butonul „ contract valid”.

28

52. Apasarea butonului „contract valid” va permite:

a. Validarea folderului angajatului (semnifica posibilitatea de a vizualiza si

incarca documente in dosar in conformitate cu matricea rolurilor)

b. Generare si posibilitatea de tiparire a Contractului de munca

c. Incarcarea Contractului de munca in folderul angajatului

d. Generarea si tiparirea Deciziei

e. Incarcarea deciziei in folderul angajatului.

f. Notificare director directie referitor la ocuparea unei pozitiei vacante

(Numele angajat, data inceperii activitatii, pozitia de incadrare, numar

marca)

g. Notificare angajat

53. Se vor prevedea butoane pentru generare documente, respectiv tiparire.

54. Documentele care au parcurs fluxul vor avea asociate numere de intrare/iesire

conforme cu regulile de alocare a numerelor din registrele interne, generate

pentru toate entitatile organizationale participante la flux.

55. Tiparirea numerelor de inregistrare se va face conform regulilor precizate la

definirea registrelor de intrare-iesire ale fiecarei entitati organizationale.

Fluxul de incheie.

29

Studiul de caz 2

Denumire proces: Intocmire note fundamentare contracte cercetare

Scopul implementării procesului: Notele de fundamentare contracte de cercetare,

(numite si Nota Fundamentare Manopera) sunt elaborate de catre managerii de

proiect pentru plata orelor lucrate in cadrul unor proiecte de cercetare pe baza

pontajelor individuale completate de membrii echipei de cercetare. Documentele

generate sunt trimise catre Departamentul Financiar pentru verificarea disponibilitatii

sumelor in cont si pentru centralizare. Odata finalizate, notele sunt trimise insotite de

centralizatoare catre Directorul Economic pentru validare si apoi catre Departamentul

Resurse Umane pentru efectuarea platilor.

Descriere sumara a procesului:

Pentru contractele de cercetare incheiate de companie cu institutii diverse, sunt

folosite resurse umane interne sau externe.

Planul de proiect pentru fiecare contract in parte prevede numarul de resurse

umane, tarifele orare cat si numarul de ore estimate a fi prestate.

In urma prestatiilor pe fiecare faza de proiect, persoanele cu activitati in cadrul

proiectului vor trebui sa-si primeasca drepturile banesti pentru prestatiile

executate.

Periodic, managerul de proiect intocmeste o nota de fundamentare pentru plata

manopera.

Nota de fundamentare este intocmita sub forma tabelara si contine lista tuturor

participantilor carora trebuie sa li se plateasca sume de bani pentru activitatile

prestate in proiect in diferite faze.

Prevederile din Nota de fundamentare trebuie sa fie in conformitate cu Pontajul

lunar pentru proiecte de cercetare.

Un economist din Departamentul Financiar consolideaza toate notele pentru care

sunt necesare efectuari de plati si pentru care exista disponibilitate in cont pentru

plata.

Aprobarile pentru efectuarea platilor sunt date de catre directorul economic.

Toate documentele sunt transmise catre Departamentul Resurse Umane in forma

consolidata si nominala (pentru fiecare proiect in parte).

Departamentul Resurse umane– salarizare face demersurile pentru plata

sumelor aprobate.

Toate notele si centralizatoarele sunt arhivate.

Actori: Economist Departamentul Financiar, Director Economic, Directorul Resurse

Umane, Biroul de Plati

Initiator: Managerul de proiect

30

Descriere narativa solutie propusa:

Aplicatia va pune la dispozitie formularul electronic si elemente de control ce vor

permite introducerea datelor direct in tabelul pentru note de fundamentare.

Managerii de proiect vor avea la dispozitie o functie de aducere a datelor din

Pontajele individuale de cercetare intocmite pentru evidenta orelor lucrate in

proiecte si vor completa manual acele sectiuni de date necesare in notele de

fundamentare manopera.

Datele se salveaza si trimit pe flux catre Departamentul Financiar folosind o

notificare la finalizarea completarii formularului.

Economistul din Departamentul Financiar, verifica disponibilul din conturile

fiecarui proiect pentru linia bugetara Resurse Umane.

In cazul in care exista fonduri, se consolideaza datele in formularul centralizator.

Daca nu exista fonduri, se va astepta pana cand conditia sold disponibil este

adevarata.

Directorul economic aproba toate notele de fundamentare pentru care exista

fonduri.

Dupa aprobare, notele de fundamentare si centralizatorul sunt transferate catre

Departamentul Resurse Umane- salarizare.

Departamentul Resurse Umane-salarizare transmite documentele de plata catre

Biroul Plati.

Documentele sunt arhivate.

Procesul se incheie.

Structura si descrierea formularelor electronice:

Pasul1. Formularul 1 este completat de catre managerul de proiect.

Formularul electronic va avea o structura standard formata din:

Header:

ALFA S.A.

Solicitant : {numele manager de proiect}

Titlu proiect : .............................................................

Contract nr.

Programul:

Tipul proiectului:

31

Cod proiect:

Faza

Nr crt

CNP Nume

prenume Functia

Salariu orar

Numar de ore Fond de salarii

Total brut Luna 1

Luna 2

Luna 3

Luna 1

Luna 2

Luna 3

1

T X Y Z T*X T*Y T*Z T*(X+Y+

Z)

2

Exista disponibil in cont? ☒ Cheltuieli de personal (salarii si

contributii asupra salariilor): T*(X+Y+Z) *

CA

CA = procent contributii angajator

Lista de semnaturi: Director de proiect, Director Economic

Se va asigura si o sectiune de comentarii (bloc de tip text) care va fi obligatoriu

completata daca nu se aproba cererea. Odata aprobat, datele din formular vor fi

disponibile pentru consolidare in centralizator si vor putea fi generate in sablonul care

se va tipari si se va arhiva.

Pasul 2. Formularul 2

Toate notele de fundamentare manopera care au disponibil in cont sunt consolidate

in urmatorul tabel:

Nr.crt. Director de proiect Tip Proiect Contract nr. TOTAL inclusiv contrib

angajator

1

T*(X+Y+Z) * CA

2

…..

Total Sum( col 1….n)

Lista de semnaturi: Economist, Director Economic

32

Fluxul standard de lucru

Manager

pro

iect

Econom

ist

Directo

r econom

icResurs

e U

mane -

sala

rizare

Completeaza notele de

fundamentare

Se colecteaza note de fundamentare pana la o data limita

Verifica disponibilitate bani in cont pt linia de proiect

Exista disponibil in cont?

Consolideaza datele in

centralizatorDa

Mai sunt cereri valide?

Nu

Se seteaza un numar implicit de zile de asteptare

Da

Verifica si valideaza

centralizator

Nu

Datelesunt ok?

Nu

Elaboreaza documente de

plata

Da

Trimite documente de

plata catre Birou Plati

Arhiveaza documente

Descrierea fluxului normal de evenimente:

56. Un manager de proiect acceseaza aplicatia folosind un username, o parola si un

cod generat de dispozitiv OTP.

57. Daca autentificarea este corecta este prezentata lista formularelor la care are

acces utilizatorul.

33

58. Este selectat link-ul “Note fundamentare plata manopera”. Apare fereastra de

dialog intermediara in care se precizeaza codul proiectului, luna de inceput a

formularului, respectiv numarul de luni pentru care acesta va fi completat.

Butoanele disponibile sunt „Abandon” si „Continuare”.

59. Sectiunile formularului 1 sunt completate manual cu datele necesare.

60. Se apasa butonul „Incarcare date din pontaj”.

61. Campurile calculate vor contine valori conforme regulilor de calcul prestabilite.

62. Butoane disponibile pentru formular: “Salvare Date”,, “Finalizare operatiune ”,

“Ștergere formular”, “Trimitere pentru aprobare” „Incarca date din Pontaj”.

63. La finalizarea operatiunii de completare a formularului managerul de proiect

apasa butonul “Salvare Date”, urmat de „Finalizare Operatiune”.

64. Operatiunea de la pasul anterior permite activarea butonului “Trimitere pentru

aprobare”. Acest buton devine activ numai dupa completarea tabelului salvarea

datelor si finalizarea operatiunii.

65. Documentul este trimis pe flux si se trimite un mesaj de informare catre

reprezentant Departament Financiar.

66. Se reiau pasii 1-9 pentru toti managerii de proiect care intocmesc „Nota de

fundamentare pentru plata manopera”.

67. Responsabilul economist din Departamentul Financiar acceseaza aplicatia prin

autentificare cu username, parola si string generat de device-ul OTP.

Autentificarea este corecta.

68. Butoane disponibile: “Salvare date”,, “Finalizare operatiune ”, „Respingere”

“Abandon”, “Consolidare in centralizator”, „Trimitere pt avizare la Director

economic”.

69. Responsabilul Economist din Departamentul Financiar primeste un mesaj pe

email prin care este informat ca este necesara verificarea disponibil cont,

respectiv centralizarea in vederea executarii platilor catre prestatori.

70. Responsabilul economist din Departamentul Financiar acceseaza formularele

trimise de managerii de proiect, verifica disponibilul din cont, si dupa caz bifeaza

controlul din formularul 1. Daca exista disponibil se trece la pasul urmator. Exista

disponibil. Consolidarea se poate face. (In caz contrar nu se face consolidarea.

Se asteapta un numar predefinit de zile si se reia operatia de verificare, respectiv

centralizare pentru acele formulare pentru care exista disponibil.)

71. Se apasa butonul „Consolidare in centralizator”.

72. Se verifica toate inregistrarile din formularul 2, se salveaza datele si se trece la

solicitarea urmatoare.

73. Se repeta pasii 14-16 pentru toate solicitarile primite pana la terminarea acestora.

74. Se apasa butonul „Finalizare operatiune” urmat de „Trimitere pentru avizare la

Director economic”.

75. Se trimite notificare catre Directorul economic referitor la existenta unui

centralizator pentru „note de fundamentare plata manopera”.

34

76. Directorul economic acceseaza aplicatia prin autentificare cu username, parola si

string generat de device-ul OTP. Autentificarea este corecta.

77. Butoane disponibile: “Aprobare”, “Finalizare operatiune ”, „Respingere”

“Abandon”, “Trimitere la Departamentul Resurse Umane- Salarizare”

78. In urma consultarii formularelor trimise se da aviz favorabil.

79. Directorul economic apasa butonul „Aprobare” si apoi „Trimitere spre

Departamentul Resurse Umane- Salarizare”.

80. Directorul economic apasa „Finalizare operatiune”.

81. Odata cu aprobarea Directorului Economic se trimite notificare catre Biroul plati si

catre Economist Departament Financiar referitor la un nou centralizator pentru

note fundamentare plata manopera care a fost aprobat si va necesita efectuarea

de plati catre prestatori.

82. Se trimite o notificare catre Departamentul Resure Umane prin care se notifica

necesitate de intocmire a documentelor de plata pt „Note de fundamentare plata

manopera”.

83. Reprezentantul Departamentului Resurse Umane – salarizare acceseaza

aplicatia prin autentificare cu username, parola si string generat de device-ul

OTP. Autentificarea este corecta.

84. Se acceseaza link-ul „Note fundamentare plata manopera”

85. Se deschide formularul activ si se genereaza toate notele de fundamentare si

centralizatorul.

86. Se trimite.

87. Se face o verificare a datelor din formular si se lanseaza procesul de generare a

documentelor de plata individuale.

88. Dupa tiparire se arhiveaza.

89. Butoane disponibile: „tiparire ”, „arhivare”, „generare documente”.

Fluxul de incheie.

35

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,


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.

Tudor, C. (2013), Sisteme informatice integrate pentru domeniul financiar-

contabil, Editura ASE București.

Ward-Dutton, N., Macehiter, N., (2005) „Business Process Management, a

holistic view”, DMReview.


procese de afaceri - bpmn

Documents