Progetto/Relazione BPI-Challenge 2012

O_SELECTED = selezione del cliente che riceve l

offerta da inviare al cliente;

O_PREPARED / O_SENT = e invio della

stessa al cliente;

O_SENT BACK = ricezione della risposta del cliente

proposta;

O_CANCELLED / O_DECLINED = stato finale di insuccesso per

Rappresentano gli stati delle attività di lavoro che avvengono durante il

processo.

lavoro W_Afhandelen leads = ricerca di ulteriori informazioni a seguito di

incomplete comunicazioni iniziali;

W_Completeren aanvraag = completamento della pre-accettazione

della richiesta;

W_Nabellen offertes = classificazione dei clienti per la trasmissione

W_Valideren aanvraag = valutazio

W_Nabellen imcomplete dossiers = ricerca di ulteriori informazioni;

W_Beoordelen fraude = indagine e valutazione su sospetto caso di

frode;

W_Wijzigen contractgegevens = modifica dettagli del contratto

Inoltre, per ciascun oggetto preso in carica da attività manuali, vi è una distinzione in base al suo ciclo

di vita: SCHEDULE:

in futuro;

START: inizio della lavorazione;

COMPLETE: conclusione del lavoro;

start risulta essere una sola (che infatti occorre nel 100% dei casi), mentre le attività di

end sono molteplici e con diverse frequenze di occorrenza. Se ne riporta una tabella riassuntiva

prelevata dal tool ProM: Figura 2: Eventi iniziali e finali (ProM)

attività più frequenti in base al rapporto eventi/giorno:

Figura 3: Attività più frequenti (Celonis)

2.1 Mappa generale del processo

Il processo viene inizializzato da una richiesta di un prestito personale o scoperto attraverso un

richiesta inoltrata dal cliente. Dopo aver completato la richiesta con informazioni aggiuntive ottenute

l caso in

cui risulti idoneo, alla richiesta precedentemente effettuata si integra una proposta

respinta.

esempio il controllo delle frodi o la mancanza di informazioni essenziali da parte del cliente.

Utilizzando il tool Disco e visualizzando il 35% delle attività e il 4% dei path, è possibile ottenere la

seguente mappa generale che riassume quanto detto sopra:

Figura 4: Mappa generale del processo (Disco)

In particolare, nel caso del sotto-processo A, esplodendo la percentuale di threshold al massimo, si

ha la seguente mappa: Figura 5: Mappa esplosa del sotto-processo "A" (Disco)

appunto A_SUBMITTED).

Prendendo in esame il sotto-processo O, esplodendo la percentuale di threshold al massimo, si ha la

Figura 6: Mappa esplosa del sotto-processo "O" (Disco)

Infine, prendendo in esame il sotto-processo W, si ha la seguente mappa esplosa:

Figura 7: Mappa esplosa del sotto-processo "W" (Disco)

Tale sotto-

immediatamente è il numero di archi e attività che lo rendono più articolato rispetto ai due sotto-

processi presi precedentemente in esame.

Per quanto riguarda lo studio delle somme richieste di prestito o come scoperto, è stato analizzato

AMOUNT_REQ riscontrando alcune anomalie. Nel caso specifico, vi erano 17 richieste di

prestito dal valore di 1 e 0 euro che ovviamente sono state rifiutate; mentre la somma più richiesta è

di 5000 euro che corrisponde al 12,58% di tutte le richieste.

Figura 8: Top 10 richieste di prestito/scoperto (Disco)

Figura 9: Top 10 richieste di prestito/scoperto anomale (Disco)

3 Analisi statistica degli eventi

Un passo necessario per un analisi complessiva è indubbiamente lo studio degli eventi, la loro

distribuzione nel tempo e la loro composizione.

Come possiamo notare dal grafico estrapolato dalla sezione Statistics/Overview del tool Disco, la

distribuzione degli eventi totali non è costante nel tempo, ma presenta dei picchi: ad esempio nel

giorno 23-02-2012 alle ore 9:38 si presenta un rapporto events/hour pari a 399.

Figura 10: Panoramica statistiche eventi nel tempo (Disco)

Come è facilmente osservabile, i giorni in cui vi sono pochi eventi corrispondono generalmente ai

giorni festivi e fine settimana, mentre durante le ore di apertura, a differenza del resto della giornata,

si verificano dei picchi in termini di numeri di eventi per ora.

La durata media di un case è di 8.6 giorni, come vedremo in seguito però questa stima è influenzata

da alcuni casi particolari che richiedono tempi o troppo brevi (1,855 secondi) o eccessivamente lunghi

(137 giorni e 5 ore). 01-10-2011 aumenta coerentemente da come ci si potrebbe

aspettare da un servizio del genere, di inversione di tendenza è il periodo

natalizio, in cui si può ipotizzare una chiusura degli uffici e quindi la presa in carico di sole domande

online. Figura 11: Panoramica statistiche dei case nel tempo (Disco)

Preso in esame il grafico dei task (Figura 10) si può notare che le 7 attività più frequenti su 36

prendono in carico il 50% degli eventi, nello specifico sono 4 le attività di tipo manuale più frequenti

e che coprono il 35.4% degli eventi.

Figura 12: Panoramica frequenze attività (Disco)

Le risorse sono 69 e sono identificate da numeri interi, il 17,42% degli eventi utilizza la risorsa 112

che infatti ha la più alta frequenza relativa ed è presente in tutti i case, ma solamente nelle transizioni

schedule e complete. Figura 13: Panoramica frequenza risorse (Disco)

Sono inoltre stati analizzati i sotto-processi e : in particolare, nel caso del sotto-

processo si possono notare un numero di eventi che, al contrario dei sottoprocessi e ,

non sono trascurabili nel fine settimana.

A_SUBMITTED, possono difatti avvenire in qualsiasi giorno, a prescindere che sia feriale o festivo.

3.1 Major behaviour e varianti

Rispetto al major behaviour le varianti sono 4.366, considerando le prime 10 varianti queste

coinvolgono il 49% dei case totali.

Di seguito viene mostrato e le prime dieci varianti:

Figura 14: Happy path (Celonis)

Figura 15: Top 10 varianti (Disco)

Figura 16: Performance delle prime 3 varianti

Mettendo a confronto le prime tre varianti si nota che condividono le attività iniziali, ma non quelle

finali; inoltre, la loro durata media differisce (anche notevolmente) a causa della presenza del

W_Afhandelen leads.

3.2 Dotted Chart

del plugin di ProM DottedChart, che attraverso una rappresentazione grafica mette in evidenza

timestamp mentre su quello

delle Y vi sono i vari case

delle possibili fluttuazioni e se in generale si potesse affermare che i vari arrivi dei processi sono

costanti per tutto il tempo. Per quanto concerne i diversi arrivi è facilmente visibile che questi sono

costanti per tutto il tempo, sono pochi difatti gli eventi che impiegano un tempo maggiore rispetto

alla media. Uno in particolare, che viene identificato appunto come outlier, è sicuramente il

W_Wijzigen contractgegevens

completato; per questo motivo si è deciso di approfondire ulteriormente su Disco e Celonis

di questa attività.

Dai risultati ottenuti si può osservare che una risorsa in particolare (la 10912) rallenta il case in cui

questo task è coinvolto. Inoltre,

sua durata media è di circa 31 giorni, il che mostra come in 2 casi sia rapida la sua esecuzione mentre

in altri 2 vi sia un vero e proprio rallentamento. Aldilà di questa particolare attività è possibile stabilire

che i casi che richiedono più di 90 giorni per la loro esecuzione sono solo 2, mentre quelli che ne

richiedono più di 80 sono 6; si può stabilire comunque che i processi tipicamente richiedono un tempo

costante. Figura 17: Dotted chart case/timestamp (ProM)

Inoltre, impostando come asse delle ordinate gli eventi per ogni attività, si può notare la loro

distribuzione nel tempo: Figura 18: Dotted Chart eventi/timestamp (ProM)

In particolare, 2 attività sono eseguite in modo costante nel log (A_SUBMITTED e

A_PARTLYSUBMITTED sono le attività sempre eseguite in ogni case), mentre vi sono altre attività

che sono eseguite più sporadicamente, come ad esempio W_Wijzigen contractgegevens, che si occupa

della Anche in questo, la risorsa 10912 è coinvolta. Si può

evidenziare inoltre che dal 29-02-2012 diverse attività non vengono eseguite.

4 Process Discovery

Lo scopo del Process Discovery è prendere in input un event log e produrre in output un modello di

processo, gli algoritmi del Process Discovery

rappresentativo che in pratica catturano i comportamenti più frequenti del log.

Esistono diversi algoritmi di estrazione e si basano sulle due principali caratteristiche degli event log:

Con il termine rumore si vogliono evidenziare i comportamenti che sono rari ed eccezionali

mentre per incompletezza si intendono quei log che contengono solo una

frazione del comportamento mostrato da un processo di business.

Di seguito verranno riportati i vari modelli estratti evidenziando i risultati ottenuti mediante i vari

algoritmi e filtri applicati.

Il primo algoritmo che stato utilizzato per estrarre il modello è , questo algoritmo è in

grado di generare modelli di processo che presentano attività concorrenti, ma non supporta tracce

contenenti attività duplicate ed ignora il problema del rumore nei log.

Il modello estratto risulta essere molto difficile da interpretare infatti le principali cause sono:

un numero molto elevato di archi (spaghetti like)

presenza di alcuni Eventi (nodi) completamente scollegati nella rete

la rete ottenuta non gode della proprietà sound

D

poco soddisfacente: Figura 19: Modello estratto da Alpha miner (ProM)

presenza di implicit places

loop di lunghezza 1 e 2 non rappresentati

non-local dependencies

representational bias

non tiene conto delle frequenze

Osservando quindi Alpha Miner filter log using simple

heuristics i parametri che sono stati selezionati sono il 100% degli eventi intermedi, mentre come

start ed end sono stati presi quelli complete degli application. spaghetti like

rimangono i problemi di eventi completamente scollegati dalla rete, oltre al fatto che la rete ancora

generata non è sound.

Figura 20: Modello estratto da Alpha miner + "filter log using simple heuristics" (ProM)

Heuristic Miner, questo algoritmo rispetto al

precedente riesce a superare alcune limitazioni come il filtraggio di componenti eccezionali, quindi

con una gestione migliorata del rumore, inoltre permette di derivare la frequenza di esecuzione delle

Come risultato otteniamo un modello che ha fitness pari al 30,25%, ma che non è una Petri net e, per

tale motivo, convert heuristics net into petri net

workflow net perché ci sono due end place invece di uno solo.

Figura 21: Modello estratto da Heuristic miner + "convert heuristics net into petri net" (ProM)

Inductive Miner con Noise threshold pari a

0.20 che, rispetto ai modelli precedentemente estrapolati, ci offre risultati molto soddisfacenti. Tutti

riesce ricorsivamente a suddivid -log fino a che non contengono singole

attività, durante questa suddivisione vengono identif