Una metodologia di analisi e confronto per strumenti BPM

POLITECNICO DI MILANO
Facoltà di Ingegneria dell’Informazione
POLO REGIONALE DI COMO
Corso di Laurea Specialistica in
Ingegneria Informatica
Una metodologia di analisi e
confronto per strumenti BPM
Relatore: Prof. Giuseppe Pozzi
Correlatore: Prof. Marco Brambilla
Tesi di Laurea di: Vanoni Davide
matr. 707679
Anno Accademico 2008-2009

POLITECNICO DI MILANO
Facoltà di Ingegneria dell’Informazione
POLO REGIONALE DI COMO
Master of Science in
Computer Engineering
A methodology for analysis and
comparison for BPM tools
Supervisor: Prof. Giuseppe Pozzi
Assistant Supervisor: Prof. Marco Brambilla
Master Graduation Thesis by: Vanoni Davide
Student Id. number 707679
Academic Year 2008-2009

A Martina

Abstract
Business Process Management (BPM) aims at describing, managing, executing,
controlling, and storing business processes inside an organization,
helping the organization to achieve its mission-critical goals.
Even though many vendors supply BPM tools, there is no rigorous
methodology available today to evaluate and to compare such tools.
This thesis proposes an evaluation method for BPM tools. The method
derives from an extended version of the business process life cycle described
by van der Aalst. The extended version proposed here includes several facets
affecting the usability of the tool, the targeted users, its compliance with
BPM standards and recommendations (BPMN, X-PDL, BPEL).
This thesis considers several entries for every category of assessment of
the framework. The evaluation framework covers all the major aspects of
the BPM fields. After having defined the framework for the assessment, such
a framework is applied to different BPM tools. By applying the framework,
the thesis achieve two main goals: the first one is that of validating the
suitability of the assessment framework; the second one is that of taking a
snapshot of the current situation of the BPM toolsavailableonthemarket.
Finally the thesis shows the results of the analysis, by applying the proposed
methodology to the (52) most popular tools and then by considering
in detail some of them (21).

Sommario
Il Business Process Management è una disciplina il cui scopo è quello di
descrivere, gestire, eseguire e controllare i processi di business presenti all’interno
di un’organizzazione con il fine di aiutare l’organizzazione a perseguire
i propri obiettivi di business.
Sebbene numerosi produttori propongono le loro soluzioni BPM, non
esiste ad oggi una metodologia rigorosa per valutare e confrontare queste
soluzioni.
La tesi propone un metodo di valutazione per gli strumenti BPM. Il
metodo deriva dalla versione estesa del modello di ciclo di vita di un processo
di business descritto da van der Aaslt. La versione estesa proposta include
aspetti che riguardano l’usabilità dello strumento, gli utenti target a cui lo
strumento è rivolto, la sua conformità con gli standard e le raccomandazioni
BPM (BPMN, X-PDL, BPEL).
La tesi definisce diverse voci per ogni categoria del modello di valutazione
e analisi. Il metodo di valutazione copre tutti i maggiori aspetti di uno
strumento BPM. Dopo aver definito la metodologia di valutazione, questa
viene poi applicata a diversi strumenti BPM. Con l’applicazione pratica del
modello di valutazione proposto, la tesi raggiunge due principali obiettivi: il
primo è quello di valutare l’adeguatezza del modello di valutazione proposto;
il secondo è quello di catturare un’istantanea della corrente situazione degli
strumenti BPM presenti sul mercato.
Infine la tesi mostra i risultati dell’analisi, applicando la metodologia di
valutazione ai (52) più popolari strumenti BPM e quindi considerandone in
dettaglio solo alcuni (21).

Ringraziamenti
Ringrazio il Prof. Giuseppe Pozzi e il Prof. Marco Brambilla per la loro
disponibilià durante lo svolgimento dell’attività di tesi. A loro va tutta la
mia gratitudine. Ringrazio i miei genitori per avermi dato l’opportunità
di studiare e di conseguire un titolo di laurea in ingegneria (sforzo non da
poco da parte loro). Ringrazio tutte quelle persone che nel corso degli anni
accademici mi hanno dato l’opportunità di applicare sul campo lavorativo
le competenze apprese durante gli studi. Infine ringrazio Martina. Sei stata
la mia forza durante i miei momenti di sconforto.
V

Indice
Abstract I
Sommario III
Ringraziamenti V
1 Introduzione 1
1.1 Processi di business, BPM e sistemi BPM . . . . . . . . . . . 1
1.2 Motivazione e obiettivi della tesi . . . . . . . . . . . . . . . . 4
1.3 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Stato dell’Arte 7
2.1 Processi di business . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Classificazione dei processi di business . . . . . . . . . 8
2.1.2 Componenti di un processo di business . . . . . . . . . 11
2.2 Business Process Management . . . . . . . . . . . . . . . . . . 12
2.2.1 Definizione di Business Process Management . . . . . 13
2.2.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3 Web Service . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.4 Sistemi BPMS . . . . . . . . . . . . . . . . . . . . . . 37
3 Standard degli Strumenti BPM 41
3.1 Standard grafici per la modellazione . . . . . . . . . . . . . . 42
3.1.1 Notazione BPMN . . . . . . . . . . . . . . . . . . . . . 46
3.2 Standard dei formati di interscambio . . . . . . . . . . . . . . 63
3.2.1 XML Process Definition Language . . . . . . . . . . . 65
3.3 Standard di esecuzione dei processi di business . . . . . . . . 70
4 Analisi degli Strumenti BPM 79
4.1 Obiettivi dell’analisi . . . . . . . . . . . . . . . . . . . . . . . 80
4.2 Scelta degli strumenti BPM da analizzare . . . . . . . . . . . 80
VII

4.3 Processo di business di riferimento . . . . . . . . . . . . . . . 86
4.4 Categorie di analisi e criteri di valutazione . . . . . . . . . . . 92
4.4.1 Conformità agli standard . . . . . . . . . . . . . . . . 93
4.4.2 Modellazione del processo di business . . . . . . . . . 97
4.4.3 Configurazione di un sistema BPM . . . . . . . . . . . 102
4.4.4 Attivazione del processo di business . . . . . . . . . . 108
4.4.5 Analisi del processo di business . . . . . . . . . . . . . 113
4.4.6 Usabilità dello strumento BPM . . . . . . . . . . . . . 118
4.4.7 Utenti target per l’utilizzo dello strumento BPM . . . 121
4.4.8 Riepilogo del framework di analisi proposto . . . . . . 125
5 Valutazione dei Singoli Strumenti BPM 129
5.1 Adobe LiveCycle Enterprise Edition . . . . . . . . . . . . . . 130
5.2 AgilePoint BPMS . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.3 Avantage BPM . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.4 Billfish BPM . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
5.5 BizAgi BPM . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
5.6 Business Process Visual Architect . . . . . . . . . . . . . . . . 145
5.7 eBPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.8 Genexus BPMS . . . . . . . . . . . . . . . . . . . . . . . . . . 152
5.9 IBM WebSphere Dynamic Process Edition . . . . . . . . . . . 154
5.10 iGrafx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
5.11 Intalio Enterprise Edition . . . . . . . . . . . . . . . . . . . . 160
5.12 jBPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
5.13 Lombardi BluePrint . . . . . . . . . . . . . . . . . . . . . . . 167
5.14 Metastorm BPM . . . . . . . . . . . . . . . . . . . . . . . . . 170
5.15 Oracle BPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
5.16 Process360 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
5.17 ProcessPAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
5.18 Questetra BPM . . . . . . . . . . . . . . . . . . . . . . . . . . 182
5.19 Savvion BPM . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
5.20 Tibco Business Studio . . . . . . . . . . . . . . . . . . . . . . 187
5.21 YAWL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
6 Risultati della Analisi Comparativa 193
6.1 Individuazione Strumenti BPMS . . . . . . . . . . . . . . . . 194
6.2 Analisi Comparativa dei BPMS Individuati . . . . . . . . . . 196
6.2.1 Completezza Rispetto alle Funzionalità . . . . . . . . 196
6.2.2 Target di Utenti di Riferimento . . . . . . . . . . . . . 200
6.2.3 Usabilità . . . . . . . . . . . . . . . . . . . . . . . . . 203
VIII

6.2.4 Conformità agli standard BPM . . . . . . . . . . . . . 207
6.3 Esito della valutazione comparativa . . . . . . . . . . . . . . . 210
7 Conclusioni e direzioni future di ricerca 215
7.1 Valutazione del framework di analisi . . . . . . . . . . . . . . 215
7.2 Direzioni future di ricerca . . . . . . . . . . . . . . . . . . . . 216
Bibliografia 219
A Risultati dettagliati dell’analisi degli strumenti BPM 223
B Analisi degli strumenti BPM 231

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 Processi di business, BPM e sistemi BPM
Ogni organizzazione possiede dei processi di business. Questi processi di
business sono una sequenza controllata di attività che portano alla creazione
di un bene o servizio. Il grado di organizzazione di questi processi di business
determina il successo di un’organizzazione [34]. Per esempio, un appropriato
processo di pubblicità può incrementare il bacino di clienti potenziali
dell’organizzazione oppure un idoneo processo manifatturiero assicura che il
prodotto sia di alta qualità, ad un prezzo ragionevole e rispetti i tempi di
mercato. Questo incrementa di conseguenza la soddisfazione del cliente e
rende l’organizzazione competitiva 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 uno specifico output [21]. Per esempio, prendiamo in
considerazione il processo di business di un’agenzia assicurativa nella quale
un cliente richiede di stipulare un contratto di assicurazione. Questo processo
di business è composto da attività che riguardano: il controllare la
credibilità del cliente, ottenere le sue informazioni, calcolare il suo salario
mensile, e molte altre. Tutte queste attività sono collegate le une con le altre,
in modo tale che esse accadano nel giusto momento e nel giusto ordine.
L’input di questo processo di business è la richiesta del cliente e l’output è
il contratto firmato della polizza assicurativa.

2 Capitolo 1. Introduzione
Fattori come la globalizzazione, le opportunità di e-business, l’instabilità
politica porta ad un mercato caratterizzato da incertezza nel quale un’organizzazione
deve costantemente adattarsi. Se un’organizzazione non cambia e
non si adatta al suo ambiente, allora deve affrontare il rischio di essere esclusa
dal mercato [4]. Quindi i cambiamenti organizzativi sono fondamentali per
la sopravvivenza di un’organizzazione. Tradizionalmente vengono individuati
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 un’organizzazione. Il secondo tipo di cambiamento
è invece più graduale e permette un’adattamento delle modalità operative
in base all’evolversi 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 affrontare un’organizzazione. In particolare, il Business
Process Management (BPM) è una disciplina gestionale che si occupa
di descrivere e gestire i processi di business in un organizzazione. L’obiettivo
del Business Process Management è quello di raggiungere gli obiettivi
dell’organizzazione allineando i processi di business con questi obiettivi e
migliorando di continuo questi processi.
Nell’era dell’impresa digitale la gestione dei processi di business viene
coadiuvata mediante l’utilizzo di sistemi software che sono in grado di gestire
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 figura 1.1. La figura mostra che i sistemi informativi
sono composti da diversi livelli. Il centro è formato dall’infrastruttura
del sistema, che consiste dell’hardware e del sistema operativo che permette
all’hardware di funzionare. Il secondo livello consiste di applicazioni generiche
che vengono utilizzate largamente all’interno di un’organizzazione. Ad
esempio tra queste troviamo i Database Management System. Il terzo livello
consiste di applicazioni specifiche del dominio di applicazione. Queste
applicazioni vengono usate solamente entro specifiche tipologie di organizzazioni.
Il quarto livello consiste di applicazioni sviluppate specificatamente
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
specifici dell’hardware a disposizione. Con il passare del tempo il numero
e la complessità delle applicazioni specifiche del dominio e della singola organizzazione
aumentò. Questo fatto fu dovuto alla necessità di supportare

1.1. Processi di business, BPM e sistemi BPM 3
Figura 1.1: Livelli di un sistema informativo
più tipi di attività e di utenti. Inoltre l’avvento del Web ha richiesto che
queste applicazioni fossero accessibili direttamente sia ai clienti che ai partner
di business. Il trend mutò dal programmare le applicazioni al’integrare
le applicazioni esistenti. Nel corso degli anni ’70 e ’80 i sistemi informativi
continuavano ad essere incentrate sui dati. L’attenzione sulla tecnologia
IT era incentrata sullo storage, recupero e presentazione dell’informazione
vista prima di tutto come dati. Solo a partire dagli anni ’90 si iniziò a porre
l’enfasi sui processi. La necessità di adeguare continuamente i processi di
business di un organizzazione al mutare delle esigenze del mercato, portò
alla creazione di metodologie in grado di comporre e riutilizzare le applicazioni
esistenti considerandole come una sequenza di attività. Il trend dei
sistemi informativi passò da essere orientato ai dati ad essere orientato ai
processi. Il risultato dell’evoluzione dei trend citati ha portato alla nascita
dei moderni sistemi BPM.
I sistemi BPM sono sistemi software che permettono di definire i processi
di business mediante l’utilizzo di notazioni adatte allo scopo, di metterli
in esecuzione e di controllarne l’esito. Il supporto di questi sistemi diventa
cruciale in termini di competitività sul mercato per l’organizzazione. Infatti
permettono sia di gestire attività che devono essere svolte da agenti
umani sia di automatizzare completamente altre attività, aumentando così
l’efficienza di un processo di business. Essi sono composti da diversi strumenti
che permettono un completo supporto al BPM. Per questo motivo
sono anche definiti BPM suite [16]. Obiettivo primario dei BPMS è gestire
un processo di business. Un processo di business può essere visto come uno

4 Capitolo 1. Introduzione
opiù workflow che collaborano tra di loro al fine di raggiungere un obiettivo
comune. Un workflow è l’automazione di una sequenza di attività. Il
concetto di workflow viene definito dal Workflow Management Coalition. Il
WfMC è un consorzio formato da sviluppatori, analisti e ricercatori che si
occupano di definire degli standard per la gestione dei processi di business
e dei relativi workflow. Tra questi standard il WfMC ha definito lo standard
XPDL che è un linguaggio che ha come scopo quello di definire 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 definito standard nell’ambito dei sistemi BPM. Uno di
questi èl’Object Management Group che ha definito uno standard per la
modellazione grafica di un processo di business: la notazione BPMN (Business
Process Management Notation). Un altro ancora èilconsorzioOASIS
(Organization for the Advancement of Structured Information Standards)
che ha definito lo standard BPEL (Business Process Execution Language).
BPEL è uno standard di esecuzione che permette al processo di business di
essere eseguito indifferentemente su tutti gli strumenti BPM che supportano
questo standard. L’adozione di questi standard da parte degli strumenti
BPM è importante dal punto di vista dell’interoperabilità. 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 l’esecuzione
di un’attività del workflow ad uno specifica risorsa. Una volta che
il 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
Esistono numerose soluzioni di strumenti BPM presenti sul mercato [19].
Queste soluzioni non sono tutte uguali. Infatti alcune di queste forniscono
solamente gli strumenti per la modellazione dei processi di business. Altre
ancora non forniscono gli strumenti di analisi del processo di business.
In base allo specifico progetto BPM che si deve realizzare, nasce la necessità
di poter scegliere lo strumento BPM adatto alle proprie necessità.
Attualmente la letteratura non propone un metodo scientifico per valutare
i differenti strumenti BPM. Lo scopo di questa tesi è appunto quello di
definire un framework di analisi e valutazione di questi strumenti BPM. La

1.3. Struttura della tesi 5
definizione del framework di analisi porterà all’individuazione e alla conseguente
definizione delle varie categorie di analisi che caratterizzano uno
strumento BPM. Una volta che questo framework sarà completato, verrà applicato
a diversi strumenti BPM presenti sul mercato con un duplice scopo:
primo, testare la bontà del framework di analisi e di valutazione; secondo,
scattare una panoramica delle diverse soluzioni BPM che il mercato offre e
individuare le soluzioni BPM migliori per categoria.
1.3 Struttura della tesi
La tesi è strutturata nel modo seguente.
Il capitolo due mostra lo stato dell’arte dei sistemi BPMS: si descrivono
le varie tipologie di processi, i concetti fondamentali quale quello di workflow
e web service. Inoltre viene illustrata la struttura funzionale di un sistema
BPMS.
Il capitolo tre illustra le varie tipologie di standard dei BPMS: standard
di modellazione, standard dei formati di interscambio e standard dei formati
di esecuzione. In particolare verranno presi in considerazione gli attuali
standard de facto: BPMN, XPDL e BPEL4WS / BPEL4PEOPLE.
Il capitolo quattro descrive il framework di analisi e valutazione proposto,
descrivendo tutte le categorie di analisi individuate.
Nel capitolo cinque vengono illustrati i risultati dell’applicazione del
framework per strumento BPM.
Il capitolo sei consiste in un’analisi comparativa tra i vari risultati trovati.
Verranno individuati gli strumenti BPM migliori sui quali verrà illustrata
nello specifico l’analisi per categoria.
Nelle conclusioni si riassumono le valutazioni finali sul framework di analisi
e valutazione creato e verranno delineate le linee guida per le prospettive
future di ricerca.
Nell’appendice A si riportano i risultati delle valutazioni per categoria.
L’appendice B mostra i risultati dell’analisi comparativa per tutti gli
strumenti BPM.

6 Capitolo 1. Introduzione

Capitolo 2
Stato dell’Arte
Il capitolo mostra lo stato dell’arte dei sistemi BPMS. Verrà prima illustrato
il concetto di processo di business (par. 2.1). Poi verranno illustrate le varie
tecnologie alla base di un BPMS: workflow e web service (par. 2.2.2 e par.
2.2.3). Infine verranno illustrate le varie architetture a supporto di un BPMS
(par. 2.2.4).
7

8 Capitolo 2. Stato dell’Arte
2.1 Processi di business
Ogni prodotto di qualsiasi natura che una compagnia immette sul mercato è
il risultato di una serie di attività che sono state eseguite per la sua creazione.
La tecnologia dell’informazione, in particolare nei sistemi informativi aziendali,
gioca un ruolo chiave nella gestione di queste attività e permette la loro
esecuzione coordinata. In molte compagnie sussiste ancora il gap tra aspetti
di business organizzativi e tecnologia dell’informazione 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 mercato.
Strumento chiave affinché questo sia possibile è considerare queste
attività tutte appartenenti ad uno o più processi di business. Per questo
motivo possiamo definire un processo di business come un insieme di attività
eseguite in coordinazione con l’ambiente organizzativo e tecnico che
permette di dare loro un’organizzazione 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 Classificazione dei processi di business
I processi di business possono definire sia strategie di business ad alto livello
sia processi di business operativi [44]. Tra questi due estremi esistono differenti
livelli che caratterizzano un processo di business (figura 2.1). Al livello
più in alto un processo di business serve per descrivere la strategia della
compagnia, definendo 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 sottoobiettivi.
Al terzo livello si trovano i processi di business organizzativi. Questi
sono processi ad alto livello che tipicamente vengono specificati in forma
testuale dai loro input, dai loro output, dai loro risultati attesi e dalle loro
dipendenze con gli altri processi di business organizzativi.

2.1. Processi di business 9
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 differenza di quelli organizzativi caratterizzati da funzionalità di business
ad alto livello, in questi processi vengono definite nel dettaglio le loro attività
e le relazioni tra di esse ma non viene definito alcun tipo di implementazione.
Questi ultimi sono le basi dei processi di business implementati poichè
essi contengono le informazioni sull’esecuzione delle attività dei processi e
sull’ambiente 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 classificazione 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 definito uno
schema delle risorse dell’organizzazione a cui vengono sistematicamente assegnate
delle attività del processo in base alla loro competenza. I tradizionali
sistemi di gestione dei workflow che vedremo più avanti sono adatti allo
scopo. Quando invece un processo necessita di interagire con un altro allora
si parla di coreografie di processi. In questo caso processi facenti parte di
una coreografie 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 definire una rappresentazione comune dei vari processi
di business. Vedremo nel paragrafo 2.2.3 un paradigma architetturale
adatto a questo scopo (SOA).
Un altro tipo di classificazione può essere fatto sulla base del loro grado
di:
• automazione
• ripetizione
• strutturazione
Per quanto riguarda il grado di automazione esistono processi di business
che non richiedono l’intervento 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

10 Capitolo 2. Stato dell’Arte
Figura 2.1: Livelli dei processi di business: dalla strategia di business ai processi di
business implementati

2.1. Processi di business 11
sistemi informatici eterogenei rendendo questa integrazione trasparente all’intervento
umano. Esistono poi processi che non possono essere in alcun
modo automatizzati ma richiedono necessariamente l’intervento umano. Un
esempio sono tutte quelle applicazioni che richiedono l’inserimento di dati
in una maschera al fine di portare a termine un’operazione. Molti processi
di business invece richiedono sia attività di tipo manuale sia attività ditipo
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
èpiù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 l’esecuzione automatica dei processi.
Questo tipo di tecnologie comportano un investimento di una certa consistenza
ma consentono la corretta esecuzione dei processi ad alta ripetitività.
Esistono invece dei processi che invece sono caratterizzati da uno scarso o
nullo grado di ripetitività. Questi processi vengono definiti processi di business
collaborativi. In questi processi l’utilizzo delle tecnologie di supporto
non ha come obiettivo quello di ottimizzare l’efficienza 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 classificazione dei processi di business in base al
loro grado di strutturazione. Si definisce workflow 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 definisce completamente
strutturato. Ad esempio in questi processi sono definiti 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 workflow sono
adatti a supportarli. Si definisce invece attività ad hoc, un processo che non
necessita di essere definito completamente in quanto deve dare una certa
flessibilità all’operatore 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 flessibilità. 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. Definiamo
con il termine “caso” (case) la produzione di un particolare prodotto. Og-

12 Capitolo 2. Stato dell’Arte
ni caso richiede che un “processo” (process) venga eseguito. Un processo
consiste in un insieme di “task” che devono essere espletate ai fini del suo
completamento e di un insieme di condizioni (condition) che determinano
l’ordine delle attività. Un task può essere considerato come un processo che
non può essere diviso ulteriormente e che viene svolto nel suo insieme da
una “risorsa” (resource). Chiamiamo “attività” l’esecuzione 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à specifiche. Ciò non significa che una risorsa necessariamente debba
portare a termina l’attività per la quale è stata assegnata. Tuttavia con il
suo assegnamento essa diventa responsabile dell’esito di tale attività. Due
opiù task che devono essere eseguiti seguendo un determinato ordine sono
chiamati “sequenza”. Quando è necessario scegliere tra due o più taskper
il proseguimento del flusso di processo ci troviamo nel caso di “selezione”
tra più task. Ci sono task che possono anche essere eseguiti “in parallelo”.
Questi ultimi devono essere completati ad esempio prima che il task successivo
possa entrare in esecuzione. Questo caso è chiamato “sincronizzazione”.
È possibile ripetere l’esecuzione di più task durante l’esecuzione di un processo.
Questa operazione è chiamata “iterazione”. Ricapitolando possiamo
identificare quattro meccanismi di base nella struttura di un flusso di un
processo:
• sequenza
• selezione
• parallelizzazione
• iterazione
è Gli strumenti che andremo ad analizzare si occupano della modellazione di
questi meccanismi e dell’esecuzione di questi processi di business. I sistemi
informatici offrono 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 definizione di Business Process Management
(par. 2.2.1). Poi presenta il concetto di workflow (par. subsec:Workflow),
i modelli che lo definiscono e l’architettura dei sistemi che
lo gestiscono. Verrà trattata l’architettura dei Web Service (par. 2.2.3).

2.2. Business Process Management 13
I Web service sono la tecnologia che viene impiegata per gestire processi
di tipo business to business. Infine il paragrafo illustra concettualmente la
struttura di un sistema BPM (BPMS) (par 2.2.4).
2.2.1 Definizione 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 qualità, la computazione distribuita, la gestione dei workflow
e la reingegnerizzazione dei processi di business [34]. Esistono diverse
definizioni 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 gestire
i processi di business con lo scopo di migliorare la qualità dei
prodotti e dei servizi.
Un’altra definizione di BPM è quella data da Weske [43]:
Un BPM è un sistema il cui scopo è 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.
L’ultima definizione 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, definizione, esecuzione, monitoraggio e
amministrazione).
Dall’unione delle tre definizioni 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 fine 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
dell’organizzazione allineando i processi di business a questi
obiettivi.

14 Capitolo 2. Stato dell’Arte
Nel paragrafo 2.2.4 descriveremo i componenti di un sistema BPM in
riferimento alla definizione data di BPM.
2.2.2 Workflow
Secondo il Workflow Management Coalition (WfMC), un workflow è l’automazione
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 affinchè si possa raggiungere un obiettivo comune, utilizzando un insieme
predefinito di regole. Un workflow può essere visto come un componente
di un processo di business, in quanto consiste in una sequenza di
attività specifiche di una particolare applicazione attuate attraverso insiemi
di istruzioni predefiniti, coinvolgendo sia procedure automatizzate che manuali.
Per questo si differenzia da un BPM che invece riguarda la definizione,
l’esecuzione e la gestione di un processo di business indipendentemente dalle
applicazioni che praticamente svolgono i task del processo. Un workflow
viene descritto attraverso tre modelli:
• Modello di processo
• Modello informativo
• Modello organizzativo
Per descrivere i tre modelli verranno utilizzati due modelli per descrivere
i workflow: quello del Workflow Management Coalition [18] e il modello
WIDE (Workflow on Intelligent and Distributed database Environment) [5].
Di seguito la descrizione dei tre modelli. L’utilizzo di questi due modelli
e della loro terminologia non fa perdere di generalità la descrizione dei tre
modelli che costituiscono il workflow.
Modello di processo
Utilizziamo la terminologia utilizzata dal Workflow Management System per
definire un workflow e metterlo in relazione con un processo di business. In
figura 2.2 lo schema della terminologia utilizzata per i vari componenti e le
relazioni tra di essi.
I componenti fondamentali di un workflow sono:
• Processo: un processo è definito come la rappresentazione formale di
un processo di business in modo tale che la sua manipolazione sia possibile
per mezzo di un workflow management system (WfMS). Questo

2.2. Business Process Management 15
è composto da un insieme di attività, da relazioni tra queste attività.
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 workflow è una risorsa
che esegue il lavoro associato ad una particolare istanza di task.
Il lavoro viene generalmente si riferisce ad un elemento di task contenuto
all’interno della work list del partecipante. Questo può essere
una risorsa umana, un’applicazione software, una parte specifica di
hardware in grado di eseguire un task.
• Work list: ogni partecipante del workflow 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 workflow engine e
appartiene all’interfaccia tra il workflow engine e il gestore della work
list.
Figura 2.2: Terminologia utilizzata dal Workflow Management Coalition per descrivere
i componenti di un workflow
Per quanto concerne la descrizione di un processo sottoforma di modello,
il Workflow Management Coalition ha definito 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 workflow:

16 Capitolo 2. Stato dell’Arte
• Processo: vista formalizzata di un processo di business, rappresentato
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 definizione
di processo che condividono una o più proprietà che permettono al
workflow 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 una
certa attività venga completata in un certo intervallo di tempo.
• Instradamento (Routing): è come vengono connesse tra loro i
diversi blocchi di attività. 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 ANDjoin
non avvengono con questo instradamento)
– Parallelo: due o più istanze di attività vengono eseguite in parallelo
all’interno del workflow, dando origine a thread multipli di
controllo. Le attività possono essere attivate in parallelo (AND)
oppure può essere scelto una o più attività da eseguire contemporaneamente
(OR). Quando da un’attività parte l’esecuzione
coordinata di più attività si parla di “attivazione parallela” .
Quando invece da più attività si torna ad una solo si parla di
“sincronizzazione”. Nelle figure da 2.3 a 2.6 i quattro possibili
casi.
• Ciclo: ripetizione di una stessa attività o di una sequenza di attività
finchè non viene soddisfatta una determinata condizione.
• Pre-post condizioni: una pre-condizione è un’espressione logica che
viene valutata dal workflow engine per decidere se iniziare un’istanza di
un particolare processo. In modo opposto una post-condizione è un’espressione
logica che viene valutata dal workflow engine per decidere
un’istanza di un particolare processo può definirsi completata.
Per poter descrivere un modello di workflow 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 workflow. Al

2.2. Business Process Management 17
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 ù attivit à
Figura 2.6: Sincronizzazione parallela di tutte le attivit à attivate dalle condizione

18 Capitolo 2. Stato dell’Arte
modello grafico 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 l’influenza 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 l’utilizzo delle reti di Petri
per descrivere i processi di workflow.
Le reti di Petri sono utili per la modellizzazione di sistemi il cui comportamento
è dominato da un flusso 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è l’insieme dei suoi vertici si può partizionare in due sottoinsiemi tali che
ogni vertice di una di queste due parti è collegato solo a vertici dell’altra. In
particolare il modello delle reti di Petri si fonda su questi concetti di base:
• Un posto (place) rappresenta uno o più oggetti. Ogni oggetto è sempre
in qualche stato.
• Una transizione (transition) rappresenta uno o più operazioni, che sono
solo possibili a degli stati specifici degli oggetti e che cambiano lo stato
di uno specifico oggetto.
• Una regola di occorrenza (occurrence rule) determina sotto quali stati
di un oggetto un transizione sia in grado di attivare (fire - condizione di
attivazione) l’operazione rispettiva e in che modo lo stato di un oggetto
cambia a seguito di questa attivazione. Gli elementi che vengono
utilizzati per definire le regole di occorrenza sono i token (figura 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 l’azione 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 posto

2.2. Business Process Management 19
influenza solo le transizioni poste nelle immediate vicinanze del posto,
e può solo cambiare dall’attivazione (firing) di queste transizioni.
Figura 2.7: Attivazione di una transizione
La figura 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 workflow. Innanzitutto non è possibile distinguere
i vari token gli uni dagli altri. Questo fatto limita i token ad avere tutti
la stessa semantica. Poi questo modello non è in grado di descrivere i
vari aspetti temporali del flusso di processo: infatti esiste un unico aspetto
temporale espresso dall’ordine degli archi. Inoltre questo modello tende
a crescere velocemente di dimensione rendendo la sua gestione complessa.
Per superare questi limiti è stato definito un modello più 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:

20 Capitolo 2. Stato dell’Arte
1. Reti di Petri colorate
2. Estensione temporale
3. 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 dell’occorrenza (figura 2.2.2). L’estensione temporale permette
di definire un timestamp su ogni token (figura 2.2.2). Il timestamp rappresenta
l’istante di tempo durante il quale il token può essere utilizzato dalla
transizione. Con questa estensione è possibile introdurre il concetto di ritardo
nell’esecuzione del flusso del processo. Infine 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 è alla base a sua volta del concetto di riuso
dei processi (figura 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 workflow. Questo formalismo permette in particolare
di descrivere il modello del processo di workflow ma non il suo corrispettivo
modello informativo e organizzativo.
Un processo di workflow 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 workflow. I token possono assumere
i seguenti ruoli:
• un oggetto fisico, 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;

2.2. Business Process Management 21
Figura 2.10: Estensione temporale rete di Petri
Figura 2.11: Supporto alla gerarchia di una rete di Petri

22 Capitolo 2. Stato dell’Arte
• un indicatore di una condizione, ad esempio la presenza di un token
può indicare il raggiungimento di una condizione
Un posto può assumere il ruolo di:
• un tipo di mezzo di comunicazione, ad esempio una linea telefonica;
• un buffer, ad esempio una coda;
• una locazione geografica, ad esempio un luogo specifico dell’organizzazione;
• 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 l’inizio di un’operazione;
• una trasformazione di un oggetto, ad esempio l’aggiornamento di un
database;
• il trasporto di un oggetto, ad esempio l’invio di un file;
Per quanto riguarda l’instradamento del flusso di processo (routing), le reti
di Petri permettono di definire quattro tipologie riguardanti i workflow:
1. Sequenze di task.
2. Instradamento parallelo, caratterizzato da un componente di tipo ANDsplit
all’inizio e di tipo AND-join al termine.
3. Instradamento selettivo, caratterizzato da un componente di tipo ANDsplit
all’inizio 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 definito come un collezione di task, condizioni, sottoprocessi
e relazioni. L’attivazione delle varie transizioni lungo il processo
avviene mediante l’utilizzo di diversi trigger (figura 2.2.2) che sono stati
definiti appositamente per il contesto dei processi di workflow:
• 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.

2.2. Business Process Management 23
• Utente (User): il task viene attivato da parte di un partecipante umano
al processo
• Messaggio (Message): rappresenta un evento esterno che abilita l’esecuzione
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 workflow
Dopo aver descritto come le reti di Petri si adattano al contesto dei processi
di workflow, mostriamo un esempio di processo di workflow modellizzato
tramite le reti di Petri (figura 2.2.2). Il processo di workflow descritto
riguarda il processo di prenotazione di una vacanza presso un’agenzia di
viaggio.
Per ulteriori approfondimenti si consiglia [35], [36] e [8].
Modello informativo
Il modello informativo di un workflow descrive le informazioni ricevute, modificate
o prodotte da un workflow. Secondo il modello WIDE, il modello
informativo di un workflow può essere definito in tre diverse modalità:
1. attraverso uno schema variabili del workflow;
2. attraverso un database condiviso con altri workflow;
3. attraverso documenti che vengono scambiati tra i diversi workflow.
Nel primo caso viene definito nel workflow uno schema delle variabili che
hanno visibilità solo all’interno della particolare istanza del workflow. Le
istanze del workflow non possono avere accesso alle variabili di un’altra
istanza: ognuna di queste possiede una propria copia dello schema delle

24 Capitolo 2. Stato dell’Arte
Figura 2.13: Esempio di processo di workflow descritto mediante rete di Petri: il caso
dell’agenzia di viaggio

2.2. Business Process Management 25
variabili del workflow. Di solito queste variabili vengono definite al momento
della definizione del task a cui queste si riferiscono.
Nel secondo caso, la definizione di uno schema delle variabili potrebbe includere
delle definizioni riguardo a dei dati che devono rimanere persistenti.
Questi dati devono poter essere condivisi dai vari partecipanti del workflow e
anche da altri workflow. Inoltre, questi dati persistenti possono anche essere
definiti all’infuori della definizione del workflow. Questi dati possono essere
scambiati con altri workflow e tra i vari task del workflow mediante la loro
manipolazione o recupero. La semantica di queste operazioni deve essere
dichiarata all’atto di definizione del processo di workflow. Possono anche
essere utilizzati dei database esterni condivisi e indipendenti dal particolare
WfMS utilizzato; hanno accesso a questi database i vari partecipanti durante
l’esecuzione del workflow. Nel caso di utilizzo di database esterni, questi dati
possono essere definiti con una notazione disponibile nel campo delle basi di
dati, come ad esempio di diagrammi entità-relazione (diagrammi E-R).
Nel terzo caso, l’insieme di informazioni che vengono utilizzate in maniera
esplicita dal workflow, oppure le informazioni che vengono create e/o modificate
da un utente per portare a termine un task, vengono descritte attraverso
degli elementi di tipo documento. Questi elementi possono essere definiti direttamente
nel workflow attraverso l’utilizzo di form oppure possono essere
creati da strumenti esterni al workflow. I documenti creati da strumenti
esterni possono essere documenti di testo, immagini, ecc. Invece attraverso
la definizione del workflow, i documenti vengono definiti sottoforma di form.
Le form sono quindi un insieme di campi di dati associati ad un determinato
task del workflow 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 workflow che sono
in evoluzione: l’aspetto temporale delle informazioni. Nei workflow questo
tipo di informazione può essere utilizzata per molteplici scopi: un utilizzo
tipico, ad esempio, è il monitoraggio dell’arrivo 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.

26 Capitolo 2. Stato dell’Arte
• condizioni temporali periodiche: servono per verificare 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 definire eccezioni che devo essere sollevate in un particolare
istante di tempo, oppure possono essere definite condizioni di scadenza
sull’esecuzione di un particolare task.
Modello organizzativo
Il modello organizzativo di un workflow deve descrivere:
• la struttura dell’organizzazione;
• il partecipante al processo di workflow;
• l’autorizzazione che ha un partecipante per eseguire una determinata
attività del processo di workflow.
Sfruttiamo il modello WIDE [5] per descrivere le caratteristiche di un modello
organizzativo di un workflow. L’utilizzo della terminologia di questo
modello non influisce minimamente sui concetti generali che descrivono il
modello organizzativo di un workflow.
Nel modello di workflow WIDE, un partecipante ad un processo di workflow
viene chiamato agente. Con l’entità agente possono essere descritte
ulteriori sotto-entità:
• Attore (Actor): è una risorsa di esecuzione individuale. Può essere
umano oppure un agente software. Un Attore può essere specificato
utilizzando diversi attributi tra cui la sua disponibilità.
• Gruppo (Group): è un insieme di attori che possiedono comuni caratteristiche
(ad esempio appartengono tutti ad una particolare unità
dell’organizzazione).
• 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 un’organizzazione viene specificata attraverso le relazioni che
vengono definite tra queste entità.

2.2. Business Process Management 27
Il modello organizzativo viene utilizzato dal WfMS per indentificare un
particolare agente coinvolto nel processo di workflow. Affichè questo sia possibile,
ogni agente viene caratterizzato da un identificativo univoco. Questo
permette di sapere quale partecipante sta eseguendo un determinato task.
Infine il modello organizzativo di un processo di workflow defisce i meccanismi
di autorizzazione dei vari agenti. Ogni task del workflow deve essere
eseguito da agenti autorizzati. Per questo c’è la necessità di specificare 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 verificare se
ci sono azioni da intraprendere. A questo proposito si introduce il concetto
di ruolo. Un ruolo è una descrizione generica delle entità acuiè permesso
eseguire uno specifico task. I ruoli vengono definiti separatamente dagli
agenti e dalla struttura organizzativa e possono riferirsi ad un uno o più task
del workflow. Il concetto di ruolo porta a due vantaggi:
1. indipendenza tra i partecipanti di un workflow e la definizione del
processo;
2. fornire un metodo per bilanciare il carico di lavoro.
L’associazione tra ruoli e partecipanti (o attori) del processo viene eseguita
quando vengono definite le informazioni di autorizzazione per quel partecipante,
cioè l’insieme 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 l’accesso e la manipolazione delle informazioni
ad ogni partecipante appartenente cui sono associati questi ruoli.
Dal punto di vista della progettazione del workflow esistono due ruoli di
base:
1. il progettista del workflow: definisce le specifiche dei processi di workflow,interminidischemidiworkflow;
2. l’amministratore del workflow: è incaricato alla gestione del workflow.
Definisce la struttura di una specifica organizzazione e gli attori che
partecipano all’esecuzione di un processo di workflow.
Dal punto di vista dell’esecuzione del workflow esistono i seguenti tre ruoli:
1. l’esecutore dell’istanza di workflow: è l’agente che inizia il caso di
workflow;
2. il responsabile dell’istanza di workflow: l’agente che ha la responsabilità
finale sul risultato dell’istanza di workflow;

28 Capitolo 2. Stato dell’Arte
3. l’esecutore del task: l’agente che sta eseguendo un task.
Grazie al modello organizzativo appena descritto, un WfMS èingrado
di assegnare task ai vari partecipanti del workflow in fase di esecuzione.
Questo assegnamento può essere effettuato sia mediante uno scheduler, dove
l’engine 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 nell’identificazione delle priorità e
dei casi critici). La necessità dientrambelemodalità 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 workflow (WfMS)
In questo paragrafo descriveremo la struttura di un sistema di gestione di
workflow. Una generica architettura di sistema di gestione dei workflow
permette di gestire i vari sottosistemi necessari per la progettazione e l’attuazione
dei workflow sia di sistema che quelli ad interazione umana (fig.
2.14). L’architettura contiene i seguenti sottosistemi e ruoli:
Figura 2.14: Schema base di un workflow management system

2.2. Business Process Management 29
• Workflow Modelling che fornisce i mezzi per poter modellare i processi
di business.
• Workflow Model Repository che si occupa di immagazzinare i modelli
di workflow che sono stati creati.
• Workflow Engine è responsabile del’attuazione dei processi di workflow.
Esso in particolare permette la creazione e l’attuazione di un’istanza
di workflow quando questa viene richiesta.
Il workflow engine si comporta diversamente in base alla tipologia di workflow
che deve istanziare. Nel caso di workflow di sistema esso manda avanti
il flusso di workflow secondo quanto è stato definito nel modello di workflow,
occupandosi direttamente del trasferimento di dati tra le applicazioni
coinvolte nel processo. Nel caso invece di workflow ad interazione umana,
l’istanza di workflow 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 workflow engine di assegnare
correttamente i task a chi ha le competenze per portarlo a termine.
L’architettura sopra descritta è un modello generico di architettura dei
wfms. Una descrizione più completaè stata fornita dalla Workflow Management
Coalition, la quale descrizione è diventata un punto di riferimento
nella progettazione di questo tipo di architetture. La figura 2.15 illustra i vari
componenti di questa architettura di riferimento. Il componente centrale di
questa architettura è il Workflow Enactment Service che nella terminologia
del WfMC rappresenta il Workflow Engine prima descritto. Quest’ultimo
comunica con gli altri sottosistemi per mezzo di interfacce.
Il sottosistema Process Definition Tools rappresenta gli strumenti per
mezzo i quali è possibile modellare i processi. Esso è connesso al Workflow
Enactment Service per mezzo dell’Interfaccia 1. L’obiettivo di tale interfaccia
è di permettere agli strumenti di modellazione prodotti dai vari vendors
di rappresentare i processi di business in una forma standard. In particolare
l’interfaccia suggerisce l’utilizzo di un linguaggio basato su XML chiamato
XPDL, XML Process Definition Language. Definiremo più avanti questo
tipo di linguaggio. Il sottosistema Workflow Client Applications permette
l’interazione con i partecipanti umani del processo quando viene attivato un
workflow ad interazione umana. L’obiettivo dell’interfaccia 2 è quello di permettere
la comunicazione delle applicazioni client di vendors differenti con
il Workflow Enactment Service. Il sottosistema Invoked Applications rappresenta
l’insieme di applicazioni che permettono di svolgere specifici task

30 Capitolo 2. Stato dell’Arte
Figura 2.15: Architettura di un workflow management system secondo WfMC
del processo. L’interfaccia 3 con il sottosistema centrale definisce degli standard
di comunicazione che permettono l’interoperabilità di quest’ultimo con
l’invocazione di applicazioni installate su piattaforme software eterogenee.
Il sottosistema Other Workflow Enactement Services rappresenta il gruppo
di altri Workflow engine che per mezzo dell’interfaccia 4 possono interagire
tra loro grazie dei protocolli di scambio dati comuni. Il sottosistema Administration
and Monitoring Tools contiene gli strumenti che permettono
di amministratore l’esecuzione di un workflow e di tenerne monitorato lo
stato. Anche questi strumenti devono interfacciarsi al workflow engine e lo
fanno per mezzo dell’interfaccia 5 che rappresenta un’interfaccia 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.
L’implementazione di questo modello architetturale ha subito delle
evoluzioni in base all’affiorare di nuove tecnologie e necessità di integrazione
tra i vari processi di business. Descriviamo ora come è stato implementato
questo modello architetturale nei tradizionali workflow management
system. In seguito nel prossimo paragrafo descriveremo la loro evoluzione
nelle architetture orientate ai servizi.
Nei tradizionali workflow management system vi è una separazione tra
tempo di costruzione (build time) e tempo di esecuzione (run time) di un
processo di workflow (figura 2.16). In particolare a tempo di costruzione
il processo viene definito attraverso uno strumento di modellazione grafica
mentre a tempo di esecuzione una istanza del processo viene eseguita dal
workflow engine. In base al tipo di workflow management system utiliz-

2.2. Business Process Management 31
Figura 2.16: Separazione tra tempo di costruzione e tempo di esecuzione di un processo
di workflow
zato, il modello di workflow viene rappresentato da uno script scritto nel
linguaggio di workflow di quel sistema. I modelli di workflow così definiti
vengono salvati in un database oppure in un repository di modelli di workflow.
Quando un processo di business richiede l’esecuzione di un particolare
workflow, il workflow engine crea un istanza di quest’ultimo e lo mette in
esecuzione. Una volta in esecuzione l’istanza del processo è totalmente indipendente
dalla definizione del modello di processo in quanto non sussiste
alcun collegamento tra i due. Questa situazione porta a non poter cambiare
la struttura di un’istanza di un flusso di workflow mentre questa è
in esecuzione facendo delle modifiche sul modello del processo stesso. Per
quest’ultima esigenza sono stati teorizzati dei sistemi di workflow “flessibili”.
Come è intuibile dal nome questi sistemi permettono di cambiare la
struttura del flusso di un workflow in esecuzione agendo sulla definizione del
suo modello. Questo permette di adattare il workflow in esecuzione in quei
scenari di processi di business caratterizzati da ambienti altamente dinamici.
Condizione affinchè sia possibile adattare dinamicamente un workflow
in esecuzione è che il workflow in esecuzione sia coerente con il workflow
modificato (relazione di continuità).
Fino ad ora abbiamo parlato delle architetture per gestire e mettere
in esecuzione dei workflow. Come abbiamo già discusso, il risultato di un
processo di business dipende dall’esecuzione coordinata di vari workflow e
dalla collaborazione con altri processi di business. Obiettivo del prossimo
paragrafo è quello di discutere l’ evoluzione di tali architetture descrivendo
i Web Service.
2.2.3 Web Service
SOA (Service Oriented Architecture) è una forma particolare di sistema distribuito.
Un sistema distribuito (distributed system) consiste di vari agenti

32 Capitolo 2. Stato dell’Arte
software distinti che devono lavorare insieme per svolgere alcuni compiti.
Questi agenti in un sistema distribuito non operano nello stesso ambiente
di calcolo quindi devono comunicare per mezzo di uno stack di protocolli
hardware/software su una rete. Motivare perchè dico questo
Questo modello architetturale permette la creazione di sistemi residenti
su una rete focalizzando l’attenzione sul concetto di servizio (service). Con
il termine “servizio” viene indicata un’applicazione residente su un sistema
progettato secondo le specifiche SOA. In questi sistemi infatti sono presenti
una o più applicazioni, chiamate appunto servizi, ben definite ed indipendenti
l’una dall’altra che risiedono su più calcolatori all’interno di una rete.
Ogni servizio mette a disposizione una certa funzionalità e può utilizzare
quelle che gli altri servizi mettono a disposizione realizzando in questo modo
applicazioni di maggiore complessità. L’architettura SOA non è legata
ad una specifica tecnologia ma contiene semplicemente delle proprietà che
devono essere rispettate da servizi che compongono il sistema. Le proprietà
che un servizio deve rispettare sono:
• essere realizzato in modo da da permetterne la composizione con altri.
La creazione di applicazioni o servizi più complessi attraverso la composizione
di servizi viene definita con il termine di “orchestrazione di
servizi” (Service Orchestration)
• fornire un’interfaccia di tipo a grana grossa (coarse-grained), cioè deve
mettere a disposizione un limitato numero di funzionalità inquanto
questo permette di avere una complessità bassa del programma di
controllo. Tale bassa complessità favorisce l’interazione con gli altri
servizi attraverso scambi di messaggi
• essere debolmente accoppiato con altri servizi (loosely coupled), cioè le
dipendenze con altri servizi devono essere in numero limitato rendendo
il sistema flessibile e facilmente modificabile
• essere ben definito, completo ed indipendente dal contesto o dallo stato
degli altri servizi
• essere ricercabile e recuperabile dinamicamente attraverso la sua interfaccia
e richiamato a tempo di esecuzione
• essere definito da un’interfaccia ed indipendente dall’implementazione
• essere reso disponibile sulla rete attraverso la pubblicazione della sua
interfaccia ed accessibile in modo trasparente rispetto alla sua collocazione.

2.2. Business Process Management 33
Il funzionamento di una SOA è basata sull’interazione di tre attori:
• Service Provider
• Service Consumer
• Service Registry
Il Service Provider è quell’entità che mette a disposizione un qualche
servizio. Tale servizio per poter essere trovato da altre entità nella rete
deve prima essere “pubblicato”. A tale fine il Service Provider comunica
al Service Registry le informazioni relative al servizio perchè vengano memorizzate.
Il Service Registry possiede quindi tutte le informazioni (come
URL o modalità di accesso) di tutti i servizi disponibili. Nel momento in
cui un Service Consumer dovrà utilizzare un servizio farà richiesta delle informazioni
ad esso relative al Service Registry. Con queste informazioni il
Service Consumer potrà comunicare direttamente con il Service Provider ed
utilizzare il servizio. Tutte queste informazioni passano attraverso quella
che viene genericamente definita rete di comunicazione che può ad esempio
essere una rete intranet oppure la stessa Internet. In figura 2.17 uno schema
riassuntivo.
Figura 2.17: Relazioni di interazione tra i vari attori di un SOA
I Web Service sono una tipologia di applicazioni web che cooperano fra
loro attraverso lo scambio di messaggi, indipendentemente dalla piattaforma
sulla quale si trovano. Ognuna di queste applicazioni viene chiamato Web

34 Capitolo 2. Stato dell’Arte
Service del quale il Web Services Architecture Working Group dà laseguente
definizione [42]:
un Web Service è un’applicazione software identificata da un
URI (Uniform Resource Identifier), le cui interfacce pubbliche e
collegamenti sono definiti e descritti come documenti XML, in
un formato comprensibile per la macchina (spec.WSDL). La sua
definizione può essere ricercata da altri agenti software situati su
una rete, i quali possono interagire direttamente con il Web Service,
con le modalità specificate nella sua definizione, utilizzando
messaggi basati su XML (SOAP) scambiati attraverso protocolli
Internet (tipicamente HTTP).
Stando alla sua definizione, le tecnologie su cui si basano i Web Service
sono:
• XML, eXtensible Markup Language
• SOAP, Simple Object Access Protocol
• WSDL, Web Services Description Language
• UDDI, Universal Description, Discovery and Integration
Attraverso l’utilizzo di questi ed altri standard, i Web Services rendono
possibile la cooperazione e la comunicazione, attraverso il web, di più applicazioni
(servizi) che mettono a disposizione alcune funzionalità e, allo stesso
tempo, utilizzano quelle rese disponibili da altre. Si può cioè ricercare e invocare
servizi che possono essere composti per formare un’applicazione per
l’utente finale, per abilitare transazioni di business o per creare nuovi Web
Services.
I vantaggi offerti dai Web Services sono:
• indipendenza dalla piattaforma, in quanto possono comunicare anche
se si trovano su piattaforme indipendenti
• indipendenza dall’implementazione del servizio: l’interfaccia che un
web service presenta sulla rete è indipendente dal software che implementa
tale servizio
• riuso dell’infrastruttura grazie all’utilizzo di SOAP come protocollo
per scambiarsi messaggi in quanto esso fa uso del protocollo HTTP
• riuso del software

2.2. Business Process Management 35
Il legame con l’architettura SOA sta nel fatto che, sfruttando al meglio tutte
le caratteristiche della tecnologia dei Web Services, il sistema che si ottiene
implementa proprio un’architettura orientata ai servizi. Dal punto di vista
dei BPMS, questo tipo di architettura viene utilizzato per implementare processi
di business basati su attività che richiedono servizi diversi e distribuiti
nella rete.
Caratteristiche dei Web Service
Definiamo meglio le tecnologie costituenti un Web Service.
XML, eXtensible Markup Language, è un metalinguaggio derivato da
SGML (Standard Generalization Markup Language) [39]. Il termine metalinguaggio
sta ad indicare che è un linguaggio per mezzo del quale è possibile
definire altri linguaggi. È basato sull’utilizzo di marcatori dalla cui
personalizzazione è possibile creare nuovi linguaggi (marcatori o tag) ed èindipendentemente
dalle varie piattaforme. L’utilizzo di questo metalinguaggio
permette la creazione di documenti strutturati e flessibili che vengono
utilizzati sulla rete per lo scambio dei dati. Il contenuto di un documento
XML è costituito da marcatori e dati strutturati secondo un ordine logico
determinato da una struttura ad albero. Il formato del documento è testuale
e questo permette all’utente di accedervi direttamente in lettura. Inoltre un
documento XML memorizza i dati all’interno di una struttura gerarchica
che rappresenta le relazioni esistenti fra di essi, senza curarsi della loro rappresentazione
visuale in quanto questi dati potranno poi essere visualizzati
in molti modi differenti. Dato che XML è un metalinguaggio e che quindi è
possibile derivare dei linguaggi da questo, è necessario per ragioni di interoperabilità
che questi linguaggi derivati vengano definiti in modo strutturato
da un meccanismo che li descriva in termini di elementi presenti, di struttura
e di relazioni fra questi elementi. Per questo sono state create delle
tecnologie per assolvere questo compito e sono Document Type Definition,
XML-Schema e XML Namespace. Grazie a questi meccanismi è possibile
validare i documenti scritti in un linguaggio derivato da XML per mezzo di
parser.
WSDL, ovvero Web Services Description Language, è un linguaggio
basato su XML usato per descrivere in maniera completa un Web Service
[41]. Di preciso un documento WSDL fornisce informazioni riguardanti
l’interfaccia del Web Service in termini di:
• servizi offerti dal Web Service
• URL ad essi associato

36 Capitolo 2. Stato dell’Arte
• modi per l’invocazione
• parametri accettati in ingresso e modalità con cui debbono essere
passati
• formato dei risultati restituiti
• formato dei messaggi
In altri termini un documento WSDL fornisce la descrizione relativa ad un
Web Service in termini di:
• cosa fa
• come comunica
• dove si trova
Attraverso tale documento si può quindi conoscere tutti i dettagli per poter
invocare correttamente il servizio.
SOAP, Simple Object Access Protocol, è un protocollo di trasmissione
di messaggi in formato XML [40]. SOAP mette a disposizione un meccanismo
semplice, ma allo stesso tempo solido, che permette ad una applicazione
di mandare un messaggio XML ad un’altra applicazione. Un messaggio è costituito
da una trasmissione in un senso, dal mittente al ricevente, ma si possono
avere uno o più messaggi che definiscono così iltipodicomunicazione
che stiamo stabilendo (per completezza: One-way, Request-response, Solicitresponse,
Notification). SOAP è un protocollo ad alto livello ed ècompletamente
indipendente dal protocollo di trasmissione sottostante, che può
essere indifferentemente HTTP (Hypertext Transfer Protocol), JMS(Java
Message Service), SMTP (Simple Mail Transfer Protocol) e altri. Tra questi
il più usatoè quello HTTP.
UDDI, Universal Description, Discovery and Integration, è un linguaggio
basato su XML che utilizza SOAP per le comunicazione da o verso
l’esterno[26]. Esso rappresenta la tecnologia per mezzo la quale si definisce
un meccanismo comune per pubblicare e trovare informazioni sui Web Services,
in base alla loro descrizione WSDL. Ciò che UDDI mette a disposizione
è un registro nel quale è possibile accedere, attraverso opportune funzioni,
per
• pubblicare servizi che un’azienda rende disponibili
• cercare aziende che mettono a disposizione un certo tipo di servizio

2.2. Business Process Management 37
• avere informazioni “Human Readable” circa indirizzi, contatti o altro
relativi l’azienda
• avere informazioni tecniche “Machine Readable”, cioè interpretabili
ed utilizzabili dalla macchina, relative ad un servizio in modo tale da
poter effettuare la connessione
Un registro UDDI è costituito in realtà da un database distribuito, cioè
da molti registri distribuiti sulla rete, ognuno dei quali si trova sul server
di un’azienda che contribuisce allo sviluppo di questo archivio pubblico, e
connessi fra loro.
2.2.4 Sistemi BPMS
Nel paragrafo 2.2.1 abbiamo dato la definizione di BPM. Questa definizione
afferma che un BPM supporta in modo esplicito la gestione del processo di
business. Questo significa che i processi di business devono essere definiti
in modo esplicito. Processi di business impliciti sono insiti nei pattern di
lavoro degli impiegati di un’organizzazione 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 definiti 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
all’esterno dell’organizzazione 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. L’ambiente 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à definite 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 esecuzione

38 Capitolo 2. Stato dell’Arte
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 figura 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 l’esecuzione delle fasi. Infatti molte attività
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 identificati,
rivisti, validati e rappresentati con dei modelli di processi di business. La
notazione grafica esprime i modelli di processi di business in modo esplicito.
Tecniche di modellazione di un processo di business come la validazione,
simulazione e la verifica vengono utilizzate durante questa fase. Per quan-

2.2. Business Process Management 39
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 verificare
la correttezza del loro comportamento. La maggior parte dei sistemi
BPM forniscono un ambiente di simulazione che può essere usato in questa
fase.
Configurazione Una volta che il modello del processo di business viene
progettato e verificato, 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 l’attivazione del processo nel BPMS. Il sistema BPM
deve essere configurato secondo l’ambiente organizzativo e in base ai processi
di business che devono essere messi in esecuzione. La configurazione
deve includere sia le interazioni degli utilizzatori del sistema con esso sia
l’integrazione dei sistemi software esistenti con il BPMS. La configurazione
di un BPMS potrebbe coinvolgere aspetti transazionali quindi deve essere
configurato in modo tale da garantire l’applicazione delle proprietà ACID
richieste dalle transazioni definite 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 configurazione, l’implementazione del processo di business
deve essere testata. A livello di processo, vengono effettuati 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 configurazione, le istanze dei processi di
business possono essere attivate. La fase di attivazione del processo riguarda
tutti gli aspetti coinvolti nell’esecuzione del processo. All’inizio della fase di
attivazione, le istanze dei processi di business vengono inizializzate in modo
da soddisfare i requisiti di business di un’organizzazione. L’iniziazione di
un’istanza 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 l’esecuzione delle istanze e fornire
meccanismi per l’orchestrazione di queste istanze, in modo da garantire che
le attività di processo vengono eseguiti secondo i vincoli di esecuzione spec-

40 Capitolo 2. Stato dell’Arte
ificati nel modello di processo. Un altro componente importanti del BPMS
di questa fase è quello che permette il monitoraggio per visualizzare lo stato
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 significativi
sull’esecuzione delle istanze di business, tipicamente sottoforma di file di log.
Questi file 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 file 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 identificare la
qualità di un modello di processo di business e il grado di adeguatezza rispetto
l’ambiente di esecuzione. Il business activity monitoring (BAM) serve a
identificare quali attività del processo di business ad esempio consumano
più risorse oppure non sono state completate in base ai vincoli previsti dal
modello di processo di business. Queste analisi vengono effettuate a tempo
di esecuzione in modo da intervenire direttamente sull’istanza del processo.
Il business cockpit,invece, si occupa di analizzare i dati raccolti a posteriori
rispetto l’esecuzione 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 identificare quelle parti del modello che devono
essere migliorate.

Capitolo 3
Standard degli Strumenti
BPM
In questo capitolo verranno illustrati gli standard applicabili agli strumenti
BPM. Come vedremo, questi possono essere di tre tipologie: standard
grafici 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 l’importanza di avere
degli standard ben definiti permette di dare uniformità alla rappresentazione
di un processo di business e di unificare le molteplici soluzioni descrittive già
esistenti. Tra le proposte di standard che citeremo, tratteremo in maniera
più approfondita gli standard che vengono presi in considerazione ai fini del
nostro studio di analisi: BPMN, XPDL, BPEL4WS, BPEL4PEOPLE.

42 Capitolo 3. Standard degli Strumenti BPM
3.1 Standard grafici per la modellazione
Gli standard grafici permettono agli utenti di esprimere sotto forma di diagramma
il flusso informativo, i punti di decisione e i ruoli dei processi di
business. Rispetto alle altre tipologie di standard, gli standard grafici sono
quelli più human-readable e facili da comprendere senza che siano necessarie
conoscenze tecniche specifiche. Tra gli standard più importanti troviamo:
• Business Process Management Notation (BPMN)
• Activity Diagram UML
• Event-driven Process Chain (EPC)
Tra questi standard grafici, Business Process Management Notation èlo
standard scelto ai fini della nostra analisi in quanto attualmente lo standard
di modellazione più utilizzato tra i vari produttori di strumenti BPM.
Business Process Management Notation sarà l’oggetto del paragrafo 3.1.1.
Vediamo ora brevemente gli altri due standard grafici citati.
Activity Diagram UML
Unified Modeling Language è un linguaggio di modellazione visuale, orientato
agli oggetti e polivalente ideato dall’ Object Management Group. Il
linguaggio contiene diverse notazioni orientate agli oggetti per mezzo delle
quali è possibile definire tutti gli attributi e i comportamenti degli oggetti
modellizzati [31]. Esempi di queste notazioni possono essere:
• Use Case Diagram: permettono di documentare ad alto livello i requisiti
dell’utente
• Sequence Diagram: permettono di documentare la sequenza del flusso
del programma
Oltre a queste notazioni, UML mette a disposizione gli Activity Diagram
che sono una notazione adatta a descrivere i processi di business. Infatti gli
Activity Diagram visualizzano sequenze di azioni che devono essere eseguite,
includendo la descrizione del flusso di controllo e del flusso dei dati tra
attività.
Per descrivere le caratteristiche di un Activity Diagram, prendiamo in
considerazione l’esempio descritto da [8] e illustrato in figura 3.1. L’esempio
mostra un processo di business che consiste nell’attività di vendita di hardware
di computer. All’interno del rettangolo dell’attività troviamo la notazione
grafica che consiste di nodi e archi rappresentanti il comportamento

3.1. Standard grafici per la modellazione 43
Figura 3.1: Esempio di processo descritto con un Activity Diagram tratto da [8]
interno del processo. Un Activity Diagram possiede due tipi di nodi per il
flusso di controllo:
1. nodi di azione: rappresentano i task che costituiscono il processo di
business. Le attività rappresentano l’esecuzione coordinata di azioni.
Vengono rappresentati come rettangoli arrotondati.
2. nodi di controllo: permettono di realizzare la coordinazione tra azioni.
La struttura di controllo più importanteè la sequenza. Nella sequenza
un’azione può iniziare la sua esecuzione quando un’altra azione
termina la sua esecuzione.
La semantica delle attività viene descritta per mezzo dei token flow. Questi
possono essere di tipo control token se sono anonimi e non distinguibili;
sono, invece, di tipo object token se si riferiscono ad oggetti di dati. Il fluire
dei token lungo gli archi di controllo permette di determinare le dipendenze
nell’esecuzione delle azioni. Un’azione può iniziare la sua esecuzione quando i
token sono disponibili nei suoi archi in entrata e provengono da tutte le azioni
che precedono quella corrente. Quando l’azione inizia la sua esecuzione, i
token vengono rimossi dagli archi in entrata e posti in quelli in uscita. A
questo punto l’azione può definirsi terminata (vedi figura 3.2). All’inizio e
al termine del processo notiamo due nodi di controllo particolari: il nodo
iniziale, il quale indica l’inizio dell’attività, e il nodo finale che indica la
fine del flusso di controllo. Nel flusso di controllo le azioni possono essere
eseguite al verificarsi di determinate condizioni. Questo fatto corrisponde
alla struttura di controllo chiamata XOR-split che consiste in una scelta
di tipo esclusivo sulla prossima attività che deve entrare in esecuzione. La
figura 3.3 mostra le tre varie tipologie di nodi decisionali:

44 Capitolo 3. Standard degli Strumenti BPM
Figura 3.2: Flusso di token tra azioni
1. Nodi decisionali (decision node): in uscita escono tanti archi quante
sono le possibilità di esecuzione.
2. Nodi di unione (merge node): l’azione ha diversi nodi in entrata ma
solo uno in uscita.
3. Nodi combinati: sono nodi che racchiudono sia quelli decisionali che
quelli di unione.
Figura 3.3: Notazione dei nodi decisionali
Oltre al flusso di controllo di tipo esclusivo, gli Activity Diagram mettono a
disposizione la possibilità di definire flussi di controllo di tipo concorrente.
Questi flussi possono essere definiti mediante le notazioni di fork e join. La
fork consiste nell’avere un solo arco di controllo in entrata e diversi archi
in uscita. Questo permette di eseguire in parallelo diverse azioni. La join
consiste nell’avere più archi in entrata e solo uno in uscita. Questo consente
di sincronizzare tutte le azioni precedenti quella corrente. La fork/join combinata
è l’unione dei due flussi di controllo appena descritti. La figura 3.4
mostra i flussi di controllo concorrenti.
I componenti dell’Activity Diagram appena descritti sono gli elementi di
base di questa notazione. Per una panoramica completa dei componenti di
un Activity Diagram si consiglia [13].

3.1. Standard grafici per la modellazione 45
Figura 3.4: Notazione dei nodi decisionali
Event-driven Process Chain (EPC)
Event-driven process chain è una metodologia di modellazione ideata da
SAP [8]. Questa metodologia consiste di descrivere il processo di business
da diversi punti di vista:
• Entità responsabili del processo e loro relazioni: descrive le entità
responsabili coinvolte nel processo di business, i loro output e le loro
relazioni di comunicazione sottoforma di diagrammi di interazione.
• Flusso funzionale: il diagramma descrive le attività appartenenti al
processo di business che devono essere eseguite. A differenza del precedente
diagramma, nel flusso funzionale il punto di vista è la sequenza
dinamica delle attività.
• Flusso di output: questo diagramma descrive le relazioni tra gli output
prodotti dalle attività del processo di business.
• Flusso informativo: il diagramma mostra gli oggetti di informazione
utilizzati durante il processo di business (ad esempio per scambiarsi
dati tra attività).
Una volta definite tutte le viste del modello di processo di business si ricava
il cosiddetto modello di processo di business consolidato che altro non èche
l’unione delle viste del processo definite precedentemente.
Una event-driven process chain consiste dei seguenti elementi (figura
3.5):
• Funzioni: rappresentano i blocchi di base. Rappresentano una attività
che deve essere eseguita.
• Eventi: descrivono la situazione prima e dopo l’esecuzione di una funzione.
Le funzioni sono collegate da eventi. Un evento potrebbe corrispondere
ad una post-condizione di una funzione e agire come una
pre-condizione di un’altra funzione.

46 Capitolo 3. Standard degli Strumenti BPM
• Connettori logici: possono essere utilizzati per collegare le attività
agli eventi (AND, XOR, OR). In questo modo si specifica il flusso di
processo.
Figura 3.5: Elementi della notazione event-drive process chain
Un esempio di processo di business modellizzato tramite metodologia EPC
è quello di figura 3.6. Per ulteriori approfondimenti sul modello si consiglia
[37].
3.1.1 Notazione BPMN
Business Process Model and Notation, BPMN, è una notazione di modellazione
per processi di business definito dall’Object Management Group
(OMG), che mira a diventare uno standard de facto tra i vari standard
grafici di modellazione di processi di business. La notazione nasce dall’esigenza
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 flusso e le descrizioni di quest’ultime 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 comunicare
una 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 classificati come:
1. Processi privati (interni)
2. Processi pubblici (pubblici)
3. Processi di collaborazione (globali)
I processi privati sono i processi interni a specifiche organizzazioni e sono
quei tipi di processi che vengono definiti workflow. Se vengono utilizzate le

3.1. Standard grafici per la modellazione 47
Figura 3.6: Esempio di processo EPC

48 Capitolo 3. Standard degli Strumenti BPM
swimlanes per la loro rappresentazione allora il flusso di sequenza (sequence
flow) del processo privato è contenuto all’interno di un singolo pool e non
può attraversare i confini di questo pool. Tuttavia è possibile un interazione
tra processi privati di business utilizzando il flusso di messaggi (message
flow). La figura 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
all’infuori dei processi di business privati con i meccanismi di controllo
di flusso appropriati vengono incluse nei processi astratti. Tutte le altre attività
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 all’interno di un pool e possono
essere modellizzati separatamente o all’interno di un diagramma BPMN più
grande per mostrare il flusso di messaggi tra le attività dei processi astratti
e le altre entità. Se il processo astratto è nello stesso diagramma del suo
corrispondente processo privato allora le attività che sono in comune ad
entrambi i processi possono essere associate. La figura 4.4 un esempio di
processo astratto con notazione BPMN.
Figura 3.8: Esempio di processo astratto descritto in BPMN tratto da [28]
Un processo di collaborazione raffigura le interazioni tra due o più entità
di business. Queste interazioni vengono definite come una sequenza di

3.1. Standard grafici per la modellazione 49
attività che rappresentano le modalità di scambio di messaggi tra le entità
coinvolte. Il processo di collaborazione può essere mostrato come due o
più processi astratti comunicanti tra di loro. All’interno 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 eseguibili
di collaborazione hanno molte più attività e dettagli rispetto ai processi
astratti come è possibile vedere in figura 4.5.
Un diagramma BPMN (chiamato diagramma BPD) può essere modellizzato
rispetto a differenti punti di vista dei partecipanti del processo. Infatti
ogni processo di business contiene due o più attori, i quali possiedono differenti
punti di vista a secondo di come vengono coinvolti all’interno del processo.
Alcune attività potranno essere interne rispetto ad un partecipante
mentre altre potrebbero risultare esterne a quel particolare partecipante.
Questa differenze di punti di vista delle attività 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 figura 4.5 infatti il processo di business presenta due
punti di vista: uno del paziente e l’altro dell’ufficio del dottore. In questo
diagramma vengono mostrate le attività dientrambiipartecipantialprocesso
ma, quando il processo viene posto in esecuzione, ogni partecipante
avrà il controllo solo delle attività che lo riguardano direttamente. L’obiettivo
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 raffigurazione 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 grafiche 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 grafici che consistono di
risolvere situazioni di modellazione complesse.
Il primo gruppo degli elementi di base della notazione contiene 11 formalismi
grafici per mezzo dei quali è possibile descrivere la maggior parte
dei processi di business. Questi formalismi grafici sono divisi in 4 categorie:
1. Oggetti di flusso (Flow Objects)
2. Oggetti di connessione (Connecting Objects)
3. Swimlanes

50 Capitolo 3. Standard degli Strumenti BPM
Figura 3.9: Esempio di processo di collaborazione descritto in BPMN tratto da [28]

3.1. Standard grafici per la modellazione 51
4. Artefatti (Artifacts)
In particolare gli oggetti di flusso sono divisi in:
• Eventi
• Attività
• 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
Infine 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 grafici in particolare.
Evento Un evento è qualcosa che accade durante il corso del processo
di business. Questi eventi influiscono sull’esito del flusso del processo e
solitamente sono caratterizzati da una causa (trigger) e da un effetto (result).
Vengono rappresentati per mezzo di un cerchio e ne esistono tre di base: gli
eventi di inizio, intermedi al processo e di fine (figura 4.6).
Attività Attivitàè un termine generico per indicare il lavoro che svolge
un qualche entità. Un’attività può essere atomica o composta. I tipi di
attività 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 (figura 4.7).

52 Capitolo 3. Standard degli Strumenti BPM
Figura 3.10: Evento BPMN
Figura 3.11: Attività BPMN

3.1. Standard grafici per la modellazione 53
Gateway Un gateway viene utilizzato per controllare la divergenza e
la convergenza di un flusso di sequenza. Quindi determinerà le operazioni
di branching, di forking, di merging e di joining dei vari percorsi di flusso.
Viene rappresentato come un rombo (figura 3.12).
Figura 3.12: Gateway BPMN
Flusso di sequenza Un flusso di sequenza viene utilizzato per mostrare
l’ordine con cui vengono eseguite le attività all’interno del processo (figura
3.13).
Figura 3.13: Flusso di sequenza BPMN
Flusso di messaggio Un flusso di messaggio viene utilizzato per mostrare
il flusso di messaggi tra due partecipanti che sono preparati a spedirli e a
riceverli (figura 3.14).
Figura 3.14: Flusso di messaggio BPMN
Associazione Un’associazione viene utilizzata per associare informazione
con gli oggetti di flusso. Oggetti testuali e grafici non di flusso possono essere
associati con quelli di flusso. Un’associazione può avere una direzione per

54 Capitolo 3. Standard degli Strumenti BPM
indicare il destinatario delle informazioni che trasporta se opportuno (figura
3.15).
Figura 3.15: Associazione BPMN
Pool Un pool rappresenta un partecipante in un processo. Inoltre serve
anche da contenitore grafico per partizionare un insieme di attività daaltri
pool (figura 3.16).
Figura 3.16: Pool BPMN
Lane Un lane rappresenta una sotto-partizione all’interno del pool che
si estende per l’intera lunghezza del pool sia in orizzontale che in verticale.
Viene utilizzato per organizzare e categorizzare le attività (figura 3.17).
Figura 3.17: Lane BPMN
Oggetto di dati Un oggetto di dati non ha alcun effetto sul flusso di
sequenza o di messaggio ma fornisce informazioni circa quelle attività che
richiedono di essere eseguite oppure cosa essere producono (figura 3.18).

3.1. Standard grafici per la modellazione 55
Figura 3.18: Oggetto di dati BPMN
Gruppo Un gruppo rappresenta un insieme di attività appartenenti
ad una singola categoria. Questo tipo di gruppo non influisce sul flusso di
sequenza delle attività all’interno del gruppo. Dato che le categorie possono
essere utilizzate per scopi di documentazione o di analisi, i gruppi rappresentano
l’unico modo per visualizzarle all’interno del diagramma (figura 3.19).
Figura 3.19: Gruppo BPMN
Annotazione Le annotazioni testuali sono un meccanismo per il modellista
per fornire ulteriori informazioni a chi leggere il diagramma BPD
(figura 3.20).
Con questi elementi è possibile descrivere la maggior parte dei processi
di business. Se volessimo dettagliare ulteriormente il diagramma con
delle specifiche del processo di business, questo richiederebbe l’utilizzo di
una notazione più avanzata che BPMN prevede. Mostriamo gli elementi
più importanti per la notazione avanzata. Per un quadro completo si
consiglia[28].

56 Capitolo 3. Standard degli Strumenti BPM
Figura 3.20: Annotazione BPMN
Tipologia di eventi Gli eventi possono avere una dimensione di flusso
e una dimensione riguardante la loro tipologia. Per quanto riguarda la prima
dimensione essi si dividono in (figura 3.21):
• Eventi di inizio: indicano che un particolare processo ha inizio. Vengono
rappresentati con un cerchio.
• Eventi intermedi: influiscono sull’andamento del flusso di processo ma
non iniziano ne terminano il processo. Vengono rappresentati con un
doppio cerchio.
• Eventi di fine: indicano la terminazione di un processo. Vengo rappresentati
con un cerchio il cui bordo è in grassetto.
Figura 3.21: Dimensione di flusso 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 identifica la funzione. Gli eventi di catching
vengono indicati con il simbolo non riempito mentre quelli di throwing con
il simbolo riempito. La figura 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 dell’evento

3.1. Standard grafici per la modellazione 57
• 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 è verificato un errore all’interno
del flusso di processo. Possono essere solo intermedi o di fine
• eventi di tipo “cancel”: vengono utilizzati per annullare gli effetti di
una transazione di business definita all’interno di un sotto-processo
• eventi di tipo “compensation”: vengono utilizzati per la gestione delle
eccezioni che possono verificarsi all’interno di un processo e servono
per effettuare 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 flusso
• eventi di tipo “signal”: viene inviato un segnale all’interno del processo
che viene diffuso in modalità broadcast a tutti i partecipanti
a differenza dei messaggi che hanno una sorgente e un destinatario
definiti
• eventi di tipo “terminate”: vengono utilizzati per terminare immediatamente
tutte le attività all’interno di un processo
• eventi di tipo “multiple”: indicano l’esistenza di molteplici trigger
riguardanti l’evento.
Tipologia di attività Le attività si dividono in: task, processo o
sotto-processo. In particolare:
• un task rappresenta un’unità atomica di attività che è inclusa all’interno
di un processo. Viene utilizzato quando l’attività non è
ulteriormente decomponibile (figura 3.23).
• un sotto-processo è un’attività composta che viene inclusa all’interno
di un processo. Graficamente può essere visualizzata completamente
(figura 3.25) oppure viene visualizzata in modalità “collassata” (figura
3.24) con il simbolo “+” che sta ad indicare questa tipologia.

58 Capitolo 3. Standard degli Strumenti BPM
Figura 3.22: Tipologie degli eventi BPMN

3.1. Standard grafici per la modellazione 59
Figura 3.23: Attività atomica BPMN
Figura 3.24: Sotto-processo “collassato” BPMN
Figura 3.25: Sotto-processo esteso BPMN

60 Capitolo 3. Standard degli Strumenti BPM
Tipologie di gateway Come è possibile notare in figura 3.26, esistono
diverse tipologie di gateway. In particolare:
• Gateway esclusivi: definiscono una scelta da fare nel flusso di processo.
Questa scelta può essere basata su dati oppure su evento.
• Gateway inclusivi: definiscono una o più scelte che vengono prese nel
flusso di processo. La scelta di un percorso nel flusso di processo non
esclude le altre.
• Gateway complessi: sono stati definiti per trattare quelle situazioni
che non è possibile affrontare con gli altri tipi di gateway. Ad esempio
l’unione di più gateway.
• Gateway paralleli: definiscono l’esecuzione di più attività in parallelo.
Figura 3.26: Tipologie di gateway BPMN
Tipologie di flussi di sequenza La notazione BPMN definisce diversi
flussi di sequenza del processo di business. Abbiamo già descritto due
tipologie di flussi di sequenza: il flusso normale e il flusso di messaggio. Oltre
a queste due tipologie ne esistono altre:
• Flusso di default: viene utilizzato nelle decisioni di flusso di processo,
sia inclusive che esclusive, e stabilisce quale sia la condizione di flusso di

3.1. Standard grafici per la modellazione 61
default. Il suo simbolo è caratterizzato dall’avere uno slash diagonale
all’inizio della linea (figura 3.27).
• Flusso di eccezione: viene utilizzato per definire le deviazioni del flusso
di processo rispetto al flusso normale. Queste eccezioni dal normale
flusso di processo vengono attivate mediante l’utilizzo di un evento
intermedio (figura 3.28).
• Flusso condizionale: è un flusso di sequenza avente un espressione
condizionale che viene valutata a runtime per determinare quale flusso
dovrà seguire il processo (figura 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 definire parti del processo come
transazioni. Nella notazione BPMN una transazione è un sotto-processo che
contiene un flusso di processo che è sottoposto ai meccanismi di gestione delle

62 Capitolo 3. Standard degli Strumenti BPM
transazioni. Nella notazione BPMN una transazione viene rappresentata
con doppio riquadro come mostra la figura 3.30. Per gestire il fallimento di
una transazione, BPMN permette di modellizzare il meccanismo di compensazione
(figura 3.31). Questo permette al flusso di processo interno ad una
transazione di deviare dal flusso normale in modo tale da rendere consistente
il risultato della transazione.
Figura 3.30: Transazione BPMN
Figura 3.31: Compensazione BPMN
Versioni BPMN considerate e differenze
Ai fini della valutazione degli strumenti BPM, vengono considerate tutte le
versioni della notazione BPMN. Queste sono sostanzialmente due: la versione
1.x (1.1, 1.2) e la versione 2.x (2.0). Nonostante la versione 2.0 della
notazione sia ancora in fase di approvazione da parte del Object Management
Group, questa viene già implementata in alcuni strumenti BPM come
vedremo nel capitolo 5. Per questo motivo anche questa versione della no-

3.2. Standard dei formati di interscambio 63
tazione verrà presa in considerazione nella nostra analisi. La versione 2.x
della notazione nasce dall’esigenza di semplificare la notazione 1.x e allo stesso
tempo estende il suo potere descrittivo. Infatti esperimenti circa l’utilizzo
della versione 1.x hanno dimostrato che meno del 20% degli elementi della
notazione viene regolarmento utilizzato, alcuni costrutti non vengono mai
utilizzati nei modelli analizzati e il modello di processo di business medio
contiene meno di 10 elementi BPMN [25]. La specifica BPMN 2.0 estende
le funzionalità di BPMN 1.2 in molte aree [29]:
• Formalizza le semantiche di esecuzione per tutti gli elementi BPMN
• Definisce un meccanismo di estensione sia per quanto riguarda il modello
di processo sia per gli elementi grafici
• Perfeziona la composizione e correlazione tra eventi
• Estende la definizione delle interazioni umane
• Definisce un modello per la coreografia tra processi
Inoltre, questa nuova versione della specifica risolve anche le inconsistenze e
le ambiguità della versione 1.x della notazione. Per una trattazione esaustiva
delle modifiche introdotte nella versione 2.0 si consiglia [29].
3.2 Standard dei formati di interscambio
La necessità di avere dei formati standard di interscambio di processi di
business nasce quando una definizione di processo di business deve essere
trasferita da uno strumento BPM ad un altro. Questo trasferimento richiede
che lo strumento BPM, dal quale la definizione del processo di business
deve essere trasferita, la esporti in un file che sia conforme ad un formato
di interscambio tale che lo strumento BPM che lo riceve sia in grado di
importare la definizione del processo di business correttamente. Inizialmente
molti produttori definivano un loro formato di interscambio in modo tale da
trasferire le definizioni dei processi di business da una versione all’altra dei
loro strumenti BPM. Quando invece è sorta, da parte degli utenti degli
strumenti BPM, la necessità di trasferire il processo di business descritto da
uno strumento BPM di un produttore a quello di un altro produttore, allora
è nata anche l’esigenza di definire un formato comune.
Secondo [24], gli standard di interscambio dei processi di business sono
necessari principalmente per due scopi:

64 Capitolo 3. Standard degli Strumenti BPM
1. tradurre gli standard grafici che descrivono i processi di business in
standard di esecuzione
2. permettere il trasferimento dei modelli dei processi di business tra
strumenti BPM di diversi produttori
Attualmente esistono due standard di interscambio significativi:
1. Business Process Definition Metamodel (BPDM)
2. XML Process Definition Language (XPDL)
Il secondo standard di formato di interscambio citato sarà l’argomento del
paragrafo 3.2.1. Infatti è lo standard di interscambio che prendiamo in
considerazione in quanto diventato standard de facto tra i produttori di
strumenti BPM.
Descriviamo brevemente il formato BPDM. Business Process Definition
Metamodel è un formato proposto dal Object Management Group (OMG).
Secondo gli autori del formato, BPDM è in grado di rappresentare e di
modellizzare i processi di business in maniera indipendente dalla notazione
o dalla metodologia utilizzata, uniformandoli in un unico formato [27]. Come
si evince dal nome del formato stesso, questo èinrealtà un meta-modello
che serve per descrivere gli elementi comuni presenti nelle definizioni dei
processi di business. Secondo l’Object Management Group:
Il meta-modello alla base di BPDM descrive i processi di business
in maniera molto generale e fornisce una sintassi XML per
immagazzinare e trasferire i modelli dei processi di business tra
i vari strumenti BPM e le varie infrastrutture. Molti strumenti
BPM, metodologie e tecnologie possono quindi mappare il loro
modo di descrivere, capire e implementare i processi di business
verso e attraverso BPDM.[27]
Di fatto un meta-modello è un modello astratto che contiene gli elementi
di base caratterizzanti diversi linguaggi di modellazione. Questo significa
che BPDM lavora come un traduttore tra diversi linguaggi standardizzati
entro una comune piattaforma. La figura 3.32 mostra i linguaggi correnti
che BPDM è in grado di tradurre.
Allo stato attuale, BPDM non viene utilizzato da nessun strumento
BPM. Le motivazioni dello scarso interesse di questo formato e della sua
mancata implementazione in nessuno strumento BPM disponibile sono dovute
al fatto che viene definito uno standard di interscambio complesso da utilizzare
e non user-friendly [22].

3.2. Standard dei formati di interscambio 65
Figura 3.32: Meccanismo di interscambio BPDM
3.2.1 XML Process Definition Language
XML Process Definition Language è lo standard di interscambio proposto
dal Workflow Management Coalition (WfMC) ed è diventato lo standard de
facto tra i produttori di strumenti BPM. Secondo gli autori del formato [45],
l’obiettivo di XPDL è quello di diventare lo standard per la rappresentazione
e lo scambio delle definizioni dei processi di business tra strumenti BPM di
diversi produttori che utilizzano differenti tecniche di modellazione oppure
tra strumenti che hanno altri scopi di applicazione, come ad esempio l’engine
di esecuzione, il cui scopo non è quello di descrivere un processo di business
ma quello di metterlo in esecuzione. La figura 3.33 mostra le possibilità
di interscambio di processi descritti in XPDL con diversi strumenti BPM e
componenti di questi.
La sintassi di XPDL viene definita da un documento XML Schema. I
principali concetti su cui si basa il linguaggio sono gli stessi del modello di
workflow descritto dal WfMC e ripreso nel capitolo precedente:
• package
• applicazioni
• partecipanti
• campididatietipididati
• processi di workflow
• attività
• transizioni

66 Capitolo 3. Standard degli Strumenti BPM
Figura 3.33: Interscambio di processi di business descritti in XPDL con diversi strumenti

3.2. Standard dei formati di interscambio 67
Questi sono i concetti di base che fanno parte del meta-modello di XDPL.
La figura 3.34 mostra le relazioni di questi elementi con il meta-modello.
Questi elementi fanno parte dell’insieme minimale di costrutti nel dominio
dei workflow che il linguaggio XPDL mette a disposizione e che sono condivisi
da tutti gli strumenti BPM. Uno strumento BPM avrà necessità di
salvare in formato XPDL anche altri dati non presenti nei costrutti base
del linguaggio. Per questo motivo, XPDL mette a disposizione tre tipi di
elementi che permettono di aggiugere informazione relativa al particolare
strumento BPM:
1. Attributi estesi: possono essere utilizzati in tutti gli elementi di XPDL.
Essi contengono informazioni specifiche del particolare strumento BPM
che non possono essere rappresentate mediante gli elementi standard.
Questi attributi vengono rappresentati da coppie di tipo nome-valore.
2. Parametri formali: vengono utilizzati per rappresentare i parametri di
input e output dei processi e delle applicazioni di workflow. Questi
parametri vengono rappresentati mediante un identificatore univoco e
un attributo che definisce la semantica del parametro passato.
3. Riferimenti esterni: possono essere utilizzati con i tipi di dato, i partecipanti
e le applicazioni. Un riferimento esterno indica l’URI di un
documento di specifica esterno al contesto, il quale potrebbe essere un
XML Schema. Questi riferimenti vengono spesso utilizzati per riferirsi
ai servizi offerti dai Web Service.
Andiamo a descrivere nel dettaglio gli elementi costituenti il linguaggio.
Package Il package è l’elemento radice di ogni documento XPDL. Esso
ha la funzione di contenitore dove immagazzinare processi di workflow
multipli e informazioni condivise circa i campi di dati, la dichiarazione di
applicazioni e la specifica dei partecipanti.
Applicazione L’elemento Application include tutte le informazioni
necessarie per invocare le operazioni che deve svolgere un’applicazione. Questa
può essere inclusa o in un package o in un elemento di processo di workflow.
Nel primo caso avrà scope globale mentre nel secondo caso avrà scope
locale nel processo dove questa è stata definita.
Partecipante I partecipanti rappresentano le risorse che possono essere
eseguire le attività di un processo di workflow. Le informazioni rilevanti

68 Capitolo 3. Standard degli Strumenti BPM
Figura 3.34: Meta-modello del linguaggio XPDL

3.2. Standard dei formati di interscambio 69
sui partecipanti vengono definite nell’elemento Participant, che èelemento
figlio di un package oppure di un processo di workflow. Se un partecipante
viene dichiarato in un package allora ha scope globale mentre se viene
dichiarato in un processo di workflow ha scope locale nel processo dove è
stato definito. Le politiche di assegnazione delle attività ai partecipanti
vengono definite in ogni attività.
Campididatietipodidati I campi di dati (Data Fields) rappresentano
le variabili che catturano i dati rilevanti del workflow. Possono
essere utilizzati ad esempio per specificare le condizioni di deadline delle attività
oppure come parametri che devono essere scambiati tra le attività del
processo. Ogni campo di dato possiede un identificatore e un attritubo che
ne indica il nome. Questi campi di dati possono avere diversi tipi. XPDL
definisce nove tipi di dati (figura 3.35). Altri tipi possono essere definiti.
Figura 3.35: Tipi di dato XPDL
Processo di workflow Un processo di workflow viene definito dall’elemento
Workflow-Process che è figlio dell’elemento Package. Questo elemento
agisce come container per gli altri elementi che sono rilevanti alla descrizione
di un processo di workflow. Il flusso di controllo di un processo di workflow
viene definito da attività e transizioni tra queste.
Attività Il lavoro che deve essere eseguito all’interno di un processo
di workflow viene definito da un insieme di attività che sono elementi figlio
dell’elemento Workflow Process. Un’attività rappresenta un task che viene
eseguito nel processo di workflow. La sua esecuzione potrebbe coinvolgere

70 Capitolo 3. Standard degli Strumenti BPM
campi di dati, partecipanti e applicazioni. Le attività possono essere raggruppate
in blocchi. In questo caso da un punto di vista del processo di
workflow questi blocchi vengono considerate delle singole attività.
Transizioni Le transizioni definiscono le condizioni che mettono in
esecuzione le attività durante l’esecuzione di un workflow. Essi rappresentano
il flusso di controllo attraverso archi diretti tra i nodi di attività inun
processo di workflow.
La versioni considerate ai fini della nostra analisi sono 3: la versione
1.0, la versione 2.0 e la versione 2.1. Le versioni 2.0 e 2.1 del linguaggio
non mostrano cambiamenti significativi in quanto appartengono alla stessa
famiglia di versione. Invece la versione 2.x del linguaggio contiene miglioramenti
nella definizione dei suoi elementi e introduce elementi nuovi rispetto
la versione 1.0. Tuttavia la versione 2.x mantiene la retrocompatibilità con
la versione 1.x.
Per ulteriori informazioni sul linguaggio XPDL e per visionare esempi di
utilizzo si rimanda a [45].
3.3 Standard di esecuzione dei processi di business
Gli standard di esecuzione permettono ai processi di business progettati
di essere distrubuiti nei sistemi BPM e di essere eseguiti dai BPM engine.
Attualmente esiste uno standard che viene utilizzato da diversi produttori
di strumenti BPM: BPEL4WS detto anche brevemente BPEL.
BPEL4WS è un linguaggio basato su XML per specificare processi di
business nel contesto dei Web Service [1] specificato dal consorzio OASIS
(Organization for the Advancement of Structured Information Standards).
Per questa ragione, BPEL4WS viene utilizzato insieme alle tecnologie che
compongono i Web Service, come Web Service Execution Language (WSDL)
descritte in 2.2.3, permettendo di fatto di definire il processo di business in
base alle invocazioni dei Web Service esistenti e al tipo di interazione del
processo con i partecipanti esterni.
Dal punto di vista dei creatori del linguaggio BPEL4WS, i processi di
business possono essere descritti come [1]:
• Processi di business eseguibili: modelli che descrivono i dettagli e il
comportamento di un partecipante all’interazione di business.
• Protocolli di business: descrizioni che specificano le modalità di scambio
di messaggi tra le parti coinvolte nel protocollo, senza rivelare il

3.3. Standard di esecuzione dei processi di business 71
comportamenteo interno e i dettagli del processo. Le descrizioni del
processo per i protocolli di business vengono chiamati processi astratti.
Dalle due descrizioni si evince che la logica completa di un processo di business
viene descritta mediante un processo eseguibile mentre le procedure
di scambio dei messaggi tra i partecipanti vengono modellizzate mediante i
processi astratti. Un processo di business scritto in BPEL4WS consiste in
due tipi di file:
1. Il file BPEL4WS, codificato in XML, indica la definizione stateful del
processo, includendo le sue attività, i link ai partner, le variabili e gli
event handler.
2. I file Web Service Definition Language (WSDL) specificano le interfacce
Web Service stateless che sono di interesse al processo definito
nel file BPEL.
Gli elementi di base di un documento BPEL4WS, strutturati in sintassi
XML, sono stati largamente influenzati dai concetti descriventi i Web Service
[23]:
• Roles dei partecipanti del processo
• Port Types richiesti dai partecipanti
• Orchestration, rappresenta l’attuale flusso di processo
• Correlation information, definisce come i messaggi possono essere instradati
alle corrette istanze di composizione
Le attività BPEL4WS possono essere attività di base oppure attività strutturate:
le prime corrispondono ai componenti del processo di business.
Queste attività sono realizzate attraverso le interazioni tra Web Service (ad
esempio attraverso invocazioni di operazioni WSDL). Le attività strutturate,
invece, ricordano le strutture di controllo dei linguaggi di programmazione
convenzionali. Essi costituiscono la parte orientata al blocco di una descrizione
BPEL4WS. BPEL4WS specifica inoltre gli handler per gli eventi e
le situazioni di failure: BPEL4WS permette di definire le attività per gestire
questi eventi.
L’esecuzione del processo viene racchiusa dall’elemento ¡flow¿ e l’ordine
di esecuzione tra le attività del processo viene gestito dagli elementi ¡link¿.
Questi assumono un ruolo chiave durante la conversione tra un modello di
processo di business, descritto in un linguaggio di modellazione (ad esempio
BPMN), e un processo eseguibile. Mostriamo ora la struttura di base di un
processo di business descritto in BPEL4WS:

72 Capitolo 3. Standard degli Strumenti BPM
?
+
*
?
+
?
+
?
+
from-spec?
?
+
?
*

3.3. Standard di esecuzione dei processi di business 73
activity
?
activity
?
*
?
+
?
+
...
*
(
duration-expr
|
deadline-expr
)?
duration-expr
?
...
activity
Per una descrizione accurata del linguaggio si rimanda a [1].
Uno degli svantaggi di BPEL4WS èquellochenontieneinconsider-

74 Capitolo 3. Standard degli Strumenti BPM
azione l’interazione tra processo e interfaccia utente, cioè non tiene in considerazione
il comportamento degli agenti umani che interagiscono con il
processo. Per questo motivo è stata definita un’estensione del linguaggio
BPEL4WS che tiene in considerazione questo aspetto: BPEL4PEOPLE
[11]. Questa estensione del linguaggio BPEL4WS introduce un insieme di elementi
che estendono gli elementi BPEL4WS e permette la modellazione di
interazioni umane, che potrebbero riguardare semplici approvazioni oppure
scenari complessi come la separazione di task tra agenti umani.
BPEL4PEOPLE si fonda principalmente sui seguenti concetti:
• Definizione di ruoli umani generici relativi al processo: questi ruoli
generici vengono assegnati a singoli agenti umani o a gruppi di essi e
definiscono quali azioni questi agenti possono intraprendere con l’istanza
di processo in esecuzione. Sono presenti tre tipi di ruoli umani
generici relativi al processo:
1. Process initiator
2. Process stakeholders
3. Business administrators
Il process initiator è l’agente umano associato all’attivazione dell’istanza
del processo a tempo di creazione. Viene determinato automaticamente
dal sistema e deve esserne presente almeno uno a tempo di
esecuzione. I process stakeholders sono gli agenti umani che possono
influenzare il progresso dell’istanza del processo. Ad esempio possono
aggiungere un documento ad-hoc oppure mandare avanti un task. I
business administratos sono gli agenti umani a cui è permesso eseguire
azioni di tipo amministrativo sul processo di business, ad esempio la
gestione delle deadline mancate. Un amministratore di processo ha
interesse di tutte le istanze di un particolare tipo di processo e non
solo di uno.
• Assegnamento di risorse umane a task specifici: Per determinare quale
agente umano sia responsabile per l’esecuzione di un determinato processo,
un task umano oppure per l’assegnazione di un particolare ruolo,
questo deve essere assegnato al task dall’engine di esecuzione del
processo.
• Scambio di dati ad-hoc: I processi possono avere dati ad-hoc riguardanti
attività umane. Gli agenti umani devono essere in grado di manipolarli
e di propagarli verso nuove attività che possono essere sia umane
oppure di sistema.

3.3. Standard di esecuzione dei processi di business 75
L’attività umana (People Activity) è l’attività di base utilizzata per integrare
le interazioni umane con i processi BPEL4WS. Vi possono essere
quattro tipi di integrazione come mostra la figura 3.36:
Figura 3.36: Tipologie di integrazione delle interazioni umane con delle attività umane
1. Nel primo caso in figura 3.36, il task umano (inline human task) risiede
all’interno dell’attività umana e la sua esecuzione è limitata entro
quella particolare attività di quel particolare processo.
2. Nel secondo caso in figura 3.36, il task umano può essere utilizzato
più volte per differenti istanze di attività umane, favorendone il riuso,
sempre nello stesso processo.
3. Nel terzo caso in figura 3.36, vediamo com l’attività umana può integrare
un task umano presente nello stesso ambiente di esecuzione ma
che non fa parte del processo. BPEL4PEOPLE permette di definire le
modalità di comunicazione tra il processo e un task umano che non fa
parte del processo ma è presente nello stesso ambiente di esecuzione.
4. Nel quarto caso in figura 3.36, il task umano risiede in un altro ambiente
di esecuzione rispetto a quello dove è presente il processo. In
questo caso l’attività umana del processo invoca il task umano mediante
i protocolli tipici dei Web Services.
Gli elementi di tipo BPEL4PEOPLE vengono indicati da tag che mostrano
come intestazione ¡b4p:¿ in un file BPEL4PEOPLE. Il seguente codice
mostra la struttura base dell’estensione BPEL4PEOPLE in un file BPEL4WS:

76 Capitolo 3. Standard degli Strumenti BPM
...
...
?
?
+
...
?
+
...
?
+
...
/b4p:humanInteractions>
...
...
...

3.3. Standard di esecuzione dei processi di business 77
...
Per ulteriori approfondimenti sulla sintassi del linguaggio si consiglia
[11].

78 Capitolo 3. Standard degli Strumenti BPM

Capitolo 4
Analisi degli Strumenti BPM
Il capitolo descrive l’obiettivo dell’analisi oggetto della presente tesi, la
metodologia proposta e i criteri di selezione degli strumenti BPM che saranno
in seguito analizzati.

80 Capitolo 4. Analisi degli Strumenti BPM
4.1 Obiettivi dell’analisi
L’obiettivo di questa analisi consiste nel fornire una valutazione oggettiva
dei vari strumenti BPM presenti sul mercato, prendendone in considerazione
i vari aspetti. Questa valutazione nasce da una duplice esigenza. La prima
è di definire un framework di valutazione in modo tale da poter valutare in
maniera oggettiva uno strumento BPM; questa analisi dovrebbe mettere in
risalto le caratteristiche di uno strumento BPM, in modo tale da poter valutare
se esso risulti idoneo per gli obiettivi di un progetto BPM che si intende
realizzare. La seconda esigenza è di scattare un’istantanea delle soluzioni
BPM presenti sul mercato (sia commerciali che open source) e applicare il
metodo di valutazione definito in modo da far emergere gli strumenti BPM
che dimostrino di essere più completi, sia dal punto di vista delle funzionalità
che sotto altri aspetti (ad esempio l’usabilità), rispetto ai loro concorrenti.
Il risultato delle analisi è una classificazione di questi strumenti BPM che
può essere sfruttata da chiunque abbia necessità di dover modellizzare e
mettere in esecuzione un processo di business, così da scegliere lo strumento
più idoneo alle proprie esigenze e a quelle del proprio processo di business.
4.2 Scelta degli strumenti BPM da analizzare
Il presente paragrafo illustra le modalità con cui sono stati selezionati gli
strumenti BPM oggetto dell’analisi.
Il primo problema che è stato riscontrato nell’affrontare questo tipo
di analisi è la scelta degli strumenti da esaminare. Attualmente esistono
una molteplicità di soluzioni BPM nel mercato e il loro numero sembra
aumentare [19]. Queste soluzioni BPM si differenziano in base al tipo di
processi di business che devono gestire. Il tipo di processi di business può
essere definito in base alla loro complessità e alla loro predicibilità [8]. La
complessità di un processo consiste nello stabilire se esiste o meno una certa
ripetitibilità delle attività componenti il processo e se seguono determinate
regole di coordinamento. Processi con attività ripetibili sono più facilmente
gestibili rispetto a processi aventi attività che non hanno un pattern definito
di esecuzione. La predicibilità di un processo può essere di quattro tipi:
1. Unframed: il processo non è associato ad un modello esplicito di processo.
Un esempio di questi processi sono quelli collaborativi che vengono
gestiti dai sistemi di groupware perchè non offrono la possibilità
di modificare questi tipi di processi.

4.2. Scelta degli strumenti BPM da analizzare 81
2. Ad hoc framed: il processo è associato ad un modello esplicito di
processo. Tuttavia viene eseguito una volta sola. Un esempio di questi
processi sono i scientific workflows.
3. Loosely framed: il processo è associato ad un modello esplicito di processo
e ad un insieme di vincoli. Il flusso di processo segue dei percorsi
prestabiliti che però non sono rigidi, ma permettono al processo di deviare
entro certi limiti. Queste deviazioni vengono gestite da sistemi
di case handling.
4. Tightly framed: il processo è associato ad un modello esplicito di
processo ed è consistente con questo.
Un altro fattore che permettere la distinzione tra processi di business è
il loro grado di automazione. Questa distinzione porta a classificare i processi
in tre categorie: Person to Person (P2P), Person to Application (P2A)
e Application to Application (A2A). I processi P2P richiedono l’intervento
umano per poter essere eseguiti. I sistemi software che gestiscono questi tipi
di processi sono i sistemi groupware. I processi P2A sono quelli che contengono
attività che in parte deve essere eseguite da agenti umani e in parte
da agenti software. I sistemi che gestiscono questi sistemi sono tipicamente
i sistemi di workflow. I processi A2A consistono di attività che vengono eseguite
esclusivamente da agenti software. I sistemi che gestiscono i processi
A2A sono tipicamente sistemi EAI (Enterprise Application Integration), sistemi
che amministrano le transazioni e web service. La distinzione di questi
tre processi non è netta ma è caratterizzata da un continuum lungo il quale
si collocano varie tipologie di sistemi di workflow (vedi figura 4.1).
Figura 4.1: Il continuum di automazione dei processi di business
Se mettiamo in correlazione il grado di predicibilità di un processo con
il suo grado di automazione, otteniamo il grafico di figura 4.2 che mostra le
varie categorie di prodotti per la gestione dei processi risultanti.

82 Capitolo 4. Analisi degli Strumenti BPM
Figura 4.2: Tipologie di processi e i relativi strumenti di gestione
Della classificazione dei vari sistemi di gestione dei processi appena fatta,
siamo interessati agli strumenti che gestiscono processi P2A. Da questa
preliminare scelta, abbiamo deciso di affrontare il processo di selezione degli
strumenti BPM in due fasi. La prima fase ha preso in considerazione 53
strumenti BPM che andremo ad elencare:
1. ActiveVOS
2. Adobe Livecycle ES
3. AgilePoint BPMS
4. Appian Enterprise
5. Aptitute BPMS
6. ARIS Process Performance Manager
7. AuraPortal BPMS
8. Avantage BPM
9. Billfish BPM
10. BizAgi Process Modeler
11. BizFlow BPM

4.2. Scelta degli strumenti BPM da analizzare 83
12. BPM one
13. Business Process Visual Architect
14. Comprehend
15. Cordys Business Operations Platform
16. eBPMN
17. EMC BPMS
18. expressFlow
19. FlexoBPM
20. Fujitsu Interstage BPM
21. Genexus BPM Suite
22. IBM WebSphere Dynamic Process Edition
23. iGrafx
24. Intalio Enterprise Edition
25. Integrify 4.5 request management software
26. InterSystems Ensemble
27. iPB - interactive Process Builder
28. jBPM
29. K2 Blackpearl
30. Lombardi Teamworks
31. M3O BPMS
32. Metastorm BPM
33. OmniFlow
34. Open ModelSphere
35. openwork
36. Oracle BPM Suite

84 Capitolo 4. Analisi degli Strumenti BPM
37. Polymita Business Suite
38. Process360, with Insight360
39. QPR ProcessGuide
40. Questetra BPM Suite
41. RunMyProcess
42. SAP NetWeaver BPM and SAP NetWeaver BRM
43. Savvion BusinessManager
44. Select Architect
45. SEQUENCE BPM
46. Singularity Process Platform
47. Skelta BPM.NET
48. SmartBPM Suite
49. Tibco iProcess
50. TLM Reconciliations, TLM Web Connect
51. Ultimus Adaptive BPM Suite
52. webMethods BPMS
53. YAWL
Di questi strumenti è stato raccolto ed analizzato tutto il materiale
disponibile dai produttori. Il fine di questa analisi è quello di poter fare
una prima selezione a grana grossa, in modo da individuare gli strumenti su
i quali vale la pena applicare il metodo di valutazione. I criteri di selezione
valutati a pari peso nella selezione, sono stati:
1. quantità di informazione messa a disposizione dal produttore sullo
strumento BPM
2. possibilità di poter testare una versione di prova dello strumento
3. valutazioni precedenti fatte da altri valutatori (come, ad esempio,
Gartner Group [19])

4.2. Scelta degli strumenti BPM da analizzare 85
Al termine di questa prima fase sono stati individuati gli strumenti su
cui si concentrerà la valutazione. Come più avanti ricorderemo, alcuni strumenti
che ci sono stati forniti non contengono tutte le funzionalità cheinvece
sarebbero disponibili comprando la licenza completa del prodotto. Per
questo motivo, i componenti di uno strumento BPM che non è stato possibile
testare direttamente, sono valutati in base a quanto dichiarato dal
produttore. Gli strumenti BPM individuati sono i seguenti:
1. Adobe LiveCycle ES
2. AgilePoint BPMS
3. Avantage BPM
4. BillFish BPM
5. BizAgi BPM
6. BP Visual Architect
7. eBPMN
8. Genexus BPMS
9. IBM WebSphere Dynamic Process Ed
10. iGrafx
11. Intalio EE
12. jBPM
13. Lombardi BluePrint
14. Metastorm BPM
15. Oracle BPM
16. Process360
17. ProcessPAD
18. Questetra BPM
19. Savvion BPM
20. Tibco BS
21. YAWL

86 Capitolo 4. Analisi degli Strumenti BPM
Una volta individuati questi strumenti, è stato applicato il modello di
valutazione descritto nel paragrafo 4.4 e i dati sono stati registrati in appositi
fogli di calcolo descriventi il modello di valutazione e poi successivamente
rielaborati. Ogni strumento BPM è stato installato in un ambiente di test
compatibile con i suoi requisiti ed è stato testato implementando il processo
BPMN di riferimento che descriveremo nel paragrafo 4.3. Quindi possiamo
affermare che per ogni strumento BPM considerato, è stato portato a
termine un caso di studio, il quale ha permesso di determinare i valori di
valutazione.
4.3 Processo di business di riferimento
Il processo di business scelto come riferimento per la valutazione di uno strumento
BPM riguarda un processo di votazione tramite e-mail. Questo processo
è descritto nella documentazione della specifica della notazione BPMN
da parte del WfMC [28]. In figura 4.3 viene mostrato il processo. Il modello
descritto mira a risolvere dei problemi inerenti ad un processo di votazione
per mezzo di e-mail per prendere delle decisioni sulla risoluzione di diversi
problemi. Il punto di vista di questo processo è quello del manager della lista
dei problemi e della discussione che la coinvolge. Da questo punto di vista i
membri votanti del gruppo di lavoro sono considerati come dei partecipanti
esterni del processo che comunicano con il manager per mezzo di messaggi.
Andiamo a descrivere le varie parti che compongono questo modello.
Il processo inizia con un evento temporale di inizio che viene impostato
affinché il processo inizi ogni venerdì (figura 4.4). Il manager riceve la lista
dei problemi (issue list), passa in rassegna la lista per determinare se vi
siano dei problemi pronti ad essere discussi ed essere messi sotto votazione.
Se esistono, allora una decisione deve essere presa su questi per mezzo di un
processo di discussione mentre se non esistono il processo termina.
Il task “Discussion Cycle” è un sotto-processo ciclico che rappresenta il
task di discussione (figura 4.5). Questo sotto-processo possiede due flussi
in entrata in cui uno proviene da una decisione che viene fatta a valle del
processo e che fa parte quindi di un ciclo all’interno del processo. Andiamo a
dettagliare il sotto-processo “Discussion Cycle”. Il sotto-processo incomincia
con il manager della lista che annuncia via e-mail la presenza di problemi
su cui è necessario prendere una decisione. Poiché questo task invia un messaggio
verso i partecipanti esterni, un message flow parte dal sotto-processo
“Discussion Cycle” verso i membri votanti. Dopo il primo task seguono tre
percorsi paralleli separati (fork) che si sincronizzano al termine del sottoprocesso.
Il primo percorso inizia con un task la cui durata è sette giorni

4.3. Processo di business di riferimento 87
Figura 4.3: Processo di riferimento riguardante votazione tramite e-mail

88 Capitolo 4. Analisi degli Strumenti BPM
Figura 4.4: Inizio del processo
Figura 4.5: Sotto processo “Discussion Cycle”

4.3. Processo di business di riferimento 89
e consiste nella moderazione la discussione via e-mail. Dopo sette giorni
l’evento intermedio temporale termina il task per iniziare un task di revisione
sullo stato della discussione. Il secondo percorso contiene un evento
temporale intermedio e un task. Dopo sei giorni un messaggio di avviso di
scadenza del tempo utile per inviare il voto viene spedito ai partecipanti
votanti. Il terzo percorso inizia con un task per mezzo del quale il manager
della lista dei problemi controlla il calendario per vedere se è fissato un incontro
per una conferenza. Il risultato di questo task sarà un aggiornamento
della variabile booleana “ConCall”. Questa variabile servirà per scegliere il
flusso di percorso da intraprendere all’arrivo nel gateway esclusivo. La prima
scelta segue il flusso di default mentre il secondo, con valore “vero” della
variabile concall, porta ad un evento temporale intermedio al termine del
quale vi è il task di moderazione della discussione nella conferenza. Una
volta terminati questi tre percorsi appena descritti, i loro flussi di processo
si riuniscono in un gateway di unione (merging gateway) e, impostando il
valore della variabile booleana “DiscussionOver”, si assegna un valore alla
variabile di terminazione del ciclo.
Il secondo sotto-processo inizia con un task che coinvolge il manager del
processo (figura 4.6). Esso deve inviare ai partecipanti la segnalazione che
esiste una lista di problemi da votare (sempre con un flusso di messaggio).
Dopo questo task viene presentata una fork dalla quale partono quattro
flussi di progetto da eseguire in parallelo. Il primo flusso porta ad una decisione
che determina se è eventualmente disponibile una conferenza per la
prossima settimana. Il secondo e terzo flusso delle fork lavorano allo stesso
modo delle attività nel sotto-ciclo precedente eccetto per il task “moderate
e-mail discussion”. Questo task infatti non è connesso ad un evento temporale
intermedio. Questo non è necessario in quanto l’intero sottoprocesso è
interrotto dopo sette giorni attraverso un evento temporale intermedio. Il
quarto flusso è un ciclo infinito. La politica del gruppo di lavoro èchei
membri votanti possono votare più di una volta su una questione, nel senso
che possono cambiare idea quante volte desiderano nel corso della settimana.
Il primo task nel ciclo riceve un messaggio dal partecipante esterno mediante
un flusso di messaggio in entrata. La terminazione del ciclo infinito èdovuto
ad un evento temporale intermedio che sancirà la terminazione del tempo
utile per esprimere il proprio voto da parte dei partecipanti. I task rimanenti
si attiveranno allo scatenarsi di questo evento temporale: il primo si
occupa di preparare i risultati della votazione mentre il secondo si occuperà
dell’invio dei risultati ai membri votanti.
La figura 4.7 mostra la parte finale di questo processo, che include un
complesso insieme di decisioni e cicli. L’ultima parte del processo comincia

90 Capitolo 4. Analisi degli Strumenti BPM
Figura 4.6: Sotto processo “Collect Votes”

4.3. Processo di business di riferimento 91
Figura 4.7: Parte finale del processo di riferimento

92 Capitolo 4. Analisi degli Strumenti BPM
mostrando quattro gateway decisionali che interagiscono tra loro portando
alla creazione di cicli con le attività precedenti. Il primo nodo decisionale
chiamato “Did enough members vote?” è necessario in quanto si richiede che
almeno due terzi dei partecipanti alla votazione abbia effettivamente espresso
il proprio voto. Se meno dei due terzi dei membri votanti ha votato allora
le questioni non possono essere risolte. In questo caso il flusso di processo
converge nel successivo nodo decisionale “Have the members been warned?”.
Se la risposta è affermativa allora i membri con diritto di voto che non hanno
votato perdono la loro possibilità di votare e viene rifatto il conteggio dei
voti escludendo i non votanti. Se la risposta è negativa allora è necessario
che il sotto processo “Collect votes” venga ripetuto. A questo punto se tutte
le questioni sono state risolte allora il processo termina. Altrimenti un’altra
decisione è richiesta. Per la votazione sulle questioni rimanenti vengono
fatti due tentativi. Durante il primo si riducono le soluzioni possibili per
una questione limitando la scelta alle due soluzioni più votate. Quindi i
votanti che hanno espresso con il loro voto la preferenza verso una soluzione
non inclusa tra le due devono rivotare ritornando al task “Announce Issues
for Votes” descritto precedentemente. Se questo invece è il secondo tentativo
allora viene ripetuto il sotto-ciclo “Discussion cycle” per una nuova
discussione sulle questioni rimanenti e una nuova votazione.
4.4 Categorie di analisi e criteri di valutazione
Il paragrafo descrive in dettaglio il modello di valutazione proposto e le sue
categorie di analisi.
Per individuare un modello di valutazione dello strumento BPM, siamo
partiti dal ciclo di vita di un prodotto BPM proposto da van der Aaslt[38].
Abbiamo precedentemente descritto questo ciclo di vita che ricordiamo essere
composto da quattro fasi: progettazione di processo, configurazione del
sistema, attivazione del processo e analisi. Ognuna di queste quattro fasi è
importante per un sistema BPM.
Nella valutazione di uno strumento BPM, queste quattro fasi non sono
state ritenute sufficienti ai fini della valutazione. Innanzitutto manca una
valutazione dello strumento BPM circa la sua conformità agli standard. Per
questo motivo, la prima estensione del ciclo di vita di van der Aaslt èproprio
quella di aggiungere tale elemento di valutazione. Un’altra categoria di valutazione
aggiunta è stata quella inerente l’usabilità del prodotto. L’usabilitàè
quella disciplina che, in riferimento all’informatica, permette di determinare
quanto è usabile un determinato prodotto, cioè seilprodottosiasemplice

4.4. Categorie di analisi e criteri di valutazione 93
da apprendere e da utilizzare, appagando la cosidetta user experience del
prodotto[33].
Infine è stata introdotta un ulteriore estensione al ciclo di vita di un
BPM. Infatti sono stati presi in considerazione gli utenti target a cui il
particolare prodotto BPM in valutazione è rivolto. Come vedremo, sono stati
individuati tre tipi di utenti target: gli analisti di business, gli sviluppatori
e gli analisti-sviluppatori. Questa valutazione permette di orientare meglio
l’utente finale nella scelta dello strumento BPM che deve acquisire.
In totale come è possibile notare in figura 4.8, sono state individuate
7 categorie di valutazione per uno strumento BPM. Per ognuna di queste
categorie, sono state individuate alcune voci di valutazione a cui viene assegnato
un valore pesato in base all’importanza di quella voce per quella
categoria. Alla fine della valutazione si possono estrarre i dati per categoria
e confrontare gli strumenti BPM tra di loro in tutte le categorie. Nel paragrafo
seguente viene descritto in dettaglio il modello di valutazione appena
proposto.
4.4.1 Conformità agli standard
In questa categoria di analisi verrà valutata la conformità rispettoatre
tipi di standard dello strumento BPM. Per quanto concerne lo standard di
modellazione grafica viene considerato BPMN nelle sue 3 versioni disponibili.
Per quanto riguarda il formato di interscambio della descrizione del processo
di business tra i vari strumenti viene preso in considerazione X-PDL nelle
sue 3 versioni disponibili. Infine, come formati di esecuzione, vengono presi
in considerazione i formati BPEL4WS e BPEL4PEOPLE.
Conformità alla notazione BPMN
L’analisi di conformità alla notazione BPMN viene svolta implementando il
processo di riferimento descritto nella documentazione della specifica della
notazione [28] e nel paragrafo 4.3. Vengono presi in considerazione gli strumenti
che dichiarano la conformità alle varie versioni delle notazioni (BPMN
1.0, 1.1, 2.0). Le differenze tra le varie versioni della notazione sono state
già evidenziate nel capitolo precedente. Tuttavia questo processo mette
in risalto le varie caratteristiche della notazione e permette di fornire una
valutazione circa la conformità di questi strumenti BPM a questa notazione.
Dal punto di vista dell’analisi cercheremo di capire quanto di questo
processo è possibile descrivere con ogni strumento BPM che supporta la
notazione. Per valutare la loro conformità sono stati individuati 45 elementi
della notazione che devono essere presenti affinché lo strumento BPM preso

94 Capitolo 4. Analisi degli Strumenti BPM
Figura 4.8: Modello di valutazione proposto per gli strumenti BPM a partire dal modello
di van der Aaslt[38]: le sette categorie di valutazione

4.4. Categorie di analisi e criteri di valutazione 95
in considerazione possa dirsi completamente conforme alla notazione. In
tabella 4.1 vengono mostrati i vari elementi presi in considerazione:
Tabella 4.1: Elementi della notazione BPMN presi in considerazione
Event Conditional Flow
Start event Default Flow
Intermediate event Exception Flow
End event Message Flow
None event Compensation Association
Message event Data Object
Timer event Fork
Error event Join
Cancel event Exclusive gateway
Compensation event Data Based exclusive gateway
Link event Event Based exclusive gateway
Terminate event Inclusive gw
Signal event Complex gw
Multiple event Parallel gw
Conditional event Activity Looping
Task (Atomic) Sequence Flow Looping
Collapsed Sub Process Multiple Instances
Expended Sub Process Process Break
Gateway Transaction
Sequence Flow Group
Off Page Connector Text Annotation
Association
Lanes
Pool
Inoltre il processo di business considerato rappresenta il processo di riferimento
anche per quei strumenti BPM che non supportano la notazione,
permettendo così di portare a termine il caso d’uso anche per questi strumenti.
Conformità a XPDL, BPEL4WS e BPEL4PEOPLE
La conformità ai linguaggi di interscambio XPDL e poi quelli di esecuzione
BPEL4WS e BPEL4PEOPLE sono un parametro chiave nella valutazione
di questa categoria. Abbiamo già discusso nei capitoli precedenti dell’importanza
di una standardizzazione ai fini dell’interoperabilità tra strumenti
e piattaforme di gestione dei processi di business diversi.

96 Capitolo 4. Analisi degli Strumenti BPM
Per quanto riguarda il linguaggio di interscambio XPDL, viene verificata
la conformità del linguaggio nelle sue 3 versione (1.0, 2.0 e 2.1) secondo
le specifiche rilasciate dal Workflow Management Coalition (WfMC).
La verifica di conformità si base sia su quanto dichiarato esplicitamente dal
produttore sia da una verifica del file generato. Oltre al supporto al linguaggio,
viene in particolare verificata la possibilità di importare ed esportare le
descrizioni dei processi di business salvati in questo formato.
Lo stesso procedimento viene applicato per i formati di esecuzione BPEL4WS
e BPEL4PEOPLE. Questi ultimi saranno importanti ai fini della valutazione
del grado di interoperabilità di un’applicazione generata da un modello di
processo di business con altre applicazioni o servizi esterni (ad es. Web
service).
Tabella riassuntiva della valutazione della fase di valutazione sulla
conformità agli standard dello strumento BPM
Abbiamo descritto i 12 fattori di valutazione che abbiamo preso in considerazione
per quanto concerne la valutazione sulla conformità agli standard.
In tabella 4.2 schematizziamo questi fattori indicando i valori che possono
assumere.
Tabella 4.2: Tabella valutazione conformità agli standard
A)Conformità agli standard
A.1) Conformità BPMN1.1 0...1
A.2) Conformità BPMN1.2 0...1
A.3) Conformità BPMN2.0 0...1
A.4) Conformità X-PDL 1.0 SI/NO
A.5) Conformità X-PDL 2.0 SI/NO
A.6) Conformità X-PDL 2.1 SI/NO
A.7) Importazione X-PDL SI/NO
A.8) Esportazione X-PDL SI/NO
A.9) Conformità BPEL4WS SI/NO
A.10) Conformità BPEL4PEOPLE SI/NO
A.11) Importazione BPEL4WS / BPEL4PEOPLE SI/NO
A.12) Esportazione BPEL4WS / BPEL4PEOPLE SI/NO

4.4. Categorie di analisi e criteri di valutazione 97
4.4.2 Modellazione del processo di business
Nella fase di modellazione, il processo di business viene descritto mediante
o le notazioni viste precedentemente(BPMN, XPDL, ecc.) o per mezzo
di notazioni proprie dello strumento BPM considerato. In questa sezione
verranno presi in considerazione dei fattori riguardanti la fase di modellazione
di un processo di business. Andiamo a descrivere questi elementi di
valutazione.
Modello informativo
Il modello informativo di un workflow rappresenta le informazioni riguardanti
il processo di business e i tipi di dati che vengono scambiati tra i vari attori
del processo. Con questo modello vengono definiti i dati che un task riceve
in ingresso e i dati prodotti al termine della sua esecuzione. In uno strumentoBPMdisolitoquestomodellopuò
essere definito durante la fase di
modellazione grafica, impostando direttamente nelle proprietà dell’elemento
i dati in ingresso e in uscita, oppure può essere definito successivamente
alla fase di modellazione. Inoltre questo modello definisce le modalità di
interazione del sistema con una sorgente di dati esterna come può essere un
DBMS (database management system). Ad esempio nel processo di riferimento
considerato, il modello informativo potrebbe definire il formato con
cui deve essere trasmesso un voto da parte dei votanti oppure quello della
lista dei problemi (issue list) che viene distribuita tra i partecipanti.
Modello organizzativo
Il modello organizzativo descrive le risorse del processo e in quale relazione
sono tra loro. La conoscenza delle varie abilità di ogni risorsa permette al
workflow engine di poter assegnare le attività allarisorsachehalapossibilità
di portarlo a termine con maggiore efficienza ed efficacia rispetto alle
altre risorse. Inoltre permette di assegnare specifiche risorse a specifici task.
Ad esempio, un task il cui compito è quello di approvare un determinato
pagamento, deve necessariamente essere assegnato alla risorsa che detiene i
diritti di approvare una simile attività. Questo fattore di valutazione permette
di comprendere se lo strumento BPM analizzato consente la definizione
di tale modello.
Modello di transazione
Il modello di transazione definisce le modalità con cui vengono trattate
quelle parti di processo di business che devono essere considerate come delle

98 Capitolo 4. Analisi degli Strumenti BPM
transazioni. Queste parti del modello devono essere soggette alle proprietà
cosiddette ACID (atomicità, coerenza, isolamento, durabilità) e devono
fornire dei meccanismi cosiddetti di rollback nel caso sia necessario annullare
la transazione. Per fare questo devono essere implementati dei meccanismi di
cancellazione o di “failure” della transazione. Le proprietà ACID derivano
dal mondo dei database e sono state applicate ai processi di business in
quanto essi contengono attività che accedono a risorse condivise contenenti
dati persistenti, e quindi soggette a semantica transazionale. In particolare,
le proprietà di atomicità e di isolamento possono essere applicate con
grande utilità ai processi di business (o in parte di essi) [17]. Nel caso di una
transazione, se un’attività si interrompe, le precedenti attività della stessa
transazione devono poter essere in grado di eseguire un roll-back eseguendo
le loro transazioni di compensazione. Uno strumento BPM deve poter dare
la possibilità di definire il comportamento di una transazione per sotto-parti
del processo stesso.
Gestione delle eccezioni
La gestione delle eccezioni è un importante funzionalità di un sistema BPM,
il quale deve poter dare la possibilità di definire come gestire queste eccezioni.
Diversi sono i casi in cui è necessario gestire le eccezioni. Ad esempio un
utente che interagisce con un processo di business deve fornire dei dati al
processo mediante delle interfacce (form, email, ecc.). Oltre alla normale
interazione con i processi di business (che si riduce all’immisione di informazione
nelle form), l’intervento umano potrebbe essere anche necessario
per risolvere le eccezioni, in quanto non tutte le eccezioni possono essere
gestite in modo automatico. Gli utenti devono essere avvisati quando le eccezioni
necessitano del loro intervento. Eccezioni di tipo sincrono e asincrono
richiedono meccanismi differenti. Se un eccezione avviene in modo sincrono
durante l’esecuzione di un’attività di workflow, l’utente può essere avvisato
immediatamente mentre sta eseguendo quella attività; se invece avviene in
modo asincrono la notifica avviene all’esterno del flusso di processo [3]. In
entrambi i casi gli strumenti BPM devono fornire delle metodologie per la
gestione di queste eccezioni. In particolare devono definire come cambia il
flusso di processo una volta risolta l’eccezione, il quale o può essere mantenuto
oppure modificato [6]. Nel primo caso gestire l’eccezione e mantenere
il flusso di esecuzione comporta azioni quali:
• cambiare il ruolo o la risorsa richiesta per una attività
• cambiare i vincoli (per esempio la deadline) per una attività

4.4. Categorie di analisi e criteri di valutazione 99
• aggiungere utenti o risorse alle attività
Nel secondo caso, invece, gestire l’eccezione e modificare il percorso di esecuzione
comporta azioni quali:
• Salvare il progresso dell’istanza di processo
• Ripetere un’attività
• Scambiare gli utenti assegnati per una attività
• Scegliere un’alternativa esistente per l’esecuzione
• Saltare l’esecuzione di una attività
• Interrompere l’istanza di un’attività oppure quella di un intero processo
La presenza o meno della possibilità di poter definire la gestione delle eccezioni
è un criterio di valutazione dello strumento BPM.
Riuso
Il fattore riuso è un fattore importante in quanto permette di non riscrivere
da zero soluzioni che sono già state trovate in precedenza nella modellazione
di un flusso di processo di business. Infatti, se da un punto di vista dell’ingegneria
del software il riuso di componenti software è un metodo per migliorare
l’efficienza e la qualità del processo di progettazione, lo stesso accade nella
modellazione dei processi di business dove il riuso migliora l’efficienza e la
qualità dei modelli dei processi di business. Sono stati individuati tre tipi
di componenti di riuso:
• processi definiti completamente da riadattare
• processi parzialmente definiti da riadattare
• template di processi da personalizzare e/o adattare
Il primo componente riguarda il riuso di processi di business che sono stati
completamente modellizzati e che magari sono già entrati in esecuzione. I
I processi così definiti vengono riutilizzati o come sotto-processi di processi
più grandi oppure vengono modificati alcuni task o gateway in modo da
adattarlo alle nuove specifiche di processo. Il secondo componente riguarda
il riuso di processi parzialmente definiti. Questi possono riguardare parti
di flusso di processo ricorrente e in qualche modo standardizzato. Ad esempio,
due processi di business differenti possono contenere al loro interno

100 Capitolo 4. Analisi degli Strumenti BPM
una sequenza di task che permette di svolgere un’operazione standardizzata
all’interno di quella particolare organizzazione (un particolare processo di
approvazione tipo dell’organizzazione, ecc.) Il terzo componente riguarda
la personalizzazione e/o l’adattamento di template di processi. Lo strumento
BPM potrebbe fornire all’utente dei template base di workflow che
permettono di progettare dei flussi tipici del processo quali cicli, procedure
di compensazione, gestione delle eccezioni, ecc.
Se uno strumento BPM permette il riuso dei vari componenti descritti
allora deve anche essere in grado di affrontare tre categorie di problemi
definiti da [14]:
• Problemi di consistenza: avvengono quando due elementi di modelli
di processi di business differenti hanno lo stesso identificatore ma non
rappresentano lo stesso concetto
• Problemi di ridondanza: avvengono quando due elementi rappresentano
lo stesso concetto ma hanno differenti identificatori
• Problemi di residuo: avvengono quando un elemento diviene parte di
un modello di processo di business composto, non perchè necessario ai
fini del processo composto, ma perchè faceva parte di un componente
di questo modello di business.
Affinché sia possibile il riuso, questi processi devono essere memorizzati
in un repository di modelli di processo che descriveremo nella fase di
configurazione.
Tipizzazione di elementi del modello
In questa categoria di valutazione sono stati considerati tre fattori:
• Possibilità di definire delle politiche sull’assegnazione delle attività
• Tipizzazione delle attività e loro riuso
• Possibilità di definire semantiche personalizzate per elementi di tipo
gateway
Il primo, “possibilità di definire delle politiche sull’assegnazione delle
attività”, riguarda il fatto di poter definire sulle singole attività delle regole
sull’assegnazione di risorse.
Il secondo, “tipizzazione delle attività e loro riuso”, riguarda la possibilità
di poter definire attività personalizzate nel modello (inteso come elementi
nuovi), definendone il comportamento (ad esempio mediante a delle

4.4. Categorie di analisi e criteri di valutazione 101
regole che possono essere definite da un linguaggio di programmazione) e
permettendone il salvataggio per un possibile riuso dell’attività definita.
Il terzo, “possibilità di definire semantiche personalizzate per elementi
di tipo gateway”, riguarda il fatto di poter definire delle semantiche personalizzate
per gli elementi di tipo gateway. Queste semantiche definiscono il
comportamento del flusso di processo durante i nodi di scelta del percorso.
Uno strumento BPM dovrebbe dare la possibilità di poter tipizzare gli
elementi sopra descritti.
Supporto ai linguaggi di programmazione, dichiarativi e basati su
regole di business
Il supporto ai linguaggi di programmazione, dichiarativi e basati su regole
permette di dettagliare e personalizzare il funzionamento di un determinato
task definito nel modello. In particolare i linguaggi di programmazione
permettono di definire la logica di funzionamento di una determinata attività
(questi possono essere C, C++, Java, ecc). Questi servono per definire la
logica operativa per quei task che sono completamente automatizzati. I
linguaggi dichiarativi come SQL permettono di definire le interazioni con i
sistemi esterni (in questo caso DBMS) oppure di definire delle regole logiche
allo svolgimento del flusso del processo. I linguaggi basati invece su regole
di business come CLIPS, permettono di definire le regole di business che
governano un processo. Le regole di business possono essere modellizzate in
tre modi:
• Utilizzando regole di business implicite: tutte le regole di business vengono
modellizzate in un modello di processo di business, tipicamente
come punti decisionali nel processo. Per esempio una compagnia assicurativa
avente come regola di business quella di far pagare un prezzo
più alto alle persone al di sotto dei 23 anni è rappresentato in figura
4.9. In questo caso cambiare la regola di business significa cambiare il
modello di processo di business.
• Utilizzando regole di business esplicite: le regole di business nel modello
del processo di business vengono modellizzate solo come riferimento
alla regola di business. Le regole stesse di business vengono salvate in
un repository e gestite separatamente. In figura 4.10 viene mostrata
la stessa situazione con l’utilizzo esplicito di regole di business.
• Utilizzando regole di business per modellizzare completamente il processo
di business: in questo caso il processo di business non viene

102 Capitolo 4. Analisi degli Strumenti BPM
modellizzato in un modello di processo di business ma viene completamente
realizzato mediante regole di business esplicite. Queste regole di
business verranno poi eseguite da un motore di esecuzione delle regole
(business rules engine).
Delle tre situazioni illustrate la seconda èquellachepiù di tutte sta aumentando
la propria importanza. Fare un uso esplicito delle regole di business
causa il loro riuso e facilita la loro gestione. Data l’importanza delle con-
Figura 4.9: Esempio di utilizzo di regole di business implicite
siderazioni fatte, si è deciso di assegnare una valutazione per l’utilizzo di
tutti e tre i linguaggi.
Tabella riassuntiva della valutazione della fase di modellazione del
processo di business
Abbiamo descritto i 13 fattori di valutazione che abbiamo preso in considerazione
per quanto concerne la fase di modellazione. In tabella 4.3
schematizziamo questi fattori indicando i valori che possono assumere:
4.4.3 Configurazione di un sistema BPM
Nella fase di configurazione, un sistema BPM viene configurato in modo da
poter eseguire il processo di business. In questa categoria di analisi dello
strumento BPM sono stati inclusi fattori riguardanti la configurazione sia
dello strumento di modellazione sia quella dell’applicazione che viene generata
mediante esso. Inoltre sono stati presi in considerazione fattori quali la
security e l’interoperabilità sia dello strumento di modellazione del processo
di business che dell’applicazione generata. Inoltre sempre in termini di

4.4. Categorie di analisi e criteri di valutazione 103
Figura 4.10: Esempio di utilizzo di regole di business esplicite
Tabella 4.3: Tabella valutazione modellazione processo di business
B)Modellazione del processo
B.1) Modello informativo SI/NO
B.2) Modello organizzativo SI/NO
B.3) Modello di transazione SI/NO
B.4) Gestione delle eccezioni SI/NO
B.5) Riutilizzo di processi completi da adattare SI/NO
B.6) Riutilizzo di frammenti di processi da adattare SI/NO
B.7) Template di processi da personalizzare/adattare SI/NO
B.8) Definizione di politiche sull’assegnazione delle attività SI/NO
B.9) Tipizzazione delle attività e loro riuso SI/NO
B.10) Semantiche personalizzate per elementi di tipo gateway SI/NO
B.11) Supporto linguaggi programmazione SI/NO
B.12) Interpretazione dei linguaggi dichiarativi SI/NO
B.13) Supporto linguaggi basati su regole SI/NO

104 Capitolo 4. Analisi degli Strumenti BPM
riuso visti nella categoria precedente, viene presa in considerazione la presenza
o meno di un sistema di gestione del versionamento sia dei modelli di
business sia delle varie applicazioni generate da queste. Di seguito verranno
presentate nel dettaglio le categorie considerate.
Richiesta di risorse minime da parte del sistema BPM
In questa categoria di analisi vengono prese in considerazione due aspetti
caratterizzanti la richiesta di risorse per l’esecuzione del sistema BPM:
1. quantità di memoria RAM minima richiesta
2. quantità di spazio richiesto su memoria secondaria (hard disk)
Entrambi i fattori sono importanti da un punto di vista della configurazione
dello strumento BPM perchè forniscono delle indicazioni sulle risorse minime
da assegnare al calcolatore. Inoltre permettono di dare delle indicazioni
su un eventuale pianificazione delle capacità di calcolo quando si presenta
la necessità di prendere in considerazione delle architetture di calcolo distribuite
dove l’intero sistema BPM deve entrare in produzione. Dal punto di
vista della valutazione, per quanto riguarda l’utilizzo della memoria RAM
viene assegnato un punteggio in base a quanta ne occorre secondo la seguente
scala di valutazione: da 0 a 512MB punteggio 1, da 512MB a 1GB punteggio
0,75, da 1GB a 2GB punteggio 0,5, da 2GB a 4GB punteggio 0,25, 4GB+
punteggio 0. Invece per quanto riguarda la quantità di memoria secondaria
richiesta viene definita la seguente scala di valutazione: da 0 a 2GB punteggio
1, da 2GBMB a 4GB punteggio 0,75, da 4GB a 6GB punteggio 0,5, da
6GB a 8GB punteggio 0,25, da 8GB+ punteggio 0.
Multipiattaforma
Un strumento BPM per essere multipiattaforma deve essere in grado di
essere eseguito in tutte le sue parti da almeno due sistemi operativi differenti.
Perchè questo sia possibile esistono due diverse possibilità:
• avere più versioni in base al sistema operativo, quindi il software viene
scritto e compilato tante volte quanti sono i sistemi operativi su i quali
deve entrare in esecuzione
• essere scritto per una piattaforma cross-platform come ad esempio la
piattaforma JRE (Java Runtime Environment) e quindi essere scritti in
linguaggio Java che rispecchia il cosiddetto paradigma WORE (Write
Once, Run Everywhere)

4.4. Categorie di analisi e criteri di valutazione 105
L’essere multipiattaforma è importante da un punto di vista dell’utilizzo dello
strumento BPM in quanto non vincola l’utilizzatore finale a dover lavorare
su un calcolatore avente un particolare sistema operativo. Questo fattore
potrebbe anche incidere sui costi di acquisizione del prodotto BPM stesso,
in quanto bisogna anche prendere in considerazione i costi di acquisizione di
licenze di sistemi operativi o di hardware supportato dal prodotto, ma non
presente dove lavora l’utilizzatore finale. Questo potrebbe essere un fattore
discriminante nella scelta se adottare o meno quel particolare strumento.
Utilizzo di Database Management System (DBMS)
L’utilizzo di un Database Management System da parte di uno strumento
BPM è un fattore importante in quanto indica che i dati trattati dal BPM
non vengono trattati salvandoli in un file ma vengono gestiti appunto da un
DBMS. In questa sede non ci soffermeremo in particolare sui vantaggi dell’utilizzare
un DBMS in generale. Invece andremo a valutare l’impatto che
un loro utilizzo hanno nei confronti di un sistema BPM. Innanzitutto la necessità
di DBMS comporta dei costi aggiuntivi all’acquisizione di un sistema
BPM in quanto quasi sempre sono software di terzi produttori. Inoltre la
loro presenza comporta una ulteriore fase di configurazione del sistema BPM
in quanto deve essere preparato il database composto da tabelle specifiche
sulle quali andranno salvati i dati di lavoro del sistema BPM. Di contro,
l’utilizzo di un DBMS permette di immagazzinare i dati in modo separato
dal particolare sistema BPM utilizzato, migliorando l’efficienza della loro
gestione. Possiamo elencare alcuni vantaggi derivati dall’utilizzo di questi
sistemi:
• i dati non sono duplicati
• l’accesso ai dati avviene in base a privilegi fissati dal DBMS
• i vincoli di consistenza possono essere fissati all’interno del DBMS
• l’accesso concorrente ai dati è controllato dal DBMS che gestisce la
mutua esclusione dei programmi
L’utilizzo di un DBMS permette di salvare in maniera sistematica i modelli
di processi di business che sono stati progettati e le applicazioni da cui
essi derivano. In particolare un ulteriore fattore di valutazione preso in
considerazione è la presenza o meno della possibilità di fare un mapping
diretto tra i dati definiti nel modello informativo del processo di business
e le tabelle associate a quel particolare processo nel database. In entrambi

106 Capitolo 4. Analisi degli Strumenti BPM
i casi, il parametro di valutazione è la presenza o meno del DBMS e del
mapping dei dati del processo definito.
Gestione delle versioni
Questo fattore valuta se lo strumento BPM e l’applicazione da esso generato
interagiscono con un sistema di gestione delle versioni. Un sistema di
versionamento permette di tenere traccia delle diverse versioni di modelli di
processo e di applicazioni generati da questo. I vantaggi nell’utilizzo di un
sistema di versionamento sono le seguenti:
• tenere traccia di tutte le versioni dei processi di business
• supportare l’esecuzione di versioni differenti dello stesso processo di
business allo stesso momento
• aggiornare un processo di business e alterare di conseguenza le istanze
di esecuzione di quel particolare processo
Il sistema di versionamento può essere o meno del produttore del sistema
BPM e può appoggiarsi o meno ad un DBMS di terze parti.
Security
La security è un fattore importante durante la valutazione di un sistemi.
Per questo parametro di valutazione viene considerata o meno la presenza
di diversi aspetti quali:
• un sistema di autenticazione dello strumento BPM
• un sistema di cifratura dello strumento
• la generazione dei file di log sull’utilizzo dello strumento
• un controllo sull’accesso dell’applicazione generata basato sui ruoli
• un sistema di autenticazione dell’applicazione generata
• storage sicuro dei dati
Partiamo dall’ultimo fattore. Abbiamo visto poc’anzi il ruolo di un DBMS
associato ad uno strumento BPM. Un aspetto di cui non abbiamo fatto
menzione è l’elevato grado di sicurezza che quest’ultimo consente ai dati
memorizzati nei suoi database. Esistono altre modalità per mettere al sicuro
i dati. Ad esempio se il sistema BPM non utilizza un DBMS per gestire i

4.4. Categorie di analisi e criteri di valutazione 107
dati, potrebbe utilizzare un proprio sistema per mettere al sicuro i file di dati
contenenti le descrizioni dei processi di business. Tuttavia il DBMS risulta
essere più affidabile in quanto contiene dei meccanismi di ripristino in caso di
disastro che permettono il recupero spesso totale dei dati. Quindi possiamo
affermare che se un sistema BPM interagisce con un DBMS per la gestione
dei dati, allora questo fattore di valutazione assume automaticamente un
valore positivo. Negli altri casi si deve valutare caso per caso.
Per quanto riguarda i fattori di sicurezza inerenti all’utilizzo dello strumento
BPM, abbiamo preso in considerazione tre aspetti. Il primo valuta la
presenza o meno di un sistema di cifratura dello strumento. Questo sistema
di cifratura, se presente, deve poter salvare i dati del modello del processo
di business utilizzando un algoritmo di cifratura. Questo permette di poter
dare accesso e di rendere intellegibili i suoi dati solo alle persone che hanno
il diritto di lettura e/o scrittura su quei dati. Un altro fattore preso in
considerazione è la presenza di un sistema di autenticazione dello strumento
BPM in modo da poter assegnare delle credenziali di accesso allo strumento
e definire dei ruoli sull’utilizzo dello stesso, nel senso di stabilire chi può
fare cosa. Quest’ultimo aspetto è importante nel caso di sistema BPM i cui
strumenti vengono utilizzati in un ambiente distribuito. Anche l’operazione
di generazione dei file di log è molto importante perchè permette di valutare
autenticazioni non lecite allo strumento BPM oppure di verificare quali siano
state le cause di determinati errori nel suo utilizzo.
Infine sono stati presi in considerazione i fattori di sicurezza riguardanti
l’applicazione generata dal modello del processo di business. Vengono valutati
due aspetti: uno il controllo dell’accesso all’applicazione basato sui
ruoli, l’altro la presenza di un sistema di autenticazione dell’applicazione.
Di quest’ultimo aspetto ovviamente solo gli utenti interessati al processo devono
poter accedere. Il primo invece consiste nel fornire l’accesso ai vari task
di processo solo a quelle persone autorizzate, in modo da rispettare il modello
organizzativo definito in fase di modellazione del processo di business.
Infatti abbiamo visto che questo modello può essere utilizzato per definire i
vari attori dei vari task di processo. Un sistema di controllo sull’accesso del
giusto attore al giusto task di processo garantisce l’integrità di esecuzione
del processo in base a quanto è stato stabilito in fase di modellazione.
Interoperabilità
Questo fattore valuta l’interoperabilità dello strumento BPM e delle applicazioni
generate con questo con dei sistemi esterni. Valutazioni positive
possono essere date quando lo strumento di modellazione ad esempio in-

108 Capitolo 4. Analisi degli Strumenti BPM
teragisce con strumenti esterni per estendere le proprie funzionalità ocome
abbiamo visto prima per interagire con dei DBMS. Da parte dello strumento
di modellazione, può essere importante interoperare con strumenti esterni
in modo da aumentare le proprie caratteristiche di modellazione. Ad esempio
vi sono strumenti di modellazione che interagiscono con altri nella
costruzione dell’applicazione. Ad esempio l’interfaccia web dell’applicazione
(ove presente) può richiedere lo sviluppo con strumenti indipendenti dallo
strumento di modellazione BPM. Da parte dell’applicazione generata dal
modello di processo di business, questa può essere stata ideata in modo da
dover interagire con dei sistemi esterni. Ad esempio deve essere in grado
di collaborare con dei DBMS dai quali deve poter fare delle query in modo
da estrarre i dati dalle tabelle e poterli utilizzare nel flusso di processo.
Inoltre quando si parla di interoperabilità di un’applicazione generata da
un modello di processo di business, entrano in gioco i concetti di orchestrazione
e coreografia dei processi (concetti descritti nei capitoli precedenti)
che indicano se l’applicazione sia stata progettata per interagire con gli altri
processi e servizi espondendo la propria interfaccia contenente le proprie
funzionalità e i risultati delle sue esecuzioni. Ad esempio questo può essere
fatto descrivendo l’applicazione con un linguaggio di esecuzione appropriato
come ad esempio il BPEL4WS visto precedentemente.
Tabella riassuntiva della valutazione della fase di configurazione di
un sistema BPM
Abbiamo descritto i 15 fattori di valutazione che abbiamo preso in considerazione
per quanto concerne la fase di configurazione. In tabella 4.4
schematizziamo questi fattori indicando i valori che possono assumere:
4.4.4 Attivazione del processo di business
La fase di attivazione del processo di business consiste in metodologie e
in strumenti il cui scopo è quello di supportare l’esecuzione del processo.
In questa fase è presente il BPM engine che è quel componente software
il cui compito è quello di gestire il flusso di processo. Tra i suoi compiti
ricordiamo l’allocazione di risorse alle varie attività, l’individuazione e la
gestione di situazioni anomale e lo scambio di dati tra gli attori partecipanti
al processo. Non tutti gli strumenti BPM che andremo a valutare consentono
l’esecuzione dei processi. Per questi ultimi la valutazione ovviamente non
verrà eseguita.

4.4. Categorie di analisi e criteri di valutazione 109
Tabella 4.4: Tabella valutazione configurazione di sistema
C) Configurazione sistema BPM
C.1) Min RAM richiesta 0...1
C.2) Min HD richiesto 0...1
C.3) Multipiattaforma SI/NO
C.4) Utilizzo DBMS SI/NO
C.5) Interoperabilità dello strumento con sistemi esterni SI/NO
C.6) Gestione del versionamento del modello di processo SI/NO
C.7) Gestione del versionamento dell’applicazione SI/NO
C.8) Sistema di cifratura dello strumento SI/NO
C.9) Sistema di autenticazione dello strumento SI/NO
C.10) Generazione di file di log sull’utilizzo SI/NO
C.11) Controllo dell’accesso all’applicazione generata basato sui ruoli SI/NO
C.12) Sistema di autenticazione dell’applicazione SI/NO
C.13) Interoperabilità dell’applicazione con sistemi esterni SI/NO
C.14) Storage sicuro dei dati SI/NO
C.15) Mapping dei dati su DBMS esterni SI/NO
Simulazione
Questo fattore determina la presenza o meno della funzionalità disimulare
il processo di business in modo da verificarne la correttezza dal punto
di vista comportamentale e prestazionale. Infatti la simulazione può essere
utilizzata sia per verificare se un processo di business si comporta nel
modo atteso sia per valutare la capacità di essere conforme a certi requisiti
prestazionali quali tempi di throughput, livelli di servizio e utilizzazione
delle risorse, parametri che sono stati definiti in fase di analisi dei requisiti
del processo di business. Ad esempio, quando versioni differenti dello stesso
processo devono essere modellizzate, esse possono essere simulate per essere
scelte prima che esse entrino nell’ambiente di produzione. Gli strumenti di
simulazione possono aiutare a determinare i costi delle attività individuali
o anche dell’intero processo. Inoltre possono essere utilizzati per calcolare i
tempi minimi e massimi di esecuzione del processo. La simulazione è utile
in quanto è difficile fare delle predizioni sul carico di lavoro effettivo che
dovrà affrontare un processo di business ed èancorapiùcomplesso determinare
quali attività di questo processo sono influenzati maggiormente dalla
mancanza di conoscenza certa del carico di lavoro.
Quando viene simulato un processo di business, un numero di casi devono
essere preparati ed inseriti nel modello eseguibile di business. Inoltre lo
stesso ambiente dove il processo sarà in esecuzione, viene simulato. L’ambi-

110 Capitolo 4. Analisi degli Strumenti BPM
ente simulato, che include risorse, servizi e i loro caricamenti, può essere impostato
in base all’esperienza dell’utente o in base a dati storici di esecuzione.
Esistono due tipi di strumenti di simulazione: quelli tradizionali, che permettono
l’utilizzo solo di parametri definiti dall’utente, e quelli più innovativi
che invece simulano i modelli di processo prendendo in considerazione anche
i dati storici. Questi ultimi sono da preferire a quelli tradizionali in quanto
prendono in considerazione[20]:
• il carico che caratterizza le risorse ed i servizi (possibilmente causati
dall’esecuzione di differenti processi)
• il carico sull’ambiente di esecuzione del prodotto BPM
• l’impatto dei cambiamenti che un processo provoca nei confronti degli
altri strumenti
• dati storici, pertanto si elimina la necessità che l’utente generi dei dati
casuali
• deviazioni rispetto a media dei tempi di esecuzione, comportamento
dell’ambiente di esecuzione e risorse
In particolare nella valutazione vengono presi in considerazione nella fase
di attivazione del processo due fattori:
1. Disponibilità della simulazione
2. Possibilità di personalizzare la configurazione della simulazione
Il primo assegna un valore positivo nel caso lo strumento BPM preveda la
possibilità di poter effettuare una simulazione. Il secondo valuta la possibilità
di poter personalizzare la configurazione dello strumento di simulazione
nei modi descritti sopra, cioè sia immettendo dei parametri definiti
dall’utente sia inserendo dati storici presi dalle esecuzioni di processi di business
simili, in modo da rendere il carico di lavoro della simulazione molto
simile a quello dello stesso processo messo in esecuzione da un BPM engine.
Generazione di prototipi
Questo fattore valuta la possibilità che il sistema BPM possa generare dei
prototipi del processo di business. I prototipi di un processo di business
rappresentano le interfacce con cui il processo interagisce con l’utente nelle
attività orientate all’intervento umano. Generalmente questi prototipi vengono
creati utilizzando strumenti di parti terze che creano interfacce di tipi

4.4. Categorie di analisi e criteri di valutazione 111
diverse (ad. esempio sottoforma di moduli stand alone o moduli incorporati
in interfacce Web). In particolare si valuta sia la presenza di un meccanismo
di generazione automatica dei prototipi a partire dalle attività e dai dati
definiti nel modello di processo di business sia del grado di configurabilitàdei
prototipi stessi generati. Infatti alcuni prodotti BPM permettono di generare
un prototipo a partire da un’interfaccia standard non personalizzabile
che racchiude tutti i campi dei dati definiti da una certa attività. Mentre
altri strumenti BPM permettono, per mezzo di parametri, di personalizzare
i prototipi, ad esempio associare al prototipo la lista delle attività che ogni
utente deve completare e i collegamenti alle applicazioni che servono per
completare queste attività. Un punteggio viene asseganto a questo fattore
(da 0 a 1) in base a quanti parametri di personalizzazione dei prototipi mette
a disposizione lo strumento BPM.
BPM engine
L’engine di esecuzione dei processi di business incluso nelle suite BPM èresponsabile
dell’esecuzione dei modelli eseguibili dei processi di business. Se i
processi di business devono essere eseguiti in maniera efficiente allora la loro
esecuzione deve essere ottimizzata secondo alcuni criteri misurabili, quali
i costi, tempo di esecuzione del processo o soddisfazione dell’utente finale.
Questo può essere fatto attraverso il raggiungimento di una configurazione
ottima del sistema, l’assegnamento delle risorse e l’adattamento dinamico
del processo [7]. Inoltre la struttura del processo di business può anche essere
cambiata. Questo accade quando l’esecuzione del processo di business
mostra inefficienza e quando l’analisi di questo mostra margini sostanziali
di miglioramento. Infine l’engine di business si occupa del calcolo delle KPI
(che vedremo nei paragrafi successivi) in quanto deve fare in modo che il
processo venga eseguito nel modo più efficiente possibile. Quando un processo
di business viene eseguito, l’engine BPM crea un’istanza del processo
stesso assegnandoli dei valori iniziali alle sue variabili. Questa istanza viene
eseguita utilizzando sia i dati passati al processo sia i dati generati dalle
attività del processo. Quando l’istanza di processo viene completata oppure
trascorre un periodo temporale definito dall’utente, questa viene cancellata,
deallocando le risorse che erano state assegnate all’istanza per la sua
corretta esecuzione. Durante l’esecuzione del processo, l’engine BPM deve
essere in grado di poter generare dei file di log in modo tale da tenere traccia
delle informazioni relative al processo quali valori di KPI, informazioni sugli
utenti, sulle attività e sui tempi di esecuzione. Per mettere in esecuzione
un processo, il BPM engine deve essere in grado di selezionare le attività in

112 Capitolo 4. Analisi degli Strumenti BPM
modo tale da poter determinare le risorse e gli strumenti richieste, la loro
attivazione e terminazione.
Durante l’esecuzione, l’engine BPM deve determinare quali attori (umani
o di sistema) devono eseguire una certa attività. Questa scelta può essere
fatta secondo diverse modalità:
• secondo regole di business (business rules) predefinite dal progettista
del progetto
• secondo delle priorità (certe attività possono avere priorità di esecuzione
più alta rispetto ad altre e quindi essere eseguite rispetto ad
altre a priorità più bassa)
• secondo dei ruoli definiti per le attività in base alle risorse disponibili
per eseguirle
• secondo eventi (infatti al verificarsi di un evento, l’attività può essere
eseguita da attori diversi invece che essere eseguita dagli attori
predefiniti per quella attività)
Un’altra funzionalità che dovrebbe caratterizzare un BPM engine èla
sua capacità nel gestire le eccezioni che potrebbero essere sollevate durante
l’esecuzione di un processo di business. Infatti non tutti i processi di business
vengono eseguiti come sono stati definiti ma circa l’80% del tempo viene
speso dal BPM engine per gestire le eccezioni e le situazioni di failures, in
modo da assicurare un’esecuzione affidabile del processo di business [17].
Secondo [9], esistono tre tipi diversi di failures in un ambiente di workflow
che sono ancora rilevanti in un ambiente BPM e che dovrebbero essere gestite
da un BPM engine:
1. Failure dell’engine di esecuzione dei processi di business: questo porta
ad una terminazione anomala dell’esecuzione del processo di business.
Per questo il BPM engine deve essere in grado di salvare gli stati di
esecuzione di un processo in un database di processo. Il salvataggio di
questi dati permette di ripristinare lo stato di esecuzione di un processo
di business a seguito di una failure dell’engine stesso.
2. Failure dell’attività: questa failure avviene all’interno dell’attività stessa.
Può essere di tre tipi: il primo viene causato da una failure dell’applicazione
e porta ad una terminazione anomala dell’attività. In questo
caso il BPM engine deve implementare un meccanismo di rollback, in
modo da rimuovere tutti i risultati inconsistenti delle esecuzioni dei
processi, e un meccanismo di esecuzione avanzata, il quale permette

4.4. Categorie di analisi e criteri di valutazione 113
di riprendere l’esecuzione dell’attività dal punto di consistenza più vicino.
Il secondo tipo di failure è di tipo semantico: il BPM engine
deve essere in grado di applicare le regole per gestire le eccezioni che
sono state definite in fase di modellazione. Il terzo tipo sono le eccezioni
comportamentali: queste sono il risultato dell’esecuzione non
ordinata di attività di processo. Il BPM engine in questo caso deve introdurre
dei meccanismi per attivare dei trigger in modo da ristabilire
a posteriori l’ordine di esecuzione delle attività.
3. Failure di comunicazione: avviene quando vi sono problemi di comunicazione
(scambio di dati) tra il prodotto BPM e le attività del processo.
Ad esempio questo può avvenire quando un’attività deve salvare dei
dati in qualche tabella di database e il dato passato dal processo al
DBMS non è in un formato valido. Il BPM engine deve essere in grado
di gestire tali situazioni.
La valutazione del BPM engine riguarda innanzitutto la presenza di
questo strumento nel prodotto BPM in esame e nella versione di valutazione
del prodotto stesso. Due sono i fattori importanti in questa valutazione:
1. la presenza di un BPM engine associato al prodotto in valutazione
2. possibilità di eseguire il processo su altri BPM engine
Quest’ultimo caso presume che gli engine considerati siano in grado di leggere
correttamente i formati di esecuzione dei vari modelli di processi di
business quale, ad esempio, BPEL4WS.
Tabella riassuntiva della valutazione della fase di attivazione del
processo di business
Abbiamo descritto i 6 fattori di valutazione che abbiamo preso in considerazione
per quanto concerne la fase di attivazione. In tabella 4.5 schematizziamo
questi fattori indicando i valori che possono assumere:
4.4.5 Analisi del processo di business
Questa fase del ciclo di vita di un BPM èquellachepermettedianalizzare
l’esecuzione di un processo di business. In questa categoria di valutazione
si cerca di valutare o meno la presenza di strumenti importanti ai fini dell’analisi
di un processo di business. Questi strumenti come vedremo tra breve
possono essere di tipo attivo o passivo in base se mostrano dati relativi al
processo in tempo reale o a processo concluso. Entrambi gli strumenti sono

114 Capitolo 4. Analisi degli Strumenti BPM
Tabella 4.5: Tabella valutazione attivazione processo di business
D)Attivazione del processo di business
D.1) Disponibilità della simulazione SI/NO
D.2) Possibilità di personalizzare la configurazione della simulazione SI/NO
D.3) Generazione automatica dei prototipi SI/NO
D.4) Grado di configurabilità dei prototipi 0...1
D.5) BPM Engine associato SI/NO
D.6) Possibilità di eseguire il processo su altri BPM engine SI/NO
di fondamentale importanza a due categorie di utenti: gli analisti di business
e gli analisti-sviluppatori. I primi dall’utilizzo di questi strumenti possono
estrarre informazioni utili ai fini del miglioramento del processo di business
a livello concettuale mentre i secondi possono utilizzare questi strumenti
per analizzare le problematiche prestazionali dei processi, che poi verranno
corrette nelle future revisioni di implementazione dei processi stessi.
Monitoraggio della simulazione
Un sistema di monitoraggio della simulazione permette di evidenziare quali
siano i bottleneck durante l’esecuzione di un processo all’interno di un simulatore.
Se quest’ultimo fosse dotato di parametri precisi sul carico di lavoro
allora il sistema di monitoraggio mostrerà dei valori abbastanza fedeli a quelli
ottenuti quando il processo di business verrà eseguito in produzione. La
valutazione in questo caso consiste nella presenza o meno dello strumento.
Business Cockpit
Un business cockpit è uno strumento che fa parte di quella classe di applicazioni
che prendono il nome di applicazioni di “Business Process Intelligence”.
Queste applicazioni supportano i processi di business e le decisioni
sull’IT sia in tempo reale che offline con l’obiettivo di migliorare la qualità
dei processi di business [32]. Un sistema di business cockpit opera secondo le
modalità di warehousing dei dati e opera con tecniche di data mining sui dati
di processi messi in esecuzione: quindi operano un monitoraggio passivo dei
processi di business utilizzando tecnologie di tipo pull per recuperare i dati.
I processi di business si differenziano per determinate caratteristiche quali
i volumi di carico, il coinvolgimento di più compagnie durante l’esecuzione,
il fatto che forniscono valori di business che impattano significativamente
sull’andamento della compagnia in quanto sono relativi alle vendite, agli acquisti,
ai profitti e ai ricavati. Queste caratteristiche richiedono dei rispettivi

4.4. Categorie di analisi e criteri di valutazione 115
requisiti in modo da essere valutati da strumenti di analisi dei processi quali
il business cockpit. Questi requisiti prendono il nome di indicatori del livello
di business. Questi indicatori permettono agli analisti di business di
analizzare e di migliorare costantemente il processo di business in esame.
Affinchè un business cockpit possa analizzare le caratteristiche di un processo
di business attraverso i corrispettivi indicatori deve possedere le seguenti
caratteristiche:
• deve essere progettato in modo tale che un analista di business possa
facilmente definire ed estrarre le metriche a livello di business dai dati
in esecuzione, nascondendo i dettagli del processo
• deve fornire un’analisi semantica dei dati in modo tale che gli analisti
di business possano definire nuovi concetti e visualizzare i dati secondo
questi concetti
• deve permettere agli analisti di business di creare una grande varietà
di report sui dati di esecuzione del processo e determinare il modo
migliore di presentare questi dati
Un business cockpit visualizza i dati di esecuzione di un processo secondo
differenti punti di vista. Ogni punto di vista rappresenta l’entità del processo
che viene preso in considerazione dall’analista di business. Nell’analisi a
livello di business sono stati individuati i seguenti punti di vista:
• Processi: mostra informazioni inerenti un processo specifico oppure un
insieme di processi
• Risorse: mostra i dati relativi ad una risorsa individuale oppure ad un
gruppo di risorse. Una risorsa può essere umana oppure un componente
software che partecipa all’esecuzione delle attività del processo
• Servizi: mostra i dati relativi ai servizi invocati durante l’esecuzione del
processo in modo da realizzare attività individuali definite del processo
Per ogni punto di vista descritto, il business cockpit presenta le informazioni
statistiche e informazioni aventi valore orientato al business quali costi e
ricavi. Inoltre deve permettere di aggregare questi dati per poter ricavare
informazione utile da diverse prospettive (ad esempio temporali).
Nella valutazione di questo fattore prendiamo in considerazione tre parametri
1. Presenza di un business cockpit
2. Configurabilità business cockpit

116 Capitolo 4. Analisi degli Strumenti BPM
3. Livello di dettaglio business cockpit
Il primo valuta la presenza o meno dello strumento nello strumento BPM
in esame. La sua presenza influenzerà la valutazione dell’utente analista
di business, che vedremo nel corso del capitolo. Il grado di configurabilità
riguarda la possibilità di definire indicatori del livello di business e report
personalizzati in modo tale che possano fornire informazioni significative
circa il particolare processo di business preso in considerazione. Per quanto
concerne l’ultimo parametro, è importante comprendere a che livello di dettaglio
possono essere mostrati i dati in particolare in riferimento ai punti di
vista e alle prospettive di cui abbiamo appena discusso.
Console di amministrazione di un processo
La console di amministrazione di un processo consente di configurare l’esecuzione
di un processo di business che deve essere eseguito. Le modifiche che
vengono effettuate riguardano solo i processi correnti in esecuzione e non il
modello di processo di business da cui essi derivano. Questo fattore della
valutazione si occupa appunto di valutare la presenza di un simile strumento
icuicompitisono:
• gestire l’evoluzione dell’istanza di processo rispetto al modello di processo
di business. Questa evoluzione del processo può avvenire: cambiando
il ruolo o la risorsa richiesta per una attività, cambiare i ruoli
agli utenti, cambiare la struttura organizzativa, cambiare le pre-condizioni
aggiungendone un’altra o aggiungendo dei pre-requisiti, eliminare le diramazioni
problematiche del processo aggiungendone altre, aggiungere
o rimuovere attività
• aggiungere gestori di eccezioni e rimuoverne altri
• canbiare le regole di business
• cambiare la struttura delle attività
• cambiare il bilanciamento di workload tra gli utenti
La presenza o meno di tale console di amministrazione riguarda la valutazione
di questo fattore.
Monitoraggio attività del processo
Un sistema di monitoraggio dell’attività di processo, detto anche BAM
(Business Activity Monitoring), permette di monitorare l’andamento delle

4.4. Categorie di analisi e criteri di valutazione 117
attività dei processi in esecuzione in tempo reale. Permette di visualizzare
quali attività non sono state ancora eseguite e quali invece sono state eseguite
e da chi, quali attività violano qualche vincolo di esecuzione generando
delle eccezioni, lo stato generale del processo e le eventuali anomalie che
possono portare all’individuazione di eventuali bottleneck nel processo. Il
monitoraggio avviene in tempo reale ed è solitamente l’amministratore o il
responsabile del processo ad accedere a queste informazioni. Per questo motivo
il monitoraggio di un BAM viene detto anche monitoraggio attivo di un
processo di business in quanto utilizza tecnologie di tipo push per poter visualizzare
i dati del processo di business in esecuzione in tempo reale. Questo
viene fatto monitorando i file di log generati dallo strumento BPM, raccogliendo
metriche di performance come ad esempio il tempo di esecuzione
di un processo e calcolando le KPI definite. Tipicamente tutte queste informazioni
vengono visualizzate in una dashboard. Dal punto di vista della
valutazione è importante valutare la presenza o meno di questo strumento in
quanto questo influenza la valutazione dell’utente analista-programmatore
che vedremo successivamente, oltre che determinare il grado di completezza
di una suite BPM.
Monitoraggio degli indicatori KPI
I KPI, o Key Performance Indicator, sono indicatori che possono caratterizzare
o il singolo processo di business in esecuzione oppure possono riferirsi
a gruppi di processi di business. Questi indicatori dovrebbero possedere un
valore obiettivo desiderato da mantenere o da raggiungere, in modo che durante
il monitoraggio, sia attivo che passivo, sia possibile confrontare il valore
KPI desiderato da quello ottenuto dal processo in esecuzione. I KPI possono
essere definiti per misurare le caratteristiche delle istanze di processo,
del processo, delle risorse o delle operazioni di business nel loro complesso.
Esempi di KPI di interesse possono essere la quantità di esecuzioni terminate
senza errori di un processo di business rispetto alla quantità totale
delle esecuzioni del processo, oppure la quantità di risorse umane impiegate
per terminare un certo processo di business rispetto alla quantità dirisorse
disponibili.
Un sistema di monitoraggio in tempo reale permette di avere sempre
una visione completa dei KPI definiti per il processo e di monitorare i suoi
valori. Il criterio di valutazione mira a mostrare la presenza o meno di questo
strumento che spesso completa un sistema BAM precedentemente descritto.

118 Capitolo 4. Analisi degli Strumenti BPM
Tabella riassuntiva della valutazione della fase di analisi del processo
di business
Abbiamo descritto i 7 fattori di valutazione che abbiamo preso in considerazione
per quanto concerne la fase di analisi. In tabella 4.6 schematizziamo
questi fattori indicando i valori che possono assumere:
Tabella 4.6: Tabella valutazione analisi processo di business
E)Analisi processo di business
E.1) Strumenti di monitoraggio della simulazione del processo SI/NO
E.2) Presenza di un business cockpit SI/NO
E.3) Configurabilità business cockpit 0...1
E.4) Livello di dettaglio business cockpit 0...1
E.5) Console di amministrazione del processo SI/NO
E.6) Monitoraggio attività di processo (BAM) SI/NO
E.7) Monitoraggio di Indicatori di KPI SI/NO
4.4.6 Usabilità dello strumento BPM
Nell’ingegneria informatica l’usabilità è la disciplina che stabilisce gli standard
di progettazione di un software dal punto di vista dell’esperienza dell’utente.
Non è sufficiente che l’utente possieda un determinato software ma
deve essere messo nella possibilità di utilizzarlo al meglio. Questa categoria
di analisi è stata appunto pensata per tenere in considerazione l’aspetto
dell’esperienza utente nella valutazione dello strumento BPM, estendendo
quindi le categorie di valutazione del ciclo di vita di un BPM definito in
precedenza. Come vedremo in dettaglio i dati di questa analisi si riferiscono
ai casi di studio che sono stati effettuati nella valutazione degli strumenti.
In questo paragrafo andiamo a delinearne i contenuti.
Facilità di download
Questo parametro di valutazione è stato pensato per valutare l’esperienza
utente percepita durante la fase di download del prodotto dal sito web del
produttore. Sono stati presi in considerazione due fattori:
• difficoltà nel reperire il prodotto in versione trial
• difficoltà nella fase di download del prodotto

4.4. Categorie di analisi e criteri di valutazione 119
Nel primo caso la richiesta di valutazione del prodotto ha portato a delle
difficoltà nel reperirlo. Queste difficoltà sono dovute, ad esempio, al fatto di
dover fare richiesta esplicita al produttore invece di poter fare la richiesta
attraverso un meccanismo automatizzato.
Il secondo caso riguarda invece le difficoltà di effettuare l’operazione di
download del prodotto come la compilazione di form più o meno lunghi,
server del produttore down, lentezza nell’effettuare il download.
Facilità di installazione
Questo parametro cerca di dare una valutazione al grado di facilità diinstallazione
del prodotto. Vi sono prodotti la cui installazione non richiede
la presenza di componenti aggiuntivi affinchè lo strumento BPM funzioni
mentre altri richiedono la presenza di applicazioni terze e di particolari configurazioni
della macchina affinchè possano essere installati. In quest’ultimo
caso, il processo di installazione del sistema BPM può rivelarsi complesso
agli utenti meno esperti.
Facilità di apprendimento
Questo parametro valuta il grado di semplicità nell’apprendere l’utilizzo
dello strumento BPM e delle sue funzionalità. È un parametro che viene
valutato a seguito del caso di studio effettuato sullo strumento. In particolare
come metro di valutazione si tiene in considerazione il tempo che è
stato necessario per implementare il modello di riferimento correttamente.
Questo è un fattore di usabilità parecchio importante ai fini della valutazione
in quanto determina il successo o meno del prodotto per gli utenti che non
hanno competenze informatiche specifiche (come gli analisti di business).
Facilità di utilizzo dello strumento di modellazione
Questo parametro valuta l’esperienza utente nell’utilizzare lo strumento di
modellazione. Diversi fattori possono influenzare questa valutazione:
• difficoltà nel posizionare gli elementi nel modello a causa di vincoli
grafici troppo stringenti
• difficoltà nell’individuare gli elementi con cui costruire il modello
• difficoltà nel specificare le proprietà di un elemento del modello

120 Capitolo 4. Analisi degli Strumenti BPM
Facilità nel generare l’applicazione
Questo fattore indica il grado di difficoltà nel generare un’applicazione funzionante
a partire dal modello di processo. Ci sono strumenti BPM che una
volta definiti tutti i parametri del modello generano automaticamente l’applicazione
che potrà essere subito messa in esecuzione. Altri ancora permettono
il controllo completo nella generazione dell’applicazione, richiedendo
esplicitamente di dover progettare ad esempio le form per l’inserimento dei
dati in input. Infine ci sono strumenti BPM che non consentono proprio la
generazione del modello. Dalla difficoltà con cui si genera e dalle competenze
richieste per poterla generare deriva il punteggio per questo fattore.
Grado di personalizzazione dello strumento
Questo fattore indica quanto lo strumento BPM è personalizzabile da parte
dell’utente. Si tiene conto sia dello strumento di modellazione, prendendo
in considerazione ad esempio la possibilità o meno di poter aggiugere
degli elementi personalizzati nel modello oppure di poter modificare la disposizione
degli strumenti nell’ambiente di modellazione, sia degli strumenti
di gestione, analisi e messa in esecuzione del processo di business.
Utilizzo prima di essere produttivi
Questo fattore viene calcolato in base al tempo che è stato necessario per
apprendere le funzionalità dello strumento in modo da essere produttivi
con esso. Una curva di apprendimento dello strumento molto lunga indica
che lo strumento contiene una molteplicità di funzioni che vanno prima
comprese per poterlo utilizzare oppure che lo strumento è stato mal progettato
dal punto di vista dell’usabilità. In entrambi i casi questo porta ad
una valutazione negativa dello strumento dal punto di vista dell’esperienza
dell’utente. Uno strumento ben progettato porta un utente a modellare e
mettere in esecuzione un processo di business in breve tempo.
Disponibilità di documentazione
La disponibilità di documentazione è un fattore fondamentale nell’apprendimento
dello strumento BPM. Le risorse possono provenire da risorse online,
documentazione elettronica inclusa nello strumento BPM, esempi di casi
d’uso e tutorial. È chiaro come la presenza o meno di documentazione influenzi
gli altri fattori di usabilità fin’ora utilizzati. Inoltre questo fattore
non valuta solo la presenza o meno di documentazione ma anche la sua reale
efficacia.

4.4. Categorie di analisi e criteri di valutazione 121
Utilizzo dell’engine
Questo fattore indica la facilità di installazione, configurazione ed utilizzo
del BPM engine ove questo sia disponibile. La valutazione di questo
fattore prende in considerazione il tempo impiegato sia per la sua corretta
installazione e configurazione sia il tempo impiegato per poter eseguire
correttamente il modello di processo di business preso in considerazione.
Tabella riassuntiva della valutazione dell’usabilità del processo di
business
Abbiamo descritto i 9 fattori di valutazione che abbiamo preso in considerazione
per quanto concerne l’usabilità di un sistema BPM. In tabella 4.7
schematizziamo questi fattori indicando i valori che possono assumere.
Tabella 4.7: Tabella valutazione usabilità strumento BPM
F)Usabilità dellostrumentoBPM
F.1) Facilità di download 0...1
F.2) Facilità di installazione 0...1
F.3) Facilità di apprendimento 0...1
F.4) Facilità di utilizzo dello strumento di modellazione 0...1
F.5) Facilità nel generare l’applicazione 0...1
F.6) Grado di personalizzazione dello strumento 0...1
F.7) Utilizzo prima di essere produttivi 0...1
F.8) Disponibilità di documentazione SI/NO
F.9) Utilizzo dell’engine 0...1
4.4.7 Utenti target per l’utilizzo dello strumento BPM
Questa categoria di valutazione mira a comprendere a quale target di utenti
è rivolto lo strumento BPM. Sono state individuate tre categorie di utenti
tipo di uno strumento BPM: l’analista di business, gli sviluppatori e gli
analisti-sviluppatori. Di seguito andremo a caratterizzare le categorie di
utenti appena citate.
Analisti di business
Il ruolo di un’analista di business è quello di essere un esperto nell’analizzare
il contesto entro il quale deve raccogliere i requisiti per poter modellizzare

122 Capitolo 4. Analisi degli Strumenti BPM
un processo di business; questo viene fatto al fine di creare un processo exnovo,
di ottimizzarne uno già esistente, definire un modello informativo ad
alto livello ed uno organizzativo, definire i requisiti prestazionali del processo
di business, controllare lo stato del processo in esecuzione, analizzare
a posteriori i risultati ottenuti dall’esecuzione del processo di business. È
una figura che non sempre possiede competenze informatiche. Per questo
motivo un strumento BPM per venire incontro a tale figura professionale
deve presentare funzionalità tali da poter permettere la documentazione e
la progettazione del processo ad alto livello, la sua verifica di funzionamento
durante l’esecuzione, ed essere in grado di interagire con sistemi esterni
(ERP, sistemi di gestione di progetto,ecc.) che vengono abitualmente utilizzati
da un analista di business. Dal punto di vista della valutazione dello
strumento BPM vengono presi in considerazione quattro fattori:
1. Possibilità di generare della documentazione riguardante il processo di
business
2. Presenza dello strumento di progettazione ad alto livello
3. Presenza di un sistema di verifica a livello semantico del modello di
business progettato
4. Possibilità di interazione con sistemi esterni che supportano la gestione
del processo di business
Nel primo caso, un sistema BPM dovrebbe essere in grado di generare della
documentazione che descriva sia il modello del processo di business progettato
con una tecnica ad alto livello, in modo che sia comprensibile da
ogni attore interessato al processo, sia che descriva i risultati di esecuzione
del processo, come ad esempio l’aderenza ai KPI definiti nel processo. Nel
secondo caso deve essere presente un editor che permetta all’analista di business
di poter descrivere il processo di business utilizzando un linguaggio ad
alto livello. Questo modello deve poter essere verificato a livello semantico.
Inoltre, come è stato già detto, lo strumento BPM deve essere in grado di
interagire con gli strumenti che supportano la progettazione e l’analisi del
processo di business.
Sviluppatori
Il ruolo degli sviluppatori nel contesto del business process management è
quello di progettare gli automatismi caratterizzanti le attività del sistema
di un processo di business, implementarli e verificarne la correttezza. Uno

4.4. Categorie di analisi e criteri di valutazione 123
strumento BPM rivolto a questa categoria di utenti è caratterizzato dall’avere
un elevato grado di personalizzazione dei prototipi generati dal modello
di processo di business. Infatti lo sviluppatore possiede le capacità dipoter
estendere le funzionalità di un componente del modello di processo, venendo
incontro ad esigenze specifiche di modellazione. Le capacità caratterizzanti
questa tipologia di utenza sono quelle della progettazione e programmazione
informatica. Diversi sono i fattori che ci fanno capire che lo strumento BPM
in questione sia un strumento adatto per gli utenti di tipo sviluppatori: uno
fra tutti è la possibilità di poter sviluppare la logica di un attività di processo
con un certo linguaggio di programmazione. Un altro fattore è quello di
dover creare delle interrogazioni verso il database oppure di dover definire
mediante un linguaggio formale delle regole di business. Per quanto concerne
uno strumento BPM, affermiamo che questo sia dedicato ad un utente
di tipo sviluppatore se:
• Possiede degli strumenti che permettano la progettazione del prototipo
del processo di business in un linguaggio di programmazione
di riferimento
• Possiede gli strumenti necessari per l’implementazione del modello
progettato con un determinato linguaggio di programmazione
• Possiede un sistema per poter effettuare una verifica semantica del
modello di processo di business implementato (ad. esempio type checking
sui dati)
Analisti-sviluppatori
Il ruolo degli analisti-sviluppatori è quello di tradurre il modello di processo
di business, descritto ad alto livello da un’analista di business, con un formalismo
che sia comprensibile da un sistema BPM in modo da generare la
versione eseguibile del processo stesso. Con questo formalismo deve essere in
grado di descrivere oltre al modello di processo anche il modello informativo
e il modello organizzativo. Inoltre l’analista-sviluppatore, a differenza dello
sviluppatore, possiede quelle conoscenze di gestione dei processi di business
che gli permettono di poter valutare l’andamento del processo in esecuzione e
di poter apportare delle modifiche qualora il processo non rispetti dei vincoli
prestazionali prestabiliti. Inoltre ha le competenze necessarie per gestire a
livello tecnico un’esecuzione del processo attraverso sistemi di monitoraggio
descritti precedentemente. Nella valutazione di un sistema BPM consideriamo
le seguenti caratteristiche come quelle che permettono di definire se il
sistema BPM considerato è adatto alla tipologia di utente descritta:

124 Capitolo 4. Analisi degli Strumenti BPM
• Presenza di un sistema di documentazione che permetta di produrre
della documentazione circa il processo di business nel particolare formalismo
scelto.
• Presenza di un sistema di progettazione che permetta di tradurre la
descrizione ad alto livello di un processo di business nel formalismo
scelto.
• Possibilità di generare l’eseguibile del processo a partire dalla sua descrizione
formale e di poterlo distribuire al BPM engine per la sua
esecuzione
• Presenza di un sistema di verifica semantica del processo descritto (ad
esempio controllo della correttezza dei vincoli del processo)
Tabella riassuntiva della valutazione degli utenti target per l’utilizzo
dello strumento BPM
Abbiamo descritto gli 11 fattori di valutazione che abbiamo preso in considerazione
per quanto concerne la valutazione degli utenti target per l’utilizzo
dello strumento BPM. In tabella 4.8 schematizziamo questi fattori indicando
i valori che possono assumere:
Tabella 4.8: Tabella valutazione utenti target
G)Utenti target
Analisti di business
G.1) Documentazione SI/NO
G.2) Progettazione SI/NO
G.3) Verifica SI/NO
G.4) Interoperabilità SI/NO
Sviluppatori
G.5) Progettazione SI/NO
G.6) Implementazione SI/NO
G.7) Verifica SI/NO
Analisti-sviluppatori
G.8) Documentazione SI/NO
G.9) Progettazione SI/NO
G.10) Implementazione SI/NO
G.11) Verifica SI/NO

4.4. Categorie di analisi e criteri di valutazione 125
4.4.8 Riepilogo del framework di analisi proposto
Nella tabella seguente viene mostrato un riepilogo del framework di analisi
proposto per la valutazione di uno strumento BPM:
Tabella 4.9: Framework di analisi proposto - Categoria A e B
A)Conformità agli standard
A.1) Conformità BPMN1.1 0...1
A.2) Conformità BPMN1.2 0...1
A.3) Conformità BPMN2.0 0...1
A.4) Conformità X-PDL 1.0 SI/NO
A.5) Conformità X-PDL 2.0 SI/NO
A.6) Conformità X-PDL 2.1 SI/NO
A.7) Importazione X-PDL SI/NO
A.8) Esportazione X-PDL SI/NO
A.9) Conformità BPEL4WS SI/NO
A.10) Conformità BPEL4PEOPLE SI/NO
A.11) Importazione BPEL4WS / BPEL4PEOPLE SI/NO
A.12) Esportazione BPEL4WS / BPEL4PEOPLE SI/NO
B)Modellazione del processo
B.1) Modello informativo SI/NO
B.2) Modello organizzativo SI/NO
B.3) Modello di transazione SI/NO
B.4) Gestione delle eccezioni SI/NO
B.5) Riutilizzo di processi completi da adattare SI/NO
B.6) Riutilizzo di frammenti di processi da adattare SI/NO
B.7) Template di processi da personalizzare/adattare SI/NO
B.8) Definizione di politiche sull’assegnazione delle attività SI/NO
B.9) Tipizzazione delle attività e loro riuso SI/NO
B.10) Semantiche personalizzate per elementi di tipo gateway SI/NO
B.11) Supporto linguaggi programmazione SI/NO
B.12) Interpretazione dei linguaggi dichiarativi SI/NO
B.13) Supporto linguaggi basati su regole SI/NO

126 Capitolo 4. Analisi degli Strumenti BPM
Tabella 4.10: Framework di analisi proposto - Categoria C e D
C)Configurazione sistema BPM
C.1) Min RAM richiesta 0...1
C.2) Min HD richiesto 0...1
C.3) Multipiattaforma SI/NO
C.4) Utilizzo DBMS SI/NO
C.5) Interoperabilità dello strumento con sistemi esterni SI/NO
C.6) Gestione del versionamento del modello di processo SI/NO
C.7) Gestione del versionamento dell’applicazione SI/NO
C.8) Sistema di cifratura dello strumento SI/NO
C.9) Sistema di autenticazione dello strumento SI/NO
C.10) Generazione di file di log sull’utilizzo SI/NO
C.11) Controllo dell’accesso all’applicazione generata basato sui ruoli SI/NO
C.12) Sistema di autenticazione dell’applicazione generata SI/NO
C.13) Interoperabilità dell’applicazione generata con sistemi esterni SI/NO
C.14) Storage sicuro dei dati SI/NO
C.15) Mapping dei dati su DBMS esterni SI/NO
D)Attivazione del processo di business
D.1) Disponibilità della simulazione SI/NO
D.2) Possibilità di personalizzare la configurazione della simulazione SI/NO
D.3) Generazione automatica dei prototipi SI/NO
D.4) Grado di configurabilità dei prototipi 0...1
D.5) BPM Engine associato SI/NO
D.6) Possibilità di eseguire il processo su altri BPM engine SI/NO

4.4. Categorie di analisi e criteri di valutazione 127
Tabella 4.11: Framework di analisi proposto - Categoria E e F
E)Analisi processo di business
E.1) Strumenti di monitoraggio della simulazione del processo SI/NO
E.2) Presenza di un business cockpit SI/NO
E.3) Configurabilità business cockpit 0...1
E.4) Livello di dettaglio business cockpit 0...1
E.5) Console di amministrazione del processo SI/NO
E.6) Monitoraggio attività di processo (BAM) SI/NO
E.7) Monitoraggio di Indicatori di KPI SI/NO
F)Usabilità dello strumento BPM
F.1) Facilità di download 0...1
F.2) Facilità di installazione 0...1
F.3) Facilità di apprendimento 0...1
F.4) Facilità di utilizzo dello strumento di modellazione 0...1
F.5) Facilità nel generare l’applicazione 0...1
F.6) Grado di personalizzazione dello strumento 0...1
F.7) Utilizzo prima di essere produttivi 0...1
F.8) Disponibilità di documentazione SI/NO
F.9) Utilizzo dell’engine 0...1
G)Utenti target
Tabella 4.12: Framework di analisi proposto - Categoria G
Analisti di business
G.1) Documentazione SI/NO
G.2) Progettazione SI/NO
G.3) Verifica SI/NO
G.4) Interoperabilità SI/NO
Sviluppatori
G.5) Progettazione SI/NO
G.6) Implementazione SI/NO
G.7) Verifica SI/NO
Analisti-sviluppatori
G.8) Documentazione SI/NO
G.9) Progettazione SI/NO
G.10) Implementazione SI/NO
G.11) Verifica SI/NO

128 Capitolo 4. Analisi degli Strumenti BPM

Capitolo 5
Valutazione dei Singoli
Strumenti BPM
In questo capitolo vengono mostrati i risultati dell’applicazione del framework
di analisi descritto nel capitolo 4. Per ognuno dei 21 strumenti appartenente
alla lista degli strumenti analizzati in dettaglio (si veda il paragrafo
4.2), il relativo paragrafo riassume i dati piú significativi.
Ogni paragrafo del presente capitolo include al proprio termine un diagramma
tipo “radar” (del tipo di quello riportato in Figura 5.2), che descrive
le valutazioni riassuntive per ogni gruppo di valutazione dello strumento in
esame (categorie da A a F , si vedano le Tabelle da 4.2 a 4.7): poiché la
categoria G non é facilmente quantificabile, essa rimane esclusa da tali diagrammi.
I risultati dettagliati delle valutazioni sono presenti nelle tabelle
presenti nell’appendice A (da tabella A.1 a tabella A.7).

130 Capitolo 5. Valutazione dei Singoli Strumenti BPM
5.1 Adobe LiveCycle Enterprise Edition
Lo strumento considerato è Adobe LiveCycle Enterprise Edition versione 9.0.
Tale suite comprende numerosi componenti che coprono la maggior parte
delle funzionalità tipiche di un sistema BPM.
A. Conformità agli standard
Adobe LiveCycle Enterprise Edition mostra una conformità rispetto allo
standard di interscambio X-PDL 2.0. Per quanto riguarda la modellazione,
questo strumento BPM utilizza un proprio linguaggio. A differenza di
BPMN, ad esempio, non è possibile definire eventi intermedi tra i task.
Non è presente un supporto allo standard di esecuzione BPEL4WS.
B. Modellazione di processo
Adobe LiveCycle Enterprise Edition permette di definire un modello informativo,
un modello organizzativo, permette di gestire le eccezioni e di
definire le transazioni. Supporta il linguaggio di programmazione Java, con
il quale è possibile creare dei componenti che tipizzano le attività epermettono
di definire elementi di tipo gateway con semantiche personalizzate, e
il linguaggio Adobe Flex, con il quale è possibile creare interfacce custom
dell’applicazione. È inoltre possibile definire delle politiche sull’assegnazione
alle risorse delle attività. La figura 5.1 mostra la possibilità di definire un
modello informativo e di assegnare risorse alle attività.
C. Configurazione di sistema
I risultati ottenuti mostrano che lo strumento BPM richiede una quantità di
risorse abbastanza consistente come requisito minimo per poter funzionare
correttamente. È uno strumento multipiattaforma scritto in Java e richiede
la piattaforma j2ee per poter funzionare. Lo strumento è in grado di interoperare
con sistemi DBMS sui quali permette di mappare il modello informativo
del processo. Inoltre l’applicazione generata dal modello di processo
di business può interoperare anch’essa con strumenti esterni. Per quanto
riguarda la security, Adobe LiveCycle Enterprise Edition consente di utilizzare
un sistema di cifratura, un sistema di autenticazione sia dello strumento
sia dell’applicazione generata e permette di effettuare lo storage sicuro dei
dati su DBMS. Inoltre è presente un sistema di gestione delle versioni dei
modelli di processo creati.

5.1. Adobe LiveCycle Enterprise Edition 131
Figura 5.1: Definizione modello informativo e assegnazione delle risorse alle attività
Adobe LiveCycle Enterprise Edition
D. Attivazione del processo
Il prodotto possiede un BPM engine dove è possibile fare il deployment
dell’applicazione direttamente dallo strumento di modellazione del processo
di business. Non possiede uno strumento per simulare il processo prima del
rilascio.
E. Analisi del processo
Adobe LiveCycle Enterprise Edition possiede degli strumenti di analisi del
processo mentre è in esecuzione che permettono sia di monitorare le sue
prestazioni per mezzo dei KPI definiti sia di monitorare l’intera esecuzione
dell’istanza del processo di business. Inoltre è presente una console per la
gestione dei processi che sono stati caricati sul server.
F. Usabilità dello strumento
I risultati ottenuti mostrano che Adobe LiveCycle Enterprise Edition è uno
strumento BPM caratterizzato da una usabilità mediocre. L’utilizzo di
Adobe LiveCycle Enterprise Edition è subordinato da una curva di apprendimento
bassa in quanto richiede che l’utente disponga di conoscenze pregresse
abbastanza approfondite circa il linguaggio Java e Adobe Flex. Infatti uno

132 Capitolo 5. Valutazione dei Singoli Strumenti BPM
dei punti di forza è la personalizzazione dello strumento di modellazione che
però richiede la conoscenza dei linguaggi di programmazione menzionati.
Inoltre sia la fase di reperimento sia quella di installazione dello strumento
BPM ha mostrato difficoltà. Buona la disponibilità di documentazione su
tutti gli aspetti di questo strumento BPM.
G. Utenti target
Adobe LiveCycle Enterprise Edition è uno strumento rivolto agli analistisviluppatori,
in quanto lo strumento permette di descrivere i modelli del
processo in dettaglio, permettendo di specificare parametri che andranno
ad influire l’interoperabilità con strumenti esterni. Inoltre è rivolto agli
sviluppatori, in quanto la creazione di nuovi elementi, per estendere la
capacità espressiva del linguaggio di modellazione, e la personalizzazione
dell’applicazione finale richiedono forti competenze di programmazione.
Riepilogo dell’analisi dello strumento BPM
Il grafico in figura 5.2 mostra il grado di completezza delle funzionalità dello
strumento BPM rispetto alle categorie di analisi.

5.1. Adobe LiveCycle Enterprise Edition 133
Figura 5.2: Valutazione finale Adobe LiveCycle Enterprise Edition

134 Capitolo 5. Valutazione dei Singoli Strumenti BPM
5.2 AgilePoint BPMS
Lo strumento considerato è AgilePoint BPMS versione 4.7. AgilePoint BPMS
può definirsi una vera e propria suite BPM. Infatti possiede tutti gli strumenti
che permettono una modellazione estremamente flessibile e completa
del processo di business, la simulazione del processo definito, l’esecuzione del
processo nel proprio BPM engine e l’analisi di questo che può essere attiva
e passiva.
A. Conformità agli standard
AgilePoint BPMS non segue la standard proposto per la modellazione del
processo di business. Infatti la sua notazione è formata da un insieme di elementi
la cui semantica deve essere definita in modo esplicito. Lo strumento
BPM permette di importare processi già definiti nel formato di interscambio
X-PDL versione 2.0.
B. Modellazione di processo
Lo strumento BPM risulta essere completo sotto tutti i criteri di valutazione
di questa categoria. Infatti è possibile definire un modello informativo e organizzativo
del processo di business. È possibile definire le attività checompongono
una transazione come è anche possibile definire i comportamente
delle eccezioni che possono accadere durante l’esecuzione del processo. AgilePoint
permette di riutilizzare sia processi completi o parziali già definiti
oppure permette di adattare dei template di modelli di processi alle proprie
esigenze progettuali. Tramite il linguaggio di programmazione Visual Basic
oC#èpossibile definire la logica applicativa di ogni componente del modello
di processo: attività e gateway. Inoltre permette di definire query in
SQL per il recupero e l’aggiornamento di dati dal DBMS.
C. Configurazione di sistema
Lo strumento BPM è interamente basato su piattaforma .NET. Permette
l’interoperabilità con altri tool di Microsoft come Sharepoint e Project. Utilizza
diversi DBMS anche se è progettato appositamente per SQL server.
Permette di gestire le versioni sia dei modelli di processi definiti sia delle
applicazioni da esse derivate. L’applicazione generata può interagire con
sistemi esterni soprattutto sviluppati con la stessa tecnologia. Lo svantaggio
di questo strumento sono le risorse minime richieste per poter funzionare
correttamente che tendono a crescere in base al tipo di installazione che si
intende effettuare.

5.2. AgilePoint BPMS 135
D. Attivazione del processo
Lo strumento possiede un ambiente di simulazione su cui è possibile fare delle
previsioni sul modello di processo definito. Inoltre è in grado di generare
automaticamente il prototipo dell’applicazione del processo che viene messo
in esecuzione nel BPM engine proprietario dello strumento. AgilePoint non
permette ad altri BPM engine di eseguire i processi di business da esso
definiti.
E. Analisi del processo
Dal punto di vista degli strumenti di analisi, Agilepoint risulta essere uno
strumento BPM completo. Infatti possiede sia un ambiente di analisi dei
risultati delle varie simulazioni, sia una console per gestire i processi di
business che sono stati rilasciati nel BPM engine. Permette di analizzare
sia attivamente che passivamente le istanze dei processi di business in esecuzione
e di monitorarne le KPI che sono state definite nel Business Activity
Monitoring.
F. Usabilità dello strumento
Lo strumento BPM è abbastanza complesso da apprendere. Infatti vi sono
numerose funzionalità da conoscere. Inoltre richiede delle conoscenze avanzate
pregresse di programmazione nel linguaggio C# e Visual Basic che
potrebbero ritardare l’apprendimento dello strumento. Un altro punto a
sfavore è il processo di installazione dello strumento BPM. Questo richiede
una fase preliminare dove si chiede all’utente competenze nell’installare e
configurare un DBMS, un Web Server e componenti di terze parti necessarie
al funzionamento dello strumento. Nel complesso AgilePoint è uno
strumento complesso da utilizzare per l’utente medio.
G. Utenti target
Gli utenti target di questo strumento BPM sono: gli sviluppatori, in quanto
devono definire la logica delle attività di un processo di business e le interfaccie
dell’applicazione generata dal processo. Gli utenti analisti-sviluppatori
che si devono interfacciare agli sviluppatori per la definizione del processo
di business nei suoi vari modelli. Infine gli analisti di business che possono
ricavare documentazione dalle analisi del processo di business in modo da
cercare di migliorarlo.

136 Capitolo 5. Valutazione dei Singoli Strumenti BPM
Riepilogo dell’analisi dello strumento BPM
Il grafico in figura 5.3 mostra il grado di completezza delle funzionalità dello
strumento BPM rispetto alle categorie di analisi.
Figura 5.3: Valutazione finale AgilePoint BPMS

5.3. Avantage BPM 137
5.3 Avantage BPM
Lo strumento considerato è Avantage BPM versione 1.3. Tale strumento
BPM risulta essere un semplice editor di modelli di processi di business che
inoltre permette di simulare il processo definito.
A. Conformità agli standard
Lo strumento BPM mostra piena conformità rispetto alla notazione BPMN
versione 1.2. Inoltre permette l’esportazione ma non l’importazione dei
modelli di processi nel formato di interscambio X-PDL versione 2.0.
B. Modellazione di processo
Lo strumento BPM permette di definire il modello organizzativo del processo.
C. Configurazione di sistema
Avantage BPM è uno strumento che può essere messo in esecuzione solo su
sistemi operativi Windows. Esso permette di gestire le varie versioni dei
modelli dei processi di business creati utilizzando un DBMS proprietario.
D. Attivazione del processo
Lo strumento BPM permette di simulare il modello del processo di business
definito. Inoltre è possibile variare i parametri di carico per definire diversi
scenari di esecuzione.
E. Analisi del processo
Lo strumento BPM possiede un componente che permette di generare un
reportistica sui risultati ottenuti dalla simulazione del processo di business.
F. Usabilità dello strumento
Avantage BPM risulta essere uno strumento facile da apprendere e da utilizzare.
G. Utenti target
Gli utenti target di questo strumento sono gli analisti di business. Infatti
lo strumento BPM permette di definire in modo intuitivo il processo di

138 Capitolo 5. Valutazione dei Singoli Strumenti BPM
business e il suo modello organizzativo. Inoltre permette di generare della
documentazione sul processo creato e sui risultati ottenuti dalle simulazioni.
Riepilogo dell’analisi dello strumento BPM
Il grafico in figura 5.4 mostra il grado di completezza delle funzionalità dello
strumento BPM rispetto alle categorie di analisi.
Figura 5.4: Valutazione finale Avantage BPM

5.4. Billfish BPM 139
5.4 Billfish BPM
Lo strumento considerato è Billfish BPM versione 3.0. Tale suite comprende
dei componenti che coprono completamente le funzionalità tipiche di un
sistema BPM.
A. Conformità agli standard
Billfish BPM mostra una conformità pari al 55% rispetto alla notazione
di modellazione BPMN 1.2. Billfish BPM non supporta alcuno standard
riguardo i formati di interscambio o linguaggi di esecuzione. In figura 5.5 la
modellazione del processo di riferimento.
Figura 5.5: Modello del processo di riferimento Billfish BPM
B. Modellazione di processo
Billfish BPM permette di definire il modello informativo e organizzativo del
processo. Inoltre permette di definire delle politiche circa l’assegnazione delle

140 Capitolo 5. Valutazione dei Singoli Strumenti BPM
risorse alle varie attività. È possibile importare dei template di processi da
adattare alle specifiche esigenze di modellazione. Lo strumento non permette
di definire le transazioni ne di gestire le eccezioni. Inoltre non è presente
alcun tipo di supporto per i linguaggi di programmazione, dichiarativi o
basati su regole.
C. Configurazione di sistema
Lo strumento BPM dimostra di essere uno strumento leggero dal punto di
vista delle risorse minime richieste. È uno strumento basato sulla tecnologia
Java quindi multipiattaforma. Permette di utilizzare un DBMS esterno
e di gestire le versioni delle applicazioni generate dal modello di processo
di business. Lo strumento possiede un sistema di autenticazione come anche
è possibile averlo nell’applicazione generata. L’applicazione non può
interoperare con sistemi esterni.
D. Attivazione del processo
Billfish BPM mette a disposizione una strumentazione per la simulazione
del processo. Inoltre permette la generazione automatica dei prototipi delle
applicazioni a partire dal modello di processo di business. Lo strumento
BPM possiede un BPM engine associato sul quale è possibile effettuare il
deployment dell’applicazione del processo direttamente dallo strumento di
modellazione.
E. Analisi del processo
Dal punto di vista dell’analisi del processo, Billfish possiede una console per
la gestione dei vari processi rilasciati e uno strumento per il monitoraggio
dell’esecuzione dell’istanza del processo di business in tempo reale.
F. Usabilità dello strumento
Billfish BPM si è rivelato essere uno strumento BPM facile da apprendere
e da utilizzare. Inoltre è estremamente semplice generare delle applicazioni
senza necessariamente avere competenze di programmazione e metterle in esecuzione
nel BPM engine. L’unica nota negativa è dovuta all’impossibilitàdi
personalizzare lo strumento di modellazione. Tuttavia si può affermareche
BillFish BPM è uno strumento BPM caratterizzato da una buona usabilità.

5.4. Billfish BPM 141
G. Utenti target
I principali utenti di Billfish BPM sono gli analisti-sviluppatori. Infatti è
possibile dettagliare il processo con dati del modello informativo e organizzativo
e la sua esecuzione può essere monitorata in tempo reale. Lo strumento
permette di generare una buona documentazione del processo definito. Per
questo motivo in parte può essere utilizzato da un target di utenti di tipo
analisti di business.
Riepilogo dell’analisi dello strumento BPM
Il grafico in figura 5.6 mostra il grado di completezza delle funzionalità dello
strumento BPM rispetto alle categorie di analisi.
Figura 5.6: Valutazione finale Billfish BPM