Sperimentazione di un sistema di Business Intelligence

14 ELENCO DELLE FIGURE
Struttura e organizzazione della tesi
La tesi e` organizzata in questo modo:
il primo capitolo introduce la questione relativa al Business Process Mana-
gement e al supporto fornito dai sistemi informativi per il miglioramento e
l’automatizzazione di tale processo;
il secondo capitolo affronta il problema del Process Mining, analizzando le
tecniche piu` diffuse e confrontando un approccio di tipo procedurale con un
approccio dichiarativo ;
nel terzo capitolo vengono spiegate le specifiche tecniche del linguaggio SCIFF
e dell’algoritmo ICL utilizzato per l’apprendimento;
nel quarto capitolo viene analizzato il linguaggio grafico DecSerFlow e la sua
traduzione in vincoli SCIFF;
nel quinto capitolo viene esaminato il plugin DecMiner basato su SCIFF e
DecSerFlow;
nel sesto capitolo viene spiegata la sperimentazione effettuata sui dati di
una popolazione studentesca, partendo dall’analisi dei dati a disposizione e
proseguendo con la valutazione delle scelte effettuate e dei risultati ottenuti.
Capitolo 1
Business Process Management
Ogni azienda, indipendentemente dalle dimensioni, dal settore in cui
opera e dal tipo di servizi di cui e` fornitrice, deve gestire al suo interno
processi di business complessi che sono alla base di tutte le attivita`. I pro-
cessi di business, molto diversi tra loro a causa della diversa complessita`,
della differente durata, delle attivita` appartenenti al processo e delle en-
tita` partecipanti, devono essere efficaci ed efficienti, integrando attivita`, in-
terne o esterne, se in qualche modo influenzano il processo, utenti, contenuti
ed eventuali normative. Il Business Process Management e` la una gestio-
ne dei processi di business capace di migliorare continuamente i processi e
prevede metodi per l’analisi e la comprensione dei dati, per la riprogettazione
e per l’attuazione delle modifiche, tecniche per la diagnosi e per il confron-
to dei risultati. Analizziamo di seguito il procedimento di Business Process
Management. Partiamo da alcune considerazioni circa i processi e le loro
caratteristiche.
15
16 1. Business Process Management
1.1 Caratterizzazione del processo di business
I processi di business possono essere molto diversi tra loro e non soltanto
nel caso in cui essi provengano da contesti molto differenti; anche all’interno
di uno stesso contesto o di uno stessa organizzazione esistono processi ben
diversi. Al di la` delle entita` e delle attivita` che caratterizzano un processo,
del numero e della frequenza con cui esse si presentano, vogliamo eviden-
ziare alcune proprieta` che diversificano i processi:questi possono essere piu`
meno complessi a seconda del livello di interazione tra le entita`, della col-
laborazioni tra i partecipanti, della sincronizzazione di attivita` o decisioni;
possono risultare piu` e meno predicibili a seconda delle circostanze che pos-
sono alterare o modificarne l’esecuzione. In alcuni casi vi possono essere
situazioni fortemente impredicibili, in quanto legati a fenomeni naturali, del
tutto aleatori o di cui non si e` ancora spiegata la causalita`. Inoltre possono
essere piu` o meno ripetitivi, sulla base della frequenza vengono eseguiti. La
comprensione e la gestione dei processi e` dunque un’operazione complessa
e delicata in quanto puo` influenzare fortemente le situazioni all’interno di
un’organizzazione.
1.2 Fasi del BPM
Il BPM risulta dunque un’operazione complessa e generalmente vien vista
come costituita da quattro fasi :
design : definizione di un modello per l’esecuzione delle attivita`;
implementazione : adattamento del sistema al modello;
attuazione : applicazione del modello definito;
1.2 Fasi del BPM 17
diagnosi : analisi dei risultati.
Figura 1.1: Fasi del Business Process Management
Nell’approccio tradizionale la prima fase di un BPM e` la fase di design,
in cui si stabilisce un modello di processo sulla base delle attivita` necessarie,
seguita da una fase di implementazione nella quale si adatta il sistema al
modello stabilito. La successiva fase di attuazione consiste nell’apportare le
modifiche e i cambiamenti, necessari per adeguare i processi a quanto stabili-
to nella progettazione. L’esecuzione dei processi genera nuovi dati utilizzabili
in fase di diagnosi, fondamentale per analizzare gli effetti ottenuti dal cambi-
amento e poter riprogettare i processi tenendo conto dei risultati precedenti.
Tradizionalmente si pone particolare attenzione a queste prime due fasi che
ovviamente sono alla base delle operazioni successive e che sono svolte al fine
di ricercare migliorie apportabili ai processi esistenti. Le migliorie possono
riguardare l’ordinamento abituale dello svolgimento dello attivita`, sceglien-
done uno piu` adatto alle politiche, al regolamento e all’efficienza, o l’ottimiz-
zazione delle performance, o il controllo degli accessi, riprogrammando la
18 1. Business Process Management
politica d’accesso per non interferire nello svolgimento del lavoro abituale.
Le modalita` di attuazione di un processo di business sono legate a interessi
di vario tipo a seconda del settore in cui essi hanno luogo e dagli obiettivi
dell’azienda. Organizzazioni commerciali avrenno come fini principali pro-
duttivita` e redditivita`, organizzazioni istituzionali avranno fini diretti alla
migliore fruibilita` dei servizi da parte degli utenti. In tutti i casi a queste
motivazioni se ne aggiungono altre di tipo politico, vincoli di tempo, norma-
tive. Nella creazione di un modello, pero`, il legame con gli obiettivi spesso
puo` risultare poco diretto. Senza una documentazione completa e senza stru-
menti adatti all’analisi, puo` risultare alquanto difficile attuare procedure di
miglioramento dei processi, sia in fase di riprogettazione, sia in fase di at-
tuazione. Le principali problematiche da affrontare in un approccio di questo
tipo sono principalmente di due tipi: da un lato possono esserci forti diver-
sita`, tra il modello definito in fase di design e la situazione realmente esistente
all’interno di una azienda, rendendo difficile il cambiamento o forzando un
cambiamento inadatto. Dall’altro lato si presenta il problema dell’interpre-
tazione dei dati e di una possibile visione soggettiva da parte di manager e
analisti del sistema.
1.3 Il supporto dei Sistemi Informativi Azien-
dali al BPM
Gli attuali sistemi informativi aziendali offrono sicuramente un valido
supporto per evitare questi problemi, ma generano allo stesso tempo una
situazione nuova e differente da quella evidenziata in precedenza, che con-
sente di vedere il problema da un’altra prospettiva: la grande quantita` di dati,
indubbiamente molto utile, necessita di strumenti adatti per essere elabora-
1.3 Il supporto dei Sistemi Informativi Aziendali al BPM 19
ta e fornire informazioni sostanziali che altrimenti resterebbero nascoste e
disperse all’interno della moltitudine di informazioni. E’ possibile pensare
ad un sistema in grado di utilizzare i dati a disposizione selezionando, ma-
nipolando, raggruppando i dati in ogni modo possibile, selezionando attivita`
e informazioni di particolare interesse. Un sistema informativo aziendale, in-
fatti, raccoglie, organizza, elabora e gestisce dati necessari per la conduzione
dell’azienda . Tali dati possono nascere nell’azienda in seguito allo svolgimen-
to dei vari processi oppure essere acquisiti come risultato delle relazioni con
soggetti esterni e possono essere destinati a consumo interno o a terzi. Alcu-
ni sistemi informativi, infatti, contengono un modello esplicito di processi di
business e gestiscono il controllo di flusso, altri supportano tool adatti alla
rilevazione del modello, ma senza definirne uno esplicitamente, altri memo-
rizzano semplicemente i dati e tengono traccia di ogni evento che si verifica
all’interno del sistema in esame. Le informazioni ottenute in questo modo
sono la base per la conoscenza dei processi del sistema e hanno il vantaggio
di non fornire alcuna visione soggettiva rispetto agli eventi finalizzata allo
sviluppo di sistemi per un controllo di flusso automatizzato. Gli eventi me-
morizzati, assieme ovviamente alle indicazioni circa il tempo, la modalita`, le
caratteristiche con cui tali eventi si verificano e le entita` coinvolte, costitui-
scono i cosiddetti log di eventi e rappresentano il punto di partenza per il
process mining. Partiamo da queste osservazioni per definire un sistema di
Business Intelligence a supporto della gestione dei processi. Per sistema di
Business Intelligence intenderemo genericamente sia l’insieme di processi per
raccogliere ed analizzare informazioni strategiche, sia la tecnologia utilizza-
ta nella realizzazione del sistema e le informazioni ottenute come risultato.
Scopo di un sistema di questo tipo sara` non solo l’organizzazione regolare
e sistematica delle informazioni sugli eventi di un’azienda, ma anche l’es-
20 1. Business Process Management
trazione di informazioni aggiuntive, nascoste, ma spesso fondamentali per
comprendere associazioni tra gli eventi.
Figura 1.2: Estrazione della conoscenza
1.4 Process Mining
L’obiettivo del Process Mining e` estrarre informazioni circa i processi a
partire dai log di transazioni. Come spiegato nei paragrafi precedenti lo
svantaggio di tecniche classiche di BPM e` quello di partire dal design senza
conoscere a fondo la situazione esistente, dove per conoscenza si intende non
solo la cognizione delle tempistiche e dell’ordine esecutivo delle azioni, ma
anche la comprensione di alcune informazioni aggiuntive. Il Process Mining
consente di invertire il processo partendo non dal design del flusso, ma dalla
raccolta delle informazioni sui processi che hanno luogo, utilizzando i log di
eventi dei Sistemi Informativi. Gli eventi indicano qualcosa che si e` verificato
e fanno riferimento ad un’azione (che chiameremo attivita`) e appartengono ad
un caso. Supponiamo che i Sistemi Informativi memorizzino tali informazioni
1.5 Workflow Mining 21
assieme naturalmente ad un riferimeto temporale. Il formato utilizzato dai
sistemi transazionali come ERP, CRM, o sistemi di gestione del workflow
purtroppo non e` omogeneo. In questo contesto non ci addentreremo in questo
problema, ma ci baseremo sull’assunzione della possibilita` di memorizzare i
dati sugli eventi in un log. Tali log sono usati per costruire una specifica di
processo che modelli adeguatamente i comportamenti registrati.
1.5 Workflow Mining
Il termine Process Mining si riferisce ai metodi per filtrare una descrizione
strutturata del processo partendo da un set di dati reali. Poiche´ questi meto-
di evidenziano i cosiddetti processi case-driven, basati sui casi, attualmente
supportati da sistemi di gestione del workflow, useremo spesso il termine
workflow mining. Questa tecnologia si sta evolvendo nella direzione di una
maggiore flessibilita` operativa in grado di affrontare la gestione delle eccezioni
nel workflow ed eventualmente la sua evoluzione. Cio` significa che gli agen-
ti del sistema non sono completamente vincolati all’andamento prestabilito,
ma possono allontanarsi leggermente da questo e seguire un andamente dif-
ferente, ma pur sempre controllato. L’evoluzione del sistema, tenuta sotto
controllo, puo` indicare come gestire le eccezioni: una deviazione, infatti, puo`
restare un caso unico e isolato, ma puo` anche ripresentarsi con una certa fre-
quenza tanto da richiedere la rivisitazione e la modifica del modello prestabil-
ito. In situazioni come questa sarebbe auspicabile creare un ciclo che, tramite
il feedback proveniente dagli eventi, consenta di cercare le imperfezioni nel
design e individuare i cambiamenti necessari.
22 1. Business Process Management
1.6 Composizione di un log di eventi
Gli eventi che un sistema informativo deve memorizzare possono essere
molto diversi e diverse sono le modalita` con cui e` preferibile memorizzarli.
Cio` non vuol dire pero` che non sia possibile individuare un formato facil-
mente utilizzabile nella maggior parte dei casi. Sfortunatamente i sistemi
informativi attualmente esistenti fanno uso di un formato specifico. Non an-
dremo nello specifico della discussione, ma ci baseremo sulla semplice e valida
assunzione che il log contenga comunque informazioni sugli eventi eseguiti,
a prescindere dal formato utilizzato. In ogni caso l’analisi svolta in questo
lavoro si basa sul formato XML, supportato da molti tool e utilizzabile in
una serie di prodotti esistenti sul mercato.
Questo formato risulta particolarmente comodo, in quanto consente il log-
ging di processi multipli in un semplice file XML.
Ogni caso e` un’istanza di un processo e viene dunque chiamata ProcessIn-
stance . Essa e` composta da piu` eventi, chiamati AuditTrailEntry. Ogni
AuditTrailEntry corrisponde a un singolo evento e rientra in un tipo di
WorkflowModelElement che consente di differenziare un tipo di evento da
un altro. Un WorkflowModelElement puo` riferirsi ad un singolo task o ad un
sottoprocesso.
Per ogni AuditTrail e` necessario specificare lo stato dell’evento tramite
l’attributo EventType. Sono stati individuati 8 possibili stati di transizione
di un evento all’interno di un sistema di workflow illustrati in fig.
I possibili stati di un evento sono:
new : se e` appena stato creato ;
schedule : abilitato;
start : avviato;
1.6 Composizione di un log di eventi 23
withdraw : eliminato;
suspend : sospeso;
resume : ripreso;
abort : terminate con anomalia;
complete : terminata;
Figura 1.3: Transizioni di stato di un evento
E’ bene pero` precisare che questa scelta deriva dal frequente uso di siste-
mi di workflow per il monitoraggio di eventi legati a processi informatici, in
cui il tipo di evento indica concretamente il suo stato all’interno del sistema,
specifica cioe` in che fase della propria esecuzione si trova l’evento. Questa
tipizzazione naturalmente non rispecchia tutti i casi di applicazioni di Pro-
cess Mining, in cui spesso si incontrano situazioni in cui gli stati di un evento
possono essere semplicemente due o tre. Su molti dataset reali, per esempio,
diffuse sono le situazioni in cui un evento puo` trovarsi in uno stato di start
24 1. Business Process Management
o di complete, mentre tutti gli altri stati non hanno alcun significato prati-
co. Questa classificazione, qui esposta al fine di una comprensione generale
sull’argomento, non sara` utilizzata nella fase sperimentale di questo lavoro,
dove, trattando azioni effettuate da personale umano, si utilizzeranno solo
azioni effettuate e quindi in uno stato complete.
WorkflowModelElement e EventType sono attributi obbligatori per ogni Au-
ditTrailEntry. E’ possibile specificare altri elementi opzionali: Data, Time-
stamp, and Originator .
I Data sono gli elementi che possono essere utilizzati per memorizzare i dati
relativi agli eventi del caso . Il Timestamp indica il momento di esecuzione
ed e` fondamentale per calcolare i risultati da un punto di vista temporale:
tempo di flusso, durata del servizio, utilizzo, ma anche semplicemente re-
lazioni di precedenza e sequenzialita`. L’attributo Originator si riferisce agli
attori , utenti o organizzazioni, che eseguono l’evento. A partire dal log di
eventi, strutturato secondo le modalita` descritte sopra, sono state sviluppate
tecniche di Process Mining che verrano discusse nei capitoli successivi.