Dipartimento di Informatica
Corso di laurea magistrale in Data Science and Business Informatics
TESI DI LAUREA
ANALISI ESPLORATIVA E DI DATA MINING
PER LA SUPPLY CHAIN
RELATORE
Prof. Salvatore RUGGIERI
CANDIDATO
Emiliano FUCCIO
SOMMARIO
Il presente lavoro di tesi nasce nell’ambito dell’esperienza di tirocinio maturata presso la BNova, società di consulenza che ha il proprio core business nei settori della Data intelligence e della Big Data Analytics.
Il settore di riferimento, che fa da scenario di fondo a questo lavoro è quello della logistica e più in particolare quello delle spedizioni di prodotti farmaceutici. L’obiettivo consiste nell’analizzare i dati prodotti durante le singole spedizioni.
L’analisi in particolare, viene condotta utilizzando tecniche che spaziano nei diversi ambiti che vanno dalla data exploration, effettuata con l’ausilio di rappresentazioni visuali, al data mining.
L’obiettivo centrale è quindi di fornire un sistema che, partendo dai risultati prodotti dall’analisi dei dati, evidenzi i tratti salienti e le peculiarità, in termini di performance qualitative e quantitative, delle spedizioni che giornalmente vengono effettuate dall’azienda farmaceutica al fine di monitorarne ed eventualmente migliorarne le performance.
Scendendo più nel dettaglio di questo lavoro di tesi vengono presentate le seguenti fasi affrontate durante la realizzazione:
La fase di data exploration, in cui vengono presentati gli aspetti progettuali e realizzativi della piattaforma di analisi insieme ai principali aspetti informativi e conoscitivi emersi durante la fase di analisi dei dati.
Le analisi di clustering, in cui vengono presentate le tematiche legate: all’applicazione di modelli descrittivi al fine di esplorare ed isolare eventuali pattern caratteristici all’interno dei dati e all’integrazione degli aspetti conoscitivi emersi in questa fase con quelli emersi nella fase precedente.
Le analisi di classificazione, in cui vengono affrontate le tematiche relative alla realizzazione di un modello predittivo delle anomalie di consegna al fine di prevenirne il manifestarsi.
INDICE
1 INTRODUZIONE ... 3
1.1 Presentazione del problema ... 3
1.2 Contenuto della tesi ... 5
2 DESCRIZIONE DEI DATI ... 6
3 TECNOLOGIE E STRUMENTI UTILIZZATI ... 9
3.1 Metabase ... 9
3.1.1 Perché Natural Language Query ... 11
3.2 Dataiku ... 14
3.3 Knime Analytics Platform... 15
3.4 Weka ... 16
4 METODOLOGIA ADOTTATA ... 17
5 DATA EXPLORATION ... 19
5.1 Introduzione alla Data Exploration ... 19
5.1.1 Differenze con il sistema di reportistica esistente ... 20
5.2 Progettazione e realizzazione della dashboard di global view ... 23
5.3 Fenomeni e caratteristiche emerse con la dashboard di global view ... 28
5.4 Progettazione e realizzazione della dashboard di analisi delle anomalie ... 31
5.5 Fenomeni e caratteristiche emerse con la dashboard di analisi delle anomalie ... 33
5.6 Progettazione e realizzazione della dashboard di confronto tra fornitori ... 43
6 CLUSTERING ... 48
6.1 Introduzione al Clustering ... 48
6.2 Clustering delle anomalie ... 48
6.3 Progettazione e realizzazione delle dashboard di rappresentazione dei cluster ... 58
6.4 Clustering delle spedizioni per gli anni 2016 e 2017 ... 62
6.5 Rappresentazione grafica del Clustering per il 2016 e per il 2017 ... 65
6.6 Integrazioni prodotte dal Clustering... 67
7 CLASSIFICAZIONE ... 75
7.1 Introduzione alla Classificazione ... 75
7.2 Classificazione delle spedizioni del 2017 ... 76
7.3 Risultati della Classificazione ... 93
8 RISULTATI E CONCLUSIONI ... 94
8.1 Misure adottabili ... 97
8.2 Possibili risvolti futuri ... 98
RINGRAZIAMENTI ... 99
APPENDICE ... 101
Appendice A1: Query SQL per question complesse... 101
Appendice A2: Query di creazione dei dataset ... 107
1 INTRODUZIONE
1.1 Presentazione del problema
Nell’odierno contesto di arena competitiva con il quale quotidianamente le aziende si trovano a doversi confrontare, la capacità di reagire rapidamente ai cambiamenti diventa un’arma fondamentale. Capacità di reazione che dal canto suo richiede: processi di decision making più efficaci e più snelli e la capacità di assumere decisioni informate. È proprio in questi due fattori e nella costante ricerca di un vantaggio competitivo che risiede la motivazione per cui le aziende sono alla continua ricerca di strategie e soluzioni per monitorare, analizzare e migliorare le performance della propria supply chain.
Un’analisi critica delle performance qualitative della supply chain non può non prescindere da un intensivo sfruttamento dei dati che essa stessa genera, per ottenere informazioni e conoscenze in essi annidati. Sono queste quindi le ragioni che spingono sempre di più gli addetti ai lavori verso un utilizzo di metodi per comprendere, analizzare ed imparare dai dati, poiché in essi spesso si nascondono le chiavi per cogliere determinate opportunità. È in questa spasmodica ricerca di informazioni e conoscenza che il presente lavoro di tesi pone le basi della sua esistenza, a cui va tuttavia aggiunta la frequente difficoltà nel colmare quel divario che si crea tra il punto di vista gestionale e quello decisionale. Problematica che è da ricercare:
Nella difficoltà, dal punto di vista gestionale, ad individuare e riportare in alto possibili misure correttive da adottare per un miglioramento delle performance dei processi aziendali, basandosi esclusivamente sulle informazioni in possesso.
Nella difficoltà, dal punto di vista direzionale, ad individuare le suddette misure correttive basandosi esclusivamente sulla visione di massima sintesi di cui dispone.
Il presente lavoro di tesi presenta quindi i seguenti due obiettivi:
Evidenziare, monitorare e classificare, eventuali fenomeni ed effetti distorsivi; fornendo, ove possibile, suggerimenti a coloro i quali muovono le leve aziendali, in tema di misure correttive atte a migliorare i livelli di performance strettamente correlate alla spedizione dei farmaci.
L’implementazione di una piattaforma di analytics, condotta mediante uno strumento fortemente orientato alla semplicità di utilizzo e che si discosti dai tecnicismi tipici del settore, dall’ utilizzo della quale trarre informazioni utili al punto precedente.
La metodologia seguita prevede l’esistenza di tre fasi successive: una prima fase di analisi esplorativa dei dati, accompagnata dalla progettazione e realizzazione delle dashboard che compongono la piattaforma di analytics sviluppata. Seguita poi dall’applicazione di modelli descrittivi, in un’ottica di integrazione agli aspetti conoscitivi precedentemente emersi, e infine dall’applicazione di modelli predittivi, in un’ottica di prevenzione di determinati fenomeni ed effetti distorsivi emersi ed evidenziati nelle fasi precedenti.
1.2 Contenuto della tesi
Il presente lavoro di tesi è organizzato come segue.
Il Capitolo 2 è dedicato alla descrizione del contesto di riferimento e dei dati presenti nel data warehouse, fornendo inoltre una panoramica della struttura dello stesso.
Il Capitolo 3 è dedicato alla descrizione delle caratteristiche e degli approcci adottati dagli strumenti software impiegati per l’analisi esplorativa, la creazione della piattaforma di analytics e per l’applicazione degli algoritmi di clustering e di classificazione.
Il Capitolo 4 fornisce una panoramica della metodologia di fondo adottata.
Nel Capitolo 5 vengono presentati tutti i dettagli relativi agli elementi conoscitivi emersi dall’analisi esplorativa insieme agli aspetti progettuali ed implementativi che riguardano la piattaforma realizzata.
Nel Capitolo 6 vengono presentati gli aspetti legati all’applicazione dell’analisi di clustering sulle anomalie di consegna e sulle spedizioni degli ultimi 3 anni e alla presentazione degli elementi conoscitivi emersi da tale analisi. Si fornisce infine una descrizione degli aspetti integrativi che tali elementi costituiscono rispetto a quelli emersi in precedenza.
Nel Capitolo 7 vengono presentati gli aspetti legati all’applicazione di modelli predittivi in un’ottica di prevenzione del manifestarsi di determinate problematiche nelle spedizioni emerse dalle analisi precedenti.
Nel Capitolo 8 vengono presentati i risultati emersi dalle tre analisi condotte insieme ad una serie di misure correttive adottabili ai fini del miglioramento delle performance della supply chain e ai possibili risvolti futuri del progetto in questione.
2 DESCRIZIONE DEI DATI
Il contesto di riferimento dei dati presenti nel DWH è rappresentato dalla spedizione di prodotti, nel caso particolare prodotti farmaceutici, da intendersi in un contesto di pianificazione e controllo. Il trasporto, in particolare, avviene da un punto iniziale ad un punto finale mediante spedizioni su gomma che possono definirsi multi-tratta, ossia formate da più tappe intermedie.
Il punto iniziale e quello finale della spedizione sono rappresentati dagli enti e dai clienti, in particolare gli enti identificano i magazzini o gli impianti farmaceutici e i clienti identificano le farmacie o i punti di raccolta da dove le farmacie stesse si riforniscono. Non necessariamente una spedizione avviene da un ente ad un cliente, può infatti accadere che il punto fisico di carico e di scarico differisca dall’ente o dal cliente e sia semplicemente un punto fisico in una zona limitrofa. Nel caso di spedizioni composte da più tratte una singola tratta si intende come un segmento avente per estremo due enti, si precisa inoltre che le uniche informazioni disponibili all’interno di una tratta sono quelle ottenute dal punto iniziale e dal punto finale della tratta stessa. In altre parole, non si ha informazione alcuna su una spedizione che si trova in un punto intermedio di una tratta.
Il servizio di trasporto viene effettuato da un fornitore che oltre a mettere a disposizione il servizio fisico di trasporto del prodotto mediante un mezzo può mettere a disposizione altre tipologie di servizi (magazzinaggio, noleggi, ecc.).
Ogni spedizione, sia essa una tratta o una spedizione da un ente a un cliente, è caratterizzata da uno stato e una causale, quest’ultima in particolare rappresenta una descrizione più dettagliata di uno stato, ed è accompagnata da una bolla. La bolla contiene tutte le informazioni relative al mittente, al ricevente e al proprietario del prodotto in oggetto oltre alla data di spedizione e di prevista consegna e al numero di colli.
Lo stato associato ad una bolla rappresenta quindi la fotografia finale di una particolare spedizione.
Il trasporto fisico del prodotto tuttavia rappresenta solo l’ultimo passaggio di un processo più articolato di pianificazione, denominato tracking, che si compone della fase di pianificazione del trasporto, di contrattazione con il fornitore e di trasporto del prodotto. Il tracking tiene quindi traccia di tutti gli step successivi, in ordine cronologico, eseguiti da una spedizione durante il suo ciclo di vita.
Tre, infine, sono i concetti fondamentali che fungono da metrica di riferimento per quanto riguarda una spedizione ossia:
Il concetto di Perfect Order. Il concetto di On Time. Il concetto di Anomalia.
Con l’espressione perfect order si identificano tutte quelle spedizioni giunte a destinazione senza riscontrare problemi di alcun genere.
Con l’espressione on time si identificano tutte quelle spedizioni giunte a destinazione nella data prevista di consegna stipulata in fase di pianificazione e riportata sulla bolla.
La differenza tra i due concetti sta quindi nel fatto che mentre il secondo si riferisce esclusivamente ad aspetti temporali, fornendo cioè un indicatore della puntualità di consegna, il primo comprende sia aspetti temporali che aspetti legati all’integrità di quanto trasportato.
Con l’espressione anomalia si identificano invece tutte quelle spedizioni che durante il loro ciclo di vita hanno manifestato un problema, sia esso legato ad aspetti temporali (ritardi o anticipi di consegna) sia esso legato ad aspetti di mancata integrità di quanto trasportato (colli danneggiati, colli smarriti, ecc.).
Ovviamente il concetto di anomalia esclude, per sua natura, il concetto di perfect order che invece a sua volta include il concetto di on time. In altre parole, è impossibile avere spedizioni che siano allo stesso tempo dei perfect order e delle anomalie, mentre è possibile avere, ad esempio, delle spedizioni che siano on time e anomalia.
3 TECNOLOGIE E STRUMENTI UTILIZZATI
3.1 Metabase
Metabase è uno strumento open source di data visualization orientato al Natural Language Query, da intendersi però in senso lato. Fa infatti della navigabilità del dato e della sua conseguente intuitività e semplicità d’utilizzo il suo principale cavallo di battaglia.
Questa sua caratteristica di navigare il dato consente, nella maggior parte dei casi, il filtraggio e il raggruppamento degli stessi in maniera semplice, veloce e intuitiva. Ciò permette all’utente di trovare esattamente quello che sta cercando attraverso la semplice interazione con l’interfaccia e senza l’utilizzo di codice SQL. Proprio questa sua peculiarità lo rende particolarmente appetibile a quel segmento di utenti, rilevante e in crescita, lontano dai tecnicismi del settore ma inglobato in quella platea di utilizzatori dei sistemi di BI.
Questo sforzo nel semplificare le operazioni sui dati introduce inevitabilmente dei vincoli alle operazioni sugli stessi, per il superamento dei quali è presente un’elegante interfaccia SQL che consente quindi lo svolgimento di operazioni anche estremamente complesse. A questa navigabilità del dato Metabase affianca la capacità di presentare i risultati ottenuti sotto forma di grafici, semplicemente e velocemente realizzabili, che meglio presentino il significato del risultato ottenuto. È così possibile realizzare dashboard visuali tramite le quali organizzare e visualizzare in modo personalizzato i dati.
Oltre a queste caratteristiche Metabase mette a disposizione dei suoi utenti tutta una serie di funzionalità di natura amministrativa come:
La profilazione degli utenti che consente di creare diversi gruppi di utenti ai quali attribuire i permessi desiderati così da avere differenti livelli di accesso ai dati. Un sistema di notifica via email che consente di informare gli altri membri del
gruppo quando ad esempio vengono aggiornati o modificati i dati.
Un sistema di alert che consente di inviare una notifica via email quando, ad esempio, il risultato di una determinata operazione raggiunge un livello definito di allarme.
Un sistema di pulses che consente di inviare automaticamente dei report a cadenza periodica fissa.
In questo modo il risultato è uno strumento di front-end completo, semplice e intuitivo appetibile sia da utenti lontani dai tecnicismi del settore BI che da utenti con uno spiccato background tecnico-informatico.
3.1.1 Perché Natural Language Query
Uno dei nuovi fronti, e probabilmente tra i più caldi del momento, nello sviluppo di piattaforme di analisi, e quindi di strumenti di Business Intelligence, è certamente quello rappresentato dal Natural Language Query. A confermare l’importanza che il tema sta assumendo nell’ambito BI vanno gli sforzi che i diversi protagonisti del settore stanno facendo in questa direzione; Tableau con l’acquisizione di ClearGraph dell’Agosto 2017, Microsoft con il suo power BI Q&A, Oracle con il suo ATG search; solo per annoverarne qualcuno. Il Magic Quadrant for Analytics and Business Intelligence Platforms redatto da Gartner a Febbraio del 2018 fornisce una misura del peso specifico di chi si sta muovendo in questa direzione, Microsoft e Tableau vengono infatti riconosciuti come leader del settore.
Con l’espressione Natural Language Query ci si riferisce alla possibilità di interrogare una base di dati utilizzando solo espressioni naturali nella lingua dell’utente, priva cioè di sintassi o parole chiavi.
La crescita del settore BI e Analytics ha prodotto un ampliamento della platea di utilizzatori di questi sistemi inglobando in essa un segmento di utenti, rilevante e in crescita, lontano dai tecnicismi del settore. Questo fattore ha certamente acceso i riflettori su questo tema.
Tuttavia, di sistemi di Natural Language Query si parla già da tempi non sospetti. Sono infatti i primi anni 80 quando viene pubblicata una working paper series intitolata USL/DW NASA/RECON che contiene una serie di articoli nei quali sono presentati i risultati di attività condotte dal Computer Science Department of the University of Southwestern Louisiana. Di particolare interesse è il report numero DBMS .NASA/RECON-6 intitolato CONCEPTS AND IMPLEMENTATIONS OF NATURAL LANGUAGE QUERY SYSTEMS, datato 1 Giugno 1984 ad opera di I-Hsiung [Liu 84]. I-Hsiung Liu già in questo articolo fa riferimento a come le interfacce utente dei sistemi di informazione dell’epoca siano sviluppate per utenti esperti ignorando il gruppo di utenti potenzialmente più grande, quello che egli definisce casual users.
Balza immediatamente all’attenzione come ancora oggi, a distanza di oltre 30 anni, questa tematica sia ancora viva e attuale.
I-Hsiung Liu prosegue inoltre spiegando come la principale funzione di un sistema informativo è quella di consentire ai suoi utenti di recuperare e modificare qualsiasi sottoinsieme dei dati, oltre a fornire supporto ai propri utenti nella loro attività decisionale. In altre parole, il sistema informativo è sviluppato per servire i suoi utenti e soddisfare i loro bisogni immediati di informazione. Il successo o il fallimento di un sistema informativo è quindi, in definitiva, deciso dagli utenti stessi che il sistema dovrebbe servire. Il criterio predominante nella valutazione di un sistema, dal punto di vista dell'utente, è legato al fatto che esso gli consenta di comunicare liberamente con lui e soddisfi i suoi bisogni. Per tutte queste ragioni, il problema di interfaccia nell'interazione utente-sistema deve essere seriamente preso in considerazione durante lo sviluppo di un sistema informativo.
L’attualità di questo documento è data da come I-Hsiung Liu definiva gli utenti casuali,
"whose interactions with the system are irregular in time and motivated by (their) jobs or social roles". Questi utenti potrebbero non solo mancare in conoscenza di
programmazione, logica o relazioni, ma inoltre non sono disposti a imparare una lingua artificiale. Il solo linguaggio di query che sono disposti a utilizzare per interagire con il sistema informativo è la loro lingua madre.
È proprio questa loro caratteristica che consente di pensare ad essi come i moderni e attuali utenti normali di un qualsiasi sistema informativo di una qualsiasi organizzazione o azienda.
Avendo esaminato le caratteristiche di questi utenti, è concepibile come l'approccio tradizionale del linguaggio di query design, che presuppone che essi siano disposti a sviluppare competenze appropriate per operare su di un sistema informativo, non può far fronte alla natura degli utenti stessi.
Durante l'utilizzo di un linguaggio di query per recuperare informazioni, l'utente dovrebbe sapere quale “fatto” vuole ottenere dal sistema e come esprimere la sua intenzione nella sua lingua preferita invece di conoscere il modo in cui accedere ai dati del sistema. L'unico modo quindi per invogliare l'utente occasionale a interagire con un sistema di basi di dati è quello di consentirgli l'uso gratuito della sua lingua madre.
Tornando ai giorni nostri e scendendo più nel dettaglio del tema, si possono sostanzialmente riconoscere due differenti rami dello stesso tema: un primo ramo che interpreta il concetto in senso stretto e che fa dell’NLP (Natural Language Processing) il suo punto cruciale e un secondo ramo che interpreta il concetto in senso più ampio facendo dell’interazione con l’interfaccia utente il suo punto cruciale. Il primo ramo verte cioè sulla creazione di sistemi in grado di tradurre un’espressione in linguaggio naturale (tipicamente in lingua inglese) in una vera e propria query in linguaggio SQL sfruttando le tecnologie tipiche della linguistica computazionale. Il secondo ramo invece verte sullo sviluppo di interfacce utente che consentano di effettuare interrogazioni al database sfruttando l’iterazione dello stesso con l’interfaccia, senza cioè dover digitare comandi SQL.
Entrambi i rami evidenziano un obiettivo comune, rendere maggiormente accessibili i dati, e le informazioni in essi contenute, a quel segmento di utenza che non possiede competenze tecniche nell’ambito dei database.
3.2 Dataiku
Dataiku DSS è una piattaforma di data science che consente a chi opera sui dati (ossia figure professionali come data scientists, business analysts e developers) di creare prototipi, costruire e distribuire servizi altamente specifici in grado di trasformare i dati grezzi in previsioni di business.
Utilizza un’interfaccia visuale, basata sul web, con la quale è possibile caricare e preparare i dati, analizzarli costruendo delle visualizzazioni, effettuare il training di algoritmi di machine learning, realizzando modelli ad hoc e infine automatizzare l’esecuzione dell’intero flusso.
Consente la connessione alle più comuni fonti di dati come file CSV, database SQL, MongoDB, HP Vertica, Amazon Redshift, Hadoop e Spark con la possibilità di esplorare i dati mediante l’utilizzo di un’interfaccia grafica intuitiva oppure mediante tool e strumenti come SQL, Python ed R.
Il risultato è quindi una piattaforma di data science completa e integrata che si distingue dai sistemi più comuni, come Knime e Weka, per una più spiccata propensione alla data visualization e alla ciclicità, tipica dell’approccio di data-mining, dove spesso è necessario ritornare alla fase di data preparation, rispetto a quanto fanno i suddetti sistemi.
Questa sua spiccata propensione alla data visualization semplifica notevolmente l’attività di interpretazione dei risultati ottenuti da parte del data scientist.
A certificare questa differenziazione rispetto agli attori principali va la classificazione ricevuta nel Gartner Magic Quadrants del 2018 dove gli viene riconosciuta una posizione di Visionaries nel settore delle data science platforms. Nel Gartner Magic Quadrants vengono infatti denominati Visioraries quei fornitori che offrono sul mercato prodotti innovativi, in grado di essere utilizzati su vasta scala dall’utente finale ma che non hanno ancora raggiunto una cospicua quota di mercato.
3.3 KNIME Analytics Platform
KNIME è una piattaforma open source per la creazione di applicazioni e servizi di data science, intuitiva, aperta e in continua estensione.
La sua logica operativa di funzionamento è basata sulla costruzione di flussi, come accade ormai per la stragrande maggioranza degli strumenti appartenenti a questa categoria, con un'interfaccia grafica in stile drag and drop che non necessità di codifica. All’interno dei flussi così creati possono coesistere strumenti appartenenti a domini diversi, inclusi scripting in R & Python, machine learning o connettori ad Apache Spark.
Consente l’importazione da svariate categorie di fonti di dati, come formati di testo (CSV, PDF, XLS, JSON, XML), tipi di dato non strutturato (immagini, documenti, reti) o serie temporali (time series) e la connessione alle tecnologie più comuni e avanzate di data warehounsing (Oracle, Microsoft SQL, Apache Hive).
Scendendo più nel dettaglio delle sue caratteristiche fondamentali vi è la capacità di ricavare statistiche, come la media, i quantili e la deviazione standard e integrare l'analisi di correlazione.
Per quanto riguarda la data preparation è possibile normalizzare i dati, effettuare la conversione del tipo di dati e la gestione dei valori mancanti oltre alla rilevazione di outlier con algoritmi di rilevamento delle anomalie.
E per finire è possibile costruire modelli di apprendimento automatico per la classificazione, la regressione e il clustering, utilizzando algoritmi avanzati tra cui deep learning, tree-based methods e logistic regression.
Si tratta quindi di uno strumento estremamente potente, completo e versatile tanto da essere annoverato tra i leaders di settore nel Gartner Magic Quadrants del 2018.
3.4 Weka
Wekaè un data mining software, interamente sviluppato in Java, che fornisce una raccolta di algoritmi di apprendimento automatico applicabili direttamente ad un set di dati o richiamabili all’interno di un codice Java. Contiene strumenti per la preparazione dei dati, la classificazione, la regressione, il clustering e il mining delle regole di associazione. Si tratta di un software open source rilasciato sotto GNU (General Public License) sviluppato presso l’Università di Waikato in Nuova Zelanda.
4 METODOLOGIA ADOTTATA
Il presente lavoro di tesi vede il suo focus incentrarsi sull’analisi dei dati precedentemente descritti e sulla progettazione e sviluppo di una piattaforma di analisi. L’analisi, in particolare, viene condotta utilizzando un’ampia gamma di tecniche che spaziano in ambiti diversi. Si va da tecniche e metodologie tipiche della data exploration, condotta mediante rappresentazioni visuali, a tecniche e metodologie tipiche del data mining.
Di seguito sono descritte nel dettaglio tutte le attività di analisi, e i relativi risultati emersi, condotte sui dati e raggruppate per le seguenti tre macro-aree di attività:
1) Data Exploration. 2) Clustering. 3) Classificazione.
Con le prime due macro-attività legate tra loro in una struttura ciclica, la metodologia è quindi così rappresentabile.
Struttura ciclica giustificata dal fatto che i risultati emersi nella fase di data exploration lasciavano intendere come fosse necessario fornire nuovi elementi conoscitivi, da aggiungere a quelli già emersi, e ottenibili mediante l’applicazione di modelli descrittivi. I risultati ottenuti dall’applicazione di questi modelli descrittivi hanno poi suggerito come fosse possibile produrre un’integrazione alla fase di data exploration.
Scendendo più nel dettaglio di queste macro-attività la prima, quella di data exploration, ha come obiettivo quello di ottenere una conoscenza più approfondita su quelle che sono le caratteristiche intrinseche nel dato e che in esso si celano. Ricerca di conoscenza che si accompagna alla progettazione e allo sviluppo di un sistema di reportistica che evidenzi quanto emerso.
La seconda, quella di clustering, ha come obiettivo quello di esplorare ed isolare eventuali pattern distintivi presenti sui dati.
Infine, la terza macro-attività, quella di classificazione, ha come obiettivo quello di costruire un modello predittivo capace di predire, entro determinati margini di errore, il verificarsi di un’anomalia nella spedizione prima che essa si verifichi realmente.
5 DATA EXPLORATION
5.1 Introduzione alla Data Exploration
Questa primissima fase di data exploration ha avuto come focus predominante lo studio dei fenomeni e delle caratteristiche presenti nel dataset, condotto mediante l’utilizzo di uno strumento avente un approccio orientato al Natural Language Query, in particolare Metabase. L’obiettivo di questa fase è quello di avere, al termine di essa, una visione chiara, completa e dettagliata di tutte le peculiarità che nel dataset si nascondono.
Accanto a questo obiettivo, che si può definire veicolante, si è affiancata l’idea di realizzare una piattaforma di analisi, sempre mediante l’utilizzo di Metabase, che consenta all’utente di trarre tutte le informazioni utili durante il suo processo decisionale. La realizzazione della piattaforma, in particolare, non è dettata da alcun tipo di requisito utente/cliente ma è il frutto di un’analisi critica costante circa i punti di vista da adottare, le informazioni da estrarre e gli elementi conoscitivi da investigare.
I due obiettivi così descritti sono quindi stati perseguiti di pari passo poiché funzionali, in maniera bi-direzionale, uno rispetto all’altro.
5.1.1 Differenze con il sistema di reportistica esistente
Per quanto concerne la piattaforma di analisi in oggetto, essa differisce dal sistema esistente innanzi tutto per la platea di attori a cui si rivolge.
Se si volessero rappresentare i profili degli utenti interessati facendo un parallelo con la piramide di [Anthony 65] potremmo identificare sostanzialmente i seguenti tre segmenti.
Figura 5.1: Piramide di Anthony e platea di utenti
Il sistema esistente, nella fattispecie, si rivolge principalmente al segmento rappresentato dai controller di gestione, fornendo loro degli strumenti di OLAP, e al segmento dei decision maker, fornendo loro delle dashboard e delle KPI. La piattaforma di analisi ideata e sviluppata nel presente lavoro di tesi si rivolge invece più ad un profilo simile a quello del “data scientist” che in questo contesto potremmo collocare tra i controller e i decision maker.
Figura 5.2: Collocazione del data scientist e strumenti utilizzati
Scendendo più nel dettaglio del profilo di questi utenti, i controller di gestione sono i responsabili per quel che riguarda l’impostazione e il raggiungimento degli obiettivi operativi prestabiliti, e quindi di breve periodo, i decision maker sono invece coloro che muovono le leve aziendali in un’ottica strategica, cioè di lungo periodo. I primi si limitano quindi ad osservare, correggere e riportare ai decision maker eventuali scostamenti tra gli obiettivi operativi prefissati e i risultati operativi raggiunti. I secondi invece hanno il compito di assumere le decisioni sulla base di un punto di vista di massima sintesi, spesso rappresentato dal valore di determinate KPI. Il risultato è il frequente crearsi di un solco tra il punto di vista dei controller e quello dei decision maker dato principalmente da due fattori. Un primo fattore rappresentato dalla difficoltà dei primi di individuare e riportare in alto possibili misure correttive da adottare ai fini di un miglioramento delle performance aziendali, basandosi esclusivamente sulle informazioni in loro possesso. Un secondo fattore dato dalle difficoltà dei decision maker nell’individuare le suddette misure correttive basandosi esclusivamente sulle informazioni fornitegli dagli analisti e dalla visione di massima sintesi di cui dispongono. È proprio all’interno di questo solco che si inserisce la figura del data scientist, in quanto profilo capace di tradurre in conoscenza, utilizzando strumenti di reporting, strumenti di OLAP, strumenti di data mining e machine learning, le informazioni provenienti dai livelli sottostanti della piramide e riportarli al livello superiore. Questa traduzione di informazioni in conoscenza già di per sé fornisce un suggerimento ai livelli più alti della piramide per quanto concerne le misure strategiche adottabili.
Ripercorrendo quindi all’indietro il parallelo effettuato tra la piramide di Anthony, i profili degli utenti e i due sistemi di analisi messi a confronto, la piattaforma di analisi esistente da un lato monitora lo svolgimento delle attività operative di spedizione, informando il controller di gestione tempestivamente circa il verificarsi di eventuali fenomeni distorsivi e riportando lui i parametri chiave relativi alle performance del processo su cui si basa. Dall’altro fornisce ai decision maker uno strumento per monitorare il livello delle perfomance relative all’intera supply chain.
Il sistema oggetto di questo lavoro di tesi invece si colloca proprio in quel solco che si viene a creare tra le informazioni prodotte e le misure adottabili. Con l’obiettivo di identificare, monitorare e classificare, eventuali fenomeni ed effetti distorsivi; fornendo, ove possibile, suggerimenti a coloro i quali muovono le leve aziendali, in tema di misure correttive atte a migliorare i livelli di performance strettamente correlate alla spedizione dei farmaci.
Altra differenza sta quindi nell’approccio dei due sistemi: mentre il sistema esistente presenta un approccio tipico della business intelligence, con una costante e tempestiva produzione di informazioni, il sistema progettato e realizzato in questo lavoro di tesi presenta un approccio orientato all’analytics con una produzione di conoscenza a partire dai dati storici.
5.2 Progettazione e realizzazione della dashboard di global view
Il modus operandi iniziale utilizzato per questa fase è riconducibile ad un approccio di natura top-down, partendo cioè da una visione d’insieme e di più alto livello proseguendo poi via via più nel dettaglio. Tale approccio è dettato principalmente dalla volontà di fornire nella piattaforma di analisi in fase di sviluppo una visione d’insieme dei dati, assumendo quindi un punto di vista di massima sintesi della situazione.
Il primissimo obiettivo operativo ha quindi come oggetto lo sviluppo di una dashboard di massima sintesi che fornisca una visione d’insieme dei dati, utilizzando Metabase.
In fase di progettazione della stessa si è optato per la visualizzazione dei seguenti elementi: Il numero totale delle spedizioni.
Il numero di spedizioni dall’Italia per singola regione.
Il numero di spedizioni con destinazione l’Europa per singola nazione di destinazione.
La percentuale complessiva di consegnato, anomalie, on time e perfect order per singolo fornitore.
Una ripartizione delle anomalie.
L’andamento del totale delle spedizioni, del totale delle anomalie, del totale di on time e del totale dei perfect order su base mensile.
Elementi che, come si intuisce, fungono da vere e proprie business question. Di seguito si riporta quindi in forma tabellare l’elenco delle business question fin qui individuate con le relative dimensioni, misure e metriche.
N Business questions Dimensions Measures Metrics
#1
Totale delle spedizioni. Totale
#2 Totale di spedizioni dall’Italia per
singola regione. dim_geo Totale
#3 Totale delle spedizioni in Europa per
nazione di destinazione. dim_geo Totale
#4 Percentuale complessiva di
consegnato, anomalie, on time e perfect order per fornitore.
dim_fornitore,
dim_stato Percentuale
#5 Ripartizione delle anomalie. dim_stato Percentuale
#6
Andamento del totale delle spedizioni, del totale delle anomalie,
del totale di on time e del totale dei perfect order su base mensile.
dim_fornitore,
dim_tempo Totale
Sono stati inoltre previsti tre differenti tipologie di filtro che consentono di visualizzare i risultati delle business questions per un solo fornitore, in un solo anno, oppure in un determinato range temporale. La predisposizione di questi filtri consente quindi una prima discesa verso il basso nell’ipotetica scala di dettaglio immaginata.
La dashboard fin qui prodotta evidenzia un’importante lacuna dal punto di vista informativo; l’incapacità di evidenziare e di mostrare in maniera chiara e immediata il rapporto tra il numero di anomalie e il totale delle spedizioni. Lacuna informativa alla quale si è prontamente ovviato aggiungendo alla dashboard un nuovo elemento: l’andamento percentuale di anomalie, di on time, di perfect order e di consegnati su base mensile, in appendice si riporta la query SQL utilizzata per la creazione della nuova question.
Il posizionamento di questo nuovo elemento non è da ritenersi casuale. Il fine è infatti quello di mantenere una corrispondenza mensile sull’asse verticale; così da semplificare la consultazione da parte dell’utente delle due facce della stessa medaglia, una visione prima in valore assoluto e poi in termini percentuali.
Altra lacuna informativa, seppur di minore entità e rilevanza, presente nella dashboard fin qui prodotta è data dalla mancanza di informazione relativa alla tipologia di spedizione adottata. Anche in questo caso si è ovviato aggiungendo alla dashboard un nuovo elemento: la ripartizione della tipologia di spedizione.
5.3 Fenomeni e caratteristiche emerse con la dashboard di global view
L’utilizzo della dashboard di global view così realizzata evidenzia, già in questa primissima fase, alcuni fenomeni e peculiarità che nel dataset si nascondono; di seguito si provvede a presentare quanto emerso.
Da un’attenta osservazione dell’andamento della curva che rappresenta il numero di anomalie e della curva che rappresenta il numero delle spedizioni, nel grafico posto in basso della dashboard, emerge un sensibile incremento del rapporto tra il numero di anomalie e il totale delle spedizioni nel mese di Agosto.
Tendenza meglio visibile nell’immagine seguente.
L’utilizzo della dashboard fa emergere un ulteriore aspetto, la presenza cioè di un fornitore, Morelli Group, che quasi monopolizza lo scenario, effettuando circa il 76,6% di spedizioni (1.147.491 su 1.498.443). Questa dipendenza dal fornitore fa si che l’aspetto precedentemente osservato, di crescita percentuale delle anomalie nel mese di Agosto, assuma non più dei risvolti “fisiologici” (fisiologico perché questo trend crescente osservato non era emerso in un particolare contesto fatto di restrizioni a particolari fornitori o a lassi temporali) bensì “patologici”.
L’immagine seguente mostra un confronto tra l’andamento percentuale delle anomalie su base mensile nel caso generale e per Morelli Group.
Appare evidente come lo scenario addirittura peggiori se si osserva l’andamento del solo fornitore, con un picco di anomalie nel mese di Agosto che passa dal 4,31% del caso generale al 4,55% di Morelli Group.
Questa dipendenza dal fornitore, in definitiva, fa si che quest’ultimo confluisca il suo particolare pattern di andamento delle percentuali di anomalie al caso generale.
I due fattori emersi hanno quindi reso necessaria una più approfondita e attenta analisi in tema di anomalie.
5.4 Progettazione e realizzazione della dashboard di analisi delle
anomalie
Anche in questo caso questa più attenta analisi è stata accompagnata dalla progettazione e dallo sviluppo di una dashboard navigabile a disposizione dell’utente, dalla quale egli potrà trarre informazioni. Analisi che, in particolare, ha riguardato due differenti punti di vista: un primo punto di vista relativo a capire quali sono le condizioni che favoriscono l’insorgere delle anomalie e un secondo punto di vista rivolto a ricercarne le cause.
In accordo quindi con questi obiettivi di analisi, in fase di progettazione della dashboard si è optato per la visualizzazione dei seguenti elementi:
Il totale delle spedizioni e le percentuali di anomalia per ente di carico.
Andamento delle percentuali di anomalia e del totale delle spedizioni su base mensile.
Il numero di anomalie per numero di colli.
La presenza del secondo elemento anche in questa dashboard è da ricercarsi nella volontà di fornire in un'unica schermata tutto quanto riguardasse le anomalie al fine di evitare salti tra le dashboard che potrebbero risultare poco funzionali.
Di seguito si fornisce un dettaglio, in forma tabellare, delle business question fin qui individuate.
N Business questions Dimensions Measures Metrics
#1 Totale delle spedizioni per ente di
carico. dim_ente Totale
#2 Percentuali di anomalia per ente di
carico. dim_ente Percentuale
#3 Andamento delle percentuali di
anomalia su base mensile. dim_tempo Percentuale
#4 Andamento del totale delle
spedizioni su base mensile. dim_tempo Percentuale
#5 Numero di anomalie per numero di
colli. m_num_colli Totale
Anche per questa dashboard sono stati previsti tre differenti tipologie di filtro che consentono di visualizzare i risultati delle business questions per un solo anno, in un determinato range temporale e per un particolare ente di carico.
L’immagine seguente mostra la dashboard di analisi delle anomalie fin qui sviluppata.
5.5 Fenomeni e caratteristiche emerse con la dashboard di analisi delle
anomalie
L’utilizzo della dashboard così realizzata fa emergere una serie considerevole di aspetti degni di nota.
Come precedentemente accennato, l’analisi sulle anomalie è stata condotta seguendo due differenti fronti d’indagine: un primo fronte relativo ad aspetti condizionali e un secondo fronte relativo ad aspetti causali. In altre parole, nel primo fronte di indagini ci si è concentrati sul capire quali sono le condizioni, in presenza delle quali, si ha una maggiore presenza di anomalie, mentre nel secondo fronte di indagini ci si è concentrati sul capire dove possa essere ricercata la causa delle anomalie.
Dal primo fronte di indagini emerge come vi sia un andamento molto singolare e inatteso del numero di anomalie per numero di colli, evidenziando un picco di anomalie nelle spedizioni composte da un solo collo e un crollo dello stesso al crescere del numero di colli spediti. Si può inoltre osservare come il numero di anomalie nelle spedizioni composte da un solo collo, sia 4 volte e mezzo superiore al numero di anomalie nelle spedizioni formate da 2 colli (17.419 contro 3.891).
Figura 5.8: Numero di anomalie per numero di colli
Per quanto riguarda invece il secondo fronte di indagini, si parte dal presupposto che le anomalie o vengono generate a monte, e cioè da attribuire all’ente di carico, oppure sono da attribuire alle cattive performance del fornitore del servizio di trasporto. Nel primo caso, denominato con X il fornitore del servizio di trasporto selezionato, non ci si aspetta una sensibile variazione percentuale delle anomalie per ente di carico tra il caso generale e il caso in cui il fornitore non è X. Nel secondo caso invece questa variazione esiste ed è apprezzabile.
Le immagini seguenti mostrano il confronto tra le percentuali di anomalie per ente di carico nel caso generale e quando il fornitore del servizio di trasporto non è Morelli Group.
Figura 5.9: Percentuali di anomalia per ente di carico nel caso generale e per Morelli Group
Dal raffronto emerge come tutti gli enti di carico che presentano percentuali di anomalie superiori alla soglia imposta del 2%, o vicine a tale soglia, vedono la propria percentuale di anomalia scendere sensibilmente. Emblematica in tal senso è la situazione di Plant Quarto Nathanumbro che vede la sua percentuale di anomalie scendere di oltre 6 punti percentuali (dall’8,02% al 1,72%) quando il fornitore del servizio di trasporto non è Morelli Group. Si può quindi concludere affermando che quest’ultimo è certamente responsabile di una parte considerevole delle anomalie registrate, e che la sua posizione di learder incontrastato in termini di volumi non è accompagnata da un’altrettanta posizione di leadership in termini di eccellenza qualitativa del servizio messo a disposizione.
La possibilità offerta da Metabase di navigare tra i dati consente di portare alla luce un ulteriore aspetto nascosto, legato alla criticità delle singole tratte ente di carico-cliente receiver.
In particolare, navigando tra i dati relativi al numero di anomalie per numero di colli, raggruppando per ente di carico e cliente receiver e contando il numero di righe, emerge come le tratte Plant Nayadedel Friuli-Milano365 e Plant Elsaa mare-Noventa Vicentina10 siano quella che presentano una maggiore criticità. Si contano infatti un totale di 100 anomalie su 606 spedizioni, cioè circa il 16,5%, per la prima tratta e 51 su 484, cioè circa il 10,5% per la seconda; quando il numero di colli è uguale a 1.
L’immagine seguente mostra il numero di anomalie per singola tratta quando il numero di colli è uguale a 1 e quando il numero di colli è uguale a 2.
Figura 5.10: Numero di anomalie per tratta per le spedizioni da 1 e 2 colli
La situazione peggiora ulteriormente se si va ad eliminare il filtro sul numero di colli, emerge infatti una terza tratta anch’essa particolarmente problematica, la tratta Plant Mircoligure-Livigno2 con ben 92 anomalie su un totale di 182 spedizioni totali, cioè oltre il 50%.
Figura 5.11: Numero di anomalie per tratta
Più in generale emerge come sia proprio la zona di Livigno, con i suoi due clienti receiver Livogno1 e Livigno2 a far registrare percentuali di anomalia record con un totale di 135 anomalie su 263 spedizioni, ovvero oltre il 51%.
Esauriti così i due fronti di indagine sopra descritti, l’analisi delle anomalie ha visto il focus spostarsi sulla ricerca delle cause più frequenti di anomalie e più in particolare sulla ricorrenza, in termini percentuali, delle problematiche di anomalia.
L’approccio seguito per rispondere a questa nuova business question risulta essere certamente in controtendenza con l’approccio esplorativo top-down fin qui seguito, in questo particolare caso si è infatti preferito seguire un approccio diametralmente opposto al precedente, procedendo cioè in maniera bottom-up da uno scenario più dettagliato risalendo via via verso uno scenario più generale. In particolare, si possono individuare 3 diversi livelli di dettaglio, partendo dal livello 1, il più dettagliato, risalendo fino al livello 3, il meno dettagliato; in appendice si riporta la query SQL creata per seguite quest’approccio.
Figura 5.13: Rappresentazione dell’approccio adottato Livello 3: •Anomalia Livello 2: •Numero di colli e anomalia Livello 1: •Tratta, numero di colli e anomalia
Per quanto riguarda il primo livello di dettaglio si sono analizzate le top 5 tratte in termini di volumi di trasporto, per un totale del 10% circa del numero totale di spedizioni, senza tuttavia che siano emersi fattori rilevanti.
Risalendo al secondo livello di dettaglio emerge come oltre il 44% delle anomalie nelle spedizioni composte da un solo collo presentano nella causale di anomalia la dicitura “Altri
motivi di anticipo dovuti al corriere” e oltre il 10% presentano la dicitura “Chiuso per ferie/lavori/spazio”. L’immagine seguente fornisce maggiori dettagli.
Figura 5.14: Ricorrenza delle problematiche di anomalia per le spedizioni da un collo
L’analisi su questo livello è stata condotta allo stesso modo fino ad un numero di 10 colli per un totale di circa il 74% del numero totale di anomalie. In tutti e 10 i casi è emerso come la causale di anomalia “Chiuso per ferie/lavori/spazio” si presenta sempre tra le prime due o tre problematiche di anomalia.
Questa costatazione lascia intendere quindi la presenza di non poche problematiche legate alla comunicazione tra l’ente di carico e il cliente receiver. Supposizione supportata anche dal fatto che la dicitura “Merce rifiutata dal cliente senza esplicita motivazione”, presenta in tutti e 10 i casi valori percentuali significativi, quasi sempre intorno all’8%.
Risalendo ulteriormente nel livello di dettaglio il fenomeno appena descritto si riconferma, fornendo quindi una visione di massima sintesi dell’aspetto. L’immagine seguente fornisce maggiori dettagli al riguardo.
Figura 5.15: Ricorrenza delle problematiche di anomalia nel caso generale
Vista la rilevanza di quanto emerso si è preferito integrare la dashboard di analisi delle anomalie con la question di ricorrenza delle problematiche, in modo che fornisca anche una visione immediata di ripartizione.
5.6 Progettazione e realizzazione della dashboard di confronto tra
fornitori
Ultimo aspetto preso in considerazione durante questa prima fase di analisi riguarda le differenti performance qualitative dei fornitori. L’idea cardine da questo punto di vista è quella di avere un confronto immediato e visivo tra essi che consenta di identificare i migliori e i peggiori in termini di qualità del servizio.
L’idea si traduce quindi nella creazione di una dashboard di confronto nella quale, in fase di progettazione, si è optato per la visualizzazione dei seguenti elementi:
Il numero di spedizioni.
Le percentuali di perfect order. Le percentuali di on time. Le percentuali di anomalie.
La misurazione vera e propria delle performance qualitative di ogni singolo fornitore è stata poi affidata ad un KPI (Key Performance Indicator) appositamente ideato e così calcolato.
Normalized Supplier Anomaly Indicator (NSAI)= 2 −
Fermo restando che sia pari a 0 la percentuale di anomalia auspicata per ogni fornitore, in questo contesto viene riconosciuta una soglia di tolleranza pari al 2%. L’indicatore è quindi stato normalizzato tenendo conto di questa soglia con l’obiettivo di misurare lo scostamento, in termini negativi, da essa.
I valori vanno quindi da 2, che rappresenta il valore massimo e indica un’eccellente performance qualitativa, a – 98 che rappresenta il 100 % di anomalie registrate. Più in generale valori negativi stanno ad indicare l’incapacità del fornitore ad avere una
percentuale di anomalia definita accettabile (il 2% appunto), valori positivi indicano invece performance migliori rispetto al minimo desiderato.
Di seguito si fornisce un dettaglio delle business question individuate.
N Business questions Dimensions Measures Metrics
#1 Totale delle spedizioni per
fornitore. dim_fornitore Totale
#2 Percentuali di perfect order per
fornitore. dim_fornitore Percentuale
#3 Percentuali di on time per fornitore. dim_fornitore Percentuale #4 Percentuali di anomalie per
fornitore. dim_fornitore Percentuale
#5
Valore di KPI per fornitore NSAI
5.7 Dettagli progettuali e implementativi delle dashboard
Di seguito verranno forniti ulteriori dettagli sugli aspetti che riguardano la progettazione e l’implementazione delle tre dashboard appena descritte.
Il processo di progettazione delle dashboard, e più in generale dell’intera piattaforma analytics, include alcuni punti cardine fondamentali, attorno ai quali ruota l’intero processo, in particolare:
Ottenere una panoramica degli indicatori tipici e identificare velocemente gli aspetti che necessitano di attenzione.
Soffermarsi su determinate aree per ottenere una migliore comprensione di ciò che si sta osservando e decidere se intervenire.
Se sono richieste maggiori informazioni, la dashboard deve essere la base di partenza per ottenerle.
Nel rispetto di questi tre punti, ogni dashboard è stata progettata per fornire un unico punto di visione e contiene solo elementi inerenti al punto di visione considerato. In particolare, la dashboard di global view assume come punto di visione quello di massima sintesi e astrazione degli eventi e rappresenta quindi il trampolino di lancio verso le altre due dashboard che forniscono invece maggiori dettagli per quanto riguarda le anomalie e i fornitori del servizio di trasporto.
Altro aspetto trasversale alle tre dashboard è la codifica dei colori utilizzata, in blu vengono sempre rappresentate le spedizioni (quando ci si riferisce ad esse in termini generali), in verde i perfect order, in viola gli on time e in rosso le anomalie.
Anche l’aspetto posizionale degli elementi all’interno delle dashboard non è casuale, la dashboard di global view, ad esempio, presenta una scala di dettaglio crescente navigandola dall’alto verso il basso della schermata. Nella parte alta sono infatti presenti tutti gli elementi relativi al totale delle spedizioni e a come questo totale è distribuito nel territorio nazionale, per quel che riguarda il carico, ed europeo, per quanto riguarda lo scarico. Nella fascia centrale della schermata sono invece concentrati gli elementi inerenti
ai concetti di on time, perfect order e anomalia e infine in basso gli elementi di maggior dettaglio relativi agli andamenti mensili delle percentuali che riguardano gli stessi concetti. L’ultimo aspetto preso in considerazione per quanto riguarda il processo di progettazione è quello relativo alla tipologia di visualizzazione di ogni singola question. La rappresentazione grafica dei risultati infatti è stata accuratamente ricercata e attenzionata, sempre nell’ottica di non risultare mai forviante e di riuscire a trasmettere un messaggio informativo che sia il più chiaro e diretto possibile.
Per quanto riguarda invece gli aspetti di natura implementativa, ogni singolo elemento all’interno delle dashboard è direttamente connesso al DW mediante driver JDBC, in questo modo l’aggiornamento dei dati presenti in esso, da intendersi ad opera di un processo ETL, provoca una variazione nell’elemento considerato.
Scendendo più nel dettaglio di questi elementi, la maggioranza di essi viene realizzata mediante lo strumento custom di Metabase che consente di selezionare: la tabella di origine dei dati, gli attributi desiderati per il raggruppamento e le eventuali funzioni di aggregazione da appositi menu a tendina. Lo strumento tuttavia presenta delle limitazioni, per queste ragioni infatti le question più complesse vengono generate mediate query in SQL. È il caso ad esempio delle question di ricorrenza e di ripartizione delle problematiche di anomalia, nella dashboard di analisi delle anomalie, nelle quali si ricorre anche all’utilizzo di funzioni di SQL analitico, oppure della question di calcolo della KPI di misurazione delle performance qualitative di ogni singolo fornitore.
Il risultato è quindi una piattaforma non solo interamente riutilizzabile all’interno del contesto di una supply chain e più in particolare nell’ambito della distribuzione, ma adattabile anche in tutti quei contesti nei quali: lo studio degli andamenti nel tempo, lo studio di particolari categorizzazioni, e lo studio di particolari picchi di eventi e quindi di particolari outlier, assume un ruolo centrale nell’attività di analisi delle performance.
6 CLUSTERING
6.1 Introduzione al Clustering
Vista la rilevanza di quanto emerso, soprattutto per quel che riguarda la ricorrenza e la ripartizione delle problematiche di anomalia, nella fase successiva di analisi l’attenzione è stata spostata prevalentemente nell’ambito del data mining con lo scopo di fornire nuovi elementi conoscitivi da aggiungere a quelli già emersi nella fase precedente. Più in particolare l’approccio seguito prevede l’applicazione di modelli descrittivi, quali gli algoritmi di clustering, condotta mediante dataiku data science platform al fine di esplorare ed isolare eventuali pattern caratteristici all’interno dei dati.
6.2 Clustering delle anomalie
La primissima attività di clustering ha avuto come oggetto le bolle caratterizzate da anomalia, in appendice si riporta la query SQL utilizzata per la creazione del dataset iniziale. Il dataset così prodotto, è stato sottoposto a due fasi successive di data preparation mediante le quali sono prima stati creati i Geo point, in previsione di una rappresentazione grafica dei clusters su una mappa, e poi rimosse le colonne ritenute non necessarie o potenziali fonti di disturbo ai fini del clustering.
Più in particolare, per quanto riguarda questa seconda fase di data preparation, sono stati eliminati gli attributi relativi:
Ai campi chiave.
Alle date esatte di carico, scarico e previsto scarico. Ai geo point creati nella fase precedente.
Alla latitudine e alla longitudine esatta di carico e scarico, a partire dalle quali sono stati creati i geo point, (da intendersi sia come punto esatto che in termini di provincia, regione, nazione o continente di carico e scarico).
Le informazioni presenti in questi attributi sono quindi state escluse per quel che riguarda la computazione dell’algoritmo di clustering ma sono poi state reintrodotte quando, al termine della computazione, ogni singola riga è stata associata ad un cluster. Operazione resa lecita e possibile dal fatto che non sono state intraprese operazioni che comportassero l’eliminazione di record dal dataset iniziale.
L’immagine seguente mostra il flusso utilizzato.
Come è noto l’algoritmo K-means presenta il problema della scelta del numero K di cluster, problema che nasce dal fatto che tale scelta va fatta prima dell’esecuzione dell’algoritmo stesso. Il primo passo da compiere consiste quindi nel determinare il valore ottimale di K.
Più in particolare due misure sono state adottate per contrastare il problema della scelta del numero di centroidi, una prima misura, rappresentata dall’Elbow Method, adottata a priori e una seconda misura, rappresentata dall’Average Silhouette Method, adottata in un’ottica di certificazione della scelta effettuata.
Più in dettaglio l’elbow method consiste nella determinazione del Error Sum of Squares
(SSE) calcolato come:
= ( − ̅)
Dove xi rappresenta l’i esima rilevazione e ̅ rappresenta il centroide a cui xi viene
assegnato dall’algoritmo.
L’idea dell’elbow method è quella di scegliere il numero di cluster in corrispondenza di un calo repentino dell’SSE, cosa che produrrà un “gomito” nel grafico, da qui appunto il nome di elbow method.
L’intero approccio è stato condotto su Knime, poiché su Dataiku non è stato possibile estrarre i centroidi dei cluster determinati dall’algoritmo, e ha previsto la valutazione della bontà di 11 valori diversi di K. L’immagine seguente mostra il workflow utilizzato per la determinazione dei valori di SSE.
Figura 6.2: Workflow per la determinazione dell’SSE
Il grafico seguente mostra infine l’andamento dell’SSE al variare di K.
Figura 6.3: Andamento dell’SSE al variare di K
Come si può osservare dalla tabella sulla sinistra in corrispondenza di K=5 si osserva un crollo del valore di SSE, si conclude quindi che 5 è il numero ottimale di cluster da
La bontà della scelta effettuata viene certificata dal secondo metodo adottato, l’average silhouette method. L’idea di quest’ultimo approccio è quella di scegliere il valore di K in cui si ottiene il massimo valore medio della Silhouette.
Il grafico seguente mostra l’andamento della silhouette per gli 11 valori di K analizzati in precedenza.
Figura 6.4: Andamento della silhouette al variare di K
Come si può osservare in occorrenza di K=5 si registrano valori prossimi al massimo che si registra per K=2 e per questo motivo scartato.
L’immagine seguente mostra il modello finale di clustering selezionato.
Per quanto riguarda l’aspetto legato all’interpretazione dei cluster prodotti dall’algoritmo, una volta terminata la sua esecuzione, ci si è avvalsi della heatmap che dataiku produce in automatico al termine di ogni esecuzione di un algoritmo di clustering. Questo strumento, in particolare, presenta, dato il valore di un attributo, la sua percentuale media globale, la percentuale di cluster che presenta quel valore nell’attributo e infine la variazione percentuale, positiva o negativa, rispetto alla media. L’immagine seguente ha lo scopo di chiarire quanto appena espresso.
Figura 6.6: Heatmap per l’interpretazione dei cluster prodotti dal modello
Ad esempio, il 75% del cluster etichettato come “Altri motivi di anticipo dovuti al corriere” presenta nel suo attributo “descr_causale” il valore “Altri motivi di anticipo dovuti al corriere” a fronte di una percentuale media del 22,83% con un incremento del 228,78%.
Operando in questo modo sono stati individuati i seguenti 5 clusters: Mancanza da collo misto.
Chiuso per ferie/lavori/prodotto.
Altri motivi di anticipo dovuti al corriere. Altri motivi di ritardo dovuti al corriere. Altro.
Per i quali si provvede di seguito a dare una descrizione e a sottolinearne i tratti salienti.
Mancanza da collo misto
Sono anomalie aventi “Plant Sesto Teseosardo” come ente di carico, Frosinone come provincia di carico e “Morelli Group” come trasportatore. Presentano una modalità di spedizione a temperatura controllata, hanno come regioni di scarico il Lazio, la Sicilia, la Campania, la Puglia, la Calabria, le Marche e l’Abruzzo, ossia tutta la fascia centro-meridionale della penisola, e si manifestano esclusivamente nel primo e nel secondo trimestre dell’anno.
Chiuso per ferie/lavori/prodotto
Sono anomalie aventi “Plant Mircoligure” come ente di carico prevalente, Lodi come provincia di carico e “Morelli Group” come trasportatore. Presentano una modalità di spedizione a temperatura controllata, hanno come regioni di scarico la Lombardia e la Liguria e si manifestano esclusivamente nel terzo e nel quarto trimestre dell’anno.
Altri motivi di anticipo dovuti al corriere
Sono anomalie aventi “Plant Elsaa Mare” come ente di carico, Bergamo come provincia di carico e “Riva, De Rosa and Ferrari” come trasportatore. Presentano una modalità di spedizione con camion, hanno come regioni di scarico il Veneto, il Piemonte, l’Emilia, il Trentino e il Friuli, ovvero tutta la fascia settentrionale della penisola, e si manifestano prevalentemente nel primo e nel secondo trimestre dell’anno, ma anche nel terzo e quarto seppur con percentuali molto più basse.
Altri motivi di ritardo dovuti al corriere
Sono anomalie aventi “Plant Sesto Teseosardo” come ente di carico, Frosinone come provincia di carico e “Morelli Group” come trasportatore. Presentano una modalità di spedizione a temperatura controllata, hanno come regioni di scarico il Lazio, la Sicilia, la Campania, la Puglia, la Calabria, le Marche e l’Abruzzo, ossia tutta la fascia centro-meridionale della penisola, e si manifestano esclusivamente nel terzo e nel quarto trimestre dell’anno.
Altro
Sono anomalie per le quali non si è riusciti a identificare una causale avente una netta prevalenza sulle altre.
Altro algoritmo di clustering preso in considerazione è il DBSCAN per il quale tuttavia non si è riusciti a determinare gli opportuni paramenti relativi alla distanza tra i punti (ε) e al minino numero di punti q che circonda un dato punto p. I risultati ottenuti sono quindi altamente negativi e per questa ragione non sono stati presi in considerazione sia per il clustering delle anomalie che per le successive attività di clustering.
L’attività di clustering sulle anomalie così effettuata è stata poi ripetuta sullo stesso dataset dal quale però è stato ricavato il giorno della settimana di consegna e di spedizione dalle rispettive date.
I risultati ottenuti sono i medesimi di quelli sopra con l’aggiunta tuttavia di un nuovo elemento conoscitivo. La heatmap prodotta evidenzia infatti come nel cluster “Altri motivi di anticipo dovuti al corriere” si abbia un notevole incremento rispetto alla media, di oltre il 120%, del valore 7, che corrisponde al Sabato, nell’attributo “day_of_week_scarico”. Questo nuovo elemento così emerso lascia ampiamente intendere come esista una forte concentrazione delle anomalie legate a motivi di anticipo dovuti al corriere in un particolare giorno della settimana, il Sabato.
6.3 Progettazione e realizzazione delle dashboard di rappresentazione
dei cluster
Terminata la fase di interpretazione dei cluster, lo step immediatamente successivo, sempre rimanendo in tema di clustering delle anomalie, ha visto il suo focus spostarsi sulla progettazione e successiva realizzazione, utilizzando le funzionalità di dataiku, di un’interfaccia grafica in grado di fornire visivamente gli elementi conoscitivi emersi e appena presentati.
Anche in questo caso il modus operandi seguito è riconducibile ad un approccio di natura top-down basato su tre livelli progressivi di dettaglio.
1. Un primo livello che potremmo definire di overview dell’attività di clustering. 2. Un secondo livello successivo di dettaglio che riguarda ogni singolo cluster, allo
scopo di comunicare le caratteristiche del cluster in esame.
3. Un terzo livello di dettaglio al quale viene aggiunta la dimensione mensile al livello di dettaglio immediatamente precedente.
Le immagini seguenti mostrano la dashboard di overview e poi una delle cinque dashboards relative al secondo e al terzo livello di dettaglio a titolo esemplificativo.
6.4 Clustering delle spedizioni per gli anni 2016 e 2017
La successiva attività di clustering ha avuto come oggetto le spedizioni effettuate negli ultimi 2 anni, il 2017 e il 2016, clustering che è stato condotto separatamente per i due anni appena elencati al fine di ricercare eventuali convergenze comportamentali nei due anni presi in considerazione. In appendice si riporta la query SQL utilizzata per la creazione del dataset iniziale per l’anno 2016.
I dataset così prodotti, sono stati sottoposti a due fasi successive di data preparation mediante le quali sono prima stati replicati i nomi dei mesi, trimestri, quadrimestri e semestri di carico e scarico, con l’aggiunta del relativo numero (ad esempio da “GENNAIO” a “01 GENNAIO”) in previsione di una migliore rappresentazione grafica dei clusters in termini di ordinamento, e poi rimosse le colonne ritenute non necessarie o potenziali fonti di disturbo ai fini del clustering e le righe che presentavano un anno di scarico precedente al 2016 o al 2017.
Le immagini seguenti mostrano i due flussi realizzati.
