Domeniul Bpm

Cuprins

1. Scurtă introducere

Înainte de a iniția orice demers științific în domeniul BPM este important să clarificăm noțiunea de Business Analyst și IT BA. Astfel, pentru a nu se realiza nici un fel de confuzii un BA este o persoană care este implicată în îmbunătățirea proceselor, reducerea costurilor și alte activități strict legate de contextul afacerii în sine, în timp ce un IT BA lucrează în contextul unor proiecte IT.

BA-ul este un “agent al schimbării” care [Haliga, 2013]:

investighează și identifică oportunități de afaceri;

facilitează procesul de schimbare și implementare;

identifică și definește soluția care să maximizeze beneficiile și să reducă costurile;

este implicat în toate nivelurile funcționale ale companiilor;

este implicat în definirea și implementarea strategiei, obiectivelor și cerințelor de business și

acționează ca un mediator, facilitând comunicarea inter/intra departamente și toate părțile interesate.

Business Analyst-ul rafinează procesul de dezvoltare prin extragerea, culegerea, analiza și comunicarea cerințelor de business aplicând metodologii, tehnici și practici specifice asignate colaborării, evidenței și controlului fluxului de lucru (interviu, workshop, modelarea proceselor, negociere, etc).

Un IT BA reprezintă legătura dintre stakeholderii unui sistem software și dezvoltatorii acestuia. Funcția acestuia este de a reprezenta interesele stakeholderilor către proiectanți, programatori și alți membri ai echipei care contribuie la dezvoltarea sistemului software. Un IT BA descoperă, analizează, negociază, reprezintă și validează cerințele unui sistem software nou sau în curs de actualizare. Cu alte cuvinte, încapsulează toate cerințele și la final testează dacă acestea sunt atinse [Podeswa, 2005].

Un Business Model este o reprezentare abstractă a unei părți clar delimitate a unei afaceri. Reprezentările unui BM pot fi diverse dar cea mai comună este sub forma unor diagrame. Aceste diagrame sunt importante deoarece prezintă cerințele într-o manieră lipsită de ambiguități adică într-o formă standardizată. Totuși acesta nu este singurul aspect benefic al utilizării diagramelor în scopul creării unui BM:

Construirea diagramelor ajută în realizarea interviurilor de documentare. O diagramă prezintă o ordine logică a unor pași specifici unui proces. La fiecare pas este necesar ca un IT BA să adreseze întrebări pentru a descoperi direcția fluxului procesului. Practic în momentul trasării diagramei un IT BA conștientizează care sunt întrebările care trebuie adresate și când trebuie adresate pentru a finaliza un interviu de documentare.

Construirea diagramelor ajută la reconcilierea mai multor puncte de vedere. Există momente când pentru a evidenția redundanțe la nivelul unui proces există nevoia unei descrieri grafice pentru o mai bună înțelegere (de către părțile interesate) a necesității de schimbare a acestuia.

2. Fundamentele BPM

Un proces de afaceri poate fi definit ca un set de activități sau sub-procese și tranzacții secvențiale sau paralele, logic relaționate menite să producă un anumit rezultat (output). Fiecare proces prezintă date de intrare (input). Input-urile și output-urile unui proces pot fi primite sau trimise de la și către un alt proces, departament sau alte părți interesate (stakeholders) interne sau externe organizației.

În literatura de specialitate am identificat numeroase definiții ale termenului proces de afaceri [Siegel,2008]:

Rummler și Brache (1995) au definit BP astfel: o serie de pași care se execută în cadrul unei organizații pentru a crea un produs sau serviciu. Dacă depășește granițele unui departament este un BP interfuncțional. Dacă produsul este destinat unui client BP-ul este considerat primar altfel este un BP ce asigură suport în cadrul organizației.

Ould (2005) a definit BP astfel: un set coerent de activități realizat de către un grup ce colaborează pentru atingerea unui obiectiv; organizarea acestor activități și definirea proceselor trebuie realizată în contextul unei bune cunoașteri a afacerii.

WMC (1999) a definit în glosarul de termeni un BP astfel: un set de proceduri sau activități mai mult sau mai puțin relaționate care împreună vizează atingerea unui obiectiv, în contextul existenței unei structuri organizaționale cu roluri funcționale bine definite și conexiuni bine stabilite. BP-urile pot fi manuale sau automatizate.

Smith and Fingar (2006) precizează că un BP este un set complet și dinamic coordonat de activități colaborative și tranzacționale care furnizează valoare clienților. BP-urile sunt mari și complexe, dinamice, personalizate, configurate pentru a funcționa durate lungi de timp, automatizate, etc.

OMG are cea mai puțin restrictivă definiție oferită BP-ului în cadrul specificației Business Motivation Model specification v. 1.3- 2015: procesele de afaceri realizează un curs de acțiuni întreprinse pentru ca organizația să progreseze continuu în vederea atingerii obiectivelor stabilite. Această definiție nu se referă doar la procesele ciclice (preluarea unei comenzi) ci și la procesele bine definite care rulează o singură dată (actualizarea proceselor este un proces în sine).

În contextul globalizării managementul proceselor de afaceri – BPM a devenit foarte important pentru toate organizațiile care doresc să:

crească numărul comenzilor;

crească viteza de transfer a datelor;

crească viteza de luare a deciziilor;

adapteze rapid cerea și oferta de produse și

să asigure competitivitate pe piața internațională.

Pentru a atinge astfel de obiective industria IT a preluat provocarea de a realiza un management eficient a proceselor de afaceri. Astfel, în ultimele trei decenii, în cadrul organizațiilor formularele tipărite au fost treptat înlocuite cu „copiile” lor electronice. Acesta a fost practic începutul a ceea ce numim astăzi BPM.

Definiția BPM oferită de van der Aalst [van der Aalst et al., 2003] este următoarea: „asigurarea unui suport eficient pentru procesele de afaceri utilizând metode, tehnici și software, pentru proiectarea, controlul și analiza proceselor care implică oameni, organizații, aplicații, documente și alte surse de informație”.

BPM Software [Appian, 2013] referă setul de instrumente software care automatizează, execută și monitorizează procesele de afaceri de la început și până la sfârșit prin conectarea utilizatorilor, aplicațiilor și utilizatorilor la aplicații. Tehnologia BPM este mult mai avansată decât cea precedentă: WfM și EAI. Deși tehnologia WfM conecta utilizatorii prin utilizarea ineficientă a unor procese controlate manual într-o singură aplicație era limitată deoarece nu putea conecta aplicații decât prin intermediul unui efort intens de programare. Tehnologia EAI conecta aplicații prin rutarea informațiilor între ele astfel încât datele erau automat sincronizate în întreaga organizație. Cu toate acestea nu permite automatizarea unor procese interactive și ca atare nu poate conecta utilizatorii. Prin conectarea utilizatorilor și aplicațiilor BPM Software a combinat și depășit aceste două tehnologii. La un nivel minim o aplicație BPM include următoarele componente:

Process Designer care permite unui utilizator instruit să analizeze și să modeleze un proces pas cu pas și să îi confere o logică;

Process Engine care execută fluxul procesului și asignează activități manuale utilizatorilor și activități automatizate către aplicații în timpul execuției;

Rules Engine care realizează managementul fluxului de informații și activități dintr-un proces în conformitate cu regulile și formulele atașate acestuia și

Process Analytics care furnizează un feedback continuu asupra procesului pentru ca în viitor să se poată aduce îmbunătățiri acestuia.

Figura 1. Componentele BPM Software [Appian, 2013].

BPM Suite [Appian, 2013] referă o tehnologie care furnizează o diversitate de procese, cunoștințe și funcționalități analitice într-un pachet unitar oferind astfel posibilitatea organizațiilor de a crea rapid și eficient aplicații compozite. Suitele BPM au apărut pentru a furniza o abordare mult mai cuprinzătoare și comparativ cu BPM Software, aceste aplicații compozite, oferă în plus următoarele funcționalități:

Knowledge management care oferă utilizatorilor posibilitatea de a partaja activități, conținut, documente și notificări via comunități;

Document management care oferă un sistem pentru stocarea și securizarea documentelor electronice, imagini sau alte fișiere;

Collaborative Tools care înlătură barierele în comunicația intra/inter departamente prin intermediul forumurilor, spațiilor de lucru dinamice, etc.;

Figura 2. Aplicații compozite[Appian, 2013].

Business Analytics care permite managerilor să identifice problemele de afaceri, trend-uri și oportunități și să le coreleze cu rapoartele existente și

Work Portal care oferă utilizatorilor un spațiu de lucru productiv pentru managementul activităților, conținutului, formularelor, documentelor, notificărilor, etc.

Aplicațiile dezvoltate cu BPM Suite sunt „user-friendly” (minimizând astfel nivelul de instruire necesar), personalizate(furnizează conținut securizat către fiecare utilizator), scalabile (extinderea funcționalităților se realizează cu ușurință) și „web-based” (accesibile la orice moment). Astfel oferă posibilitatea utilizatorilor de a lua decizii corecte astfel încât putem spune că aceste aplicații nu realizează doar un management eficient a proceselor de afaceri ci rezolvă probleme de afaceri.

BPM System [Appian, 2013] reprezintă un set de practici de management destinate a îmbunătăți agilitatea și performanța funcțională într-un mediu specific proceselor de afaceri. Această viziune holistică oferită de Gartner oferă o abordare structurată pentru optimizarea proceselor și consideră atât instrumentele software prezentate mai sus cât și metodele, politicile, metricile și practicile de management ale organizației. Astfel BPM referă o organizație a cărui management se realizează prin intermediul proceselor și care presupune adițional la IT următoarele:

Expertiză și experiență – focalizare pe dobândirea de aptitudini centrate pe proces, intruire, educație, certificare, cercetare, perspicacitate în afaceri și capital intelectual;

Discipline organizaționale – adoptarea de noi și îmbunătățite culturi, structuri, roluri, responsabilități, politici, reguli și proceduri;

Management și audit – îmbunătățirea proceselor prin definire, modelarea, simulare, execuție, monitorizare, analiză și optimizare și

Parteneriate și servicii – suport din partea partenerilor pentru consultanță, implementare,etc.

Deoarece această abordare permite organizațiilor să separe procesele de afaceri de infrastructura IT, BPM System practic transcede automatizarea proeselor de afaceri și rezolvarea problemelor de afaceri permițând afacerii în sine să răspundă mai ușor la modificările din piață generând astfel avantaj competitiv.

Vocabularul BPM cuprinde înafară de termenii discutați anterior următoarele (un glosar complet de termeni poate fi identificat la [Appian, 2013]):

BPMN sau notația BPM a fost dezvoltată de către BPMI pentru a furniza un set de elemente grafice care poate fi înțeleasă cu ușurință de către proiectanți, utilizatori, analiști,etc.

Business process model – BPMN definește un model ca un set de elemente grafice sau activități și fluxuri care definesc ordinea lor de desfășurare.

Cloud BPM presupune lansarea tehnologiilor BPM în cloud pentru modelare și execuția proceselor.

Mobile BPM presupune abilitatea de a accesa aplicații BPM via smatphone, tablete sau alte dispozitive mobile.

Social BPM referă posibilitatea de a utiliza colaborarea socială în contextul proceselor de afaceri.

BPM permite organizațiilor să obțină eficiență operațională, integreze sisteme, partajeze cunoștințe, obțină vizibilitate și feedback, să creeze responsabilitate și politici unitare și să faciliteze schimbarea. După dezvoltarea și lansarea aplicațiilor compozite utilizând o suită BPM o organizație este mult mai bine pregătită pentru a răspunde cerințelor pieții. Astfel, :

pe termen scurt organizațiile înegistrează o creștere a profitului prin descreșterea costurilor și creșterea veniturilor și

pe termen lung BPM ajută la generarea de avantaj competitiv prin îmbunătățirea agilității organizaționale. Pentru a înțelege mai bine proporțiile schimbărilor survenite după o astfel de implementare vizualizați figura anterioară.

2.1. BPM versus BPR versus WfM versus SOA sau scurt istoric BPM

Influența IT în managementul proceselor de afaceri o regăsim inițial în paradigma BPR discutată de Hammer și Champy în 1993. BPR propune ignorarea completă a proceselor de afaceri existente într-o organizație, în timp ce BPM, descendentul său este mai practic, iterativ și incremental în adaptarea proceselor de afaceri.

În ceea ce privește diferențele dintre BPM și WfM am identificat în literatura de specialitate două puncte de vedere:

BPM este o disciplină de management iar WfM îi asigură suportul tehnologic [Hill etal., 2008];

Componentele WfM reprezintă un subset al ciclului de viață al BPM definit de van der Aalst [Georgakopoulos et al., 1995] diferența majoră constând din existența fazei de diagnoză.

În realitate numeroase BPMS sunt încă WfMS deoarece nu suportă faza de diagnoză. Recent din ce în ce mai mulți dezvoltatori au actualizat denumirea WfM a produselor lor utilizând termenul mai contemporan BPM. Deși numeroase BPMS oferă instrumente de monitorizare BAM acestea încă necesită utilizarea unor instrumente de raportare externe și specializate cum sunt Microsoft Reporting Server sau Crystal Reports [Ryan K.L. Ko et al., 2009].

Tabelul 1. Comparație între WfM și BPM [Ryan K.L. Ko et al., 2009

În ceea ce privește diferențele dintre BPM și SOA se poate argumenta că BPM „organizează oameni pentru o eficiență sporită” în timp ce SOA „organizează tehnologii pentru o eficiență sporită”. Cu alte cuvinte, procesele SOA (servicii web interconectate) facilitează coordonarea sistemelor distribuite care oferă suport proceselor de afaceri și nu trebuie niciodată confundate cu procesele de afaceri.

Pe scurt, BPMS=BPM+SOA [Baker, 2006].

Figura 3. Aplicații de întreprindere monolitice[Muehlen, 2007].

Pentru o mai bună înțelegere a conceptelor și diferențelor dintre BPM și SOA voi realiza o prezentare a evoluției BPM. Inexistența BPM presupune existența unor aplicații de întreprindere monolitice construite ca un tot unitar (figura anterioară) și cu o interfață utilizator construită pentru toate funcționalitățile aplicației, ceea ce presupune că orice modificare sau extindere de funcționalitate presupune intervenția directă a unui programator.

În anii 1990 ideea de flux începea să prindă contur.

Figura 4. BPM în anii 1990.

În anul 1993 s-a constatat o orientare către managementul activităților. Fluxurile erau controlate de către utilizator dar spre deosebire de anul 1990 nu erau doar o idee. După cum se observă și din figura ce urmează utilizatorul accesează interfața în mod direct în momentul în care dorește să creeze un cont nou, ceea ce înseamnă că încă nu s-au înregistrat progrese semnificative.

Figura 5. BPM în 1993-orientarea către managementul activităților[Muehlen, 2007].

În 1996 s-a demarat rutarea fluxurilor dar acestea erau controlate în continuare manual.

Figura 6. BPM în 1996. Rutarea fluxurilor[Muehlen, 2007].

În 2003 au apărut îmbunătățiri semnificative în sensul că interfața grafică conecta utilizatorul la BPMS și nu direct la aplicație, acest lucru fiind posibil datorită implementării de servicii web interconectate (SOA).

Figura 7. BPMN în 2003. Integrarea serviciilor[Muehlen, 2007].

Figura 8. BPMN în 2007. Servicii compozite[Muehlen, 2007].

În anul 2007 au apărut serviciile compozite, apariția BPEL conducând la o separare clară a responsabilităților în acest domeniu. Astfel, asignarea de responsabilități, definirea de grupuri, roluri, aptitudini, termene limită, alerte, memento-uri, escalări, adăugarea de sarcini manuale, ordonarea sarcinilor și interfața utilizator sunt apanajul sferei de afaceri în timp ce logica computațională, reprezentarea datelor, scalabilitatea/performanța, interoperabilitatea și managementul datelor devin apanajul sferei IT [Muehlen, 2007].

Figura 9. BPMN 2007. Servicii compozite. Extindere BPEL[Muehlen, 2007].

2.2. Standarde BPM

BPM a stârnit rapid interesul atât practicienilor cât și teoreticienilor, motiv pentru care s-au dezvoltat diverse paradigme și metodologii transformând BPM într-un subiect interdisciplinar. Problema este că numeroasele terminologii și tehnologii nu au fost suficient de bine definite, înțelese, propuneau notații diferite pentru aceleași concepte și nu au fost validate prin implementarea lor în mediul de afaceri real. Cu alte cuvinte necesitatea unui standard era imperativă și poate fi justificată prin relația existentă între teoria BPM, standarde BPM și sistemele BPM.

Figura 10. Teoria BPM versus standarde BPM și limbaje versus sisteme BPM.

În continuare voi încerca să:

discut terminologia asociată cu BPM și standardele acestuia;

clasifica sistematic standardele BPM;

discuta punctele tari și punctele slabe ale fiecărui standard;

clarifica diferențele teoretice care stau la baza celor mai importante standarde BPM și

explora lacunele existente în standardele BPM actuale și cum acestea pot fi depășite.

2.2.1. Noțiunea de standard

Impactul unui standard poate fi foarte mare. Să definești un standard este un proces riscant deoarece selecția greșită a tehnologiei poate fi contraproductivă, incompatibilă și poate conduce la neadoptarea acestuia în practică. Pe de altă parte și adoptarea unui standard trebuie realizată cu maximă atenție deoarece o alegere greșită poate genera dificultăți în momentul actualizării tehnologiei utilizate, poate limita conectivitatea între partenerii de afaceri și forța instruirea utilizatorilor într-o tehnologie depășită moral. În general se observă necesitatea unei mai bune înțelegeri asupra întregului proces de standardizare [Muehlen, 2007] și ca atare voi realiza câteva clarificări.

Fazele standardizării sunt inițierea, dezvoltarea, ratificarea, adopția și distribuția Astfel:

Inițierea unui standard poate fi cauzată de apariția unor sancțiuni aplicate de către instituțiile statului unor standarde deja existente sau poate fi cauzată de diverși utilizatori, vânzători sau dezvoltatori. Inițierea unui standard poate apare în urma unei solicitări (specificații OMG) sau nu (specificații IETF), sau poate fi rezultatul celor mai bune practici din domeniu [Muehlen, 2007].

Dezvoltarea unui standard se realizează într-un cadru organizațional pe baza unei cooperări între membrii organizației, dar totodată solicitându-se și opinia unor experți independenți sau a altor grupuri sau organizații direct interesate în vederea implementării standardului înainte de ratificare.

Ratificarea se poate realiza prin vot sau sub forma de specificații (recomandări, RFC, standard) după care se validează specificațiile realizate.

Adopția se realizează în general în ordinea următoare: organizațiile participante la definirea standardului, alte organizații, comunități open-source. După această etapă se trasează standardele obligatorii și cele recomandate prin studiul atent și comparativ între conformitate și posibilitatea reală de implementare a acestora [Muehlen, 2007].

Difuzia apare ca urmare a utilizării standardului de către utilizatorii finali și este determinată de către prezența pe piață și promovarea eficientă a acestuia.

2.2.2. Clasificarea standardelor BPM

Pentru a înțelege cât mai bine noțiunile fundamentale BPM este necesar ca mai întâi să avem o perspectivă clară și succintă asupra ciclului de viață al BPM. Există numeroase modele ale ciclului de viață BPM dar cel mai clar este cel realizat de van der Aalst [van der Aalst et al., 2003] și care constă din:

Proiectarea proceselor. În această fază procesele de afaceri sunt modelate „ca atare” în BPMS. Standardele grafice sunt dominante în această fază.

Configurarea sistemului. În această fază se configurează BPMS și infrastructura acestuia. Această fază este dificil de standardizat deoarece organizațiile au arhitecturi IT diferite.

Implementarea proceselor. Procesele de afaceri modelate electronic sunt executate cu ajutorul motoarelor BPMS. Standardele de execuție domină această fază.

Diagnoză. Se utilizează instrumente de analiză și monitorizare cu ajutorul cărora analistul BPM identifică lacune ale proceselor de afaceri. În această fază domină standardele pentru diagnoză.

Figura 11. Ciclul de viață al BPM.

Într-o primă fază putem putem grupa standardele existente după funcții similare sau caracteristici. Multe dintre aceste standarde fac referire la una dintre fazele ciclului de viață BPM. De exemplu BPMN adresează faza de proiectare a proceselor sau de implementare a acestora. Ca atare o primă clasificare este următoarea:

Standarde grafice care permit utilizatorilor să exprime procesele de afaceri, fluxurile și tranzițiile acestora sub forma unor diagrame;

Standarde pentru execuție care permit automatizarea proceselor de afaceri;

Figura 12. Standarde BPM [Muehlen, 2007].

Standarde pentru portabilitate utilizate pentru a asigura portabilitatea proceselor de afaceri modelate cu ajutorul a mai multor standarde grafice în același BPMS sau standarde de execuție diferite pe mai multe BPMS sau translatarea standardelor grafice în standarde de execuție și invers.

Standarde pentru diagnoză care oferă funcționalități administrative și de monitorizare și care pot identifica probleme, audita și interoga în timp real procesele de afaceri dintr-o organizație.

Deseori se realizează confuzii între standardele BPM și alte standarde cum ar fi cele SOA.

Un algoritm prin care se poate realiza o diferențiere între standarde este prezentat în figura următoare. Această diagramă realizată de Ryan K.L. Ko et al.[Ryan K.L. Ko et al., 2009] exprimă grafic algoritmul pentru separarea standardelelor BPM de standardele B2B și cele SOA. După cum se observă diferențierea dintre standardele SOA și cele BPM se realizează prin diferențierea între serviciu web și proces, iar diferențierea între standardele B2B și cele BPM se realizează în funcție de tipul procesului de afaceri care poate fi public sau privat. În continuare standardele se diferențiază în funcție de fazele din ciclul de viață al BPM descrise anterior.

Figura 13. Diagramă pentru clasificarea standardelor BPM [Ryan K.L. Ko et al., 2009].

Principalele standarde, limbaje, notații și teorii BPM existente sunt prezentate în Tabelul 2.

Tabelul 2. Starea curentă a standardelor BPM, SOA și B2B [Ryan K.L. Ko et al., 2009].

Privind sub o altă perspectivă, standardele grafice reprezintă cel mai înalt nivel de expresie a proceselor de afaceri, în timp ce standardele de execuție reprezintă cel mai scăzut nivel (sunt tehnice) de expresie pentru procesele de afaceri. Deși standardele pentru portabilitate au ca scop translatarea dintre standardele grafice și cele de execuție și vice versa, aceasta poate fi imperfectă deoarece aceste standarde sunt conceptual diferite [Recker and Mendling, 2006]. Aplicând algoritmul din Figura 13 standardelor prezentate în Tabelul 2 putem realiza clasificarea din Figura 14.

Figura 14. Clasificarea standardelor în funcție de faza din ciclul de viață al BPM.

2.2.3. Exemple de standarde grafice

Standardele grafice permit utilizatorilor să exprime fluxul de informații, punctele de decizie și rolurile proceselor de afaceri într-o manieră grafică prin crearea de diagrame. Tehnicile cele mai cunoscute utilizate pentru modelarea proceselor de afaceri în mod graphic sunt diagramele UML AD (OMG, 2009), BPMN (OMG, 2011), EPC și RAD. Aceste tehnici variază de la notații comune la standarde. Dintre standarde, cele mai expresive și ușor de integrat cu nivelele următoare (portabilitate și execuție) sunt UML și BPMN.

UML

UML a fost standardizat în 2004 și reprezintă o suită de 13 notații orientate obiect care încorporează toate atributele și comportamentul obiectelor modelate [Ambler, 2004]. Câteva exemple de astfel de notații includ diagrame ale cazurilor de utilizare, diagrame de secvență, diagrame de activitate, etc. Dintre toate cea mai des utilizată pentru modelarea proceselor de afaceri este diagrama de activitate [Russel et al., 2006].

De-a lungul timpului au existat câteva încercări de a realiza comparații între notațiile utilizate de UML AD și WPF. De asemenea s-a investigat cât de utilă și expresivă poate fi UML AD pentru a captura esența colecțiilor de șabloane de fluxuri de lucru [Dumas și Hofstede, 2001]. Acest studiu a apărut ca o replică la publicația Workflow Handbook [White, 2004] prin care se realizează o comparație între notațiile specifice modelării proceselor de afaceri (BPMN și UML AD) și fluxurile de lucru. Concluziile referitoare la cât de adecvată este UML AD pentru modelarea proceselor de afaceri au fost următoarele [Russell et al., 2006]:

UML AD oferă un bun suport pentru reprezentarea fluxurilor de control și a datelor dar

UML AD oferă posibilități limitate de a modela aspecte organizatorice ale proceselor de afaceri.

Deși UML AD este funcțională, aceasta nu poate fi utilizată de analiști fără ca aceștia să dețină cunoștințe tehnice. De asemenea UML AD nu facilitează modelarea unui proces de afaceri și sub-procesele acestuia de la cel mai înalt nivel de detaliere la cel mai mic.

Figura 15. Extras dintr-o diagramă UML AD.

BPMN

Standardul BPMN a fost realizat în speranța de a micșora decalajul existent între IT și analiști. BPMI a expus prima dată BPMN ca o reprezentare grafică a BPML care este un limbaj pentru execuția proceselor bazat pe XML. În timp, BPML a fost înlocuit de rivalul său BPEL. BPMN permite modelarea proceselor private(interne), publice(abstracte) și de colaborare la nivele diverse de granularitate. Cele mai multe modele BPMN pot fi mapate în BPEL ceea ce de fapt reprezintă marele avantaj al BPMN comparativ cu UML AD. Totuși, datorită diferențelor ireconciliabile dintre BPMN și BPEL,

Figura 16. Exemplu de BPMN BPD.

este dificil să se genereze cod BPEL din modelele BPMN și de asemenea să se sincronizeze modelele BPMN cu codul BPEL generat. La pol opus, dezavantajul major constă în portabilitatea redusă a diagramelor BPMN. OMG a introdus un standard în acest sens numit BPDM dar în mod curent se utilizează standardul XPDL.

Diferențele dintre UML AD și BPMN BPD sunt:

de terminologie;

BPMN BPD utilizează mai puține obiecte pentru a modela procese complexe;

UML AD solicită cunoștințe tehnice analiștilor.

EPC

EPC (Event-driven process chain) a fost dezvoltat de către Institute for Information Systems din Germania și este un limbaj utilizat de către setul de instrumente ARIS a IDS Scheer AG și componenta de fluxuri de lucru a sistemului SAP R/3. Deși a fost foarte popular în anii 1990 și a avut câteva caracteristici notabile, acesta prezintă suficiente limitări pentru ca cercetătorii și practicienii din domeniu să nu îl considere un standard grafic pentru modelarea proceselor de afaceri.

Figura 17. Exemplu de diagramă EPC.

RAD

RAD și diagramele de fluxuri de lucru nu sunt standarde dar sunt instrumente utilizate pentru a afișa tranzițiile proceselor de afaceri [Odeh et.al , 2002].

Figura 18. Notația RAD [Brennan, 2006].

Notații grafice ca UML AD și BPMN sunt ușor de utilizat de către analiști și alte persoane care nu dețin cunoștințe tehnice. Comparate cu BPEL standardele grafice pot evidenția șabloane și diverse lacune ale proceselor de afaceri, dar datorită setului finit de componente existent pentru modelare pot totodată să și restricționeze libertatea de proiectare. Datorită absenței formalismului semantic și computațional din aceste notații grafice modelele BPMN sau UML AD nu vor putea fi niciodată complet translatate în cod executabil.

2.2.4. Exemple de standarde pentru execuție, portabilitate și diagnoză

Standardele pentru execuție permit lansarea proceselor de afaceri modelate în BPMS pentru ca instanțele acestora să fie executate de către motorul BPMS. Momentan există două standarde BPML și BPEL importante. BPEL a fost adoptat de către mai multe suite software (IBM Websphere, BEA AquaLogic BPM Suite, SAP Netweaver, etc.) deși BPML adresează mai bine semantica proceselor de afaceri.

BPML

Avantajele BPML sunt [Ryan K.L. Ko et al., 2009]:

BPML suportă conceptul de zero cod. Programatorii nu sunt obligați să-și concentreze atenția asupra activității de programare ci mai degrabă pe definirea corectă a proceselor și a secvențelor lor de execuție. Practicienii numesc acest concept „programarea în ansamblu”;

BPML încurajează reutilizarea și scalabilitatea fiind un standard deschis pentru toate BPMS. Componentele sale pot fi reutilizate și parsate deoarece BPML are la bază XML;

BPML este formal complet și

BPML suportă tranzacții.

BPML prezintă următoarele limitări [Ryan K.L. Ko et al., 2009]:

Componenta temporală a unui proces nu este evidentă în momentul definirii acestuia dar se specifică în format XML.

BPML poate fi suportat doar de către sisteme BPMS pure și nu de către sistemele unor dezvoltatori mari cum ar fi Microsoft BizTalk, IBM MQServer și Websphere ceea ce a condus la apariția XLANG (dezvoltat de Microsoft) și WSFL(dezvoltat de IBM).

BPMI a retras suportul pentru BPML în 2005 după fuziunea cu OMG.

BPEL, XLANG și WSFL

BPEL este un limbaj bazat pe XML prin intermediul căruia putem defini procese de afaceri prin utilizarea serviciilor web și care poate servi ca un limbaj de execuție (procese executabile) și ca un limbaj de descriere (procese abstracte).

Figura 19. Evoluția BPEL [Ryan K.L. Ko et al., 2009].

Avantajele BPEL sunt [Ryan K.L. Ko et al., 2009]:

Este cel mai popular și nu prezintă în acest moment nici un competitor serios, find adoptat de marea majoritate a dezvoltatorilor de software (ca atare nu există nici probleme de portabilitate cu produse a dezvoltatorilor mai mici de BPMS).

Comparativ cu alte limbaje de programare (Java) nu se concentrează pe programarea propriu-zisă ceea ce facilitează semnificativ modelarea proceselor și micșorează și numărul liniilor de cod.

Adoptă paradigma serviilor web în sensul că BPEL încorporează un număr de componente menite a dezvolta servicii web și a facilita comunicarea asincronă, precum și suport XML pentru definirea și manipularea datelor.

BPEL prezintă următoarele limitări [Ryan K.L. Ko et al., 2009]:

Prezintă o sintaxă complexă dificil de implementat.

Sintaxa este restrictivă ceea ce cauzează numeroase probleme la translatarea BPMN-BPEL.

BPEL este restrictiv în modelarea comportamentului uman în cadrul proceselor.

BPEL nu oferă suportă pentru toate construcțiile posibile de procese și ca atare deseori se utilizează împreună cu alte limbaje de programare (Java).

BPEL nu oferă suport B2B.

În ciuda limitărilor sale BPEL este momentan cel mai popular limbaj de execuție.

Standardele de execuție sunt limitate deoarece secvențele, activitățile și legăturile care se creează în interiorul și între procese nu sunt vizibile (similar limbajelor de asamblare). De asemenea o altă mare limitare pentru standardele de execuție îl reprezintă faptul că necesită cunoștințe tehnice în special referitoare la servicii web ceea ce creează dificultăți analiștilor.

Diferența fundamentală dintre standardele grafice și cele de execuție este: standardele grafice sunt orientate-graf în timp cele standardele de execuție sunt orientate-bloc. Din acest motiv deseori informația se pierde în translatarea între cele două tipuri de standarde. Standardele pentru portabilitate sunt menite să rezolve această problemă. Momentan există două astfel de standarde:

Business Process Definition Metamodel (BPDM) creat de OMG și

XML Process Definition Language (XPDL) creat de WfMC.

BPDM este complex și neprietenos. XPDL este cel mai popular (ultima versiune este 2.2 disponibilă din august 2012 conform http://www.xpdl.org/).

Diferența esențială între WM și BPM rezidă în etapa de diagnoză din ciclul de viață BPM. Standardele pentru diagnoză monitorizează și optimizează BP din BPMS.

Exemple de standarde pentru diagnoză:

Business Process Runtime Interface (BPRI) este proiectat pentru a oferi o interfață comună pentru modelul de date utilizat la execuția proceselor și are ca prim obiectiv facilitarea analizei și

Business Process Query Language (BPQL) asigură o interfață pentru managementul întregii infrastructuri BPM și include facilități cum ar fi process server și process repository.

3. Standarde grafice: UML

UML a fost conceput ca un limbaj universal care să fie utilizat la modelarea sistemelor. UML presupune că metodologia este “ghidată” de cazurile de utilizare, că ea se bazează pe arhitectura sistemului, iar procesul de aplicare a metodologiei este iterativ și incremental. Detaliile acestui proces trebuie adaptate la domeniul aplicației, la modul de organizare al echipei de realizatori, la experiența echipei. UML nu tratează aspecte de metodologie, permițând astfel separarea limbajului de modelare de procesul aplicării metodologiei [Giurcă, 2004].

Modelarea unui sistem presupune parcurgerea mai multor faze ale dezvoltării: analiză, proiectare, implementare testare și desfășurare sistematică.

Modelarea unui sistem poate fi o muncă foarte dificilă. Ideal ar fi ca pentru descrierea sistemului să se folosească un singur graf, însă de cele mai multe ori acesta nu poate să surprindă toate informațiile necesare descrierii sistemului. Un sistem poate fi descris luând în considerare diferite aspecte:

Funcțional: este descrisă structura statică și comportamentul dinamic al sistemului;

Non-funcțional: necesarul de timp pentru dezvoltarea sistemului și

Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de cod.

UML poate fi structurat în [Giurcă, 2004]:

views sau vederi (surprind aspecte particulare ale sistemului de modelat, o vedere este o abstractizare a sistemului, iar pentru construirea ei se folosesc diagrame),

diagrame (sunt grafuri care descriu conținutul unei vederi; există nouă tipuri de diagrame care pot fi combinate pentru a forma toate vederile sistemului),

elemente de modelare (sunt concepte folosite în diagrame care au corespondență în programarea orientată-obiect, cum ar fi: clase, obiecte, mesaje și relații între acestea: asocierea, dependența, generalizarea; un element de modelare poate fi folosit în mai multe diagrame diferite și va avea același înțeles și același mod de reprezentare) și

mecanisme generale (permit introducerea de comentarii și alte informații despre un anumit element).

Figura 20. Etapele modelării unui sistem[Giurcă, 2004], [Eriksson et.al, 1998].

Fiecare view este descris folosind un număr de diagrame care conțin informații relative la un anumit aspect particular al sistemului. Aceste view-uri se acoperă unele pe altele, deci este posibil ca o anumită diagramă să facă parte din mai multe view-uri [Giurcă, 2004], [Eriksson et.al, 1998]:

View-ul cazurilor de utilizare (Use-case View). Acest view surprinde funcționalitatea sistemului, așa cum este ea percepută de actorii externi care interacționează cu sistemul, de exemplu utilizatorii acestuia sau alte sisteme. În componența lui intră diagrame ale cazurilor de utilizare și ocazional, diagrame de activitate. Cei interesați de acest view sunt deopotrivă clienții, proiectanții, dezvoltatorii dar și cei care vor realiza testarea și validarea sistemului.

View-ul logic (Logic View). Spre deosebire de view-ul cazurilor de utilizare, un view logic “privește” înăuntrul sistemului și descrie atât structura internă a acestuia (clase, obiecte și relații) cât și colaborările care apar când obiectele trimit unul altuia mesaje pentru a realiza funcționalitatea dorită. Structura statică este descrisă în diagrame de clasă, în timp ce pentru modelarea dinamicii sistemului se vor folosi diagramele de stare, de secvență, de colaborare sau de activitate. Prin urmare, cei care sunt interesați de acest tip de vizualizare a sistemului sunt proiectanții și dezvoltatorii.

Figura 21. UML views [Eriksson et.al, 1998].

View-ul componentelor (Component View). Componentele sunt module de cod de diferite tipuri. În funcție de conținutul lor acestea pot fi: componente care conțin cod sursă, componente binare sau executabile. View-ul componentelor are rolul de a descrie componentele implementate de sistem și dependențele ce există între ele, precum și resursele alocate acestora și eventual alte informații administrative, cum ar fi de exemplu un desfașurător al muncii de dezvoltare. Este folosit în special de dezvoltatorii sistemului, iar în componența sa intră diagrame ale componentelor.

View-ul de concurență (Concurent View). Sistemul poate fi construit astfel încât să ruleze pe mai multe procesoare. Acest aspect, care este unul nonfuncțional, este util pentru o gestionare eficientă a resurselor, execuții paralele și tratări asincrone ale unor evenimente din sistem, precum și pentru rezolvarea unor probleme legate de comunicarea și sincronizarea thread-urilor. Cei care sunt interesați de o astfel de vizualizare a sistemului sunt dezvoltatorii și integratorii de sistem, iar pentru construirea lui se folosesc diagrame dinamice (stare, secventă, colaborare și activitate) și diagrame de implementare (ale componentelor sau de desfășurare).

View-ul de desfășurare (Deployment View). Desfășurarea fizică a sistemului, ce calculatoare și ce dispozitive (numite și noduri) vor fi folosite pentru realizarea efectivă a implementării, cum sunt acestea conectate, precum și ce componente se vor executa pe fiecare nod (de exemplu ce program sau obiect este executat pe fiecare calculator), toate sunt surprinse în view-ul de desfășurare. Acest tip de vizualizare a sistemului prezintă interes pentru dezvoltatori, integratorii de sistem și cei care realizează testarea sistemului, iar pentru construirea view-ului este folosită diagrama de desfășurare.

Un model de sistem are o dimensiune dinamică și una statică. Modelul dinamic al unui sistem analizează sistemul din perspectiva acțiunilor sale adică la nivel comportamental (răspunde la întrebarea: ce face sistemul?), în timp ce modelul static analizează sistemul din perspectiva sa structurală (răspunde la întrebarea: ce este sistemul?) [Podeswa, 2005]. Astfel diagramele UML vor reprezenta aspecte dinamice respectiv statice ale sistemului modelat.

Figura 22. Tipologia diagramelor UML.

Diagramele sunt grafuri care prezintă simboluri ale elementelor de modelare aranjate astfel încât să ilustreze o anumită parte sau un anumit aspect al sistemului.

Un model are de obicei mai multe diagrame de același tip. O diagramă este o parte a unui view specific, dar există posibilitatea ca o diagramă să facă parte din mai multe view-uri, în funcție de conținutul ei. În UML sunt nouă tipuri de diagrame prezentate pe scurt în cele ce urmează.

Figura 23. Exemplu de diagramă a cazurilor de utilizare [Giurcă, 2004], [Eriksson et.al, 1998].

Diagrama cazurilor de utilizare (Use Case Diagram). Un caz de utilizare este o descriere a unei funcționalități (o utilizare specifică a sistemului) pe care o oferă sistemul. Diagrama prezintă actorii externi și cazurile de utilizare identificate, numai din punctul de vedere al actorilor (care este comportamentul sistemului, așa cum este el perceput de utilizatorii lui) nu și din interior, precum și conexiunile identificate între actori și cazurile de utilizare.

Diagrama claselor (Class Diagram). O diagramă a claselor prezintă structura fizică a claselor identificate în sistem. Clasele reprezintă “lucruri” gestionate de sistem; clasele pot fi legate în mai multe moduri: asociate (conectate între ele), dependente (o clasa depinde/folosește o altă clasă), specializate (o clasă este specializarea altei clase) sau împachetate (grupate împreună în cadrul unei unități). Toate aceste relații se materializează în structura internă a claselor în atribute și operații. Diagrama este considerată statică, în sensul că este validă în orice moment din ciclul de viață al sistemului.

Figura 24. Exemplu de diagramă a claselor [Giurcă, 2004].

Diagrama obiectelor (Object Diagram). Acest tip de diagramă este un variant al diagramei claselor care în locul unei clase prezintă mai multe instanțe ale ei. Diagrama obiectelor folosește aproape aceleași notații ca și diagrama claselor cu două mici diferențe: obiectele sunt scrise subliniat și sunt vizualizate toate instanțele relației. Deși nu este la fel de importantă ca diagrama claselor, cea o obiectelor este folosită pentru exemplificarea unei diagrame a claselor de complexitate mare, permițând vizualizări ale instanțelor actuale și a relațiilor exact așa cum sunt ele realizate. Mai poate fi folosită ca o parte a diagramelor de colaborare, în care sunt vizualizate colaborările dinamice existente în cadrul unui set de obiecte.

Figura 25. Exemplu de diagramă a claselor și obiectelor [Giurcă, 2004], [Eriksson et.al, 1998].

Diagrama de stare (State Diagram). O stare este de obicei un complement al descrierii unei clase. O diagramă de stare prezintă toate stările prin care trece un obiect al clasei precum și evenimentele care-i cauzează modificările de stare. Modificarea stării se numește tranziție. Nu vom construi diagrame de stare pentru toate clasele din sistem ci numai pentru acelea care au un număr de stări bine definit iar comportamentul clasei este afectat și modificat de acestea.

Figura 26. Exemplu de diagramă de stare [Dorobăț, 2012].

Diagrama de secvență (Sequence Diagram). O diagramă de secvență prezintă colaborarea dinamică între un număr de obiecte, mai precis secvențele de mesaje trimise între acestea pe măsura scurgerii timpului. Obiectele sunt văzute ca linii verticale distribuite pe orizontală, iar timpul este reprezentat pe axa verticală de sus în jos. Mesajele sunt reprezentate prin săgeți între liniile verticale ce corespund obiectelor implicate în mesaj.

Figura 27. Exemplu de diagramă de secvență [Giurcă, 2004], [Eriksson et.al, 1998].

Diagrama de colaborare (Collaboration Diagram). Această diagramă surprinde colaborarea dinamică între obiecte, într-o manieră similară cu a diagramei de secvență, dar pe lângă schimbul de mesaje (numit și interacțiune) prezintă obiectele și relațiile dintre ele (câteodată referite ca și context).

Figura 28. Exemplu de diagramă de colaborare [Giurcă, 2004], [Eriksson et.al, 1998].

Cum decidem ce tip de diagramă să folosim?

Dacă cel mai important aspect este timpul sau secvența de mesaje vom folosi diagrama de secvență, dar dacă trebuie scos în evidență contextul, vom apela la o diagramă de colaborare. Desenarea unei diagrame de colaborare se face similar cu a unei diagrame a obiectelor. Mesajele vor fi reprezentate prin săgeți între obiectele implicate în mesaj și pot fi însoțite de etichete care specifică ordinea în care acestea vor fi transmise. De asemenea se pot vizualiza condiții, iterații, valori returnate, precum și obiectele active care se execută concurent cu alte obiecte active.

Diagrama de activitate (Activity Diagram). O diagramă de activitate prezintă fluxul secvențelor de activități și este de obicei folosită pentru a descrie activitățile realizate în cadrul unei operații, folosind dacă este cazul decizii și condiții. Diagrama conține stări de acțiune (action states) și mesaje care vor fi trimise sau recepționate ca parte a acțiunii realizate.

Figura 29. Exemplu de diagramă de activitate [Giurcă, 2004], [Eriksson et.al, 1998].

Diagrama componentelor (Component Diagram). O diagramă a componentelor prezintă structura fizică a codului în termenii componentelor de cod, realizând o mapare de la view-ul logic la view-ul componentelor. O componentă poate să conțină un cod sursă sau poate să fie într-o formă binară sau executabilă. În cadrul diagramei vor fi ilustrate și dependențele dintre componente, ceea ce permite o vizualizare simplă a componentelor care vor fi afectate de modificarea uneia dintre ele.

Figura 30. Exemplu de diagramă a componentelor [Giurcă, 2004], [Eriksson et.al, 1998].

Diagrama de desfășurare (Deployment View). Arhitectura fizică pe care va fi implementat sistemul, calculatoarele, device-urile (referite ca nodurile sistemului), împreună cu conexiunile dintre ele, vor putea fi prezentate în cadrul unei diagrame de desfașurare. Componentele și obiectele executabile sunt alocate în interiorul nodurilor, ceea ce ne va permite o vizualizare a unităților care se vor executa pe fiecare nod.

Figura 31. Exemplu de diagramă de desfășurare [Giurcă, 2004], [Eriksson et.al, 1998].

3.1. Studiu de caz UML

AICI

În scop didactic (pentru a înțelege modalitatea de utilizare a diagramelor UML în cadrul proiectelor de dezvoltare software) voi prezenta în continuare un studiu de caz. Datorită dimensiunii reduse a modelului de sistem prezentat anumite diagrame caracteristice sistemelor informatice de mari dimensiuni nu vor fi prezentate.

Singura diagramă care nu este supusă la modificări și îmbunătățiri pe parcursul unei iterații este diagrama cazurilor de utilizare, aceasta reprezentând numitorul comun al celor patru faze ale dezvoltării sistemului.

Definirea problemei

O companie dorește implementarea unui sistem informatic pentru managementul programelor educaționale oferite de către aceasta.

Obiectivele sistemului informatic sunt:

Înregistrarea și monitorizarea activităților profesorilor: acreditarea profesorului, înregistrarea profesorului, autentificarea profesorului, înregistrarea studenților, programarea susținerii pre/post testului;

Înregistrarea și monitorizarea activităților studenților: autentificarea studentului, susține pre-test, susține post-test;

Înregistrarea și monitorizarea activităților funcționarilor: autentificarea funcționarului, managementul programelor educaționale.

Monitorizarea performanței programelor educaționale presupune realizarea unor rapoarte privind:

Rata de succes a programelor educaționale la nivel de student student/ instituție de învățământ/ județ

Costurile programului educațional la nivel de student student/ instituție de învățământ/ județ

Profitul programului educațional realizat la nivel de student/ instituție de învățământ/ județ

Instituțiile de învățământ care nu beneficiază de programe educaționale.

Prezentarea cazurilor de utilizare

Pentru a stabili în detaliu funcționalitatea sistemului care se proiectează este necesară o descriere a cazurilor de utilizare. Aceasta nu are o structură standard, existând multiple variante în funcție de necesitățile echipei de dezvoltare. De exemplu definirea unui caz de utilizare se realizează în cazul proiectelor de dezvoltare de dimensiuni mari după un șablon similar celui prezentat în tabelul următor. Este posibil ca numărul și complexitatea cazurilor de utilizare să fie atât de mare încât să fie necesar să se întocmească un grafic de livrare a cazurilor de utilizare către beneficiar.

Figura 32. Șablon pentru descrierea cazurilor de utilizare.

În cazul problemei definite anterior am identificat cazurile de utilizare și voi prezenta o selecție dintre cele relevante pentru studiul modelului de sistem.

Figura 33. Diagrama cazului de utilizare UC01 Acreditare profesor.

Figura 34. Diagrama cazului de utilizare UC02 Înregistrare profesor.

Figura 35. Diagrama cazului de utilizare UC05 Înregistrează studenți.

Figura 36. Diagrama cazului de utilizare UC08 Formează clasa.

Diagrama cazurilor de utilizare raportată la înregistrarea și monitorizarea activităților profesorilor, studenților și funcționarilor companiei este prezentată în următoarea figură.

Monitorizarea performanței programelor educaționale presupune realizarea unor rapoarte privind:

Rata de succes a programelor educaționale la nivel de student student/ instituție de învățământ/ județ;

Costurile programului educațional la nivel de student student/ instituție de învățământ/ județ;

Profitul programului educațional realizat la nivel de student/ instituție de învățământ/ județ și

Instituțiile de învățământ care nu beneficiază de programe educaționale.

Diagrama de activitate???

Figura 37. Diagrama cazurilor de utilizare.

4. Standarde grafice: BPMN

4.1. Procesul de modelare BPMN

Să ne imaginăm o organizație în care fiecare departament prezintă propriul set de proceduri de lucru și propriul „limbaj”. Nu mă refer la un limbaj tehnic, ci la un limbaj care descrie activitățile pe care personalul din aceste departamente le execută în mod curent: pe scurt cum funcționează procesele lor de afaceri (BP). Managementul unei asemenea companii este cu atât mai dificil dacă și departamentele responsabile de documentarea și îmbunătățirea proceselor de afaceri (analiștii, arhitecții, dezvoltatorii de software, etc.) utilizează limbaje propriii, prin aplicarea unor reguli și convenții specifice unor metodologii sau instrumente software diferite.

Acest lucru poate fi modificat prin utilizarea unui limbaj vizual, a unui standard în întreaga organizație. Un astfel de limbaj vizual este furnizat prin intermediul notației BPM sau BPMN. BPMN standardizează diagramele utilizate în vederea descrierii proceselor de afaceri ale unei companii prin intermediul unui set de figuri și simboluri predefinite. Pentru a realiza un management eficient este nevoie de instrumente software care să aibă încorporate facilități BPMN, de o metodologie sau ghid care să ne asigure că un model de proces (care poate fi creat cu Microsoft Visio sau alte instrumente software) poate fi înțeles doar din diagrama sa fără să se utilizeze altă documentație suplimentară, precum și instrumente care să faciliteze simularea și optimizarea modelelor BPMN ( de exemplu analystView de la Global 360) și care să creeze totodată și legătura cu mediile de execuție a proceselor [Silver, 2010].

BPMN este utilizat atât pentru analiza și documentația proceselor de afaceri cât și pentru proiectarea de procese executabile. Obiectele esențiale ale BPMN sunt: căsuțele care reprezintă activities (activități) organizate în lanes (care pot reprezinta departamente ale organizației) interconectate prin săgeți numite sequence flows. BPMN este conceptual simplu prezentând 3 obiecte principale care descriu un flux: activity (descrie o acțiune din cadrul procesului reprezentată printr-o formă rectangulară cu colțuri rotunjite), gateway (descrie o condiție din cadrul procesului reprezentată printr-o formă de romb) și un event (un semnal care informează dacă procesul a generat sau recepționat ceva, reprezentat printr-o formă circulară).

Figura 38 Principalele obiecte BPMN care descriu un flux: activity, gateway și event [Silver, 2010].

Înafară de aceste obiecte clasice diagramelor de fluxuri, BPMN adaugă:

expresivitate deoarece definește o largă paletă de subtipuri pentru obiectele activity, gateway și event ceea ce permite BPMN să transceadă dincolo de simpla descriere a unui proces către posibilitatea de a creea procese executabile;

sub-procese permițând astfel vizualizarea unui model de proces pe mai multe niveluri de detaliere;

message flows (fluxuri de mesaje) permițând vizualizarea conexiunilor dintre un proces și mediul exterior acestuia – de exemplu clientul care a solicitat procesul, furnizorul de servicii aferent procesului sau alte procese interne care interacționează cu procesul respectiv; fluxurile de mesaje definesc poziția fiecărui proces la nivelul întregii arhitecturi de procese;

tratarea excepțiilor prin utilizarea de evenimente;

universalitatea notațiilor deoarece semnificația unei diagrame este independentă de instrumentul de modelare utilizat sau metodologia utilizată.

Procesul de modelare utilizând BPMN nu este facil și presupune parcurgerea următorilor pași [Silver, 2010]:

înțelegerea obiectivelor procesului de modelare – înainte de a începe să documentezi starea curentă a unui proces este necesar să înțelegi de ce trebuie să depui acest efort sau pe scurt ce încerci să obții: îmbunătățirea unui proces existent pentru eficientizarea acestuia sau adaptarea unui proces pentru lansarea unui nou produs sau poate documentarea procesului pentru o simplă auditare;

documentarea unui proces în starea sa curentă (as is) prin realizarea de interviuri, observarea activității personalului organizației și întâlniri menite să faciliteze o descriere cât mai amănunțită a procesului; este de asemenea necesesară crearea unei prime diagrame a procesului și confirmarea de către personalul organizației că într-adevăr aceasta este modalitatea curentă de funcționare a procesului respectiv;

analiza stării curente a procesului pentru a evidenția principalele probleme care conduc la o performanță scăzută a acestui proces; cele mai comune probleme sunt: abundența activităților secvențiale în defavoarea celor executate în paralel, pași redundanți executați pentru aprobarea, informarea, verificarea sau revizuirea unor activități, activități duplicate, lipsa validării, automatizare insuficientă, decalaje între nivelul de calificare a personalului și tipul activității pe care o execută, lacune în standardizare (aceiași activitate este executată diferit în departamente diferite ale organizației), birocrația.

propunerea unor îmbunătățiri pentru noul proces (to be) – ideal este să se identifice mai multe alternative de îmbunătățire a procesului și să se realizeze mai multe versiuni pentru noul model de proces care să fie foarte bine detaliate, care să definească resursele, costul, disponibilitatea, volumul de procesare zilnic al activităților modificate și nivelul de calificare al personalului care va fi implicat în execuția acestora.

analiza și validarea noului model de proces în concordanță cu obiectivele stabilite – orice modificare propusă pentru un anumit proces trebuie validată de către managerii organizației.

Simularea modelului procesului curent și compararea rezultatelor cu valorile reale (cunoscute) de timp și costuri aferente acestuia este necesară pentru a consolida ideea că modelul procesului curent este valid (câteodată este necesară iterarea unei diagrame și a parametrilor de simulare a acesteia până când se obțin valorile reale de timp și cost atașate procesului curent). Această simulare (bazată pe date reale) a procesului curent oferă credibilitate în momentul simulării procesului îmbunătățit.

Simularea presupune definirea de resurse pentru fiecare activitate desfășurată și timpul necesar pentru finalizarea acesteia. De asemenea punctele de decizie trebuie să aibă atașate probabilitățile de a urma o ramură sau alta sau pot avea atașate condiții specifice bazate pe date.

Un factor major în performanța procesului este reprezentat de modalitatea de alocare a resurselor mai ales dacă simularea evidențiază apariția unor blocaje sau decalaje majore de timp pentru anumite activități. Aceste blocaje sau decalaje de timp pot fi reduse prin realocarea resurselor sau altfel spus prin optimizare.

Simularea ajută prin testarea a numeroase alternative (pe hârtie) și compararea acestor alternative în termeni de timp și costuri. Aceste alternative sunt discutate cu managementul organizației și stakeholderi (alte părți interesate din organizație).

4.2. Soluții BPMN

Conform studiilor de piață realizate de Forrester, Microsoft Visio Premium 2010 este instrumentul cel mai frecvent utilizat de către analiști (mai mult de 75%) în vederea elaborării și validării de procese de afaceri în cadrul companiilor.

Figura 39 Microsoft Visio Premium 2010.

Simularea nu este una din funcționalitățile specific Microsoft Visio 2010 dar există soluții software cum ar fi Global 360 care oferă un add-in numit analystView care asigură suport pentru simularea procesului curent și optimizarea automată a noului model de proces.

Îmbunătățirea proceselor nu necesită întotdeauna automatizarea într-o soluție BPMS. Multe procese pot deveni mai performante prin simpla reorganizare a activităților acestora, automatizarea unor activități manuale sau prin clarificarea logicii procedurale a procesului explicit într-o diagramă partajată. Totuși pentru a maximize beneficiile BPM este recomandat să se utilizeze o soluție BPMS.

În Figura 9 se ilustrează componentele Global 360’s BPMS numit Process360. Microsoft Visio asigură analiza și modelarea proceselor, iar analystView furnizează procese executabile către designerView.

La lansarea unui proces utilizatorul interacționează cu sistemul prin intermediul rolurilor definite în userViews și poate monitoriza performanța procesului prin managerView. Microsoft SharePoint colectează toate modelele de procese, rapoartele de simulare, etc. (historical proces intelligence). Într-un astfel de sistem un model de proces executabil este lansat într-un motor de procese care rutează fiecare instanță a acestuia prin pașii descriși în model. Acesta creează activitățile specifice fluxului de lucru, execută și definește logica fluxului și regulile, interoghează și actualizează alte sisteme utilizate prin comandă direct din motorul de procese.

Proiectarea unor procese executabile într-un BPMS necesită detalii tehnice mai avansate decât cele oferite de către notația BPM analitică din Visio dar se poate obține translatarea directă între aceste două modele utilizând XPDL, un standard al Workflow Management Coalition. Global 360 analystView permite această translatare XPDL↔BPMN facilitând astfel integrarea modelelor BPMN create în Visio în designerView [Silver, 2010].

Figura 40 Process360 turns BPMN from Visio and analystView into an executable process solution. [Global360, 2013].

Momentan OMG anunță 76 soluții care implementează BPMN [OMG,2013]. Multe dintre acestea sunt disponibile gratis (AgilePoint, AuraPortal, Bonita Open Solution, etc.) dar nu au fost clasificate ca fiind printre cele mai bune BPMS conform Gartner. Cele mai performante soluții BPMS (conform criteriilor anunțate de Gartner în 2010) sunt prezentate în Figura 10.

Schimbat cu ultimul

Figura 41 Cvadrantul magic al BPMS [Gartner 2010].

4.3. Utilizarea BPMN

BPM este utilizat pentru a comunica o varietate mare de informații către o varietate mare de audiențe. BPMN este proiectat să ofere diverse tipuri de modelare și permite crearea unor BP end-to-end. Obiectele BPMN permit celui care le vizualizează să diferențieze ușor secțiunile unei diagrame BPMN. Există trei tipuri de submodele în cadrul unui model BPMN end-to-end:

Procese (Orchestrație), incluzând:

BP private non-executabile (interne);

BP private executabile (interne);

Procese publice;

Coreografii

Colaborări care pot include procese și/sau coreografii: Conversații

Procesele private (interne) sunt cele specifice unei organizații. Aceste procese sunt numite la modul general flux sau procese BPM. Un alt sinonim utilizat în cazul serviciilor web este de orchestrație de servicii. Există două tipuri de procese private: executabile și non-executabile. Un proces executabil este un proces care a fost modelat cu scopul de a fi executat în concordanță cu o anumită semantică descrisă în capitolul 14 din OMG BPMN specification 2.0 [OMG, 2011]. Un proces non-executabil este un proces care a fost creat cu scopul de a documenta comportamentul procesului respectiv. Cu alte cuvinte, informații necesare execuției unui proces cum ar fi de exemplu condiții (expressions) nu sunt incluse în procesele non-executabile.

Un proces privat poate fi delimitat într-un singur obiect pool. Fluxul procesului nu poate depăși granița marcată de pool. Fluxul de mesaje poate depăși această graniță pentru a putea evidenția astfel interacțiunea dintre mai multe procese private.

Figura 42 Exemplu de proces privat [OMG, 2011].

Un proces public este reprezintat de interacțiunile dintre un proces privat și un alt proces sau un alt participant. Numai obiectele activity care sunt utilizate pentru comunicarea cu un alt participant sunt incluse în procesul public. Toate celălalte obiecte activity ale procesului privat nu sunt evidențiate în procesul public. Cu alte cuvinte, procesul public evidențiază fluxurile de mesaje (prin obiectele message flows) și ordinea acestora, necesare în interacțiunea cu un alt proces. Procesele publice pot fi modelate separat sau într-o colaborare pentru a evidenția fluxul de mesaje dintre activitățile procesului public și alți participanți. Procesele publice au fost numite procese abstracte în BPMN 1.2.

Figura 43 Exemplu de proces public [OMG, 2011].

O colaborare descrie interacțiunile dintre una sau mai multe entități. O colaborare conține de obicei unul sau mai multe obiecte pool care reprezintă participanții din colaborarea respectivă. Mesajele interschimbate între participanți sunt evidențiate prin obiecte message flow care conectează obiectele pool. O colaborare poate fi reprezentată de două sau mai multe procese publice care comunică. Pentru procesele publice obiectele activity pentru participanții la colaborare pot fi considerate puncte de contact între participanți. Procesele interne (executabile) asociate sunt mult mai detaliate decît procesele publice afișate. Toate combinațiile de obiecte pool, procese și coreografii sunt permise într-o colaborare.

Figura 44 Exemplu de proces colaborativ[OMG, 2011].

O coreografie definește comportamentul dintre participanți fără implicarea unor obiecte pool sau orchestrații. Un proces este definit în cadrul unui obiect pool pe când coreografia există între obiectele pool (sau participanți). Coreografia este similară unui proces privat deoarece constă dintr-o rețea de obiecte activity, event, gateway. Totuși coreografia este diferită deoarece activitățile sale reprezintă de fapt un set de schimburi de mesaje care implică unul sau mai mulți participanți. Deasemenea nu există o entitate responsabilă sau observator al procesului respectiv.

Figura 45 Exemplu de coreografie[OMG, 2011].

Selecția corectă a tipurilor de procese ce vor fi modelate se realizează conform diagramei BPMN prezentată în Figura 15.

Figura 46 Tipuri de procese [Venter, 2010].

O diagramă de conversație este o formă particulară și în același timp oferă și o descriere informală a diagramei de colaborare. În acest tip de diagramă obiectele pool ale unei conversații nu conțin procese iar o coreografie nu este în mod uzual plasată în interiorul unor obiecte pool ale diagramei de conversație. O conversație definește logica schimbului de mesaje. Această relație logică de obicei referă un obiect cum ar fi: comandă, transport, factură. Schimburile de mesaje sunt relaționate între ele și reflectă diferite scenarii specifice afacerii. De exemplu, în logistică, actualizarea stocurilor implică următoarele tipuri de scenarii: crearea unor comenzi, alocarea unor transportatori pentru mai multe comenzi combinate, trecerea vamei, procesarea plăților și investigarea excepțiilor. O diagramă de conversație prezintă conversațiile în construcții de tip hexagon legând participanții (obiecte pool). Astfel obținem o vedere de ansamblu asupra diferitelor conversații din domeniul studiat.

Figura 47 Exemplu de conversație[OMG, 2011].

4.4. Obiectele BPMN

Scopul BPMN este de a crea mecanisme simple și ușor inteligibile pentru a crea modele pentru procese de afaceri complexe. Ca atare primul pas a fost să se organizeze toate obiectele grafice în categorii. Acestea oferă un set de notații care ajută în recunoașterea obiectelor principale ale unei diagrame. Principalele categorii de obiecte sunt:

Flow objects – acestea sunt principalele obiecte grafice care definesc comportamentul unui BP; există trei obiecte de acest tip: Events; Activities; Gateways;

Data – reprezentată de patru obiecte: Data objects; Data inputs; Data outputs; Data stores;

Connecting Objects: Sequence flows; Message flows; Associations; Data associations;

Swimlanes: Pools; Lanes ;

Artifacts – sunt utilizate pentru a oferi informație adițională despre proces; există două astfel de obiecte standard: Group; Text annotation.

Principalele obiecte BPMN sunt descrise în Tabelul 3.

Tabelul 3 Obiecte de bază BPMN [OMG, 2011].

În tabelele care urmează sunt prezentate obiectele care pot avea un flux de secvență sau mesaj ca intrare/ieșire.

Tabelul 4 Fluxuri de secvență și regulile fluxurilor de mesaje [Polancic,Tomislav 2008].

Tabelul 5 Tipuri de evenimente.

În procesul de modelare descriem evenimente care au loc și prezentăm modalitatea în care acestea afectează fluxul întregului proces. Un eveniment declanșează un proces, are loc în timpul procesului sau încheie un proces. BPMN oferă notații distincte pentru fiecare din aceste trei tipuri de evenimente.

În cazul în care modelăm procese complexe (de exemplu servicii web B2B) avem nevoie de evenimente mai complexe de tip message, timer, business rule și error condition. BPMN ne permite să specificăm tipul de declanșator (trigger type) pentru fiecare eveniment demarcându-le cu ajutorul unor simboluri speciale prezentate în Tabelul 5. Precizând un tip de declanșator pentru fiecare eveniment de fapt adaugăm restricții fluxului de proces descris. De exemplu un eveniment de tip timer nu poate finaliza un proces sau un message flow nu poate conecta decât două evenimente de tip message.

Tipologia evenimentelor descrise în Tabelul 3 este prezentată pe larg în Tabelul 5.

Evenimentele Start și unele evenimente Intermediate prezintă declanșatori (triggere) care definesc o cauză evenimentului. Există multiple modalități în care aceste evenimente pot fi declanșate. Evenimentele End pot avea un rezultat adică o consecință a fluxului procesului. Evenimentele Start pot doar reacționa la un declanșator (catch the trigger).

Evenimentele End pot doar să creeze un rezultat (throw a trigger). Evenimentele Intermediate pot reacționa la un declanșator dar în același timp pot creea și un rezultat. Deasemenea există evenimente care sunt utilizate pentru a întrerupe activități sau nu.

Obiectele extinse ale BPMN sunt descrise în Tabelul 6.

Figura 48 Mecanismul fluxurilor de secvență [Polancic,Tomislav 2008].

Tabelul 6 Obiecte extinse BPMN [OMG, 2011].

4.5. Șabloane și capcane comune

În continuare voi prezenta câteva dintre capcanele comune întâlnite în procesul de modelare:

Utilizarea greșită a fluxurilor în/între obiectele pool: când modelăm obiecte pool fluxurile de secvență și evenimentele start/end lipsesc adesea pentru că se presupune greșit că fluxurile de mesaje înlocuiesc fluxurile de secvență; adițional fluxurile de secvență sunt utilizate incorect pentru a conecta participanții. Corect este să modelăm fluxul în fiecare obiect pool independent și ulterior să definim fluxurile de mesaje între obiectele pool.

Figura 49 Utilizarea greșită a fluxurilor în/între obiectele pool [Polancic,Tomislav 2008].

Utilizarea greșită a obiectelor event timer: două greșeli sunt comune când se utilizează aceste obiecte; în primul rând obiectele start event sunt utilizate incorect în locul obiectelor intermediate event, în al doilea rând evenimentele intermediare sunt adesea utilizate ca mecanisme de amânare în loc de mecanisme de excepție (reprezentând durata unei sarcini) și vice-versa.

Figura 50 Utilizarea greșită a obiectelor event timer [Polancic,Tomislav 2008].

Utilizarea mecanismului fluxului de secvență: când se folosesc sub-procese extinse, fluxurile de secvență ar trebui să fie conectate la granițele sub-proceselor.

Figura 51 Utilizarea mecanismului fluxului de secvență [Polancic,Tomislav 2008].

Utilizarea fluxurilor în cadrul obiectelor lane: obiectele lane sunt adesea utilizat eronat în locul obiectelor pool, ele conțin adesea mai multe procese de afaceri sau conțin fluxuri de mesaje între obiecte pool diferite

Figura 52 Utilizarea fluxurilor în cadrul obiectelor lane [Polancic,Tomislav 2008].

Utilizarea obiectelor gateway: obiectele gateway sunt conectate numai cu fluxuri de secvență, iar punctele de decizie trebuie să conțină cel puțin două fluxuri de ieșire.

Utilizarea obiectelor task și a evenimentelor: analiștii modelează des eronat evenimentele și obiectele task în sensul că evenimentele sunt modelate greșit ca obiecte task, iar stările obiectelor task sunt modelate ca obiecte task noi.

Figura 53 Utilizarea obiectelor task și a evenimentelor [Polancic,Tomislav 2008].

Utilizarea evenimentelor message și ale fluxurilor de mesaje: start event și intermediate event nu pot fi surse pentru fluxuri de mesaje, evenimentele pot fi doar declanșate de un flux mesaj.

În Figura 54 este prezentată o diagramă de colaborare care prezintă succint modalitatea corectă de utilizare a obiectelor BPMN.

Figura 54 Utilizarea obiectelor BPMN într-o diagramă de colaborare [BPM Offensive, 2011].

4.6. Exemple de diagrame BPMN

Așa cum am anunțat anterior cu ajutorul BPMN putem realiza o singură diagramă pentru un proces de afaceri numită BPD (Business Process Diagram). Pentru a modela fluxul specific unui BP se descriu evenimentele care determină activarea unui proces, activitățile sau sub-procesele care se execută și evenimentele care încheie procesul respectiv. Punctele de decizie așa cum am anunțat anterior sunt modelate cu ajutorul gateway-urilor.

Exemplele prezentate în continuare au caracter didactic și sunt create cu scopul de a evidenția modalitatea de utilizare a obiectelor BPMN. Aceste modele nu conțin procese executabile ci sunt procese prin care sunt reprezentate aspecte organizaționale ale proceselor de afaceri.

Exemplul 1

Procesul care va fi modelat în continuare îl vom intitula Aprobarea investițiilor în punctele de lucru [AuraPortal, 2012].

Abordare: un responsabil al punctului de lucru dorește să obțină aprobare pentru realizarea unor noi investiții și pentru aceasta este necesar să completeze un formular care să conțină date relevante referitoare la investiția dorită.

La completarea acestui formular numit Cerere pentru Aprobarea investițiilor în punctele de lucru trebuie să se genereze un mesaj care să declanșeze procesul Aprobarea investițiilor în punctele de lucru. Odată ce procesul se declanșează o sarcină numită Revizuirea primei aplicări trebuie adăugată în coada de așteptare a sarcinilor managerului punctelor de lucru. Când managerul punctelor de lucru va accesa sarcina, va examina datele furnizate în mesaj.

Figura 55 BPD Exemplul 1 – Aprobarea investițiilor în punctele de lucru.

După luarea unei decizii, acesta va completa un formular unde se anunță decizia de aprobare sau respingere a cererii:

Dacă investiția nu este aprobată trebuie să redirectăm fluxul către o sarcină de sistem numită Respingere cerere și procesul se încheie. Această sarcină de sistem notifică responsabilul punctului de lucru în legătură cu respingerea cererii.

Dacă investiția se aprobă de către manager, fluxul este redirectat către un nou punct de decizie în vederea solicitării unei a doua aprobări care se obține de la un manager de divizie. Pentru lua această decizie trebuie luate în considerare două criterii: cât de mare este investiția și riscul de țară asociat punctului de lucru respectiv.

Dacă o a doua aprobare nu este necesară fluxul este redirectat în sensul creării unui document Aprobare cerere semnat digital de către manager; după ce se consemnează momentul în care se aprobă cererea se declanșează alte procese ale companiei care vizează realizarea propriu-zisă a investiției pentru ca la final să se realizeze înregistrările contabile aferente investiției.

Dacă o a doua aprobare este necesară fluxul, cererea trebuie să fie trimisă numai în intervalul orar 10.00-12.00 a zilei de Luni sau Vineri, cu alte cuvinte procesul este amânat până când managerul de divizie examinează cererea deja aprobată de către manager pentru a lua propria decizie.

Exemplul 2

Procesul care va fi modelat în continuare îl vom intitula Planificarea unei călătorii [ArisCommunity, 2013]. Există numeroase activități pe care le desfășurăm în momentul în care dorim să planificăm o călătorie. Motiv pentru care este necesar ca după plasarea obiectului start event să inserăm un obiect parallel gateway. Vom modela un user task (sarcină utilizator) Rezervă zbor și un system task (sarcină automată) Rezervă hotel.

Figura 56 BPD Exemplul 2 – Planificarea unei călătorii [ArisCommunity, 2013].

Rezervarea hotelului se realizează de către o agenție de voiaj și ca atare vom modela această interacțiune utilizând un obiect pool.

Obiectul pool Agenția de voiaj va avea două obiecte lane Angajat agenție și Serviciu relații cu clienții. Vom plasa un start event de tip message în interiorul obiectului lane Angajat agenție pentru a iniția o conversație. Acest eveniment va fi conectat cu un user task Verifică date client.

Vom plasa un send task Rezervă cameră hotel în interiorul obiectului lane Serviciu relații cu clienții pe care îl vom conecta cu un receive task Confirmare de primire.

Vom plasa un user task numit Compune răspuns în interiorul obiectului lane Angajat agenție pe care îl vom conecta cu un message end event pentru a evidenția că această parte a procesului s-a încheiat cu trimiterea unui mesaj.

Vom conecta Verifică date client cu Rezervă cameră hotel și Confirmare de primire cu Compune răspuns.

Vom conecta Rezervă hotel cu Message Start Event din interiorul obiectului lane Angajat agenție.

Vom conecta Message End Event din interiorul obiectului lane Angajat agenție cu Rezervă hotel.

În acest moment am finalizat modelarea acestei comunicări.

Hotelul va trebui să confirme rezervarea. Ca atare vom introduce un nou obiect pool în care vom modela o cerere către hotel, procesarea acesteia și trimiterea unui răspuns.

În ceea ce privește modalitatea de a călători va trebui să modelăm un flux standard și unul alternativ în care vom modela posibilitatea de a călători cu mașina personală fără a opta pentru cazare. Pentru aceasta vom verifica ruta și vom modela un eveniment intermediar de compensare pentru anularea rezervării realizate pentru zbor și hotel.

Exemplul 3

Procesul care va fi modelat în continuare îl vom intitula Planificarea unui transport de bunuri. În acest exemplu utilizăm doar un obiect pool și trei obiecte lane pentru participanții implicați în proces ceea ce înseamnă că nu modelăm și comunicarea dintre aceștia, presupunând că ea există într-o formă sau alta.

Figura 57 BPD Exemplul 3 – Planificarea unui transport de bunuri [OMG, 2010].

Dacă am utiliza un motor de procese, acesta ar gestiona comunicația dintre participanți prin atribuirea de user task-uri. Dacă nu dispunem de un astfel de motor de procese dar dorim totuși să modelăm comunicarea dintre participanți putem crea o diagramă de colaborare.

Evenimentul de start Bunuri de expediat indică faptul că marfa deja a fost pregătită pentru expediere. Imediat după instanțierea procesului se vor desfășura două acțiuni în paralel așa cum anunța și obiectul parallel gateway: un funcționar va trebui să decidă dacă acesta este un transport normal sau special, timp în care, un manipulator împachetează produsele pentru expediere. Sarcina executată de către funcționar și urmată de un obiect exclusive gateway este un bun exemplu pentru a clarifica modalitatea corectă de utilizare a obiectelor gateway: acestea sunt responsabile doar de rutarea fluxului ca urmare a unei sarcini sau activități anterioare și oferă alternative. Obiectul gateway este exclusive deoarece numai una dintre cele două alternative oferite poate fi traversată: dacă avem nevoie de un transport special funcționarul Solicită costuri de expediție de la diverși transportatori, Atribuie un transportator și apoi creează documenția necesară, altfel funcționarul trebuie să verifice dacă este necesară întocmirea unei polițe de asigurare suplimentare. Dacă acest lucru este adevărat managerul trebuie să se ocupe de obținerea acesteia. În oricare din cazuri funcționarul trebuie să creeze o etichetă poștală pentru colet. În cazul acestui scenariu obiectul gateway inclusive este cea mai bună alegere deoarece trebuie să marcăm faptul că doar una din cele două alternative este întotdeauna urmată în timp ce cealaltă doar dacă e nevoie de o asigurare suplimentară, și dacă este aleasă cea din urmă aceasta trebuie realizată în paralel cu prima alternativă. Datorită acestui paralelism avem nevoie de obiectul de sincronizare inclusive gateway imediat după Creare etichetă poștală și Poliță suplimentară.

Exemplul 4

Figura 58 BPD Exemplul 4 – Colaborare B2B [OMG, 2010].

Exemplul care urmează (Figura 58) exemplifică o colaborare business-to-business (B2B). Deoarece dorim să modelăm interacțiunea dintre un client și un vanzător în mod explicit trebuie să creăm un obiect pool pentru fiecare dintre acești doi participanți.

Clientul selectează un produs, îl comandă și așteaptă expedierea acestuia. Obiectul gateway plasat după obiectul task Comandă produs indică faptul că participantul așteaptă două evenimente care se pot întâmpla: produsul este expediat imediat sau cu întârziere. După 60 minute clientul apelează telefonic vânzătorul. Presupunem că funcționarul promite expedierea produsului și clientul așteaptă din nou ca acesta să fie expediat. Din perspectiva vânzătorului acesta trebuie doar să expedieze produsul să încaseze banii și să ofere o chitanță clientului.

În acest exemplu utilizăm obiecte message nu numai pentru cazul informal cum ar fi realizarea comenzii ci și pentru obiecte fizice cum sunt produsul în sine sau banii. Putem face acest lucru deoarece aceste obiecte sunt purtătoare de informație și deoarece nu modelăm un proces executabil.

Exemplul 5

Procesul care va fi modelat în continuare îl vom intitula Managementul comenzilor. Acest proces începe după recepționarea unei cereri și continuă cu verificarea disponibilității produsului respectiv. Dacă articolul se regăsește pe stoc atunci acesta este expediat clientului împreună cu un Acord financiar modelat în această diagramă ca sub-proces. În cazul în care articolul nu este disponibil acesta va fi comandat prin apelarea sub-procesului Procurare. Să observăm ca reprezentarea utilizată este cea a unui obiect call activity. O altă caracteristică a acestui sub-proces este faptul că are atașate două evenimente cu ajutorul cărora putem gestiona situații care pot apare spontan la momentul execuției unei activități sau sub-proces. De aceea este necesar să facem distincție între evenimentele întreruptibile și cele non-întreruptibile. Spre deosebire de evenimentele întreruptibile cele non-întreruptibile nu opresc execuția activității sau sub-procesului la care sunt atașate.

Figura 59 BPD Exemplul 5 – Managementul comenzilor [OMG, 2010].

Procesul Managementul stocului este declanșat de către un eveniment condițional. Aceasta înseamnă că procesul este instanțiat în cazul în care condiția devine adevărată, în acest caz dacă stocul are o valoare sub limita minimă stabilită. Pentru a crește nivelul stocului este necesară achiziționarea articolului. Ca atare vom utiliza același proces Procurare din BPD anterioară și o vom referi prin obiectul call activity cu același nume. Similar cu procesul anterior modelăm și situația în care articolul nu poate fi achiziționat și trebuie retras din catalog.

Figura 60 BPD Exemplul 5 –Managementul stocului [OMG, 2010].

În continuare voi descrie sub-procesul Procurare utilizat în ambele procese descrise mai sus. Deoarece acesta este un sub-proces evenimentul de start nu prezintă un tip anume indicând astfel că procesul nu este declanșat de un eveniment extern ci că face referire la procese aflate pe un nivel superior. Prima activitate din acest sub-proces este de a verifica dacă articolul este disponibil la furnizor. Dacă nu este disponibil la furnizor se va genera un eveniment Indisponibil de tip error. În cazul în care achiziționarea articolului durează mai mult de două zile, se modelează acest lucru utilizând un eveniment de escalare de tip throw pentru a permite referirea către procesele de pe nivelul imediat superior. Similar evenimentului tip error evenimentul de escalare are un asociat cod necesar pentru conectarea evenimentelor de escalare de tip catch și throw. Contrar evenimentelor de tip error firele de execuție active nu sunt afectate de către evenimentele intermediare de escalare tip throw. Mai mult procesul își continuă execuția deoarece se așteaptă livrarea.

Figura 61 BPD Exemplul 5 –Sub-procesul Procurare [OMG, 2010].

Exemplul 6

În continuare voi prezenta cum se pot obține perspective diferite a aceluiași proces utilizând BPMN. În primul pas voi prezenta o diagramă pentru un proces de gestionare a unei situații excepționale care poate surveni la un moment dat într-o organizație. Apoi, voi rafina acest model prin transferarea de la orchestrație la colaborare și apoi la coreografie. Scopul acestui exemplu este de a crea diagrame simple și abstracte dar și pentru a detalia colaborarea și a crea specificații tehnice necesare execuției unui proces.

Figura 62 BPD Exemplu 6 – Gestionarea unei situații excepționale –privire de ansamblu

[OMG, 2010].

Procesul descris în modelul din Figura 62 este declanșat de către un client care solicită ajutor din partea managerului de cont asociat în legătură cu un produs achiziționat. Managerul va încerca să gestioneaze situația singur și să explice clientului modalitatea de rezolvare a problemei sale. Dacă nu reușește va pasa problema unui agent din departamentul de relații cu clienții de nivel 1, iar acesta la rândul său la un coleg din departamentul de relații cu clienții de nivel 2 dacă este necesar. Acesta din urmă poate întreba un coleg din departamentul de dezvoltare în cazul în care nu este sigur că acest client poate rezolva singur problema. Această diagramă reflectă situația fericită în care se găsește o rezolvare problemei clientului. Modelul nu detaliază colaborarea dintre angajați iar utilizarea activităților abstracte denotă faptul că nu știm care din părțile acestui proces sunt executabile. Această diagramă este utilă pentru a înțelege scopul procesului, fluxul acestuia, dar nu este utilă dacă dorim să îmbunătățim procesul respectiv.

Figura 63 BPD Exemplu 6 – Gestionarea unei situații excepționale –colaborare detaliată

[OMG, 2010].

În figura 63 am creat o diagramă de colaborare mult mai detaliată care ne permite vizualizarea tuturor proceselor participanților și de asemenea am setat activitățile ca fiind de tip manual ceea ce denotă că gândim întregul proces ca fiind non-executabil. De fapt această diagramă reflectă starea as-is a procesului. Următorul pas în demersul nostru este de a decide dacă întreaga colaborare descrisă în diagramă va face subiectul unui motor de procese sau doar o parte din ea. Înainte de a lua acestă decizie putem crea o coreografie care să reflecte doar activitățile care sunt dedicate comunicării dintre participanți, ascunzând celălalte activități. Diagramele din Figura 62 și 63 nu au nici o conexiune formală între ele spre deosebire de Figura 63 și 64 care reprezintă același model semantic dar perspective diferite.

Dacă dorim să automatizăm procesul prezentat (Figura 65) putem în acest moment să decidem care părți din acesta ar trebui executate într-un motor de procese și care nu. Vom considera un scenariu în care managerul de client nu va fi deranjat cu formulare web sau liste de sarcini, acesta având doar responsabilitatea de a trimite un email când dorește să raporteze o problemă a clientului și să primească un răspuns când această problemă a fost rezolvată. Aceiași idee se aplică și dezvoltatorului, care vom presupune că se află în aceiași cameră cu agentul din departamentul de relații cu clienții nivel 2 și ca atare această colaborare nu va fi automatizată.

În schimb, cererile către agenții din departamentul de suport vor fi automatizate prin introducerea unui sistem care să preia rolul de motor de procese și ca atare va fi modelat într-un obiect pool separat. Acest sistem poate recepționa și analiza un email trimis de către managerul de client și genera o cerere de tratare a problemei.

Dacă agentul din departamentul de relații cu clienții nivel 1 consideră că este o problemă care poate fi tratată doar la nivel 2, acesta își va documenta decizia și va finaliza sarcina editează cerere la nivel 1. Această cerere este mai departe rutată către agentul din departamentul de relații cu clienții nivel 2 și când acest agent finalizează propria analiză poate decide că această problemă nu poate fi rezolvată decât la lansarea următoarei versiuni a produsului. În acest moment sistemul propus va realiza un apel către sistemul care monitorizează și înregistrează cererile nesoluționate referitoare la produsul software și va solicita realizarea unei noi înregistrări. La final sistemul va trimite un email către managerul de client care conține soluția problemei și va închide cererea.

Această modalitate de a modela fluxurile automatizate și cele manuale reprezintă una din posibilitățile care există și demonstrează cum poate BPMN să asigure suportul pentru alinierea Business –IT din perspectiva modelării proceselor. Astfel, în timp ce utilizăm un motor de procese putem de asemenea să prezentăm separat celorlalți participanți obiectele pool asociate lor în cadrul colaborării astfel încât să se poate discuta nivelul de implicare a acestora fără necesitatea de a prezenta întregul model de colaborare. Astfel se poate discuta modelul propus fără a aglomera nici una din părțile implicate (Business și IT) cu diagrame complexe.

Figura 64 BPD Exemplu 7 – Gestionarea unei situații excepționale –coreografie [OMG, 2010]

Figura 65 Exemplul 8 – Gestionarea unei situații excepționale –automatizare parțială a procesului [OMG, 2010].

5. Comparație între notațiile oferite de standardele grafice UML și BPMN

Aici se va introduce materialul [White S., 2004] , [Sparxsystems, 2013]

Bibliografie

[Ambler, 2004] Ambler Scott, The Object Primer: Agile Model Driven Development with UML 2.0,Cambridge University Press, Cambridge, 2004.

[Appian, 2013] Appian Learning Center, Introduction to BPM, http://www.appian.com/bpmbasics/bpmintro.jsp, accesat în data de 2 octombrie 2013.

[ArisCommunity, 2013] Learn how to model BPMN diagrams in ARIS Express http://www.ariscommunity.com/videos/learn-how-model-bpmn-diagrams-aris-express, accesat în data de 11 martie 2013.

[AuraPortal, 2012] User Guide BPM Modeler Java, www.AuraPortal.com

[BPM Offensive, 2011] BPMN 2.0 Business Process Model and Notation poster, accesat în data de 13 februarie 2013, http://www.bpmb.de/images/BPMN2_0_Poster_EN.pdf

[Brennan, 2006] Kevin Brennan, RAD Stencil, 2006, https://www.graffletopia.com/stencils/140, accesat în data de 3 octombrie 2013.

[Dorobăț, 2012] Iuliana Dorobăț, Laura Mina, Radu Constantinescu, Alexandru Pavel, „Extension of the European Union Services Directive – Implementation in Romania”, Transylvanian Review of Administrative Sciences, nr. 35 E, pp. 78-92, 2012, ISSN: 2247 – 8310.

[Dumas M., ter Hofstede A.H.M., 2001] Marlon Dumas, Arthur H.M. ter Hofstede, „UML activity diagrams as a workflow specification language”, UML 2001: 4th International Conference on the Unified Modeling Language: Modeling Languages, Concepts, and Tools, Toronto, pp. 76-90, 2001.

[Eriksson et.al, 1998], Eriksson Hans-Erik, Penker Magnus, UML Toolkit, 1998, John Wiley & Sons, Inc., New York.

[Gartner, 2010] Magic Quadrant for Business Process Management Suites, http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/enterprise/pdfs/magic-quadrant-for-business-process-management-suites.pdf accesat în data de 13 februarie 2013.

[Giurcă, 2004] Giurcă Adrian, Introducere în UML, http://inf.ucv.ro/~giurca/courses/CB3105/archive.htm, accesat data de 13 noiembrie 2013.

[Global360, 2013] http://bps.opentext.com/solutions/solution/microsoft, accesat în data de 13 februarie 2013.

[Muehlen, 2007] Michael zur Muehlen, „Business Process Management Standards, Origin, Overview and Directions”, Howe Scholl of Technology Management, Stevens Institute of Technology, Hoboken NJ, http://www.slideshare.net/mzurmuehlen/business-process-management-standards-tutorial?from_search=1 , accesat în data de 30 septembrie 2013.

[Odeh et.al , 2002] M. Odeh, I. Beeson, S. Green and J. Sa, Modelling Processes Using RAD and UML Activity Diagrams: an Exploratory Study, Systems Modelling Research Group, ACIT 2002, http://www.cems.uwe.ac.uk/~sjgreen/RAD&AD_V2.pdf, accesat în data de 3 octombrie 2013.

[OMG, 2009] UML 2.2 Superstructure Specification, OMG, http://www.omg.org/spec/UML/2.2/Superstructure/PDF, accesat în data de 22 noiembrie 2012.

[OMG, 2010] BPMN 2.0 by example, http://www.bpmn.org/ accesat în data de 13 februarie 2013.

[OMG, 2011] Business Process Model and Notation (BPMN), OMG, http://www.omg.org/spec/BPMN/2.0/PDF, accesat în data de 22 noiembrie 2012.

[Owen, Raj, 2003] Martin Owen, Jog Raj, BPMN and Business Process Management, Popkin Software, www.popkin.com, 2003.

[Podeswa, 2005] Podeswa Howard, UML for the IT Business Analyst:A Practical Guide to Object-Oriented Requirements Gathering, Thomson Course Technology PTR, 2005, ISBN: 1-59200-912-3, http://www.whiteboxqa.com/StudentMaterial/Books/IP-BA-UML%20for%20the%20IT%20Business%20Analyst%20A%20Practical%20Guide%20to%20Object%20Oriented%20Requirements%20Gathering.pdf, accesat data de 13 noiembrie 2013.

[Polancic,Tomislav, 2008] Polancic Gregor, Tomislav Rozman, Business Process Modelling Notation Poster, 2008.

[Recker and Mendling, 2006] Jan Recker, Jan Mendling, „On the translation between BPMN and BPEL: conceptual mismatch between process modeling languages”, in Latour, T. and Petit, M. (Eds), Proceedings of the 18th International Conference on Advanced Information Systems Engineering, Luxembourg, pp. 521-32, 2006.

[Russell N., van der Aalst W.M.P., ter Hofstede A.H.M., Wohed P. 2006] Russell N., van der Aalst W.M.P., ter Hofstede A.H.M., Wohed P., „On the suitability of UML 2.0 activity diagrams for business process modeling”, Proceedings of the 3rd Asia-Pacific Conference on Conceptual Modelling, Vol. 53, pp. 95-104, 2006.

[Ryan K.L. Ko et al., 2009] Ryan K.L. Ko, Stephen S.G. Lee, Eng Wah Lee, „Business process management (BPM) standards: a survey”, Business Process Management Journal, Vol. 15, No. 5, pp. 744-791, 2009.

[Silver, 2010] Bruce Silver, Jump start your BPM program with standard-based process modeling, Industry Trend reports, 2010.

[Sparxsystems, 2013] Comparing UML activities to BPMN processes, http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/model_simulation/bpmn_simulation_comparison.html, accesat data de 13 noiembrie 2013.

[van der Aalst et al., 2003] van der Aalst, W.M.P., ter Hofstede, A.H.M. and Weske, M. (2003), „Business process management: a survey”, Proceedings of the International Conference on Business Process Management, BPM 2003, Eindhoven, The Netherlands, 26-27 June 2003.

[Venter, 2010] Etienne Venter, BPMN starter guide: Which process type to use?, http://www.ariscommunity.com/users/etienne/2010-08-27-bpmn-starter-guide-which-process-type-use, accesat în data de 26 februarie 2013,

[White S., 2004] White Stephen, „Process modeling notations and workflow patterns”, Workflow Handbook, Future Strategies, Lighthouse Point, FL, pp. 265-294, 2004, http://www.omg.org/bpmn/Documents/Notations_and_Workflow_Patterns.pdf, accesat data de 13 noiembrie 2013.

[Roșca I. et al., 2004] I. Roșca, D. Mangiuc, D. Boldeanu, O. Secătureanu, C. Țarțavulea, D. Băbeanu, Proiectarea obiectuală a sistemelor informatice, 2004, Editura InfoMega, București.

[Haliga, 2013] D. Haliga, Cine este Business Analyst-ul și de ce aș avea nevoie de el?, Today Software magazine, nr. 9, martie 2013, http://www.todaysoftmag.ro/tsm/magazines/TSM_9_2013_ro.pdf, accesat la data de 9 noiembrie 2015.

[Siegel, 2008] J. Siegel, In OMG’s OCEB Certification Program, What is the Definition of Business Process?, OCEB Certification Program White Paper 2008, http://www.omg.org/oceb/defbusinessprocess.htm, accesat la data de 9 noiembrie 2015.

[Baker, 2006] Standards in Business Modeling and Integration The BPM – SOA Connection, 2006 OMG Workshops, http://omg.net/news/meetings/workshops/soa-bpm-mda-2006/04-1_Baker.pdf, accesat la data de 6 ianuarie 2016.