Il Process Mining può essere definito come una combinazione di tecniche di data science e di business process management (BPM) che permette di analizzare i processi aziendali tramite l’analisi dei log e dei dati di eventi generati dai sistemi informativi. Questi dati provengono da diverse fonti aziendali, come ERP (Enterprise Resource Planning), CRM (Customer Relationship Management), sistemi di gestione delle risorse umane e sistemi di gestione della produzione. Il punto centrale del Process Mining è che utilizza i dati realmente generati dai processi.
Nella forma classica, gli algoritmi di Process Mining vengono utilizzati per costruire un modello del processo a partire dai dati estratti. Questo modello visualizza il flusso delle attività, rappresentando le sequenze di eventi e i vari percorsi seguiti all’interno del processo. L’output può essere una mappa grafica che mostra tutte le possibili varianti del processo, incluse le eccezioni o deviazioni dai flussi standard. I modelli appartenenti a questa categoria vengono denominati imperativi e, in caso di processi ben definiti e standardizzati, riescono a descrivere in maniera corretta e completa i processi analizzati.
Per i processi che non hanno queste caratteristiche, i modelli imperativi spesso non si rivelano adatti perché rischiano di perdere di generalità, escludendo varianti lecite, o di diventare illeggibili ed inutilizzabili, i famosi “spaghetti model”.
In Figura 2 viene mostrata una rappresentazione di un processo reale come l’area verde sulla sinistra. Un modello imperativo può essere rappresentato come l’ellisse blu al centro della figura, esso può rappresentare una parte del processo reale eventualmente andando ad includere varianti e percorsi non presenti nella realtà. Un modello dichiarativo è basato su regole e vincoli che possono essere utilizzati non per definire tutti i possibili percorsi del processo ma per delimitare la regione in cui le tracce del processo possono trovarsi. In maniera grafica questo è mostrato nella parte destra della figura.
Revelis crede fortemente nelle attività di ricerca e sviluppo e, negli scorsi mesi, ha partecipato allo sviluppo di tecniche di process intelligence spiegabile e consapevole, basate sull’uso di linguaggi e tecniche dichiarative per rappresentare processi flessibili.
Il lavoro svolto da Revelis ha avuto l’obiettivo di implementare un prototipo dimostratore delle tecniche applicando queste ultime ad un caso di studio industriale.
Declarative Process Mining
Il Process Mining Dichiarativo rappresenta un’evoluzione innovativa nell’ambito dell’analisi dei processi. A differenza del Process Mining tradizionale, che si basa principalmente sull’estrazione di modelli di processo da log di eventi, il Process Mining dichiarativo introduce un livello di astrazione superiore. Declare è un linguaggio dichiarativo per la modellazione dei processi che consiste in un insieme di template che esprimono le proprietà temporali delle tracce di esecuzione dei processi.
I modelli (o template) Declare possono essere classificati in quattro categorie distinte, ognuna delle quali affronta aspetti diversi del comportamento dei processi:
- modelli di esistenza, che specificano la necessità o il divieto di eseguire una particolare attività potenzialmente con vincoli sul numero di occorrenze;
- modelli di scelta, incentrati sul concetto di scelte di esecuzione, in quanto modellano scenari in cui esiste un’opzione relativa a quali attività possono essere eseguite;
- modelli di relazione, che stabiliscono una dipendenza tra le attività in quanto stabiliscono che l’esecuzione di un’attività richiede l’esecuzione di un’altra, spesso in base a condizioni o requisiti specifici;
- modelli di negazione, modellando l’esclusività reciproca o le condizioni proibitive nell’esecuzione delle attività.
Ad esempio il modello Existence(A) indica che in una traccia del log deve essere presente l’attività A. Il modello Exclusive Choice(A, B) stabilisce che le attività A e B possono apparire in una traccia ma non contemporaneamente. Per il modello ChainResponse(A, B) ogni volta che A appare nell’istanza di processo allora B è l’attività immediatamente seguente.
Answer Set Programming
La Answer Set Programming (ASP) è una forma di programmazione logica non monotona che si concentra sulla risoluzione di problemi rappresentandoli come insiemi di regole logiche. Invece di fornire un singolo risultato, l’ASP fornisce un insieme di modelli (o insiemi di risposte) che soddisfano tutte le regole del programma. Questo la rende particolarmente adatta per affrontare problemi complessi e incerti, dove possono esistere molteplici soluzioni valide.
Codifica dei modelli Declare in ASP
All’interno del progetto è stata messa a punto una tecnica di traduzione automatica dei modelli Declare e dei log di processo in programmi logici ASP. Ciò permette di utilizzare la ASP per effettuare dei task di Conformance Checking e Query Checking. Nel primo caso si vuole verificare l’aderenza di un log di eventi ad un insieme di template Declare. Nel secondo caso, si vuole individuare tutte le possibili soluzioni di un’interrogazione fatta specificando un template Declare, un’attività del processo ed una o più variabili.
Esempio:
ChainResponse(‘A’, X) con supporto minimo 0.8
Sia A un’attività del processo e X una variabile, il risultato della query è dato da tutte quelle attività che seguono immediatamente l’attività A rendendo il modello vero almeno nel 80% dei casi.
Caso di Studio
Le tecniche presentate finora sono state applicate utilizzando i dati sulla gestione delle pratiche presentate per l’ottenimento di Contratti di Sviluppo (CdS) con un’importante agenzia nazionale per lo sviluppo. Il processo preso in considerazione è suddiviso in due macro-fasi indipendenti (Istruttoria e Verifica Tecnica) che sono state analizzate separatamente. Utilizzando il prototipo appositamente implementato, la prima attività è stata quella di ricavare un modello Declare per le due fasi. Un estratto del modello per la fase di Verifica Tecnica è qui riportato.
| 0: Existence1[VT merito in lavorazione] | | |
| 6: Exactly1[VT merito in lavorazione] | | |
| 8: End[VT merito in lavorazione] | | |
| 14: Init[VT Merito da assegnare] | | |
| 15: Choice[VT merito in lavorazione, VT Merito da assegnare] | | |
| 16: Choice[VT Merito da assegnare, VT merito in lavorazione] | | |
| 21: Chain Response[VT Merito da assegnare, VT merito in lavorazione] | | |
| 22: Precedence[VT Merito da assegnare, VT merito in lavorazione] | | |
| 23: Alternate Precedence[VT Merito da assegnare, VT merito in lavorazione] | | |
| 24: Chain Precedence[VT Merito da assegnare, VT merito in lavorazione] | | |
| 27: Not Chain Response[VT merito in lavorazione, VT Merito da assegnare] | | |
| 28: Not Chain Precedence[VT merito in lavorazione, VT Merito da assegnare] | | |
Ogni riga rappresenta una regola che risulta valida per le tracce del log analizzate dall’algoritmo. Ad esempio le righe 0 e 6 indicano l’esistenza di un’unica istanza attività “VT merito in lavorazione” Utilizzando questo modello, opportunamente rivisto, è possibile effettuare l’analisi di Conformance Checking che stabilisce se delle istanze di processo violino o meno i vincoli specificati. Questa tecnica è stata applicata su un insieme di tracce fornito dal cliente e non utilizzato per la creazione del modello. Tra le istanze analizzate, le seguenti due hanno riportato delle violazioni di vincoli che sono mostrate nella seguente tabella:
| Trace: 0 Constraints: 15, 16 |
| Trace: 1 Constraints: 23, 24 |
Andando a verificare i vincoli violati nelle tracce si può vedere che:
- Nella traccia 0, le violazioni dei vincoli 15 e 16 sono dovute all’assenza di almeno una tra le attività “VT merito in lavorazione” e “VT Merito da assegnare”;
- Nella traccia 1 vengono violati i vincoli 23 e 24 che indicano che l’attività “VT merito in lavorazione” non è preceduta dall’attività “VT Merito da assegnare”.
Nel modello Declare mostrato in precedenza, è possibile vedere che l’attività di “Merito da Assegnare” è marcata come init alla riga 14 della tabella del flusso di Verifica Tecnica. Per verificare quali siano le attività eseguite nel caso essa sia presente nel log è possibile utilizzare la tecnica del Query Checking sottoponendo un’interrogazione al prototipo formata dal template Precedence, primo parametro “Merito da Assegnare” e secondo parametro la variabile X. I risultati sono:
- X: VT merito conclusa – support: 1
- X: VT merito in lavorazione – support: 1
- X: VT Merito da assegnare – support: 1
Ciò indica che le tre attività sopra menzionate vengono eseguite solo nel caso in cui “Merito da Assegnare” è eseguita.
Per verificare l’esistenza di percorsi alternativi a quello che inizia con “Merito da Assegnare”, è possibile utilizzare una query di “Exclusive Choice” con primo parametro “Merito da Assegnare” e secondo la variabile X. I risultati sono:
- X: VT merito conclusa – support: 0.7272727272727273
- X: VT Fast Track da assegnare – support: 0.7727272727272727
- X: VT Fast Track in lavorazione – support: 0.7727272727272727
- X: VT fast Track conclusa – support: 0.7272727272727273
Come si può facilmente vedere esiste un ramo di Valutazione Tecnica delle istanze alternativo a quello principale e denominato “Fast Track”.
Conclusioni
Le tecniche e gli algoritmi qui descritti permettono un nuovo approccio al Process Mining che consente un’analisi più flessibile. In particolar modo è possibile descrivere le proprietà di un processo utilizzando dei vincoli noti a priori o scoperti automaticamente. Questi vincoli possono essere utilizzati per identificare anomalie nell’esecuzione del processo tramite un’analisi di Conformance Checking. Inoltre è possibile esplorare le caratteristiche del processo ponendo delle interrogazioni utilizzando delle tecniche di Query Checking.
Autore: Luigi Granata
