Dipartimento di Informatica
Corso di Laurea Magistrale in Informatica per l'economia e per
l'azienda
(Business Informatics)
TESI DI LAUREA
LA BUSINESS INTELLIGENCE A SUPPORTO DEL
PROCESSO ACQUISTI NEL SETTORE AUTOMOTIVE
RELATORI
Prof. Rossano VENTURINI
Dott. Giuliano Formato
CANDIDATO
Andrea Buccarella
Indice
INTRODUZIONE ... 1
CONTENUTO DELLA TESI ... 4
CAPITOLO 2 PRESENTAZIONE DELL’AMBIENTE ... 5
2.1 AZIENDA COMMITTENTE ED AZIENDA ESECUTRICE ... 5
2.2 CASO DI STUDIO ... 6
2.3 LA BUSINESS INTELLIGENCE ... 7
2.3.1 STORIA DELLA BUSINESS INTELLIGENCE ... 7
2.3.2 CARATTERISTICHE DELLA BUSINESS INTELLIGENCE ... 8
2.4 STATO DELL’ARTE ... 10
2.4.1 IL MAGIC QUADRANT DI GARTNER ... 10
2.4.2 ATTORI PRINCIPALI ... 12
CAPITOLO 3 PROGETTAZIONE DEL DW ... 17
3.1 INTRODUZIONE ... 17
3.2 ANALISI DEI REQUISITI ... 17
3.3 PROGETTAZIONE CONCETTUALE... 18
3.3 PROGETTAZIONE LOGICA ... 20
3.4 PROGETTAZIONE DELL’ALIMENTAZIONE ... 23
3.5 PROGETTAZIONE FISICA ... 25
CAPITOLO 4 CASO DI STUDIO ... 26
4.1 CASO DI STUDIO: BUSINESS INTELLIGENCE PER REPARTO ACQUISTI ... 26
4.2 ANALISI DEI REQUISITI ... 26
4.2.1 KPI ... 27
4.2.2 TOOL DATA ENTRY ... 29
4.2.3 TOOL DATA VISUALIZATION ... 30
4.3 SORGENTI INFORMATIVE: APEX ... 31
4.3.1 PREPARAZIONE DELL’AMBIENTE ... 31
4.3.2 ORACLE APEX APPLICATIONS ... 36
4.4.2 ETL DIMENSIONI ... 80
4.4.3 ETL KPI ... 84
4.5 OBIEE MODEL ... 94
4.5.1 ARCHITETTURA E AMBIENTE OBIEE ... 94
4.5.2 BUSINESS MODEL ... 97 4.6 DASHBOARD ... 120 5.CONCLUSIONI ... 130 APPENDICE ... 133 TRIGGER APEX ... 133 JAVASCRIPT ... 138 BIBLIOGRAFIA ... 144
1
INTRODUZIONE
Negli ultimi anni il settore industriale sta affrontando un periodo di profondo cambiamento che sta rivoluzionando il settore e ha spinto molti esperti a parlare di terza rivoluzione industriale. Sempre più spesso infatti si sente parlare del termine “Industria 4.0” per indicare un insieme di nuove tecnologie, nuovi fattori produttivi e nuove organizzazioni che stanno modificando la produzione industriale, provocando effetti rilevanti anche sul mercato del lavoro e sull’organizzazione sociale.
Cosa significa esattamente “Industria 4.0”?
Il termine indica lo stadio che raggiungeranno le imprese, dopo aver adottato un insieme di tecniche e tecnologie, che porteranno le fabbriche ad essere sempre più “Intelligenti” e “Smart”. A conferma della sempre maggiore importanza che viene data all’argomento, è fondamentale evidenziare che numerose sono le iniziative adottate dai diversi Stati affinché tale processo possa coinvolgere un numero sempre maggiore di Imprese. Possiamo citare il programma americano “Industrial Internet”, quello tedesco “Industrie 4.0” o quello italiano “Fabbrica intelligente” per capire che, anche se in maniera differente l’una dall’altra, tutte le maggiori potenze economiche stanno mettendo in atto una serie di iniziative volte a favorire la crescita di questo paradigma. L’obiettivo ultimo dell’industria 4.0 è quello di favorire l’interazione tra uomo e macchina, in modo tale da avere dei miglioramenti sia in termini di efficienza che in termini di risparmio dei costi, a livello di processo produttivo e a livello di distribuzione.
Le tecnologie che porteranno le Fabbriche a raggiungere questo nuovo stadio, possono essere raggruppate in sei dimensioni distinte, sotto elencate e brevemente analizzati
• Internet Of Things (IOT) • Big Data
• Additive Manufacturing • Realtà aumentata
• Robot di nuova generazione • Digital Manufacturing
2
Internet of Things
Con il termine IOT si indica la rete di software, sensori e altri dispositivi tecnologici che hanno lo scopo di consentire l’interfaccia tra mondo fisico e digitale e di collezionare e scambiare dati. Il fine ultimo è di ottenere una maggiore personalizzazione dei prodotti, una maggiore flessibilità e di avere un’interazione tra mercato e supply chain in tempo reale. Tutto ciò comporta delle modifiche importanti alle strutture degli impianti, ai volumi di produzione e alla gamma di prodotti. Per il consumatore finale, l’IOT è l’aspetto di maggiore fascino dell’industria 4.0, in quanto permetterà anche agli oggetti e non più solo ai pc, di essere connessi in rete, consentendo così, ad esempio, di interagire con elettrodomestici ed automobili. Il risultato di tutto ciò è che l’eccessiva mole di dati prodotti, rende inadeguati i tradizionali data warehouse che così devono lasciare il posto alle tecnologie dei Big Data.
Big Data
Con il termine Big Data vengono classificati quei dati che, a causa della loro complessità e della loro mole sono difficilmente utilizzabili attraverso le metodologie classiche come i data warehouse. All’interno delle industrie digitali infatti, il processo produttivo può produrre milioni di dati grezzi che senza una profonda analisi dovrebbero essere scartati in quanto non produrrebbero dei risultati utili al fine di migliorare l’efficienza del ciclo produttivo. Occorrono quindi strumenti più complessi con una maggiore potenza di calcolo, con una maggiore velocità e con un’elevata capacità di archiviazione. Tali strumenti, utili per la raccolta e l’elaborazione dei dati sono identificati con il termine Big Data.
Additive Manufacturing
Letteralmente la parola additive manufacturing indica la produzione per aggiunta di materiale, che si contrappone al classico modello di produzione, in cui invece, si lavora per sottrazione di materiale da blocchi di metallo. Con questo termine viene indicato il modo in cui vengono convertiti i modelli 3D, prodotti attraverso software come CAD, in oggetti fisici. Il tutto è reso possibile attraverso l’uso di stampanti 3D che fondono e aggregano strati di polveri, andando a creare il prodotto finale. Questo tipo di processo non è del tutto nuovo nello scenario industriale, tuttavia, mentre in passato era utilizzato per la creazione di prototipi, con la diffusione su larga scala, potrebbe portare alla creazione di un nuovo
3
paradigma. Si passerebbe da una produzione di massa di prodotti standardizzati ad una di prodotti personalizzati. La linea produttiva potrebbe essere utilizzata per produzioni differenti e si potrebbe rispondere più velocemente ai cambiamenti del mercato. Inoltre, si realizzerebbero prodotti con forme che, con i vecchi macchinari di produzione, sarebbe impossibile ottenere.
Realtà aumentata
Come per gli IOT, il termine realtà aumentata indica un insieme di tecnologie indossabili, che permettono di incrementare le informazioni a disposizione dell’utente all’interno di ambienti reali. A differenza delle tecnologie elencate sino ad ora, la realtà aumentata ad oggi è quella che ha avuto meno applicazione nelle realtà industriali se non per scopi sperimentali.
Robot di nuova generazione
I robot rappresentano una delle innovazioni tecnologiche che ha riscosso maggiore credito nell’industria 4.0. Grazie ai miglioramenti ottenuti nel campo della robotica infatti, le macchine vengono addestrate per operare sia su semplici operazioni che su operazioni più complesse, agevolando così il processo produttivo. Sono considerati dei veri e propri collaboratori che lavorano in autonomia ed in sicurezza con gli operai, tanto che hanno permesso di realizzare nuovi modelli di organizzazione del lavoro in fabbrica.
Digital Manufacturing
Con il termine Digital Manufacturig infine, viene indicato un processo produttivo all’interno del quale troviamo la coesistenza delle diverse tecnologie analizzate sino ad ora. Il processo produttivo viene completamente simulato prima che venga messo in atto, in modo tale da verificare la possibilità o meno di ottenere dei miglioramenti in termini di efficienza. Il Digital Manufacturing semplifica la comunicazione delle informazioni tra le diverse aree e consente di ottenere dei feedback in tempo reale dalla produzione, permettendo così di reimmettere le informazioni raccolte all’interno della progettazione che, in tal modo, risulterà sempre aggiornata sulle dinamiche interne alla fabbrica.
Studi da parte di agenzie di consulenza come la McKinsey & Company affermano che la combinazione delle tecnologie sopra descritte, associate ai programmi lanciati dalle diverse
4
Nazioni, hanno portato le imprese che hanno focalizzato i propri investimenti nell’innovazione, ad ottenere dei grossi benefici sia in termini di riduzione dei costi che in termini di miglioramento dell’efficienza in molti settori lungo tutta la catena di valore.
CONTENUTO DELLA TESI
Il lavoro svolto in questa tesi documenta il progetto realizzato presso ICONSULSTING S.p.A., azienda bolognese specializzata nella progettazione di sistemi best-in-class di Data Warehouse, Business Intelligence, Performance Management e Big Data Analytics, per una nota azienda leader del settore automotive, che all’interno dell’elaborato sarà chiamata con il nome “Tyre”.
L’obiettivo finale dell’elaborato è quello di fornire un sistema in grado di analizzare sia il dato di sintesi sia il dato di dettaglio, relativo al processo acquisti cross settore merceologico. Di seguito viene riportata sinteticamente la struttura della tesi, indicando il contenuto di ogni capitolo.
Nel Capitolo 2 viene rappresentato il profilo sia dell’azienda committente che dell’azienda esecutrice, viene introdotto il caso di studio, viene descritta la Business Intelligence e viene indicato lo stato dell’arte di ciò che esiste per la risoluzione del problema affrontato.
Nel Capitolo 3 vengono introdotti i passaggi chiave utili per la realizzazione del progetto commissionato. Tali passaggi poi, verranno utilizzati nel capitolo successivo per descrivere le diverse fasi del lavoro svolto.
Nel Capitolo 4 viene analizzato dettagliatamente il caso di studio, riguardante l’utilizzo della BI tradizionale per il progetto Cockpit e ne viene descritta la fase di progettazione, di sviluppo a la fase finale di reportistica.
Nella parte conclusiva infine, vengono descritti gli obiettivi raggiunti, le conclusioni derivanti dal lavoro svolto e i possibili sviluppi futuri.
5
CAPITOLO 2 PRESENTAZIONE DELL’AMBIENTE
2.1 AZIENDA COMMITTENTE ED AZIENDA ESECUTRICE
Il lavoro descritto in questa tesi è stato commissionato da una nota azienda operante nel settore dell’automotive che nel prosieguo verrà indicata con il nome ‘Tyre’. L’azienda in questione da anni ha intrapreso la strada verso la digitalizzazione con lo scopo di diventare una data driven company e ha creato al proprio interno una funzione, che non si configura come funzione di staff, come potrebbe essere l’IT, ma si affianca a tutte le altre funzioni di core business aziendali. Con questa ideologia e con una vera e propria funziona a supporto, la Tyre ha investito e continua a farlo, risorse e competenze in molti concetti dell’industria 4.0 sopra descritti. Il concetto di Smart Manufacturing per l’azienda committente si
concretizza con un concetto di Supply chain più ampio, che parte dalla fornitura, con tutto ciò che concerne la valutazione dei fornitori,valuta il processo produttivo, analizzando tutte le dinamiche che riguardano il magazzino, la produzione e la logistica, e che va a mappare alla perfezione il cliente finale.
L’azienda responsabile del progetto descritto in questo lavoro è stato svolto presso Iconsulting S.p.a, azienda bolognese di consulenza informatica, focalizzata nella progettazione e realizzazione di sistemi di data Warehouse, Business Intelligence e Corporate Performance Management. Un’azienda in continua crescita, nata da un gruppo di ricercatori del Cineca e che oggi è divenuta un punto di riferimento nel mercato della BI.
6
2.2 CASO DI STUDIO
Il progetto descritto è stato svolto attraverso attività di Team e con una metodologia Agile ed in particolare la metodologia SCRUM.
Questo framework di processo, come visibile dall’immagine sopra rappresentata si
compone di diversi attori con compiti specifici e consente di risolvere problemi complessi di tipo adattivo e di rilasciare prodotti in modo efficace e creativo dal più alto valore possibile. Questa metodologia si basa sul concetto di conoscenza e sul fatto che questa sia fondamentale nel prendere le decisioni e utilizza un metodo iterativo ed un approccio incrementale per ottimizzare il controllo del rischio. Il progetto descritto ha seguito questo tipo di approccio, producendo risultati settimanali, che sono stati oggetto di validazione e approvazione da parte dell’azienda committente. Il progetto commissionato dall’azienda committente ha lo scopo di fornire un sistema in grado di dare supporto alle strategie in termini di analisi per la funzione acquisti di gruppo. In particolare sono stati individuati una serie di Key Performance Indicator che consentissero ai responsabili del settore di poter effettuare delle valutazioni oggettive in merito all’andamento della propria area. In dettaglio, lo scopo ultimo del progetto è di fornire un sistema in grado di analizzare sia il dato di sintesi sia il dato di dettaglio, relativo al processo acquisti cross settore
merceologico. E’ stato quindi richiesto da una parte, la creazione di un cruscotto che
7
permettesse l’inserimento dei dati raccolti dagli utenti e dall’altra, la realizzazione di un’applicazione mobile che consentisse l’esplorazione dei dati raccolti. Questo lavoro quindi, ha tutte le componenti che permettono di classificarlo come un vero e proprio progetto di Business Intelligence. Analizzerò brevemente nel paragrafo successivo il significato del termine e lo stato dell’arte della Business Intelligence ai nostri giorni.
2.3 LA BUSINESS INTELLIGENCE
2.3.1 STORIA DELLA BUSINESS INTELLIGENCE
Il termine “Business Intelligence” venne utilizzato per la prima volta in un’opera di
Richard Millar Devens del 1865, intitolata “Cyclopaedia of Commercial and Business Anecdotes”, in cui l’autore utilizzò il termine per descrivere il modo attraverso il quale un mercante inglese di nome Henry Furnese riuscì ad ottenere successo. Egli era in grado di avere informazioni in merito al mercato e alle vicende politiche prima dei concorrenti e proprio su tale fattore fondò il proprio vantaggio competitivo. Tuttavia fu nel 1958 che, grazie ad un articolo pubblicato da Hans Peter Luhn, dipendente IBM, il vero potenziale della BI venne riconosciuto. Lui, ritenuto il padre della Business Intelligence, la descrisse come un sistema automatico ideato affinché venissero diffuse le informazioni all’interno delle diverse aree di un’organizzazione, sia che essa sia di tipo di industriale che di tipo governativo. Ciononostante, a causa dell’arretratezza della tecnologia, questa nuova disciplina non si diffuse sino a quando negli anni 80 non si ebbe la propagazione dei personal computer, che diedero alle aziende un’alternativa alla memorizzazione dei dati su carta, e la proliferazione di sistemi di archiviazione, come i Floppy disk e altri strumenti, che rappresentarono le prime forme di database. Inoltre in quel periodo iniziarono a svilupparsi i primi software di BI che a loro volta portarono alla creazione dei primi Data Warehouse, dei tool di ETL (Extract, Transform, and Load) e di software OLAP (Online Analytical Processing). Questa fase della Business Intelligence viene definita come
Business Intelligence 1.0. Un periodo in cui parlare di BI significava produrre informazioni e report e fare in modo che questi fossero visualizzabili dai board aziendali. Tuttavia vi erano sempre due problematiche legate alla tecnologia che non consentivano l’espansione della BI. Il tempo e la complessità. I progetti erano ancora presi in carico dall’IT e ciò ad indicare che gli utenti non erano ancora in grado di utilizzare i tool esistenti ed inoltre i dati memorizzati in silos rendevano lento il processo di produzione della reportistica. Con il passare degli anni però le tecnologie si sono evolute. I processi real-time consentirono di
8
avere le informazioni così come erano presenti nel Data Warehouse e permisero alle aziende di poter prendere decisioni basandosi sui dati più recenti disponibili. Inoltre numerosi tool iniziarono ad includere accessi self-service per gli utenti meno esperti, portando così tale tecnologia alla portata di tutti. Così, in poco tempo la BI è divenuta di vitale importanza per le aziende. Non solo per ottenere un vantaggio competitivo nei confronti dei concorrenti, ma è divenuta di vitale importanza per la sopravvivenza in un mercato in cui i dati continuano a rivestire un ruolo sempre più importante.
2.3.2 CARATTERISTICHE DELLA BUSINESS
INTELLIGENCE
L’architettura della Business Intelligence è formata da tre stadi principali:
FONTI DATI
Il punto di partenza sono le fonti. I dati elementari provengono da diverse sorgenti come file Excel, file Xml, database ecc. Di norma queste informazioni provengono
principalmente dai sistemi operazionali, tuttavia è possibile reperire dati anche da fonti esterne e non strutturate come ad esempio le email. Raccolte le informazioni, il passaggio successivo, di vitale importanza, è la fase di staging, in cui i dati vengono ripuliti e riportati tutti sotto un unico standard per poi essere caricati nel DW. Qualora i dati fossero già presenti nel DWH è possibile, da una parte procedere in modalità full refresh ed inserire tutti i dati nelle tabelle, dall’altra proseguire in modalità incremental load aggiornando in tabella solo i dati modificati. Queste operazioni sono racchiuse dentro la
9
fase che nello schema viene indicata con l’acronimo ETL (Extract, Transform, Load) tramite l’ausilio di tool dedicati.
DATA WAREHOUSE E DATA MART
Il secondo livello dell’architettura è rappresentato dal DWH. A differenza dei classici database relazionali, all’interno del DWH i dati sono memorizzati seguendo il modello dimensionale e l’architettura è strutturata in maniera tale da garantire che sia:
• Integrato: contiene le informazioni provenienti da diverse fonti in un unico ambiente di analisi.
• Subject-oriented: i dati sono organizzati per agevolarne l’utilizzo da parte
dell’utente. L’obiettivo principale è quello di favorire la produzione di informazioni e non di diminuire la ridondanza.
• Non volatile: i dati sono caricati in sola lettura e non possono essere modificati. • Variabile nel tempo: i dati vengono storicizzati. Ciò permette di fornire un quadro
storico del fenomeno analizzato in quanto i vecchi dati vengono preservati all’interno del DWH.
Dal DWH è possibile procedere verso i Data Mart che altro non sono che un estratto dei primi. Al loro interno i dati fanno riferimento esclusivamente ad un’area aziendale specifica (Acquisti, Vendite, ecc) e ciò garantisce migliori performance, maggiore personalizzazione e un aumento della sicurezza.
Questa prima fase può essere definita come fase di Back-End a cui segue una fase di Front-End e all’interno della quale troviamo la Business Intelligence che rappresenta il terzo stadio dell’architettura.
METODOLOGIE DI BUSINESS INTELLIGENCE
In questa fase è possibile analizzare il dato in base al sistema di analisi adottato. Le principali applicazioni di Business Intelligence che possono essere utilizzate sono:
1) Reporting: il dato viene rappresentato mediante l’utilizzo di grafici.
2) OLAP: acronimo di On Line Analytical Processing. I dati vengono memorizzati su cubi che ne permettono l’esplorazione su diverse dimensioni.
3) Data Mining: tramite l’utilizzo di tecniche matematiche e statistiche vengono fatte delle previsioni basandosi sulle relazioni e le tendenze dei dati a disposizione.
10
4) Simulazione: Tecniche predittive basate sulle scelte degli utenti.
5) Dashboard: applicativi grafici che permettono all’utente di esplorare i dati in tempo reale con la possibilità di inserire allarmi grafici in caso di scostamenti
significativi. Di norma questo tipo di strumento è indirizzato ai vertici aziendali.
2.4 STATO DELL’ARTE
2.4.1 IL MAGIC QUADRANT DI GARTNER
Con l’esplosione del concetto di BI si è avuto un conseguente aumento degli strumenti e delle aziende software che investono nella creazione di tool dedicati. Numerose sono le aziende presenti sul mercato e la Gartner Inc, società americana che si occupa di
consulenza strategica e di ricerca e analisi nel campo dell’Information Technology, offre ai vari acquirenti la possibilità di ottenere una valutazione dei vari fornitori attraverso
l’utilizzo del Magic Quadrant. Questo grafico permette di visualizzare, monitorare e valutare il progresso e le posizioni delle aziende fornitrici di software per la BI all’interno del mercato tecnologico. Viene utilizzata una matrice bidimensionale per illustrare i punti di forza e le differenze tra le aziende e le dimensioni che costituiscono gli assi del grafico sono:
• Capacità di esecuzione: indica la capacità dell’azienda di rendere la propria visione una realtà sul mercato. Riguarda l’efficienza dell’azienda la sua capacità in tutte le attività post-vendita e la sua situazione finanziaria.
• Completezza della visione: indica la capacità dell’azienda di comprendere le esigenze degli acquirenti di avere una buona strategia di marketing e di avere uno sguardo rivolto alle innovazioni.
In base a questi criteri, il grafico viene diviso in 4 aree:
1) Niche Players: racchiude i fornitori che hanno avuto successo in un solo segmento del mercato e che hanno una capacità di innovazione ridotta. Di norma sono presenti in questo quadrante aziende di nuova costituzione.
2) Visionaries: racchiude i fornitori con una forte visione verso l’innovazione ma che non sono ancora in grado di offrire un servizio all’altezza dei grandi marchi. 3) Challenger: racchiude le aziende che hanno una forte capacità di esecuzione ma
11
con una maggiore predisposizione all’evoluzione della propria visione potrebbero diventare aziende Leader del mercato.
4) Leaders: racchiude i grandi marchi che hanno un grosso bacino di utenza e che sono in grado di influenzare il mercato, grazie alle proprie competenze e alla propria visone innovativa.
1)
E’ importante evidenziare che non sempre le aziende Leader sono la migliora soluzione per le esigenze dei clienti. Ogni quadrante contiene al suo interno aziende che hanno sia punti di forza che di debolezza e sono questi fattori che dovrebbero essere considerati nel valutare l’opzione migliore da adottare. L’information technology manager ha il compito di analizzare i bisogni aziendali ed in base ad essi individuare i tool che meglio possano rispondere alle proprie esigenze. Di seguito una rassegna dei maggiori attori sul mercato
12
per analizzare lo stato dell’arte della Business Intelligence e comprendere le diversità che vi sono tra i vari concorrenti presenti nel panorama mondiale.
2.4.2 ATTORI PRINCIPALI
All’interno del mercato della Business Intelligence, come è possibile vedere dal Magic Quadrant di Gartner, numerose sono le aziende che hanno investito le proprie risorse per produrre strumenti in grado di soddisfare le esigenze dei clienti. Di seguito sono riportate le aziende più importanti del panorama della BI con i rispettivi prodotti e i rispettivi punti di forza e di debolezza.
Oracle Corporation
La Oracle Corporation fu fondata nel 1977 da Larry Ellison e ha sede in California nella Silicon Valley. Il prodotto di punta della compagnia è Oracle, uno dei più diffusi DBMS al mondo che ad oggi è aggiornato alla versione Oracle Database 12c. In aggiunta alla struttura fisica Oracle ha sviluppato diversi prodotti sia per la parte di back-end e quindi la parte relativa al caricamento e l’integrazione dei dati, che per la parte di front-end e quindi la parte dedicata all’analisi e al reporting.
Lato back-end il prodotto di punta della Oracle Corporation è Oracle Data Integrator (ODI). Questo software, ad oggi uno dei più potenti sul mercato, consente di integrare dati provenienti da numerose sorgenti come Excel, CSV, Database MySQL, Microsoft Access, IBM DB2 e di salvarli nella struttura di destinazione chiamata target. Permette inoltre di utilizzare le stesse procedure per memorizzare i dati in strutture fisiche differenti. Il tutto grazie ad una potente interfaccia che, a causa delle numerose funzionalità implementate, è una delle più complesse e difficili da utilizzare nel campo dell’ETL. Il risultato delle operazioni eseguite con questo tool consentono di avere una struttura consistente e integrata su cui utilizzare i prodotti di BI.
Lato Front-end i prodotti di maggiore rilievo sono Oracle Business Intelligence e Oracle
Hyperion. Entrambi hanno una serie di componenti che consentono di fornire le
funzionalità che uno strumento di BI deve possedere come i report, le dashboard e le analisi sui dati. A livello di usabilità il primo risulta essere di più semplice utilizzo rispetto al secondo che tuttavia ha una predisposizione maggiore verso le analisi predittive.
13
IBM (International Business Machines Corporation) è una software house fondata nel 1911 a New York che produce hardware, software e servizi informatici che vanno a soddisfare tutte le esigenze di un’impresa. Dal punto di vista della Business Intelligence i prodotti di maggiore importanza sono IBM InfoSphere DataStage lato back-end e IBM Cognos lato front-end.
Il primo è un tool di ETL in grado di integrare dati provenienti da diversi sistemi e fornisce numerose funzionalità che rendono la piattaforma scalabile, user friendly, abilitata
all’utilizzo dei big data e supporta un numero elevato di fonti e destinazione dati. Lato Back-end il prodotto di rilievo abbiamo detto essere IBM Cognos 10. Questo è un tool che permette di adempiere a tutte le funzionalità di back-end che un’azienda possa richiedere. Numerosi prodotti sono contenuti all’interno della piattaforma e ciò consente alle aziende di poter utilizzare solo le funzionalità di cui si necessita, con la possibilità di continuare ad estendere il proprio pacchetto nel caso di nuove esigenze.
I prodotti IBM sono particolarmente difficili da utilizzare e per questo spesso rendono difficile per le aziende quantificare l’investimento per implementare una struttura basata su prodotti IBM.
SAP
SAP (Sistemi, Applicazioni e Prodotti nell'elaborazione dati) è una multinazionale europea leader nel settore degli ERP e in generale nelle soluzioni informatiche per l’impresa. Negli ultimi anni ha effettuato degli investimenti rivolti verso la Business Intelligence,
acquistando Business Object e dando vita ad una suite chiamata SAP Business Objects
Business Intelligence all’interno del quale è presente anche un programma di ETL.
Lato back-end il tool di riferimento è SAP Data Services. Un programma di ETL che fornisce tutte le funzionalità standard che un tool per l’integrazione e la trasformazione dei dati deve avere e che si integra alla perfezione con Business Objects Web Intelligence il
quale è il prodotto di punta lato Front-end. Questo tool ha una maggiore predisposizione alla reportistica piuttosto che al dashboarding ed è questo il motivo per il quale risulta poco attraente in confronto ai prodotti di fascia alta presenti sul mercato.
14
La Microsoft Corporation è la più grande software house per fatturato al mondo, è nata nel 1975 per opera di Bill Gates e Paul Allen ed ha sede a Redmond nello stato di Washington. A livello di bacino di utenza e di dimensioni può essere considerata la diretta concorrente di Oracle nel campo della BI grazie a Microsoft Sql Server, un DBMS intorno al quale sono state sviluppate soluzioni di DW e di BI. I prodotti di rilievo presenti all’interno della versione Business Intelligence di Microsoft SQL Server 2016 sono, lato Back-end, SQL
Server Integration Services e lato Front-end, Microsoft BI Semantic Model, SQL Server Reporting Services e Microsoft Power BI.
Server Integration Services è un software di ETL molto semplice da utilizzare ma allo stesso tempo molto potente. Consente di creare dei flussi di estrazione e caricamento dati attraverso una serie di operazioni già implementate e semplici da utilizzare, oltre a consentire di crearne delle nuove tramite l’utilizzo di codice SQL o JAVA.
Lato Front-End i tool Microsoft BI Semantic Model e SQL Server Reporting Services consentono di rappresentare ed analizzare i dati sfruttando prevalentemente come output finale dei file Excel. Storicamente questo è uno dei motivi che ha reso Microsoft poco appetibile dal punto di vista dell’offerta di prodotti front-end. Negli ultimi anni però gli investimenti rivolti verso questa fase della BI hanno portato alla creazione di Microsoft
Power BI che permette operazioni di reporting e dashboarding con risultati avanzati dal
punto di vista grafico. Secondo Gartner i prodotti Microsoft tendono ad essere sottovalutati nonostante abbiano dei prezzi vantaggiosi in confronto ai concorrenti di pari livello e nonostante siano di semplice utilizzo.
MICROSTRATEGY
MicroStrategy tra le aziende menzionate sino ad ora è quella di più recente costituzione. Nata nel 1989 per opera di Michael J. Saylor e Sanju Bansale con sede a Washington è una delle realtà maggiormente affermate nel campo della BI. Lato Back-end offre soluzioni che coprono tutta l’area della Business Intelligence e sono stati i primi ad investire sul mobile. MicroStrategy Intelligence Server nonostante permetta di estrarre dai principali Database disponibili, non presenta un tool di ETL per la determinazione dei flussi di estrazione e caricamento dei dati. Tale mancanza è sopperita dal fatto che la struttura adottata da Microstrategy consente di utilizzare tool di ETL di altri vendor che si vanno ad integrare con il resto delle funzionalità. Lato front-end i prodotti principali sono
15
dati provenienti da sorgenti diverse e salvati in locale, MicroStrategy Web, che ha le stesse funzionalità del primo e consente di condividere in tempo breve le informazioni con tutti i componenti aziendali ed infine MicroStrategy Mobile che permette di condividere le analisi su tutti i dispositivi touch presenti in azienda. I prodotti elencati rendono
MicroStrategy una delle migliori azienda software nel campo della BI, tuttavia la difficoltà di utilizzo dei programmi, la mancanza di un tool di ETL nonché gli alti costi delle licenze, rendono MicroStrategy una soluzione adottata prevalentemente dalle grandi aziende.
QLIK
Qlik è un’azienda di software fondata in Svezia nel 1993 ma con sede negli Stati Uniti a Radnor, in Pennsylvania. Viene riconosciuta come la piattaforma di BI con il più alto tasso di diffusione al mondo ed utilizza una tecnologia associativa brevettata, che elabora i dati in memoria permettendo così di rendere più semplice lo sviluppo e l’utilizzo di sofisticate applicazioni di analisi e reporting. La gestione dei dati in memoria consente di avere dei tempi di risposta molto rapidi per qualsiasi tipo di calcolo indipendentemente dalle dimensioni del set di dati e dal numero di utenti che li analizzano in contemporanea. Il prodotto di punta dell’azienda è QlikView.
Questo tool permette di creare dashboard molto complesse che permettono agli utenti di poter analizzare ed esplorare il dato in maniera approfondita tramite l’utilizzo di semplici filtri che consentono di limitare il campo verso le informazioni di interesse. Tuttavia nonostante la creazione delle dashboard sia agevolata da strumenti grafici, che ne
agevolano la creazione, è necessaria una formazione di base superiore a quella richiesta da altri prodotti presenti sul mercato. QlikView è uno strumento maggiormente improntato verso il dashboarding ed è proprio per questo motivo che nel 2014 è stato lanciato un nuovo prodotto, Qlik Sense Enterprise, che sopperisce alle esigenze delle aziende di coprire anche le altre aree dell BI come la reportistica.
La propensione al dashboarding ha portato Qlik ad essere un’azienda leader nel campo della data visualization e del data discovering e nonostante non possa essere considerato uno strumento completo a causa delle mancanze dal lato della reportistica, continua a ricevere il gradimento dei clienti, tanto da raggiungere un ruolo di leadership nel Magic Quadrant rappresentato precedentemente.
16
Tableau è un’azienda giovane, nata nel 2003 in seguito alla commercializzazione di una ricerca prodotta a Stanford riguardo l’esplorazione grafica dei database relazionali e con sede a Seattle. Il prodotto di maggiore rilievo è Tableau, un tool di BI che, come Qlick, è maggiormente rivolto verso il dashboarding e di conseguenza verso la data visualization e il data discovering. Per soddisfare le esigenze dei clienti, al suo interno Tableau ha una serie di prodotti quali:
• Tableau Desktop: uno strumento di analisi dei dati, con caratteristiche simili ad Excel. I dati provenienti da diverse sorgenti, vengono importati all’interno dei fogli di lavoro grazie a delle interfacce molto semplici da utilizzare. Una volta costruita la base dati, questi fogli di lavoro possono essere integrati in un unico cruscotto interattivo, dove l’utente è in grado applicare filtri, effettuare calcoli statistici e visualizzare le informazioni su mappe, tutto attraverso semplici operazioni
agevolate dalla tecnologia drag-and-drop e da soluzioni grafiche già implementate. • Tableau Server: un server che permette di condividere all’interno dell’azienda i
cruscotti creati attraverso Tableau Desktop. In tal modo le informazioni possono essere aggiornate in tempo reale e le modifiche degli elaborati vengono effettuate in tempi brevi.
• Tableau Online: rappresenta la versione in Cloud di Tableau Server e consente di centralizzare le informazioni all’interno di un’unica architettura.
• Tableau Reader: un tool che permette l’interazione degli utenti con le dashboard create tramite Tableau Desktop.
Oltre agli strumenti sopra citati, una funzionalità fondamentale è rappresentate da Tableau
Mobile, il quale è supportato sia da Tableau Desktop che da Tableau Server e permette di
compiere le operazioni su dashboard anche da dispositivi touch.
Tableau è un prodotto che negli ultimi anni ha avuto una diffusione esponenziale tanto da
renderlo un prodotto leader nel campo della data visualization. I punti di forza che
spingono i clienti a scegliere questo strumento sono la facilità di utilizzo e una grafica che non ha concorrenti nel mercato.
17
CAPITOLO 3 PROGETTAZIONE DEL DW
3.1 INTRODUZIONE
La prima fase di un progetto riguarda la realizzazione del Data Warehouse. Per la
progettazione di un DW vengono svolte operazioni che possono essere racchiuse in diverse fasi:
1. Analisi dei requisiti: vengono stabiliti con il committente i requisiti delle analisi dei dati che si desiderano eseguire.
2. Progettazione concettuale: viene creata una rappresentazione astratta, in forma grafica, dello schema dei dati. Il modello concettuale per la progettazione di un DWH è il Dimension Fact Model (DFM).
3. Progettazione logica: viene fatta una rappresentazione legata allo schema scelto per l’implementazione. 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
5. Progettazione fisica: vengono stabilite le strutture di memorizzazione per agevolare le operazioni di analisi dei dati.
Il Data Warehouse è stato progettato secondo l’architettura a tre livelli come rappresentato nell’immagine seguente.
Figura 4 Progettazione Dw
Di seguito verranno descritte le fasi principali per la costruzione di un DW, le quali saranno riprese nello specifico nel capitolo successivo, in cui verranno evidenziate le fasi realizzate per il progetto commissionato.
3.2 ANALISI DEI REQUISITI
“Tutto lo sviluppo del Data Warehouse deve essere guidato dai requisiti del business. I requisiti determinano quali dati devono essere disponibili nel Data
18 Warehouse, come devono essere organizzati, ogni quanto bisogna aggiornarli…l’analisi dei requisiti è il centro di tutto l’universo Data Warehouse” [1]
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.
Questa fase progettuale è ritenuta una delle più importanti all’interno di un progetto di BI, in quanto in tale fase deve essere compreso il modello di business dell’azienda committente e quali saranno i vincoli da rispettare affinché venga realizzato l’output richiesto. Per ottenere ciò sono fondamentali le interviste con i responsabili progettuali menzionate precedentemente. La delicatezza di questa fase è riconducibile al fatto che potrebbero esservi delle difficoltà dovute alla diversità di linguaggio utilizzato tra le parti e che l’output generato in questa fase andrà a definire le attività di progettazione concettuale, logica e fisica della base di dati. Inoltre vengono definiti i processi di caricamento delle informazioni nel DW e le specifiche delle applicazioni da costruire.
3.3 PROGETTAZIONE CONCETTUALE
Terminata la fase di analisi dei requisiti, le specifiche dei requisiti vengono raffinate in maniera tale da ottenere una base stabile da cui partire per il progetto logico. Questa fase prende il nome di Progettazione Concettuale e si avvale del modello Dimensional Fact
Model (DFM) per agevolare la comunicazione tra il progettista e l’utente finale.Il
19
Dimensional Fact Model è un modello concettuale grafico per Data Mart ideato per assolvere a diverse funzioni, quali:
• fornire supporto a tutta la fase concettuale
• creare un ambiente su cui formulare le interrogazioni dell’utente • permettere il dialogo tra progettista e utente finale
• creare una base su cui sviluppare la progettazione logica • restituire una documentazione a posteriori non ambigua
La rappresentazione generata dal DFM è detta Dimensional Scheme (DS) e consiste di un insieme di Fact Scheme (FS) che modellano fatti, misure, dimensioni e gerarchie.
FATTI
Il fatto è un concetto di interesse per il processo decisionale; di norma modella un insieme di eventi che avvengono all’interno dell’azienda(Ordine,Spedizione,Vendita) e le
dimensioni su cui viene costruito il fatto danno vita alla dimensionalità del fatto.
MISURE
La misura è una proprietà numerica di un fatto e ne descrive un aspetto quantitativo di interesse per l’analisi.
DIMENSIONI
Una dimensione è una proprietà con dominio finito di un fatto e ne descrive una coordinata di analisi. 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.
GERARCHIE
Una gerarchia rappresenta un ordinamento logico di alcuni livelli all’interno di una stessa dimensione. E’ fondamentale stabilire i livelli che la compongono e le relazioni esistenti tra loro. Di fatto le gerarchie vengono utilizzate per definire come le istanze possano essere selezionate e aggregate in modo significativo per il processo decisionale. Nello specifico, la navigazione dei dati può avvenire in due modi differenti:
20
• Roll-Up: i dati vengono aggregati per un livello superiore e conseguentemente diminuisce il livello di dettaglio dell’analisi
• Drill-Down: i dati vengono aggregati per un livello più basso e conseguentemente aumenta il livello di dettaglio dell’analisi.
Di seguito viene riportato, per una migliore comprensione di quanto appena descritto, un esempio di modellazione tramite il Dimension Fact Model.
3.3 PROGETTAZIONE LOGICA
Terminata la fase riguardante la progettazione concettuale, da cui si eredita un modello in grado di definire i concetti di interesse ma che non fornisce nessun tipo di informazione sull’organizzazione dei dati, inizia la parte relativa alla progettazione logica. In base alle tecnologie di memorizzazione dei dati possiamo avere differenti modelli logici. Qualora venisse utilizzato un Database Multidimensionale, la progettazione logica è praticamente inesistente, in quanto esiste una corrispondenza biunivoca con il modello
multidimensionale. Qualora invece si facesse uso di un Database Relazionale(ipotesi maggiormente diffusa), si ha la necessità di utilizzare delle tecniche di rappresentazione logica appositamente ideate per rappresentare strutture dati multidimensionali. A partire dal modello concettuale il risultato finale sarà uno schema relazionale contenente generalmente due tipi di tabelle che rappresenteranno gli oggetti del modello multidimensionale. Le tabelle che comporranno tale schema sono:
21
• Fact Table: tabella contenente valori numerici(Misure) che descrivono un evento di business e collegamenti(Foreign Key) a tabelle dimensionali. • Dimensional Table: tabella contenente le informazioni delle entità principali
legate all’evento di business
La rappresentazione multidimensionale quindi può avvenire tramite l’utilizzo di due tipi di schemi che differiscono in base al grado di normalizzazione dei dati. Per normalizzazione dei dati si intende il processo attraverso il quale, nella progettazione di un Db, si elimina la ridondanza dei dati. Tale ridondanza, potrebbe causare delle anomalie nella consistenza degli stessi in seguito a operazioni di inserimento, cancellazione e modifica dei dati. Gli schemi sono:
• Star Schema • SnowFlake Schema
STAR SCHEMA
Lo Star Schema è uno schema in cui si ha la presenza di una forte denormalizzazione dei dati. Ciò permette da un lato di riuscire ad ottenere con un solo join tutte le informazioni riguardanti una Dimensione, ma dall’altro aumenta la ridondanza dei dati. Ciò comporta in prima istanza, un aumento dello spazio occupato dalle tabelle ed in seconda battuta anche a problemi di consistenza dei dati in caso di operazioni di modifica aggiornamento o
cancellazione dei dati. Come si evince dall’immagine, la Fact Table contiene le misure e le
22
chiavi esterne delle Dimension Table, le quali contengono al loro interno un campo che identifica univocamente ogni istanza della tabella (Primary Key) e gli attributi propri della Dimensione.
SNOWFLAKE SCHEMA
Lo SnowFlake Schema è uno Schema in cui viene ridotta la denormalizzazione delle Dimension Table dello Star Schema eliminando alcune delle dipendenze transitive che le caratterizzano. In tal modo le Dimension Table realizzate conterranno al proprio interno le chiavi primarie utili a identificare univocamente un’istanza, gli attributi dimensionali e zero o più chiavi esterne importate da altre Dimension Table. Le chiavi esterne presenti all’interno della Fact Table rendono le tabelle da cui provengono, Dimension Table
primarie, mentre le rimanenti prendono il nome di secondarie. Un DW progettato in questo modo non presenta ridondanza di dati, grazie al processo di normalizzazione attuato e ciò comporta una diminuzione dello spazio occupato per la memorizzazione dei dati e agevola le interrogazioni che coinvolgono attributi che fanno riferimento alla Fact Table o alle Dimension Table. Di contro c’è il fatto che aumenta il tempo per le interrogazioni che interessano più dimensioni in quanto è necessario un maggior numero di join per il reperimento delle informazioni.
23
3.4 PROGETTAZIONE DELL’ALIMENTAZIONE
Terminata la fase relativa alla progettazione logica e concettuale si passa alla fase
successiva in cui è necessario progettare la parte relativa all’ETL. Kimball paragona l’ETL alla punta di un Iceberg, che a bordo di una nave sembra essere spaventosa, ma non se ne percepisce la maestosità sino a quando non ci si sbatte contro, scoprendo ciò che si nasconde sotto il livello dell’acqua. Il paragone fatto da Kimball indica l’importanza che ha il processo ETL nella progettazione di un DW, è risaputo infatti che uno dei grossi limiti delle architetture di BI sono le procedure di aggiornamento per l’alimentazione del DW.
EXTRACT
La prima fase del processo di ETL riguarda l’estrazione dei dati. La diversità delle sorgenti dati rendono necessario definire un piano di estrazione degli stessi che comporta la
definizione delle modalità di estrazione e degli orari in cui attuare tali estrazioni. Nella maggior parte dei casi, a causa della grossa mole di dati si predilige far partire i processi di estrazione nelle ore notturne, in quanto vi sono meno richieste al sistema. La modalità di estrazione può essere di due tipi:
• Statica: solitamente è un tipo di estrazione che viene fatta la prima volta che deve essere popolato il DW e consiste nell’importare tutti i dati presenti nelle sorgenti dati.
• Incrementale: vengono estratti solo i dati che hanno subito delle modifiche dall’ultima estrazione. Naturalmente in questo caso è necessario preservare le informazioni relative alle ultime estrazione affinché si possa essere in grado di determinare i cambiamenti avvenuti.
Una volta che i dati sono stati estratti dalle sorgenti vengono memorizzati nella Staging Area, all’interno della quale le informazioni sono memorizzate transitoriamente per poter compiere le operazioni di pulizia e trasformazione.
TRANSFORM
La fase di trasformazione riguarda principalmente la qualità del dato. Le operazioni che vengono svolte in questa fase dell’ETL riguardano appunto la pulizia e la trasformazione dei dati. A causa della diversità delle sorgenti, questa fase richiede un grande sforzo per il
24
progettista, in quanto alla fine di tale processo devono essere prodotte le informazioni “pulite” che andranno a finire nel DW. Nel dettaglio le operazioni possono essere categorizzate in due fasi:
• Pulizia: vengono prima individuati i record che contengono dati “sporchi” e successivamente vengono corretti per garantire la consistenza delle sorgenti. I principali problemi riscontrati in questa fase riguardano dati duplicati, dati errati o mancanti e inconsistenza tra campi correlati.
• Trasformazione: vengono effettuate una serie di operazioni sui dati in modo tale da rendere i dati uniformi per poter essere caricati sul DW. Le operazioni compiute sono:
o Conversione: a causa della diversità delle sorgenti i dati potrebbero essere memorizzati in formati differenti e ciò comporta la necessità di convertirli in un unico formato.
o Integrazione: vengono integrati i dati provenienti da diverse fonti
o Aggregazione: i dati vengono aggregati per ottenere migliori performance durante le interrogazioni frequenti
o Selezione: vengono selezionati solo i dati necessari.
o Misure: vengono calcolate delle misure derivate da quelle esistenti
LOAD
L’ultimo stadio di questa fase progettuale riguarda il caricamento delle informazioni nel DW. I dati derivanti dai precedenti processi quindi, vanno a popolare prima le tabelle Dimensionali e poi le Fact table in modo da mantenere i vincoli di integrità referenziale. Anche in questo caso vi sono due differenti modalità di caricamento:
• Refresh: caricamento totale del Dw. Solitamente viene utilizzata questa modalità per effettuare il primo caricamento.
• Update: caricamento esclusivo dei dati che hanno subito modifiche dalla data dell’ultimo aggiornamento. I vecchi dati non vengono cancellati in maniera da preservare la storicizzazione del DW.
25
3.5 PROGETTAZIONE FISICA
In questa fase progettuale vengono definite le tecniche per migliorare le performance di un DW. In sostanza le tecniche da utilizzare possono essere raggruppate in tre categorie:
1. Pre-aggregazione dei dati: di norma i dati che sono caricati sul Dw hanno un livello di dettaglio minimo che porta ad avere un elevato dispendio di risorse nel caso in cui dovessimo effettuare delle interrogazioni che comportino aggregazioni da effettuare run-time. Per evitare questo è possibile effettuare un’aggregazione dei dati nella fase precedente di caricamento, in modo tale da creare diverse Fact table, chiamate Summary Table, che contengono dati a diversi livelli di aggregazione. Naturalmente ciò comporta un aumento dello spazio occupato dal DW e quindi affinché possano essere ottenuti risultati soddisfacenti è necessario trovare un giusto compromesso tra tempi di risposta delle query, spazio occupato e tempo impiegato per la pre-aggregazione dei dati.
2. Partizionamento delle Tabelle: quando le tabelle assumono dimensioni elevate è
necessario effettuare operazioni di partizionamento per poter ottenere miglioramenti nelle performance. Il partizionamento avviene a seconda di
determinate regole stabilite in base ai dati da analizzare. Ciò determina un aumento della velocità di risposta delle interrogazioni, in quanto in base alle informazioni di interesse si accede esclusivamente alla parte di tabella in cui si trovano i dati. Di contro si ha l’aumento della difficoltà delle query e il maggiore numero di join necessari per accedere a dati di diverse sotto tabelle.
3. Indicizzazione delle tabella e chiavi numeriche: per velocizzare la lettura delle
informazioni è fondamentale definire le chiavi primarie delle tabelle come campi numerici e definire degli indici sulle chiavi sia delle dimension table che delle Fact Table. Queste operazioni consentono come detto di velocizzare le interrogazioni in lettura, ma causano una perdita di performance nelle operazioni di aggiornamento dei dati a causa della manutenzione dei vari indici creati.
26
CAPITOLO 4 CASO DI STUDIO
4.1 CASO DI STUDIO: BUSINESS INTELLIGENCE PER
REPARTO ACQUISTI
Il seguente capitolo ha lo scopo di fornire una descrizione del progetto realizzato per una nota azienda leader del settore automotive. Verranno riprese le fasi progettuali
precedentemente argomentate con lo scopo di fornire una visione completa del lavoro. Il progetto in questione, può essere diviso in due parti, il pre-progetto ed il progetto vero e proprio. Nella prima fase sono state svolte tutte le attività riguardanti la raccolta delle informazioni utili a capire i motivi che hanno spinto Tyre ad investire nel progetto, in modo tale da captare le varie esigenze che si sarebbero dovute soddisfare con il nostro lavoro e permettere di esporre una prima bozza di quello che si sarebbe potuto creare. Nella seconda fase invece si è proceduto a predisporre in maniera dettagliata un piano di realizzazione che andasse a comprendere le attività progettuali con relative tempistiche e i prodotti da utilizzare.
Durante il primo stadio progettuale sono stati sostenuti una serie di incontri con il
responsabile progettuale di Tyre, il quale ha ricoperto un ruolo fondamentale durante tutta la fase di sviluppo, in quanto è stata la figura di collegamento tra il Team di Iconsulting e gli utenti finali. Sono state analizzate le richieste di business ed in base ad esse sono state definite differenti fasi all’interno del progetto. Nel dettaglio sono stati programmati 3 rilasci e per consentire che questi venissero rispettati, sono stati definiti i cosiddetti milestone, che altro non sono che eventi importanti definiti da chi ha commissionato il progetto. Esempi potrebbero essere il completamento di una parte importante del prodotto oppure il raggiungimento di un punto cruciale in cui devono essere prese decisioni in merito al progetto. Il lavoro che seguirà, rappresenterà il lavoro che è stato svolto per la realizzazione della prima Wave, che ha comportato il rilascio dei primi 4 KPI, del Tool di Data Entry e della Dashboard per la reportistica in riferimento agli indicatori in oggetto.Di seguito saranno descritte le attività sostenute seguendo l’ordine con cui sono state descritte nel capitolo precedente.
4.2 ANALISI DEI REQUISITI
Il progetto descritto in questo elaborato è nato a causa delle esigenze da parte di Tyre di avere un maggiore controllo del settore acquisti dell’azienda. L’obiettivo che si vuole
27
raggiungere con questo lavoro è duplice. Da una parte si è fornito agli utenti uno strumento di Data Entry che consentisse di superare gli ormai obsoleti fogli Excel e che permettesse allo stesso tempo di agevolare l’inserimento di dati relativi ad alcuni KPI, appositamente calcolati e relativi ai processi d’acquisto cross settore merceologico. Dall’altro lato invece si è fornito un applicativo che permettesse di monitorare ed esplorare i dati su diverse dimensioni di analisi in modo tale da consentire ai responsabili delle varie aree di avere sempre informazioni aggiornate e di prendere decisioni in maniera tempestiva.
4.2.1 KPI
Dopo le prime interviste realizzate agli utenti in cui sono stati stabiliti gli obiettivi da raggiungere, gli incontri successivi sono serviti per determinare gli indicatori da calcolare, capire quali di questi dovessero essere inseriti tramite il Data Entry appositamente creato e come questi dovessero essere esplorati nell’applicativo finale. Di seguito sono illustrati i Kpi discussi. Per ogni indicatore viene descritto il significato, viene indicata la frequenza di aggiornamento, viene specificato il livello di dettaglio temporale con cui dovrà essere esplorato sulla Dashboard finale ed infine viene indicato il perimetro su cui deve essere calcolato. Gli indicatori discussi sono:
1. Total Price Saving
➢ Descrizione: delta tra prezzo finale di acquisto e Reference Price(prezzo previsto d’acquisto) * totale quantità acquistata. Il prezzo iniziale potrebbe essere calcolato come:
➢ Prezzo unitario anno precedente ➢ Prezzo unitario da Budget ➢ Prima migliore offerta
➢ Frequenza aggiornamento: Mensile ➢ Vista Periodica: Monthly + Year to Date ➢ Categorie: tutte
Per categorie si intendono le differenti aree su cui deve essere calcolato l’indicatore. Le categorie individuate sono:
28 • Raw Material • Marketing • Shared Services • ICT • Capex
• Moulds & Off Take • Indirects
• Energy • Motorsport
L’inserimento delle informazioni da parte dell’utente deve avvenire attraverso il tool Apex. Il tool in questione fa parte della suite di Oracle ed è uno strumento che viene fornito gratuitamente con il prodotto di punta della compagnia, che come precedentemente descritto risulta essere Oracle.
2. Number of Active Supplier
➢ Descrizione: numero di fornitori attivi negli ultimi 12 mesi ➢ Frequenza aggiornamento: mensile
➢ Vista Periodica: mensile + Year to Date ➢ Categoria: tutte
3. % Call-Off Orders
➢ Descrizione: indicatore che misura la percentuale di ordini automatici rispetto al totale ordini
➢ Frequenza aggiornamento: mensile ➢ Vista periodica: mensile + Year to Date ➢ Categorie: raw Material
29
4. Net Cash Flow
➢ Descrizione: impatto degli acquisti sul flusso netto di cassa ➢ Frequenza aggiornamento: mensile
➢ Vista Periodica: mensile + Year to Date ➢ Categorie: tutte
5. MonoSource Raw Material
➢ Descrizione: numero di materie prime per il quale esiste un solo fornitore qualificato / il numero totale di materie prime. Il rapporto viene espresso in percentuale.
➢ Frequenza aggiornamento: annuale ➢ Vista periodica: annuale
➢ Categorie: raw material
I KPI sopra descritti, come precedentemente accennato, sono frutto di una serie di discussioni con i responsabili progettuali, in cui la collaborazione tra i team delle due aziende, ha contribuito a stabilire le linee guida da seguire per gli sviluppi e le tempistiche di rilascio. Durante gli sviluppi sono stati previsti dei SAL settimanali che hanno permesso all’azienda committente di essere componente attiva nella risoluzione delle problematiche riscontrate e hanno consentito al Team di Iconsulting di avere un feedback frequente sul lavoro svolto e di avere la possibilità di discutere con gli utenti sulle varie difficoltà/possibilità implementative esaminate.
4.2.2 TOOL DATA ENTRY
Una parte sostanziale del lavoro ha riguardato la creazione di un’applicazione per il Data Entry. A seguito delle prime riunioni in cui sono stati stabiliti i KPI, la fase successiva è stata fondamentale per stabilire le caratteristiche e le funzionalità del tool. Come accennato sopra, il software scelto dall’azienda committente per assolvere al compito di Data Entry è
Oracle Application Express (Apex). La scelta del tool è stata condizionata dalla presenza
in azienda di numerosi applicazioni sviluppate con tale strumento. Ciò naturalmente ha influenzato la scelta per due motivi principali, il primo riguarda la familiarità da parte degli
30
utenti nell’utilizzare lo strumento, il secondo riguarda il fattore economico. Infatti la
licenza del tool è legata alla licenza di utilizzo di Oracle DB, il quale viene utilizzato come
DBMS all’interno dell’azienda. Dalle riunioni effettuate sono emerse diverse esigenze e
sono state richieste alcune feature ritenute fondamentali dagli utenti. Di seguito sono riportati i requisiti richiesti:
1. Login da effettuare tramite credenziali di rete aziendali.
2. Home Page da cui poter accedere agevolmente alle Form di Data Entry dei KPI. 3. KPI editabili in base alle utenze ed in base all’area di competenza.
4. Distinzione tra utente approvatore e utente standard.
5. Form Data Entry con possibilità di inserire agevolmente le informazioni. ➢ Autocomplete delle celle in base ai valori presenti nelle anagrafiche. ➢ Pulsante che permetta la copia delle righe inserite nel mese precedente a
quello di riferimento con valore del KPI non valorizzato. ➢ Disabilitazione del Form dopo il 15 di ogni mese.
➢ Abilitazione del Form dal 1 al 15 di ogni mese con possibilità di inserire dati per il mese corrente e modificare dati relativi ad un periodo temporale che include i 12 mesi precedenti al mese abilitato.
➢ Validazione dei dati prima dell’inserimento con annessa verifica dei vincoli di integrità referenziale.
➢ Differente colorazione delle righe in base allo stato dell’istanza(in attesa di approvazione, approvata, rigettata).
6. Form File Entry che permetta di effettuare un Upload massivo tramite file .Csv e tramite copia incolla da Excel.
7. Processo di approvazione dei dati inseriti.
8. Email alert all’utente approvatore per ogni nuovo record inserito.
9. Pagina di Approvazione visibile solo agli utenti con privilegi da approvatore. 10. Possibilità di accettare/rigettare simultaneamente più istanze.
11. Email alert all’utente standard del cambiamento di stato della propria istanza.
4.2.3 TOOL DATA VISUALIZATION
L’analisi riguardante la parte relativa alla reportistica ha richiesto un numero di incontri inferiori rispetto a quelli precedenti. Il tool da utilizzare per gli sviluppi è Oracle Business
31
Gli incontri svolti hanno riguardato principalmente argomenti relativi al layout della Dashboard e alle differenti pagine di dettaglio da creare in base ai kpi.
4.3 SORGENTI INFORMATIVE: APEX
4.3.1 PREPARAZIONE DELL’AMBIENTE
Terminata la fase di analisi dei requisiti sono iniziati i lavori di sviluppo relativi al Data Entry richiesto. In prima analisi è stato realizzato uno schema che descrive come sarà gestito il flusso delle informazioni e che riassume le funzionalità da implementare.
Come è possibile notare dal diagramma di flusso, nell’applicativo le informazioni seguono flussi differenti in base al tipo di utente.
Standard User
Qualora il Login venisse effettuato da un utente standard, sarà abilitato a compiere esclusivamente azioni di inserimento o modifica. L’inserimento può avvenire in due modi:
32
• Add or Modify single or multiple instances: abilita l’utente alla modifica o all’inserimento. In entrambi i casi l’istanza oggetto dell’operazione attiverà il processo di validazione sopra descritto.
• Massive Upload: consente all’utente di effettuare l’upload da file oppure tramite il “Copy and Paste”. Una volta terminata la procedura, verrà attivato un processo di validazione che avrà fine quando l’utente Admin avrà accettato o rigettato la richiesta. Qualora le istanze venissero approvate, verranno visualizzate nella BI, altrimenti saranno visibili solo all’utente responsabile dell’Upload.
Admin User
Qualora il Login venisse effettuato da un utente Admin l’operazione a cui è abilitato è di un solo tipo:
• Approval: l’operazione di approvazione consente all’utente Admin di gestire le istanze inserite dagli standard users. Le operazioni consentite sono di due tipi:
• Approve: i record selezionati vengono ritenuti validi e saranno visibili nella BI. • Reject: i record selezionati non vengono ritenuti validi e saranno visibili solo
ed esclusivamente nella pagina dell’utente responsabile dell’inserimento.
L’utente può essere abilitato a compiere anche le operazioni di “Inserimento”,“Modifica” e “Upload” se previsto nel Workflow. Entrambe le operazioni non si discostano da quelle appena descritte per gli Standard User.
La profilazione delle utenze è stata gestita mediante l’utilizzo di tre tabelle create all’interno del DB. Le tabelle in questione sono:
1. USER_LOGIN
➢ Descrizione: Tabella contenente le informazioni dell’utente ➢ Attributi: Username, Password, Privilegi, Email
➢ PK: Username
2. WORKFLOW_MAPPING
➢ Descrizione: Tabella contenente le informazioni riguardanti i KPI e le aree su cui gli utenti sono abilitati.
33
➢ Attributi: Area, Username, Kpi ➢ PK: Area, Username, Kpi
3. WORKFLOW_MAPPING_APPROVATORE
➢ Descrizione: Tabella contenente le informazioni riguardanti l’utente abilitato ad approvare le istanze.
➢ Attributi: Area, Kpi, Approvatore ➢ PK: Area,Kpi
Le strutture create permettono a più utenti di poter editare la medesima area e il medesimo Kpi, cosa che invece non avviene per gli utenti approvatori. Infatti, in base a precise richieste da parte della committenza è possibile avere un solo utente approvatore per ogni KPI e Area. Una volta definite le strutture delle tabelle utili per gestire la profilazione degli utenti, il passaggio successivo è stato quello di analizzare i KPI che richiedono la creazione del Data Entry su Apex, in modo tale da definire la struttura della Fact Table e di delineare le Lookup Table da utilizzare. Questa analisi ha portato alla creazione di due tabelle, descritte di seguito.
PURCH_SAVING_ACTUAL
➢ Nome Campo
• MANDT (VARCHAR2(9) NOT NULL): Descrive il settore a cui si riferisce l’inserimento. Viene valorizzato con il codice ‘210’ che rappresenta ‘Industrial’.
• MONTH_ID (NUMBER NOT NULL): Identificativo del mese a cui si riferisce l’inserimento. Il formato desiderato dalla committenza è ‘YYYYMM00’.
• AREA (VARCHAR2(150) NOT NULL): Indica l’area industriale. I valori previsti sono quelli descritti in precedenza quando sono state definite le Categorie.
34
• BU (VARCHAR2(150) NOT NULL) : Indica la Business Unit. Le Business
Unit presenti sono: TRUCK, CAR, VELO, MOTO, CYBER ed N/A(valore inserito nel caso in cui non venga definita la business unit di competenza) • REGION (VARCHAR2(150) NOT NULL): indica la Regione, intesa come
l’area geografica in cui è situato il Plant per il quale viene fatto l’inserimento.
• COUNTRY (VARCHAR2(150) NOT NULL): Indica la Nazione a cui appartiene il Plant.
• COMPANY_CODE (VARCHAR2(150) NOT NULL): Codice
identificativo della Compagnia alla quale viene attribuito l’iserimento. • PLANT (VARCHAR2(100) NOT NULL):: Codice identificativo del Plant
al quale viene attribuito l’iserimento.
• PRICE_SAVING_ACTUAL (NUMBER): Misura che rappresenta la differenza tra prezzo effettivo d’acquisto e prezzo previsto.
• DW_DT_INS (TIMESTAMP(6)): Timestamp dell’inserimento dell’istanza.
• DW_DT_UPD(TIMESTAMP(6)):Timestamp dell’aggiornamento
dell’istanza.
• USERNAME (VARCHAR2(100)): Identificativo dell’user responsabile dell’inserimento.
• DW_VALDITY (NUMBER NOT NULL): Stato dell’istanza.
➢ PK: MANDT,MONTH_ID,AREA,BU,REGION,COUNTRY,COMPANY_CODE, PLANT
PURCH_CASHFLOW_A
➢ Nome Campo
• MANDT (VARCHAR2(9) NOT NULL): Descrive il settore a cui si riferisce l’inserimento. Viene valorizzato con il codice ‘210’ che rappresenta ‘Industrial’
35
• MONTH_ID (NUMBER NOT NULL): Identificativo del mese a cui si riferisce l’inserimento. Il formato desiderato dalla committenza è ‘YYYYMM00’
• AREA (VARCHAR2(150) NOT NULL): Indica l’area industriale. I valori previsti sono quelli descritti in precedenza quando sono state definite le Categorie.
• COUNTRY (VARCHAR2(150) NOT NULL): Indica la Nazione a cui appartiene il Plant.
• NET_CASH_FLOW_ACTUAL (NUMBER NOT NULL ENABLE): misura che indica l’impatto di un acquisto sul flusso netto di cassa.
• DW_DT_INS (TIMESTAMP(6)): Timestamp dell’inserimento dell’istanza.
• DW_DT_UPD(TIMESTAMP(6)): Timestamp dell’aggiornamento
dell’istanza.
• USERNAME (VARCHAR2(100)): Identificativo dell’user responsabile dell’inserimento.
• DW_VALDITY (NUMBER NOT NULL): Stato dell’istanza. ➢ PK: MANDT,MONTH_ID,AREA,COUNTRY
Le due tabelle sono state create all’interno del DB nello Schema DW_APEX, dove sono contenute tutte le tabelle utilizzate dal Tool di Oracle. Definite le strutture principali, è stata eseguita un’analisi sui campi che le compongono, per identificare all’interno del DB operazionale le tabelle da utilizzare come Look Up table. Il termine “Look Up table” indica le tabelle utili per la validazione dei campi immessi, ovvero tabelle con caratteristiche particolari, quali:
• Sono popolate da dati descrittivi riguardanti una particolare Dimensione • Sono generalmente di dimensioni ridotte rispetto alle Fact Table
• Le operazioni principali sono di lettura e scrittura. Raramente vengono effettuate operazioni di update su di esse.
36
Nel nostro caso le Look up utilizzate sono:
• DW_PURCHASING_AREA: Tabella contenente le informazioni relative alle differenti aree.
• DIM_BI_OBU: Tabella contenente le informazioni relative alle Business Unit
• DIM_COMPANY_CODE: Tabella contenente le informazioni riguardanti le Company.
• DIM_COUNTRY_PURCHASE: tabella contenente le informazioni relative alle Country.
• DIM_WAREHOUSE_PURCHASE: tabella contenente le informazioni relative ai Plant.
• DIM_REGION: tabella contenente le informazioni relative alle Region. Definite le tabelle da utilizzare per il corretto funzionamento del Data Entry la fase successiva ha riguardato la creazione dell’interfaccia utente per l’inserimento dei dati.
4.3.2 ORACLE APEX APPLICATIONS
Il Tool adottato è uno strumento di sviluppo integrato con Oracle Db per la creazione di applicazioni Web con SQL e PL/SQL. Tramite l’utilizzo di un Web Browser possono essere sviluppate e distribuite applicazioni Web professionali per dispositivi Desktop e Mobile. E’ uno strumento basato sul Db tramite il quale è possibile trasformare un foglio di calcolo in un’applicazione web multi-utente. Apex utilizza un’architettura tramite la quale le pagine sono generate in modo dinamico grazie ai metadati memorizzati all’interno del DB di Oracle. Ciò comporta che non vi è una generazione di codice e che non vi sia nessun file per la compilazione, infatti, una volta installato e configurato è possibile accedere allo strumento attraverso un URL definito sia per gli sviluppatori che per gli utenti finali senza la necessità di dover installare Client software aggiuntivi. Per una migliore comprensione del Tool di seguito verranno descritte, tramite l’utilizzo di immagini esemplificative, le componenti più importanti che lo compongono.
