II Parte Da Unire

Capitolo 1

Introduzione

Il capitolo presenta il contesto, gli obiettivi e la struttura di questa tesi. Esso mette in risalto la rilevanza di avere un metodo di valutazione per i prodotti di Business Process Management.

1.1 Business Processes e BPM

Ogni societ elabora processi di business. Tali processi di business rappresentano una sequenza controllata di attivit atti alla creazione di un bene o servizio. Il grado di organizzazione di questi processi di business determina il successo di unorganizzazione, incrementando la soddisfazione del cliete e la competizione aziendale sul mercato. I processi di business possono essere visti come un insieme di attivit collegate e correlate tra di loro che vengono progettate per acquisire un certo input e trasformarlo in un output specico. Tutte queste attivita` sono collegate le une con le altre, in modo tale che esse accadano nel giusto momento e nel giusto ordine. Linput di questo processo di business è la richiesta del cliente e loutput è il contratto rmato della polizza assicurativa Fattori come la globalizzazione, le opportunit

Di e-business, linstabilitàPolitica porta ad un mercato caratterizzato da incertezza nel quale unorganizzazione deve costantemente adattarsi. Se unorganizzazione non cambia e non si adatta al suo ambiente, allora deve arontare il rischio di essere esclusa dal mercato [4]. Quindi i cambiamenti organizzativi sono fondamentali per la sopravvivenza di unorganizzazione. Tradizionalmente vengono individ- uati due tipologie di cambiamenti: quelli rivoluzioanari e quelle evolutivi. I primi sono i cambiamenti di tipo radicale che si concretizzano nei progetti di reingegnerizzazione dei processi di business e che cambiano completamenteLe modalit

Operative di unorganizzazione. Il secondo tipo di cambiamentoè invece piu` graduale e permette unadattamento delle modalità operative in base allevolversi della situazione del mercato. Entrambi questi tipi di cambiamenti necessitano delle tecniche e metodologie per la loro gestione. Il Business Process Management è un metodo che facilita la gestione dei cambiamenti che deve arontare unorganizzazione. In particolare, il Busi- ness Process Management (BPM) è una disciplina gestionale che si occupa di descrivere e gestire i processi di business in un organizzazione. Lobiet- tivo del Business Process Management è quello di raggiungere gli obiettivi dellorganizzazione allineando i processi di business con questi obiettivi e migliorando di continuo questi processi.Nellera dellimpresa digitale la gestione dei processi di business viene coadiuvata mediante lutilizzo di sistemi software che sono in grado di ge-Stire una grande quantit

Di informazioni: i sistemi BPM (BPMS). I BusinessProcess Management System sono il risultato della convergenza di diversi trend sulla gestione delle informazioni che sono apparsi nel corso degli anni come viene illustrato in gura 1.1. La gura mostra che i sistemi informativi sono composti da diversi livelli. Il centro è formato dallinfrastruttura del sistema, che consiste dellhardware e del sistema operativo che permette allhardware di funzionare. Il secondo livello consiste di applicazioni gener- iche che vengono utilizzate largamente allinterno di unorganizzazione. Ad esempio tra queste troviamo i Database Management System. Il terzo livello consiste di applicazioni speciche del dominio di applicazione. Queste applicazioni vengono usate solamente entro speciche tipologie di organizzazioni. Il quarto livello consiste di applicazioni sviluppate specicatamente per la singola organizzazione. Nel corso degli anni 60 il secondo e terzo livello non esisteva. Di fatto le organizzazioni disponevano di applicativi fatti su misura incentrati sui dati che erano in esecuzione su sistemi operativi specici dellhardware a disposizione. Con il passare del tempo il numero e la complessità delle applicazioni speciche del dominio e della singola or-Ganizzazione aumentò. Questo fatto fu dovuto alla necessit

Di supportare

Figura 1.1: Livelli di un sistema informativo

Piu` tipi di attività e di utenti. Inoltre lavvento del Web ha richiesto che queste applicazioni fossero accessibili direttamente sia ai clienti che ai part- ner di business. Il trend mutò dal programmare le applicazioni alintegrare le applicazioni esistenti. Nel corso degli anni 70 e 80 i sistemi informativi continuavano ad essere incentrate sui dati. Lattenzione sulla tecnologia IT era incentrata sullo storage, recupero e presentazione dellinformazione vista prima di tutto come dati. Solo a partire dagli anni 90 si inizio` a porre lenfasi sui processi. La necessità di adeguare continuamente i processi di business di un organizzazione al mutare delle esigenze del mercato, porto` alla creazione di metodologie in grado di comporre e riutilizzare le applicazioni esistenti considerandole come una sequenza di attività. Il trend deiSistemi informativi pass

Da essere orientato ai dati ad essere orientato aiProcessi. Il risultato dellevoluzione dei trend citati ha portato alla nascita dei moderni sistemi BPM.I sistemi BPM sono sistemi software che permettono di denire i processi di business mediante lutilizzo di notazioni adatte allo scopo, di metterli in esecuzione e di controllarne lesito. Il supporto di questi sistemi diventa cruciale in termini di competitività sul mercato per lorganizzazione. In- fatti permettono sia di gestire attivita` che devono essere svolte da agenti umani sia di automatizzare completamente altre attività, aumentando cos` lecienza di un processo di business. Essi sono composti da diversi strumenti che permettono un completo supporto al BPM. Per questo motivo sono anche deniti BPM suite [16]. Obiettivo primario dei BPMS è gestire un processo di business. Un processo di business può essere visto come unoO piu` workow che collaborano tra di loro al ne di raggiungere un obiettivo comune. Un workow è lautomazione di una sequenza di attivita`. Il concetto di workow viene denito dal Workow Management Coalition. Il wfmc è un consorzio formato da sviluppatori, analisti e ricercatori che si occupano di denire degli standard per la gestione dei processi di business e dei relativi workow. Tra questi standard il wfmc ha denito lo standard XPDL che è un linguaggio che ha come scopo quello di denire una rappresentazione univoca del modello di processo di business in modo tale che possa essere interpretato da diversi sistemi BPM. Esistono altri enti e consorzi che hanno denito standard nellambito dei sistemi BPM. Uno di questi è lObject Management Group che ha denito uno standard per la modellazione graca di un processo di business: la notazione BPMN (Busi- ness Process Management Notation). Un altro ancora è il consorzio OASIS (Organization for the Advancement of Structured Information Standards) che ha denito lo standard BPEL (Business Process Execution Language). BPEL è uno standard di esecuzione che permette al processo di business di essere eseguito indierentemente su tutti gli strumenti BPM che supportano questo standard. Ladozione di questi standard da parte degli strumenti BPM è importante dal punto di vista dellinteroperabilita. Oltre agli strumenti che devono supportare gli standard descritti, un sistema BPM deve presentare uno strumento che metta in esecuzione il processo di business descritto. Questo strumento è il BPM engine che permette di assegnare lese-Cuzione di unattivit

Del workow ad uno specica risorsa. Una volta cheIl processo di business è in esecuzione, lo strumento BPM deve fornire uno strumento per poter monitorare lo stato del processo e raccogliere metriche sulle prestazioni della sua esecuzione. Questi componenti sono il Business Activity Monitoring (BAM) e il Business Cockpit. Vedremo in dettaglio nel corso dei capitoli successivi i componenti di un sistema BPM.

1.2 Motivazione e obiettivi della tesi

1.3 Struttura della tesi

La tesi è strutturata nel modo seguente.

Capitolo 2

Stato dellarte

Descrizione capitolo

2.1 Processi di business

Ogni prodotto di qualsiasi natura che una compagnia immette sul mercato è il risultato di una serie di attivita` che sono state eseguite per la sua creazione. La tecnologia dellinformazione, in particolare nei sistemi informativi azien- dali, gioca un ruolo chiave nella gestione di queste attivita` e permette la loro esecuzione coordinata. In molte compagnie sussiste ancora il gap tra aspetti di business organizzativi e tecnologia dellinformazione presente [2]. Il su- peramento di questo gap permette di fornire le basi tecniche per la creazioneRapida di nuove funzionalit

Che portano alla realizzazione di nuovi prodottiPermettendo quindi alla compagnia di essere sempre competitiva sul mercato. Strumento chiave anche questo sia possibile è considerare queste attività tutte appartenenti ad uno o piu` processi di business. Per questo motivo possiamo denire un processo di business come un insieme di at- tività eseguite in coordinazione con lambiente organizzativo e tecnico che permette di dare loro unorganizzazione e aumentare la comprensione delle loro relazioni. Queste attività insieme realizzano un obiettivo di business (business goal). Possono essere eseguite direttamente da un agente umano (manualmente oppure aiutato da un sistema informativo) oppure possono essere attivate automaticamente senza il suo coinvolgimento. Ogni processo di business viene attivato da una singola organizzazione ma potrebbe anche interagire con processi di business eseguiti da altre organizzazioni.

2.1.1 Classicazione dei processi di business

I processi di business possono denire sia strategie di business ad alto livello sia processi di business operativi [44]. Tra questi due estremi esistono dierenti livelli che caratterizzano un processo di business (gura 2.1). Al livelloPiu`

In alto un processo di business serve per descrivere la strategia dellaCompagnia, denendo la rotta da seguire a lungo termine per sviluppare un vantaggio competitivo sostenibile sul mercato.Al secondo livello dello schema, la strategia di business viene decomposta in obiettivi operativi di business. Questi obiettivi possono essere organizzati in modo tale che ognuno possa essere ulteriormente decomposto in sotto- obiettivi.Al terzo livello si trovano i processi di business organizzativi. Questi sono processi ad alto livello che tipicamente vengono specicati in forma testuale dai loro input, dai loro output, dai loro risultati attesi e dalle loro dipendenze con gli altri processi di business organizzativi.Per questi tre livelli sono disponibili delle tecniche informali e semiformali che permettono di descrivere in forma testuale e per mezzo di diagrammi la strategia della compagnia, i suoi obiettivi e i suoi processi di business organizzativi.Al di sotto di questi livelli esistono i processi di business detti operativi. A dierenza di quelli organizzativi caratterizzati da funzionalità di business ad alto livello, in questi processi vengono denite nel dettaglio le loro attivita` e le relazioni tra di esse ma non viene denito alcun tipo di implementazione.Questi ultimi sono le basi dei processi di business implementati poichè essi contengono le informazioni sullesecuzione delle attivita` dei processi e sullambiente tecnico e organizzativo sul quale essi sono in esecuzione.Nel corso della trattazione discuteremo del ruolo dei sistemi informatici che hanno nella descrizione e nella esecuzione dei processi di business operativi.Un altro tipo di classicazione riguarda il grado di relazione che un processo di business ha con un altro. Un processo di business che non ha nessun tipo di legame con un altro viene detto intraorganizzativo. Questi tipi di processi hanno come obiettivo primario quello di snellire i processi interni eliminando le attività che non portano valore al processo. Viene denito uno schema delle risorse dellorganizzazione a cui vengono sistematicamente as- segnate delle attivita` del processo in base alla loro competenza. I tradizionali sistemi di gestione dei workow che vedremo piu` avanti sono adatti allo scopo. Quando invece un processo necessita di interagire con un altro allora si parla di coreograe di processi. In questo caso processi facenti parte di una coreograe necessitano di tutta una serie di tecnologie abilitanti al loro scopo. Queste tecnologie riguardano i protocolli di comunicazione, il formato dei dati scambiato e il denire una rappresentazione comune dei vari processi di business. Vedremo nel paragrafo 2.2.3 un paradigma architetturale adatto a questo scopo (SOA).

Di:

Un altro tipo di classicazione pu

automazione ripetizione strutturazione

Essere fatto sulla base del loro grado

Per quanto riguarda il grado di automazione esistono processi di business che non richiedono lintervento umano. In questo caso si parla di processi di business pienamente automatizzati. Un esempio sono le tecnologie EAI (Enterprise Application Integration) il cui compito è quello di integrare

Figura 2.1: Livelli dei processi di business: dalla strategia di business ai processi di business implementatiSistemi informatici eterogenei rendendo questa integrazione trasparente al- lintervento umano. Esistono poi processi che non possono essere in alcun modo automatizzati ma richiedono necessariamente lintervento umano. Un esempio sono tutte quelle applicazioni che richiedono linserimento di dati in una maschera al ne di portare a termine unoperazione. Molti processi di business invece richiedono sia attività di tipo manuale sia attività di tipo automatiche. Quindi sono state sviluppate delle tecnologie che permettono di gestire e sincronizzare entrambi i tipi di attività.Rispetto al grado di ripetizione è possibile valutare quale tipo di tecnologia è piu` adatta a supportare un determinato processo di business. Nei processi di business dove il grado di ripetizione è alto sono richieste tecnologie che permettano la modellazione e lesecuzione automatica dei processi. Questo tipo di tecnologie comportano un investimento di una certa consis- tenza ma consentono la corretta esecuzione dei processi ad alta ripetitivita`. Esistono invece dei processi che invece sono caratterizzati da uno scarso o nullo grado di ripetitività. Questi processi vengono deniti processi di business collaborativi. In questi processi lutilizzo delle tecnologie di supporto non ha come obiettivo quello di ottimizzare lecienza ma quello di monitorare il processo e di scoprire eventuali relazioni causali tra i vari task di progetto. Gli strumenti che andremo ad analizzare permettono di gestire entrambi i tipi di processi descritti.Per ultimo si ha una classicazione dei processi di business in base al loro grado di strutturazione. Si denisce workow di produzione, un proces-So di business il cui modello descrive perfettamente le sue attivit

I vincoliTra queste in modo completo. In questo modo il processo si denisce completamente strutturato. Ad esempio in questi processi sono deniti tutti i vincoli decisionali del processo in modo che nessun tipo di decisione possa essere presa da parte di un intervento umano. Questi tipi di processi, inoltre, sono altamente ripetibili. I sistemi tradizionali di gestione dei workow sono adatti a supportarli. Si denisce invece attività ad hoc, un processo che non necessita di essere denito completamente in quanto deve dare una certaessibilit

Alloperatore umano di poter gestire parti del processo in baseAlla sue competenze. Quindi questi processi sono caratterizzati da un basso livello di strutturazione e da un alto livello di essibilità. Anche per questi tipi di processi esistono tecnologie in grado di supportarli.

2.1.2 Componenti di un processo di business

Descriviamo ora le parti costituenti di un processo di business. Deniamo con il termine caso (case) la produzione di un particolare prodotto. Og-Ni caso richiede che un processo (process) venga eseguito. Un processo consiste in un insieme di task che devono essere espletate ai ni del suo completamento e di un insieme di condizioni (condition) che determinano lordine delle attivita. Un task può essere considerato come un processo cheNon pu

Essere diviso ulteriormente e che viene svolto nel suo insieme daUna risorsa (resource). Chiamiamo attivita lesecuzione di un task da parte di una risorsa. Una risorsa è il nome generico che viene assegnato ad una persona, macchina o gruppo di persone e macchine che possono eseguire attività speciche. Ciò non signica che una risorsa necessariamente debbaPortare a termina lattivit

Per la quale è stata assegnata. Tuttavia con ilSuo assegnamento essa diventa responsabile dellesito di tale attività. Due o piu` task che devono essere eseguiti seguendo un determinato ordine sono chiamati sequenza. Quando è necessario scegliere tra due o piu` task per il proseguimento del usso di processo ci troviamo nel caso di selezione tra piu` task. Ci sono task che possono anche essere eseguiti in parallelo. Questi ultimi devono essere completati ad esempio prima che il task succes- sivo possa entrare in esecuzione. Questo caso è chiamato sincronizzazione.E` possibile ripetere lesecuzione di piu` task durante lesecuzione di un pro-Cesso. Questa operazione è chiamata iterazione. Ricapitolando possiamoIdenticare quattro meccanismi di base nella struttura di un usso di unProcesso: sequenza selezione parallelizzazione iterazione

è Gli strumenti che andremo ad analizzare si occupano della modellazione di questi meccanismi e dellesecuzione di questi processi di business. I sistemi informatici orono la possibilità di gestire questi processi di business ed in particolare quelli che vanno sotto il nome di Business Process Management System (BPMS). Nel paragrafo 2.2 illustreremo i concetti di questi sistemi.

2.2 Business Process Management

Il paragrafo illustra prima di tutto la denizione di Business Process Man- agement (par. 2.2.1). Poi presenta il concetto di workow (par. Sub- sec:Workow), i modelli che lo deniscono e larchitettura dei sistemi cheLo gestiscono. Verr

Trattata larchitettura dei Web Service (par. 2.2.3).I Web service sono la tecnologia che viene impiegata per gestire processi di tipo business to business. Inne il paragrafo illustra concettualmente la struttura di un sistema BPM (BPMS) (par 2.2.4).

2.2.1 Denizione di Business Process Management

Il Business Process Management è il risultato della convergenza di diverse discipline, tra le quali troviamo: modellizzazione dei processi di business, la gestione della qualita`, la computazione distribuita, la gestione dei workow e la reingegnerizzazione dei processi di business [34]. Esistono diverse denizioni di Business Process Management. Secondo Horak [10], il Business Process Management è

Business Process Management (BPM) è un approccio sistematico e strutturato per analizzare, migliorare, controllare e gestireI processi di business con lo scopo di migliorare la qualita dei prodotti e dei servizi.Unaltra denizione di BPM è quella data da Weske [43]:Un BPM è un sistema il cui scopo è quello di supportareI processi di business utilizzando metodi, tecniche e softwarePer progettare, mettere in esecuzione, controllare e analizzareI processi operativi che coinvolgono esseri umani, organizzazioni,Applicazioni, documenti e altre fonti di informazione.Lultima denizione che citeremo è quella data da Gartner [15]:

Un sistema BPM è un sistema composto da servizi e strumenti che supportano in modo esplicito la gestione del processo di business (analisi, denizione, esecuzione, monitoraggio e amministrazione).

Dallunione delle tre denizioni di Business Process Management è possibile ricavarne una che descrive in modo completo un sistema BPM:

Business Process Management è una disciplina gestionale che utilizza un approccio sistematico e strutturato con il ne di supportare la gestione esplicita di un processo di business utilizzando metodi, tecniche e strumenti, che coinvolgono esseri umani, organizzazioni, applicazioni, documenti e altre fonti di informazione, con lo scopo di raggiungere gli obiettivi di business dellorganizzazione allineando i processi di business a questi obiettivi.Nel paragrafo 2.2.4 descriveremo i componenti di un sistema BPM in riferimento alla denizione data di BPM.

2.2.2 Workow

Secondo il Workow Management Coalition (wfmc), un workow è lautomazione di un processo di business in tutto o in parte durante la quale documenti, informazioni e tasks vengono passati da un partecipante ad un altro anchè si possa raggiungere un obiettivo comune, utilizzando un insieme predenito di regole. Un workow può essere visto come un componente di un processo di business, in quanto consiste in una sequenza di attività speciche di una particolare applicazione attuate attraverso insiemi di istruzioni predeniti, coinvolgendo sia procedure automatizzate che man- uali. Per questo si dierenzia da un BPM che invece riguarda la denizione, lesecuzione e la gestione di un processo di business indipendentemente dalle applicazioni che praticamente svolgono i task del processo. Un workow viene descritto attraverso tre modelli:

Modello di processo Modello informativo Modello organizzativoPer descrivere i tre modelli verranno utilizzati due modelli per descrivereI workow: quello del Workow Management Coalition [18] e il modelloWIDE (Workow on Intelligent and Distributed database Environment) [5].Di seguito la descrizione dei tre modelli. Lutilizzo di questi due modelliE della loro terminologia non fa perdere di generalità la descrizione dei treModelli che costituiscono il workow.

Modello di processo

Utilizziamo la terminologia utilizzata dal Workow Management System per denire un workow e metterlo in relazione con un processo di business. In gura 2.2 lo schema della terminologia utilizzata per i vari componenti e le relazioni tra di essi.I componenti fondamentali di un workow sono:

Processo: un processo è denito come la rappresentazione formale di un processo di business in modo tale che la sua manipolazione sia possibile per mezzo di un workow management system (wfms). Questoè composto da un insieme di attivita, da relazioni tra queste attivita. Da criteri di inizio e terminazione del processo e da informazioni circa le singole attività, i partecipanti, i documenti e i dati relativi, applicazioni software richieste.

Partecipante di WF: un partecipante di un workow è una risorsa che esegue il lavoro associato ad una particolare istanza di task. Il lavoro viene generalmente si riferisce ad un elemento di task con-Tenuto allinterno della work list del partecipante. Questo pu

EssereUna risorsa umana, unapplicazione software, una parte specica di hardware in grado di eseguire un task.

Work list: ogni partecipante del workow ha la sua lista di task da eseguire. Questa work list può anche essere assegnata ad un gruppo di agenti (lista condivisa). La work list è gestita da un workow engine e appartiene allinterfaccia tra il workow engine e il gestore della work list.

Figura 2.2: Terminologia utilizzata dal Workow Management Coalition per descrivere i componenti di un workow

Per quanto concerne la descrizione di un processo sottoforma di modello, il Workow Management Coalition ha denito gli elementi costituenti questo modello che ora andiamo a descrivere. Il modello cos` proposto viene preso come riferimento per lo sviluppo di linguaggi di modellazione per workow: Processo: vista formalizzata di un processo di business, rappresenta- to come un insieme coordinato di attività connesse tra loro in modo da raggiungere un obiettivo comune. Sotto processo: processo che viene attivato da un altro processo(istanziato) e che rappresenta parte del processo totale. Blocco di attività: un insieme di attività contenute della denizioneDi processo che condividono una o piu`

Proprietà che permettono alWorkow management software di svolgere alcune azioni rispetto a questo gruppo. Ad ogni singola attività viene assegnato uno stato. Deadline: un vincolo di schedulazione temporale che richiede che unaCerta attivit

Venga completata in un certo intervallo di tempo.

Instradamento (Routing): è come vengono connesse tra loro iDiversi blocchi di attivita. Sono possibili due tipi di instradamento:

Sequenziale: le attività vengono eseguite in sequenza sotto un singolo thread di esecuzione (le condizioni di AND-split e AND- join non avvengono con questo instradamento) Parallelo: due o piu` istanze di attività vengono eseguite in parallelo allinterno del workow, dando origine a thread multipli diControllo. Le attivit

Possono essere attivate in parallelo (AND)Oppure può essere scelto una o piu` attivita`Poraneamente (OR). Quando da unattivit

Da eseguire contem- parte lesecuzioneCoordinata di piu`

Attivit

Si parla di attivazione parallela .Quando invece da piu`

Attivit

Si torna ad una solo si parla disincronizzazione. Nelle gure da 2.3 a 2.6 i quattro possibili casi.

Ciclo: ripetizione di una stessa attività o di una sequenza di attività nchè non viene soddisfatta una determinata condizione.

Pre-post condizioni: una pre-condizione è unespressione logica che viene valutata dal workow engine per decidere se iniziare unistanza di un particolare processo. In modo opposto una post-condizione è unespressione logica che viene valutata dal workow engine per decidere unistanza di un particolare processo può denirsi completata.

Per poter descrivere un modello di workow vengono utilizzati diversi linguaggi di modellazione. Nel paragrafo 2.2.2 vengono descritte le reti di Petri come formalismo di base per descrivere i processi di workow. Al

Figura 2.3: Attivazione parallela di attivit à da eseguire in parallelo

Figura 2.4: Sincronizzazione parallela di tutte le attivit à

Figura 2.5: Attivazione condizionale di una o pi u` attivit à

Figura 2.6: Sincronizzazione parallela di tutte le attivit à attivate dalle condizioneModello graco delle reti di Petri si ispirano la maggior parte dei linguaggi di modellazione dei processi esistenti.

Reti di Petri

Le reti di Petri sono dei modelli matematici utilizzati per descrivere i sistemi distribuiti di tipo discreto, per i quali sono fondamentali le conseguenze locali delle operazioni e linuenza locale degli stati degli oggetti [8]. In questa sede non descriveremo il formalismo matematico di questo modello (per il quale si rimanda a [36]), ma cercheremo di descrivere lutilizzo delle reti di Petri per descrivere i processi di workow.Le reti di Petri sono utili per la modellizzazione di sistemi il cui comportamento è dominato da un usso di informazioni, oggetti, da logiche di controllo e cos` via, cioè da tutte quelle operazioni caratterizzate da un dare e da un ricevere. Una rete di Petri viene visualizzata come un grafo diretto avente due tipi di nodi: i posti, rappresentati da un cerchio, e da transizioni, rappresentati da rettangoli. Le reti di Petri sono un grafo bipartito cioè linsieme dei suoi vertici si può partizionare in due sottoinsiemi tali che ogni vertice di una di queste due parti è collegato solo a vertici dellaltra. In particolare il modello delle reti di Petri si fonda su questi concetti di base:

Un posto (place) rappresenta uno o piu` oggetti. Ogni oggetto è sempre in qualche stato.

Una transizione (transition) rappresenta uno o piu` operazioni, che sono solo possibili a degli stati specici degli oggetti e che cambiano lo stato di uno specico oggetto.

Una regola di occorrenza (occurrence rule) determina sotto quali stati di un oggetto un transizione sia in grado di attivare (re - condizione di attivazione) loperazione rispettiva e in che modo lo stato di un ogget- to cambia a seguito di questa attivazione. Gli elementi che vengono utilizzati per denire le regole di occorrenza sono i token (gura 2.7). Infatti una transizione viene attivata se e solo se ogni posto di ingresso contiene almeno un token. La sua attivazione comporta il consumo del token presente nei posti in ingresso e la conseguente produzione di un token nel posto in uscita della transizione.

Il principio di località permette di circoscrivere lazione della condizione di attivazione di una transizione e il cambiamento di stato causato da questa solo a quei posti che sono direttamente connessi alla transizione attraverso un arco. Al contrario, lo stato di un postoInuenza solo le transizioni poste nelle immediate vicinanze del posto, e può solo cambiare dallattivazione (ring) di queste transizioni.

Figura 2.7: Attivazione di una transizione

La gura 2.8 mostra un esempio di modello classico di rete di Petri. Questo modello contiene delle limitazioni che non lo rendono adatto per de-

Figura 2.8: Esempio di modello classico di rete di Petri

Scrivere un processo di workow. Innanzitutto non è possibile distinguereI vari token gli uni dagli altri. Questo fatto limita i token ad avere tut-Ti la stessa semantica. Poi questo modello non è in grado di descrivere iVari aspetti temporali del usso di processo: infatti esiste un unico aspet-To temporale espresso dallordine degli archi. Inoltre questo modello tendeA crescere velocemente di dimensione rendendo la sua gestione complessa.Per superare questi limiti è stato denito un modello piu` avanzato delle retiDi Petri: le reti di Petri ad alto livello. Queste permettono permettono diSuperare le limitazioni del modello classico introducendo tre estensioni:1. Reti di Petri colorate2. Estensione temporale3. Supporto alla gerarchia

In particolare, le reti di Petri colorate permettono di assegnare ai vari token un valore con il quale il token rappresenta una particolare condizione delle regola delloccorrenza (gura 2.2.2). Lestensione temporale permette di denire un timestamp su ogni token (gura 2.2.2). Il timestamp rappresenta listante di tempo durante il quale il token può essere utilizzato dalla transizione. Con questa estensione è possibile introdurre il concetto di ritar- do nellesecuzione del usso del processo. Inne il supporto alla gerarchiaPermette di ridurre la complessit

Delle reti di Petri aumentando il gradoDi leggibilit

Del processo descritto. Il supporto alla gerarchia introduce ilConcetto di sotto-processo che è alla base a sua volta del concetto di riuso dei processi (gura 2.2.2).

Figura 2.9: Estensione reti di Petri colorate

Il modello delle reti di Petri ad alto livello può essere utilizzato per descrivere i processi di workow. Questo formalismo permette in particolare di descrivere il modello del processo di workow ma non il suo corrispettivo modello informativo e organizzativo.Un processo di workow deve essere delimitato da uno stato di inizio e da uno stato di terminazione. Gli elementi che fanno parte delle reti di Petri devono essere contestualizzati ai workow. I token possono assumereI seguenti ruoli: un oggetto sico, ad esempio un prodotto; un artefatto informativo, ad esempio un messaggio; una collezione di oggetti, ad esempio un magazzino di componenti; un indicatore di stato, ad esempio lo stato in cui si trova il processo;

Figura 2.10: Estensione temporale rete di Petri

Figura 2.11: Supporto alla gerarchia di una rete di Petri un indicatore di una condizione, ad esempio la presenza di un token può indicare il raggiungimento di una condizioneUn posto può assumere il ruolo di: un tipo di mezzo di comunicazione, ad esempio una linea telefonica; un buer, ad esempio una coda;

una locazione geograca, ad esempio un luogo specico dellorganizzazione;

un possibile stato o condizione, ad esempio un possibile stato in cui si trova un ascensore;

Una transizione pu

Assumere il ruolo di:

un evento, ad esempio linizio di unoperazione;

una trasformazione di un oggetto, ad esempio laggiornamento di un database; il trasporto di un oggetto, ad esempio linvio di un le;

Per quanto riguarda linstradamento del usso di processo (routing), le reti di Petri permettono di denire quattro tipologie riguardanti i workow:1. Sequenze di task.

2. Instradamento parallelo, caratterizzato da un componente di tipo AND- split allinizio e di tipo AND-join al termine.

3. Instradamento selettivo, caratterizzato da un componente di tipo AND- split allinizio e di tipo AND-join al termine.

4. Instradamento iterativo, che può essere di tipo repeat-until o di tipo while-do.

Un processo viene denito come un collezione di task, condizioni, sotto- processi e relazioni. Lattivazione delle varie transizioni lungo il processo avviene mediante lutilizzo di diversi trigger (gura 2.2.2) che sono stati deniti appositamente per il contesto dei processi di workow:

Automatici (Automatic): il task viene attivato automanticamente non appena viene abilitato a farlo. Questo trigger viene utilizzato quandoI task sono gestiti direttamente dal sistema e non richiedono alcun intervento umano. Utente (User): il task viene attivato da parte di un partecipante umano al processo

Messaggio (Message): rappresenta un evento esterno che abilita lesecuzione di un task.

Tempo (Time): il task viene attivato per mezzo di un evento temporale.

Figura 2.12: Tipologie di trigger di una rete di Petri che descrive un workow

Dopo aver descritto come le reti di Petri si adattano al contesto dei processi di workow, mostriamo un esempio di processo di workow modelliz- zato tramite le reti di Petri (gura 2.2.2). Il processo di workow descritto riguarda il processo di prenotazione di una vacanza presso unagenzia di viaggio.Per ulteriori approfondimenti si consiglia [35], [36] e [8].

Modello informativo

Il modello informativo di un workow descrive le informazioni ricevute, mod- icate o prodotte da un workow. Secondo il modello WIDE, il modello informativo di un workow puo` essere denito in tre diverse modalita`:1. Attraverso uno schema variabili del workow;2. Attraverso un database condiviso con altri workow;3. Attraverso documenti che vengono scambiati tra i diversi workow. Nel primo caso viene denito nel workow uno schema delle variabili cheHanno visibilit

Solo allinterno della particolare istanza del workow. LeIstanze del workow non possono avere accesso alle variabili di unaltra istanza: ognuna di queste possiede una propria copia dello schema delle

Figura 2.13: Esempio di processo di workow descritto mediante rete di Petri: il caso dellagenzia di viaggioVariabili del workow. Di solito queste variabili vengono denite al momento della denizione del task a cui queste si riferiscono.Nel secondo caso, la denizione di uno schema delle variabili potrebbe includere delle denizioni riguardo a dei dati che devono rimanere persistenti. Questi dati devono poter essere condivisi dai vari partecipanti del workow e anche da altri workow. Inoltre, questi dati persistenti possono anche essere deniti allinfuori della denizione del workow. Questi dati possono essere scambiati con altri workow e tra i vari task del workow mediante la loro manipolazione o recupero. La semantica di queste operazioni deve essere dichiarata allatto di denizione del processo di workow. Possono anche essere utilizzati dei database esterni condivisi e indipendenti dal particolare wfms utilizzato; hanno accesso a questi database i vari partecipanti durante lesecuzione del workow. Nel caso di utilizzo di database esterni, questi dati possono essere deniti con una notazione disponibile nel campo delle basi di dati, come ad esempio di diagrammi entita-relazione (diagrammi E-R).Nel terzo caso, linsieme di informazioni che vengono utilizzate in maniera esplicita dal workow, oppure le informazioni che vengono create e/o modi- cate da un utente per portare a termine un task, vengono descritte attraverso degli elementi di tipo documento. Questi elementi possono essere deniti direttamente nel workow attraverso lutilizzo di form oppure possono essere creati da strumenti esterni al workow. I documenti creati da strumenti esterni possono essere documenti di testo, immagini, ecc. Invece attraverso la denizione del workow, i documenti vengono deniti sottoforma di form. Le form sono quindi un insieme di campi di dati associati ad un determinato task del workow che, una volta compilati, vengono salvati nella form stessa oppure vengono associati ad attributi presenti nelle tabelle di database condivisi. I wfms possono generare automaticamente queste form ai partire dai campi di dati.Oltre alle modalità di rappresentazione delle informazioni che abbiamo descritto, esiste un ulteriore aspetto che caratterizza i workow che sono in evoluzione: laspetto temporale delle informazioni. Nei workow questoTipo di informazione pu

Essere utilizzata per molteplici scopi: un utiliz-Zo tipico, ad esempio, è il monitoraggio dellarrivo di un certo istante di tempo. Queste condizioni temporali possono essere espresse attraverso le informazioni temporali. In particolare queste condizioni possono essere:

condizioni istantanee: determina quando una determinata azione deve essere eseguita.

condizioni di intervallo: servono per testare se un certo intervallo di tempo è trascorso da un altro evento. condizioni temporali periodiche: servono per vericare se delle condizioni temporali periodiche vengono soddisfatte da un certo istante di tempo.

Esempi di utilizzo delle informazioni temporali è la gestione delle eccezioni: ad esempio si possono denire eccezioni che devo essere sollevate in un particolare istante di tempo, oppure possono essere denite condizioni di scadenza sullesecuzione di un particolare task.

Modello organizzativoIl modello organizzativo di un workow deve descrivere:

la struttura dellorganizzazione;

il partecipante al processo di workow;

lautorizzazione che ha un partecipante per eseguire una determinata attività del processo di workow.

Sfruttiamo il modello WIDE [5] per descrivere le caratteristiche di un modello organizzativo di un workow. Lutilizzo della terminologia di questo modello non inuisce minimamente sui concetti generali che descrivono il modello organizzativo di un workow.Nel modello di workow WIDE, un partecipante ad un processo di work-ow viene chiamato agente. Con lentit ulteriori sotto-entità:

Agente possono essere descritte

Attore (Actor): è una risorsa di esecuzione individuale. Può essereUmano oppure un agente software. Un Attore pu

Essere specicatoUtilizzando diversi attributi tra cui la sua disponibilità.

Gruppo (Group): è un insieme di attori che possiedono comuni caratteristiche (ad esempio appartengono tutti ad una particolare unita` dellorganizzazione).

Funzione di organizzazione (Organization function): descrive una funzione che può essere eseguita da un gruppo o da un attore individuale. Viene assegnato un attibuto di tipo capacità di esecuzione (skill).

La struttura di unorganizzazione viene specicata attraverso le relazioni che vengono denite tra queste entita.Il modello organizzativo viene utilizzato dal wfms per indenticare un particolare agente coinvolto nel processo di workow. Achè questo sia possibile, ogni agente viene caratterizzato da un identicativo univoco. Questo permette di sapere quale partecipante sta eseguendo un determinato task.Inne il modello organizzativo di un processo di workow desce i meccanismi di autorizzazione dei vari agenti. Ogni task del workow deve essere eseguito da agenti autorizzati. Per questo cè la necessità di specicare quali agenti possono eseguire i vari task. In questo modo, gli agenti possono monitorare i task di loro competenza che devono essere eseguiti e di vericare se ci sono azioni da intraprendere. A questo proposito si introduce il concetto di ruolo. Un ruolo è una descrizione generica delle entita` a cui è permes- so eseguire uno specico task. I ruoli vengono deniti separatamente dagli agenti e dalla struttura organizzativa e possono riferirsi ad un uno o piu` task del workow. Il concetto di ruolo porta a due vantaggi:

1. Indipendenza tra i partecipanti di un workow e la denizione del processo;2. Fornire un metodo per bilanciare il carico di lavoro.

Lassociazione tra ruoli e partecipanti (o attori) del processo viene eseguita quando vengono denite le informazioni di autorizzazione per quel partecipante, cioè linsieme di ruoli che possono essere eseguiti da quel particolare partecipante. Inoltre è possibile associare un insieme di vincoli ai diversi ruoli in modo tale da regolare laccesso e la manipolazione delle informazioni ad ogni partecipante appartenente cui sono associati questi ruoli.Dal punto di vista della progettazione del workow esistono due ruoli di base:

1. Il progettista del workow: denisce le speciche dei processi di workow, in termini di schemi di workow;2. Lamministratore del workow: è incaricato alla gestione del workow.Denisce la struttura di una specica organizzazione e gli attori chePartecipano allesecuzione di un processo di workow.Dal punto di vista dellesecuzione del workow esistono i seguenti tre ruoli:

1. Lesecutore dellistanza di workow: è lagente che inizia il caso di workow;2. Il responsabile dellistanza di workow: lagente che ha la respons-Abilit

nale sul risultato dellistanza di workow;3. Lesecutore del task: lagente che sta eseguendo un task.

Grazie al modello organizzativo appena descritto, un wfms è in grado di assegnare task ai vari partecipanti del workow in fase di esecuzione.Questo assegnamento pu

Essere eettuato sia mediante uno scheduler, doveLengine dello scheduler assegna il task al miglior partecipante disponibile del ruolo associato al task secondo la policy di assegnamento, oppure viene fatto direttamente da un utente. Nel primo caso si parla di assegnamento automatico dei task; nel secondo caso si parla assegnamento manuale che potrebbe essere assistito dal calcolatore nellidenticazione delle priorità e dei casi critici). La necessita` di entrambe le modalità di assegnamento dei task emerge in tutte quelle situazioni in cui il task viene assegnato ad un gruppo di partecipanti e, allo stesso tempo, non vi è il bisogno di schedulare in anticipo chi deve eseguire quel determinato task.

Sistemi di gestione di workow (wfms)

In questo paragrafo descriveremo la struttura di un sistema di gestione di workow. Una generica architettura di sistema di gestione dei workow permette di gestire i vari sottosistemi necessari per la progettazione e lattuazione dei workow sia di sistema che quelli ad interazione umana (g.2.14). Larchitettura contiene i seguenti sottosistemi e ruoli:

Figura 2.14: Schema base di un workow management system Workow Modelling che fornisce i mezzi per poter modellare i processi di business.

Workow Model Repository che si occupa di immagazzinare i modelli di workow che sono stati creati.

Workow Engine è responsabile delattuazione dei processi di workow. Esso in particolare permette la creazione e lattuazione di unistanza di workow quando questa viene richiesta.

Il workow engine si comporta diversamente in base alla tipologia di workow che deve istanziare. Nel caso di workow di sistema esso manda avanti il usso di workow secondo quanto è stato denito nel modello di workow, occupandosi direttamente del trasferimento di dati tra le applicazioni coinvolte nel processo. Nel caso invece di workow ad interazione umana, listanza di workow contiene sia applicazioni invocate automaticamente sia interazioni umane. Queste interazioni umane vengono eseguite utilizzandoUna Graphical User Interface. Inoltre la conoscenza delle abilit

E delle com-Petenze dei partecipanti al processo permette al workow engine di assegnare correttamente i task a chi ha le competenze per portarlo a termine.Larchitettura sopra descritta è un modello generico di architettura dei wfms. Una descrizione piu` completa è stata fornita dalla Workow Man- agement Coalition, la quale descrizione è diventata un punto di riferimento nella progettazione di questo tipo di architetture. La gura 2.15 illustra i vari componenti di questa architettura di riferimento. Il componente centrale di questa architettura è il Workow Enactment Service che nella terminologia del wfmc rappresenta il Workow Engine prima descritto. Questultimo comunica con gli altri sottosistemi per mezzo di interfacce.Il sottosistema Process Denition Tools rappresenta gli strumenti per mezzo i quali è possibile modellare i processi. Esso è connesso al Workow Enactment Service per mezzo dellinterfaccia 1. Lobiettivo di tale interfac- cia è di permettere agli strumenti di modellazione prodotti dai vari vendors di rappresentare i processi di business in una forma standard. In particolare linterfaccia suggerisce lutilizzo di un linguaggio basato su XML chiamatoXPDL, XML Process Denition Language. Deniremo piu`

Avanti questoTipo di linguaggio. Il sottosistema Workow Client Applications permette linterazione con i partecipanti umani del processo quando viene attivato un workow ad interazione umana. Lobiettivo dellinterfaccia 2 è quello di permettere la comunicazione delle applicazioni client di vendors dierenti con il Workow Enactment Service. Il sottosistema Invoked Applications rappresenta linsieme di applicazioni che permettono di svolgere specici task

Figura 2.15: Architettura di un workow management system secondo wfmc

Del processo. Linterfaccia 3 con il sottosistema centrale denisce degli standard di comunicazione che permettono linteroperabilità di questultimo con linvocazione di applicazioni installate su piattaforme software eterogenee. Il sottosistema Other Workow Enactement Services rappresenta il gruppo di altri Workow engine che per mezzo dellinterfaccia 4 possono interagire tra loro grazie dei protocolli di scambio dati comuni. Il sottosistema Ad- ministration and Monitoring Tools contiene gli strumenti che permettono di amministratore lesecuzione di un workow e di tenerne monitorato lo stato. Anche questi strumenti devono interfacciarsi al workow engine e lo fanno per mezzo dellinterfaccia 5 che rappresenta uninterfaccia generica implementata con diverse tecniche.Gli strumenti BPMS che andremo ad analizzare sono il risultato di diversi componenti che seguono logicamente lo schema architetturale appena descritto. Limplementazione di questo modello architetturale ha subito delle evoluzioni in base allaorare di nuove tecnologie e necessita` di integrazione tra i vari processi di business. Descriviamo ora come è stato implementato questo modello architetturale nei tradizionali workow management system. In seguito nel prossimo paragrafo descriveremo la loro evoluzione nelle architetture orientate ai servizi.Nei tradizionali workow management system vi è una separazione tra tempo di costruzione (build time) e tempo di esecuzione (run time) di un processo di workow (gura 2.16). In particolare a tempo di costruzione il processo viene denito attraverso uno strumento di modellazione graca mentre a tempo di esecuzione una istanza del processo viene eseguita dal workow engine. In base al tipo di workow management system utiliz-

Figura 2.16: Separazione tra tempo di costruzione e tempo di esecuzione di un processo di workow

Zato, il modello di workow viene rappresentato da uno script scritto nel linguaggio di workow di quel sistema. I modelli di workow cos` deniti vengono salvati in un database oppure in un repository di modelli di workow. Quando un processo di business richiede lesecuzione di un particolare workow, il workow engine crea un istanza di questultimo e lo mette in esecuzione. Una volta in esecuzione listanza del processo è totalmente in- dipendente dalla denizione del modello di processo in quanto non sussiste alcun collegamento tra i due. Questa situazione porta a non poter cambiare la struttura di unistanza di un usso di workow mentre questa è in esecuzione facendo delle modiche sul modello del processo stesso. Per questultima esigenza sono stati teorizzati dei sistemi di workow essibil- i. Come è intuibile dal nome questi sistemi permettono di cambiare la struttura del usso di un workow in esecuzione agendo sulla denizione del suo modello. Questo permette di adattare il workow in esecuzione in quei scenari di processi di business caratterizzati da ambienti altamente dinam- ici. Condizione anchè sia possibile adattare dinamicamente un workow in esecuzione è che il workow in esecuzione sia coerente con il workow modicato (relazione di continuità).Fino ad ora abbiamo parlato delle architetture per gestire e mettere in esecuzione dei workow. Come abbiamo gia` discusso, il risultato di un processo di business dipende dallesecuzione coordinata di vari workow e dalla collaborazione con altri processi di business.

2.2.4 Sistemi BPMS

Nel paragrafo 2.2.1 abbiamo dato la denizione di BPM. Questa denizione aerma che un BPM supporta in modo esplicito la gestione del processo di business. Questo signica che i processi di business devono essere deniti in modo esplicito. Processi di business impliciti sono insiti nei pattern di lavoro degli impiegati di unorganizzazione o nella logica applicativa delle applicazioni. Rendere i processi di business espliciti richiede che un modello di processo di business debba essere prodotto nel quale i processi di business possano essere deniti in maniera precisa. Questo modello dovrebbe essere analizzato e migliorato se necessario. Deve essere possibile decidere se im- plementare il modello con o senza un supporto IT, e se rendere disponibile allesterno dellorganizzazione il processo di business. Quando viene implementato un processo di business senza il supporto IT devono essere create nuove politiche e pattern di lavoro a cui i partecipanti del processo di business devono adeguarsi. Nel caso il supporto IT sia disponibile, il modello del processo di business viene reso eseguibile e deve essere progettato un ambiente di esecuzione in grado di supportarlo. Lambiente di esecuzione di un processo di business consiste di un engine di esecuzione del processo di business. Questo deve essere in grado di: eseguire i processi di business eseguibili

gestire le modalit

Di interazione del processo che gli utenti utilizzanoPer interagire con i modelli eseguibili del processo di business gestire le funzionalità denite nel processo di business

Un modello di processo di business eseguibile può essere tradotto in codice ed essere eseguito da un engine di esecuzione del processo di business. Gli utenti possono interagire con i processi di business in esecuzioneE i manager possono monitorarli e controllarli. I processi di business in esecuzione e quelli terminati possono essere analizzati per trovare margini di miglioramento, creando un ciclo continuo di miglioramento del processo di business.Le operazioni citate possono essere racchiuse in un ciclo di vita di un processo di business [44]. La gura 2.18 mostra lo schema del ciclo di vita di un processo di business e i corrispettivi componenti di un sistema BPM. Il ciclo di vita di un processo di business è diviso in fasi che sono collegate le

Figura 2.18: Ciclo di vita di un processo di business e corrispettivi componenti del sistema BPM

Une con le altre. Le fasi sono organizzate in una struttura ciclica, mostrando le loro dipendenze logiche. Queste dipendenze non implicano il rispettare uno stretto ordine temporale per lesecuzione delle fasi. Infatti molte attivita` di progetto e di sviluppo vengono condotte durante ciascuna di queste fasi.Le fasi di un processo di business possono essere mappate nelle corrispettive metodologie e tecnologie che formano i componenti di un sistema di Business Process Management (BPMS). Descriviamo ora queste fasi e le loro corrispettive funzionalità.

Progettazione In questa fase i processi di business vengono identicati, rivisti, validati e rappresentati con dei modelli di processi di business. La notazione graca esprime i modelli di processi di business in modo esplicito. Tecniche di modellazione di un processo di business come la validazione, simulazione e la verica vengono utilizzate durante questa fase. Per quan-To concerne le tecniche di modellazione e validazione, gli strumenti BPM mettono a disposizione un ambiente di modellazione che permette di descrivere il processo di business con un determinato formalismo (vedremo alcuni di essi nel capitolo 3) e di validare il modello. Le tecniche di simulazione possono essere utilizzate per supportare la validazione del modello. Infatti tramite la simulazione è possibile scoprire quelle sequenze di esecuzione che mostrano dei bottleneck prestazionali durante la loro esecuzione e di vericare la correttezza del loro comportamento. La maggior parte dei sistemi BPM forniscono un ambiente di simulazione che puo` essere usato in questa fase.

CongurazioneUna volta che il modello del processo di business viene progettato e vericato, il processo di business deve essere implementato. Un sistema BPM fornisce dei componenti software dedicati a questo scopo. Questi componenti si occupano di fornire le informazioni tecniche necessarie che facilitano lattivazione del processo nel BPMS. Il sistema BPM deve essere congurato secondo lambiente organizzativo e in base ai processi di business che devono essere messi in esecuzione. La congurazione deve includere sia le interazioni degli utilizzatori del sistema con esso sia lintegrazione dei sistemi software esistenti con il BPMS. La congurazione di un BPMS potrebbe coinvolgere aspetti transazionali quindi deve essere congurato in modo tale da garantire lapplicazione delle proprieta ACID richieste dalle transazioni denite nel processo di business. Inoltre in questa fase devono essere raccolte le informazioni necessarie circa i requisiti minimi di risorse che il sistema BPMS richiede per la sua esecuzione. Una volta terminata la congurazione, limplementazione del processo di business deve essere testata. A livello di processo, vengono eettuati dei test di integrazione o di performance che sono importanti per individuare potenziali problemi a tempo di esecuzione del processo.

Attivazione Terminata la fase di congurazione, le istanze dei processi di business possono essere attivate. La fase di attivazione del processo riguarda tutti gli aspetti coinvolti nellesecuzione del processo. Allinizio della fase di attivazione, le istanze dei processi di business vengono inizializzate in modo da soddisfare i requisiti di business di unorganizzazione. Liniziazione di unistanza di un processo tipicamente segue un determianto evento (ad esempio il ricevimento di un ordine spedito da un cliente). Un sistema BPM deve essere in grado di controllare attivamente lesecuzione delle istanze e fornire meccanismi per lorchestrazione di queste istanze, in modo da garantire che le attività di processo vengono eseguiti secondo i vincoli di esecuzione spec-Icati nel modello di processo. Un altro componente importanti del BPMS di questa fase è quello che permette il monitoraggio per visualizzare lo sta- to delle istanze dei processi di business. Il monitoraggio del processo è un meccanismo importante per fornire informazioni accurate sullo stato delle esecuzioni. Il BPMS deve essere in grado di raccogliere i dati signicativi sullesecuzione delle istanze di business, tipicamente sottoforma di le di log. Questi le di log consistono di insiemi ordinati di record che indicano eventi che sono accaduti durante le varie esecuzioni. Queste informazioni sono la base per valutare i processi nella fase di analisi.

Analisi La fase di analisi utilizza le informazioni disponibili per valutare e migliorare i modelli dei processi di business e le loro implementazioni. I BPMS utilizzano i le di log raccolti nella fase precedente per valutarli utilizzando sistemi quali i business activity monitoring e i business cockpit. Questi ultimi utilizzano tecniche di data mining per cercare di identicare la qualità di un modello di processo di business e il grado di adeguatezza rispet- to lambiente di esecuzione. Il business activity monitoring (BAM) serve a identicare quali attività del processo di business ad esempio consumano piu` risorse oppure non sono state completate in base ai vincoli previsti dal modello di processo di business. Queste analisi vengono eettuate a tempo di esecuzione in modo da intervenire direttamente sullistanza del processo. Il business cockpit,invece, si occupa di analizzare i dati raccolti a posteriori rispetto lesecuzione del processo. Lo scopo di questo strumento è quello di mettere in relazione i vari dati prodotti da varie istanze dello stesso processo di business in modo da identicare quelle parti del modello che devono essere migliorate.

Capitolo 3

Standard degli StrumentiBPM

In questo capitolo verranno illustrati gli standard applicabili agli strumenti BPM. Come vedremo, questi possono essere di tre tipologie: standard graci di modellazione, standard per i formati di interscambio dei modelli dei processi di business e standard di esecuzione dei processi di business. La conformità agli standard è una caratteristica chiave di ogni strumento BPM, in quanto gli consente di poter interagire con altri strumenti BPM in un linguaggio che sia comune ad entrambi. Inoltre limportanza di avere degli standard ben deniti permette di dare uniformità alla rappresentazione di un processo di business e di unicare le molteplici soluzioni descrittive già esistenti. Tra le proposte di standard che citeremo, tratteremo in maniera piu` approfondita gli standard che vengono presi in considerazione ai ni del nostro studio di analisi: BPMN, XPDL, BPEL4WS, BPEL4PEOPLE.3.1 Standard graci per la modellazione

Gli standard graci permettono agli utenti di esprimere sotto forma di diagramma il usso informativo, i punti di decisione e i ruoli dei processi di business. Rispetto alle altre tipologie di standard, gli standard graci sono quelli piu` human-readable e facili da comprendere senza che siano necessarie conoscenze tecniche speciche. Tra gli standard piu` importanti troviamo: Business Process Management Notation (BPMN) Activity Diagram UML Event-driven Process Chain (EPC)

Tra questi standard graci, Business Process Management Notation è lo standard scelto ai ni della nostra analisi in quanto attualmente lo standard di modellazione piu` utilizzato tra i vari produttori di strumenti BPM. Business Process Management Notation sarà loggetto del paragrafo 3.1.1. Vediamo ora brevemente gli altri due standard graci citati.

3.1.1 Notazione BPMN

Business Process Model and Notation, BPMN, è una notazione di modellazione per processi di business denito dallobject Management Group (OMG), che mira a diventare uno standard de facto tra i vari standard graci di modellazione di processi di business. La notazione nasce dallesi- genza di creare un linguaggio di modellazione che fosse in grado di eliminare il gap tecnico esistente tra le descrizioni dei processi di business per mezzo di diagrammi di usso e le descrizioni di questultime in un linguaggio di esecuzione (paragrafo 3.3). Per mezzo di questa notazione è infatti possibile mappare la descrizione visuale di un processo di business, descritta direttamente dagli analisti di business, nel linguaggio di esecuzione appropriato [28].La modellazione del processo di business viene utilizzata per comunicareUna vasta variet

Di informazioni ad un altrettanto vasto insieme di entità.Per questo motivo BPMN è stato ideato in modo da creare diverse tipologie di modelli di business end to end. Secondo OMG, questi processi possono essere classicati come:1. Processi privati (interni)2. Processi pubblici (pubblici)3. Processi di collaborazione (globali)

I processi privati sono i processi interni a speciche organizzazioni e sono quei tipi di processi che vengono deniti workow. Se vengono utilizzate le

Figura 3.6: Esempio di processo EPCSwimlanes per la loro rappresentazione allora il usso di sequenza (sequence ow) del processo privato è contenuto allinterno di un singolo pool e nonPu attraversare i conni di questo pool. Tuttavia è possibile un interazioneTra processi privati di business utilizzando il usso di messaggi (message ow). La gura 4.3 mostra un esempio di processo di business privato.

Figura 3.7: Esempio di processo privato descritto in BPMN tratto da [28]

I processi astratti rappresentano le interazioni tra i processi di business privati e altri processi o partecipanti. Solo quelle attività che vengono utilizzate allinfuori dei processi di business privati con i meccanismi di controllo di usso appropriati vengono incluse nei processi astratti. Tutte le altre at- tività interne dei processi di business privati non vengono incluse nei processi astratti. Per questo motivo un processo astratto mostra al mondo esterno la sequenza di messaggi che sono richiesti per interagire con quel processo di business. I processi astratti sono contenuti allinterno di un pool e possono essere modellizzati separatamente o allinterno di un diagramma BPMN piu`Grande per mostrare il usso di messaggi tra le attivit

Dei processi astrattiE le altre entità. Se il processo astratto è nello stesso diagramma del suoCorrispondente processo privato allora le attivita`

Che sono in comune adEntrambi i processi possono essere associate. La gura 4.4 un esempio di processo astratto con notazione BPMN.

Figura 3.8: Esempio di processo astratto descritto in BPMN tratto da [28]

Tit

Un processo di collaborazione ragura le interazioni tra due o piu` en-Di business. Queste interazioni vengono denite come una sequenza diAttività che rappresentano le modalità di scambio di messaggi tra le entità coinvolte. Il processo di collaborazione può essere mostrato come due o piu` processi astratti comunicanti tra di loro. Allinterno di un processo astratto, le attività per i partecipanti che collaborano tra loro possono essere considerate come i punti di contatto tra i partecipanti. I processi eseguibiliDi collaborazione hanno molte piu`

Attivit

E dettagli rispetto ai processiAstratti come è possibile vedere in gura 4.5.Un diagramma BPMN (chiamato diagramma BPD) pu

Essere modelliz-Zato rispetto a dierenti punti di vista dei partecipanti del processo. Infatti ogni processo di business contiene due o piu` attori, i quali possiedono dierenti punti di vista a secondo di come vengono coinvolti allinterno del pro-Cesso. Alcune attivit

Potranno essere interne rispetto ad un partecipanteMentre altre potrebbero risultare esterne a quel particolare partecipante. Questa dierenze di punti di vista delle attivita` risulta importante a tempo di esecuzione del processo, in quanto permette al partecipante di monitorareLo stato delle sue attivit

Anche se di fatto il diagramma rimane lo stesso perTutti i partecipanti. In gura 4.5 infatti il processo di business presenta due punti di vista: uno del paziente e laltro dellucio del dottore. In questo diagramma vengono mostrate le attivita di entrambi i partecipanti al processo ma, quando il processo viene posto in esecuzione, ogni partecipanteAvrà il controllo solo delle attivit

Che lo riguardano direttamente. Lobiet-Tivo del Open Management Group è quello di creare una notazione semplice e facilmente adottabile dagli analisti di business. Inoltre questa notazione deve essere in grado di gestire contemporaneamente la ragurazione di processi di business complessi e il loro mapping verso i linguaggi di esecuzione BPM. Per vedere come BPMN risolve entrambi i problemi descriveremo le componenti grache di un diagramma BPMN sfruttando la divisione in due gruppi suggerita da OMG. Il primo gruppo contiene gli elementi di base della notazione con i quali è possibile creare dei modelli della maggior parte dei processi di business. Il secondo gruppo, oltre a contenere gli elementi del primo, contiene inoltre una serie di formalismi graci che consistono di risolvere situazioni di modellazione complesse.Il primo gruppo degli elementi di base della notazione contiene 11 formalismi graci per mezzo dei quali è possibile descrivere la maggior parte dei processi di business. Questi formalismi graci sono divisi in 4 categorie:

1. Oggetti di usso (Flow Objects)2. Oggetti di connessione (Connecting Objects)3. Swimlanes

Figura 3.9: Esempio di processo di collaborazione descritto in BPMN tratto da [28]4. Artefatti (Artifacts)In particolare gli oggetti di usso sono divisi in: Eventi Attivita` GatewaysGli oggetti di connessione in: Flusso di sequenza (Sequence Flow) Flusso di messaggio (Message Flow) Associazione (Association) Le swimlanes si dividono in Pools Lanes

Inne gli artefatti, che vengono utilizzati per fornire informazioni ulteriori circa il processo, sono: Oggetto di dati (Data Object) Gruppo (Group) Annotazione (Annotation)Vediamo questi oggetti graci in particolare.

Evento Un evento è qualcosa che accade durante il corso del processo di business. Questi eventi inuiscono sullesito del usso del processo e solitamente sono caratterizzati da una causa (trigger) e da un eetto (result). Vengono rappresentati per mezzo di un cerchio e ne esistono tre di base: gli eventi di inizio, intermedi al processo e di ne (gura 4.6).

Attività Attivita è un termine generico per indicare il lavoro che svolgeUn qualche entità. Unattività pu

Essere atomica o composta. I tipi diAttività che fanno parte del modello di processo sono tre: il processo, il sottoprocesso e il task. I task e i sotto-processi sono rappresentati con un rettangolo arrotondato mentre i processi sono contenuti nei pool (gura 4.7).

Figura 3.10: Evento BPMN

Figura 3.11: Attività BPMNGateway Un gateway viene utilizzato per controllare la divergenza eLa convergenza di un usso di sequenza. Quindi determiner

Le operazioniDi branching, di forking, di merging e di joining dei vari percorsi di usso. Viene rappresentato come un rombo (gura 3.12).

Figura 3.12: Gateway BPMN

Flusso di sequenza Un usso di sequenza viene utilizzato per mostrare lordine con cui vengono eseguite le attività allinterno del processo (gura3.13).

Figura 3.13: Flusso di sequenza BPMN

Flusso di messaggio Un usso di messaggio viene utilizzato per mostrare il usso di messaggi tra due partecipanti che sono preparati a spedirli e a riceverli (gura 3.14).

Figura 3.14: Flusso di messaggio BPMN

Associazione Unassociazione viene utilizzata per associare informazione con gli oggetti di usso. Oggetti testuali e graci non di usso possono essere associati con quelli di usso. Unassociazione puo` avere una direzione perIndicare il destinatario delle informazioni che trasporta se opportuno (gura3.15).

Figura 3.15: Associazione BPMN

Pool Un pool rappresenta un partecipante in un processo. Inoltre serve anche da contenitore graco per partizionare un insieme di attività da altri pool (gura 3.16).

Figura 3.16: Pool BPMN

Lane Un lane rappresenta una sotto-partizione allinterno del pool che si estende per lintera lunghezza del pool sia in orizzontale che in verticale. Viene utilizzato per organizzare e categorizzare le attività (gura 3.17).

Figura 3.17: Lane BPMN

Oggetto di dati Un oggetto di dati non ha alcun eetto sul usso di sequenza o di messaggio ma fornisce informazioni circa quelle attivita che richiedono di essere eseguite oppure cosa essere producono (gura 3.18).

Figura 3.18: Oggetto di dati BPMN

Gruppo Un gruppo rappresenta un insieme di attivita` appartenenti ad una singola categoria. Questo tipo di gruppo non inuisce sul usso di sequenza delle attività allinterno del gruppo. Dato che le categorie possono essere utilizzate per scopi di documentazione o di analisi, i gruppi rappresentano lunico modo per visualizzarle allinterno del diagramma (gura 3.19).

Figura 3.19: Gruppo BPMN

Annotazione Le annotazioni testuali sono un meccanismo per il mod- ellista per fornire ulteriori informazioni a chi leggere il diagramma BPD (gura 3.20).Con questi elementi è possibile descrivere la maggior parte dei processi di business. Se volessimo dettagliare ulteriormente il diagramma con delle speciche del processo di business, questo richiederebbe lutilizzo diUna notazione piu`

Avanzata che BPMN prevede. Mostriamo gli elemen-Ti piu`

Importanti per la notazione avanzata. Per un quadro completo siConsiglia[28].

Figura 3.20: Annotazione BPMN

Tipologia di eventi Gli eventi possono avere una dimensione di usso e una dimensione riguardante la loro tipologia. Per quanto riguarda la prima dimensione essi si dividono in (gura 3.21):

Eventi di inizio: indicano che un particolare processo ha inizio. Ven- gono rappresentati con un cerchio.

Eventi intermedi: inuiscono sullandamento del usso di processo ma non iniziano ne terminano il processo. Vengono rappresentati con un doppio cerchio.

Eventi di ne: indicano la terminazione di un processo. Vengo rappresentati con un cerchio il cui bordo è in grassetto.

Figura 3.21: Dimensione di usso degli eventi BPMN

Per quanto riguarda la loro tipologia essi possono essere di tipo catching se reagiscono a un qualche trigger che li metta in esecuzione oppure possono essere di tipo throwing se creano un qualche risultato. Ogni tipo di eventoè indicato da un simbolo che ne identica la funzione. Gli eventi di catching vengono indicati con il simbolo non riempito mentre quelli di throwing con il simbolo riempito. La gura 3.22 mostra le varie tipologie di eventi. In particolare:

eventi di tipo message: indicano che un messaggio è arrivato da parte di un partecipante oppure è il risultato dellevento eventi di tipo timer: sono solo di tipo catching e rimangono in ascolto di un trigger temporale che decide il momento della loro esecuzione

eventi di tipo error: indicano che si è vericato un errore allinterno del usso di processo. Possono essere solo intermedi o di ne

eventi di tipo cancel: vengono utilizzati per annullare gli eetti di una transazione di business denita allinterno di un sotto-processo

eventi di tipo compensation: vengono utilizzati per la gestione delle eccezioni che possono vericarsi allinterno di un processo e servono per eettuare compensazione

eventi di tipo conditional: questi eventi si attivano quando una condizione diventa vera

eventi di tipo link: rappresentano un meccanismo grazie al quale è possibile collegare due sezioni di un processo. Vengono utilizzati per creare situazioni cicliche oppure per evitare lunghe sequenze di usso

eventi di tipo signal: viene inviato un segnale allinterno del processo che viene diuso in modalità broadcast a tutti i partecipanti a dierenza dei messaggi che hanno una sorgente e un destinatario deniti eventi di tipo terminate: vengono utilizzati per terminare immedi-Atamente tutte le attivit

Allinterno di un processo

eventi di tipo multiple: indicano lesistenza di molteplici triggerRiguardanti levento.

Tipologia di attività Le attività si dividono in: task, processo o sotto-processo. In particolare:

un task rappresenta ununit

Atomica di attività che è inclusa al-Linterno di un processo. Viene utilizzato quando lattività non èUlteriormente decomponibile (gura 3.23). un sotto-processo è unattività composta che viene inclusa allinternoDi un processo. Gracamente pu

Essere visualizzata completamente(gura 3.25) oppure viene visualizzata in modalit

collassata (gura3.24) con il simbolo + che sta ad indicare questa tipologia.

Figura 3.22: Tipologie degli eventi BPMN

Figura 3.23: Attività atomica BPMN

Figura 3.24: Sotto-processo collassato BPMN

Figura 3.25: Sotto-processo esteso BPMNTipologie di gateway Come è possibile notare in gura 3.26, esistono diverse tipologie di gateway. In particolare: Gateway esclusivi: deniscono una scelta da fare nel usso di processo.Questa scelta pu

Essere basata su dati oppure su evento.

Gateway inclusivi: deniscono una o piu` scelte che vengono prese nelusso di processo. La scelta di un percorso nel usso di processo nonEsclude le altre.

Gateway complessi: sono stati deniti per trattare quelle situazioni che non è possibile arontare con gli altri tipi di gateway. Ad esempio lunione di piu` gateway.

Gateway paralleli: deniscono lesecuzione di piu` attivit

Figura 3.26: Tipologie di gateway BPMN

In parallelo.

Tipologie di ussi di sequenza La notazione BPMN denisce di-Versi ussi di sequenza del processo di business. Abbiamo già descritto dueTipologie di ussi di sequenza: il usso normale e il usso di messaggio. OltreA queste due tipologie ne esistono altre:

Flusso di default: viene utilizzato nelle decisioni di usso di processo, sia inclusive che esclusive, e stabilisce quale sia la condizione di usso diDefault. Il suo simbolo è caratterizzato dallavere uno slash diagonale allinizio della linea (gura 3.27).

Flusso di eccezione: viene utilizzato per denire le deviazioni del usso di processo rispetto al usso normale. Queste eccezioni dal normale usso di processo vengono attivate mediante lutilizzo di un evento intermedio (gura 3.28).

Flusso condizionale: è un usso di sequenza avente un espressione condizionale che viene valutata a runtime per determinare quale usso dovrà seguire il processo (gura 3.29).

Figura 3.27: Flusso di default BPMN

Figura 3.28: Flusso di eccezione BPMN

Figura 3.29: Flusso condizionale BPMN

Transazioni La notazione permette di denire parti del processo come transazioni. Nella notazione BPMN una transazione è un sotto-processo che contiene un usso di processo che è sottoposto ai meccanismi di gestione delleTransazioni. Nella notazione BPMN una transazione viene rappresentata con doppio riquadro come mostra la gura 3.30. Per gestire il fallimento di una transazione, BPMN permette di modellizzare il meccanismo di compensazione (gura 3.31). Questo permette al usso di processo interno ad una transazione di deviare dal usso normale in modo tale da rendere consistente il risultato della transazione.

Figura 3.30: Transazione BPMN

Figura 3.31: Compensazione BPMN

Capitolo 4

Analisi BIZAGI BPM

Il capitolo descrive lobiettivo dellanalisi oggetto della presente tesi, la metodologia proposta e i criteri di selezione degli strumenti BPM BIZAGI che saranno in seguito analizzati.

Documents

II Parte Da Unire