Modelarea Proceselor de Afaceri cu Ajutorul Bpmn

CUPRINS

INTRODUCERE 4

1.3.1 Descrierea și modelarea proceselor de afaceri 10

1.3.2 Metodologiile de modelare ale afacerii 11

CAPITOLUL 2 MODELAREA PROCESELOR DE AFACERI FOLOSIND BPMN 13

2.1 Notația BPMN 14

2.1.1 Modelarea evenimentelor în afaceri 15

2.1.2 Procese, subprocese și sarcini de afaceri 18

2.1.3 Simularea proceselor de afaceri 21

2.2 Legătura dintre BPMN și UML 21

2.2.1. Despre BPMN și UML 23

2.2.2.Tipuri de procese care pot fi modelate 26

2.3 Maparea la BPEL4WS 30

2.4 Implementări BPMN 31

CONCLUZII 33

BIBLIOGRAFIE 34

INTRODUCERE

Procesele de afaceri sunt o colecție de unități de muncă consecutive, alternative și paralele cu obiectivul de a crea valoare pentru clienții săi sau pentru organizația din care face parte. Pentru aș atinge scopul, procesele de afaceri comunică cu alte procese ce pot aparține aceleiași organizații sau a altei organizații.

Odată cu existența proceselor de afaceri vine nevoia de a gestiona aceste procese. Gestionarea în acest caz se referă la activitățile întreprinse de către organizații pentru a proiecta, analiza, optimiza și adapta la procesele lor. Aceste activități sunt rezumate ca managementul proceselor de afaceri. În ultimii 20 de ani asistăm la un interes tot mai mare în domeniul managementului proceselor de afaceri (BPM), a unei comunități tot mai mare de manageri, utilizatori, analiști, consultanți, furnizori și academicieni. Acest lucru este vizibil în numărul substanțial de cunoștințe, o serie de metodologii, instrumente, tehnici, și un domeniu de aplicare tot mai mare. Business Process Management (BPM), nu este o noua teorie de management, dar este un nou mod de lucru.

În Process-Aware Information System (PAIS), procesele de afaceri sunt adesea modelate într-un mod explicit. Se poate spune, grosso modo, că limbajele de modelare a proceselor de afaceri pot fi împărțite în două grupuri. Limbajele din primul grup sunt preferate de către oamenii din mediul academic, dar evitate de cei din afaceri – aici sunt incluse rețelele Petri. Aceste limbaje au o semantică formală corespunzătoare, care permitw modelelor să fie verificate într-un mod formal. Limbajele din al doilea grup sunt preferate de către oamenii de afaceri, dar displăcute de oamenii din mediul academic – aici sunt incluse BPEL, BPMN și EPC. Acestor limbaje le lipsește de multe ori o semantică corespunzătoare, care duce adesea la dezbateri cu privire la modul de interpretare a anumitor modele de afaceri. O excepție de la această clasificare este YAWL (Yet Another Workflow Language), care își are rădăcini în lumea academică, dar este folosit și în practică, utilizează semantica rețelelor reset.

În cadrul capitolului 1, am prezentat procesele de afaceri, modalitățile de descriere a acestora, elementele proceselor de afaceri, precum și modelarea proceselor de afaceri.

Simularea proceselor de afaceri este considerată ca fiind extrem de relevantă și aplicabilă, utilizarea de simulare este limitată în realitate. Multe organizații au încercat, la un moment dat, să folosească simularea pentru analiza proceselor de afaceri. Cu toate acestea, puține organizații utilizează simularea într-un mod structurat și eficient. Acest lucru poate fi cauzat de o lipsă de formare și de limitările instrumentelor existente, dar există și altfel de probleme și mai fundamentale.

Capitolul 2 prezintă notația BPMN pentru modelarea proceselor de afaceri, o comparare între BPMN și UML și câteva implementări.

Inițiativa procesului de afaceri BPMI a dezvoltat notația pentru modelarea proceselor de afaceri BMPN. Specificația BPMN 1.0 a fost lansată pentru public în mai 2004. Această specificație reprezintă mai mult de doi ani de efort de către Grupul de notație BPMI. Scopul principal al celor de BPMN fost de a crea o notație ușor de înțeles de către toți utilizatorii de afaceri, de la analiștii de afaceri care dezvolă proiecte inițiale ale proceselor, către dezvoltatorii tehnici responsabili pentru punerea în aplicare a tehnologiei care ruleaza toate procesele pe care în cele din urmă va fi monitorizarea acestor procese de către persoaneledin domeniul afacerilor.

BMPN de asemenea vă fi sprijinit cu un model intern care va permite executarea BPEL4WS. Cu alte cuvinte, BMPN crează o punte standardizată pentru lacuna dintre procesele design de afaceri și procesul de implementare.

BPMN definește o Diagramă a proceselor de afaceri (BPD), bazată pe tehnica modelelor grafice ale operațiilor proceselor de afaceri. Un model al proceselor de afaceri este o rețea de obiecte grafice, ale căror activități și ale căror controale definesc disciplina performanței.

CAPITOLUL 1. PROCESELE DE AFACERI

Definirea proceselor de afaceri

Procesul de afaceri reprezintă o colecție de activități ce au ca scop obținerea unui output specific pentru un anumit client sau piață, utilizând un set de inputuri – intrări. Accentul se pune pe modul în care sunt realizate activitățile dintr-o organizație și nu pe ce tip de produs se obține efectiv. Un astfel de proces constă într-o ordonare specifică de activități ce au loc într-un timp și spațiu determinat, având un început, un sfârșit, precum și inputuri (intrări) și outputuri (ieșiri) clar definite.

Notația utilizată pentru descrierea unui proces de afaceri este următoarea:

Notația utilizată sugerează un flux de activități de la stânga la dreapta. În general, un element de tip eveniment va fi plasat în stânga procesului și outputul va fi în partea dreaptă. Elementele ce desemnează activități vor fi incluse în elementul de tip proces.

1.2. Elementele unui proces de afaceri

Un proces are un scop și este influențat de evenimente.

A. Inputuri (intrare), resurse și informații

Procesele de afaceri utilizează informații pentru a adapta sau finaliza diferite activități. Spre deosebire de resurse, informațiile nu sunt “consumate” în cadrul procesului, ci mai degrabă sunt utilizate ca parte a procesului de transformare. Informațiile pot proveni din surse externe, de la clienți, de la unități interne din cadrul organizației sau pot fi chiar rezultatul unor alte procese.

O resursă reprezintă un input al unui proces de afaceri și spre deosebire de informație este consumată în cadrul acestuia. Resursele sunt toate elementele utilizate în afaceri de tipul: elemente de capital, forța de muncă, contracte, etc.

Notația utilizată pentru redarea informațiilor și resurselor este următoarea:

Exemplu de informație: template-urile utilizate pentru comenzi pot fi utilizate în mod repetat pentru că noi comenzi să aibă un format unitar, identic. Template-urile nu sunt “alterate” sau “epuizate” în cadrul acestei activități.

Exemplu de input: pe măsură ce comenzile primite de la clienți sunt procesate, ele sunt “consumate” și nu vor mai fi utilizate din nou.

B. Evenimente

Un eveniment poate fi: primirea unui obiect, atingerea unui deadline, o notificare sau orice altceva ar putea iniția un proces de afaceri. Evenimentul poate fi “consumat” și “transformat” (de ex. o comandă a clientului) sau poate acționa ca un catalizator.

Un eveniment este generat de un proces și primit de unul sau mai multe procese diferite de cel ce l-a generat.

C. Outputul (ieșire)

Un proces de afaceri va produce unul sau mai multe outputuri utilizate fie intern, fie pentru a satisface cerințe externe. Un output poate fi un obiect (de tipul unui raport sau o factură), o transformare a unor resurse primare (o programare zilnică) sau un rezultat de tipul satisfacerii comenzilor clienților.

Un output al unui proces de afaceri poate fi utilizat de un alt proces, fie ca un element ce a fost inițial solicitat de acesta, fie că unul generator de noi activități.

D. Scopul

Orice proces de afaceri are un scop bine definit. Acesta reprezintă motivul pentru care organizația își desfășoară activitatea și trebuie definit în termenii beneficiilor pe care acest proces le aduce organizației per ansamblu și satisfacerii nevoilor de afaceri.

E. Regulile de afaceri

Regulile de afaceri reprezintă premisele ce definesc sau restricționează anumite aspecte ale afacerii și constituie ansamblul cunoștințelor legate de business-ul respectiv.

F. Mecanismele generale

Mecanismele generale pot fi folosite în toate diagramele. De exemplu, o notă poate conține numele unui document extern sau al unei alte diagrame pentru a indica locul în care putem găsi informații suplimentare cu privire la model.

Ca principii avute în vedere la modelarea proceselor de afaceri, trebuie introduse activități paralele și eliminate acțiunile care nu sunt necesare. Nu este permisă depășirea granițelor organizaționale în misiunea lor de a adăuga valoare produsului destinat clientului: acțiunea pe orizontală în cadrul organizației

Exemple tipice de procese de afaceri :

Aprovizionare: asigurând materialele și echipamentul necesar producerii bunurilor și serviciilor.

Dezvoltarea produselor : planificarea noilor produse sau servicii destinate clienților sau perfecționarea produselor existente.

Producție : crearea produselor și serviciilor.

Comenzi-Livrare : primirea comenzilor de la clienți și asigurarea onorarii acestora

Distribuție : asigurând distribuția în condiții sigure a bunurilor către clienți.

Suport pentru clienți : oferind asistenta clienților după ce aceștia au cumpărat produsele și serviciile.

Clasificarea proceselor de afaceri:

Procese operative

Procese de suport

Procese de management (ex: management strategic,)

Aceste trei tipuri de procese interacționează pentru atingerea obiectivele.

Clasificarea proceselor de afaceri-exemplu:

Deservirea comenzii unei cărți de pe Amazon.com:

Procesul de management:

decide personalul necesar și stabilește mijloacele prin care se îndeplinesc sarcinile în organizației.

Stabilește obiective de marketing

Stabilește procedurile de facilitare a operațiunilor – ex: procedurile de livrare a cărții către client.

Procesul operativ:

primește comanda cărții pe Internet, pregătește o factură și o trimite la bancă.

Primește o confirmare a platii de la bancă

Confirma comanda clientului printr-un e-mail către acesta.

Trimite depozitului o cerere de livrare a cărții către client.

Procesul de operațiuni:

atașează pachetului de livrat un document identificând clientul și conținutul pachetului.

Raportează sistemului informatic ca pachetul a fost livrat.

Procesul operativ:

îi trimite clientului o confirmare a livrării produsului

Comunica managementului un raport comparând cifra ținta de vânzări cu vânzările actuale.

Tipuri de procese de afaceri:

Procese orientate client:

Facturarea

Procesarea unei comenzi

Mentenanța asigurată clienților

Distribuție

Manufacturare

Procese specifice industriei:

Procesul de împrumut – specific industriei bancare

Procesul de prepararea a mâncării – restaurant

Manipularea rezervărilor – hoteluri

Manipulare bagaje – firme de transport aerian

Returnare marfa – lanțuri de magazine

Procese administrative:

Planificare strategică

Bugetarea

Instruire

Managementul tehnologiei informației

Managementul facilitaților

Direcții de îmbunătățire

Indiferent de tipul de proces, este foarte important ca acesta să fie revizuit periodic, îmbunătățit sau înlocuit de alt proces mai bun, urmând cel puțin una din cele patru direcții:

Eficacitate – măsura în care obiectivele așteptate de la proces sunt obținute; este primă măsură a capabilității procesului de a îndeplini așteptările logice și raționale.

Eficienta – Exemplu: livrarea unui produs după primirea unei comenzi durează mult peste așteptări, generând numeroase plângeri; livrarea este eficace, dar nu și eficientă, deci trebuie îmbunătățită.

Control intern – Exemplu: permiterea trimiterea unei comenzi de materie primă către un anumit furnizor cu care s-a stabilit un preț constant pe parcursul anului, dar care între timp și-a modificat prețul; implementarea procesului de afaceri nu trebuie să permită o astfel de acțiune;

Respectarea procedurilor – Exemplu: înșteptările logice și raționale.

Eficienta – Exemplu: livrarea unui produs după primirea unei comenzi durează mult peste așteptări, generând numeroase plângeri; livrarea este eficace, dar nu și eficientă, deci trebuie îmbunătățită.

Control intern – Exemplu: permiterea trimiterea unei comenzi de materie primă către un anumit furnizor cu care s-a stabilit un preț constant pe parcursul anului, dar care între timp și-a modificat prețul; implementarea procesului de afaceri nu trebuie să permită o astfel de acțiune;

Respectarea procedurilor – Exemplu: înainte de plată serviciilor unor contractori trebuie deduse anumite taxe și impozite datorate statului; dacă aceste deduceri nu au fost implementate în procesul de afaceri, o să apară probleme de natura legală.

1.3 Modelarea proceselor de afaceri

Am observat o distincție clară între prototipurile limbajelor de modelare, limbajele de

modelare industriale și produsele comerciale. Prototipurile limbajelor de modelare consacrate se referă la FlowMake , ADEPTflex și YAWL.

Limbajele de modelare industriale cele mai cunoscute sunt:

Business Process Execution Languages for Web Services- Limbajul de execuție al

proceselor de afaceri pentru servicii web – BPEL4WS;

Business Process Modeling Notation- Notațiile Modelării Proceselor de afaceri –

BPMN.

Limbajele de modelare comerciale consacrate deja sunt:

Tibco Staffware Process Suite;

Oracle BPEL Process Manager;

ILOG BPM.

1.3.1 Descrierea și modelarea proceselor de afaceri

Procesul de afaceri, din punct de vedere al teoriei sistemelor, reprezintă un set de

activități care transformă intrări (inputs) particulare în ieșiri particulare (outputs), iar acest aspect va duce la concluzia firească a faptului că un proces – la un nivel de abstractizare – poate reprezenta o activitate, la un nivel superior. În funcție de diversele comunități de afaceri, distingem utilizări diferite ale noțiunilor de: proces, afaceri, activități, sarcini.

În figură 1 observăm exemple de notații utilizate pentru descrierea proceselor de afaceri, care pot include sau nu modele grafice ale proceselor de afaceri.

În partea a din figură apar notațiile susținute și utilizate de două surse: în 2003 cartea lui

P. Harmon, cât și de portalul www.bptrends.com. În partea b1 și b2 din figură sunt notațiile care se regăsesc în cartea lui H.J.Harrington (1997), iar în partea c a figurii notațiile sunt regăsite în cartea autorilor A.Bruce și D.Kutnick (2002), respectiv în portalul metagrup; ultima parte (d) conține descrierea aplicațiilor practice ale cerințelor de inginerie a modelării proceselor de afaceri, explicate pe larg în 2003 de S.Lausen.

Managementul workflow-urilor este responsabil pentru asigurarea eficienței în cazul transmiterii informației, documentelor și sarcinilor de la un angajat (sau mașină) la altul. Un sistem de management al workflow-urilor (WfMS) este un sistem care definește,

administrează și execută workflow-urile cu ajutorul aplicațiilor informatice. Ordinea în care se execută operațiile este dictată de către o reprezentare computerizată a logicii fluxului de lucru (Hollingswoth, 2005). Se poate afirma că WfMS sunt punți între muncă oamenilor și aplicațiile software (van der Aalst, 2005), care permit optimizarea fluxurilor de lucru dintr-o organizație.

Figura 1. Nivele de abstractizare ale proceselor de afaceri

1.3.2 Metodologiile de modelare ale afacerii

Comparativ, metodele de modelare IDEF0, IDEF1, IDEFIX, IDEF3, RÂD, REAL,

Modelarea dinamică, Modelarea Orientată Obiect, AI, MAIS, sunt prezentate în funcție de

următoarele aspecte: componente, reprezentare, caracteristici principale, procedura de

modelare.

.

Tabel 1. Reprezentarea punctelor țări ale componentelor BPM

( adaptare după Fu RenLing et all, 2002)

În tabelul 1: reprezentarea punctelor țări ale componentelor modelelor proceselor de

afaceri este realizată în funcție de șase perspective: funcțională (P1), comportamentală (P2), informațională (P3), organizațională (P4), verificare/validare (P5), procedura de modelare (P6). Componentele (punctele tari) după care se face comparația sunt: Activitate, Resurse, Comportament, Eveniment, Informație, Relație, Agent, Entitate, Verificare/ Validare/ Simulare, Procedura de modelare, notate C1 la C10.

Modele colaborative de afaceri – Procesul de afaceri și cerințele sale

Pentru a clădi adecvat sau a configura o soluție software bazată pe nevoile de business, este necesară definirea cerințelor. Această definire reprezintă de fapt o descriere clară și completă a nevoilor de afaceri, adesea numită de utilizator și care va conține informații despre: cerințele funcționale și non-funcționale, cerințe de ecran și cerințele de integrare (Silver, 2008, Zachmann, 2009). Cerințele funcționale constau în ceea ce sistemul trebuie să facă și ce funcționalitate este nevoie să ofere. Cerințele non-funcționale sunt axate pe cerințele de calitate față de soluția de performanță, timpii de răspuns, securitate, scalabilitate, mentenabilitate, etc. Cerințele de ecran punctează interacțiunea om-calculator, cum este comunicarea între utilizator și sistemul care trebuie să se construiască.

Cerințele de integrare prezintă modul în care multe alte sisteme sunt implicate în sistemul de integrare și modul în care soluția trebuie să integreze și să comunice cu alte sisteme.

Aceste cerințe sunt folosite pentru a aranja în părți de gestionat și de logică, grupate pe

bază mai multor tehnici: cazuri de utilizare, descrierea utilizatorilor, funcție de metoda utilizată pentru identificare.

Procesele de afaceri versus cazuri de utilizare

Cazul de utilizare este adnotat cu: actori, căi implicite /de excepție, regulile de business,

informații de intrare și de ieșire și de constrângerile de calitate. Actorii sunt părțile implicate în cazul de utilizare, calea implicită reprezintă o combinație de pași care vor duce la atingerea obiectivului, calea de excepție arată pașii care trebuie urmați atunci când o eroare / problemă apare în calea implicită. Regulile afacerii sunt reguli sau condiții specifice de aplicare (calcule, reguli de validare, reguli de corelație), informațiile de intrare și de ieșire trebuie să fie prezente înainte de a fi executată calea implicită, iar informațiile de ieșire sunt livrate de către căile implicite sau căile de excepție. Constrângerile de calitate reprezintă mai multe criterii de calitate referitoare la măsurile specifice (întârziere, timpul de răspuns, rotunjire).

Se pot observa în tabelul 2 mai multe caracteristici importante și o comparație între procesul de afaceri și Use Case. Informațiile de la modelul de proces de afaceri pot fi preluate în cerințele din definiția detaliată. Se asigură astfel trasabilitatea în procesul de gestionare a cerințelor (Robertson, 2006).

Deci, următorul pas spre automatizare este faptul că se lucrează cu cerințele detaliate pentru etapele din procesul de automatizare, dacă acest lucru este dorit.

Tabelul 2. Business Process și caracteristicile cazurilor de uilizare

(sursa:Robertson, 2006)

CAPITOLUL 2 MODELAREA PROCESELOR DE AFACERI FOLOSIND BPMN

Business Process Modeling Notation sau pe scurt BPMN este unul dintre cele mai cunoscute standarde de modelare și management al proceselor de business, fiind extrem de util în etapele de definire și aliniere a produselor software. Obiectivul BPMN este acela de a furniza un set unificat de elemente și de notații care să fie ușor de înțeles și de folosit de către toți participanții la procesul de livrare.

BPMN a apărut ca o notație standard, pentru a capta procesele de afaceri, în special la nivelul analizei domeniului și a designului sistemelor de nivel înalt . Notația moștenește și combină elemente ale unui număr de notații propuse anterior pentru procesele de modelare de afaceri, incluzând limbajul de definire a proceselor pentru XML (XPDL) și diagrame de componente din activități UML. Ca și în cazul predecesorii săi, ideea de bază a BPMN este că modelele de proces sunt formate din: – noduri de activitate, denotă evenimente de afaceri sau de elemente de lucru executate de persoane sau de software – noduri de control, capturând controlul fluxului de activități. Cele două noduri pot fi conectate printr-o relație cursivă prin metode aproape arbitrare.

Limbile care urmează aceeași paradigm, numite și limbaje de definire a proceselor orientate pe grafuri, au fost studiate din punct de vedere formal. Este cunoscut faptul că modelele definite în această familie de limbaje pot expune unele erori semantice (s impas, livelock s). Chiar mai mult, BPMN aduce alte caracteristici netradiționale asociate cu limbajele orientate pe grafuri aduse din surse, incluzând modele Workflow și BPEL, un standard în definirea proceselor de afaceri la nivelul de punere în aplicare. Aceste caracteristici includ capacitatea de a defini: – subprocese ce pot fi executate de mai multe ori, concurent – subprocese ce pot fi întrerupte în urma unor – mesaje între procese.

Interacțiunea dintre aceste caracteristici și cele tradiționale, găsite în limbajele orientate pe grafuri, crește tipul erorilor semantice ce pot fi găsite în modelele BPMN. Așadar, abilitatea de a analiza statistic modele BPMN va deveni, probabil, o caracteristică deșirabila pentru suportul uneltelor de modelare a proceselor în BPMN. Probe anecdotice sugerează că utilizatorii de BPMN produc modele cu erori semantice ce ar putea fi detectate folosind tehnologii deja existente de verificare.

Analiza semantică a modelelor BPMN este împiedicată de eterogenitatea construcțiilor sale și lipsa unei definiții neambigue a notației. În timp ce regulile sintactice sunt documentate pe înțeles în tabele în toate specificațiile standard BPMN, semantica este descrisă numai în formularul narativ, fiind folosite, uneori, terminologii inconsistențe. Acest articol preia provocarea definirii unei semantici formale pentru o submulțime mai largă de BPMN. Semantica este definită ca o legătură între modele BPMN și rețele Petri. Alegerea de a folosi rețele Petri simple ca țintă a legăturii este motivată de disponibilitatea de tehnici de analiză statică eficiente. De asemenea, maparea propusă nu doar servește scopului de a dezambiguiza construcția principală a BPMN, dar oferă o fundație de verificare a corectitudinii semantice a modelelor BPMN. Pentru a susține această afirmație, am implementat o unealtă care traduce din serializarea XML a modelelor BPMN și PNML.

2.1 Notația BPMN

BPMN cuprinde o singură diagrama a procesului de afaceri, numită Business Process Diagram (BPD). Aceasta diagramă a fost creată să delimiteze bine două lucruri. În primul rând este ușor de utilizat și înțeles. Poate fi folosită pentru a modela rapid și ușor procesele în afaceri, și este ușor de înțeles de către utilizatorii mai puțin tehnici (de obicei managerii).

În al doilea rând oferă expresivitatea de a modela procese de afaceri foarte complexe și poate fi ușor legată de limbajele de execuție în afaceri.

Pentru a modela un flux de procese în afaceri, trebuie să modelăm evenimentele care apar pentru a crea un process, procesul care se formează, și rezultatul final al fluxului de procese. Deciziile în afaceri și ramificarea fluxurilor sunt modelate utilizând gateway-uri. Un gateway este similar unui simbol decizional într-o diagramă.

Mai mult, un process din flux poate conține subprocese, care pot fi reprezentate grafic printr-o alta diagrama de procese conectată print-un hyperlink cu un simbol de proces. Dacă un proces nu este împărțit în subprocese atunci acesta este considerat un task – proces de nivel cel mai scăzut. Simbolul “+” într-o diagramă semnifică faptul că un proces este împărțit în subprocese. Dacă simbolul “+” nu este prezent, atunci procesul este numit “task”.

Fig. 1. Diagrama de procese de afaceri simplă pentru un sistem de licitare on-line(sursă: http://www.omg.org/)

Cu cât se înaintează în procesul de analiză în afaceri, se poate spune 'cine ce face', prin plasarea de evenimente și procese în zonele delimitate, denumite noduri (pools), care arată cine efectuează procesul. Mai mult decât atât, un nod poate fi împărțită în subnoduri (lanes). Un nod este de obicei o organizație și un subnod este un departament în cadrul organizației (deși poate fi folosit pentru a reprezenta alte lucruri, cum ar fi caracteristici, aplicații sau sisteme).

Fig.2 BPMN Diagrama proceselor de afaceri cu procese reprezentate sub formă de noduri (sursa: http://www.omg.org/)

2.1.1 Modelarea evenimentelor în afaceri

În timpul modelării proceselor de afaceri, sunt modelate evenimentele care se petrec în afaceri, și modul în care acestea influențează fluxul de procese. Un eveniment fie pornește un flux de procese,fie are loc în timpul unui un flux de procese sau încheie un flux de procese. BPMN oferă un punctaj separat pentru fiecare eveniment, așa cum se arată în tabelul de mai jos.

Tabelul 1: Tipuri de evenimente de bază în BPMN și notațiile lor (sursa: http://www.omg.org/)

Evenimente complexe – Precizați tipurilor trigger (declanșatoare)

Când sunt modelate fluxuri de process mai complexe, cum ar fi servicii web B2B, trebuie modelate evenimente de afaceri complexe, cum ar fi mesaje, cronometre (timers), reguli de afaceri și de tratare a erorilor. BPMN permite pentru specificarea tipului de cronometru atașat evenimentului și a reprezentării sale cu o iconiță reprezentativă, după cum este specificat în tabelul 2. Atașarea unui tip de cronometru la un eveniment creează anumite constrângeri asupra fluxului de procese care sunt modelate, procese ce sunt explicate în tabel. De exemplu, un temporizator nu poate încheia un flux de proces. Se pot primi sau trimite fluxuri de mesaje de la sau către evenimentele de tip mesaj. Aceste tipuri de reguli de modelare, care sunt de fapt diferite regulile în afaceri, ar trebui să fie executate în mod automat de către unealta de modelare furnizând suport pentru BPMN.

Tabelul 2: Tipuri de evenimente declanșatoare (sursa: http://www.omg.org/)

De multe ori un eveniment are loc în timp ce un proces se execută, realizând astfel o întrerupere a procesului și declanșarea unui nou proces care să ruleze. Sau, procesul va fi complet, provocând un eveniment de pornire și rulează un nou proces. Aceste evenimente intermediare pot fi modelate prin plasarea unui simbol direct asupra evenimentului căruia îi este asociat. În figura 3, se poate vedea un cum un mesaj de eveniment este declanșat atunci când procesul “Send Password”. se încheie, cauzând un mesaj “Password Request” să fie trimis către procesul 'Trimite parola'. Acest tip de notație BPMN clarifică pentru cititor faptul că procesul “Check Inbox” generează un eveniment de tip mesaj care trimite un mesaj către alt proces.

Fig.3 Un eveniment de tip mesaj este declanșat la sfârșitul procesului “Check Inbox”, trimițând mesajul “Password Request” către procesul “Send Password”

(sursa: http://www.omg.org/)

2.1.2 Procese, subprocese și sarcini de afaceri

La baza proceselor de modelarea al afacerilor se află însăși procesele. Există trei tipuri de procese: procese, sub-procese si sarcini. Fiecare simbol este reprezentat grafic de același simbol dreptunghiular; utilizarea diferitelor denumiri reflectând doar relațiile ierarhice dintre ele.

Descompunerea procesului în ierarhii

Un proces este o rețea de 'lucruri care lucrează'. Se desenează un dreptunghi pe nivelul superior al diagramei de procese de afaceri BPMN . Pot fi specificate propriile detalii cu privire la un proces prin crearea sau atașarea unui alt proces de afaceri cu cel inițial. Subdiagrama este considerată o diagramă 'copil'. Un proces care are diagramă 'copil' primește un semn '+' în corpul său.

Reprezentarea grafică a detaliilor unui proces printr- o altă diagramă de proces de afaceri se consideră "descompunerea" procesului. Se poate continua procesul de descompunere fără restricții – crearea unei diagrame 'copil' pentru un proces și diagrame 'copil' pentru procesele primei diagrame 'copil', etc

Procesele desenate pe diagrame 'copil' sunt considerate subprocese. Procesele de pe nivelul inferior, care nu se descompun mai departe sunt considerate sarcini.

Fig 4. Parte a unei diagrame de Proces de Afaceri BPMN pentru un sistem de licitație online (sursa: http://www.omg.org/)

Figura 4 arata o diagramă a unui proces de afaceri BPMN în care procesul Register Item For Auction a fost modelat. Semnul "+" în corpul procesului arată că există cel puțin o diagramă de proces de afaceri “copil” legată la acest proces, și că pe acea diagramă se găsește o reprezentare grafică a detaliilor acestui proces.

Fig 5. Subprocese și sarcini (sursa: http://www.omg.org/)

Figura 5 prezintă o diagramă a proceselor de afaceri 'copil' BPMN la procesul Register Item For Auction.

Pentru că se află pe o diagramă “copil”, procesele sunt considerate subprocese. Procesele de pe această diagramă care nu sunt descompuse mai departe (nu au semnul '+' în centrul lor) sunt considerate sarcini.

După cum se poate vedea, este ușor de identificat o sarcină într-o diagramă – sunt acele dreptunghiuri rotunjite care nu au un semn '+' în centru.

Vizualizarea cu ușurință a complexității procesului

Din nou, diagrama BPMN este reprezentată pentru a fi ușor de înțeles de către privitori. Pentru a ajuta la înțelegerea complexităților proceselor, se poate afișa în mod grafic o pictogramă a unui flux de procese pe însuși simbolul de proces. În editorul de modelare, acest lucru se face prin apăsarea simbolul '+' în centrul simbolului de procesi, care va schimba semnul '-', și prezentarea schiței pictogramei . În acest fel, pentru a vizualiza o diagramă a unui proces BPMN, se pot vedea cu ușurință procesele complexe, care descompun pe nivele.

Fig 6. Vizualizarea schiței pictogramei diagramei fiice a unui process

(sursa: http://www.omg.org/)

Modelarea tranziției către un proces

Pentru a arăta ordinea de execuție a proceselor, acestea trebuie să fie conectate printr-o săgeată. Tranziția este reprezentată grafic cu o săgeata cu vârful plin (vezi figurile 4 și 5).

Tranziția este folosită pentru a arăta secvențele proceselor în cadrul unei organizații sau a unui departament. Deci, în cazul în care s-au adăugat noduri și subnoduri în diagrama, se vor folosi săgețile pentru a conecta evenimentele, procesele și gateway-urile plasate între noduri și subnoduri.

BMPN trasează o a doua linie de flux – Săgeata de Mesaj – disponibilă pentru a modela comenzile de procese dintre organizații și departamente (cu alte cuvinte, între noduri).

2.1.3 Simularea proceselor de afaceri

Un model creat cu ajutorul BPMN este o descriere logică a modului în care funcționează afacerea, din care pot fi create limbaje de process pentru afacerea în cauză. Cu toate acestea, pentru cele mai bune rezultate, această abordare ar trebui să fie utilizate în conformitate cu simularea proceselor de afaceri.

Simularea este o tehnică puternică, disponibilă analiștilor în afaceri pentru a-și putea analiza modelele înainte de a fi puse în practică. Un model, când este simulat, mimează operațiile afacerii, parcurgând pas cu pas evenimentele compresate în timp, și arătând o imagine animată a fluxului.

Deoarece programele de simulare țin evidența statisticilor despre elementele modelului, performanța poate fi evaluată prin analiza rezultatului modelului. Acest lucru permite evitarea de greseli costisitoare prin revizuirea eficienței unui model de afaceri înainte de implementarea efectivă.

Fig.14 Simularea și execuția unei diagrame de proces de afaceri BPMN

(sursa: http://www.omg.org/)

2.2 Legătura dintre BPMN și UML

Apariția de BPMN, BPML și BPMS nu face învechită nevoia de dezvoltare a unor noi sisteme, spre deosebire de utilizarea UML (Unified Modeling Language). Dezvoltarea de noi sisteme are un rol important de jucat în arhitectura de întreprindere.

UML este un limbaj care ajută dezvoltatorii pentru a specifica, vizualiza și documenta modele de sisteme software. Acesta se adresează în principal arhitecților de sistem și inginerilor software. Acesta a fost dezvoltat ca un mijloc de a simplifica dezvoltarea de software, de la design-ul arhitectural la implementarea aplicației pentru a fi utilizată de către un comitet tehnic.

BPMN se adresează analiștilor de afaceri, arhitecți de sistem și ingineri de software. Acesta a fost dezvoltat ca o modalitate de a simplifica întregul ciclu de viață al dezvoltării unui proces de afaceri creat de către un comitet de oameni de afaceri.

UML nu este familiar pentru majoritatea analiștilor de afaceri

UML definește un număr de diagrame care pot fi clasificate într-una din cele trei categorii:

Structura statică a aplicației;

Comportamentul dinamic;

Gestionarea și organizarea de soluții software.

Dintre aceste categorii diagrama de comportament dinamic este cea mai folosită pentru a modela procesele de afaceri pentru a realiza diagrame, cum ar fi diagrama de activitate UML si diagrama cazurilor de utilizare. BPMN este legat de UML în sensul că definește o notație grafică pentru procesele de afaceri, care este similară cu diagramele de omportament UML . Cu toate acestea, BPMN și UML au abordări foarte diferite cu privire la modelarea procesului de afaceri.

UML oferă o abordare orientată pe obiecte pentru modelare aplicatiilor , în timp ce BPMN folosește o abordare a proceselor centrice. Cele mai multe metode UML necesită ca primul să fie găsit obiectul folosind o structură static și apoi cer să fie construită o diagramă de comportament dinamicî pentru a evidenția modul de acționare al obiectelor. Ca și fel de modelare această metodă nu le este familiară pentru mulțor analiști de afaceri.

BPMN oferă o abordare de procese centrică care este mult mai naturală și intuitivă pentru analiști în afaceri. Cu BPMN, fluxurile de control și fluxurile de mesaje ale proceselor sunt modelate în primul rând. Un model pentru process este definit mai degrabă implicit decât explicit. BPMN oferă deasemenea, opțiunea de modelare explicită a obiectelor care pot fi expuse prin intermediul serviciilor în fluxurile de procese.

UML nu are o implementare vizuala a modelelor de afaceri

UML este o asamblare de diagrame care sunt rezultatul celor mai bune practici collective ale diferiților fondatori practicieni. Din păcate, acest lucru înseamnă că diagramele sunt o agregare și nu au fost concepute în mod specific pentru a lucra una cu alta. Ca rezultat, dezvoltatorii pot modela doar o parte a aplicațiilor folosind UML; nivelul detaliat de implementare nu este acoperit.

În schimb, BPMN definește un tip de diagramă care are mai multe înfățișări derivate din același proces de bază al meta-modelului. Rezultatul natural al acestui lucru este faptul că punerea în aplicare într-un limbaj de execuție de procese în afaceri pur și simplu devine un alt punct de vedere logic al procesului.

UML nu are nici un fundament matematic pentru a fi mapat la BPEL

În cele din urmă, UML nu definește nici un meta-model de execuție pentru procesele de afaceri modelate. Cu toate acestea, orice meta-model de executie trebuie definit cu ajutorul Model Drive Architecture (MDA). BPMN se bazează pe executarea proceselor de către meta-modelul BPML și drept urmare, nu sunt necesare măsuri suplimentare pentru modelarea procesului complet executabil.

2.2.1. Despre BPMN și UML

Se anticipează că BPMN și UML vor co-exista. Vor fi utilizatori tehnici care nu vor dori să folosească BPML că metoda principală de lucru și care vor utiliza în continuare UML. Figura 15 arată că BPMN poate fi folosit pentru a crea soluții care să ruleze direct pe BPMS sau care să fie folosite drept analist de afaceri pentru dezvoltări ulterioare folosind UML. În acest scenariu utilizatorii UML ar considera procesele de afaceri pur și simplu o altă componentă.

Fig.15 BPMN și UML sunt folosite pentru a crea procese de afaceri și aplicații care să ruleze pe un Business Process Management Server (BPMS) (sursă: http://www.omg.org/)

Business Process Modeling Notation (BPMN) este un standard care a fost dezvoltat de către o organizație non-profit Business Process Management Inițiative (BPMI.org), care a fost înființată în august 2000, în scopul de a promova dezvoltarea și utilizarea de Business Process Management (BPM), prin stabilirea de standarde deschise pentru proiectarea, implementarea, execuția, întreținerea și optimizarea. A început prin specificații deschise pentru Business Process Modeling Language (BPML) și Procesul de afaceri Query Language (BPQL).

În timpul dezvoltării de BPML, membrii BPMI.org au discutat despre ideea de a crea o notație completă pentru BPML, deoarce nu există nici o notație standard acceptată pentru procesele de afaceri. Au fost, și încă sunt, multe note de proprietate, pentru de modelarea proceselor de afaceri. Scopul Grupului de lucru în dezvoltarea de notație BPMN a fost de a lua cele mai bune idei de la aceste notații diferite pentru a oferi o notație standard, care ar putea fi înțelesă și utilizată de către toți cei implicați în activitatea de modelare, nu numai de dezvoltatorii tehnici, dar, de asemenea și de analiști de afaceri .

Scopul a fost o notație care unește cele două lumi a designului de procese de afaceri și implementarea proceselor de afaceri.

În august 2001, un grup de lucru cu prezidenția Stephen White, IBM, a fost delegat pentru a creea notația cu implicarea altor companii, cum ar fi Intalio, CSC, MEGA Internațional, Casewise, Popkin Software și webMethods. În noiembrie 2002, BPMN 0.9 a fost lansat pentru public în mai 2004, caietului de sarcini a versiunii 1.0 a BPMN a fost publicat oficial [BPMN].

Această versiune a inclus o cartografiere de la BPMN la BPEL4WS, o indicație a faptului că și atunci BPMI.org a recunoscut importanța de BPEL4WS, comparativ cu propriile sale BPML .

O versiune de BPMN 1.x a fost dezvoltată ca o eliberare de discrepanțe constatate mai târziu. De asemenea, s-a lucrat pentru a standardiza seturi de artefacte pentru a sprijini modelarea generală de afaceri și zonele de afaceri verticale (de exemplu, asigurare, de fabricație, finanțe) [White04b].

În iunie 2005 BPMI.org și OMG au unit activitățile lor legate de BPM, plasarea responsabilității pentru caietul de sarcini BPMN (și în prezent) în OMG, la unitatea Business Modeling and Integration Domain Task Force.

Din septembrie 2005, grupul de lucru a fost format din 58 de membrii care reprezintă 35 de companii [White05b]. Caietul de sarcini BPMN 1.0 a fost publicat ca document de OMG. Versiunea finală adoptată de caietul de sarcini OMG BPMN a fost lansat în februarie 2006, ca document de OMG [BPMN06].

În ceea ce privește relația cu alte organizații de standardizare în cauză, BPMI.org a dezvoltat BPMN, în scopul de a fi parte dintr-o stivă inițial cu BPML propriu, mai apoi BPEL4WS, dar și alte mapări au fost luate în vedere. Acum, că OMG a luat BPMN în proprietate, nu este destinat în mod clar pentru a stabili relații mai strânse între BPMN și alte OMG-uri de lucru [White05b].

De exemplu, este de așteptat ca BPDM ar putea servi ca un metamodel pentru BPMN de a folosi și de a genera o schemă BPMN pentru schimbul de informații semantice BPMN. Ele sunt, de asemenea, de așteptat să fuzioneze BPMN și UML pentru a aduce împreună cele două lumi de modelare și a proceselor de afaceri și de analiză și proiectare de software. Nucleul versiunii curente a BPMN este compatibil cu UML 2.0 Diagrama de activitate și BPMN este capabilă de a construi un profil de activitate UML 2.0 Activitate este luată în considerare.

Versiunea 1.x ale BPMN din caietul de sarcini stabilesc specificațiile pentru erori și neconcordanțe, ș adăuga / modifica [modelarea procesele de colaborare pe baza feedback-ului primit de la Comitetul tehnic OASIS pentru procese de afaceri ebXML, și este posibil să existe o mapare pentru alte versiuni de BPEL, cum ar fi WS-BPEL 2.0.

De asemenea, este posibil să se construiască un metamodel (BPDM și / sau XPDL) pentru BPMN pentru a genera un program de păstrat și transportat în diagram de informație semantică și pentru a utiliza XMI pentru a face schimb de informații de cadru a diagramelor BPMN Nu există muncă avute în vedere, pe cât de explorare executiv și alte niveluri de afaceri de modelare a extinde sau stratificat sunt în partea de sus a BPMN [White05b].

Un proces de afaceri nu este neapărat pus în aplicare ca un proces de afaceri automat într-o limbă de execuție. În acest caz, procesele de afaceri și participanții pot fi mapate la construcție, cum ar fi utilizarea de modele comportamentale și cazuri în UML.

BPMN a fost proiectat pentru procesele de modelare de afaceri, în general, și se adresează unei game largi de utilizatori care au nevoie pentru a comunica cu alte procese de afaceri și prin urmare, necesită o notație standard.

Notația grafică este proiectată pentru a fi intuitiva pentru utilizatorii de afaceri care ar trebui să poată citi cu ușurință și să înțeleagă o diagramă BPMN, care are, de asemenea, posibilitatea de a reprezenta semantica pentru proces complex pentru implementorii procesului, care pot folosi caracteristicile extinse ale notației pentru a reprezenta un proces de aplicare. Acesta este prima notație în procesele de afaceri care oferă o viziune comună a proceselor de afaceriprecum implementatorilor de proces.

BPMN este conceput pentru a fi ușor mapat la orice limbaj de execuție a proceselor de afaceri, dar, de asemenea, pentru a fi utilizate în modelarea proceselor de afaceri, fără a le executa în mod necesar. Tehnicile se bazează pe fluxuri de procese de business utilizate de către analiștii și oferă o varietate de instrumente de proprietate, astfel că analiștii de modelare de afaceri, care sunt obișnuiți pentru a folosi una din aceste limbi nu vor avea prea multe probleme în conversie. Scopul a fost de a crea un mecanism simplu pentru a crea modele de procese de afaceri, și, în același timp, să fie în măsură să se ocupe de complexitatea inerentă a proceselor de afaceri [White 04b].

Criterii de piață

BPMN a fost acceptat în industrie ca notație pentru de utilizare și procesare a modelelor în instrumente produse de vendori. Alternative la BPMN sunt sisteme proprier sau text simplu. Aproximativ 65% din procesul de modelare întreprinse în cele mai multe companii se bazează pe text, și de mulți manageri care folosesc procesul de diagrame grafice de utilizare, utilizează fie PowerPoint fie Visio [Harmon05]. Astfel, este clar că BPMN trebuie să fie evaluat împotriva unui astfel de fond. În Europa, se pare că BPMN este cu siguranță la toată lumea pe lista de cerințe. Cu toate acestea, nu a fost îmbrățișat de către un număr mare de organizații încă. Este într-o situație similară cu BPEL pentru care numărul de adoptări este încă în fază incipientă. Se așteaptă să mai dureze ceva timp înainte de BPMN devine un standard real [Casewise05]. În prezent, BPMN este o notație standard grafică pentru modelarea proceselelor de afaceri. Nu este probabil să fie înlocuit de către orice alt standard, dar probabil va evolua pentru a fi compatibil cu alte standarde ale OMG.

BPMN este un standard deschis și specificația este disponibilă pentru descărcare de pe site-ul OMG. În conformitate cu acest site, există peste treizeci de implementări de BPMN. Cele mai multe instrumente sunt produse comerciale, dar sunt disponibile și o serie de instrumente open source. De exemplu, M1 Global convergență Studio, listate pe site-ul OMG, este un plug-in Eclipse bazat pe standardul BPMN. BPMN Package of Plugins (proiect Sorceforge) oferă un șablon Visio pentru BPDS folosind BPMN.

Criterii tehnice

BPMN a fost conceput pentru o descriere stndard bazată pe π-calcul pentru procesele de afaceri. Notația utilizată pentru BPMN este o notație grafică pentru exprimarea proceselor de afaceri într-o Diagramă a Proceselor de Afaceri (BPD), care se bazează pe diagrame tradiționale, cunoscute de cei mai mulți analiști de afaceri.

Texte adnotări pot fi adăugate la oricare elemente ale modelului pentru a oferi informații și detalii suplimentare. BPMN este independent de orice metodologie de modelare proces de afaceri specifice.

2.2.2.Tipuri de procese care pot fi modelate

Trei tipuri de bază de model pot fi create cu un BPD [BPMN].

Colaborare (global) – procesele B2B arată interacțiunea dintre două sau mai multe entități de afaceri. Interacțiunile dintre participanți sunt definite ca o succesiune de activități, reprezentând șabloanele schimburilor de mesaje dintre ele. Aceste procese sunt aproape de limbajele de colaborare, cum ar fi ebXML BPSS, RosettaNet Limbajul de Coregrafie al W3C (care nu au fost disponibile de la lansarea versiunii 1.0).

Privat (intern) – procesele de afaceri se concentrează pe activitățile unei singure organizații de afaceri, care, deși arată interacțiuni cu interne participanți, care nu sunt vizibile pentru public și sunt astfel activități private. Un proces de afaceri privat, poate fi mapat la unul sau mai multe documente BPEL4WS.

Abstract (publice) – procese care arată activitățile pe care un proces de afaceri privat le folosește pentru a comunica cu un alt participant sau proces, dar nu și activitățile interne ale procesului de afaceri privat. Un astfel de proces poate fi mapat la un singur proces abstract BPEL4WS (imposibil în versiunea 1.0 a BPMN).

Principalelor concepte folosite

BPMN este conceput pentru a sprijini atât analiști de afaceri și implementorii de procese, elementele diagramei de elemente în BPMN au fost organizate în două categorii. Setul de bază de elemente permite să fie produse BPDs care sunt familiare analiștilor de afaceri deoarece acestea se bazează pe diagrame de fluxuri.

Această gamă include următoarele elemente:

Debit de obiecte:

Evenimentele sunt folosite pentru a reprezenta faptul că se întâmplă ceva și, de obicei, au o cauză și un rezultat și pot începe, întrerupe sau termina un proces de flux;

Activitățile reprezintă un lucru care se desfășoară în cadrul unui proces de afaceri, ele pot fi descompuse în sub-activități și sarcini. Ciclarea activtătilor este permisă. Conceptul de "stare" este folosit astfel încât starea unei activități nu poate fi modelată;

Gateway modelează deciziile de afaceri și permite ramificare, bifurcare, fuzionare și aderare a drumurilor. Mai multe tipuri de Gateway sunt acceptate, și se face o distincție între gateway-XOR pe bază de date și pe bază de eveniment.

Obiecte de conectare

Ordinea curgerii prezintă ordinea de activități într-un proces;

Curgerea de mesaje prezintă fluxul de mesaje între entități. Un mesaj nu este considerat un eveniment în sine; un eveniment este de a primi sau a trimite un mesaj adecvat;

Asocierea asociază informații / date, text și altele cu obiectele flux.

Swimlanes:

Bazin reprezintă un participant la proces, astfel încât un set de activități pot fi partiționate în diferite bazine. Bazinele pot reprezenta organizații, în special a entități diferite de afaceri în contexte B2B;

Banda este o sub-partiție a unui Bazin utilizate pentru a organiza și categorisi activități separate într-un Bazin, de obicei, prin rol sau funcție. Banda poate reprezenta departamente din cadrul unei organizații, precum și anumite funcții sau sisteme.

Artefact:

Obiecte de date furnizează informații despre modul în care documente, date și alte obiecte sunt utilizate și actualizate într-un proces. Acestea sunt conectate la activități prin intermediul asociațiilor;

Adnotările text sunt un mecanism care permit unui modelator să furnizeze informații suplimentare pentru un cititor de diagramă BPMN;

Grupurile oferă un mecanism de a organiza activități și pot fi utilizate în scopuri de documentare sau de analiză, dar nu afectează fluxul.

Figura de mai jos oferă un exemplu de specificație BPMN pentru un proces de colaborare de afaceri folosind elemente grafice de bază. BPDul este ușor de citit și sunt potrivite pentru modelatorii care creează modele de procese de afaceri în scopuri de documentare și comunicare.

Figura 7 Diagrama unui proces de colaborare de afaceri prin specificația BPMN

(sursa: http://www.omg.org/)

Pentru cei care au nevoie pentru a produce procesul de modele la un nivel mai mare de detaliu, în continuare se pot face adăugiri la elemente de bază.

Markeri interni, de exemplu pentru Mesaj, Timpul, Excepție, Anulare, Compensare, Regulă, Link, Terminare, și Multiple, pot fi adăugați la Evenimente pentru a arăta tipul de Eveniment (Figura 8).

Markeri pot fi adăugate la Activități pentru a distinge Buclă, Instanță multiplă, Compensare, precum și activități Ad-Hoc. BPMN pot fi folosite pentru a crea procese de nivel înalt, precum și procese complexe cu mai multe niveluri de detaliu. Pot să includă procese de instrucție cu puncte de vedere în nivele mai scăzute de detaliu separate, cu diagrame.

Figura 1 Tipuri de markere care pot fi adăugate la evenimente de bază BPMN

(sursă: http://www.omg.org/)

Specificațiile BPMN se referă la șabloane și arată cum BPMNurile se pot ocupa de cerințe de tratare simple și complexe pentru modelarea proceselor de afaceri. Se pot considera bifurcații ale curgerii, unirii ale curgerii, divizarea curgerii, instalarea curgerii, și ciclări, precum și un flux de excepție. [White04a] a investigat măsura în care Diagrama BPMN a proceselor de afaceri (și în UML 2.0 Diagrama de Activitate) poate reprezenta modele de flux de lucru elaborate de van der Aalst et al [Aalst03c]. Pentru fiecare șablon, cele două notations sunt comparate cât de bine tratează șablonul. Este arătat că fiecare șablon poate fi reprezentat în mod adecvat de către BPMN, deși [Wohed05] consideră că există anumite probleme cu soluția propusă și că anumite limitări ale BPMN exista când întreaga gamă de modele este examinată.

Figura 9 arată că fluxul este folosit ca un exemplu ilustrativ în [BPMN] pentru caracteristicile extinse ale BPMN.

Figura 1 Un exemplu de specificație BPMN (sursă: http://www.omg.org/)

Tratarea erorilor, tranzacții, asistență la compensare

Tratarea excepțiilor este posibilă; evenimente intermediare atașate la limita unei activități reprezintă generatoare ca început de activitate.Lucrul în activitatea de muncă va fi oprit și se va continua fluxul de la Eveniment. Se pot genera cronometre excepții, mesaje, etc. O tranzacție este o activitate descrisă de o frontieră dublă. Diferite fluxuri poate fi modelate pentru a permite finalizarea cu succes a tranzacției, o anulare de finalizare, sau o excepție de tranzacție cauzând o eroare. Compensarea este, de asemenea, susținută atunci când este necesar pentru a reveni la anumite activități prin invocarea activități de anulare a efectelelor activita inițial. Activitățile utilizate cu markerul de compensare sunt în afara fluxului normal al procesului și se crede a fi asociate cu activitățile normale.

Extensibilitate

BPMN este extensibil. În speciificatii se afirmă că: 'Extensiile pot fi realizate în elementele Diagrama de noi markeri sau indicatori markeri asociați cu grafice actuale. Acești markeri sau indicatori ar putea fi folosiți pentru a evidenția un atribut specific de activitate pentru a crea un nou tip de eveniment, de exemplu.

În plus, extensiile pot include, de asemenea, un obiect de culoare sau de a schimba stilul de linie a unui obiect, cu condiția ca nu ar trebui să intre în conflict cu orice linie de stil BPMN definită anterior.

Orice număr de artefacte, constând dintr-o varietate de forme, poate fi adăugată la o diagramă, cu condiția ca forma artefactul nu trebuie să între în conflict cu orice altă formă de obiect sau marcator deja definit." [BPMN]

[White05a] introduce pictograme, care nu sunt parte a notație standard BPMN pentru a demonstra extensibilitatea BPMN. Aceasta înseamnă că modelatorii pot crea artefacte necesare pentru scopul lor specifice, posibil adăugând mai multe detalii la o activitate care este în curs de efectuat.

2.3 Maparea la BPEL4WS

Specificația BPMN oferă o mapare a BPEL4WS versiunea 1.1 pentru a arăta modul în care obiectele BPMN și relațiile dintre aceste obiecte pot fi mapate la BPEL4WS. Deși BPMN poate fi considerat aproape de un limbaj de coregrafie mai mult decât un limbaj de orchestratie, nu a existat nici un limbaj de coregrafie disponibil atunci când a fost elaborat. Când o mapare este considerată trebuie decis unde să fie mapată la un format BPEL4WS bazat pe structura grafică BPEL4WS (elementul flux), sau pe structura BPEL4WS bloc (element de ordine). Specificația BPMN adoptă o abordare de mapare a elementelor BPEL4WS în principal folosind elemente și structuri de bloc, și în [White05a] se adoptă o structură de tip graf pentru mapare. Anexa A a specificației prevede codul complet BPEL4WS cod pentru exemplul din corpul principal al specificației.

Nu tot BPMN poate fi descris în BPEL4WS, deci este posibil să se reprezinte procese în BPMN care nu pot fi mapate la BPEL4WS. Cu toate acestea, maparea la BPEL4WS nu este întotdeauna necesară pentru că un proces de afaceri nu este neapărat destinat a fie pus în aplicare ca un proces automat într-un limbaj de execuție a proceselor de afaceri. Acesta poate fi produs la începutul de proiectare a software-ului pentru a înțelege cerințele de proiectare de sistem.

Aplicabilitate

BPMN oferă un standard de notație grafică pentru modelarea proceselor de afaceri. Nu are nici o alt concurent ca standard, exceptând instrumentele proprietate. Ca o notație de modelare pentru afaceri, este aplicabil la SCIPA pentru acele zone de lucru în care o astfel de notație este necesară. Este clar compatibil cu BPEL (4WS) și exists o serie de instrumente software, care permit ca realizarea maparii în mod automat.

Avantaje

BPMN este singura notație standard grafică pentru modelarea de procese de afaceri. Este destinat să permită atât la nivel înalt de afaceri procesul de proiectare, precum și acordarea de asistență pentru modelarea procese de afaceri mai complexe, cât și maparea la un limbaj de executatie. Este destul de intuitiv pentru acei analiști de afaceri cu cunoștințe privind notația grafică a procesului tradițional de afaceri și în același timp permite construirea de procese complexe. Ea se extinde mai mult decât notațiile tradiționale de afaceri în multe privințe, nu numai legat de maparea la un limbaj de execuție, dar sprijină de asemenea conceptul de proces B2B, inclusiv procese publice și private, precum și interacțiunele între două entități de afaceri. Se permite, de asemenea, tratarea excepțiilor, operațiuni de compensare.

Un alt punct forțe al BPMN este suportul său pentru trimite mesaje de modelare între două entități. BPMN poate, de asemenea, descrie fluxurile de mesaje și oferă o notație de obiecte de date care pot fi asociate cu activități.

Spre deosebire de cele mai multe notații pentru procesele de afaceri BPMN permite obiectelor de date să fie reprezentate și modelatorii pot arăta cum datele, documentele și alte obiecte sunt folosite și actualizate în timpul unui flux al procesului. Odată cu creșterea cererii de modelare a procesului de afaceri tip B2B, BPMN crește în semnificație. Cum un proces de modelare de afaceri este implicat în tratarea datelor în cauză, BPMN oferă un avantaj față de alte notații unde modelatorii să utilizeze soluții sau să facă presupuneri, în care sunt implicite nevoile. BPMN nu este, totuși, o notație pentru diagrama fluxului de date. Modele de date și informații nu sunt incluse în specificații.

Specificația BPMN oferă o mapare la BPEL4WS și o serie de instrumente sunt disponibile pentru a sprijini această mapare, care permite astfel ca BPMN să fie utilizat într-un lanț de instrumente. Acest lucru este important pentru mediul SCIPA. Deoarece BPMN este parte aOMG, legăturile sale cu alte specificații și standarde vor fi consolidate.

Dezavantaje

Specificația nu prevede un metamodel sau un schimb de diagrame. Acesta a fost conceput pentru a stabili mecanismul într-o etapă ulterioară [BPMN]. Acest lucru face dificil schimbul de modele între instrumentele de BPMN și poate duce la probleme grave, atunci când o varietate de instrumente sunt utilizate de diferiți modelatori. Decizia de a dezvolta BPDM ca un metamodel pentru BPMN [Frankel06] va consolida poziția și această slăbiciunea specială va fi eliminată.

BPMN nu oferă o notație pentru reprezentarea arhitecturii organizatorice la nivel de proces. Structurile organizaționale și de resurse, de strategie, roluri de afaceri sunt excluse în mod expres din domeniul de aplicare a standardului și luate în considerare ca o problemă deschisă care trebuie rezolvată. Nu există nici o schemă XML asociată cu BPMN. Specificația BPMN ca un nivel limbaj XML deasupra limbajelor de exceutie BPM a fost considerată o problemă deschisă în continuare pentru studiu.

Recomandări

Ca un standard de notație grafică în modelarea proceselor de afaceri, el poate fi recomandat pentru utilizare la SCIPA în fazele timpurii ale sistemului de proiectare. Coregrafia acestor procese de afaceri pot fi specificate folosind notația BPMN.

2.4 Implementări BPMN

Cordys BPMS

CORDYS BPMS oferă: viteză – scurtând timpul de modelare, dezvoltare și modificare, scalabilitate – prin excelență adaptabilitate și expansiune simplă, stabilitate – asigurând execuția proceselor non-stop și continuitatea afacerii, vedere singulară – transparentă a datelor firmei și a proceselor.

Cele cinci componente care interoperează într-o arhitectură singulară și unificată sunt:

CAF – Composite Application Framework, care oferă suport de creare a unor aplicații internet complexe, bazate pe tehnologii Web 2.0;

BPM – Business Process Management componentă de proiectare cu soluție simplă, intuitivă de design, execuție, monitorizare și îmbunătățire a modelelelor de procese de afaceri care sunt construite pentru a constitui o punte între mediul de afaceri și IT.

SOA grid – Service Oriented Architecture grid – asigură scalabilitate și stabilitate în execuție, permite interoperabilitate în timp real și simultană între stratul de proces de afaceri și sistemele IT existente, printr-o abordare bazată pe Service Bus.

BAM – Business Activity Monitoring – componentă care oferă monitorizare în timp real a performanțelor, ceea ce presupune analize de proces predefinite sau ad-hoc și manage-mentul evenimentelor.

Non-Stop High Availability Framework furnizează stabilitate și continuitate permițând reconfigurare facilă, la cerere, pe platforme IT, evitând timpi morți la adăugare sau ștergere de servicii.

SAP Webflow

La crearea unui workflow SAP, cea mai întâlnită problemă o constituie identificarea modalității de inițializare a workflow, cele mai comune mecanisme de start fiind:

introducerea de date de către un utilizator într-un formular web;

procesele de resurse umane – HR human resources – cum ar fi angajarea de personal,

ieșirea – outputul – unui document (trimiterea unei comenzi de achiziție la un furnizor, mecanism folosit în special de modulele MM și SD);

schimbarea unui status (atingerea bugetului, mecanism folosit în special de modulele FI și CO);

schimbarea master dată (schimbarea unui customer info record).

Componentele cheie ale fluxului de lucru SAP includ definiția fluxului de lucru (Workflow Definition), elemente de lucru (Work Items), declanșatori de evenimente (Events triggers) și structura organizatorică la locul de muncă (Organizațional Structure).

ADONIS – o soluție de BPM

ADONIS este un program care sprijină în proiectarea și documentarea imaginii procesului, optimizarea proceselor de afaceri, reingineria și reducerea timpilor și costurilor în organizație. Printre avantajele ADONIS menționăm: utilizarea facilă, curbele de modelare ale învățării scurte, simularea și evaluarea afacerii prin capacitatea de planificare și procesul de calculație a costurilor, suport al diferitelor standarde de modelare și notații – cum ar fi BPMN, UML, EPC, și LOVEM – interfețe pentru implementarea procesului de tipul BPEL, XPDL, XMI, cât și mecanisme de publicare web puternice.

Portalul de proces ADONIS oferă roluri specifice pentru modelele cu acces web, lucru care permite implicarea directă a persoanelor în ciclul de modelare a proceselor de afacere BPM, implicare până acum doar indirectă și fără nici un instrument-suport. Conceptul unic bazat pe rol al ADONIS Proces Portal – APP – oferă informații precise și funcționalitatea cerută de fiecare dintre angajați, datorită interfeței web intuitive și personalizate. Metoda ADONIS se bazează pe cadrul de lucru al sistemelor de management ale proceselor de afaceri – BPMS. Conceptele ADONIS sunt bazate pe fazele identificate în cadrul de lucru, care încadrează teoria unui ciclu de îmbunătățire permanentă.

CONCLUZII

Un proces de afaceri este o colecție de activități în cadrul companiei care are drept scop dezvoltarea produselor și/sau serviciilor pentru clienți.

Gestionarea în mod eficient a proceselor este o activitate critică pentru succesul companiei, iar acest lucru este greu de realizat – în mare parte datorită faptului că procesele nu sunt independente, ci interacționează unul cu altul.

O notație standard de modelare folosită de furnizorii de modelare, analiștii în afaceri și comunitatea IT este fundamentală în gestionarea proceselor de afaceri și în alinierea lor cu arhitecturile de tehnologiei informației (IT).

Executarea proceselor de afaceri este o paradigmă alternativă de dezvoltare la tehnicile tradiționale de dezvoltare. Dezvoltarea în mod tradițional nu va dispărea, de fapt, este fundamentală pentru a sprijini punerea în aplicare a serverelor de management al proceselor de afaceri (BPMS’s).

În capitolul 1 am prezentat pe scurt procesele de afaceri, cum sunt acestea definite, precum și elementete, dar și modelarea proceselor de afaceri.

Modelarea folosind BPMN este esențială pentru înțelegerea și comunicarea proceselor de afaceri în interiorul organizației. BPMN furnizează o creștere puternică pentru celelalte tehnici de modelare cum ar fi modelarea de date, design de aplicații și sisteme cu UML, XML și arhitectura rețelelor. Aceste tehnici de modelare îi permit unei firme să înțeleagă și să definească arhitectura de afacere, ceea ce îi permite să reacționeze rapid la schimbări, într-un mod mai puțin riscant.

În cadrul capitolului 2 am vorbim mai mult despre ceea ce este BPMN, felul cum sunt modelate evenimentele în afaceri, la punctul 2.1.2 am spus despre procese, subprocese și sarcini de afaceri, iar la punctul 2.1.3, despre simularea proceselor de afaceri. 2.2 prezintă legătura dintre BPMN și UML, dar și maparea la BPEL4WS prezentat la punctul 2.3. În final am vorbit despre implementările BPMN.

Simplificarea și demistificarea serviciilor web și a modului lor de a fi folosite în lumea de afaceri este cheia pentru a ajuta clienții să aibă succes pe piața pe care concurează.

În concluzie, putem spune că BPMN este o notație standard grafică și deschisă pentru procesul de modelare de afaceri care a fost dezvoltat de BPMI, acum fuzionat cu OMG. Ea se bazează pe bine-cunoscuta notație flowchart și, astfel, este destul de intuitiv pentru analiștii de afaceri. Caietul de sarcini prevede, de asemenea o notație pentru mai multe procese complexe și o mapre a BPEL (4WS), care îi permite să fie folosit în prima etapă din ciclul de viață al dezvoltării. Există instrumente de sprijin, în special pentru maparea BPEL, dar, de asemenea, pentru XPDL, de asemenea, de interes pentru SCIPA.

Prin urmare, acesta poate fi recomandat pentru utilizare ca o notație grafică la stadiul SCIPA pentru etapa de proiectare a proceselor de afaceri, în special în modelarea coregrafiei proceselor de afaceri.

BIBLIOGRAFIE

Anupindi, R., Chopra, S., Deshmukh, S., Mieghem, J., Zemel, E. (1999), Managing Business Process Flows. Prentice Hall, Englewood Cliffs

Bădică, A., Tehnologii și servicii web, Note de curs, 2013

Juric, M., Sasa, A.: Effective Process Modeling with BPM & BPMN

Șoavă, G., Analiză și proiectare obiectuală, Note de curs, 2012

http://www.bpmn.org

http://en.wikipedia.org/wiki/Business_process_management

http://profs.info.uaic.ro/~alaiba/mw/index.php?title=Nota%C5%A3ia_BPMN_pentru_modelarea_proceselor_de_afaceri

http://profs.info.uaic.ro

http://www.todaysoftmag.ro/article/ro/19/BPMN_%E2%80%93_util_in_modelarea_proceselor_de_business_672

http://www.adonis-community.com

BIBLIOGRAFIE

Anupindi, R., Chopra, S., Deshmukh, S., Mieghem, J., Zemel, E. (1999), Managing Business Process Flows. Prentice Hall, Englewood Cliffs

Bădică, A., Tehnologii și servicii web, Note de curs, 2013

Juric, M., Sasa, A.: Effective Process Modeling with BPM & BPMN

Șoavă, G., Analiză și proiectare obiectuală, Note de curs, 2012

http://www.bpmn.org

http://en.wikipedia.org/wiki/Business_process_management

http://profs.info.uaic.ro/~alaiba/mw/index.php?title=Nota%C5%A3ia_BPMN_pentru_modelarea_proceselor_de_afaceri

http://profs.info.uaic.ro

http://www.todaysoftmag.ro/article/ro/19/BPMN_%E2%80%93_util_in_modelarea_proceselor_de_business_672

http://www.adonis-community.com