Dipartimento di Informatica
Laurea Magistrale in Informatica per l’Economia e per l’Azienda
(Business Informatics)
TESI DI LAUREA
Business Intelligence per il controllo di
gestione della società Sapio
Relatore:
Dott.ssa Giovanna ROSONE
Controrelatore:
Prof. Giorgio GHELLI
Candidato:
Roberto CARNEVALE
Tutor Aziendale:
Dott.ssa Marta CAROLI
Nel lavoro di tesi vengono affrontate le tematiche inerenti le fasi di modellazione di un cubo multidimensionale e lo sviluppo di un sistema di reportistica che sintetizza i Key Performance Indicators (KPIs) utili per analizzare e valutare le performance aziendali della società cliente Sapio, una multinazionale nel settore della produzione di gas.
Vista la complessità del processo produttivo e le particolari esigenze dell’u-tente, sono stati elaborati diversi documenti di progettazione per evidenziare gli aspetti chiave sui quali incentrare lo sviluppo.
L’obiettivo è quello di realizzare un’applicazione di Business Intelligence, capace di raccogliere ed organizzare i dati e fornire delle dashboards di re-portistica contenenti i reports generati tramite il calcolo dei KPIs stabiliti. Inoltre, una funzionalità essenziale che il sistema deve fornire all’utente, è quella di poter intervenire, attraverso degli adjustments, sui risultati ottenuti dai reports.
Uno dei problemi riscontrati in fase di progettazione è stato quello della grande quantità di dati da dover gestire. Per risolvere questa situazione, è stato necessario riprogettare il data warehouse utilizzato attualmente dall’u-tente, semplificandolo in modo da contenere solamente le entità utili ai fini del progetto.
Nella relazione vengono presentate le diverse fasi affrontate, quali la pro-gettazione del data warehouse, il processo di ETL per l’elaborazione dei da-ti, la modellazione di un cubo multidimensionale ed infine i calcoli dei KPIs opportunamente organizzati in dashboards interattive.
L’applicazione è stata realizzata utilizzando Oracle Hyperion Essbase, Ora-cle Business Intelligence e OraOra-cle Smart View per Microsoft Excel.
1 INTRODUZIONE 1
1.1 Presentazione del problema . . . 1
1.2 Stato dell’arte . . . 4
1.3 Rassegna della letteratura . . . 5
1.4 Contenuto della tesi . . . 6
2 IL CASO DI STUDIO 9 2.1 L’azienda committente . . . 9 2.1.1 Sapio Industria . . . 10 2.1.2 Sapio Sanità . . . 11 2.2 L’azienda esecutrice . . . 12 2.3 Ambito di riferimento . . . 13 2.3.1 Controllo di gestione . . . 13 2.3.2 Budget e Forecast . . . 15 3 PROGETTAZIONE 19 3.1 Specifica dei requisiti di analisi . . . 19
3.2 Cambiamento delle dimensioni . . . 36
3.3 Progettazione concettuale di un data mart . . . 37
3.4 Classificazione delle tabelle . . . 38
3.5 Progettazione logica del data warehouse . . . 39
4 AMBIENTE DI SVILUPPO 40 4.1 Componenti applicative utilizzate . . . 40
4.2 Hyperion Essbase . . . 41
4.2.1 Outline . . . 43
4.2.2 Confronto tra cubo ASO e BSO . . . 44
4.2.3 Dimensioni dense o sparse e modalità di memorizzazione dei dati . . . 46
4.2.4 Proprietà Data Storage dei membri . . . 47
4.2.5 Membri Dynamic Time Series . . . 48
4.2.6 Variabili di sostituzione . . . 49
4.2.7 Calculation script . . . 49
4.2.8 Ristrutturazione del database . . . 50
4.3 OBIEE . . . 51
4.3.1 Componenti di Oracle Business Intelligence . . . 51
4.4 Smart View . . . 52
5 PROCESSO DI ETL 54
5.1 Introduzione del processo ETL . . . 54
5.2 Load Rule di Oracle Essbase . . . 55
5.2.1 Estrazione tramite Load Rule . . . 55
5.2.2 Trasformazione tramite Load Rule . . . 57
5.2.3 Caricamento tramite Load Rule . . . 60
6 MODELLAZIONE MULTIDIMENSIONALE 63 6.1 On-Line Analytical Processing vs On-Line Transaction Processing 63 6.1.1 Cubo Multidimensionale . . . 65
6.1.2 MOLAP, ROLAP, HOLAP . . . 66
6.2 Progettazione del cubo Essbase . . . 67
6.2.1 La dimensione di tipo Tempo . . . 70
6.2.2 La dimensione di tipo Dinamico . . . 70
6.2.3 La dimensione di tipo Conto Dinamico . . . 71
6.3 Outline del database SAPIOKPI . . . 71
6.4 Data Storage dei membri . . . 73
6.5 Script MaxL . . . 73
6.6 Aggiornamento mensile del cubo . . . 74
7 MAPPATURA KPIs E ADJUSTMENTS 76 7.1 I KPIs . . . 77
7.2 Adjustments . . . 80
7.2.1 Il caso delle gare nuove e delle gare perse . . . 81
7.2.2 Il caso delle fatture duplicate . . . 84
8 REPORTISTICA E DASHBOARDS 85 8.1 Le Dashboards implementate . . . 85
8.2 Analisi in OBIEE . . . 87
9 CONCLUSIONI 91
Elenco delle figure 95
Elenco delle tabelle 97
INTRODUZIONE
1.1
Presentazione del problema
In un’azienda il controllo di gestione (o controllo direzionale) è il sistema ope-rativo volto a guidare la gestione verso il conseguimento degli obiettivi stabiliti in sede di pianificazione operativa, rilevando, attraverso la misurazione di ap-positi indicatori, lo scostamento tra obiettivi pianificati e risultati conseguiti e informando di tali scostamenti gli organi responsabili, affinché possano decidere e attuare le opportune azioni correttive. Uno dei principali strumenti per que-sto tipo di analisi è il budget, che tramite un documento permette di fissare gli obiettivi da raggiungere sia a livello qualitativo che quantitativo [Marasca 08]. Tali obiettivi devono essere coerenti con la pianificazione strategica aziendale. Il budget viene elaborato annualmente prima della chiusura dell’esercizio al quale si riferisce. Spesso accade, però, che nel corso della gestione azien-dale ci si renda conto che i risultati ottenuti nei primi mesi di esercizio non sono coerenti con quelli ipotizzati nella stesura del budget. Pertanto in molte organizzazioni vengono realizzati, generalmente con cadenza trimestrale, dei documenti chiamati forecast. Il forecast ha le stesse funzioni del budget, ma viene elaborato nel corso dell’esercizio al quale si riferisce e contiene le rile-vazioni consuntive registrate prima della sua redazione e i dati previsionali relativi al periodo restante.
Il metodo generalmente usato per conoscere lo stato e l’andamento azien-dale, consiste nel calcolo di indicatori, denominati Key Performance Indicators (KPIs), ritenuti essenziali dal controllo di gestione. L’utilizzo dei KPIs, appli-cati ad un lasso temporale ampio, permette di evidenziare gli aspetti essenziali per la correzione di andamenti negativi o per il miglioramento di quelli positi-vi. Inoltre, forniscono informazioni utili per la stesura di documenti di budget
e forecast su base previsionale.
L’utilizzo dei KPIs, o di qualunque altro metodo per fare previsioni, spesso risulta essere un’impresa ardua se non si hanno a disposizione i dati con un certo grado di storicità e sopratutto con un certo livello di dettaglio. Di conse-guenza, risultano importanti le strutture di memorizzazione dati e le modalità con la quale vengono utilizzate.
In particolare, in questo caso di studio, l’utente utilizza un data warehouse che consente un livello di dettaglio adeguato dei dati attuali e storici, ma la complessità della struttura e la numerosità dei dati contenuti non permettono un agevole utilizzo in fase di reportistica.
Per questo motivo, il primo step affrontato riguarda la riprogettazione del data warehouse in modo da semplificarlo utilizzando solo quei dati necessari allo scopo. Dopo questa prima fase, è stato prodotto un documento di proget-tazione che permettesse ai responsabili del reparto informatico del cliente di mettere a disposizione le tabelle relazionali necessarie per la modellazione del cubo.
Un approccio comunemente usato per sviluppare applicazioni di Business Intelligence in quest’ambito consiste nell’utilizzare direttamente le tabelle re-lazionali per generare i reports richiesti dall’utente e permettere lo studio del-l’andamento della propria organizzazione, mediante software del settore, come
Oracle Business Intelligence (OBIEE). Nel caso specifico si è scelto di non
utilizzare tale strategia, poichè la numerosità dei dati graverebbe sul livello di performance del sistema, rendendo i calcoli, per realizzare i KPIs richiesti dall’utente, particolarmente complessi.
Per questo motivo, si è deciso di utilizzare una struttura multidimensionale che permettesse di semplificare la complessità computazionale. Tale obiettivo è stato ottenuto grazie all’utilizzo di Oracle Hyperion Essbase, un
Multidi-mensional Database Management System (MDBMS), che consente di gestire
cubi multidimensionali. Quest’applicazione mette a disposizione due tipi di database, uno di tipo Block Storage Option (BSO) e l’altro Aggregate
Stora-ge Option (ASO). Il primo tipo è quello più comunemente utilizzato perché
integra funzionalità di calcolo che permettono di spostare parte della com-plessità computazionale sul lato server, anche se utilizza molto spazio per la memorizzazione dei dati. Nel caso oggetto di studio, tale svantaggio è stato ritenuto troppo rilevante, così la scelta si è spostata sui cubi ASO che però non integrano tutte quelle funzionalità di calcolo presenti nei BSO. Per risolvere tale inconveniente, sono stati sviluppati script MDX in combinazione con le
potenzialità di calcolo del software OBIEE.
Un’ulteriore richiesta dell’utente è quella di analizzare i reports e succes-sivamente avere la possibilità di effettuare delle correzioni (adjustments) ad un livello di dettaglio massimo. Generalmente, questo tipo di applicazioni che consentono di effettuare adjustments, vengono implementate utilizzando tabelle relazionali con metodi di Write-Back1, o software aggiuntivi quali,
Ora-cle Hyperion Profitability and Cost Management (HPCM) o OraOra-cle Hyperion Planning. Invece, in questo caso, è stato possibile utilizzare una nuova
funzio-nalità dei cubi ASO, che permette di collegarsi direttamente al cubo Essbase e, selezionando uno specifico incrocio, consente la visualizzazione, la modifica e l’imputazione del dato. Ciò è possibile sfruttando Hyperion Smart View per
Microsoft Excel, che è un software compreso nella licenza di OBIEE.
Inoltre, per facilitare l’analisi dei reports mostrati, è stato predisposto per ognuno di essi una versione alternativa. In particolare, oltre al report di sinte-si, è stato sviluppato un report corrispondente, ma con un livello di dettaglio maggiore. Per esempio, se il report di sintesi mostra il delta fatturato per una categoria di articoli, quello di dettaglio mostrerà lo stesso dato, ma suddiviso per altre dimensioni di analisi. In questo modo, l’utente potrà verificare l’esat-tezza dei dati dai reports di sintesi e, in caso ci fossero scostamenti dal valore atteso, poter circoscrivere l’anomalia grazie ai reports di dettaglio. Oltre ad avere la necessità di correggere eventuali errori, gli adjustments sono necessari anche per modificare dei valori corretti ma non significativi dal punto di vista del controllo di gestione. In questo modo, l’utente potrà analizzare i risultati ad un livello di dettaglio massimo, ed eventualmente, apportare delle modifi-che utilizzando Smart View, modifi-che si presenta come un semplice foglio di calcolo di Microsoft Excel.
L’obiettivo e il motivo della scelta di queste tecnologie e metodologie è per-mettere agli utenti di non discostarsi dalle loro abitudini nello svolgimento delle attività e consentire un giusto grado di personalizzazione delle logiche di calco-lo che possono essere modificate, successivamente al rilascio dell’applicazione, anche dai responsabili IT del cliente.
1Metodi che permettono di realizzare delle maschere (forms di testo) in cui inserire i valori da caricare nelle tabelle
1.2
Stato dell’arte
I sistemi di business intelligence nell’ambito del controllo di gestione sono oramai la base per un funzionamento ottimale di tutte quelle attività che con-sentono all’organizzazione di prosperare e crescere. Riuscire ad avere sotto controllo l’andamento e i risultati raggiunti risulta essere un valore aggiunto non indifferente per le società che puntano non solo a raggiungere determinati margini di profitto ma anche ad ottimizzare al massimo l’utilizzo delle proprie risorse.
Di conseguenza, una continua evoluzione del controllo di gestione ha por-tato allo sviluppo di nuove modalità di reportistica e monitoraggio di tutti i fattori critici di successo aziendali. L’esigenza di ottenere risultati sempre precisi ha contribuito a far sviluppare sul mercato nuovi applicativi in gra-do di sostenere in mogra-do sempre più tempestivo ed efficiente la richiesta di informazioni di tipo direzionale.
Le fasi, in linea teorica, per realizzare un sistema di business intelligence sono la raccolta dei dati, lo sviluppo della logica di calcolo e la disposizione dei risultati. Generalmente, la raccolta di dati può avvenire utilizzando diverse strutture di memorizzazione, dalle tabelle relazionali ai più semplici file grezzi, fino ad arrivare ai database multidimensionali. L’utilizzo di questi ultimi ha permesso un netto miglioramento a livello computazionale e di performance in fase di caricamento dati.
Negli ultimi anni, sono state introdotte numerose funzionalità per sfrut-tare al massimo le potenzialità del concetto di multidimensionalità. Uno dei fornitori di software in questo campo più conosciuto al mondo, Oracle, ha svi-luppato un MDBMS (Multidimensional Data Management System) chiamato
Essbase. Esso convoglia tutte le funzionalità necessarie ed è uno dei software
più utilizzati in sistemi di questo genere. Un’applicazione Essbase è come un contenitore e può comprendere più database. Ognuno di questi database può utilizzare una struttura dati, la più comune è chiamata Block Storage Option (BSO). Essa si basa su un metodo di memorizzazione dei dati completo, cioè tutti i dati del cubo sono memorizzati in celle e questo consente di caricarli ad ogni livello di gerarchia. Questa possibilità permette di applicare logiche di calcolo complesse per soddisfare analisi di ogni tipo, ma d’altro canto occupa uno spazio non indifferente di memoria. Questo suo vincolo obbliga gli svi-luppatori ad una attenta analisi e progettazione per limitare i dati da caricare così da non gravare sulle dimensioni e di conseguenza sulle performance.
un’applicazio-ne Essbase o software esterni, quale ad esempio Oracle Busiun’applicazio-ness Intelligence, che consentono di raggiungere i risultati prefissati. In particolare, il software Oracle Business Intelligence generalmente punta a tabelle relazionali, che so-no utilizzate in situazioni in cui è necessario gestire una grande quantità di dati, al contrario, difficilmente gestibile in strutture multidimensionali. Inol-tre, le tabelle relazionali, sono utilizzate quando vi è la necessita di imputare dati utilizzando metodi di Write Back, metodi non consentiti nei database multidimensionali gestiti dall’applicazione Essbase. Infatti nei cubi BSO, l’im-putazione del dato viene gestita tramite l’utilizzo di maschere implementate in software aggiuntivi tipo Oracle Hyperion Profitability and Cost Management (HPCM) o Oracle Hyperion Planning.
Una possibile implementazione del sistema sviluppato sarebbe stata quella di utilizzare un cubo Essbase BSO in combinazione con maschere preimpostate per l’imputazione del dato e la predisposizione di etichette per gli adjustements fornite dal software Oracle Hyperion Planning, più Oracle Business Intelligence per sviluppare i KPIs e organizzare i report in dashboards. Questo compor-tava l’acquisto di licenze per tutti e tre i software oltre alla gestione della problematica dell’enorme quantità di dati da caricare per la generazione delle dimensioni (come verrà spiegato nei capitoli successivi).
Un’altra possibile implementazione avrebbe comportato l’utilizzo di tabelle relazionali per l’imputazione dei dati e degli adjustments, in combinazione con il cubo Essbase BSO. Questo mix risultava maggiormente limitante rispetto al precedente perché l’unico modo per riflettere le imputazioni manuali sareb-be stato quello di ricaricare i dati sul cubo e tale operazione (generalmente schedulata mensilmente) può richiedere diverse ore.
La soluzione descritta nei prossimi capitoli ha permesso di raggiungere i risultati sperati ovviando ai problemi che si sarebbero verificati implementando le soluzioni precedentemente illustrate.
1.3
Rassegna della letteratura
Nella scrittura del seguente documento sono state consultate diverse fonti. Nello specifico, per gli argomenti riguardanti il lato economico, quindi budget
e forecast, nonchè più in generale il processo del controllo di gestione si è fatto
riferimento al libro Il controllo di gestione, scritto da S.Marasca, L. Marchi, A. Riccaboni [Marasca 08].
Riguardo le informazioni generali dell’azienda committente e l’azienda ese-cutrice si è fatto riferimento, rispettivamente ai siti web ufficiali www.sapio.it [Sapio 15] e www.reply.it [Reply 15]. Per i concetti riguardanti il CPM, invece, è stata consultata la fonte di [Melchert 06] Aligning Process Automation and
Business Intelligence to Support Corporate Performance Management.
Per la parte riguardante l’analisi e la progettazione di un data warehouse e alcuni concetti di modellazione multidimensionale si è fatto riferimento al libro
Decision Support Database Essentials, scritto da A. Albano [Albano 13]e altre
fonti quali Dimensional Modeling: In a Business Intelligence Environment [Ballard 06] e ROLAP Implementation of the Data Cube [Morfonios 06].
Infine si fa riferimento ai corrispettivi manuali presenti sul sito ufficiale di Oracle www.oracle.com quali [Essbase], [Smart View], [Data and Dimensions] e [OLAP Model] per la parte riguardante gli strumenti utilizzati della sui-te Oracle e a [Dashboards Building] per i concetti riguardanti i metodi di visualizzazione dei risultati.
1.4
Contenuto della tesi
La presente relazione di tesi sintetizza l’applicazione realizzata a supporto del processo di reportistica per il controllo di gestione del cliente. La società realizzatrice di questo caso di studio è Reply Consulting, la società cliente è SAPIO, per la precisione SAPIO Produzione Idrogeno Ossigeno Srl del set-tore Industria e Sapio Life del setset-tore Sanità. Inoltre, vengono presentate tutte le funzionalità e caratteristiche principali degli strumenti utilizzati per la realizzazione dell’applicazione oggetto di studio.
Nel secondo capitolo vengono presentate le aziende coinvolte nello sviluppo dell’applicazione con una breve panoramica delle loro attività svolte. Inoltre, vi è la descrizione dei processi del controllo di gestione con particolare attenzione a quelli di budgeting e forecasting.
Nel terzo capitolo viene descritta la fase di analisi dei requisiti e della pro-gettazione dei modelli utili per la costruzione di un cubo multidimensionale sul quale verranno memorizzati i dati. In questo capitolo vengono presen-tate le fonti dati a partire dal data warehouse già utilizzato dal cliente, e il processo di semplificazione di quest’ultimo per riadattarlo al nuovo data
ware-house. Seguendo la struttura descritta in [Albano 13] vengono definite tutte
le dimensioni, gli attributi, le gerarchie interessate e stabilita la granularità del fatto. Inoltre, vengono descritte tutte le misure utili per il calcolo dei
valori che andranno a comporre i Key Perfomance Indicators. Nella seconda parte del capitolo, vi è una breve descrizione sul tema del cambiamento delle dimensioni e sulla tipologia implementata. Infine, viene mostrato lo schema concettuale di un data mart che riassume tutte le analisi fatte in precedenza e sulla base di questo schema, vengono classificate le tabelle sorgenti e realizzato lo schema logico che sarà il punto di partenza per la modellazione del cubo multidimensionale.
Nel quarto capitolo viene presentato l’ambiente di sviluppo assieme alle tec-nologie utilizzate. In particolare, viene descritto sia Oracle Hyperion Essbase per la realizzazione del cubo multidimensionale, sia alcune caratteristiche, qua-li outqua-line, cubi BSO e ASO, proprietà delle dimensioni e script di calcolo. Un altro strumento utilizzato è Oracle Smart View, utile sia per l’imputazione di dati all’interno del cubo, sia per l’implementazione del sistema di adjustments; ciò è possibile grazie al fatto che esso si collega direttamente al cubo Essba-se. Infine, viene descritto Oracle Business Intelligence, che è una piattaforma utilizzata per sviluppare tutte le analisi richieste e organizzarle in dashboards interattive pronte per essere utilizzate dall’utente.
Nel quinto capitolo vengono descritte le prime fasi di sviluppo del caso di studio, in particolare, il processo di ETL utile per il caricamento dei dati all’in-terno della struttura multidimensionale. Tale descrizione consisterà prima in una panoramica sul processo in generale e successivamente verranno illustrate le specifiche che hanno caratterizzato le fasi di estrazione, trasformazione e caricamento. Queste ultime sono state svolte utilizzando le Load Rules, uno strumento di Essbase, che permettono di creare un collegamento JDBC con il database. L’utilizzo di queste Load Rules avviene tramite un’interfaccia dell’Administration Services Console di Essbase, il web client utilizzato per la gestione del cubo. La parte di estrazione e trasformazione viene realizzata utilizzando delle query SQL, mentre per il caricamento è necessario mappare tutti i campi seguendo la struttura del cubo.
Nel sesto capitolo vengono descritte le fasi della modellazione multidimen-sionale del cubo Essbase che sarà il contenitore delle dimensioni e dove saranno caricati i fatti, organizzati secondo specifiche misure o, nel caso specifico di que-sta applicazione, in KPIs base. Partendo da una breve introduzione sui sistemi OLTP, OLAP, MOLAP , ROLAP e HOLAP si passa alla fase di progettazione della struttura del cubo ASO. In particolare, dopo l’analisi delle dimensioni che andranno a comporre la struttura, sono stati definiti i metodi di memoriz-zazione e le proprietà di consolidamento. Le dimensioni sono state organizzate
in maniera tale da permettere il recupero dei dati nel più breve tempo possibile e la scrittura dei valori imputati tramite Smart View.
Nel settimo capitolo vengono introdotti i KPIs, che sono sia suddivisi per il settore sanità e per quello dell’industria sia classificati come base o
calco-lati, nell’ultimo caso viene fornita la formula per svilupparli. Inoltre, viene
presentato il problema degli adjustments alla base di quest’applicazione. In particolare, dopo una breve panoramica vengono descritti due casi reali nei quali l’utente avrà necessità di intervenire.
Infine, nell’ottavo e ultimo capitolo viene mostrato il sistema di reporti-stica, sviluppato con OBIEE. Il capitolo è suddiviso in due parti. Durante la prima parte vengono illustrate le possibili scelte per poter mostrare i reports all’utente finale, in questo caso l’implementazione di dashboards interattive. Nella seconda parte viene illustrato il modo in cui vengono sviluppate le analisi alla base dei reports richiesti.
IL CASO DI STUDIO
In questo capitolo, vengono presentate le aziende coinvolte nello sviluppo del-l’applicazione. Nello Specifico, l’azienda committente è Sapio, e l’azienda ese-cutrice è Reply Consulting. Dopo una breve descrizione delle stesse, vengono introdotte le due società dell’azienda Sapio, interessate alla realizzazione del sistema. Queste sono Sapio Life per il settore Sanità e SAPIO Produzione
Idrogeno Ossigeno Srl per il settore industria. Successivamente viene spiegato
l’ambito di riferimento del progetto, cioè il controllo di gestione, che utilizza strumenti quali il budget e il forecast per indirizzare le attività della società verso l’ottimizzazione dei risultati.
2.1
L’azienda committente
La società che ha commissionato la realizzazione dell’applicazione è Sapio, una grossa multinazionale del settore della produzione di gas. La società Sapio è stata fondata a Monza nel 1922, con lo scopo di produrre gas tecnici, successi-vamente è cresciuta a tal punto da coprire tutta la nazione sia nella produzione di gas industriali sia per gas sanitari.
Alla base del successo e della crescita vi è un forte spirito di ricerca e di innovazione tecnologica. Il livello di performance del gruppo, in costante aumento, ha permesso stabilità e crescita, registrando oltre 1450 tra dipendenti e collaboratori e un fatturato del 2013 di circa 457 mln di euro [Sapio 15].
Tale successo permette un continuo investimento nell’evoluzione, in par-ticolare in rilevanti progetti IT, uno dei quali viene rappresentato in questa relazione.
All’interno del Gruppo Sapio si sviluppano numerose società, ognuna con una precisa organizzazione e scopo. In riferimento all’applicazione da
pare verranno mostrate le caratteristiche delle società SAPIO Produzione Idro-geno OssiIdro-geno Srl e Sapio Life, rispettivamente riguardanti la parte industria e la parte sanità.
2.1.1
Sapio Industria
SAPIO Produzione Idrogeno Ossigeno Srl, logo in Figura 2.1, del settore in-dustriale del gruppo Sapio, produce e distribuisce gas per la chimica, per la metallurgia, per il settore alimentare, per il settore ambientale, per l’elettro-nica, per il vetro, per il cemento, per la ceramica e per altre attività di altri settori. In primo piano nelle iniziative ci sono attività volte all’utilizzo di mezzi di trasporto ad idrogeno, come il progetto IniMI. Inoltre, Sapio è stata una delle prime società a credere nelle energie alternative per la mobilità, per que-sto motivo e grazie all’esperienza ventennale, l’impegno per l’innovazione ha portato ad uno sviluppo non indifferente nel campo.
Figura 2.1: Logo della società Sapio Industria
Un altro progetto che si sviluppa nell’ambito della farmaceutica e delle bio-tecnologie è SAPIO 4Pharma. Esso si riferisce ad una fornitura completa di gas prodotti in siti autorizzati da AIFA1 e nel rispetto delle GMP2, quindi in
li-nea con tutti i requisiti di qualità stabiliti dalle principali Farmacopee. Inoltre, la distribuzione dei prodotti avviene seguendo i principi stabiliti dalle GDP3,
garantendo la completa tracciabilità dei lotti lungo la filiera distributiva. Forte dell’esperienza e del know-how acquisiti in oltre 90 anni nel settore, SAPIO ha sviluppato l’offerta 4Food dedicata al “food and beverage”: riferita a prodotti da forno, frutta, verdura, carne, pesce, piatti pronti o bevande. I gas, i servizi, le tecnologie e le applicazioni dell’offerta 4Food di SAPIO sono in grado di soddisfare le diverse esigenze del comparto agroalimentare, nel rispetto degli standard di qualità e sicurezza imposti dalle norme nazionali e internazionali [Sapio 15].
1Agenzia Italiana del Farmaco 2Good manufacturing practices 3Good distribution practices
2.1.2
Sapio Sanità
Sapio Life è un’azienda del Gruppo Sapio, logo in Figura 2.2, che si occupa del-la produzione, commercializzazione e distribuzione di gas tecnici e medicinali, settore in cui, negli anni, ha conquistato una solida posizione di leadership. Sapio Life è nata per ampliare l’offerta di servizi di strutture sanitarie e ospe-daliere e per offrire soluzioni affidabili nelle terapie e nell’assistenza a domicilio. Oggi riunisce competenze, esperienze e professionalità a livelli di eccellenza che hanno fatto della società un interlocutore di primo piano per aziende sanitarie, ospedali, laboratori e centri di ricerca pubblici e privati.
Figura 2.2: Logo della società Sapio Life
Operando sia nell’ambito ospedaliero sia in quello della home care, Sapio Life conosce le soluzioni più efficaci per soddisfare una delle esigenze oggi prioritarie nella sanità: trasferire, quando possibile, le cure dall’ospedale al domicilio del paziente, per un maggiore benessere della persona e una più efficiente organizzazione dell’assistenza.
Con i servizi proposti da Sapio Life è possibile realizzare la continuità di cure tra ospedale e territorio con un ottimale grado di efficienza, affidabilità e semplicità, sia per le istituzioni sanitarie (ASL, ospedali) che per gli utenti finali.
A casa del paziente Sapio Life porta i dispositivi medici, gli accessori e i farmaci necessari allo svolgimento delle terapie, consentendo la continuità delle cure al di fuori delle strutture ospedaliere. Inoltre, avvalendosi di personale sanitario specializzato garantisce ai pazienti fragili e complessi assistenza domi-ciliare con prestazioni di tipo infermieristico, medico-specialistico, riabilitativo, nonché supporto psicologico ed educativo e, nel caso, anche cure palliative.
Alle strutture ospedaliere, oltre alla fornitura dei gas medicinali e alle at-tività relative al loro utilizzo, Sapio Life fornisce servizi ospedalieri e di Total Gas Management4. Grazie alla sinergia con le aziende del Gruppo completa l’offerta per il settore ospedaliero con i servizi di criobiologia e la realizzazione
4Consiste in servizi integrati e modulari di gestione del prodotto: la logistica, la garanzia di purezza fino al punto d’uso, gli aspetti di manutenzione e di sicurezza d’impiego dei gas
di banche biologiche (BioRep Srl) e con la realizzazione di camere iperbariche e dei relativi impianti (Sistemi Iperbarici Srl).
Sapio Life sostiene, come Fornitore Ufficiale della Federazione Italiana Rug-by (FIR), la Nazionale Italiana di rugRug-by grazie a una criocamera mobile per eseguire trattamenti di crioterapia con azoto utili alla prevenzione e alla cura degli infortuni, al recupero dall’affaticamento muscolare e al miglioramento del benessere fisico degli atleti [Sapio 15].
2.2
L’azienda esecutrice
Reply è una società italiana, logo in Figura 2.3, di consulenza di system integra-tion e digital services specializzata nella progettazione e nell’implementazione di soluzioni basate su internet e reti sociali. Fondata nel 1996, ha conseguito risultati economico-finanziari in continua crescita e dal 2000 è quotata sul seg-mento star di Borsa Italiana. Reply SPA è la holding operativa del gruppo, a capo di tutte le società, ognuna specializzata su un particolare business. In particolare Reply Consulting è specializzata in CPM (Corporate Performance Management)[Reply 15].
Con Corporate Performance Management (CPM) si intende un insieme di processi per la gestione, la misurazione e il controllo delle performance aziendali, a seguito dell’idinteficazione degli obiettivi da raggiungere in un dato periodo. In tal senso è da considerarsi sinonimo di Business
Perfor-mance Management (BPM) e Enterprise PerforPerfor-mance Management (EPM)
[Melchert 06]. Concettualmente è collocato nell’area della Business Intelligen-ce e dal punto di vista IT,i proIntelligen-cessi di CPM, vengono considerati come lo sviluppo e avanzamento dei processi di BI.
2.3
Ambito di riferimento
Il progetto considerato consiste nella realizzazione di un’applicazione finaliz-zata a supportare i processi di budget e forecast del controllo di gestione dei settori industria e sanità. Di seguito viene illustrato il compito del controllo di gestione e dei processi di budget e forecast.
2.3.1
Controllo di gestione
Il controllo di gestione è definito come un sistema di metodologie, strumen-ti, processi, ruoli e soluzioni informatiche, il quale vuole indurre comporta-menti individuali e organizzativi in linea con il raggiungimento degli obiettivi aziendali. Esso è un utile strumento per misurare i risultati, controllare le attività e supportare le decisioni aziendali in linea con gli obiettivi strategici [Marasca 08].
Oltre a monitorare i risultati, il controllo di gestione ha come obiettivo quello di indurre comportamenti individuali e organizzativi per il raggiungi-mento degli obiettivi espressi nel piano strategico. Le azioni di monitoraggio si svolgono valutando lo svolgimento delle attività dei dipendenti e dei dirigenti al fine di attribuire premi e punizioni per far si che gli stessi svolgano i propri compiti nel miglior modo possibile e per il bene della società, in linea con gli obiettivi aziendali.
Un buon controllo di gestione riesce ad instaurare nell’azienda uno spirito di collaborazione e organizzazione tale da favorire il raggiungimento dei risultati stabiliti. D’altro canto un cattivo controllo di gestione potrebbe provocare eccessivo stress nei dipendenti e competizione interna.
Il controllo di gestione può essere riferito separatamente a più settori, in questo caso al settore dell’ industria e a quello della sanità. Questo potrebbe portare a cosiddetti “trucchetti contabili” per mostrare risultati più in linea con quelli stabiliti come obiettivo. Un ulteriore risvolto negativo potrebbe essere la miopia manageriale, cioè un eccessivo orientamento al breve termine per ottenere risultati favorevoli a discapito dei risultati a medio e lungo termine. Le fasi del controllo di gestione sono suddivise in:
• Individuazione degli obiettivi da raggiungere, i vincoli da rispettare e le risorse da utilizzare;
• Misurazione e controllo dei risultati ottenuti;
• Determinazione delle cause degli scostamenti e attuazione delle azioni correttive.
Per riuscire a trarre vantaggi da questo processo è necessario che gli obietti-vi siano ben definiti e, soprattutto, realmente raggiungibili. È possibile attuare due tipologie di processo:
• il controllo di retroazione (feedback) realizzato al termine del periodo pre-so in considerazione attraverpre-so la misurazione e il confronto dei risultati ottenuti con quelli prefissati;
• il controllo sulla direzione di marcia, realizzato con un modello predit-tivo, confrontando i risultati prefissati con una proiezione di quelli che potrebbero realizzarsi.
Al contrario della prima, la seconda tipologia permette di attuare azioni cor-rettive già prima che il periodo di riferimento sia completamente concluso, d’altro canto essendo una proiezione dei risultati ha un grado di affidabilità minore rispetto alla misurazione a consuntivo della prima tipologia.
Il compito di attuare i processi di controllo di gestione spetta ai centri di responsabilità, definiti come un’area organizzativa, all’interno della società, con un responsabile a cui è affidato il compito di utilizzare determinati input e risorse per produrre output. Internamente ogni centro di responsabilità ha a disposizione delle risorse per raggiungere gli obiettivi prefissati ed ha le leve decisionali adeguate per operare all’interno della propria area.
I centri di responsabilità sono così suddivisi:
• centri di costo, nei quali l’obiettivo dei responsabili è di ridurre i costi o aumentare la produttività dei fattori produttivi;
• centri di spesa, in cui non vi è la possibilità di trovare una relazione precisa tra input e output, dunque il manager responsabile ha l’obiettivo di non superare un determinato tetto di spesa;
• centri di ricavo, in cui l’obiettivo è costituito dal ricavo conseguito nella vendita di beni e servizi a terzi;
• centri di profitto, nei quali si vuole massimizzare il profitto;
• centri d’investimento, in cui l’obiettivo è generalmente dato dall’otteni-mento di un certo tasso di redditività sul capitale investito (ROI).
2.3.2
Budget e Forecast
Il processo di controllo è sviluppato tramite strumenti tecnici di supporto, chiamati di contabilità direzionale, i quali permettono di rilevare, analizzare e confrontare le prestazioni di tutti gli individui coinvolti nelle attività aziendali [Marasca 08].
Uno dei principali strumenti della contabilità direzionale è il budget, che definisce gli obiettivi economici dell’azienda e li distribuisce per i centri di responsabilità interessati. Spesso si attribuisce il budget non solo a risultati quantitativi monetari, ma anche ad un documento attraverso il quale vengono definite le strategie e le attività da svolgere per raggiungere gli obiettivi pre-stabiliti. Generalmente il budget copre un determinato periodo, solitamente di un anno. Le funzioni del budget sono classificate in:
• definizione degli obiettivi di breve periodo;
• supporto nella scelta delle alternative considerate;
• valutazione dell’operato dei manager;
• coordinamento tra i vari responsabili aziendali;
• responsabilizzazione dei dipendenti sugli obiettivi loro assegnati (tramite centri di responsabilità);
• aumento della motivazione dei dipendenti per il conseguimento degli obiettivi;
• aumento della motivazione degli individui partecipanti alla definizione degli obiettivi di budget.
Un ulteriore strumento utilizzato dal controllo di gestione è il forecast. Prevalentemente si comporta come il budget, cioè viene validato per un arco temporale (tipicamente annuale) e suddiviso in base alle responsabilità. La differenza sostanziale è che il forecast non è un dato definito solamente sulla base di previsioni, ma tiene conto anche del consuntivo conseguito durante il periodo considerato. In particolare, è uno strumento integrativo del budget che aiuta la direzione nello sforzo di operare nell’incertezza del futuro facendo riferimento a dati storici ed attuali e ad analisi dei trend futuri.
L’importanza del forecast sta nel fatto che durante l’esercizio ci si può ren-dere conto che gli obiettivi definiti in fase di budget non siano più realistici e
coerenti con i risultati raggiunti, ciò nonostante tali scostamenti non giustifica-no la modifica del budget ma l’introduzione del forecast come ulteriore punto di riferimento per gli obiettivi.
È possibile classificare il forecast come meccanismo di controllo in corso di marcia [Marasca 08].
Sulla base degli individui coinvolti nella realizzazione del budget, è possibile distinguerne tre tipologie:
1. Imposti (stile direttivo o non partecipativo);
2. Partecipativi;
3. Negoziati.
I budget imposti sono definiti direttamente dalla direzione con un processo top-down, quindi il budget viene preparato dall’alta direzione, con l’ausilio del controller o della funzione Amministrazione. Dove il Controller o il respon-sabile del controllo di gestione è colui che, in tutti i tipi di imprese, consente l’interpretazione e la valutazione dell’attività aziendale. La funzione Ammi-nistrazione, invece, consistente nella rilevazione ordinata (ed eventualmente nell’elaborazione) di informazioni, per lo più di natura economica, sui fatti della gestione aziendale, al fine di costituire la memoria dell’organizzazione.
I vantaggi nell’utilizzare questo tipo di budget sono:
• tempi brevi di elaborazione;
• costi di preparazione inferiori;
• snellezza del processo;
• visione globale e sistemica dei vincoli organizzativi ed economico finan-ziari.
Gli svantaggi invece sono:
• spesso vengono ignorati i bisogni e le problematiche delle varie aree;
• atteggiamenti negativi da parte dei subordinati;
• problemi in fase di delega a causa dello scarso coinvolgimento nel processo di definizione degli obiettivi.
I budget partecipativi sono stabiliti attraverso la definizione degli obiet-tivi e l’allocazione delle risorse in maniera più razionale, il che porta ad un alto livello di motivazione da parte dei subordinati perché avranno partecipato attivamente alla definizione di questi ultimi. Infatti, tutti i manager o respon-sabili di area partecipano al processo, partendo dalla preparazione dei budget funzionali. In questo modo si ha una visione più completa delle necessità e delle possibilità di ogni area.
Di seguito sono elencati i vantaggi nell’utilizzo di questo tipo di budget: • alto grado di coinvolgimento;
• definizione di obiettivi realistici.
Gli svantaggi, invece, sono:
• costi e tempi maggiori rispetto al budget imposto;
• spesso viene sfruttato negativamente dai vari responsabili che favoriscono la propria area cercando di ottenere maggiori risorse o fissando obiettivi più semplici da raggiungere.
Le possibili fasi di un processo di budgeting partecipativo sono: • definizione linee guida dall’alta direzione;
• proposta di budget da parte dei responsabili di ogni centro di responsa-bilità;
• approvazione e distribuzione per i vari livelli di responsabilità;
• verifica fattibilità delle proposte e della coerenza con le linee guida.
I budget negoziati (misti) sono stabiliti attraverso una fase di negoziazione in cui i responsabili richiedono revisioni sugli obiettivi stabiliti, ma la defini-zione finale spetta sempre alla diredefini-zione. È probabilmente il più frequente, anche se con una ampia varietà di combinazioni fra lo stile direttivo e quello partecipativo.
Dall’utilizzo di questo tipo di budget ne conseguono i seguenti vantaggi: • la definizione di budget realistici (riduzione dell’asimmetria informativa
• budget accettati e condivisi dai responsabili di area;
• il coinvolgimento per il raggiungimento degli obiettivi stabiliti.
Gli svantaggi invece sono:
PROGETTAZIONE
Nel seguente capitolo, seguendo la struttura descritta in [Albano 13] per la modellazione di un data warehouse, vengono illustrate le fasi di specifica dei requisiti risultanti dagli incontri con i referenti IT1 e con i responsabili del
con-trollo di gestione. In particolare, viene ripreso il formalismo del Dimensional
Fact Model.
Dopo la raccolta di tutti i requisiti di analisi, vengono stabilite le dimen-sioni, gli attributi e le misure necessarie per le fasi successive.
Al termine dell’analisi viene mostrato lo schema concettuale del data mart elaborato ed infine tradotto nello schema logico, utilizzato per stabilire quali tabelle e in che modo saranno predisposte per il caricamento delle dimensioni e dei dati nel cubo multidimensionale.
3.1
Specifica dei requisiti di analisi
Durante gli incontri con i referenti IT del cliente e tramite estrazioni e do-cumentazioni fornite dagli stessi sono state formalizzate le specifiche per la realizzazione del modello concettuale sul quale sviluppare il cubo in Essbase.
Partendo dal metodo del Dimensional Fact Model sono stati analizzati i “fatti” e le “dimensioni” che verranno sviluppate partendo dal data warehou-se già utilizzato dal cliente. Infatti, l’obiettivo di questa analisi è quello di realizzare la progettazione di un data warehouse semplificato cercando di sin-tetizzare quello esistente, considerando solo le informazioni necessarie allo svi-luppo dell’applicazione. Sulla base del modello risultante verranno corrisposte le tabelle necessarie ad alimentare il cubo Essbase per la fase di modellazione multidimensionale.
1Responsabili del reparto di information technology
Un data warehouse è un magazzino di dati orientato ai soggetti, integrato, non volatile e variabile nel tempo [Albano 13]. I benefici rispetto ad un data-base sono quelli di riuscire ad ottenere un accesso più orientato alle analisi ai fini decisionali-aziendali.
Nella Tabella 3.1 sono riportati i requisiti di analisi principali:
Tabella 3.1: Analisi delle richieste
N. Requisito di analisi
Dimensioni Misure Metriche
1 Totale fatturato di una società per VPS, tavo-la vendite e per mese (o anno) in un dato scena-rio. Struttura Azienda (Codice Società), VPS (Codice, De-scrizione), tavola vendite (Codice, Descrizione), Data (Mese, Anno), Scenario (Nome). Importo, Quantità SUM(Importo)* SUM(Quantità) 2 Delta totale fatturato (con PY2) di una società per VPS, tavola vendite e per mese (o anno) in un dato scenario. Struttura Azienda (Codice Società), VPS (Codice, De-scrizione), tavola vendite (Codice, Descrizione), Data (Mese, Anno), Scenario (Nome). Importo, Quantità SUM(Importo)* SUM(Quantità)
3 Totale recipienti pieni di una società per VPS, tavola vendite, articolo inven-tory e per mese (o anno) in un dato scenario. Struttura Azienda (Codice Società), VPS (Codice, De-scrizione), tavola vendite (Codice, Descrizione), ar-ticolo inventory (Codice, Descrizio-ne), Data (Mese, Anno), Scenario (Nome). Recipienti Pieni SUM(Recipienti Pieni) 4 Totale recipienti vuoti di una società per VPS, tavola vendite, articolo inven-tory e per mese (o anno) in un dato scenario. Struttura Azienda (Codice Società), VPS (Codice, De-scrizione), tavola vendite (Codice, Descrizione), ar-ticolo inventory (Codice, Descrizio-ne), Data (Mese, Anno), Scenario (Nome). Recipienti Vuoti SUM(Recipienti Vuoti)
Così come affermato in [Albano 13] bisogna definire precisamente la granularità del fatto per riuscire ad effettuare analisi dettagliate. In questo caso sarà necessario avere un livello di dettaglio massimo quindi la granularità sarà su una singola vendita e di conseguenza su una singola voce di ricavo. La Tabella 3.2 mostra la descrizione del fatto, le dimensioni e le misure preliminari.
Tabella 3.2: Analisi del fatto: la singola vendita
Descrizione Dimensioni Preliminari Misure Preliminari
Un fatto riguarda la manifestazione di una singola vendita che si traduce co-me un singolo ricavo per un dato articolo ecc...
Articolo Inventory, Artico-lo Commerciale, Linea ticolo Inventory, Linea Ar-ticolo Commerciale, Clien-te, Clente Riclassificato, Commessa, Famiglia ASA, Prodotto ASA, Struttura Azienda, Tavola Vendite, VPS, Tipo Articolo Inven-tory
Ricavi, Quantità, Re-cipienti Pieni, Reci-pienti Vuoti
Nella Tabella 3.3 viene riportata la lista delle dimensioni con la relativa de-scrizione e granularità.
Tabella 3.3: Analisi delle dimensioni
Nome Descrizione Granularità
Articolo Inventory. Il singolo articolo prodotto che, generalmente, viene associato ad un articolo commerciale nel momento in cui avviene la ven-dita. Alcune volte, però, que-sto non si verifica quindi la ven-dita avviene replicando il codi-ce dell’articolo inventory anzi-chè producendo il corrispondete commerciale.
Un articolo.
Articolo Commer-ciale.
Il singolo articolo associato ad una vendita.
Linea Articolo In-ventory.
La singola linea alla quale ap-partiene un articolo inventory.
Una linea.
Linea Articolo Commerciale.
La singola linea alla quale ap-partiene un articolo commercia-le.
Una linea.
Cliente. Il singolo cliente che genera una vendita.
Un cliente.
Cliente Riclassifica-to.
Il singolo cliente associato ad una riclassificazione separata dalla logica dell’acquisto. Un cliente riclassificato non ha spe-cifiche corrispondenze con il cliente.
Un cliente riclas-sificato.
Commessa. La singola commessa alla quale è associata una vendita.
Una commessa.
Famiglia ASA. Una famiglia ASA si riferisce ad’unità dalla quale è ricavare l’ASA3 di appartenenza.
Una Famiglia ASA.
Prodotto ASA. Un prodotto ASA si riferisce ad una riclassificazione dei prodot-ti dalle quale è ricavare l’ASA di appartenenza.
Un prodotto ASA.
Struttura Azienda. Un singolo settore commerciale. Un settore.
Società. Una singola società che rappre-senta il GRUPPO SAPIO.
Una società.
Tavola Vendite. La singola tavola vendite è una riclassificazione della com-binazione dell’articolo commer-ciale, VPS e linea articolo commerciale.
Una tavola ven-dite.
VPS. Il singolo VPS, un codice utile per riclassificare la combinazio-ne licombinazio-nea articolo commerciale e articolo commerciale.
Un VPS.
Tipo Articolo In-ventory.
Il singolo tipo articolo invento-ry, come la VPS per la par-te commerciale, è la riclassifica-zione della combinariclassifica-zione linea articolo inventory e l’articolo inventory.
Un tipo articolo inventory.
Scenario. Il momento al quale si riferisco-no gli importi.
Uno scenario.
Data. Dimensione temporale. Un mese.
Per ognuna delle dimensioni precedentemente elencate, vengono riportati gli attributi correlati, Tabelle 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, 3.11, 3.12, 3.13, 3.14, 3.15, 3.16, 3.17, 3.18, 3.19, 3.20, 3.21.
Tabella 3.4: Dimensioni: Articolo Inventory
Attributo Descrizione
Articolo Inventory ID. ID dell’articolo inventory.
Descrizione Articolo Inventory. Descrizione dell’articolo inventory.
Sottofamiglia. Sottofamiglia di appartenenza dell’artico-lo.
Famiglia. Famiglia di appartenenza dell’articolo.
Unità di misura. Unità di misura utilizzata per quantificare l’articolo.
Tipo Recipiente. Tipo del recipiente utilizzato per confezio-nare l’articolo.
Tabella 3.5: Dimensioni: Articolo Commerciale
Attributo Descrizione
Articolo Commerciale. ID dell’articolo commerciale.
Descrizione Articolo Commer-ciale.
Descrizione dell’articolo commerciale.
Sottofamiglia. Sottofamiglia di appartenenza dell’artico-lo.
Famiglia. Famiglia di appartenenza dell’articolo.
Tabella 3.6: Dimensioni: Linea Articolo Inventory
Attributo Descrizione
Sottolinea. Sottolinea di appartenenza dell’articolo inventory.
Descrizione Sottolinea. Descrizione della sottolinea.
Tabella 3.7: Dimensioni: Linea Articolo Commerciale
Attributo Descrizione
Sottolinea. Sottolinea di appartenenza dell’articolo commerciale.
Descrizione Sottolinea. Descrizione della sottolinea.
Linea. Linea di appartenenza dell’articolo.
Tabella 3.8: Dimensioni: Cliente
Attributo Descrizione
Cliente PDC ID. Codice che identifica un cliente in base all’ID del PDC (Punto Di Consegna).
Descrizione Cliente. Descrizione del cliente composta dal no-me, informazioni di residenza e codice identificativo.
KAM4 Code. Codice che identifica un gruppo di
impre-se con le quali avvengono transazioni di vendite.
Area Geografica. L’area geografica non viene attribuita in base al residenza del cliente o al punto di consegna, ma tramite una logica ben pre-cisa che combina articoli, KAM, regione geografica e Cliente PDC.
Regione. Regione geografica di appartenenza del cliente.
Categoria. Categoria di appartenenza del cliente in base alla sua tipologia.
Tabella 3.9: Dimensioni: Linea Articolo Commerciale
Attributo Descrizione
Sottolinea. Sottolinea di appartenenza dell’articolo commerciale.
Descrizione Sottolinea. Descrizione della sottolinea.
Tabella 3.10: Dimensioni: Cliente Riclassificato
Attributo Descrizione
Cliente Riclassificato. Codice che identifica un cliente riclassi-ficato secondo logiche specifiche definite dall’utente.
Descrizione Cliente Riclassifi-cato.
Descrizione del cliente riclassificato.
Gruppo. Raggruppamento del cliente riclassificato sulla base del codice.
Tabella 3.11: Dimensioni: Commessa
Attributo Descrizione
Commessa code. Codice che identifica una commessa.
Descrizione Commessa. Descrizione della commessa.
Progetto. Un progetto contiene una serie di commes-se.
Tabella 3.12: Dimensioni: Famiglia ASA
Attributo Descrizione
Famiglia ASA code. Codice che identifica una famiglia di un’area strategica d’affari.
Tabella 3.13: Dimensioni: Prodotto ASA
Attributo Descrizione
Prodotto ASA code. Codice che identifica un prodotto di un’area strategica d’affari.
Tabella 3.14: Dimensioni: Struttura Azienda
Attributo Descrizione
Settore Commerciale. Codice che identifica un settore.
Tabella 3.15: Dimensioni: Società
Attributo Descrizione
Società. Codice che identifica una società.
Descrizione società. Nome della società.
Tabella 3.16: Dimensioni: Tavola Vendite
Attributo Descrizione
Codice Tavola Vendite. Codice che identifica una tavola vendite.
Tavola Vendite liv2. Codice che identifica un raggruppamento delle tavole vendite.
Tavola Vendite liv1. Codice che identifica un raggruppamento delle tavole vendite liv2.
Tabella 3.17: Dimensioni: VPS
Attributo Descrizione
VPS. Codice che identifica un VPS per l’articolo commerciale.
Descrizione VPS. Descrizione di un VPS.
VPS liv2. Codice che identifica un raggruppamento dei VPS.
VPS liv1. Codice che identifica un raggruppamento dei VPS liv2.
Tabella 3.18: Dimensioni: Tipo Articolo Inventory
Attributo Descrizione
VPS INV. Codice che identifica un VPS per l’articolo inventory.
Descrizione VPS INV. Descrizione di un VPS.
VPS INV liv2. Codice che identifica un raggruppamento dei VPS INV.
VPS INV liv1. Codice che identifica un raggruppamento dei VPS INV liv2.
Tabella 3.19: Dimensioni: Data
Attributo Descrizione
Mese. Un mese.
Trimestre. Un trimestre.
Anno. Un anno.
Tabella 3.20: Dimensioni: Scenario
Attributo Descrizione
Nome Scenario. Lo scenario che può essere consuntivo,
budget, forecast.
Attributo Descrizione
Versione. Versione di caricamento.
Alcuni attributi sono in relazione seguendo delle gerarchie dimensionali, nella Tabella 3.22 vengono elencate specificando gli attributi coinvolti e il tipo di gerarchia.
Tabella 3.22: Analisi delle gerarchie dimensionali
Dimensione Descrizione Tipo di gerarchia
Articolo Inven-tory.
ID ⇒ Sottofamiglia ⇒ Famiglia Bilanciata
Articolo Commerciale.
ID ⇒ Sottofamiglia ⇒ Famiglia Bilanciata
Linea Articolo Inventory.
Sottolinea ⇒ Linea Bilanciata
Linea Articolo Commerciale.
Sottolinea ⇒ Linea Bilanciata
Cliente Riclassi-ficato.
Codice ⇒ Gruppo Bilanciata
Commessa. Codice ⇒ Progetto Bilanciata
Struttura Azien-da.
Settore ⇒ Filiale Bilanciata
Tavola Vendite. Codice ⇒ Liv2 ⇒ Liv1 Bilanciata
VPS. Codice ⇒ VPS Liv2 ⇒ VPS Liv1 Bilanciata
Tipo Articolo Inventory.
Codice INV ⇒ Liv2 INV ⇒ Liv1 INV
Bilanciata
Data. Mese ⇒ Trimestre ⇒ Anno Bilanciata
Le misure frutto di analisi sono importo, quantità, recipienti pieni e
reci-pienti vuoti, descritte nella Tabella 3.23. Tutte risultano semi-additive rispetto
alla dimensione Scenario e Versione, in quanto non avrebbe senso aggregarle su scenari o versioni diverse mentre l’aggregazione sulla base delle altre dimensio-ni è necessaria, invece, le misure potrebbero essere aggregate per dimensiodimensio-ni, quali Articolo Inventory, quindi per Famiglia oppure per la Categoria della dimensione Cliente. Si noti che aggregare tali misure per Scenario comporte-rebbe la somma dei valori di Budget, Forecast e Consuntivo che produrcomporte-rebbe un risultato senza significato. Stessa cosa per la Versione, che indica diversi caricamenti come, per esempio, quelli di test.
Tabella 3.23: Analisi delle misure
Misure Descrizione Aggregabilità Calcolata
Importo L’importo generato da una vendita
Semi-additiva No
Quantità Quantità vendute in una singola transazio-ne.
Semi-additiva No
Recipienti Pieni Recipienti pieni in ri-ferimento agli articoli prodotti.
Semi-additiva No
Recipienti Vuoti Recipienti vuoti in ri-ferimento agli articoli prodotti.
Semi-additiva No
3.2
Cambiamento delle dimensioni
Un attento confronto con i responsabili funzionali della società ha permesso di stabilire in che modo trattare le dimensioni con attributi che potrebbero cambiare nel tempo.
Come descritto in [Albano 13], esistono quattro tipologie per il trattamen-to delle dimensioni in queste situazioni. In particolare, tre sono riferite al-la dimensioni con attributi che cambiano raramente (slowly changing
dimen-sions), mentre la restante è riferita alle dimensioni con attributi che
cambia-no frequentemente. Di seguito vengocambia-no descritte le quattro tipologie appena menzionate:
• Tipo 1 - Perdita della storia: il valore dell’attributo dimensionale mo-dificato viene sostituito con il nuovo valore. Questa è prevalentemente la soluzione più immediata, ma non permette di storicizzare i cambiamenti.
• Tipo 2 - Storicizzazione: in questo caso viene aggiunta una nuova riga alla tabella dimensionale, creando una nuova entità. Tutti i fatti verificati precedentemente alla modifica, continuano a far riferimento alla vecchia entità, mentre tutti i fatti che si verificano successivamente alla modifica faranno riferimento a quella nuova. Questa tipologia permette di storicizzare il cambiamento ma aumenta la mole di dati in fase di caricamento.
• Tipo 3 - Storicizzazione con data cambiamento: questa tipologia permette di mantenere lo storico così come il tipo 2, inoltre consente di memorizzare anche il momento temporale in cui avviene il cambiamento. Per ottenere questo risultato vi è la necessità di sostituire il vecchio attributo con tre campi: Attributo, Nuovo_Attributo, Data_modifica.
• Tipo 4 - Elevata frequenza di cambiamento: per gli attributi con un’alta frequenza di cambiamento è preferibile creare due tabelle dimen-sionali contenenti, in una gli attributi che rimangono invariati e nell’altra gli attributi che variano frequentemente.
In questo caso di studio non è necessario tenere traccia delle modifiche dato che un attributo modificato viene sempre visto con il nuovo valore senza “spaccare” le analisi tra vecchio e nuovo attributo. Per questo motivo tutte le dimensioni sono trattate con il Tipo 1.
3.3
Progettazione concettuale di un data mart
Sulla base delle informazioni recepite, è stato disegnato lo schema concettuale di un data mart, mostrato in Figura 3.1. Questo modello costituisce un’utile descrizione formale dei requisiti di analisi emersi. Così come mostrato nella figura, le dimensioni frutto di analisi sono numerose, ma tutte strettamente necessarie per riuscire a raggiungere il livello di dettaglio richiesto. In questo caso lo schema concettuale iniziale corrisponde con quello finale.
La struttura risulta essere abbastanza articolata, ma rispecchia totalmen-te la situazione che verrà successivamentotalmen-te sviluppata. Come si evince dalla figura, ci sono alcune dimensioni, come Prodotto ASA e Famiglia ASA che
Figura 3.1: Schema concettuale di un data mart
sono opzionali. Esse sono utili per risalire all’ASA5 di appartenenza, ma solo in riferimento ad alcuni articoli. Al contrario, tutte le altre dimensioni sono sempre presenti per l’identificazione di una transazione.
3.4
Classificazione delle tabelle
Come affermato in [Albano 13] le tabelle interessanti possono essere classificate in tre categorie:
1. Entità Evento, sono tabelle contenenti record che rappresentano eventi d’interesse per i processi di business da analizzare. Tali tabelle, per es-sere considerate entità evento, devono possedere due requisiti. Uno di questi è quello di descrivere eventi o transazioni che si verificano in un determinato istante, l’altro è quello di contenere misure o quantità che possono essere aggregate.
In questo caso la tabella che è considerata di entità evento è quella dei
Ricavi. Essa descrive le transazioni che avvengono in un determinano
momento, il che rispetta il primo requisito. Inoltre, contiene i campi considerati come misure (importo, quantità, recipienti vuoti e
recipien-ti pieni) sui quali è possibile aggregare, rispettando, così, il secondo
requisito.
2. Entità Componente, sono tabelle che rappresentano la base per la pro-gettazione delle dimensioni nel modello concettuale. Esse definiscono per ogni entità evento i dettagli necessari e sono legate da una relazione uno a molti.
Le tabelle considerate in questo modo sono quelle che si riferiscono alle anagrafiche dell’applicazione, quindi cliente, articolo, commessa, ecc.
3. Entità di Classificazione, sono tabelle collegate ad un’entità componente da una catena di relazioni uno a molti. Queste entità generalmente rap-presentano gerarchie integrate nello schema dati.
In questo caso le gerarchie non sono altro che campi contenuti nelle tabelle classificate come entità componente.
3.5
Progettazione logica del data warehouse
In questa fase, lo schema concettuale finale del data mart viene tradotto in uno schema relazionale, con i fatti e le tabelle delle dimensioni, organizzate secondo uno schema a stella. Il fatto, in questo caso la singola transazione, viene memorizzata valorizzando le misure rappresentate nel data mart, quali
importo, quantità, recipienti pieni e recipienti vuoti. In combinazione di un
singolo fatto vengono considerate tutte le informazioni che corrispondono alle dimensioni analizzate.
AMBIENTE DI SVILUPPO
In questo capitolo vengono presentate le tecnologie utilizzate per sviluppare l’applicazione descrivendo dettagliatamente le loro funzionalità. In particolare, inizialmente, vengono presentate le logiche di funzionamento dei componenti di Oracle Hyperion Essbase e in che modo sono integrate tra loro. Inoltre, vengono descritte le caratteristiche dei cubi Essbase, che saranno analizzate nel capitolo di modellazione multidimensionale. Successivamente, sarà data una breve panoramica sugli strumenti di reportistica quali Oracle Hyperion
Smart View e Oracle Business Intelligence.
4.1
Componenti applicative utilizzate
Di seguito vengono elencati i componenti utilizzati per la realizzazione del sistema in questione:
• Hyperion Essbase
• OBIEE
• Oracle Hyperion Smart View For Office
• DB di proprietà del cliente come appoggio per le tabelle
Dalle tabelle ricevute, seguendo lo schema concettuale precedentemente illustrato, sono state utilizzate delle “load rule” per generare e caricare le di-mensioni sul cubo Essbase.
Successivamente, con l’applicazione OBIEE è stato mappato il cubo e sono state generate le dimensioni su repository di OBIEE.
Da qui il tool di interfaccia permettere di combinare gli incroci necessari per
estrapolare il dato memorizzato in Essbase e realizzare i KPIs utili per formu-lare i report richiesti.
Un ulteriore strumento che si interfaccia con il cubo Essbase è Smart View, che genera la lista delle dimensioni dalle quali è possibile navigare nella mul-tidimensionalità del cubo ed estrapolare i dati nei vari incroci.
In più, Smart View permette di imputare i dati e salvarli nel cubo nella spe-cifica posizione selezionata. In particolare, questa funzionalità sarà utilizzata dall’utente per effettuare gli adjustement sul dato dopo opportune verifiche.
4.2
Hyperion Essbase
Essbase, è un “OLAP database software” o MDBMS (Multidimensional Data-base Management System). Esso consente di creare e gestire dei dataData-base mul-tidimensionali, cioè repository nei quali sono memorizzati i dati con strutture di array multidimensionali, implementando la tabella dei fatti direttamente come un cubo multidimensionale [Essbase].
Un’applicazione Essbase è invece una sorta di contenitore che può compren-dere più database. Essbase fornisce inoltre enormi potenzialità di calcolo, in particolare un’ampia libreria di funzioni (ad esempio funzioni finanziarie o fun-zioni per il calcolo della varianza tra i membri di una dimensione ecc.), per soddisfare complesse richieste di analisi.
L’architettura di Essbase è composta da tre livelli, come riportato nella Figura 5.1:
1. un client-tier, composto dai client Essbase, come ad esempio Oracle
Hyperion Smart View for Microsoft Office o la stessa Essbase Admi-nistration Services Console (EAS). Attraverso quest’ultima è possibile
utilizzare le Load Rule per gestire o modificare le proprietà dell’Outline (illustrata nei prossimi paragrafi);
2. un middle-tier, che include servizi come Oracle Essbase Administration Server;
3. un database-tier, che è costituito dal server Essbase.
La comunicazione tra il client e il middle tier e tra il middle e il database tier avviene tramite http, mentre le comunicazioni tra le sorgenti di dati e il
Figura 4.1: Architettura Essbase
catalogo dei metadati con il middle e il database tier avvengono tramite JDBC e ODBC.
Tutte le componenti delle applicazioni Essbase risiedono sul server, che for-nisce numerose funzionalità analitiche da un’unica infrastruttura. Il client si occupa solo di recuperare e visualizzare i dati che si trovano sul server.
Essbase fornisce un linguaggio di accesso ai database multidimensionali (Ma-xL) con il quale è possibile automatizzare i task di amministrazione e manu-tenzione.
Administration Services è l’interfaccia di Essbase per gli amministratori di si-stema; essa è una console che consente di progettare, sviluppare e gestire più server, applicazioni e database da un unico punto d’accesso.
Le applicazioni OLAP, come già affermato, devono necessariamente fornire, tra le altre cose, una visione multidimensionale dei dati e importanti capacità di calcolo.
I database multidimensionali sono dunque fondamentali nei sistemi OLAP per aggregare, calcolare e recuperare una varietà di sottoinsiemi di dati. In parti-colare la fase di sviluppo è stata effettuata sulla console di amministrazione, EAS (Essbase Administration Console). Nei prossimi paragrafi verranno de-scritte le funzionalità principali utilizzate per lo sviluppo in questo specifico progetto.
4.2.1
Outline
L’outline di un cubo Essbase è la struttura che ne definisce tutti i metadati, mostrando le dimensioni e i membri in una struttura ad albero e indicando le relazioni strutturali, matematiche e di consolidamento tra i membri. La strut-tura definita nell’outline determina come sono memorizzati i dati nel database [Essbase].
La creazione di un cubo Essbase genera automaticamente un outline, la quale ha lo stesso nome del database e viene memorizzato in un file con estensione .otl.
Il livello di consolidamento più alto nell’outline del database è costituito dalle dimensioni. Una dimensione è composta da uno o più membri e a loro volta ogni membro può essere composto da altri membri.
Quando viene creata una dimensione occorre specificare come consolidare i va-lori dei suoi singoli membri. Un consolidamento (o gerarchia) è costituito da un insieme di membri in un ramo dell’albero dell’outline.
Essbase, per descrivere i ruoli e le relazioni tra i membri dell’outline, utilizza i seguenti termini:
• un membro padre è un membro che ha un ramo sotto di esso;
• un membro figlio ha un padre sopra di sè;
• due o più membri sono detti fratelli se sono figli dello stesso padre e si trovano alla stessa generazione;
• i discendenti di un certo membro sono tutti i membri che si possono raggiungere percorrendo i rami che scendono da quel membro;
• gli antenati di un certo membro sono quelli che si possono raggiungere percorrendo i rami che salgono da quel membro;
• la radice è il membro che non ha nessun membro padre;
• una foglia è un membro che non ha figli;
• la generazione si riferisce al livello di consolidamento sotto una dimen-sione, la generazione 1 e i numeri di generazione crescono di un’unità scendendo nell’outline dalla radice alle foglie;
• il livello si riferisce anch’esso al consolidamento sotto una dimensione ma l’ordinamento numerico è invertito rispetto a quello usato per le generazioni: le foglie hanno livello zero e il livello della radice varia a seconda della profondità del ramo che si percorre.
4.2.2
Confronto tra cubo ASO e BSO
Esistono due tipi di storage per i database Essbase:
1. BSO (Block Storage Option);
2. ASO (Aggregate Storage Option).
Le applicazioni BSO si basano su un metodo di memorizzazione dei da-ti completo, cioè tutda-ti i dada-ti contenuda-ti nel cubo sono memorizzada-ti in blocchi di celle, questo permette di caricare dati ad ogni livello di gerarchia. Men-tre le applicazioni ASO si basano su un metodo di memorizzazione aggregato comportando il fatto che i dati siano caricati solamente al livello foglia delle gerarchie. Vi sono diverse differenze fra questi due tipi di storage che conse-guono anche una serie di funzionalità e, a loro volta, giustificano l’utilizzo di una o dell’altra modalità che verranno illustrate di seguito.
La differenza principale consiste nel fatto che un cubo BSO memorizza tutti i livelli di tutte le gerarchie, fornendo così ottime prestazioni nel recupero dei dati ma richiedendo un’elevata quantità di memoria. Pertanto un database BSO non è “scalabile”, in quanto diventa inefficiente se il numero di dimensioni e la quantità di dati sono molto elevati.
Un database ASO (la cui logica di funzionamento è più simile a quella di un data warehouse relazionale) memorizza tutte le foglie, mentre i livelli superiori sono memorizzati solo tramite aggregazioni dinamiche richiamate in run-time, cioè quando vi è un’interrogazione dal client. Un cubo ASO dunque è molto più “leggero” rispetto ad un BSO.
Per estrarre e manipolare i dati da un cubo BSO vi sono tre alternative:
• utilizzare il linguaggio MDX;
• utilizzare un report script;
• utilizzare un Calculation Script, un linguaggio di programmazione pro-cedurale specifico per Hyperion Essbase che dispone di un’ampia libre-ria di funzioni (la modalità più efficiente che però fornisce solo una formattazione standard dei dati).
