Dipartimento di Informatica
Corso di Laurea Magistrale in Informatica per l’Economia e per l’Azienda Business Informatics
La Business Intelligence a supporto del
controllo qualità nel settore Manufacturing
Relatore
Chiar.ma Prof.ssa Giovanna Rosone
CANDIDATO
Maurizio Quintini
Tutor aziendale
Dott. Luca Gaia
Indice
1 Introduzione 6
1.1 Smart Facturing . . . . 7
1.1.1 Advanced Manufacturing Solution . . . . 8
1.1.2 Augmented Reality . . . . 8 1.1.3 Simulation . . . . 8 1.1.4 Industrial Internet . . . . 9 1.1.5 Cloud Computing . . . . 9 1.1.6 Internet of Things . . . . 9 1.1.7 Cyber - Security . . . . 9
1.1.8 Big Data Analytics . . . . 9
1.2 Contenuti . . . 10 1.3 Metodologia . . . 11 2 Business Intelligence 13 2.1 Definizione e Storia . . . 13 2.2 Caratteristiche . . . 14 2.2.1 ETL . . . 15 2.2.2 Data Warehouse . . . 16
2.3 Stato dell’Arte della BI . . . 17
2.3.1 Gartner Magic Quadrant . . . 17
3 Progettazione del Data Warehouse 21 3.1 Analisi dei requisiti . . . 22
3.2 Progettazione concettuale . . . 22
3.2.1 Fatti . . . 23
3.2.3 Dimensioni . . . 24 3.2.4 Gerarchie . . . 24 3.3 Progettazione logica . . . 24 3.3.1 Star Schema . . . 25 3.3.2 Snowflake Schema . . . 27 3.4 Progettazione dell’alimentazione . . . 27 3.4.1 Extract . . . 28 3.4.2 Transform . . . 28 3.4.3 Load . . . 29 3.5 Progettazione fisica . . . 29 4 Caso di studio 31 4.1 Azienda Committente ed Azienda Operatrice . . . 31
4.2 Analisi dei Requisiti . . . 32
4.2.1 Riparazioni . . . 35
4.2.2 Interventi Tecnici . . . 36
4.2.3 Ricambi (Spare Parts) . . . 37
4.2.4 Vendite . . . 37
4.2.5 Riaddebiti per Assistenza Tecnica . . . 37
4.2.6 Matrice Flussi - Sorgenti . . . 37
4.2.7 Affidabilità: KPIs . . . 38
4.2.8 Dashboard finale . . . 39
4.3 Progettazione e creazione del Data Warehouse . . . 40
4.3.1 Tools e tecnologie . . . 41
4.3.2 Dimensional Table: Depot . . . 47
4.3.3 Dimensional Table: Albero Guasti . . . 54
4.3.4 Dimensional Table: Stato Garanzia . . . 55
4.3.5 Dimensional Table: Anagrafica Seriali . . . 56
4.3.6 Dimensional Table: Anagrafica Service Request . . . 64
4.3.7 Dimensional Table: Anagrafica Clienti . . . 65
4.3.8 Fact Table: Fact Affidabilità . . . 66
4.3.9 Dimensional Fact Model . . . 75
4.4 Creazione del modello . . . 77
4.4.1 OBIEE Administration Tool: Livello fisico . . . 77
4.4.3 OBIEE Administration Tool: Livello di presentazione . . . 84
4.5 Creazione delle analisi . . . 85
4.5.1 Prima pagina: KPIs Affidabilità . . . 85
4.5.2 Seconda pagina: Rankings . . . 92
4.5.3 Risultato finale . . . 95
5 Conclusioni 97 5.1 Sviluppi futuri . . . 98
1
|
Introduzione
Negli ultimi anni il settore industriale mondiale sta assistendo ad un cambiamento radicale di tutti quei processi che hanno come obiettivo finale la creazione di valore. In particolar modo nel settore manifatturiero, grazie alla digitalizzazione di un numero considerevole di attività, non solo è cambiato il modo di lavorare, ma anche la natura delle singole operazioni quotidiane effettuate dalle aziende, modernizzando gli stessi processi aziendali e migliorando così la propria catena del valore. Tali cambiamenti dunque portano benefici sia in ambito lavorativo che in ambito economico, permettendo alle aziende di ottenere un guadagno maggiore sfruttando le nuove tecnologie a disposizione.
A tal proposito sempre più spesso si tende a parlare delle cosiddette Industrie 4.0, ovvero tutte quelle aziende in grado di rinnovarsi periodicamente e sfruttare le tecnologie informatiche a disposizione. Il livello di innovazione è tale per cui l’accezione Industria 4.0 presenta ulteriori significati, quale uno dei più frequenti è Smart Manufacturing, dove il suffisso “Smart” diventa il denominatore comune di una gestione integrata delle informazioni, associata all’uso della tecnologia digitale; in questo contesto l’insieme dei dati informatici che le aziende analizzano e manipolano risulta di fondamentale importanza al fine di comprendere gli stessi processi che portano alla creazione del dato in sé, e quindi l’intero processo di business.
Occorre dunque una definizione più precisa per il concetto di Industria 4.0:
"Il termine Industria 4.0 indica una tendenza dell’automazione industriale che integra
alcune nuove tecnologie produttive per migliorare le condizioni di lavoro ed aumentare la
produttività e la qualità produttiva degli impianti."
Anche il Ministero dello Sviluppo Economico dà una definizione del fenomeno in questione:
"Con Industria 4.0 si intende un modello di produzione e gestione aziendale, con connessione
In sintesi tali tecnologie andranno ad influire positivamente sulla produttività aziendale, permettendo una semplificazione di tutti quei processi che creano valore economico aggiunto per le aziende che ne usufruiscono. Inoltre, come conferma della sempre maggior importanza dell’argomento, sono aumentati anno dopo anno gli incentivi forniti dal Governo per innovare e coinvolgere verso questa direzione un numero sempre maggiore di aziende.
Una delle chiavi di successo dell’Industria 4.0 in generale è senza dubbio la possibilità di scelta tra modelli di implementazione flessibili e trasversali, in grado di semplificare la complessità dei processi aziendali e permettere una corretta esecuzione di tutti quei processi costruiti con tale implementazione.
1.1
Smart Facturing
L’Industria 4.0 si basa sul concetto di Smart Facturing[4], ovvero una metodologia lavorativa che con-sente di far lavorare in modo più intelligente e connesso le risorse disponibili, garantendo velocità e
flessibilità, elementi di cui tutte le imprese, soprattutto quelle manifatturiere, hanno bisogno per essere competitive sul mercato. Lo Smart Manufacturing[2] si compone di tre concetti:
• Smart Production: nuove tecnologie produttive che creano collaborazione tra tutti gli elementi presenti nella produzione, ovvero collaborazione tra operatore, macchine e strumenti;
• Smart Services: tutte le infrastrutture informatiche e tecniche che permettono di integrare i sistemi o che permettono un’integrazione tra aziende e strutture esterne;
• Smart Energy: tutto questo sempre con un occhio attento ai consumi energetici[3].
I risultati ottenuti finora hanno spinto in seguito un numero sempre maggiore di aziende ad adottare tale politica volta al rinnovo e all’innovazione radicale; questo passaggio è stato definito da molti come
Quarta Rivoluzione Industriale, processo mondiale che non ha una vera e propria data di inizio e che porterà alla produzione industriale completamente automatizzata ed interconnessa.
Suddetta “Rivoluzione Industriale” è frutto di varie direttrici di sviluppo:
• Advanced Manufacturing Solution; • Augmented Reality;
• Simulation;
• Cloud Computing; • Internet of Things; • Cyber - Security; • Big Data Analytics.
Le tecnologie elencate hanno permesso l’interconnessione e la collaborazione tra i sistemi aziendali, cambiando il panorama dei mercati globali e portando alla customizzazione di massa, ovvero una strategia di produzione di beni e servizi orientata a soddisfare i bisogni individuali dei clienti e contemporanea-mente preservare l’efficienza della produzione di massa, in termini di bassi costi di produzione, e quindi prezzi di vendita contenuti, divenendo di notevole interesse per l’intero settore manifatturiero.
Le varie direttrici di sviluppo menzionate in precedenza saranno dettagliate brevemente a fini de-scrittivi nei paragrafi seguenti.
1.1.1
Advanced Manufacturing Solution
Per Advanced Manufacturing Solution si intendono tutti i sistemi avanzati di produzione, ovvero sistemi interconnessi e modulari che permettono flessibilità e performance; in queste tecnologie rientrano i sistemi di movimentazione dei materiali automatici e la robotica avanzata.
1.1.2
Augmented Reality
Si intendono tutti i sistemi di visione con realtà aumentata per guidare meglio gli operatori nello svol-gimento delle attività quotidiane, ovvero tutti i sistemi che comportano l’arricchimento della percezione sensoriale umana mediante informazioni, manipolate e convogliate elettronicamente all’interno della realtà normalmente percepita.
1.1.3
Simulation
Anche il processo di simulazione tra macchine interconnesse ha permesso un miglioramento dell’au-tomazione industriale, base principale delle Industrie 4.0. Più nello specifico un processo di simulazione prevede un modello della realtà che consente di valutare e prevedere lo svolgersi dinamico di una serie di eventi o processi conseguenti all’imposizione di certe condizioni da parte dell’utente. Tale tecnica consente dunque di prevedere e prevenire rischi e problemi derivanti da processi di business che hanno obiettivo finale quello di creare valore per l’azienda stessa.
1.1.4
Industrial Internet
L’Industrial Internet ha come obiettivo principale quello di ottenere una comunicazione efficace ed effi-ciente non solo all’interno dell’azienda, ma anche all’esterno, grazie all’ausilio della tecnologia Internet. Questa direttiva era già presente in molte aziende, ma che ha comunque garantito dei risultati positivi in ottica Industry 4.0.
1.1.5
Cloud Computing
Tecnologia di fondamentale importanza per la centralizzazione delle informazioni e la loro conser-vazione. Si tratta dunque di un modello di erogazione di risorse informatiche, come l’archiviazione, l’elaborazione o la trasmissione di dati, caratterizzato dalla disponibilità on demand attraverso il web a partire da un insieme di risorse preesistenti e configurabili.
1.1.6
Internet of Things
Il concetto di Internet of Things (IOT) è un neologismo riferito all’estensione Internet al mondo degli oggetti e dei luoghi concreti. Più nello specifico è un’evoluzione dell’uso della rete: gli oggetti (dispo-sitivi, apparecchiature, eccetera) si rendono riconoscibili ed acquisiscono intelligenza grazie al fatto di poter comunicare dati su sé stessi ed accedere alle informazioni aggregate da parte di altri. L’obiettivo è quello di far sì che il mondo elettronico vada a tracciare una mappa di quello reale, dando un’identità elettronica alle “cose” e ai luoghi dell’ambiente fisico; in questo modo tutti i dispositivi ed oggetti saranno sempre più interconnessi tra loro e daranno vita ad una rete ancora più fitta di presenza sul territorio e, in generale, su tutti gli ambienti che necessitano di controllo, automazione e rilevamento.
1.1.7
Cyber - Security
Con l’aumento delle interconnessioni interne ed esterne si rende necessario incrementare il livello di sicurezza delle informazioni e dei sistemi, che non devono essere alterati dall’esterno. Ciò è dovuto alla sempre più crescente digitalizzazione delle informazioni da parte di società e servizi e della parallela diffusione e specializzazione di attaccanti a tali informazioni.
1.1.8
Big Data Analytics
Il tema dell’Analytics è diventato ricorrente solo negli ultimi anni. Generalmente per Big Data Analytics si intende un processo di raccolta ed analisi di grandi volumi di dati per estrarre conoscenza ed informazioni nascoste.
e comportamento dei clienti, rendendo l’attività decisionale più efficace e veloce. Tutte le attività che hanno a che fare con i Big Data rientrano all’interno delle analisi predittive, poiché attraverso un modello e dati storici è possibile determinare con basi o fondamenti statistici l’evolversi di uno scenario in futuro.
1.2
Contenuti
Il lavoro svolto nella tesi documenta il progetto realizzato presso Iconsulting S.P. A., società di consulenza informatica con sede a Bologna specializzata nella progettazione di sistemi best-in-class di Data
Ware-house, Business Intelligence, Performance Management e Big Data Analytics per una nota azienda del settore
manifacturing, che nel documento di tesi sarà citata come “l’Azienda”.
Di seguito verrà presentata la struttura della tesi, suddivisa per capitoli e con una breve descrizione del contenuto di ognuno:
• Il Capitolo 2 fornisce una panoramica su quella che è la Business Intelligence e la storia di come la stessa si è evoluta nel corso del tempo. Inoltre saranno dettagliate maggiormente tutte quelle tec-nologie o strumenti che sono di fondamentale importanza nell’ottica della BI. Infine viene indicato lo stato dell’arte di ciò che esiste per la risoluzione del progetto di tesi affrontato;
• Il Capitolo 3 elenca e dettaglia tutti i passaggi fondamentali per la creazione di un Data Warehouse, a partire dall’analisi dei requisiti fino alla progettazione fisica vera e propria; saranno inoltre for-nite peculiarità e caratteristiche fondamentali di tutte le strutture e le architetture informatiche relative alla Business Intelligence ed alla conseguente costruzione del DW. Ogni passaggio sarà ac-compagnato da accenni teorici che permettono di evidenziare le motivazioni delle scelte suddette per la creazione dell’architettura finale;
• Il Capitolo 4 si incentrerà sull’analisi del caso di studio principale, inserendo una breve descrizione sull’ambiente in generale, facendo riferimento all’azienda committente ed all’azienda operatrice. L’inizio del capitolo sarà dedicato inizialmente all’analisi dei requisiti, mentre in seguito verranno elencate e descritte le strutture costruite, fornendo a corredo di ognuna sia le motivazioni che hanno guidato il team di lavoro alla costruzione delle stesse che dettagli riguardo gli algoritmi adottati in grado di popolarle. Infine saranno descritte le fasi di modellazione e di costruzione delle pagine di reportistica obiettivo dell’intero progetto di tesi, soffermandosi anche in questo caso sulle scelte che hanno condotto al risultato finale;
• Il Capitolo 5 tratta le conclusioni del progetto di tesi, con considerazioni riguardanti l’ambiente lavorativo e la consulenza in sé, ponendo l’attenzione su un concetto cardine come quello della fidelizzazione del cliente, rilevante per il lavoro di consulente.
1.3
Metodologia
Per un corretto svolgimento dell’intero lavoro si è ritenuto opportuno adottare la metodologia di gestione di progetti agile denominata SCRUM, che ha avuto e sta avendo una diffusione notevole, cambiando completamente il modo di approcciare i progetti di sviluppo. Essa si basa su tre semplici concetti:
• Sprint
• Backlog
• Scrum Meeting
SCRUM prevede di dividere il progetto in blocchi rapidi di lavoro (Sprint) di durata limitata in modo da concentrarsi esclusivamente su ciò che è strettamente necessario; per ogni blocco occorre consegnare una versione alla committenza, la quale indica come definire i dettagli del lavoro da fare nell’immediato futuro (Backlog) per averne una definizione estesa; infine riunioni giornaliere del team di sviluppo (Scrum Meeting) permettono di verificare cosa si è fatto e cosa è in programma di fare[5].
Figura 1.1: Processo SCRUM
Sinteticamente SCRUM è un framework di processo che prevede di dividere il progetto in blocchi rapidi di lavoro, dove alla fine di ciascuno creare un incremento del software. Esso indica come definire i dettagli del lavoro da fare nell’immediato futuro e prevede vari meeting per creare occasioni di ispezione e controllo del lavoro svolto.
Il termine "scrum" deriva dal termine del rugby che indica la mischia durante il match, metafora del team di sviluppo che lavora nella stessa direzione, agendo come un’unica entità coordinata. Per tale
motivo SCRUM oltre ad essere efficace in ambito produttivo si connota per la semplicità del modello proposto per organizzare il proprio progetto.
2
|
Business Intelligence
2.1
Definizione e Storia
Il documento di tesi e l’intera analisi descritta si basa totalmente su processi aziendali e tecnologie di
Business Intelligence. Per ovvi motivi si è ritenuto opportuno approfondire l’argomento, in modo da evi-denziare le proprietà principali che contraddistinguono questo tipo di tecnologie da quelle tradizionali. Il termine Business Intelligence (BI) è stato coniato per la prima volta nel 1958 per merito di Hans
Peter Luhn, ricercatore ed inventore tedesco che lavorava per IBM[6]. Il concetto di Business Intelligence esprime l’insieme dei processi e tecnologie annesse che permettono la trasformazione di dati in informazioni, e le informazioni in conoscenza, orientando il processo decisionale a vari livelli dell’or-ganizzazione aziendale.
Entrando maggiormente nel merito dell’argomento, gli strumenti di BI sono software di tipo ap-plicativo che raccolgono ed elaborano grandi quantità di dati non strutturati, permettendo di acquisire informazioni derivanti da tali dati principalmente tramite l’esecuzione di query. Questi strumenti con-sentono inoltre di preparare i dati per l’analisi, creare report, dashboards e visualizzazioni dei dati.
Ci si può riferire a sistemi di BI anche con l’espressione “Sistemi di supporto alle decisioni”
(De-cision Support Systems o DSS), ovvero di supporto per tutte quelle aziende che, attraverso una mole di dati a disposizione, necessitano di assumere decisioni corrette riguardo al proprio business. Queste applicazioni sono nate in un periodo in cui si cominciava ad avere il problema di possedere giganteschi archivi di dati senza sapere come trarre benefici da tali dati.
La Business Intelligence rappresenta dunque lo strumento chiave dell’evoluzione verso una gestione sempre più efficace e strategica delle informazioni; l’apertura all’innovazione che è cresciuta con il passare degli anni ha consentito alla BI di inglobare al suo interno un numero sempre più crescente di tecnologie ed esperti del settore, rendendola una scienza di fondamentale importanza per tutte le aziende che hanno l’obiettivo di risultare competitive sul mercato.
I dati generati dai vari sistemi aziendali sono archiviati in particolari database, chiamati Data
maggior-mente nel dettaglio funzionamento e caratteristiche principali dei DW.
2.2
Caratteristiche
La Business Intelligence è un sistema di modelli, metodi e processi che rende possibile la raccolta organizzata dell’insieme dei dati generato da un’azienda. Attraverso elaborazioni, analisi o aggregazioni è possibile la trasformazione dei dati in informazioni utili ai fini dei processi decisionali; inoltre la loro conservazione, reperibilità e presentazione in forma semplice, flessibile ed efficace garantisce rapidità di comprensione e di utilizzo dei dati stessi.
Figura 2.1: Processo di Business Intelligence
Ogni sistema di Business Intelligence comporta dunque:
• La raccolta dei dati da varie sorgenti, quali fogli di lavoro Excel, file XML, database, file destrut-turati, eccetera;
• La loro pulizia, validazione ed integrazione;
• Successiva elaborazione, aggregazione ed analisi, gestite attraverso un tool specifico per l’estra-zione, trasformazione e caricamento dati: Extract Transform and Load (ETL);
• A seguito di una certificazione e pulizia dei dati risulta fondamentale l’utilizzo degli stessi a sup-porto dei processi decisionali aziendali.
Figura 2.2: Dalle sorgenti dati alla creazione di report
L’intero processo di BI passa attraverso due fasi intermedie tra la raccolta delle informazioni dalle varie sorgenti e la fase di creazione della reportistica che sono fondamentali per l’immagazzinamento dei dati e la modifica degli stessi per ottenere le informazioni d’interesse:
• Processo di Extract, Transform and Load (ETL) dei dati dalle varie sorgenti;
• Costruzione di un Data Warehouse (DW), all’interno del quale sono caricati i dati precedentemente trasformati dal tool di ETL.
Saranno mostrati di seguito peculiarità e caratteristiche dei punti appena illustrati.
2.2.1
ETL
Un processo di ETL (Extract, Transform and Load) è un qualsiasi processo di estrazione, trasformazione e caricamento dei dati in un sistema di sintesi. I dati sono estratti da più sistemi sorgenti, subendo quindi un processo di trasformazione in grado di uniformarli e renderli consistenti; di seguito ne sono presentati alcuni tipi:
• Selezione di campi d’interesse;
• Normalizzazione dei dati;
• Derivare nuovi dati calcolati, detti anche metriche o KPI (Key Performance Indicator);
• Eseguire join tra dati recuperati da tabelle differenti;
• Unione o raggruppamento di dati.
Tali trasformazioni sono necessarie per il consolidamento dei dati, ovvero per rendere omogeneo l’insieme dei dati proveniente da sorgenti diverse. In seguito a ciò occorre memorizzare (load) la totalità delle informazioni all’interno di strutture ad hoc, quali Data Warehouse o Data Mart.
2.2.2
Data Warehouse
Il termine Data Warehouse è diventato sempre più ricorrente con il passare del tempo, soprattutto nelle realtà di medie e grandi dimensioni. La definizione ed il significato di questo temine trovano corrispon-denza nell’aumento di volume e di complessità dei dati raccolti nell’ambito delle soluzioni di Business Intelligence.
Con Data Warehouse (DW) si fa riferimento ad un archivio contenente i dati di un’organizzazione, progettato per consentire di produrre facilmente analisi e relazioni che diventano il cuore del sistema di definizione delle strategie aziendali. In questo modo un DW può essere visto come una vera e propria base di dati sulla quale si fondano le analisi a supporto delle scelte manageriali; infatti tale struttura ha senso solo nel momento in cui i dati in esso immagazzinati vengono raffinati, organizzati ed analizzati da strumenti di BI, con il fine ultimo di produrre analisi.
Quando gruppi di dati del DW vengono organizzati in più unità compatte allora si parlerà di Data Mart, ovvero un raccoglitore di informazioni specializzato in un particolare soggetto che contiene un’im-magine dei dati permettendo di formulare strategie, in modo da venire incontro ad un’esigenza specifica e già determinata. Usualmente viene collocato a valle di un DW più globale ed è alimentato a partire da esso di cui costituisce un sottoinsieme minore.
Ciò che differenzia realmente un database relazionale classico da un DW è lo scopo finale per il quale vengono progettate le due strutture menzionate: mentre la prima ha l’obiettivo di registrare in tempo reale i dati con i quali viene alimentata, la seconda struttura invece è progettata sulla base di sistemi
OLAP(On Line Analytical Process) per compiere aggregazioni di dati a fini analitici.
Il primo che ha parlato esplicitamente di Data Warehouse è stato William H. Inmon, definendolo una raccolta dati “integrata, orientata al soggetto, variabile nel tempo e non volatile” di supporto ai processi decisionali; di seguito saranno descritti più nel dettaglio le motivazioni che hanno portano Inmon alla scelta delle espressioni precedentemente menzionate:
• Integrata: requisito fondamentale del DW, in quanto in esso confluiscono i dati provenienti da più fonti. La costruzione di un sistema di DW non comporta l’inserimento di nuove informazioni bensì la riorganizzazione di quelle esistenti, ed implica pertanto l’esistenza di un sistema informativo;
• Orientata al soggetto: il DW è orientato a temi specifici aziendali piuttosto che alle applicazioni o funzioni, ragion per cui i dati vengono archiviati in modo che possano essere facilmente letti o elaborati dagli utenti, ossia per favorire la produzione di informazioni;
• Variabile nel tempo: i dati archiviati in un DW hanno un orizzonte temporale molto più esteso rispetto a quelli archiviati in un sistema operazionale. Tutte le informazioni relative all’area d’in-teresse colgono quindi la situazione relativa ad un dato fenomeno in un ampio intervallo
tem-porale. Ciò comporta che i dati nel DW sono aggiornati fino ad una certa data, che è sempre
antecedentea quella in cui l’utente interroga il sistema. Situazione differente si manifesta in un DB transazionale in cui i dati corrispondono sempre ad una situazione costantemente aggiornata, non fornendo dunque un quadro storico del fenomeno.
• Non volatile: tale caratteristica indica la non modificabilità dei dati da parte degli utenti all’interno del DW, che consente accessi di sola lettura. Questo comporta una semplicità di progettazione del database rispetto a quella di un’applicazione transazionale[11].
In sintesi: il Data Warehouse descrive il processo di acquisizione, trasformazione e distribuzione di informazioni di supporto ai decision makers e si differenzia in modo sostanziale dai normali sistemi transazionali che hanno il limitato compito di automatizzare le operazioni di routine.
2.3
Stato dell’Arte della BI
Il fenomeno relativo alla sempre più crescente mole di dati da analizzare è diventato un fatto noto che, soprattutto negli ultimi anni, è diventato una prassi. Per tale ragione il management aziendale ha la necessità di analizzare trend temporali sempre più lunghi ed ha maturato la convinzione che solo un’analisi completa di tutti i dati può garantire un risultato analitico valido. D’altro canto un gran numero di aziende non dispone di tecnologie adatte per garantire analisi rapide ed efficienti. [7]
La Business Intelligence ha vissuto negli ultimi anni un’evoluzione che l’ha trasformata da strumento per analisi retrospettive a mezzo per analisi sempre più real-time e predittive [8]. Oggi le nuove possibilità della BI derivano dall’evoluzione delle tecnologie hardware e software collegate alla gestione dei dati. Un modello significativo di un fenomeno si può trarre solo da una grande quantità di dati (Big
Data) ed è necessario un sistema in grado di raccogliere questi dati in tempo reale, immagazzinarli in database ed in seguito elaborarli.
2.3.1
Gartner Magic Quadrant
Ad oggi le piattaforme di BI sono utilizzabili sia come applicazioni in locale e sia come servizi cloud, a vari livelli di complessità e funzioni, permettendo anche a personale non tecnico di creare cruscotti informativi attraverso un’interfaccia intuitiva ed interattiva.
Conseguentemente a ciò è aumentato sensibilmente il numero di competitors che hanno come obiet-tivo principale quello di guadagnare una quota di mercato creando tool di BI dedicati. A tal proposito occorre citare l’analisi effettuata da Gartner Inc., società per azioni americana e leader mondiale nella consulenza strategica, in grado di fornire una panoramica sui fornitori tecnologici presenti sul mercato: l’analisi in questione è chiamata Gartner Magic Quadrant.
Oltre a dare un quadro generale su tutte le tecnologie presenti, il Quadrante in questione può risultare uno strumento utile anche per quelle aziende che vogliono analizzare e capire il loro livello di competitività sul mercato.
Il Quadrante si presenta come una griglia con quattro campi e due parametri, uno per ascissa e l’altro per ordinata che indicano rispettivamente la Completezza di visione (o Completeness of vision) e Capacità di esecuzione (o Ability to execute).
Figura 2.3: Gartner Magic Quadrant
La Completezza di visione indica la capacità dell’azienda di comprendere le esigenze degli acquirenti, avendo uno sguardo sempre rivolto al campo dell’innovazione; la Capacità di esecuzione invece misura la capacità dell’azienda di rendere la propria visione una realtà effettiva sul mercato, considerando l’ef-ficienza dell’azienda, la capacità nelle attività post-vendita e la situazione finanziaria. I due parametri menzionati sono associati a 4 grandi aree, descritte di seguito:
alte. Solitamente sono aziende molto grandi che operano in mercati già maturi, dove si distinguono come leader del settore, con base clienti ampia, sviluppata grazie alle capacità ed ai continui in-vestimenti. Non sono altro che i migliori sul mercato e sono quelle aziende in grado di dominarlo e di determinarne la direzione, andamento ed evoluzione futura.
• ATTORI DI NICCHIA: nel riquadro opposto ai leader vi sono quelle aziende focalizzate su un mercato molto specifico. Al contrario dei precedenti, la completezza di visione e la capacità di esecuzione di queste aziende è molto limitata, poiché si tratta di aziende di piccole dimensioni con capacità specifiche e limitate ad un’area di competenza. Talvolta vengono posizionate in questo quadrante anche aziende di grandi dimensioni, ma che per difficoltà di sviluppo o poca visione non sono in grado di posizionarsi in modo determinante.
• SFIDANTI: sono identificate le aziende con grande potenziale, capacità di esecuzione sul mercato e grandi capacità, tanto da rappresentare una minaccia per i leader stessi, ma che hanno una visione futura più limitata.
• VISIONARI: sono quelle aziende, spesso molto innovative, che forniscono prodotti e servizi con una visione ampia ed evoluta, in grado di rispondere a problemi anche su larga scala, ma che non hanno le abilità e le capacità di esecuzione per mettere in atto operazioni molto costose eco-nomicamente.
Il Quadrante di Gartner, come detto in precedenza, mostra una panoramica reale della situazione del mercato di riferimento, ma ciò non significa che i leader di mercato siano sempre la soluzione migliore da adottare. Risulta necessario quindi eseguire un’attenta analisi su pro e contro di ogni tool a disposizione, ma soprattutto è opportuno che ogni singola possibilità venga calata sulla singola situazione, in modo da trovare la soluzione ottima tra quelle disponibili[9].
Figura 2.4: Confronto tra Febbraio 2016 e Febbraio 2017
Come da figura è possibile notare come all’interno del quadrante siano cambiate le posizioni di aziende leader nel settore tra febbraio 2016 e febbraio 2017. Un miglioramento consistente vede pro-tagonisti Microsoft e Tableau, dove avanzano sia per quanto riguarda la Completezza di visione che la
Capacità di esecuzione. Qlik invece è l’unica company di punta che subisce una leggera retrocessione, dovuta a causa della varietà di soluzioni che offre[10].
3
|
Progettazione del Data
Ware-house
La prima fase di ogni progetto di Business Intelligence riguarda la realizzazione del Data Warehouse, ovvero l’architettura sottostante a tutte le analisi mostrate all’utente finale. Per la progettazione di un DW sono necessarie più operazioni che possono essere racchiuse nelle seguenti fasi:
1. Analisi dei requisiti: in questa prima fase vengono stabiliti con il committente i requisiti che devono essere soddisfatti dalle analisi che si andranno a sviluppare. Questa fase è tutt’altro che semplice, poiché gli analisti possono avere difficoltà a comprendere il linguaggio del cliente, e viceversa; inoltre lo stesso cliente potrebbe aver difficoltà nell’identificare gli obiettivi ultimi aventi maggior priorità, e ciò potrebbe causare incomprensioni tra le parti;
2. Progettazione concettuale: nella seconda fase viene creata una rappresentazione astratta, in forma grafica, dello schema dei dati. Ha lo scopo di esprimere il significato di termini e concetti usati dagli esperti del dominio per discutere il problema e di trovare le giuste relazioni tra concetti differenti. Il modello concettuale per la progettazione di un Data Warehouse è chiamato
Dimen-sional Fact Model(DFM);
3. Progettazione logica: in questa fase viene adottata una rappresentazione logica ed organizzata delle strutture dati, ovvero viene effettuata una trasformazione dallo schema concettuale allo schema logico usando il modello dati di un sistema per la gestione di Data Warehouse;
4. Progettazione dell’alimentazione del DW: una volta terminata la fase di progettazione logica è necessario mantenere aggiornate le strutture che ospiteranno tutti i dati per le analisi, quindi questa fase è esclusiva per la costruzione ed il mantenimento del flusso ETL;
5. Progettazione fisica: in quest’ultima fase vengono stabilite le strutture di memorizzazione per agevolare le operazioni di analisi dei dati.
Figura 3.1: Architettura a tre livelli
Il Data Warehouse è stato progettato secondo l’architettura a tre livelli come viene mostrato nell’im-magine seguente.
3.1
Analisi dei requisiti
La fase riguardante l’analisi dei requisiti, come già accennato, risulta essere una delle più importanti per la costruzione e creazione di un Data Warehouse, ma nel contempo è spesso anche una delle operazioni più critiche, poiché devono essere specificati chiaramente i requisiti fondamentali delle analisi, e non sempre ciò è immediato.
La fase di analisi dei requisiti si divide nei seguenti punti:
• Interviste agli utenti e analisi della reportistica;
• Preparazione e presentazione della documentazione sull’analisi dei requisiti.
Assumono fondamentale importanza le interviste agli utenti poiché è necessario comprendere al meglio il modello di business dell’azienda committente ed i vincoli necessari per ottenere il risultato finale atteso. Inoltre in questa fase vengono definiti i processi di caricamento delle informazioni nel DW e le specifiche delle applicazioni e delle strutture da costruire.
3.2
Progettazione concettuale
Ultimata la fase di analisi dei requisiti è necessario che vengano affinate dal punto di vista logico le speci-fiche ottenute nella fase precedente. A tal proposito risulta opportuno creare una base di partenza stabile
dalla quale costruire il progetto logico del Data Warehouse; questa fase prende il nome di Progettazione
concettualee sfrutta il modello chiamato Dimensional Fact Model (DFM), standard internazionale in grado di agevolare la comunicazione tra progettista ed utente finale. Il DFM è dunque un modello con-cettuale grafico, concepito specificamente per la progettazione multidimensionale con l’obiettivo di:
• Fornire un supporto efficace a tutta la fase di progettazione concettuale;
• Creare un ambiente in cui le domande degli utenti possano essere formulate in modo intuitivo;
• Rendere possibile la comunicazione tra i progettisti e gli utenti finali con l’obiettivo di formalizzare le specifiche dei requisiti;
• Costruire una piattaforma stabile per la progettazione logica;
• Fornire una documentazione di progettazione chiara ed espressiva.
Figura 3.2: Struttura del Dimensional Fact Model
La rappresentazione concettuale generata dal DFM consiste di un insieme di Fact Scheme (FS), in grado di modellare concetti come fatti, misure, dimensioni e gerarchie.
3.2.1
Fatti
All’interno di un DFM, il fatto è il concetto di maggior interesse per i processi di decision-making. Esso infatti racchiude al suo interno indicatori (o misure) di grande importanza per l’azienda committente, in quanto forniscono un’indicazione sui requisiti discussi in fase di analisi.
Di norma un fatto modella un insieme di eventi interni aziendali (es. ordini, spedizioni, vendite, ecc.) e fornisce un’informazione numerica per ogni evento modellato e gestito all’interno dello stesso.
3.2.2
Misure
Le misure sono proprietà numeriche appartenenti a fatti e descrivono attributi quantitativi determinanti per l’analisi. Esse sono ottenute attraverso il calcolo di più parametri e secondo le logiche discusse in fase di analisi dei requisiti.
3.2.3
Dimensioni
In uno schema DFM le dimensioni sono strettamente correlate ai fatti, poiché forniscono un contesto finito al fatto con il quale sono collegate, ovvero sono in grado di descrivere ed esplorare una coordi-nata di analisi del fatto stesso. La parola "dimensione" deriva dal fatto che andando ad analizzare i dati secondo diverse prospettive, questi possono essere rappresentati tramite cubi aventi tante dimensioni quante sono le prospettive di analisi. Generalmente un fatto ha più dimensioni che definiscono la sua granularità minima di rappresentazione.
Un attributo dimensionale, invece, è una proprietà avente dominio finito appartenente ad una dimen-sione. Le relazioni tra gli attributi dimensionali sono espresse attraverso le gerarchie.
3.2.4
Gerarchie
Le gerarchie rappresentano un ordinamento logico dei livelli all’interno di una stessa dimensione. Esse definiscono il modo in cui gli eventi aziendali possono essere selezionati ed aggregati per i processi di
decision-making. Nello specifico l’aggregazione e la successiva navigazione dei dati può avvenire in due modi differenti:
• Roll-Up: i dati vengono aggregati per un livello superiore, il che comporta una diminuzione del livello di dettaglio dell’analisi;
• Drill-Down: i dati vengono aggregati per un livello inferiore, che implica dunque un aumento del livello di dettaglio dell’analisi.
3.3
Progettazione logica
Terminata la fase di progettazione concettuale, che ha fornito un modello in grado di definire i concetti rilevanti senza alcuna informazione sull’organizzazione dei dati, segue la fase di progettazione logica. Il
Figura 3.3: Esempio di DFM con fatto e dimensioni associate
risultato finale sarà dunque uno schema relazionale che avrà due tipi di tabelle, in grado di rappre-sentare gli oggetti del modello. Le tabelle che comporranno lo schema sono:
• Fact Table: tabella contenente valori numerici (misure) che descrivono un processo di business; inoltre ogni fact table ha un collegamento (foreign key) ad ogni tabella dimensionale;
• Dimensional Table: tabelle che contengono informazioni delle entità principali legate al processo di business e che forniscono un contesto di vario tipo allo stesso.
La rappresentazione multidimensionale a questo punto può essere costruita attraverso due tipi di schemi che differiscono tra loro in base al grado di normalizzazione dei dati, ovvero il processo at-traverso il quale, in fase di progettazione del DB, viene eliminata la ridondanza dei dati. Questa potrebbe infatti causare delle anomalie nella consistenza degli stessi in seguito ad operazioni di inserimento, can-cellazione e modifica di record. Gli schemi appena descritti saranno dettagliati in seguito e sono:
• Star Schema;
• Snowflake Schema.
3.3.1
Star Schema
Lo Star Schema (o Schema a Stella) è lo schema più utilizzato per Data Warehouse. La struttura di base consiste in una tabella fatto che referenzia un numero di tabelle dimensionali. Data la semplicità di tale
schema questo viene solitamente utilizzato per la rappresentazione di data mart, ovvero un sottoinsieme di dati aziendali con un ambito di analisi specifico e ben definito.
Lo schema a stella classifica gli attributi di un evento come attributi dei fatti, chiamati metriche, o come attributi dimensionali in grado di definire il contesto dei fatti. Ogni record è il nesso tra i valori delle dimensione in analisi e le tabelle dei fatti. Il nome di Star Schema è dovuto alla rappresentazione grafica delle relazioni tra la fact table (centrale a tutto lo schema) e le tabelle dimensionali (che assumono in questo caso le "punte" della stella).
Figura 3.4: Rappresentazione di Star Schema
Nel caso in cui venga scelto uno schema a stella la tabella dei fatti conterrà un numero elevatissimo di record, poiché per una corretta analisi è necessario salvare tutti i valori misurabili per uno specifico processo di business. Una tabella dei fatti in genere può essere di tre tipi:
• Di transazione, in cui viene analizzato uno specifico evento;
• Istantanea (o Snapshot), in cui sono analizzati degli eventi accaduti in uno specifico periodo tem-porale;
• Instantanea ad accumulo (o Accumulating snapshot) che tengono traccia di tutti gli eventi ac-caduti nel periodo di riferimento.
Il beneficio principale di uno Star Schema è che questi sono progettati per ottimizzare le prestazioni per il recupero dei dati, riducendo al minimo il numero di join tra le tabelle dimensionali per ottenere i
risultati attesi.
3.3.2
Snowflake Schema
Lo Snowflake Schema (o Schema a Fiocco di Neve) può essere visto come un’estensione dello Star Schema, avente sempre come struttura centrale una tabella del fatto che referenzia più tabelle dimensionali, con la differenza che queste ultime possiedono ulteriori ramificazioni con altre tabelle normalizzate. Il nome di tale schema deriva appunto da questa ramificazione che viene ottenuta collegando le varie tabelle a partire dalla fact table.
Figura 3.5: Rappresentazione di Snowflake Schema
Uno dei benefici derivanti dall’utilizzo di tale schema è l’assenza di ridondanza tra i dati, poiché per ogni informazione d’interesse è opportuno creare una tabella ad-hoc; ci ò comporta una netta sempli-ficazione dell’aggiornamento dei dati ed una maggiore velocità di accesso alle informazioni. Di contro l’aumento del numero delle tabelle rende necessarie query che necessitano di più join per la ricerca di informazioni.
3.4
Progettazione dell’alimentazione
Una volta ultimata la fase di progettazione logica e concettuale è necessario progettare la parte relativa all’ETL, Extract, Transform and Load, ovvero l’insieme di procedure in grado di aggiornare sistemati-camente l’intero Data Warehouse. Questa fase è molto importante per la progettazione di un DW, ma d’altro canto le procedure di aggiornamento dei dati per l’alimentazione dei DW sono proprio uno dei grossi limiti delle architetture di Business Intelligence.
3.4.1
Extract
La prima fase del processo ETL consiste nel leggere i dati che provengono dalle diverse sorgenti infor-mative. La diversità di queste sorgenti rende necessaria dunque la definizione di un piano di estrazione degli stessi che comporta la definizione delle modalità di estrazione e l’orario in cui eseguirla. Nella maggior parte dei casi, a causa della notevole mole di dati che devono essere caricati, è nella norma far partire i processi di estrazione dei dati nelle ore notturne, in quanto vi sono meno richieste al sistema rispetto al resto della giornata. Vi sono due tipi di modalità di estrazione:
• Statica: consiste nell’importazione di tutti i dati presenti nelle sorgenti dati; questo tipo di estra-zione viene eseguita la prima volta che deve essere popolato il Data Warehouse;
• Incrementale: in questo caso vengono estratti solo i dati che hanno subìto delle modifiche dall’ul-tima estrazione. Per far ciò è necessario preservare le informazioni relative alle ultime estrazioni affinché si possa essere in grado di determinare i cambiamenti ottenuti.
Una volta estratti i dati dalle sorgenti vengono memorizzati nella Staging Area, area di storage inter-media, all’interno della quale le informazioni sono memorizzate temporaneamente in modo da compiere operazioni di pulizia e trasformazione del dato.
3.4.2
Transform
La fase di trasformazione riguarda le operazioni di pulizia e di trasformazione del dato, in modo da uniformare l’intera mole di informazioni che confluirà in seguito all’interno del Data Warehouse. Le operazioni di trasformazione possono essere categorizzate in due fasi:
• Pulizia: in questa fase vengono individuati i record contenenti informazioni non utili ai fini del-l’analisi, e quindi non consistenti, e successivamente corretti per garantire la correttezza dell’intera mole di dati. I maggiori problemi che vengono riscontrati in questa fase possono essere: dati du-plicati, mancanti o errati;
• Trasformazione: vengono effettuate una serie di operazioni sui dati in modo tale da renderli uniformi all’interno del DW. Le possibili operazioni di trasformazione sono:
• Conversione: il diverso formato dei dati potrebbe causare problemi a lungo andare, e quindi
risulta necessario convertirli in un unico formato;
• Integrazione: vengono integrati i dati provenienti da diverse fonti;
• Aggregazione: i dati vengono aggregati in modo da ottenere migliori performance durante le
• Selezione: vengono selezionati solamente i dati necessari; • Misure: vengono calcolate misure derivate da quelle esistenti.
3.4.3
Load
L’ultima fase di ETL riguarda il caricamento delle informazioni nel Data Warehouse. I dati derivanti dai precedenti processi di trasformazione permettono dunque di popolare in primis le tabelle dimensionali, ed in seguito le fact, mantenendo in questo modo i vincoli di integrità referenziale. Si possono annoverare due tipologie di caricamento dati:
• Refresh: la prima tipologia effettua un caricamento totale del DW e viene utilizzata solitamente per effettuare il primo caricamento;
• Update: la seconda tipologia consiste in un caricamento esclusivo dei dati che hanno subìto modi-fiche dalla data di ultimo aggiornamento. Questo permette di non cancellare i dati meno recenti, preservando così la storicizzazione del DW[11].
3.5
Progettazione fisica
Nell’ultima fase progettuale vengono definite le tecniche per migliorare le performance di un DW. Le tecniche in questione possono essere raggruppate in tre categorie:
• Pre-aggregazione: i dati all’interno del DW hanno un livello di dettaglio minimo, e ciò com-porta un elevato dispendio di risorse e di tempo in caso di interrogazioni che comportino delle aggregazioni run-time; per evitare questo comportamento è possibile effettuare un’aggregazione dei dati nella fase precedente al caricamento degli stessi in modo da creare diverse fact table che contengono dati a livelli diversi di aggregazione. Questo implica un aumento del volume com-plessivo del DW, e quindi per poter ottenere risultati soddisfacenti è necessario trovare un giusto compromesso tra velocità di esecuzione, spazio occupato e tempo per la pre-aggregazione dei dati.
• Partizionamento delle tabelle: nel caso in cui fossero presenti tabelle di dimensioni elevate (es. Fact Table) risulta quasi obbligatorio effettuare delle operazioni di partizionamento per poter ot-tenere migliori performance. Mentre da un lato ciò comporta un aumento sensibile della velocità di esecuzione, dall’altro causa un notevole incremento nella difficoltà delle query, con un maggiore numero di join per accedere alle diverse partizioni delle tabelle.
• Indicizzazione della tabella e chiavi numeriche: tale tecnica è necessaria per velocizzare la lettura delle informazioni; questo perché in caso di tabelle di dimensioni elevate in mancanza di
indicizzazione delle stesse risulta molto oneroso effettuare ricerche di qualsiasi tipo. Indicizzando le tabelle il DW è capace di recuperare i dati necessari direttamente consultando l’indice in modo da identificare la posizione esatta occupata dalle informazioni sul DW stesso. Di contro queste tecniche causano una perdita di performance nelle operazioni di aggiornamento dei dati a causa della manutenzione dei vari indici creati.
4
|
Caso di studio
4.1
Azienda Committente ed Azienda Operatrice
Il lavoro descritto nella tesi è stato commissionato da una nota azienda operante nel settore
Manufac-turingche sarà menzionata per tutto il documento come “l’Azienda”.
L’azienda in questione, leader nel proprio settore, ha l’obiettivo di perseguire il cammino, già in-trapreso da vari anni, orientato al raggiungimento dell’eccellenza dei propri processi, prodotti e servizi, alla piena soddisfazione dei propri clienti e stakeholders interni ed esterni oltre che al miglioramento continuo. L’azienda è leader nella produzione di dispositivi meccanici che, attraverso una punta da tra-panatura o fresatura, permettono di effettuare diversi tipi di lavorazioni su materiali quali vetro, legno e pietra: i componenti sono meglio conosciuti con il nome di elettromandrini e saranno i prodotti prin-cipalmente analizzati dal documento di tesi.
Il percorso perseguito dall’Azienda è stato quello di una costruzione di un Sistema di Gestione per la qualità basato su elevati standard internazionali, considerando fondamentali valori quali il cliente, lo sviluppo delle persone e la creazione del valore. Oltre ciò l’Azienda garantisce che il prodotto finito sia qualitativamente in linea con le specifiche tecniche e di prodotto, strutturando al suo interno un sistema di controlli all’avanguardia a vari livelli e rigorosi test di affidabilità simulando le peggiori condizioni di lavoro; in questo modo viene assicurata la qualità dei componenti e l’aspettativa del cliente, anche con l’aiuto di personale esperto di qualità, che ha il compito ed il dovere di far rispettare tutti gli standard aziendali per la creazione di un prodotto finale d’eccellenza.
L’azienda protagonista della tesi ha come obiettivo prossimo la creazione di strumenti di analisi e di reportistica avanzata che tengano traccia dei vari processi di business interni e che vadano a costru-ire una rete interconnessa tra tali processi e processi esterni, sfruttando tutte le potenzialità e benefici derivanti da una solida comunicazione.
L’obiettivo perseguito dall’azienda è quindi volto alla sostituzione di sistemi di reporting ed analisi obsoleti e costruiti manualmente attraverso fogli di lavoro Excel, dunque eccessivo lavoro manuale che occuperebbe tempo e risorse, con pagine di dashboarding più efficaci ed intuitive, dotate di meccanismi
di adattamento real-time. Il processo di automatizzazione e digitalizzazione descritto può essere salvato e potrebbe risultare trasversale ed utilizzato da altre funzioni aziendali.
L’azienda operatrice e responsabile del corretto svolgimento dell’intero lavoro è Iconsulting S.p.A., avente sede a Bologna ed operante nell’ambito della consulenza informatica, il cui business principale è la progettazione di sistemi di Data Warehouse e Business Intelligence, essenziali per la creazione delle analisi e delle pagine di reportistica. In quest’ambito Iconsulting è un’azienda in continua crescita e che investe in forza lavoro giovane ed in tecnologie all’avanguardia, in modo tale da essere sempre aggior-nata ed al passo delle altre concorrenti e divenendo un punto di riferimento nel mercato della Business Intelligence.
4.2
Analisi dei Requisiti
In questo paragrafo sono raccolte le esigenze espresse dai key users durante la fase di intervista, di notevole importanza per il progetto in sé in quanto definiscono quelli che sono gli obiettivi attesi e le modalità con le quali si intende procedere. Il progetto descritto nel documento di tesi è chiamato “Logistica Inversa” e si pone i seguenti obiettivi:
• Fornire una reportistica elettronica che consenta il monitoraggio dei dati dei vari flussi informativi relativi alla Logistica Inversa, adoperabile dalla Direzione di Gruppo;
• Effettuare il passaggio da un sistema di reporting accentrato nella figura del controller ad uno molto più diretto ed accessibile anche da parte dei Product Manager;
• Monitorare l’intero processo della Logistica Inversa al fine di mostrare il dato di sintesi e di dettaglio dei KPIs delle diverse aree di analisi;
• Evidenziare gli indicatori di performance d’interesse per l’azienda, oltre che esporre nel dettaglio informazioni relative ai diversi livelli di analisi.
Il fine ultimo è quello dunque di consentire una gestione integrata dei flussi di dati inerenti alla fun-zione Logistica Inversa, garantendo agli utenti l’accesso alle varie informazioni ed ai KPI di analisi tramite reportistica di dettaglio e dashboards di sintesi che siano in grado di mostrare i risultati ottenuti.
Le aree di analisi d’interesse per il progetto "Logistica Inversa" rappresentano i distinti settori di busi-ness aziendali che analizzano indicatori di performance relativi per ognuno di essi. Le aree in questione che l’Azienda ha manifestato di automatizzare e monitorare sono le seguenti:
• Affidabilità • Costi in Garanzia
• Livelli di Servizio
La prima area che la Logistica Inversa andrà ad analizzare sarà quella dell’Affidabilità, la quale si focalizza sul calcolo di KPIs che hanno lo scopo di misurare l’affidabilità dei componenti prodotti dall’azienda. La seconda area dei Costi in Garanzia andrà a studiare tutti i costi sostenuti dall’Azienda derivanti da una garanzia dei prodotti rientrati a seguito di un malfunzionamento. L’area dei Livelli di
Servizioinfine analizzerà il livello di servizio generale dell’Azienda fornito verso i clienti finali, dove si assume che la stessa soddisfa un certo livello di servizio verso il cliente se risolve il problema o ripara un componente entro certe tempistiche prestabilite.
i
Il lavoro di tesi descritto presenterà esclusivamente la parte relativa all’area dell’Affidabilità, in quanto è stato ritenuto che la stessa sia in grado di descrivere in maniera esaustiva l’intero processo di Business Intelligence, che parte quindi dall’analisi dei requisiti alla creazione finale di dashboards di reporting. Le successive aree di analisi saranno quindi inserite all’interno del paragrafo che tratta gli Sviluppi futuri del progetto.Le informazioni e i dati relativi a queste tre aree erano gestite manualmente a partire da diverse sorgenti, quali Excel ed Oracle EBS, ed elaborate per la stesura di report utilizzando fogli di lavoro Excel. Tali report venivano successivamente inviati ai key users tramite messaggi di posta elettronica.
Sono da tenere in considerazione alcuni vincoli posti da diversi fattori:
• Non tutte le filiali dell’Azienda salvano le informazioni allo stesso modo;
• Molti processi non sono automatizzati, rendendo quindi necessario lo sviluppo di sistemi informa-tivi che permettano tale automatizzazione.
In riferimento al primo punto, la totalità dei dati aziendali disponibili non è presente in un’unica “struttura”, ma proviene da più fonti e necessita dunque di essere uniformata. Dal punto di vista architet-turale, il fine ultimo è quello di far convergere tutti i dati verso un’unica struttura, con lo scopo di armo-nizzare in maniera corretta le informazioni gestite separatamente dalle tre aree sopra elencate. Risulta dunque di fondamentale importanza individuare le procedure con le quali organizzare ed in seguito in-tegrare le informazioni in un unico sistema, garantendo una struttura dati trasversale per l’Azienda e per
tutte le filiali della stessa.
La totalità dei dati aziendali provengono da più flussi informativi, i quali interessano le tre aree descritte in precedenza. I flussi informativi in questione sono i seguenti:
• Riparazioni • Interventi Tecnici • Ricambi (o Spare Parts) • Vendite
• Riaddebiti per Assistenza Tecnica
Il flusso informativo delle Riparazioni focalizza la propria attenzione sulle riparazioni dei prodotti dell’Azienda a seguito di una segnalazione da parte del cliente.
Per quanto riguarda gli Interventi Tecnici le informazioni gestite fanno riferimento agli interventi svolti dai tecnici dell’Azienda o dalle filiali presso la sede del cliente che ha richiesto assistenza.
Il flusso relativo ai Ricambi riguarda la gestione dei prodotti che vengono sostituiti da parte del-l’Azienda.
Il flusso delle Vendite contiene informazioni relative alle vendite dei vari prodotti e componenti. Il flusso dei Riaddebiti per Assistenza Tecnica infine analizza tutti quei casi in cui vi sono clienti del-l’Azienda che effettuano ulteriori interventi sui loro clienti finali, addebitando in seguito i costi di tale intervento direttamente all’Azienda.
i
Per quanto riguarda l’area dell’Affidabilità gli unici flussi di dati che ricadono all’interno della stessa sono Ri-parazioni ed Interventi Tecnici, mentre le altre aree di analisi utilizzeranno anche gli altri flussi informativi.Remark. Tutti i flussi informativi descritti contengono dati utili ai fini dell’analisi, ma che devono confluire
in modo conforme all’interno delle tre aree di analisi, affinché report e analisi risultino veritiere.
Di seguito sono elencati i concetti e relativi acronimi di rilevante importanza per la Logistica Inversa, e che saranno presenti per tutto il resto del documento:
• Service Request (SR): richiesta di riparazione creata dal frontline in seguito ad una segnalazione da parte del cliente;
• Return Merchandise Authorization (RMA): autorizzazione comunicata dall’azienda preposta alla riparazione o sostituzione di un prodotto in periodo di garanzia;
• Ordine di Lavoro (OdL): documento scritto che contiene le operazioni da svolgere per un deter-minato lavoro. È possibile suddividerlo ulteriormente in:
• OdL di Smontaggio: documento che registra le operazioni effettuate durante le procedure di
smontaggio per l’analisi del problema;
• OdL di Montaggio: documento che registra le operazioni effettuate durante le procedure di
montaggio per la riparazione del prodotto;
• Depot Repair (DR): documento tecnico che descrive le operazioni effettuate sul prodotto da ri-parare. Esiste dunque solo in caso di riparazione di un componente, mentre un intervento tecnico non presenta tale documento.
Come convenzione saranno utilizzati agli acronimi appena citati per riferirsi ai componenti interes-sati.
I componenti in questione contengono le informazioni necessarie per la determinazione delle logiche relative ai KPIs per ogni area d’analisi; tuttavia a seconda che si tratta dell’Azienda o della filiale della stessa, si ha una gestione differente dei dati.
Inoltre prima di dettagliare maggiormente i concetti appena descritti occorre evidenziare alcune specifiche fondamentali al fine della creazione delle logiche:
• Una SR può contenere più DR: si parla dunque di una relazione 1:N;
• Ogni SR contiene al suo interno il seriale dell’articolo a cui fa riferimento;
• Il seriale presente sul DR è uguale al seriale presente all’interno della SR.
4.2.1
Riparazioni
Il flusso informativo delle Riparazioni ha lo scopo di monitorare il processo che parte dalla segnalazione del cliente, fino alla riparazione e spedizione del prodotto riparato. I dati relativi a tale flusso sono situati su:
• Oracle EBSnel caso di informazioni salvate dall’Azienda;
Le informazioni provenienti dalla sede italiana dell’Azienda sono interamente gestite attraverso Ora-cle EBS e recuperate attraverso le tabelle predisposte dalla committenza in fase di analisi dei requisiti. Nel dettaglio i dati che sono utilizzati per il calcolo dei KPIs obiettivo sono presenti all’interno delle tabelle che riguardano Service Request e Depot Repair.
4.2.2
Interventi Tecnici
Il flusso informativo relativo agli Interventi Tecnici raccoglie tutti i casi in cui i tecnici dell’Azienda svol-gono delle operazioni di riparazione presso il cliente che ha inviato una richiesta di assistenza. Così come per le Riparazioni, un intervento tecnico può essere:
• In garanzia, e quindi risultare gratuito per il cliente richiedente assistenza;
• Non in garanzia, impostando quindi un prezzo per il cliente basato su costi di manodopera e materiali impiegati.
Anche per quanto riguarda gli interventi tecnici, ogni qualvolta viene richiesta l’assistenza di un tecnico viene creata una nuova Service Request per la sede italiana, mentre non è gestita la creazione di SR per le filiali estere, in quanto non dispongono ad oggi del sistema gestionale Oracle EBS.
N.B. Ogni richiesta di intervento presenta la medesima struttura della SR in caso di riparazione del
prodotto, con la presenza di un discriminante che permette di identificare la richiesta stessa come
Riparazione o Intervento Tecnico.
Anche per il flusso relativo agli Interventi Tecnici vi è una differente gestione delle informazioni da parte della sede italiana e delle filiali:
• Per la sede italiana le informazioni sugli interventi tecnici sono registrate sia su Oracle EBS che su fogli di lavoro Excel.
• Per quanto riguarda le filiali dell’Azienda, come per il flusso delle Riparazioni, tutti i dati relativi gli interventi tecnici vengono registrati in un file Excel per poi essere utilizzati in seguito per la stesura di report.
Anche in questo caso l’obiettivo fondamentale sarà la creazione di processi efficienti in grado di uniformare i dati provenienti dalle differenti sorgenti, al fine di avere una base dati omogenea sulla quale fare affidamento per la costruzione di report.
È necessario precisare che nel caso in cui un intervento da parte di un tecnico non riesca a risolvere il problema per il quale è stata presentata la richiesta, risulterà opportuno considerare il problema non più appartenente al flusso degli Interventi Tecnici ma a quello delle Riparazioni.
4.2.3
Ricambi (Spare Parts)
Il flusso relativo ai Ricambi (o Spare Parts) prende in considerazione i casi in cui l’Azienda decide di sostituire il prodotto a seguito di un malfunzionamento segnalato dal cliente. In questo caso solamente la sede italiana tiene traccia delle informazioni riguardanti le sostituzioni in garanzia.
Risulta necessario specificare due tipologie del flusso in analisi:
• Sostituzioni in Garanzia (SG): in questa prima tipologia il prodotto da sostituire rientra in Azienda, ma viene spedito un nuovo prodotto con diverso seriale dall’Azienda al cliente che ne ha fatto richiesta; tutto ciò accade per prodotti o componenti di piccole dimensioni per i quali non è economicamente conveniente spedirli in sede. Per il componente in entrata viene creato un DR associato, attraverso il quale è possibile verificare la causa del malfunzionamento. Possono verificarsi due diversi scenari:
• Nel primo scenario la causa del problema è relativa ad un difetto di fabbrica direttamente
imputabileall’Azienda stessa; in questo caso al cliente non sarà addebitato alcun costo, mentre l’Azienda dovrà pagare la somma dei costi derivanti da materiali e manodopera;
• Nel secondo scenario invece viene riscontrato un malfunzionamento del prodotto imputabile
al cliente fruitore che, per negligenza o quant’altro, ne ha leso una o più funzionalità; in tal caso la responsabilità ricade sul cliente e l’Azienda invia una fattura allo stesso.
• Garanzia Ricambi (GR): in questo secondo scenario non è previsto il rientro del pezzo nel-l’Azienda, quindi non risulta necessaria la creazione di un DR associato.
4.2.4
Vendite
Il flusso relativo alle vendite viene utilizzato sia per le analisi riguardanti l’area dell’Affidabilità che per l’area dei Costi in Garanzia.
4.2.5
Riaddebiti per Assistenza Tecnica
L’ultimo flusso informativo relativo ai Riaddebiti per Assistenza Tecnica, come già accennato, prende in considerazione tutti i casi in cui un cliente dell’Azienda effettua un intervento su un suo cliente, addebi-tando successivamente il costo dell’intervento direttamente all’Azienda.
4.2.6
Matrice Flussi - Sorgenti
In questa sezione sono mostrate le tabelle relative alla sede italiana e le filiali estere dell’Azienda, che mostrano in maniera sintetica la suddivisione dei dati tra Oracle EBS ed Excel per l’area dell’Affidabilità:
Sede Italia EBS Excel Riparazioni Ø Interventi Tecnici Ø Ø Filiali Estere EBS Excel Riparazioni Ø Interventi Tecnici Ø
4.2.7
Affidabilità: KPIs
Un altro step fondamentale nella fase di analisi è la definizione dei KPIs in grado di mostrare il dato di sintesi rispetto a quello che sono i processi di business attuati dall’Azienda; attraverso gli indicatori di performance i key users potranno essere al corrente dell’andamento dei processi di creazione del valore e, sulla base di questi, prendere decisioni differenti in grado di impattare positivamente sull’Azienda.
Nello specifico i KPIs richiesti in fase di analisi sono:
• Tasso di Guasto • Issue Quantity
• Mean Time To Failure(MTTF)
Tali indicatori garantiscono una visione completa riguardo l’area dell’Affidabilità, garantendo tutte le informazioni necessarie per identificare correttamente eventuali problematiche all’interno del processo di business. Nei paragrafi successivi viene data una descrizione di ogni KPI, fornendo a corredo di ognuno peculiarità e formule di calcolo.
4.2.7.1 Tasso di Guasto
Il Tasso di Guasto fornisce il rapporto di non conformità dei componenti per anno di produzione e le quantità vendute nello stesso anno. In formula quindi il tasso di guasto sarà pari a:
Numero non conformità per anno di produzione Quantità vendute nello stesso anno
Per il calcolo delle non conformità, e quindi per ottenere un tasso di guasto attendibile, vi è la necessità di far confluire tutti i dati provenienti dai flussi informativi relativi a Riparazioni, Interventi Tecnici e Vendite. Nel dettaglio il numero di riparazioni ed interventi tecnici contribuisce ad ottenere il numeratore del tasso di guasto, mentre la quantità venduta permette di ottenere il denominatore della formula.
4.2.7.2 Issue Quantity
La quantità di riparazioni ed interventi tecnici (o Issue Quantity) fornisce un’indicazione riguardo al numero di riparazioni ed interventi tecnici effettuati dall’Azienda. In sostanza tale indicatore rappresenta il numeratore del tasso di guasto, e viene ottenuto contando la quantità di riparazioni/interventi tecnici eseguiti nel periodo d’analisi designato.
4.2.7.3 Mean Time To Failure(MTTF)
L’ultimo KPI riguardante l’area dell’Affidabilità si pone come obiettivo quello di mettere in luce il tempo medio di vita dei prodotti dell’Azienda. Il Mean Time To Failure (MTTF o Life Duration) prende in analisi
esclusivamenteil flusso informativo delle riparazioni e viene calcolato secondo la seguente formula:
M T T F=
Pn
i=1 data guastoi− data ultima spedizionei
n
dove i indica lo specifico componente ed n indica il numero totale dei prodotti oggetto d’analisi. Tale indicatore può essere espresso come il periodo medio che intercorre tra la data di vendita del prodotto (quindi la data in cui viene effettivamente spedito al cliente) e la data in cui è stato riscontrato un malfunzionamento (data in cui è avvenuto il sinistro), per ogni prodotto.
4.2.8
Dashboard finale
La committenza ha infine fornito i mockup delle analisi che andranno a comporre la pagina di reportistica finale, dai quali partire per ottenere dashboards il più possibile vicine ai desiderata dell’Azienda. In questo modo i mockup garantiscono che il risultato finale sia coerente con quanto definito inizialmente dall’azienda committente.
La dashboard finale dunque sarà composta essenzialmente da due pagine:
• Nella prima pagina saranno mostrati i risultati dei KPIs descritti in precedenza attraverso piastrelle di performance, grafici a barre e a torta, permettendo di filtrare e modificare le analisi attraverso i prompts presenti nella parte alta della pagina (Figura 4.1(a)):
