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 al- tre, in modo tale che esse accadano nel giusto
momento e nel giusto ordine. Linput di questo processo di business `e la richiesta del cliente e loutput `e
il contratto rmato della polizza assicurativa
Fattori come la globalizzazione, le opportunit
Di e-business, linstabilit`a
Politica porta ad un mercato caratterizzato da incertezza nel quale unorga- nizzazione 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 completamente
Le modalit
Operative di unorganizzazione. Il secondo tipo di cambiamento
`e invece piu` graduale e permette unadattamento delle modalit`a 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 `e un metodo che facilita la gestione dei cambiamenti
che deve arontare unorganizzazione. In particolare, il Busi- ness Process Management (BPM) `e una
disciplina gestionale che si occupa di descrivere e gestire i processi di business in un organizzazione.
Lobiet- tivo del Business Process Management `e 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 Business
Process 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 informa- tivi sono composti da diversi livelli. Il centro `e 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 liv- ello
consiste di applicazioni speciche del dominio di applicazione. Queste applicazioni vengono usate
solamente entro speciche tipologie di organiz- zazioni. 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`a delle applicazioni speciche del dominio e della singola orGanizzazione aument`o. Questo fatto fu dovuto alla necessit
Di supportare

Figura 1.1: Livelli di un sistema informativo

Piu` tipi di attivit`a 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`o dal programmare le applicazioni alintegrare le
applicazioni esistenti. Nel corso degli anni 70 e 80 i sistemi informa- tivi
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`a 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 appli- cazioni esistenti
considerandole come una sequenza di attivit`a. Il trend dei
Sistemi informativi pass
Da essere orientato ai dati ad essere orientato ai
Processi. 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 proces- si 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`a sul mercato per lorganizzazione. In- fatti
permettono sia di gestire attivita` che devono essere svolte da agenti umani sia
di automatizzare completamente altre attivit`a, aumentando cos` lecienza di
un processo di business. Essi sono composti da diversi stru- menti che
permettono un completo supporto al BPM. Per questo motivo sono anche deniti
BPM suite [16]. Obiettivo primario dei BPMS `e gestire un processo di business.
Un processo di business pu`o essere visto come uno

O piu` workow che collaborano tra di loro al ne di raggiungere un obiet- tivo

comune. Un workow `e lautomazione di una sequenza di attivita`. Il concetto
di workow viene denito dal Workow Management Coalition. Il wfmc `e 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 stan- dard XPDL che `e 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 `e 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 `e il consorzio OASIS (Organization for the Advancement of
Structured Information Standards) che ha denito lo standard BPEL (Business
Process Execution Language). BPEL `e uno standard di esecuzione che permette
al processo di business di essere eseguito indierentemente su tutti gli strumenti
BPM che support- ano questo standard. Ladozione di questi standard da parte
degli strumenti BPM `e importante dal punto di vista dellinteroperabilita. Oltre
agli stru- menti che devono supportare gli standard descritti, un sistema BPM
deve presentare uno strumento che metta in esecuzione il processo di business
de- scritto. Questo strumento `e il BPM engine che permette di assegnare leseCuzione di unattivit
Del workow ad uno specica risorsa. Una volta che
Il processo di business `e 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 `e 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 `e 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 superamento di questo gap permette di fornire le basi tecniche per la creazione
Rapida di nuove funzionalit
Che portano alla realizzazione di nuovi
prodotti
Permettendo quindi alla compagnia di essere sempre competitiva sul mer- cato.
Strumento chiave anche questo sia possibile `e considerare queste attivit`a
tutte appartenenti ad uno o piu` processi di business. Per questo motivo
possiamo denire un processo di business come un insieme di at- tivit`a eseguite
in coordinazione con lambiente organizzativo e tecnico che permette di dare
loro unorganizzazione e aumentare la comprensione delle loro relazioni.
Queste attivit`a 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 dier- enti
livelli che caratterizzano un processo di business (gura 2.1). Al livello
Piu`
In alto un processo di business serve per descrivere la strategia della
Compagnia, 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`a 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`e 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 informati- ci che
hanno nella descrizione e nella esecuzione dei processi di business operativi.
Un altro tipo di classicazione riguarda il grado di relazione che un pro- cesso 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`a 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 tradizion- ali 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 pro- cessi di
business. Vedremo nel paragrafo 2.2.3 un paradigma architetturale adatto a
questo scopo (SOA).
Un altro tipo di classicazione
Essere fatto sulla base del loro grado
Di:
pu
automazione
ripetizione
strutturazione
Per quanto riguarda il grado di automazione esistono processi di business che
non richiedono lintervento umano. In questo caso si parla di proces- si di
business pienamente automatizzati. Un esempio sono le tecnologie EAI
(Enterprise Application Integration) il cui compito `e quello di integrare

Figura 2.1: Livelli dei processi di business: dalla strategia di business ai

processi di business implementati

Sistemi informatici eterogenei rendendo questa integrazione trasparente allintervento 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`a di tipo manuale sia attivit`a di tipo automatiche.
Quindi sono state sviluppate delle tecnologie che permettono di gestire e
sincronizzare entrambi i tipi di attivit`a.
Rispetto al grado di ripetizione `e possibile valutare quale tipo di tec- nologia `e
piu` adatta a supportare un determinato processo di business. Nei processi di
business dove il grado di ripetizione `e alto sono richieste tecnolo- gie 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`a. Questi processi vengono deniti processi di busi- ness collaborativi.
In questi processi lutilizzo delle tecnologie di supporto non ha come obiettivo
quello di ottimizzare lecienza ma quello di moni- torare 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 procesSo di business il cui modello descrive perfettamente le sue attivit
I vincoli
Tra 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`a ad hoc, un processo che non necessita di
essere denito completamente in quanto deve dare una certa
essibilit
Alloperatore umano di poter gestire parti del processo in base
Alla sue competenze. Quindi questi processi sono caratterizzati da un basso
livello di strutturazione e da un alto livello di essibilit`a. 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`o essere considerato come un processo che
Non pu
Essere diviso ulteriormente e che viene svolto nel suo insieme da
Una risorsa (resource). Chiamiamo attivita lesecuzione di un task da parte
di una risorsa. Una risorsa `e il nome generico che viene assegnato ad una
persona, macchina o gruppo di persone e macchine che possono eseguire attivit`a
speciche. Ci`o non signica che una risorsa necessariamente debba
Portare a termina lattivit
Per la quale `e stata assegnata. Tuttavia con il
Suo assegnamento essa diventa responsabile dellesito di tale attivit`a. Due o
piu` task che devono essere eseguiti seguendo un determinato ordine sono
chiamati sequenza. Quando `e 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 `e chiamato sincronizzazione.
E` possibile ripetere lesecuzione di piu` task durante lesecuzione di un proCesso. Questa operazione `e chiamata iterazione. Ricapitolando possiamo
Identicare quattro meccanismi di base nella struttura di un usso di un
Processo:
sequenza
selezione
parallelizzazione
iterazione
`e 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`a 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 Management (par. 2.2.1). Poi presenta il concetto di workow (par. Subsec:Workow), i modelli che lo deniscono e larchitettura dei sistemi che
Lo 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 `e 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 work- ow e
la reingegnerizzazione dei processi di business [34]. Esistono diverse denizioni
di Business Process Management. Secondo Horak [10], il Business Process
Management `e
Business Process Management (BPM) `e un approccio sistem- atico e strutturato
per analizzare, migliorare, controllare e gestire
I processi di business con lo scopo di migliorare la qualita dei prodotti e dei
servizi.
Unaltra denizione di BPM `e quella data da Weske [43]:
Un BPM `e un sistema il cui scopo `e quello di supportare
I processi di business utilizzando metodi, tecniche e software
Per progettare, mettere in esecuzione, controllare e analizzare
I processi operativi che coinvolgono esseri umani, organizzazioni,
Applicazioni, documenti e altre fonti di informazione.
Lultima denizione che citeremo `e quella data da Gartner [15]:
Un sistema BPM `e un sistema composto da servizi e stru- menti che supportano
in modo esplicito la gestione del proces- so di business (analisi, denizione,
esecuzione, monitoraggio e amministrazione).
Dallunione delle tre denizioni di Business Process Management `e pos- sibile
ricavarne una che descrive in modo completo un sistema BPM:
Business Process Management `e una disciplina gestionale che utilizza un
approccio sistematico e strutturato con il ne di supportare la gestione esplicita
di un processo di business uti- lizzando metodi, tecniche e strumenti, che
coinvolgono esseri umani, organizzazioni, applicazioni, documenti e altre fonti
di informazione, con lo scopo di raggiungere gli obiettivi di busi- ness
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 `e 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`e si possa raggiungere un obiettivo comune, utilizzando un in- sieme
predenito di regole. Un workow pu`o essere visto come un com- ponente di
un processo di business, in quanto consiste in una sequenza di attivit`a 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 organizzativo
Per descrivere i tre modelli verranno utilizzati due modelli per descrivere
I workow: quello del Workow Management Coalition [18] e il modello
WIDE (Workow on Intelligent and Distributed database Environment) [5].
Di seguito la descrizione dei tre modelli. Lutilizzo di questi due modelli
E della loro terminologia non fa perdere di generalit`a la descrizione dei tre
Modelli 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 `e denito come la rappresentazione formale di un
processo di business in modo tale che la sua manipolazione sia pos- sibile per
mezzo di un workow management system (wfms). Questo

`e composto da un insieme di attivita, da relazioni tra queste attiv- ita. Da criteri di

inizio e terminazione del processo e da informazioni circa le singole attivit`a, i
partecipanti, i documenti e i dati relativi, applicazioni software richieste.
Partecipante di WF: un partecipante di un workow `e una risor- sa che esegue il
lavoro associato ad una particolare istanza di task. Il lavoro viene generalmente si
riferisce ad un elemento di task conTenuto allinterno della work list del partecipante. Questo pu
Essere
Una 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`o anche essere assegnata ad un gruppo di agenti (lista
condivisa). La work list `e 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`a 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`a: un insieme di attivit`a contenute della denizione
Di processo che condividono una o piu`
Propriet`a che permettono al
Workow management software di svolgere alcune azioni rispetto a questo
gruppo. Ad ogni singola attivit`a viene assegnato uno stato.
Deadline: un vincolo di schedulazione temporale che richiede che una
Certa attivit
Venga completata in un certo intervallo di tempo.
Instradamento (Routing): `e come vengono connesse tra loro i
Diversi blocchi di attivita. Sono possibili due tipi di instradamento:
Sequenziale: le attivit`a 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`a vengono eseguite in par- allelo
allinterno del workow, dando origine a thread multipli di
Controllo. Le attivit
Possono essere attivate in parallelo (AND)
Oppure pu`o essere scelto una o piu` attivita`
Da eseguire contemPoraneamente (OR). Quando da unattivit
parte lesecuzione
Coordinata di piu`
Attivi Si parla di attivazione parallela .
t
Quando invece da piu`
Attivi Si torna ad una solo si parla di
t
sincronizzazione. Nelle gure da 2.3 a 2.6 i quattro possibili casi.
Ciclo: ripetizione di una stessa attivit`a o di una sequenza di attivit`a nch`e
non viene soddisfatta una determinata condizione.
Pre-post condizioni: una pre-condizione `e unespressione logica che viene
valutata dal workow engine per decidere se iniziare unistanza di un particolare
processo. In modo opposto una post-condizione `e une- spressione logica che
viene valutata dal workow engine per decidere unistanza di un particolare
processo pu`o 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 `a da eseguire in parallelo

Figura 2.4: Sincronizzazione parallela di tutte le attivit `a

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

Figura 2.6: Sincronizzazione parallela di tutte le attivit `a attivate dalle

condizione

Modello 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 `e dominato da un usso di informazioni, oggetti, da logiche di
controllo e cos` via, cio`e 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 tran- sizioni,
rappresentati da rettangoli. Le reti di Petri sono un grafo bipartito cio`e linsieme
dei suoi vertici si pu`o partizionare in due sottoinsiemi tali che ogni vertice di
una di queste due parti `e 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 `e 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`a permette di circoscrivere lazione della con- dizione 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 posto

Inuenza solo le transizioni poste nelle immediate vicinanze del posto, e pu`o
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 `e possibile distinguere
I vari token gli uni dagli altri. Questo fatto limita i token ad avere tutTi la stessa semantica. Poi questo modello non `e in grado di descrivere i
Vari aspetti temporali del usso di processo: infatti esiste un unico aspetTo temporale espresso dallordine degli archi. Inoltre questo modello tende
A crescere velocemente di dimensione rendendo la sua gestione complessa.
Per superare questi limiti `e stato denito un modello piu` avanzato delle reti
Di Petri: le reti di Petri ad alto livello. Queste permettono permettono di
Superare le limitazioni del modello classico introducendo tre estensioni:

1. Reti di Petri colorate

2. Estensione temporale
3. Supporto alla gerarchia
In particolare, le reti di Petri colorate permettono di assegnare ai vari to- ken 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 rappre- senta listante di
tempo durante il quale il token pu`o essere utilizzato dalla transizione. Con
questa estensione `e possibile introdurre il concetto di ritar- do nellesecuzione
del usso del processo. Inne il supporto alla gerarchia
Permette di ridurre la complessit
Delle reti di Petri aumentando il grado
Di leggibilit
Del processo descritto. Il supporto alla gerarchia introduce il
Concetto di sotto-processo che `e 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`o 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 assumere
I 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`o

indicare il raggiungimento di una condizione
Un posto pu`o 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 dellorganiz- zazione;
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`o 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 quando
I 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 lese- cuzione
di un task.
Tempo (Time): il task viene attivato per mezzo di un evento tempo- rale.

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 pro- cessi 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, modicate 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 che
Hanno visibilit
Solo allinterno della particolare istanza del workow. Le
Istanze 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 viaggio

Variabili 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 modicate 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 con- divisi. I
wfms possono generare automaticamente queste form ai partire dai campi di
dati.
Oltre alle modalit`a 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 questo
Tipo di informazione pu
Essere utilizzata per molteplici scopi: un utilizZo tipico, ad esempio, `e 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 `e
trascorso da un altro evento.

 condizioni temporali periodiche: servono per vericare se delle con- dizioni

temporali periodiche vengono soddisfatte da un certo istante di tempo.
Esempi di utilizzo delle informazioni temporali `e 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 organizzativo
Il 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`a
del processo di workow.
Sfruttiamo il modello WIDE [5] per descrivere le caratteristiche di un mod- ello
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 workow viene chiamato agente. Con lentit
Agente possono essere descritte
ulteriori sotto-entit`a:
Attore (Actor): `e una risorsa di esecuzione individuale. Pu`o essere
Umano oppure un agente software. Un Attore pu
Essere specicato
Utilizzando diversi attributi tra cui la sua disponibilit`a.
Gruppo (Group): `e un insieme di attori che possiedono comuni carat- teristiche
(ad esempio appartengono tutti ad una particolare unita` dellorganizzazione).
Funzione di organizzazione (Organization function): descrive una fun- zione
che pu`o essere eseguita da un gruppo o da un attore individuale. Viene
assegnato un attibuto di tipo capacit`a 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`e 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`e la necessit`a 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 `e una descrizione generica delle entita` a cui `e 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`e linsieme di ruoli che possono essere eseguiti da quel particolare
partecipante. Inoltre `e 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 work- ow,
in termini di schemi di workow;
2. Lamministratore del workow: `e incaricato alla gestione del workow.
Denisce la struttura di una specica organizzazione e gli attori che
Partecipano allesecuzione di un processo di workow.
Dal punto di vista dellesecuzione del workow esistono i seguenti tre ruoli:
1. Lesecutore dellistanza di workow: `e lagente che inizia il caso di
workow;
2. Il responsabile dellistanza di workow: lagente che ha la responsAbilit
nale sul risultato dellistanza di workow;

3. Lesecutore del task: lagente che sta eseguendo un task.

Grazie al modello organizzativo appena descritto, un wfms `e in grado di
assegnare task ai vari partecipanti del workow in fase di esecuzione.
Questo assegnamento pu
Essere eettuato sia mediante uno scheduler,
dove
Lengine 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`a e dei casi critici). La
necessita` di entrambe le modalit`a 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 `e 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 `e responsabile delattuazione dei processi di work- ow.
Esso in particolare permette la creazione e lattuazione di unis- tanza di
workow quando questa viene richiesta.
Il workow engine si comporta diversamente in base alla tipologia di work- ow
che deve istanziare. Nel caso di workow di sistema esso manda avanti il usso
di workow secondo quanto `e stato denito nel modello di work- ow,
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 utilizzando
Una Graphical User Interface. Inoltre la conoscenza delle abilit
E delle
comPetenze 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 `e un modello generico di architettura dei wfms.
Una descrizione piu` completa `e stata fornita dalla Workow Man- agement
Coalition, la quale descrizione `e 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 `e 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 `e possibile modellare i processi. Esso `e connesso al Workow Enactment
Service per mezzo dellinterfaccia 1. Lobiettivo di tale interfac- cia `e 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 chiamato
XPDL, XML Process Denition Language. Deniremo piu`
Avanti questo
Tipo 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 `e quello di permettere la comunicazione delle applicazioni client di vendors dierenti con il
Workow Enactment Service. Il sottosistema Invoked Applications rap- presenta
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`a 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 diver- si
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 `e stato implemen- tato
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 `e 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 work- ow.
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 `e totalmente indipendente dalla denizione del modello di processo in quanto non sussiste alcun
collegamento tra i due. Questa situazione porta a non poter cam- biare la
struttura di unistanza di un usso di workow mentre questa `e in esecuzione
facendo delle modiche sul modello del processo stesso. Per questultima
esigenza sono stati teorizzati dei sistemi di workow essibil- i. Come `e
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`e
sia possibile adattare dinamicamente un workow in esecuzione `e che il
workow in esecuzione sia coerente con il workow modicato (relazione di
continuit`a).
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 implementare 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 busi- ness 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
utilizzano
Per interagire con i modelli eseguibili del processo di business
gestire le funzionalit`a denite nel processo di business
Un modello di processo di business eseguibile pu`o essere tradotto in codice ed
essere eseguito da un engine di esecuzione del processo di busi- ness. Gli utenti
possono interagire con i processi di business in esecuzione

E 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 `e 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 cor- rispettive
metodologie e tecnologie che formano i componenti di un sistema di Business
Process Management (BPMS). Descriviamo ora queste fasi e le loro
corrispettive funzionalit`a.
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 descri- vere
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 `e possibile scoprire quelle sequenze di esecuzione che mostrano dei
bottleneck prestazionali durante la loro esecuzione e di veri- care la correttezza
del loro comportamento. La maggior parte dei sistemi BPM forniscono un
ambiente di simulazione che puo` essere usato in questa fase.
Congurazione
Una 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 neces- sarie che
facilitano lattivazione del processo nel BPMS. Il sistema BPM deve essere
congurato secondo lambiente organizzativo e in base ai pro- cessi 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 vol- ta terminata la congurazione,
limplementazione del processo di business deve essere testata. A livello di
processo, vengono eettuati dei test di in- tegrazione 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 mo- do
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`a di processo vengono eseguiti secondo i vincoli di esecuzione spec-

Icati nel modello di processo. Un altro componente importanti del BPMS di

questa fase `e quello che permette il monitoraggio per visualizzare lo sta- to delle
istanze dei processi di business. Il monitoraggio del processo `e 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`a 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`a 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 `e quello di mettere in relazione i vari dati prodotti
da varie istanze dello stesso proces- so di business in modo da identicare quelle
parti del modello che devono essere migliorate.

Capitolo 3

Standard degli Strumenti

BPM

In questo capitolo verranno illustrati gli standard applicabili agli strumen- ti

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`a agli
standard `e 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`a alla rappresentazione di un processo di business e di
unicare le molteplici soluzioni descrittive gi`a 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 `e lo
standard scelto ai ni della nostra analisi in quanto attualmente lo stan- dard di
modellazione piu` utilizzato tra i vari produttori di strumenti BPM. Business
Process Management Notation sar`a 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, `e 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 `e 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 comunicare
Una vasta variet
Di informazioni ad un altrettanto vasto insieme di entit`a.
Per questo motivo BPMN `e 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 EPC

Swimlanes per la loro rappresentazione allora il usso di sequenza (sequence

ow) del processo privato `e contenuto allinterno di un singolo pool e non
Pu attraversare i conni di questo pool. Tuttavia `e possibile un interazione
Tra 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`a che vengono utiliz- zate
allinfuori dei processi di business privati con i meccanismi di controllo di usso
appropriati vengono incluse nei processi astratti. Tutte le altre at- tivit`a 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 astratti
E le altre entit`a. Se il processo astratto `e nello stesso diagramma del suo
Corrispondente processo privato allora le attivita`
Che sono in comune ad
Entrambi 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` enDi business. Queste interazioni vengono denite come una sequenza di

Attivit`a che rappresentano le modalit`a di scambio di messaggi tra le entit`a

coinvolte. Il processo di collaborazione pu`o essere mostrato come due o piu`
processi astratti comunicanti tra di loro. Allinterno di un processo as- tratto, le
attivit`a per i partecipanti che collaborano tra loro possono essere considerate
come i punti di contatto tra i partecipanti. I processi eseguibili
Di collaborazione hanno molte piu`
Attivi E dettagli rispetto ai processi
t
Astratti come `e possibile vedere in gura 4.5.
Essere
Un diagramma BPMN (chiamato diagramma BPD) pu
modellizZato rispetto a dierenti punti di vista dei partecipanti del processo. Infatti ogni
processo di business contiene due o piu` attori, i quali possiedono dier- enti
punti di vista a secondo di come vengono coinvolti allinterno del proCesso. Alcune attivit
Potranno essere interne rispetto ad un partecipante
Mentre 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 monitorare
Lo stato delle sue attivit
Anche se di fatto il diagramma rimane lo stesso
per
Tutti 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 pro- cesso
ma, quando il processo viene posto in esecuzione, ogni partecipante
Avr`a il controllo solo delle attivit
Che lo riguardano direttamente. LobietTivo del Open Management Group `e 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 pro- cessi 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 `e 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 for- malismi
graci per mezzo dei quali `e 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`
Gateways
Gli 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 `e 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`a Attivita `e un termine generico per indicare il lavoro che svolge
Un qualche entit`a. Unattivit`a pu
Essere atomica o composta. I tipi di
Attivit`a 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`a BPMN

Gateway Un gateway viene utilizzato per controllare la divergenza e

La convergenza di un usso di sequenza. Quindi determiner
Le operazioni
Di 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`a allinterno del processo (gura
3.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 per

Indicare il destinatario delle informazioni che trasporta se opportuno (gura

3.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`a 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`a (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`a allinterno del gruppo. Dato che le categorie possono essere utilizzate
per scopi di documentazione o di analisi, i gruppi rappresen- tano 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 `e possibile descrivere la maggior parte dei proces- si di
business. Se volessimo dettagliare ulteriormente il diagramma con delle
speciche del processo di business, questo richiederebbe lutilizzo di
Una notazione piu`
Avanzata che BPMN prevede. Mostriamo gli elemenTi piu`
Importanti per la notazione avanzata. Per un quadro completo si
Consiglia[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 rapp- resentati
con un cerchio il cui bordo `e 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
`e 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 `e arrivato da parte di un
partecipante oppure `e 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 `e 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 `e 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 pro- cesso che
viene diuso in modalit`a 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 immediAtamente tutte le attivit
Allinterno di un processo
eventi di tipo multiple: indicano lesistenza di molteplici trigger
Riguardanti levento.
Tipologia di attivit`a Le attivit`a si dividono in: task, processo o sottoprocesso. In particolare:
un task rappresenta ununit
Atomica di attivit`a che `e inclusa alLinterno di un processo. Viene utilizzato quando lattivit`a non `e
Ulteriormente decomponibile (gura 3.23).
un sotto-processo `e unattivit`a composta che viene inclusa allinterno
Di un processo. Gracamente pu
Essere visualizzata
completamente
(gura 3.25) oppure viene visualizzata in modalit
collassata (gura
3.24) con il simbolo + che sta ad indicare questa tipologia.

Figura 3.22: Tipologie degli eventi BPMN

Figura 3.23: Attivit`a atomica BPMN

Figura 3.24: Sotto-processo collassato BPMN

Figura 3.25: Sotto-processo esteso BPMN

Tipologie di gateway Come `e 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 nel
usso di processo. La scelta di un percorso nel usso di processo non
Esclude le altre.
Gateway complessi: sono stati deniti per trattare quelle situazioni che non `e
possibile arontare con gli altri tipi di gateway. Ad esempio lunione di piu`
gateway.
Gateway paralleli: deniscono lesecuzione di piu` attivit
In parallelo.

Figura 3.26: Tipologie di gateway BPMN

Tipologie di ussi di sequenza La notazione BPMN denisce diVersi ussi di sequenza del processo di business. Abbiamo gi`a descritto due
Tipologie di ussi di sequenza: il usso normale e il usso di messaggio. Oltre
A 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 di

Default. Il suo simbolo `e 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: `e un usso di sequenza avente un espressione
condizionale che viene valutata a runtime per determinare quale usso dovr`a
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 `e un sotto-processo che
contiene un usso di processo che `e sottoposto ai meccanismi di gestione delle

Transazioni. 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 compen- sazione
(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.