tesi di laurea - francesco golfierifrancescogolfieri.com/images/tesi_bi_golfieri.pdf · management...
TRANSCRIPT
ALMA MATER STUDIORUM - UNIVERSITÀ DI BOLOGNA
FACOLTÀ DI INGEGNERIA
CORSO DI LAUREA MAGISTRALE IN INGEGNERIA GESTIONALE
TESI DI LAUREA
in
Business Intelligence
METODI E STRUMENTI DI BUSINESS
INTELLIGENCE PER I PROCESSI
DI CICLO ATTIVO: un caso di studio
in un’azienda di servizi
CANDIDATO:
Francesco Golfieri
RELATORE:
Chiar.mo Prof. Fabio Grandi
CORRELATORI:
Ing. Giorgio Gabbani
Chiar.mo Prof. Stefano Rizzi
Chiar.ma Prof.ssa Maria Rita Scalas
Anno Accademico 2011/2012
Sessione III
Pag. 1
Indice
1 Introduzione ................................................................................................... 4
1.1 Sommario .................................................................................................. 5
2 Company profile ICONSULTING ................................................................ 6
2.1 Cenni sulla metodologia progettuale BE - LEAN .................................... 7
3 Business Intelligence e Decision Support System ...................................... 10
3.1 Aspetti storici del settore e della proposta Microsoft ............................. 10
3.2 Data warehousing e Business Intelligence ............................................. 14
3.2.1 Teoria Relazionale ......................................................................... 16
3.2.2 Teoria della Normalizzazione ....................................................... 18
3.2.3 Star Schema & Snowflake Schema ............................................... 20
3.3 Struttura di un DSS, studio su diverse alternative .................................. 25
3.3.1 Import ............................................................................................ 28
3.3.2 Staging Area .................................................................................. 30
3.3.3 Data Mart ....................................................................................... 31
3.4 Cubi Multidimensional OLAP ................................................................ 32
4 Aspetti tecnici e strumenti utilizzati ............................................................ 34
4.1 Specifiche HW ........................................................................................ 34
4.2 Specifiche SW ........................................................................................ 35
4.2.1 SQL Server .................................................................................... 35
4.2.2 SSIS ............................................................................................... 36
4.2.3 SSAS ............................................................................................. 40
4.2.4 Interfaccia Excel ............................................................................ 44
4.2.5 MS SharePoint ............................................................................... 44
5 Analisi funzionale del caso ......................................................................... 46
5.1 Processi di Ciclo Attivo .......................................................................... 46
5.2 Contingenze al caso specifico ................................................................. 48
5.2.1 Rateizzazione e Fatturazione ......................................................... 50
Pag. 2
5.2.2 Work Breakdown Structure ........................................................... 53
5.3 Bacino d’utenza ...................................................................................... 56
6 Modello dei dati .......................................................................................... 57
6.1 Analisi del database sottostante il sistema Transazionale ...................... 57
6.2 IMPORT ................................................................................................. 59
6.2.1 Criticità dei dati in ingresso .......................................................... 59
6.2.2 Scelta del criterio incrementale\full-refresh .................................. 62
6.2.3 Algoritmo di Upsert per la gestione dei dati incrementali ............ 63
6.3 STAGING AREA ................................................................................... 64
6.3.1 Relazione con i Work Breakdown Elements ................................ 69
6.4 Data mart e Cubo Multidimensionale ..................................................... 73
6.4.1 Studio sulla creazione della tabella dei fatti (Stock) ..................... 73
6.4.2 Algoritmo di creazione della tabella dei fatti (Stock) ................... 75
6.4.3 Denormalizzazione dei dati ........................................................... 87
6.4.4 Implementazione del cubo Analysis Services ............................... 89
6.4.5 Calculated Members in MDX (con cenni sul query language
multidimensionale) ...................................................................................... 90
7 Fruizione dei dati ......................................................................................... 97
7.1 Distribuzione delle informazioni attraverso Intranet aziendale e
Microsoft Excel ............................................................................................... 97
7.2 Ambito: Rate scadute (Passato) .............................................................. 99
7.2.1 Valori numerici: “Stock” ............................................................... 99
7.2.2 Valori numerici: “Conteggio Contratti” ...................................... 102
7.2.3 Dimensione “Tempo P” .............................................................. 102
7.2.4 Altre Dimensioni ......................................................................... 102
7.3 Ambito: Rate a scadere (Futuro) .......................................................... 104
7.3.1 Valori numerici: “A Scadere” ..................................................... 104
7.3.2 Dimensione “Tempo F” .............................................................. 105
7.3.3 Altre Dimensioni ......................................................................... 105
7.4 Descrizione della reportistica ............................................................... 105
Pag. 3
7.4.1 Analisi Scaduto per Area e Servizio ........................................... 105
7.4.2 Analisi Rate scadute e stock ........................................................ 107
7.4.3 Analisi Stock iniziale per anzianità ............................................. 109
7.4.4 Analisi Rate scadute per area con dettaglio Contratto ................ 111
7.4.5 Analisi Fatturato e LT di fatturazione ......................................... 113
7.4.6 Analisi rate a scadere................................................................... 114
8 Conclusioni ................................................................................................ 116
9 APPENDICE A: Indice delle figure ......................................................... 117
10 APPENDICE B: Bibliografia .................................................................... 119
11 Ringraziamenti ............................................ Error! Bookmark not defined.
Pag. 4
1 Introduzione
Quello della razionalizzazione delle informazioni aziendali e del controllo del
loro “percorso” dalla sorgente (di solito un sistema transazionale) fino ai
decisori è un tema ormai sdoganato, oggetto consolidato di studio accademico
informatico-gestionale così come di applicazione pratica.
Le tecniche specifiche della Business Intelligence, come verrà spiegato, sono
caratterizzate da un ciclo di vita straordinariamente lungo per i canoni
dell’Information Technology.
Proprio per questo il settore della consulenza in BI e quello dello sviluppo e
commercializzazione di software ad essa finalizzati, pur avendo una storia che
inizia circa 30 anni fa, sono tuttora solidi nella domanda e presentano notevoli
opportunità di mercato.
Nonostante siano cambiati in modo radicale i metodi di fruizione, aumentate
esponenzialmente le potenzialità di calcolo e ampliate le basi d’utenza si
constata che la teoria sottostante il data warehousing non abbia subito grandi
modifiche.
Il presente lavoro di Tesi consiste nella relazione dettagliata riguardante un
progetto completo di data warehousing, Business Intelligence e Performance
Management realizzato dal candidato presso ICONSULTING Srl da Luglio
2012 a Gennaio 2013, a partire dallo studio funzionale preventivo, fino alla
consegna finale al Cliente e ai successivi processi di quadratura, formazione,
testing e bug-fixing.
Il Cliente è un’azienda di servizi di grandi dimensioni attiva su tutto il territorio
nazionale e l’oggetto specifico dell’attività consulenziale è il suo processo di
Ciclo Attivo (afferente quindi la divisione amministrativa).
L’applicazione risultante si interfaccia e integra con altre realizzate per lo stesso
Cliente (Controllo di gestione, Acquisti), con cui condivide parte della struttura
dimensionale sottostante.
A corollario della relazione stessa si intendono introdurre tutti gli elementi
teorici utili alla comprensione dell’attività svolta e le riflessioni sulle scelte
consulenziali e tecniche applicate, con un approfondimento privilegiato sui punti
cruciali del progetto.
Pag. 5
1.1 Sommario
Il Capitolo 2 è una presentazione dell’azienda ICONSULTING e del suo metodo
di project management, il Capitolo 3 introduce l’argomento dei “Decision
Support System” e della loro evoluzione, entrando nel merito della teoria
relazionale.
Nel Capitolo 4 sono descritte le infrastrutture Hardware e Software utilizzate nel
progetto.
Nel Capitolo 5 viene messa da parte la tematica strettamente informatica per
lasciare spazio all’analisi funzionale del caso, con rimandi teorici sui processi
aziendali di Ciclo Attivo.
Concluse le premesse, il Capitolo 6 è quello centrale dell’intera relazione: esso
contiene la documentazione vera e propria di tutti gli sviluppi attuati, suddivisi
in “Import”, “Staging Area” e “Data Mart / Cubo Multidimensionale”.
Il Capitolo 7 tratta della reportistica, descrivendo i criteri utilizzati nella
rappresentazione delle informazioni, i prospetti effettivamente composti e i
metodi di delivery di questi agli utenti attraverso un sito intranet aziendale.
Il Capitolo 8, a chiosa, contiene la sintesi dei risultati e considerazioni sui
possibili sviluppi futuri.
Pag. 6
2 Company profile ICONSULTING
ICONSULTING Srl è un’organizzazione privata specializzata nella
progettazione e realizzazione di sistemi di data warehouse, Business Intelligence
e Corporate Performance Management con sedi a Casalecchio di Reno
(Bologna), Milano e Roma e attività su tutto il territorio nazionale.
E’ partner di riferimento (e ha progetti in produzione) di tutti i più importanti
fornitori di software internazionali: si citano per esempio Oracle, Microsoft,
IBM e SAP.
Le sue origini (1998) sono radicate nel Laboratorio di Data Warehouse e
Business Intelligence interno ad un importante consorzio di ricerca.
Nel 2001 ICONSULTING viene fondata come spin-off del gruppo storico del
laboratorio. Dopo i suoi 11 anni di storia l’azienda si è affermata come un punto
di riferimento sul mercato: può vantare oltre 300 progetti realizzati su più di 100
clienti, con una crescita annua dei fatturato del 12% nel 2010 e del 14% nel
2011. L’organico conta oltre 90 persone ed è composto per oltre il 50% da
ingegneri (un terzo dei quali ingegneri gestionali).
In virtù della professionalità riconosciuta e del forte legame col mondo
accademico i consulenti tengono periodicamente seminari presso le facoltà e le
più prestigiose Master School dell’Università di Bologna.
ICONSULTING dispone di un laboratorio interno permanente con personale
dedicato alla ricerca sui nuovi prodotti in collaborazione con l’Università: il
DNA da ricercatori è molto evidente, tanto che il 25% del tempo in azienda è
allocato in formazione e R&D.
Le attività includono il beta testing di diversi strumenti tecnologici, con
collegamento diretto ai laboratori di sviluppo dei software presso le case
produttrici per garantire al cliente rapidità e massimo aggiornamento.
Ogni progetto viene svolto secondo una metodologia (BE - LEAN) atta a
garantire l’aderenza alle specifiche e la riduzione dei rischi.
Pag. 7
2.1 Cenni sulla metodologia progettuale BE - LEAN
Figura 1 - Schema metodologia BE – LEAN
La metodologia di project management utilizzata in ICONSULTING è
approfondimento e “personalizzazione” del celebre modello detto “Spiral
Development” di Boehm [1], in cui le fasi di sviluppo, prototipazione, testing e
documentazione si sovrappongono iterativamente, consegnando al Cliente
frazioni funzionanti del progetto completo ad intervalli di tempo predefiniti.
Il numero di consegne e la durata di ogni ciclo dipendono dalle dimensioni del
progetto.
Le principali caratteristiche e punti di forza del metodo sono:
La gestione per fasi iterative: l’analisi funzionale apre un circolo
incrementale di Progettazione \ Sviluppo e Testing \ Documentazione \
Collaudo e Delivery.
La scomposizione della soluzione in funzionalità modulari espresse dalle
specifiche, ognuna delle quali dev’essere quantificabile, associata ad un
esplicito valore aggiunto per il cliente e collaudabile separatamente
Pag. 8
La scomposizione temporale del progetto in un insieme di rilasci, con
periodicità massima di 30 giorni, che accrescono incrementalmente il
valore consegnato al cliente
Un piano progettuale basato sugli obiettivi di business e sulle esigenze del
cliente, che sia flessibile e rinegoziabile ad ogni release.
Gli obiettivi del metodo sono:
Definizione corretta di requisiti e vincoli progettuali
Ottimizzazione tempi e costi di esecuzione
Rispetto delle scadenze e dei costi
Rapida gestione di problemi e rischi
Agevolazione della comunicazione tra gli stakeholder di progetto
Documentazione completa di tutte le fasi del progetto
Garanzia del passaggio di competenza agli utenti, supportandoli nel
cambiamento tecnico-organizzativo introdotto
Nel metodo BE-LEAN le fasi pre-progettuale e post-progettuale rivestono
un’importanza fondamentale quanto le fasi “core”: la prima è basilare per capire
come l’uso dell’informazione possa coadiuvare il raggiungimento degli obiettivi
di business del cliente, mentre l’Enterprise Assessment finale, che affianca il
supporto On-Going nell’operatività (ovvero il supporto offerto in tempo reale,
mentre l’utente utilizza già il sistema) e l’eventuale manutenzione evolutiva, ha
l’obiettivo di “misurare” oggettivamente il livello di successo del progetto
attraverso il monitoraggio di 5 fattori critici di successo:
Risorse umane – Soddisfazione
Qualità del dato – Sua consistenza e significatività
Modelli di controllo – Per il monitoraggio continuo delle performance
Infrastruttura tecnica – Necessaria per la solidità del progetto
Organizzazione e cultura – “Impattate” adottando le nuove tecnologie
Comparando BE-LEAN con il metodo progettuale Kimball Lifecycle
Methodology [2] ideato da R. Kimball (considerato uno tra i “padri fondatori”
del data warehousing) sono evidenti, assieme alle analogie, le differenze tra i
due.
Pag. 9
L’approccio KLM (in figura 1) differisce in primis per la sua focalizzazione
sulla progettazione a discapito dello sviluppo (come coerente con il core
business di KG), d’altra parte in esso si riscontra il consolidato processo
iterativo e circolare già citato in precedenza.
Figura 2 - Kimball Lifecycle Methodology (Kimball Group)
La difformità chiave, che sicuramente potrebbe essere spunto per molte
riflessioni successive, è individuabile nell’ “ampiezza” della circolarità: nel
metodo Kimball essa comprende anche tutta la fase di definizione dei requisiti di
business, disegnando così un progetto che, a tutti gli effetti, ha un inizio ma non
necessariamente una conclusione definita ex-ante (è evidente che il diagramma,
infatti, sia circolare e non a spirale).
L’approccio BE-LEAN applicato nel caso in esame si presenta, in questi aspetti,
più pragmatico e improntato alla risoluzione di uno specifico problema (o
genericamente alla reingegnerizzazione di un processo).
Seguendo questo approccio, ciascuna fase viene supportata da procedure e
istruzioni operative facenti parte del sistema qualità aziendale certificato ISO
9001:2000.
Pag. 10
3 Business Intelligence e Decision Support System
3.1 Aspetti storici del settore e della proposta Microsoft
Con il termine Business Intelligence si definiscono le attività rivolte al fornire
agli operatori “business”, qui intesi come contrapposti agli operatori “IT”, le
informazioni e gli strumenti di cui essi hanno bisogno per compiere decisioni
operative così come strategiche [3].
Questa disciplina, ramificazione funzionale del data warehousing, ha trovato
riscontro pratico (come detto essenzialmente sempre nella stessa forma) fin dagli
anni 80 e continua a godere di un successo straordinariamente duraturo: soltanto
a metà degli anni 2000 hanno iniziato ad emergere segni di maturità nel settore.
Uno di questi, particolarmente inerente al caso oggetto di questa Tesi, è
l’emergenza di fornitori software single-source, ossia che propongono la propria
offerta come autosufficiente alla completa soddisfazione delle necessità
progettuali di un generico cliente.
L’affidarsi ad un fornitore di questo tipo rappresenta, per un’azienda cliente, una
variazione e un’auspicabile riduzione del rischio progettuale: se utilizzando
fornitori diversi ci si espone all’eventualità di incontrare problemi di
incompatibilità e basse performance legate alla predisposizione di interfacce tra
sistemi diversi, unificando il portafoglio di acquisti in una sola voce e
sviluppando una soluzione servendosi di una piattaforma integrata questi
dovrebbero essere minimizzati. L’altra faccia della medaglia è l’aumento del il
rischio di lock-in nei confronti del fornitore unico: questa seconda ipotesi è
quella preferita dal Cliente nel caso in esame.
Essendo il fornitore unico Microsoft, attuale sviluppatrice di tutti i sistemi
operativi utilizzati in azienda e della suite Office installata su tutti i propri PC,
così come di molti altri software di uso quotidiano (escluso il sistema gestionale,
unico fronte su cui affrontare problematiche di interfaccia), il rischio di lock-in è
stato ignorato data la fattuale necessità di rimanervi vincolati (si potrebbe dire
che il rischio sia stato ignorato perché il lock-in era già in essere).
Pag. 11
Ritornando alle definizioni di base, quella di “data warehousing” appare
piuttosto ostica: il corpus tecnologico di quest’area tecnologica copre qualsiasi
aspetto legato all’uso delle basi dati in azienda, dall’ottimizzazione degli output
dei sistemi sorgenti alla progettazione delle strutture cui attingeranno i sistemi di
reportistica.
Visto dal lato IT, che potremmo definire come l’ottica “a monte” del progetto, il
DSS (Decision Support System) invece è il sistema dedicato ai processi di
trasformazione dei dati “grezzi” provenienti da una qualsiasi fonte dati semi-
automatizzata in informazioni rilevanti per i decisori.
Visto invece dal lato Business, ove si trovano i destinatari delle informazioni di
cui sopra, “un sistema DSS è un sistema informativo dedicato ad aiutare i
responsabili del business in tutta la gestione dell’impresa, in modo da
permettere decisioni più veloci, più mirate e più efficaci”. [4]
E’ dunque corretto dire che un progetto di Business Intelligence è volto a
supportare il processo decisionale del Cliente, servendosi delle tecnologie di
data warehousing.
Molte delle aziende fornitrici di software e servizi legati al mondo dei DSS
hanno cercato, nel corso degli anni, di posizionarsi come fornitori single-source
attraverso acquisizioni successive di aziende più piccole a copertura di aree (o di
singole funzioni) prima sguarnite.
Per i fornitori che l’hanno attuata, questo tipo di crescita ha generato portafogli
di offerta enormi contenenti software non sempre coordinati ed integrati tra loro
(né, nei casi peggiori, in grado di integrarsi tra loro agevolmente).
Risulta chiaro che le aziende con fortissime competenze nello sviluppo di
sistemi atti alla gestione di database relazionali erano e sono le uniche che
possano realmente riuscire nell’intento di proporsi come end-to-end vendor [3].
Questo risultato è ottenuto al meglio attraverso l’allargamento di perimetro
d’offerta già sviluppato internamente piuttosto che acquisendo software esterni
“a macchia di leopardo”.
Microsoft, in particolare, è una delle aziende che più efficacemente propone su
mercato una suite di Business Intelligence integrata ed onnicomprensiva.
L’azienda ha, in questi anni, investito consistentemente nella costruzione e nel
Pag. 12
miglioramento di capacità BI in tre delle sue offerte basilari: SQL Server, Office
(Excel) e SharePoint, al fine di incrementare il loro valore.
Incorporando funzioni di BI nei suoi software più diffusi, Microsoft garantisce
continuità nell’adozione della sua offerta completa, specialmente per
organizzazioni il cui sistema informativo è già fondato su Windows e sui suoi
numerosi prodotti [5] .
In sintesi, il settore Business intelligence vede Microsoft automaticamente
avvantaggiata per le evidenti esternalità di rete derivate dalla diffusione capillare
dei suoi prodotti.
Figura 3 - Quadrante di Gartner per la BI 2012
Osservando il magic quadrant 2012 per la Business Intelligence, ossia lo
schema riassuntivo del famoso rapporto che l’azienda Gartner redige ogni anno
sintetizzando lo stato di diversi settori, vediamo come Microsoft sia saldamente
posizionata nel settore LEADERS.
Pag. 13
Gli analisti ritengono che l’azienda sappia unire un ampio spettro di offerta
(letteralmente completezza della visione) ad un’alta qualità intrinseca dei propri
prodotti (letteralmente abilità dell’esecuzione).
Tra i punti a sfavore del fornitore, invece, gli analisti individuano
principalmente una mancanza di attenzione negli aspetti mobile, trascurati
nonostante la tensione competitiva che si sta sviluppando in quest’ambito, e la
complessità dell’architettura multi prodotto: essa è interpretabile come punto di
forza e contemporaneamente di debolezza.
Se da un lato permette la pervasività e la modularità (coniugata ad un buon
livello di integrazione tra i diversi moduli), dall’altro mescola le funzioni di
Business Intelligence con quelle di natura diversa e, dunque, si scontra con le
offerte dei competitor focalizzate esclusivamente sul tema BI, non “appesantite”
da funzionalità sovrabbondanti [5].
Per concludere la panoramica sul settore BI è necessaria anche una parentesi più
“organizzativa”, legata alla strutturazione aziendale della funzione IT: data
l’importanza crescente che il monitoraggio di grandi volumi di dati aziendali sta
coprendo in tutti i settori, infatti, si va diffondendo in questi anni la pratica di
dedicare alla Business Intelligence non solo risorse esterne (acquistando
software dedicati e consulenze funzionali ed informatiche volte alla loro
implementazione), ma anche interne fino alla composizione di un vero e proprio
“BICC”, Business Intelligence Competency Centre.
Il BICC è ossia un centro di responsabilità interno costituito da un team
interfunzionale (sia business che IT) che si occupa della progettazione dei flussi
informativi. [6].
Come detto, infine, la tecnologia sottostante la Business Intelligence appare ad
oggi ancora lontana dal “declino” fisiologico, tanto che i ricercatori sono tuttora
impegnati nella sua progressione.
In particolare, si citano i seguenti ambiti di sviluppo futuri [7]:
Capacità di analisi di “big data”, grandi volumi di dati.
Business Intelligence “real time”, anche detta just-in-time BI. Attraverso
due approcci alternativi ad oggi in piena evoluzione: Complex Event
Processing e Fast ETL.
Pag. 14
Analisi predittive, fondate sugli algoritmi di data mining
Servizi “cloud” erogati attraverso licenze di tipo “Software as a service”,
ossia residenti su server ospitati in rete anziché in locale presso il cliente,
il cui utilizzo è pagato a canone periodico anziché una tantum.
Agli aspetti teorici che stanno alla base dell’operatività quotidiana nella
Business Intelligence, consolidati nella letteratura tecnica, è dedicato il capitolo
seguente.
3.2 Data warehousing e Business Intelligence
Il data warehousing è, come accennato, l’insieme delle metodologie e delle
tecnologie orientate all’organizzazione dei dati aziendali in strutture ottimizzate
con l’obiettivo di migliorare la fruibilità delle informazioni da parte dell’utente.
In particolare si riscontrano nella comune esperienza lavorativa “terziaria” (le
attività contabili ne sono il maggior esempio), trasversale a tutti i settori
produttivi, una serie di possibili dinamiche patologiche nella gestione dei dati.
L’obiettivo della Business Intelligence attraverso gli strumenti data warehousing
si traduce, in altri termini, nell’annullamento di queste dinamiche.
Si citano, per esempio:
Eccessiva personalizzazione dei dati
Con la diffusione capillare delle tecnologie informatiche basate sui fogli
di calcolo, è diventata comune la tendenza ad arricchire i dati con calcoli e
informazioni aggiuntive personalizzate.
Il risultato, nel caso in cui il processo di arricchimento non sia coordinato
a monte, è la riduzione della fruibilità del dato da parte di un utente
diverso da chi l’ha manipolato.
Aumento della complessità del dato per arricchimenti successivi
La non-gestione dello stato dei dati, delegandone la responsabilità
informatica all’operatore non IT la cui attività dovrebbe essere
esclusivamente la loro analisi, gli permette, ogni qualvolta lo ritenga
opportuno, l’arricchimento manuale e spontaneo (e il conseguente
Pag. 15
aumento di complessità dell’informazione), senza uno studio strategico e
condiviso sottostante.
All’aumentare della complessità e dei volumi dei dati, tipicamente
progressive nel tempo, l’informazione in essi contenuta perde di fruibilità.
Inadeguatezza tecnologica
La mancata formazione degli utenti sulle tecnologie disponibili per la
gestione dei dati determina una probabile sub-ottimalità delle soluzioni
scelte rispetto a quanto offerto dal mercato corrente. Non si intende solo
l’inconsapevolezza dello stato del mercato software per la Business
Intelligence, quanto più genericamente quello dello stato dell’arte
tecnologico nel panorama informatico.
Le tre eventualità citate, tra le molte facilmente riconoscibili, sono tutte
collegate alla medesima radice: l’utilizzo non monitorato di strumenti
informatici inadatti al raggiungimento di obiettivi strategici.
In particolare, il foglio di calcolo risulta essere nella pratica aziendale lo
strumento più comunemente utilizzato per svolgere compiti non idonei alle
proprie potenzialità.
D’altra parte, se per “foglio di calcolo” intendiamo più strettamente Microsoft
Excel (installato ufficialmente su oltre un miliardo di personal computer [8], e
dunque di gran lunga il più diffuso), dobbiamo considerare lo sforzo
dell’azienda sviluppatrice di ampliarne le potenzialità per renderlo uno
strumento più predisposto all’analisi complessa di grandi moli di dati (per
esempio attraverso l’aumento di capacità dei singoli fogli avvenuta nella
versione 2007 o l’ampliamento delle funzioni di pivoting nel modulo
PowerPivot introdotto nella versione 2010).
Tornando agli aspetti teorici, i due pilastri tecnologici su cui si basano
universalmente le tecniche di Business Intelligence per la risoluzione delle
criticità informative sono le basi dati Relazionali e Multidimensionali.
In particolare queste ultime concretizzano tecnicamente un approccio finalizzato
all’analisi detto OLAP (OnLine Analytical Processing), contrapposto
all’approccio finalizzato all’input detto OLTP (OnLine Transaction Processing).
Pag. 16
3.2.1 Teoria Relazionale
L'assunto fondamentale del modello relazionale, con l’obiettivo di proporre una
grammatica atta a descrivere qualsiasi struttura dati (dove per dato si intende un
elemento atomico di un’informazione di business), è che tutti questi siano
rappresentati come relazioni e manipolati con gli operatori dell'algebra
relazionale.
Il modello relazionale consente al progettista di database di creare una
rappresentazione consistente dell'informazione: questa viene ottenuta inserendo
nel progetto del database appropriati vincoli, il cui insieme è normalmente detto
schema logico.
Lo schema logico è di fatto basato su due concetti: relazione e tabella [9].
Un attributo è una coppia ordinata di "nome di attributo" e "nome di tipo",
mentre un valore di attributo è un valore specifico valido per quel tipo di dato.
Uno schema di relazione è costituito da un simbolo R, detto nome della
relazione, e da un insieme di attributi X = {A1, A2… An}, indicato
normalmente con R(X).
Una tupla è un insieme non ordinato di valori degli attributi.
Un’istanza di relazione su uno schema fissato R(X) è un insieme r di tuple su X.
Va da sé che la testata di una relazione, ossia l’insieme dei nomi dei suoi
attributi, sia anche necessariamente la testata di ciascuna delle sue tuple.
L’entità “istanza di relazione” si traduce tecnicamente su un database nel
concetto di Tabella, ove gli attributi sono rappresentati dalle colonne.
Uno schema di base dati R è un insieme di schemi di relazioni con nomi diversi
R = { R1, R2, … RN}
Organizzato in un’istanza di base dati un certo set di informazioni, non è detto
che qualsiasi insieme di tuple sullo schema rappresenti informazioni corrette per
l’applicazione.
Si introduce allora la definizione di vincolo di integrità: una proprietà che deve
essere soddisfatta dalle istanze che rappresentano informazioni corrette per
l’applicazione.
Pag. 17
Ogni vincolo può essere visto come un predicato che associa ad ogni istanza di
tupla il valore vero o falso: l’associazione del valore falso ad una tupla ne
determina l’inammissibilità nella base dati.
Un vincolo può essere:
Intra-relazionale, ossia interno ad una singola istanza di relazione
Esempio: Nella relazione ESAMI =
{CODICE FISCALE, ESAME, VOTO, LODE(sì\no)}
Sono imposti i seguenti vincoli di integrità:
o Il valore di VOTO non può superare 30
o Il valore di LODE può essere “sì” se e solo se il valore di VOTO
è uguale a 30.
Inter-relazionale, se coinvolge più relazioni
Esempio: Date le due relazioni
STUDENTI = {CODICE FISCALE, NOME, COGNOME, …}
ESAMI = {CODICE FISCALE, ESAME, VOTO, LODE(sì\no)}
E’ imposto il seguente vincolo di integrità:
Per ogni tupla di ESAMI, il valore di CODICE FISCALE deve
essere presente nell’omonimo attributo di una tupla della
relazione STUDENTI
L’ultimo concetto fondamentale della teoria relazionale è quello di chiave: Si
dice chiave di una relazione l’elemento della relazione che identifica ogni tupla
univocamente.
Se nessun elemento (da solo) soddisfa questa condizione, si dice super chiave
l’insieme degli elementi che identificano ogni tupla univocamente.
Una notazione comunemente utilizzata è quella, ancora una volta anglosassone,
di primary key (PK) per definire una chiave primaria.
Ogni relazione deve necessariamente avere una chiave, non è cioè possibile che
in una relazione esistano due tuple identiche.
Nelle due relazioni STUDENTI ed ESAMI dell’esempio precedente, possiamo
individuare in CODICE FISCALE la chiave della prima e nella coppia CODICE
FISCALE – ESAME la super chiave della seconda.
La teoria relazionale si è formalizzata, nel tempo, in realizzazioni software
ormai giunte alla maturità tecnologica.
Pag. 18
I database relazionali, la cui definizione è stata postulata da Codd nel 1970, sono
nient’altro che la formalizzazione concreta di un modello relazionale.
In essi ritroviamo le istanze delle astrazioni definite per i modelli di cui sopra: le
relazioni si traducono in tabelle, i cui attributi sono le colonne e le cui tuple
diventano le righe.
Per interagire con i dati memorizzati sono predisposti software detti Database
Management System (o DBMS, nel nostro caso quello utilizzato è SQL Server
2012), le interrogazioni al database per il recupero, l’aggiunta e la modifica dei
dati (chiamate nel contesto lavorativo, spesso anglofono, col termine query)
sono scritte in Structured Query Language (SQL).
3.2.2 Teoria della Normalizzazione
Le proprietà di normalizzazione di un database ne certificano la qualità dello
schema. Se uno schema non soddisfa una forma normale, allora presenta
ridondanze e si presta a comportamenti “poco desiderabili” durante le
operazioni di aggiornamento [9].
In realtà, più che una condizione “necessaria” alla qualità dello schema, la
normalizzazione è una caratteristica che il progettista deve conoscere e valutare
a seconda delle esigenze specifiche dell’applicazione.
Si riassumono in estrema sintesi i principali elementi della teoria della
normalizzazione (sempre da [9]):
Vincolo di integrità
Come già detto, per vincolo di integrità si intende una “legge”, che può andare
dal tipo dato atomico (per esempio in formato numerico piuttosto che stringa)
cui il dato deve sottostare per soddisfare i criteri di qualità ed essere dunque
ammissibile all’interno della base dati.
Nella concretezza dei software di data warehousing, se si tentasse l’immissione
di un dato non soddisfacente all’interno di una base dati, il sistema cercherebbe
di correggere l’errore con algoritmi automatici e, se questi fallissero,
restituirebbe errore interrompendo l’immissione.
Pag. 19
Dipendenza funzionale
Per dipendenza funzionale si intende un particolare vincolo di integrità che
descrive legami di tipo funzionale tra gli attributi di una relazione.
In una relazione Città – Regione possiamo dire che l’attributo Città determina
l’attributo Regione, in quanto esiste una funzione che associa ad ogni elemento
del dominio dell’attributo Città che compare nella relazione un solo elemento
del dominio dell’attributo Regione.
Forma Normale di Boyce e Codd
Una relazione r si dice in Forma Normale di Boyce e Codd (già citato quale
“inventore” della definizione di database) se per ogni dipendenza funzionale
(non banale) X → Y definita su di essa, X contiene una chiave K d r (cioè X è
super chiave di r)
Esempio di relazione che NON soddisfa la forma normale di Boyce e Codd:
Nome (PK) Città di nascita Regione di nascita
Rossi Bologna Emilia-Romagna
Verdi Bologna Emilia-Romagna
Bianchi Milano Lombardia
Esiste una relazione di dipendenza funzionale Città di nascita → Regione di
nascita, tuttavia Città di nascita non è chiave della relazione
Esempio di decomposizione in forma normale di Boyce e Codd:
Nome (PK) Città di nascita
Rossi Bologna
Verdi Bologna
Bianchi Milano
Città di nascita (PK) Regione di nascita
Bologna Emilia-Romagna
Milano Lombardia
Pag. 20
Terza Forma Normale
Una relazione r si dice in Terza Forma Normale (3FN) se per ogni dipendenza
funzionale (non banale) X → Y definita su di essa, è soddisfatta una delle due
condizioni:
X contiene una chiave K d r (cioè X è super chiave di r)
Ogni attributo Y è contenuto in almeno una chiave di r
La terza forma normale è “meno forte” della forma normale di B&C e quindi
non offre le medesime garanzie di qualità, ha però il vantaggio di essere sempre
ottenibile, per qualsiasi struttura logica relazionale.
D’ora in poi quando uno schema sarà detto normalizzato verrà sottointeso che la
forma normale di riferimento sia la terza.
Prima e Seconda Forme Normali
Vediamo anche i concetti di Prima e Seconda FN nonostante non siano
particolarmente rilevanti ai fini dell’applicazione progettuale.
La Prima Forma Normale (1FN) stabilisce semplicemente che gli attributi delle
relazioni siano definiti su valori atomici e non su costrutti più complessi quali
insiemi o relazioni. La Seconda Forma Normale (2FN) è una variante debole
della terza, poiché consente dipendenze funzionali come quella tra due elementi
non-chiave della relazione.
3.2.3 Star Schema & Snowflake Schema
Prima di procedere con la spiegazione dei diversi stadi progettuali, è necessario
chiarire i concetti di Star e Snowflake Schema.
Questi sono gli archetipi fondamentali che identificano due tipi di base dati: una
completamente denormalizzata (Star) e una perfettamente normalizzata
(Snowflake).
È già stata approfondita la dinamica tale per cui una struttura in 3FN non
contiene nessuna informazione ridondante: ogni tabella che contenga su tuple
Pag. 21
diverse al stessa occorrenza di dipendenza funzionale dev’essere scomposta in
due tabelle, una delle quali espliciti la dipendenza senza ripetizioni.
Va da sé che questa metodologia è ottimale per la scrittura nel DWH (sarà allora
utilizzata nei sistemi che seguono il paradigma OLTP, quali gli ERP e i sistemi
gestionali in genere), dove per metodologia ottimale si intende quella che offre
le migliori performance e il minor spazio su disco occupato dall’applicazione.
Figura 4 - Schema tabellare a Snowflake
In uno schema a Snowflake, ogni livello di ogni risalita gerarchica di una
dimensione è su una tabella separata, collegata alle altre attraverso una “chiave
surrogata” (valore di chiave generato dal sistema con un criterio di semplicità e
univocità assoluta, tipicamente un valore numerico crescente).
Tale organizzazione ottimizza il processo di scrittura dei dati perché ogni
informazione memorizzata andrà scritta una ed una sola volta.
Prendiamo il semplice esempio citato al capitolo precedente:
Pag. 22
Supponiamo che la relazione denormalizzata
A := {NOME, CITTA’ DI NASCITA, REGIONE DI NASCITA}
Sia destinataria di un input manuale da utente. Per ogni persona nata a
Bologna, andrà imputata nella cella corrispondente della stessa tupla
anche la regione Emilia-Romagna.
Supponendo al contrario le due relazioni normalizzate, che potrebbero
essere parte di uno Snowflake schema
A := {NOME, CITTA’ DI NASCITA}
B := {CITTA’ DI NASCITA, REGIONE DI NASCITA}
La relazione gerarchica Bologna -> Emilia-Romagna andrà imputata una
sola volta, e ad ogni NOME si potrà attribuire la REGIONE DI NASCITA
grazie al legame logico inter relazionale che intercorre tra la CITTA’
attribuita al nome e la REGIONE nella seconda tabella.
Proseguendo nell’esempio, il risparmio in termini di scrittura e spazio occupato
su disco si può calcolare facilmente supponendo che ogni cella occupi un’unità
di tempo di scrittura \ spazio occupato e i seguenti parametri:
n il numero di tuple presenti nella relazione A
m città distinte (m <= n poiché più tuple possono essere caratterizzate da
una stessa città)
Il tempo necessario per imputare questi dati in una sola tabella denormalizzata è
3*n:
n volte il nome (PK) su A
n volte le città anche se ripetute su A
n volte le regioni anche se ripetute su A
Nella forma normalizzata, con gli stessi dati, il tempo e lo spazio necessari per
imputarli sono 2n + 2m:
n volte il nome (PK) su A
n volte le città anche se ripetute su A (chiave esterna)
m volte le città (PK) su B
m volte le regioni anche se ripetute su B
E’ evidente che più sintetica è la relazione, tanto più la normalizzazione è un
criterio efficace di ottimizzazione in scrittura.
Pag. 23
Se ogni NOME imputato avesse una diversa CITTA’ DI NASCITA, le due
strutture non presenterebbero differenze. In particolare, nel semplice esempio
immaginato la conversione è conveniente se ogni città caratterizza almeno 2
tuple.
Se invece valutassimo come obiettivo la lettura, com’è per definizione nei
progetti di Business Intelligence, immediatamente noteremmo la non
vantaggiosità della soluzione normalizzata: essendo l’accesso ad una tabella
un’operazione onerosa, così come il collegamento tra due o più tabelle, e
volendo ottenere un’informazione di sintesi C := {NOME; REGIONE DI
NASCITA}, nel caso denormalizzato sarebbe sufficiente:
Accedere alla tabella A
Isolare in A le due colonne di interesse
SELECT [NOME], [REGIONE DI NASCITA]
FROM A
Mentre nel caso normalizzato sarebbe necessario:
Accedere alla tabella A e B
Collegare le due tabelle attraverso JOIN
Isolare le due colonne di interesse
SELECT A.[NOME], B.[REGIONE DI NASCITA]
FROM A INNER JOIN B
ON A.[CITTA’ DI NASCITA] = B.[CITTA’ DI NASCITA]
Per questa ragione nei data warehouse R-OLAP la forma denormalizzata a Star
Schema (dove tutti i livelli gerarchici successivi al primo sono “appiattiti” su di
esso e resi limitrofi alla tabella dei fatti) è preferita a quella a Snowflake
nonostante porti ridondanze e, nel caso manchino controlli appropriati, possa
condurre ad incongruenze.
Pag. 24
Figura 5 - Schema tabellare a Star
Rimanendo nell’esempio di cui sopra, per un errore di imputazione una stessa
città potrebbe essere associata a più regioni: nella forma normalizzata questa
casistica è inaccettabile e impossibile da finalizzare, poiché invaliderebbe il
vincolo di univocità della chiave della tabella B, mentre nel secondo caso essa
non viola nessun vincolo di integrità predefinito e, dunque, va considerata ed
evitata con controlli di natura diversa.
Pag. 25
3.3 Struttura di un DSS, studio su diverse alternative
Quale sia la struttura ottimale di un Decision Support System tra tutte le
possibili configurazioni di un insieme di database sottostanti un unico data
warehouse è, dacché è fiorita la partecipazione della comunità scientifica alla
discussione su questi temi, un argomento di ricerca oggetto di numerose ipotesi.
La prima risposta a questa domanda è sicuramente quella che il mercato delle
consulenze (in senso ampio così come in Business Intelligence) richiede per
antonomasia, e cioè che la miglior configurazione del sistema informatico è
contingente alle esigenze peculiari e non generalizzabili del singolo Cliente.
Tuttavia, un interessante articolo pubblicato sul “Business Intelligence Journal”
[10] riporta l’analisi dei feedback progettuali di 545 consulenti, data warehouse
manager, sviluppatori e sistemisti su 5 diverse alternative strutturali.
Queste alternative sono valutate, attraverso questionario, sui seguenti parametri:
Qualità dell’informazione – accuratezza, completezza e consistenza
delle informazioni che raggiungono l’utente finale (senza considerare
“come” queste lo raggiungano)
Qualità del sistema – flessibilità, scalabilità e performance del sistema
Impatto individuale – velocità e facilità di utilizzo da parte dell’utente
finale, miglioramento delle capacità analitiche rispetto alla situazione
precedente lo sviluppo del sistema
Impatti organizzativi – rispondenza alle esigenze aziendali, capacità di
coadiuvare efficacemente i processi decisionali e ritorno sull’investimento
(indice ROI di progetto) quantificabile.
Pag. 26
Figura 6 - Cinque architetture di un data warehouse [10]
In particolare due tra queste alternative sono citate come rappresentative delle
“filosofie” di Inmon e Kimball, rispettivamente l’inventore della definizione di
data warehouse e il, già citato, più celebre ricercatore sullo stesso tema.
Inmon è l’ideatore e il sostenitore di una struttura detta hub-and-spoke (da lui
soprannominata “Corporate Information Factory”), impostata in queste fasi:
1. Sistemi sorgenti (Import)
2. Staging Area
3. Data warehouse relazionale completamente normalizzato
4. Data Mart dipendenti dal DWH sottostante, con dati denormalizzati e
rispondenti a richieste di sintesi specifiche
Pag. 27
5. Accesso delle applicazioni per gli utenti finali sia al DWH relazionale sia
ai data mart dipendenti
Kimball, di contro, propone un’architettura detta “Data Mart Bus” (con
riferimenti dimensionali collegati):
1. Sistemi sorgenti (Import)
2. Staging Area
3. Data mart collegati tra loro da dimensioni comuni (dati sia atomici che
sintetici), la cui integrità è quindi verificata in modo centralizzato a monte
4. Accesso delle applicazioni per gli utenti finali dai data mart
Premettendo che quest’ultima (evidenziata in Figura 6) è la struttura più simile a
quella sviluppata nel caso in esame, l’articolo (coerentemente con i risultati
dello studio) non si schiera apertamente a favore dell’una o dell’altra alternativa,
ponendole però su un piano più alto rispetto alle altre possibilità.
Osservando i risultati dello studio, questa struttura consente l’ottenimento di
migliori performance, miglior impatto sia per gli utenti finali che per
l’organizzazione cliente.
L’unico parametro in cui la Bus Architecture non guadagna il massimo dei
consensi è la qualità dell’informazione: lo schema a Snowflake perfettamente
normalizzato garantisce un massimo controllo dell’integrità delle informazioni e
della loro consistenza (a scapito della performance in lettura).
I risultati ottenuti dai ricercatori statunitensi sono dunque conformi con quanto
atteso e con le scelte che abbiamo effettuato nel caso in esame. Ritrovata in
letteratura la teoria cui la struttura progettuale è riconducibile, si prosegue con la
relazione di quanto realizzato.
Pag. 28
3.3.1 Import
Il primo aspetto da curare in un progetto di Business Intelligence è la modalità
con cui i dati aziendali vengono, dopo essere stati innanzitutto selezionati,
raccolti all’interno di un data warehouse unificato.
Le caratteristiche di questa fase sono, per ovvie ragioni, strettamente
conseguenti la natura del dato sottostante e la sua organizzazione pregressa.
Tuttavia è possibile ritrovare un semplice schema comune nella sua
progettazione, che prescinde dai casi specifici:
1. Analisi delle fonti in termini di natura, dimensione, normalizzazione,
integrità e completezza rispetto alla specifiche
2. Sviluppo dell’applicazione che, mantenendo tutte le informazioni
rilevanti, assimili gli output delle fonti dati nel data warehouse unificato
3. Automazione del processo così che possa avviarsi e funzionare
stabilmente a intervalli di tempo predefiniti senza l’intervento
dell’operatore
4. Disposizione di un sistema di segnalazione nel caso in cui, ad un dato
caricamento, il processo fallisse (incongruenza delle fonti dati rispetto a
quanto pianificato)
Queste 4 qui riportate potrebbero intendersi anche come le fasi complessive
dello sviluppo dell’intero progetto, ma solo apparentemente: è infatti la fase di
Import quella che, dipendendo direttamente da output non controllabili,
concentra al suo interno larghissima parte del rischio progettuale di ottenere
errori durante il funzionamento in produzione. Ha senso, quindi, che il suo
monitoraggio sia privilegiato nei confronti delle fasi successive.
Se infatti il collaudo complessivo dell’applicazione avesse dato esito positivo,
sarebbe impossibile che le fasi Staging Area (SA) e Data Mart (DM), ricevendo
per definizione in input dati coerenti con quelli attesi, mostrino comportamenti
tecnici imprevisti.
Prendiamo uno dei casi realmente verificatisi in cui un file di testo (Comma
Separated Value) è importato dal sistema transazionale. In esso, uno degli
attributi non è mai stato valorizzato, ma si prevede la sua futura valorizzazione.
Pag. 29
Dovendo “prevedere” la sua popolazione in futuro, in fase di Import il file CSV
viene mappato come relazione, ossia nei metadati dell’applicazione sono
memorizzate le caratteristiche dei suoi attributi e, tra questi, dev’essere presente
la colonna al momento non valorizzata.
Siccome ogni dato deve avere un “Tipo” associato per essere consistente, lo
studio funzionale riporta un tipo dato “Stringa” di lunghezza 8 caratteri, il tipico
formato di un campo imputato come data (nella forma AAAAMMGG).
Va da sé che la fase di Import prevedrà un dato di questo genere in input e
quella successiva, per esempio, predisporrà su di esso una conversione dal suo
attuale formato a un formato “Data”.
Nel caso in cui lo studio funzionale non sia stato abbastanza approfondito e quel
campo sia imputato in modo differente, per esempio scrivendo la data in una
forma diversa, sarà la fase di Import ad interrompersi (o a scartare la tupla
corrispondente) in modo trasparente alla fase successiva, che potrebbe non
avviarsi mai (in caso di errore) oppure ottenere in input tutte le altre tuple, senza
quella errata.
E’ chiaro, a questo punto, che lo stadio in cui i dati vengono importati
dall’esterno dovrebbe, una volta avviate le fasi successive, essere modificato il
meno possibile, se non in modo incrementale: il cambiamento di un attributo a
questo livello si ripercuote in cascata sulla Staging Area e sui Data Mart
successivi, causando errori nel caso in cui non sia garantita la compatibilità tra la
vecchia e la nuova versione del dato (compatibilità intesa come possibilità di
immagazzinare il nuovo dato nella stessa cella del precedente).
Allo stesso modo, ogni modifica incrementale sullo stadio di Import dovrà
essere proiettata fino a valle, nella reportistica, per poter essere assimilata dal
sistema: questo tipo di interventi dev’essere limitato se non evitato, data la sua
pesante onerosità in tempi di sviluppo.
Pag. 30
3.3.2 Staging Area
Sperimentando la fase progettazione della Staging Area (di seguito anche SA) è
risultato immediato che, come si pianificano gli aspetti temporali di un progetto,
così per generare un flusso che soddisfi le fasi a valle si deve necessariamente
procedere a ritroso, partendo dai risultati finali desiderati.
Partendo dai report che si vogliono ottenere, si risale quindi a cosa sarà
necessario includere nei data mart. Progettati questi, nuovamente, si fa un passo
indietro valutando cosa serve mantenere in Staging Area.
Questa è il nucleo centrale del processo di ETL costituendo sostanzialmente “la
T di Transformation”, in quanto ha il compito di:
Convertire tutti i dati nei formati corretti
Eseguire calcoli e modifiche sui dati numerici per portarli nella forma
definitiva in cui verranno aggregati nella popolazione dei data mart
Organizzarli in maniera fruibile dalle fasi successive attraverso lo studio
della normalizzazione
Già nella SA gli Star Schema da cui attingeranno i data mart iniziano a prendere
forma, nel senso che vengono create e validate le tabelle dimensionali.
Queste, coerentemente col modello Data Mart Bus di Kimball, possono essere
specifiche dell’ambiente in esame oppure condivise tra più SA di diverse
applicazioni, in modo da garantire la solidità non solo dell’applicazione di Ciclo
Attivo ma anche dell’intera soluzione di Business Intelligence offerta al Cliente.
Un paio di esempi di anagrafiche condivise tra più applicazioni (ricordando che
le altre applicazioni sviluppate nello stesso ambiente sono quelle per l’ufficio
Controllo di Gestione e Acquisti – vd. Cap. 1) sono quella dei Committenti
(condivisa con CdG) e, per la sua trasversalità e rilevanza all’interno
dell’azienda, quella degli elementi della Work Breakdown Structure, che è
presente in tutti gli ambienti operativi (Vd. Cap. 5.2.1).
Pag. 31
3.3.3 Data Mart
Sul concetto di data mart in termini generici è difficile spendere più di qualche
cenno, essendo la sua struttura completamente determinata dall’ambito
progettuale.
Questa è la fase in cui il livello di denormalizzazione raggiunge il massimo, in
quanto il dato dev’essere reso fruibile al meglio possibile dai sistemi a valle (in
termini di tempo, flessibilità e contenuto informativo), senza nessun altro
vincolo tecnico.
L’asservimento dell’ultima fase alle esigenze di reportistica è rafforzato dalla
sua natura completamente in full-refresh: i dati vengono storicizzati (così come
dalla fonte esterna) in Import poi formalizzati, convalidati e di nuovo
immagazzinati in Staging Area. Non è richiesta un’ulteriore fase di
“warehousing”, ma soltanto la disponibilità veloce e precisa delle informazioni
richieste dalla reportistica.
Nel progetto i database usati in fase di DM sono due, uno per le informazioni “di
scaduto”, riferite al passato, e uno per quelle “a scadere”, riferite al futuro, ma
essi sono raggruppati in uno soltanto avendo in comune tutte le dimensioni e,
dunque, differendo solo per il metodo di calcolo della tabella dei fatti.
Pag. 32
3.4 Cubi Multidimensionali OLAP
Il primo strumento M-OLAP era “Express”, di Oracle, programmato e
commercializzato negli anni ’70.
I sistemi OLAP permettono agli analisti e ai manager di migliorare le
performance d’impresa grazie ad un veloce accesso interattivo ad una larga
varietà di visualizzazioni dei dati [11].
Prima caratteristica degli strumenti OLAP deve essere quindi la velocità, a
prescindere dal volume dei dati trattati: essa può dipendere dalla quantità di dati
da restituire ma non dalla dimensione totale del database sottostante.
Questo obiettivo è raggiunto strutturando il dato servendosi di un paradigma
tecnologico diverso da quello relazionale: mentre una tabella R-OLAP
(Relational OLAP, ovvero interna ad un database “classico” organizzato a star
schema così da emulare i paradigmi di un ipercubo di dati) è bidimensionale
(righe e colonne) e il collegamento con più dimensioni avviene “emulando” la
multidimensionalità attraverso operazioni di JOIN tra più tabelle, il dato
immagazzinato in un M-OLAP è assimilabile ad un “array” dove alle misure
numeriche è associato l’insieme degli N attributi, i quali in memoria riferiscono
a N dimensioni distinte solo per quel che riguarda le strutture gerarchiche non
rappresentabili sull’array.
Si propone una visualizzazione grafica che evidenzi le differenze tra i due
paradigmi tecnologici:
Pag. 33
Figura 7 - Schematizzazione del paradigma R-OLAP
Figura 8 - Schematizzazione del paradigma M-OLAP
Esistono però esigenze a cui R-OLAP può rispondere più efficientemente
rispetto a M-OLAP: un ipercubo, infatti, occupa fisicamente memoria per ogni
incrocio dimensionale possibile, a prescindere che il dato sia presente o meno.
Questa caratteristica introduce il problema della “sparsità”, concetto
completamente assente nel paradigma relazionale, ossia la presenza di incroci
multidimensionali per cui le misure non sono valorizzate.
Il livello di sparsità è proporzionale alla memoria occupata (non utilmente)
dall’infrastruttura.
Conclusa la panoramica teorica, nel capitolo seguente saranno presentati tutti gli
strumenti di progetto utilizzati.
Pag. 34
4 Aspetti tecnici e strumenti utilizzati
4.1 Specifiche HW
Figura 9 - Schema architettura HW
In figura 9 è rappresentata la semplice architettura hardware predisposta per il
progetto. Si tratta di tre macchine fisiche, due delle quali già utilizzate in
azienda, e di due macchine virtuali.
Le tre macchine fisiche sono utilizzate, rispettivamente, per:
Ospitare il server Microsoft Exchange, che contiene la mappatura di tutte
le utenze aziendali e permette, interfacciandosi con tutti gli altri software,
di accedere a tutte le informazioni per cui si è correttamente profilati con
un unico login.
Pag. 35
Ospitare il web server, su piattaforma coerentemente .NET1, su cui oltre al
sito Internet della società sono avviati anche i servizi Intranet
Ospitare il server Business Intelligence SQL Server e memorizzare tutti i
dati raccolti.
Le due macchine virtuali, invece, servono rispettivamente a:
Ospitare il Server SharePoint, che non necessita di performance
particolari e di ampie capacità di memorizzazione dati e, quindi, rimarrà
virtualizzato anche dopo l’entrata in produzione del progetto
Ospitare temporaneamente il Server OLAP Multidimensionale. Le
performance della macchina virtuale sono ritenute sufficienti alla fase di
sviluppo, ma sarà presumibilmente effettuata la sua migrazione una volta
chiusi i lavori.
4.2 Specifiche SW
Le specifiche tecniche di progetto richiedono l’implementazione di un sistema di
Business Intelligence che, come detto, attinga dalla base dati OLTP (SAP) e,
dopo aver pulito ed elaborato i dati, predisponga una reportistica su Excel
fruibile anche attraverso il portale aziendale Intranet.
Il Cliente ha scelto, per i motivi già esposti parlando del mercato dei software
per la Business Intelligence (Vd Cap. 3.1), la suite Microsoft BI 2012 per
ottenere al meglio questi risultati.
Segue una breve carrellata dei moduli che abbiamo utilizzato nello sviluppo del
progetto.
4.2.1 SQL Server
SQL Server (Vers. 2012) è un sistema di database management (DBMS) e
analisi dei dati per soluzioni di e-commerce e data warehousing.
1 .NET è il framework (ambiente applicativo) sviluppato da Microsoft, dotato di interoperabilità rispetto a
programmi esterni, una grande libreria accessibile attraverso svariati linguaggi e molti tool di sviluppo assistito
[17]
Pag. 36
Presente sul mercato nella sua prima versione dal 1989, è uno dei sistemi più
diffusi a livello mondiale. Numerosi report di customer satisfaction registrano
uno slittamento della preferenza dei clienti da Oracle Database Administrator,
leader di mercato, verso Microsoft SQL Server, considerando una sostanziale
somiglianza nelle possibilità tecniche e nelle performance a fronte di un Total
Cost of Ownership molto inferiore [12].
4.2.2 SSIS
SQL Server Integration Service (Vers. 2012) è un software che consente lo
sviluppo “assistito”, limitando la scrittura di codice SQL, di una soluzione di
ETL. Attraverso l’utilizzo di oggetti funzionali, che altro non sono che strutture
preconfezionate di query SQL complesse, lo sviluppatore può costruire molto
più rapidamente flussi di dati in entrata e uscita da svariate tipologie di
fonti\destinazioni dati.
Figura 10 - SQL Server Integration Services 2012
Nella schermata riportata è visibile una schermata Control Flow: a sinistra è
presente una Toolbox contenente tutti gli oggetti funzionali disponibili, a destra
Pag. 37
una visuale detta Solution Explorer utile per navigare all’interno dei pacchetti
sviluppati.
Un Control Flow permette l’organizzazione visuale, come detto, di un flusso di
dati: collegando oggetti funzionali con delle frecce possiamo definire la
sequenza temporale di esecuzione e la loro consequenzialità logica. All’interno
di un Control Flow si possono parametrizzare Cicli For, inserire pacchetti
sviluppati in linguaggio C#, VB o Procedure SQL e, soprattutto, inserire Data
Flow.
I Data Flow, sottoinsiemi logici dei Control Flow, sono insiemi ordinati di fonti
dati, operazioni su tabelle e destinazioni, il tutto organizzato in un diagramma di
flusso identico a quanto mostrato precedentemente.
Utilizzando questo strumento grafico è possibile “emulare” query complesse in
SQL, così come inserire veri e propri script.
L’agevolazione visiva ad oggetti, rispetto al classico codice commentato,
aumenta esponenzialmente la facilità con cui il progetto è manutenuto,
modificato e soprattutto trasferito da una persona all’altra in caso di
cambiamento di ownership.
Tra oggetti funzionali presenti nella cosiddetta Toolbox di SSIS ritroviamo le
principali strutture logiche dello Structured Query Language.
Si riportano di seguito i più frequentemente utilizzati:
Union & Multicast
Union & Multicast sono oggetti atti all’instradamento dei flussi dati.
Union agisce esattamente come la clausola omonima in SQL: le due fonti dati
(Tabelle A, B) devono avere lo stesso numero e tipo di colonne, le righe
risultanti sono l’unione tra tutti gli elementi dei due insiemi senza duplicati.
Multicast, invece, rappresenta un concetto difficilmente descrivibile con
analogie in SQL: l’oggetto duplica il flusso dati, che in tal modo può
parallelizzare operazioni concorrenti per poi ricongiungersi attraverso una Union
(o fluire in diverse destinazioni dati).
Pag. 38
Lookup
L’oggetto Lookup richiede una tabella in ingresso ( A := { XA, YA, ZA,…} ), una
“in lookup” collegata alla prima da uno o più campi di JOIN che rispettino
l’integrità referenziale (nell’esempio supponiamo che il campo di JOIN sia XA B
:= {KB, WB, JB… XA} ), e ne consente una in output.
In quest’ultima si potrà selezionare quale set di attributi di B (per proseguire
nell’esempio supponiamo una sola colonna WB) saranno aggiunti ad A usando i
campi di JOIN come collegamento.
La sintassi SQL generata è:
SELECT A.XA, A.YA, A.ZA, …, B.WB
FROM A LEFT OUTER JOIN B
ON A.XA = B.XA
Derived Column
L’oggetto Derived Column richiede una tabella in ingresso ( A := { XA, YA,
ZA,…} ) e ne consente una in output.
Ad una o più colonne di A possiamo applicare una (o più) funzioni attingendo
ad una libreria di C# (sostanzialmente, anche se non formalmente, simili alla
collezione di funzioni di MS Excel). Le colonne calcolate possono aggiungersi
alla tabella oppure sostituire una delle colonne precedenti.
La sintassi generata, date F e G le funzioni applicate e supponendo di sostituire
alla prima colonna il risultato di F e di aggiungere in coda il risultato
dell’applicazione di G alla seconda colonna, risulta:
SELECT F(XA) AS XA, YA, ZA, …, G(YA) AS Y2A
FROM A
Aggregate
L’oggetto Aggregate richiede una tabella in ingresso ( A := { XA, YA, ZA, NA, …}
) e ne restituisce una all’uscita. I campi di questa tabella vengono suddivisi in 3
sottoinsiemi disgiunti: campi di aggregazione, campi aggregati e campi ignorati.
Pag. 39
Il comportamento, si nota immediatamente, è analogo all’istruzione SQL
“GROUP BY”.
I campi di aggregazione vengono “raggruppati” per valori distinti, diventando
automaticamente la nuova superchiave della tabella risultante.
I campi aggregati, invece, sono fatti convergere all’interno delle tuple generate
dalla nuova chiave in numero minore o uguale rispetto alla condizione di
partenza.
Il criterio di aggregazione va specificato: per i valori numerici saranno
disponibili le funzioni matematiche (somma, media…) mentre per i valori non
numerici si potrà selezionare il valore massimo o minimo (max, min).
Dato XA, YA la nuova chiave di aggregazione, ZA ignorato e NA un campo
numerico aggregabile per media aritmetica, Aggregate funziona come
l’istruzione SQL:
SELECT XA, YA, SUM(NA)
FROM A
GROUP BY XA,YA
Data Conversion
L’oggetto Data Conversion richiede una tabella in entrata e ne restituisce una in
uscita. Come evidente dalla denominazione, utilizza le funzioni a disposizione
da C# per convertire una colonna in un’altra che contenga gli stessi valori in un
differente tipo dato. Per una stessa colonna in input può restituire più di una
conversione.
Si potrebbe dire con buona approssimazione che la corrispondenza in SQL sia
con le funzioni CAST (funzione “storica” di SQL Server, compatibile con le
versioni più vecchie) e CONVERT (nuova funzione di SQL Server, utilizzabile
con un parametro ulteriore per definire lo “stile” del risultato qualora il formato
scelto supporti questa funzionalità). In realtà non bisogna confondere le due
cose, in quanto la conversione in SSIS avviene all’interno di un ambiente C#, e
dunque i tipi dato possono seguire regole diverse [13].
Pag. 40
4.2.3 SSAS
SQL Server Analysis Services (Vers. 2012) è il software atto a creare e gestire
cubi multidimensionali pronti per l’accesso in lettura via MS Excel.
Figura 11 - SQL Server Analysis Services
SSAS offre allo sviluppatore un ambiente interamente modulare, che permette di
concentrarsi su singole parti del progetto per poi unificarle dinamicamente.
I moduli applicativi di SSAS sono, in ordine ideale di sviluppo lineare:
Data Source
Nel Data Source sono gestite, non molto diversamente da come sono trattate in
SSIS e, per certi versi, con modalità ricordate (e sintetizzate) nelle interfacce di
Microsoft Access, tutte le provenienze dei dati cui i cubi potranno attingere.
Ovviamente l’input predefinito e privilegiato di SSAS, nato per elaborare grandi
moli di dati, è un database SQL Server.
Ciò non toglie che anche altri DB Provider, così come fogli di calcolo o file di
testo, possano essere usati per la connessione.
Pag. 41
Data Source Views
Nelle Data Source Views è possibile definire “cosa” della fonte dati il cubo
debba caricare. Si dovranno cioè definire, per ogni fonte, le tabelle da importare
e, per ognuna di queste, le colonne di interesse.
Già in questa fase il software mostra il suo potenziale, con due funzionalità
molto importanti:
a. La possibilità di caricare dati secondo una specifica query SQL,
potendo quindi usare in partenza tutte le operazioni caratteristiche
del linguaggio d’interrogazione: in questo modo i data mart
sottostanti (che verosimilmente sono lo stadio del data warehouse a
cui “punta” il Data Source) possono essere ancora filtrati o
arricchiti.
b. La possibilità di definire uno schema di chiavi primarie ed esterne:
in tal modo SSAS validerà i caricamenti controllando l’integrità
referenziale sia interna (chiave primaria non duplicata) sia esterna
(valori delle chiavi esterne presenti nelle chiavi di riferimento).
Inoltre, la visualizzazione dello schema “in chiaro” e la sua
strutturazione potrebbero portare a considerazioni sulla sua
normalizzazione e, dunque, a suggerire modifiche sul data mart
sottostante.
Dimensions
Nella definizione delle dimensioni, lo sviluppatore non si limita a definirne il
nome e la tabella di provenienza: SSAS mappa, in questa fase, tutte le relazioni
tra gli attributi della dimensione, in modo da poter verificare in fase di
caricamento che siano valorizzati correttamente.
Inoltre, è in questa visualizzazione che le gerarchie tra attributi (a N livelli)
vengono definite: le parametrizzazioni verranno utilizzate da Excel in fase di
analisi dei dati.
SSAS è predisposto anche per le applicazioni che necessitino, ad esempio allo
scopo di consolidamento di gruppo, di supportare utenze internazionali: è
disponibile una funzione di gestione delle traduzioni di tutte le etichette definite
per ogni elemento dimensionale.
Pag. 42
Cubes
Nella definizione dei cubi, vero nucleo del software, è possibile caratterizzare
pienamente il modello dati.
a. Cube Structure
Partendo da una Data Source View, la Cube Structure consente di collegare le
tabelle dei fatti alle dimensioni precedentemente determinate. Se presenti, il
software utilizza automaticamente le chiavi esterne di JOIN definite nella fase di
Data Source View. In questa fase vanno anche definite tutte le misure non
calcolate che vanno estratte dalla tabella dei fatti e che saranno aggregate lungo
le dimensioni del nuovo cubo.
b. Dimension usage
Questa funzione consente di definire, per ogni coppia misura\dimensione, quale
sia la funzione logico\matematica di aggregazione del dato lungo la dimensione
(la funzione di default è come sempre SUM).
c. Calculations
In quest’area è possibile definire le funzioni MDX utilizzate per la
valorizzazione dei membri calcolati del cubo.
MDX (MultiDimensional eXpressions) altro non è che il linguaggio proprietario
di Microsoft per la modellazione multidimensionale.
Esempi di calcolo MDX sono riportati al capitolo 6.4.5.
d. KPIs
I KPI (Key Performance Indicator) sono intesi da SSAS come valori definiti
univocamente per l’intero cubo, estraniandosi dunque dai concetti dimensionali
sottostanti. Nel progetto essi non sono stati utilizzati, ma è evidente l’utilità della
funzione per ambiti funzionali di maggior sintesi analitica (come ad esempio per
il calcolo degli indici di bilancio, oppure per soddisfare necessità specifiche del
controllo di gestione).
e. Aggregations
SSAS dispone di un motore automatico di pre-calcolo delle aggregazioni, che
può operare basandosi sia sulla struttura “naturale” del cubo sia analizzando le
richieste effettuate per ottimizzarne la risposta.
Pag. 43
Nel primo caso, il motore elabora la numerosità delle dimensioni e la sparsità
delle misure lungo di esse, andando poi a pre-aggregare i dati secondo algoritmi
trasparenti all’utente. L’operazione di pre-aggregazione, oltre ad essere onerosa
al momento dell’esecuzione (che va effettuata non ad ogni query, ma solo al
momento del caricamento dei dati), occupa spazio su disco senza valutare
effettivamente quali siano gli incroci “cruciali”.
Più interessante, quindi, il secondo caso, che sulla base di un range temporale è
in grado di analizzare il log di tutte le query multidimensionali svolte e
ottimizzare il cubo per la loro esecuzione.
Il processo di sviluppo si svolge quindi in tre fasi:
Si realizza il cubo senza ottimizzazioni e pre-aggregazioni
Si passa al sistema di reportistica e si testa la quadratura del dato
confrontandosi con il Cliente su quali siano le analisi più spesso effettuate
Infine si lancia questa routine di analisi e pre-aggregazione che
ottimizzerà il cubo a seconda dei test effettuati
Essendo le aggregazioni statiche, una volta definite (l’analisi delle query OLAP
non avviene ad ogni caricamento, ma solo nella fase di sviluppo) è bene
manutenerle con una certa periodicità, garantendo che il cubo sia pre-aggregato
a seconda delle ultime “tendenze” che gli utenti dimostrano nell’utilizzo della
reportistica.
f. Partitions & Perspectives
Queste funzioni, che permettono di suddividere cubi di grandi dimensioni in più
sottoinsiemi calcolati e accessibili separatamente, non sono state approfondite
nel progetto in esame.
g. Translations
Anche per le misure è possibile la gestione multi-lingua.
Pag. 44
4.2.4 Interfaccia Excel
Per la reportistica e la navigazione dei dati si è scelto lo strumento familiare agli
utenti di business per eccellenza, ossia MS Excel (Vers. 2010).
Specificato che l’interfaccia con SSAS è nativa e non serve, dunque, modificare
il proprio software con Add-In o il proprio metodo di lavoro consueto, le
modalità di accesso al dato saranno trattate nel dettaglio al Cap. 7.
4.2.5 MS SharePoint
SharePoint è il software di gestione del lavoro collaborativo di Microsoft,
rappresentante il front-end ideale di un’applicazione di BI nel proprio ambiente.
Figura 12 - Screenshot del portale di reportistica
Basato su Silverlight, uno tra i pilastri dello sviluppo web in ambiente MS,
SharePoint permette di creare e manutenere, limitando le parti di sviluppo in
codice, un portale aziendale inter-funzionale dotato di capacità avanzate di
Pag. 45
Enterprise Search (ricerca all’interno di tutti i contenuti disponibili in azienda),
Content Management (gestione dinamica di contenuti, siano essi reportistica
dinamica, articoli, relazioni, presentazioni ecc…) e Document Management
(gestione centralizzata del ciclo di vita dei documenti elettronici rilevanti per
l’operatività dell’azienda come ordini, buste paga, fatture, rimborsi spese
ecc…). La funzionalità di SharePoint di maggiore rilevanza nel progetto in
esame è la conversione “al volo”, ossia senza sviluppo aggiunto da parte
dell’analista BI, di un report costruito in Excel e poggiante su un cubo SSAS, in
una pagina web navigabile con gli stessi controlli del foglio iniziale.
Grazie a questa capacità si coniugano i due obiettivi fondamentali che la
reportistica deve possedere:
Dal punto di vista dell’integrità dei dati, essi risiedono on-line su un data
warehouse centrale e non su PC dell’utente finale, dunque è certificata la
loro correttezza e completezza.
Dal punto di vista dell’utente, il report consegnato si presenta strutturato
in modo familiare (ossia nella forma di un semplice foglio Excel) ed è
dunque semplice da manipolare ed analizzare. Tutto questo senza alterare
la sua forma sul server, che rimarrà quindi necessariamente “invariata”
per l’accesso degli utenti successivi.
Vd. Cap. 7 per la relazione di quanto implementato utilizzando MS SharePoint.
Pag. 46
5 Analisi funzionale del caso
5.1 Processi di Ciclo Attivo
Il Ciclo Attivo di un’azienda è il processo che va dal primo contatto con il
committente fino alla transazione finanziaria finale tra quest’ultimo e l’azienda
stessa, in retribuzione alla cessione di un bene o servizio.
Per un fornitore di prodotti fisici, il ciclo attivo si configura solitamente in
questo modo:
Figura 13 - Ciclo Attivo per prodotti fisici o di servizi
Gli addetti al processo possono essere dedicati o condivisi, a volte anche
afferenti diverse funzioni.
Ad esempio, la fase 1 è tipicamente svolta dalla funzione Marketing, mentre la
fase 2 e 3 sono responsabilità, nel caso sia separata, della funzione Vendite.
Pag. 47
Il “ciclo di vita” della vendita passa poi di mano diventando appannaggio della
funzione Amministrativa una volta che l’Offerta e successivamente l’Ordine
sono stati emessi.
Per un’azienda di servizi, come quella del Cliente di progetto, il ciclo presenta
poche differenze, non sostanziali, che vedremo al prossimo capitolo.
Centrando la nostra analisi sugli aspetti più importanti per l’ufficio
Amministrazione, risulta chiaro che la massima attenzione sia posta sulle ultime
tre attività del flusso, che separano l’emissione dell’Ordine dall’evasione della
fattura. In ottica di reingegnerizzazione del flusso informativo è possibile, già a
questo punto, uno studio approssimato su quali siano i più rilevanti KPI (Key
Performance Indicator) del processo:
1. % € Fatture da emettere e % € Fatture inevase
Sia genericamente che analizzata lungo le dimensioni aziendali (in un
dato periodo, per un dato tipo di clienti o di servizi, in una certa area
geografica ecc.…), la percentuale in valore di fatture non ancora emesse
dall’ufficio Amministrazione (KPI interno) e quella di fatture emesse ma
non pagate dai clienti (KPI esterno) sono sicuramente i più importanti tra
gli indicatori, in quanto attestano quantitativamente la rapidità operativa
dell’ufficio e la solvibilità dei clienti.
2. % Clienti con fatture da emettere o inevase
La percentuale dei clienti con fatture da emettere certifica internamente
dove il processo di Ciclo Attivo sia più lento e meno efficiente.
3. LT Medio di fatturazione
I giorni medi che trascorrono dal momento ideale di emissione della
fattura a quello effettivo sono un indicatore relativo molto efficace delle
performance della funzione amministrativa.
4. Incroci dimensionali con valori “anomali” dei parametri in termini di
% Fatture Inevase e LT medio di fatturazione
Attraverso l’analisi delle informazioni è possibile identificare pattern
prima non distinguibili nel processo di fatturazione: ad esempio se ci
siano anomalie per cliente, come prolungamenti nella negoziazione,
Pag. 48
oppure per tipo di prodotto\servizi, magari in base alla metodologia di
fornitura\erogazione.
Nel prossimo capitolo si approfondiranno le caratteristiche specifiche del
processo presso il Cliente oggetto di studio, con particolare attenzione alla fasi
conclusive (successive l’ordine di vendita), considerando che quelle iniziali si
sarebbero studiate nel caso in cui il sistema informativo prendesse in carico tutti
i dati relativi alla “storia” dei committenti (e in tal caso ci saremmo serviti delle
tecniche informatico-gestionali del CRM, Customer Relationship Management).
5.2 Contingenze al caso specifico
Figura 14 - Processo di Ciclo Attivo con rateizzazione (caso di studio)
Analizziamo il processo punto per punto:
Pag. 49
Offerta ed eventuale negoziazione per un “set” di servizi: l’Azienda offre
ai propri clienti un portafoglio di servizi con la possibilità di
personalizzazioni ad hoc. Una volta selezionato (o “formulato”, se nuovo)
il set di servizi interessanti, viene proposto un prezzo e può seguire una
fase di negoziazione. Tipicamente i servizi sono ricorrenti e la fornitura ha
durata di medio-lungo termine (> 6 mesi).
Decisi i termini dello scambio, le parti sottoscrivono un contratto di
fornitura più o meno aperto a possibili variazioni future. Al contratto
segue un OdV (Ordine di vendita).
Al contratto, come approfondiremo in seguito, è allegato ad uno più PdF
(Piano\i di Fatturazione), ossia pianificazioni rateali di pagamenti che si
estendono per tutta la durata della fornitura.
La moltiplicazione dei PdF deriva dall’eventuale molteplicità di tipi di
servizi forniti e delle località in sui sono erogati, dalle distribuzioni di
responsabilità e da altre particolarità organizzative.
Il Piano di Fatturazione perciò ha due aspetti analitici: il primo è il
contratto, che lo riconduce al committente, e il secondo è un elemento
“base” dell’attività core dell’azienda, che chiameremo Work Breakdown
Element e approfondiremo in seguito. (Vd. Cap. 5.2.2). Con i tempi
previsti dal contratto stipulato segue, allora, l’inizio dell’erogazione del
servizio
E’ questo il punto in cui, agli intervalli corretti, le fatture dovrebbero
essere emesse. Questo nella misura in cui:
o Il committente non ha intenzione di intraprendere alcuna
rinegoziazione, reclamo o altre azioni che rallenterebbero il
processo
o L’ufficio amministrativo è efficiente nel suo monitoraggio delle
fatture da emettere e rapido nell’operatività vera e propria
Dopo che il committente ha ricevuto la fattura effettua il pagamento,
dando origine al vero e proprio flusso di cassa corrispondente.
Pag. 50
Ora, per concludere l’analisi specifica del processo è necessario dare un’idea più
precisa delle sue dimensioni enumerando alcuni tra i suoi parametri funzionali
più rilevanti.
In tal modo, si vuole sottolineare più di quanto non sia già stato fatto quanto un
sistema informativo reingegnerizzato possa essere utile alla sua ottimizzazione
o, più comunemente, al controllo del suo svolgimento corretto.
L’attuale attività, quasi del tutto manuale, di monitoraggio del Ciclo attivo è
svolta su un corpus di:
Più di 35.000 rate scadute negli ultimi sei mesi del 2013, per un totale di
circa 280 Milioni di Euro (una media di 46,7 Milioni di Euro mensili).
Una media di 45 Milioni di Euro di fatture emesse mensilmente, che
evidenzia il ritardo, in parte fisiologico come si dirà, del processo.
Un parco clienti che ha coinvolto, nei sei mesi di cui sopra, oltre 1400
ragioni sociali, per un totale di oltre 2200 contratti stipulati.
Alla luce di queste cifre, si può ben percepire la necessità di un sistema più
automatizzato per il loro controllo puntuale.
5.2.1 Rateizzazione e Fatturazione
Come detto nei capitoli precedenti, nei settori B2B la transazione finanziaria tra
le parti, contestualmente alla fornitura di un bene o servizio, di rado è
contemporanea a quella economica.
In particolare, quando il committente è un’azienda di proprietà o a
partecipazione pubblica, la burocrazia centralizzata impone pesanti
procrastinazioni che causando un bias finanziario a monte si proiettano “in
cascata” su tutta la catena di forniture di beni e servizi sottostanti.
Focalizzandosi sul nostro progetto, la richiesta di pagamento, spesso
corrispondente alla fornitura di un servizio ricorrente, è rateizzata in più
emissioni di fatture per dilazionare l’uscita di cassa “lato cliente” e, “lato
fornitore”, garantire contrattualmente le parti in termini di continuità della
Pag. 51
relazione: non sarebbe sostenibile un rapporto commerciale in cui avvenga un
unico pagamento al termine dell’erogazione del servizio, anche considerando
che questa può avere durata pluriennale.
Il contratto sottoscritto da committente e fornitore è collegato ad uno o più (a
seconda del numero e delle caratteristiche dei servizi acquistati) PdF.
Essi, a loro volta, sono “scomponibili” in più Rate.
La rata diventa l’elemento fondamentale del nostro studio: ognuna di esse è
caratterizzata da un importo monetario e da una data di scadenza.
Se idealmente la data di scadenza coincide o addirittura è successiva l’istante
dell’emissione della fattura, quest’ultimo è successivo nella stragrande
maggioranza dei casi reali.
Il lavoro svolto ci ha permesso un’analisi dettagliata del fenomeno ed è possibile
mostrare le statistiche a riguardo:
Figura 15 - Analisi globale del LT di fatturazione
La funzione Amministrazione è, come detto, chiamata a gestire la
documentazione necessaria ai rapporti con i clienti. Quel 47% dei casi in cui
viene oltrepassato il ritardo “fisiologico” dei 30 giorni (di distanza tra la
scadenza della rata come da contratto e l’effettivo avvio della transazione
finanziaria) indica che è necessaria un’osservazione più continua, puntuale e
dettagliata da parte del management.
Pag. 52
In questa attività di monitoraggio, che deve partire da un livello di indagine
macroscopico e potersi spingere fino alla massimo atomicità dei dati, un sistema
informativo efficiente ed efficace è lo strumento fondamentale dell’operatività
quotidiana.
Evidenziando dunque l’aspetto più saliente, ossia quello in cui dinamiche
patologiche si stanno sviluppando oltre il normale decorso del Ciclo Attivo, lo
strumento consegnato al Cliente consente alla funzione centrale di
Amministrazione, che a sua volta coordina i distaccamenti locali, di valutare
dove, per ogni dimensione di analisi richiesta, ci siano rate scadute da tempo e
ancora non emesse (e dunque fatture certamente non evase).
Pag. 53
5.2.2 Work Breakdown Structure
I dati del caso in esame sono caratterizzati dalla presenza di una dimensione
funzionalmente complessa detta Progetto o Commessa, la cui strutturazione si
riconduce alla teoria della WBS.
Una WBS (Work Breakdown Structure) è un sistema logico di decomposizione
di un progetto o, più genericamente, di un’attività in componenti additive [14].
La definizione di insiemi discreti di attività atomiche (Work Breakdown
Elements) è volto a facilitarne l’analisi di dettaglio, così come a definire più
precisamente il perimetro delle attività più ampie. Quest’ultima facilitazione
risulta particolarmente importante in caso di “ridistribuzioni” di responsabilità,
in cui un’attribuzione sfocata di partenza potrebbe rendere la revisione onerosa e
disfunzionale.
Nei processi legati al controllo di gestione e all’allocazione dei costi, uno studio
corretto della WBS incide positivamente sulla capacità dell’azienda di
riconoscere le vere fonti di inefficienze e sprechi.
La Work Breakdown Structure fornisce una base organizzativa solida allo
sviluppo naturale della pianificazione e controllo delle attività: grazie alla
divisione in elementi incrementali è più facile raggiungere condizioni di
modularità sia nei temi organizzativi, che in quelli contabili e di reportistica.
La WBS è costruita seguendo alcuni semplici principi logici:
Regola del 100% - Un WBE include il 100% delle attività definite in un
perimetro progettuale non più suddivisibile. Successivamente, la somma
dei nodi “figli” di uno di livello gerarchico superiore deve
necessariamente essere uguale al 100% delle sue attività.
Mutua esclusività - Oltre al criterio di additività al 100%, è importante
che non ci siano intersezioni tra gli elementi di tutti i livello gerarchici.
Riprendendo il semplice concetto di algebra relazionale, la relazione tra
un nodo gerarchico e i suoi figli dev’essere sempre 1:N, e non è possibile
che uno stesso “figlio” lo sia di più “padri”.
Livello di dettaglio - Il livello di dettaglio dei WBE deve essere definito
con attenzione, in quanto non deve eccedere nella precisione richiedendo
Pag. 54
di profilare le informazioni troppo in profondità rispetto a quanto
possibile nella pratica.
Allo stesso tempo, il livello dev’essere sufficientemente approfondito da
garantire, sia applicativamente sia a scopo informativo, la massima
granularità in cui ogni informazione possa essere rilevante.
Codifica razionalizzata - Gli elementi della WBS devono seguire una
numerazione o una codifica organizzata in modo da ridurre difficoltà di
lettura e ricerca, da evidenziare i rapporti gerarchici, minimizzare le
difficoltà tecniche e costituire una conoscenza facilmente trasmissibile.
Analizziamo ora le proprietà del sistema in esame:
Come accennato la WBS, sia nella teoria che nel caso, ha la forma di una
decomposizione gerarchica ad albero. Le risalite gerarchiche possono essere di
natura geografica, di responsabilità, contabili o funzionali.
Figura 16 - Schema delle risalite gerarchiche WBS
Per quel che riguarda il caso in esame, si individuano 4 risalite gerarchiche delle
WBS (in verde):
Pag. 55
La prima è Funzionale, per “Prestazione” (insieme ampio di servizi simili
svolti tipicamente per uno stesso cliente). Le “Prestazioni”, intese come
raggruppamenti di WBE (ossia Progetti), sono a loro volta raggruppabili
per “Tipo di Servizio”.
La seconda è Geografica, per “Provincia”, “Regione” e successivamente
“Area” di competenza.
Le Aree di competenza hanno una natura mista tra le aree Nielsen e i
raggruppamenti funzionali conseguenti contratti stipulati con grandi
clienti o gruppi di clienti simili.
La terza è anch’essa Funzionale, su gerarchia piatta, per “Modalità di
Erogazione” del servizio
La quarta è nuovamente Funzionale, afferente la gerarchia per centro di
costo\responsabilità trasversale, rinominato appunto per “WBS” e
raggruppabile a sua volta per “Mercato” di riferimento.
Da notare la presenza di due attributi “Cliente”, uno vero e proprio
“Committente” associato ad un contratto stipulato, l’altro “Cliente di
fatturazione”, ossia intestatario della fattura. Questi due possono differire in casi
peculiari, come la stipula di un contratto con un’azienda holding (o un ente
statale esteso) che demanda poi la fatturazione a consociate sottostanti (o, nel
caso statale, ad enti locali più ristretti).
Si tratta di una solo apparente ridondanza informativa, ed è stata risolta
escludendo il dettaglio del cliente di fatturazione: i piani di rateizzazione, infatti,
derivando dal contratto sono caratteristici dei committenti, a prescindere da chi
liquidi successivamente la fattura.
Infine un’attenzione particolare, che verrà approfondita in seguito, è stata rivolta
all’assegnazione corretta del WBE al dato atomico (Vd. Cap. 6.3.1).
Pag. 56
5.3 Bacino d’utenza
In un progetto di Business Intelligence è fondamentale studiare la numerosità e
le caratteristiche del bacino d’utenza previsto.
Il primo motivo della rilevanza di questo studio è, banalmente, la definizione
delle licenze software che saranno necessarie per l’ingresso in produzione (ossia
nella fase di vero e proprio utilizzo finale) dell’infrastruttura sviluppata.
Secondariamente, la composizione dell’utenza dev’essere nota per poter
strutturare al meglio la reportistica: un’utenza costituita da pochi manager di C-
level richiede una reportistica di massima sintesi che contenga poche
informazioni aggregate e rilevanti nella forma di cruscotti ed indici. In linea di
massima per una casistica di questo genere non sarà necessario sviluppare la
possibilità di approfondire l’analisi.
Volendo fare l’esempio opposto, più vicino al caso in esame, se il progetto fosse
destinato alla funzione “Amministrazione” e, all’interno di questa, non al
manager ma ad un process owner specifico (il responsabile del Ciclo Attivo) e ai
suoi collaboratori, certo sarebbe necessario fornire le informazioni di sintesi, in
modo da dare istantaneamente, all’apertura del report, un’idea della situazione,
ma parallelamente andrebbero fornite tutte le capacità di analisi libera care ad un
utente business che voglia conoscere le informazioni al massimo dettaglio
possibile.
Ancora una volta, Excel ritorna l’argomento centrale: se il C-level è ben
soddisfatto da una reportistica web-based, accessibile rapidamente e magari in
mobilità, l’utente business che ha bisogno di svolgere analisi di dettaglio
richiederà certamente di poter utilizzare per i suoi scopi lo strumento con cui ha
più dimestichezza.
Come detto al Cap. 3.1, sotto questo profilo è nuovamente palese la forza
contrattuale e il valore dell’offerta di Microsoft rispetto ai concorrenti (costretti,
di fatto, ad interfacciarsi con Excel).
Entrando nel dettaglio del caso in esame, gli utenti erano costituiti da:
Il dirigente responsabile dell’ufficio amministrativo
6 operatori dello stesso ufficio
Pag. 57
2 consulenti esterni, un analista e un esperto funzionale, impiegati
nella revisione del processo di Ciclo attivo
Una volta terminato il progetto abbiamo erogato una formazione ad hoc per il
corretto sfruttamento del pieno potenziale del nuovo strumento a supporto delle
decisioni.
6 Modello dei dati
6.1 Analisi del database sottostante il sistema Transazionale
Figura 17 - Struttura tabelle dati in SAP
In figura 17 sono riportate le tabelle dei dati principali presenti nel sistema
transazionale (SAP)2. La notazione utilizzata per i rapporti logici tra le tabelle è
codificata in questo modo:
2 Lo schema completo di tutte le tabelle anagrafiche, data la sua complessità, non è riportato e ne saranno citate
quando necessario le frazioni più rilevanti.
Pag. 58
Figura 18 - Notazione frecce figura precedente
Siccome il sistema è, come detto a proposito degli OLTP, strutturato a scopo
documentale e ottimizzato per la memorizzazione di input anziché per la
restituzione di output, si noti come sono presenti relazioni 1:1 tra le tabelle,
assolutamente non ripetibili all’interno del DWH (dai criteri di normalizzazione
di cui al capitolo 3.2.2, due tabelle le cui chiavi sono in relazione 1:1 tra loro
non avrebbero motivo di esistere, esse devono essere trasformate in una sola
tabella con i campi di entrambe).
Si aggiunga che tutti gli attributi, come i raggruppamenti per clienti ed aree,
sono separati sia dalle tabelle dei dati cui riferiscono sia tra loro, coerentemente
con la teoria degli Snowflake schema. Con l’eccezione rilevante dei casi di
relazione 1:1 di cui al paragrafo precedente, si riscontra anche nel caso reale la
tendenza nella struttura del DB transazionale alla massima forma di
normalizzazione. Tutte le tabelle sono legate tra loro da vincoli di integrità
referenziale sulle chiavi. Le più importanti nello schema sono:
Codice Testata Fattura e Posizione sulla Fattura
Codice Testata Piano di Fatturazione e Posizione su di esso (singola Rata)
Codice Testata Contratto e Posizione sul Contratto
I dati, intesi propriamente come importi monetari e date di calendario di
interesse, sono concentrati sulle due tabelle “marcate” in figura 17 con il bordo
doppio, ossia le tabelle dei dettagli delle fatture e dei piani di fatturazione.
Si è scelto, in fase di studio funzionale, di concentrare le analisi lungo due
dimensioni: Contratto (Tabella “Testate contratto” in figura 17) e WBE (Work
Breakdown Element, per le sue caratteristiche, la teoria sottostante e il
complesso processo di associazione e ripartizione con i fatti Vd. Capp. 0 e 0).
La terza dimensione di analisi è chiaramente il Tempo, e la granularità massima
richiesta è quelle mensile. Oltre a queste, è presente una quarta dimensione
imputata manualmente nella reportistica pre-progettuale e dunque non estraibile
direttamente dal sistema transazionale, detta “Tipo Cliente”.
Pag. 59
6.2 IMPORT
Analizzata la fonte dati sottostante si può proseguire con la documentazione
puntuale di quanto realizzato attraverso SQL Server Integration Services per
alimentare, partendo dalle fonti dati (file Comma Separated Value esportati dal
transazionale SAP), il database “Import”.
6.2.1 Criticità dei dati in ingresso
Le criticità risolte, relative alle peculiarità dei dati in ingresso, sono state le
seguenti:
DATI GENERATI “MANUALMENTE”, NON PRESENTI
ALL’INTERNO DEL SISTEMA TRANSAZIONALE
La casistica è riconducibile a quanto detto riguardo i comportamenti
patologici nel trattamento dei dati (Vd. Cap. 3.2).
Risoluzione:
Nella fase di import, proprio per la natura esterna al transazionale, non è
possibile gestire problematiche di questo genere.
“Mascherare” un dato imputato in maniera destrutturata ed esterna al
transazionale trattandolo come lo standard nasconderebbe le provenienze
dei dati creando confusione in seguito. Sarà sufficiente predisporre delle
tabelle manuali (ossia non alimentate automaticamente dai flussi di
Integration Services) opportunamente riconoscibili e popolate ad hoc in
Staging Area. L’obiettivo nel lungo termine è, comunque, che
l’informazione sia integrata nel sistema transazionale.
E’ tuttavia importante che la consulenza “partecipi” allo studio
dell’integrità dei dati, evidenziando in tal modo le inefficienze operative
qualora informazioni molto rilevanti risiedano fuori dal sistema
transazionale.
Pag. 60
FULL REFRESH vs INCREMENTALE
Va valutata la differenziazione tra le tabelle anagrafiche, da importare ad
ogni caricamento completamente e ignorando i dati contenuti in
precedenza (logica “full-refresh”) e quelle contenenti fatti, ossia dati, che
visti i volumi e la sostanziale “cristallizzazione” delle tuple inserite in
passato dovrebbero essere trattate diversamente, cercando di limitare lo
sforzo computazionale (logica “incrementale”).
Risoluzione:
Abbiamo effettuato uno studio puntuale della metodologia migliore di
importazione a seconda della natura dei dati (Vd. Cap. 6.2.2).
TRATTAMENTO DEI FILE *.CSV
I file Comma Separated Value esportati dal sistema transazionale sono
stati posizionati in una cartella e caratterizzati da un prefisso che contiene
la data dell’esportazione e la versione dell’estrazione (nel senso di
versione della procedura informatica).
Il loro nome, quindi, varia con la data e non è univocamente identificabile
da SSIS.
Risoluzione:
Avendo una cartella di export (da SAP) \ import (nel sistema di BI) che
rimanga sempre la stessa a disposizione, questa viene trattata da un
modulo di SQL Server Integration Services che:
o Cerca i file più recenti per ogni tabella analizzando i prefissi dei file
o Li carica nel sistema a seconda della logica impostata
o Elimina i file più vecchi di sette giorni per le tabelle incrementali,
così da mantenere la pulizia della cartella e, contemporaneamente,
conservarne una breve memoria storica aggiuntiva ai backup di
sicurezza.
Per le tabelle full-refresh, non essendo necessaria la memoria
storica (la tabella viene estratta completamente ogni giorno), sono
eliminati tutti i file più vecchi di quello odierno.
Pag. 61
INTEGRITA’ DEI DATI IMPUTATI
Il sistema transazionale ha, tra i suoi principali motivi d’essere, il
controllo dell’integrità e della validità dei dati imputati al suo interno.
Nonostante ciò, l’incrementalità che caratterizza i progetti di sviluppo di
un sistema gestionale e la sua modularità spesso portano i vincoli meno
stringenti a “diluirsi” nel tempo, per esempio con la modifica del
significato funzionale di un campo.
Può succedere, per esempio, che un campo di testo sul sistema gestionale,
inizialmente dedicato alle “note varie” e coerentemente con un unico
vincolo di integrità sul numero di caratteri massimo imputabile, si
consolidi nell’utilizzo quotidiano come il campo utilizzato per
memorizzare una data, tanto che all’avvio di un progetto interfunzionale e
coordinato di analisi del dato quel campo debba a tutti gli effetti essere
trattato come una data nonostante la sua diversa natura.
Per un intervento di queste ridotte dimensioni è possibile che, data
l’apparente non significatività, non si fosse ritenuto necessario contattare
gli sviluppatori del transazionale per effettuare la modifica.
Risoluzione:
Nel caso di dati manuali inseriti con un senso funzionale diverso dal
proprio “tipo dati” tecnico, è sufficiente segnalare la loro inutilizzabilità a
scopo informativo.
Questa soluzione mantiene integro il data warehouse ma non è
ovviamente sufficiente nel caso in cui un dato molto rilevante ai fini
progettuali fosse contenuto in un campo di questo genere.
In quest’ultima ipotesi, verificatasi, questi sono stati i percorsi risolutivi:
o Nel caso in cui gli utenti siano stati formati diversamente sulla
compilazione in periodi diversi, importare solo i dati imputati nei
periodi in cui questi sono rilevanti ed escludere gli altri
o In caso contrario, inserire dei controlli sulla presenza di determinate
sottostringhe nel testo imputato, così da poter attribuire il significato
corretto basandosi su di esse.
Pag. 62
Si noti come in questa fase non si tratti alcun concetto relazionale tra le tabelle:
tutti i ragionamenti sulla referenzialità e l’integrità delle chiavi, così come sulla
normalizzazione, sono rimandati alla fase di Staging Area.
6.2.2 Scelta del criterio incrementale\full-refresh
In ogni progetto di data warehousing è necessario che il sistema informatico sia
messo in condizione di aggiornarsi automaticamente trasferendo al suo interno
l’ultima versione dei dati, senza l’intervento dell’operatore umano.
Nel caso in esame questa re-importazione, detta comunemente Refresh dei dati,
è quotidiana e avviene in orario notturno per evitare congestioni nel traffico dati
o nell’uso dei processori dei server.
Svolgendosi con tale periodicità, pur trattando un ambito progettuale, è da
escludere la possibilità di reimportare l’intero storico ad ogni lancio automatico.
E’ allora necessario, per ogni tabella o insieme di tabelle simili, studiare quale
sia la logica migliore di importazione.
I criteri di scelta sono:
Natura del dato e sua storicizzazione
Performance delle operazioni di caricamento
In linea di principio, una dimensione cristallizzata temporalmente, ossia fissata
nell’organizzazione aziendale, offre un costo computazionale minore se
aggiornata in maniera incrementale (anche perché la scrittura sul database sarà
quasi nulla ad ogni caricamento).
La modalità incrementale, inoltre, è da utilizzarsi nel caso in cui la tabella sia
essa stessa aggiornata in modo additivo.
Al contrario, una dimensione che evolve velocemente, ossia che presenta molte
righe aggiunte o modificate ad ogni caricamento, offre un costo computazionale
miglior se aggiornata in full-refresh, dato che il controllo su tutte le righe
modificate occuperebbe le risorse a disposizione per un tempo molto superiore
rispetto alla semplice eliminazione e ri-creazione della tabella.
Anche una tabella le cui righe possono essere eliminate dal sistema sottostante
(senza causare perdite di informazioni) dev’essere gestita in full-refresh.
Pag. 63
Risultano dunque queste configurazioni:
Per le tabelle “dei fatti”, contenenti cioè i dati relativi ad eventi contabili
come scadenze rateali ed emissione delle fatture, si utilizza una logica
incrementale: esse non devono mai essere eliminate dalla base dati ma, in
caso di errori di imputazione, contenere delle tuple contrassegnate come
non più valide. In questo modo si garantisce che con il passare del tempo i
dati passati di uno stesso periodo non possano cambiare.
Per le dimensioni più importanti, legate direttamente al dato atomico, si
utilizza nuovamente una logica incrementale:
Di esse è necessario mantenere la memoria storica, così che i dati passati
non perdano la possibilità di riferirvi
Per le dimensioni che cambiano più velocemente e/o con pochi elementi,
si utilizza una logica in full-refresh.
6.2.3 Algoritmo di Upsert per la gestione dei dati incrementali
Col termine Upsert (o Merge) si intende l’operazione di aggiornamento di una
tabella incrementale. Questa consiste nell’aggiunta (APPEND) delle righe
presenti nella fonte dati ma non nella destinazione e nella modifica (UPDATE)
delle righe invece già presenti ma caratterizzate da attributi diversi: questo
significa che nella fonte dati, a sua volta, non è presente ad ogni caricamento
l’intero storico ma soltanto le righe recentemente aggiunte\modificate.
Innanzitutto va ricordato che il concetto di “presenza” di una riga nella tabella di
destinazione non si riferisce all’intera riga (in questo caso infatti perderebbe di
significato il concetto di “UPDATE delle righe già presenti”), bensì solo al suo
campo (o ai suoi campi) di chiave primaria.
L’algoritmo di Upsert consiste nelle seguenti fasi:
Verifica della presenza delle nuove righe importate all’interno della
tabella di destinazione, in base al confronto tra le concatenazioni di tutti i
campi chiave (a formare un’unica stringa-chiave)
Per le righe non presenti, aggiungi le nuove righe nella destinazione
Per le righe presenti, modifica le colonne non chiave
Pag. 64
Si noti come l’algoritmo, come accennato in precedenza, non gestisca la
cancellazione di righe dalla destinazione: esso può solo incrementare la tabella,
al contrario del più semplice algoritmo di full-refresh.
6.3 STAGING AREA
Il background teorico su come debba essere predisposta la fase di Staging è
contenuto nel capitolo 3.3.2.
Entrando nel dettaglio più operativo, si riporta il Control Flow d’insieme che
contiene la sequenza degli step in cui è stata organizzata la SA:
Figura 19 - Control Flow generale per la Staging Area in Integration Services
CONFIG
Il primo step di configurazione popola una tabella temporale con metodologia
“Rolling”: ad ogni rilancio viene ricalcolata con l’avanzare della data odierna
ma mantenendo costante l’ampiezza temporale di analisi.
Pag. 65
Gli attributi assegnati ad ogni data sono gli insiemi temporali di Settimana,
Mese, Trimestre, Anno. Inoltre è presente un attributo che identifica se il giorno
in esame sia feriale o festivo.
La data maggiore e minore di questa tabella temporale serviranno in seguito a
limitare il perimetro di analisi dei dati, esse non sono quindi fisse ma
parametrizzate all’interno di una tabella manuale (la quale riporta il numero di
mesi per cui vanno conservati i dati passati e quelli futuri).
PROGETTI e CONTRATTI
Nel sistema SAP i dati dimensionali sono presenti, come detto parlando degli
OLTP, in forma più normalizzata possibile.
Nella tabella anagrafica di una dimensione, dunque, non è presente tutto l’albero
gerarchico di cui essa è foglia ma soltanto la chiave esterna che rimanda ad una
seconda tabella (degli elementi “Padre” di primo livello, come ad esempio la
Provincia per i Progetti).
Su questa tabella “Padre” sarà presente un elemento descrittivo che identifica
l’elemento stesso e l’eventuale riferimento alla tabella “Padre” di secondo
livello (come ad esempio la Regione per le Province) e così via fino al
raggiungimento del più alto livello gerarchico.
Per le due dimensioni di analisi fondamentali, partendo dalla tabella anagrafica
normalizzata presente nel sistema SAP, sono associati attraverso LOOKUP (Vd.
Cap. 4.2.2) tutti gli attributi necessari allo studio funzionale, recuperati dalle
varie relazioni in cui si trovano seguendo le risalite gerarchiche.
Si riporta, ad esempio, il Data Flow SSIS che popola in maniera incrementale la
tabella di Staging Area dei Contratti:
Pag. 66
Figura 20 - Data Flow di trattamento dei Contratti - Staging Area
Il seguente Data Flow consiste in:
1. Importazione della tabella dei Contratti (dall’ambiente IMPORT,
TT_AMM_VBAK è l’effettivo nome della tabella nel data warehouse)
2. Lookup con la tabella dei contratti in STAGING AREA
a. Nel caso in cui il Lookup abbia successo (le chiavi della tupla in
IMPORT sono già presenti nella tabella dei Contratti) si verifica
che almeno uno dei campi non chiave sia stato modificato
i. Se almeno un campo è stato modificato, la riga viene
aggiornata attraverso un update in SQL
ii. Se nessun campo è stato modificato, la riga non viene
modificata
1
2
3
4
5
6
Pag. 67
b. Nel caso in cui Lookup non abbia successo (la riga proveniente da
IMPORT non era presente nella tabella dei Contratti), le operazioni
sono bypassate e la nuova riga è accodata a quelle già presenti
3. Tutti i risultati sono uniti tra loro in un’unica tabella virtuale.
4. Sulla tabella importata era presente solo la chiave dell’attributo Cliente,
senza la descrizione associata.
Perseguendo la denormalizzazione, la tabella cerca attraverso un Lookup
la descrizione del proprio Cliente sulla relativa anagrafica.
Nel caso in cui questa non venga trovata, una Derived column (Vd. Cap.
4.2.2) inserisce un attributo “Descrizione cliente” fittizio.
5. Lo stesso processo visto per il Cliente è replicato per l’attributo “Tipo
contratto” (la dicitura TDV significa “Tipo documento di vendita”)
6. Il risultato delle elaborazioni viene memorizzato nella tabella di
destinazione temporanea, che sarà poi copiata in quella definitiva di
Staging Area. Passando per questa tabella “di servizio” si guadagna un
ulteriore punto di controllo prima dell’aggiornamento dei dati.
A fronte di un calo di performance trascurabile, dato che l’uso di una
temporanea è limitato a tabelle con una numerosità di tuple ridotta,
usando questo semplice artificio ci si cautela da possibili errori di
sviluppo che potrebbero portare alla perdita di tutti i dati storici.
RATE
Nel caso in esame siamo partiti da una struttura tabellare replica di quanto visto
per il sistema transazionale (output della fase di Import) e, attraverso un JOIN
multiplo, abbiamo collegato tra loro tutte le tabelle per trarne una soltanto
(Tabella “Rate” in Staging Area) che contenesse sinteticamente, per ogni singola
Rata da piano di fatturazione, le seguenti informazioni:
Codice e posizione Rata
Data Scadenza della Rata, sia passata che futura
Importo netto registrato sulla Rata
Eventuale codice e posizione Fattura, nel caso in cui quest’ultima sia stata
emessa
Pag. 68
Eventuale data Emissione della Fattura
Eventuale importo netto registrato sulla Fattura
Work Breakdown Element (Progetto)
Codice e posizione Contratto
Attributo codificato “Tipo Cliente”
Il JOIN multiplo utilizzato è di tipo LEFT OUTER: partendo da tutti i record
della tabella dei PdF (su cui è incentrata l’analisi), le altre tabelle sono collegate
ad essi attraverso le chiavi mantenendo i casi (ossia le “rate”) in cui la
corrispondenza non sia trovata.
Un esempio di immediata semplicità è una riga di piano di fatturazione (ossia
una singola rata) con data di scadenza passata a cui non corrisponde, nella
relativa tabella, una fattura.
L’informazione della rata scaduta va assolutamente mantenuta per dare
consistenza all’analisi, viceversa una fattura emessa senza un’associazione ad un
piano di fatturazione (afferente cioè a qualsiasi ricavo non rateizzato) non è
rilevante per il dominio di analisi progettuale.
Questo è, per intero, la “catena” di JOIN implementata per creare l’unica tabella
dei fatti:
Figura 21 - Struttura dei JOIN per la creazione della tabella dei fatti in SA
Pag. 69
Le frecce con un cerchio alla base rappresentano gli OUTER JOIN
unidirezionali, che mantengono tutti gli elementi della “prima tabella” (nel
nostro caso quella delle Rate) anche se non corrispondenti agli elementi della
“seconda”. Le frecce tratteggiate, in grigio, rappresentano un diverso percorso
relazionale disponibile per l’analisi, passante per il flusso documentale.
Questo percorso non è utilizzabile contemporaneamente a quello principale nella
struttura a JOIN multipli in quanto avrebbe chiuso un percorso circolare,
circostanza assolutamente da evitare per mantenere l’integrità dei dati.
L’informazione è stata riportata comunque in figura 21 poiché utilizzato in fase
di sviluppo, come “contro-prova” della correttezza del percorso standard.
6.3.1 Relazione con i Work Breakdown Elements
In fase di Staging avviene il collegamento tra i “fatti” numerici e gli elementi
della Work Breakdown Structure (detti anche Progetti), evidentemente mancanti
nella struttura dei JOIN del capitolo precedente.
Il collegamento è delicato poiché attraverso l’attributo Progetto si attribuisce
l’area aziendale e la responsabilità personale relativa ad ogni particolare
“evento” di richiesta di pagamento \ fatturazione: in pratica si evince chi e dove,
nella gerarchia aziendale, sia il referente di un possibile ritardo di pagamento.
Il criterio di associazione funziona in questo modo:
Figura 22 - Associazione tra "Fatti" e WBE
Pag. 70
Sul sistema transazionale è presente una specifica tabella che contiene le “regole
di liquidazione”, ossia i criteri con cui sono organizzati i pagamenti.
Queste regole sono specificate sui Contratti (relazione tratteggiata in tabella) e
ognuna di esse specifica un Progetto associato.
Se non ci fossero logiche aggiuntive a questa, l’attributo Progetto sarebbe
collegato attraverso un legame relazionale (gerarchico) al Contratto, e dunque
essi sarebbero diversi livelli di un’unica gerarchia dimensionale.
All’emissione della fattura, tuttavia, l’utente del transazionale popola
manualmente un campo differente, che può sovrascrivere il Progetto che
proviene dalle regole di liquidazione.
Dal punto di vista organizzativo, il caso può essere spiegato sottolineando la
durata dei Contratti, che possono propagarsi per anni e dunque “sopravvivere” a
cambiamenti nell’organizzazione aziendale. Questo fenomeno funzionale,
comunque sia, non è stato ulteriormente approfondito.
Al momento di una fattura odierna, nel 2013, afferente un servizio il cui
contratto è attivo dal 20023 è altamente probabile che il Progetto imputato
correttamente all’atto della stipula dieci anni fa sia cambiato: ad esempio le Aree
possono essere state riorganizzate, il turn-over dei responsabili ha inciso
sull’organigramma oppure le modalità di erogazione sono cambiate per adattarsi
alle esigenze del committente.
Coerentemente con la logica di integrità totale che fonda il concetto di sistema
transazionale, il WBE del 2003 è ancora presente in base dati, magari
contrassegnato come non più attivo, e le modifiche dei suoi attributi si sono
tradotti nella creazione di uno o più WBE aggiornati.
L’utente imputa quindi il nuovo Progetto al momento della fatturazione e, in tal
modo, non sovrascrive solo quello collegato alla fattura ma, dati i JOIN spiegati
precedentemente, anche quello collegato alla rata scaduta (di fatto, si tratta della
stessa entità sul data warehouse).
Questo fenomeno genera una relazione molti-a-molti tra Progetti e Contratti in
virtù della differente natura temporale e richiede che essi siano, come previsto,
due dimensioni distinte.
Pag. 71
L’associazione Fatti \ WBE non è gestita attraverso gli oggetti precostruiti di
SSIS, ma attraverso una clausola SQL nel JOIN iniziale (quello che elabora la
tabella delle rate) per minimizzare il costo computazionale.
Ad arricchire il modello, si aggiunga che le associazioni ai Progetti descritte, sia
dalle Fatture che dai Contratti, non sono in relazione 1:1.
La natura puramente contabile \ organizzativa di questa associazione, infatti,
richiede un processo di ripartizione degli importi di partenza (associati ad una
singola fattura se manualmente, o ad un singolo contratto se attraverso le regole
di liquidazione) su più di un elemento WBE.
Nelle due tabelle di associazione, quindi, è presente un campo numerico che
contiene la percentuale di ripartizione scelta.
Anche in questo caso, la soluzione tecnica deriva da una contingenza funzionale:
se per esempio la responsabilità dei rapporti con un singolo cliente è condivisa
tra due o più Project manager, occorre creare dei corrispondenti Progetti
attraverso cui risalire ai rispettivi responsabili.
Stesso discorso vale, per esempio, per un contratto stipulato con un solo cliente
che abbia sedi in diverse regioni d’Italia, e le cui WBE sono dunque distinte.
Nel dettaglio, ecco la metodologia scelta per gestire queste complessità espressa
in codice SQL, dove le parti non rilevanti sono state “sintetizzate” in linguaggio
naturale:
Definizioni:
[FATTURE] := Tabella posizione fatture
[REGOLE_LIQ] := Regole di liquidazione, contiene il
riferimento (1:1) al contratto e al WBE
[CONTRATTI] := Tabella posizione contratti, contiene il
riferimento (1:N) alle posizioni fatture
[FATTURE_WBE] := Associazione manuale Fatture \ WBE,
contiene il riferimento (1:1) alla
posizione fattura e al WBE
SELECT
[Tutti i campi di interesse come da modello],
cast(
Pag. 72
Isnull(
[FATTURE_WBE].[PERCENTUALE],[REGOLE_LIQ].[PERCENTUALE]
)
as float
)
as PERCENTUALE,
from
[RATE]
LEFT OUTER JOIN
[Tutte le tabelle di interesse come da modello]
ON […]
LEFT OUTER JOIN [FATTURE_WBE]
ON [Chiave di join tra FATTURE_WBE e CONTRATTI]
LEFT OUTER JOIN [REGOLE_LIQ]
ON (
[Chiave di join tra REGOLE_LIQ e FATTURE]
AND
[Chiave di join tra FATTURE_WBE e CONTRATTI]
IS NULL
)
WHERE
[FILTRI per eliminare i dati non significativi]
Attraverso l’inserimento della clausola all’interno del secondo JOIN,
quest’ultimo viene tentato solo se il primo è fallito, escludendo il rischio di
“raddoppiamento” delle righe.
La percentuale di ripartizione è inserita nella SELECT, ma anziché estrarre sia
quella derivata dal primo JOIN sia quella del secondo in due colonne distinte
(considerando che se il primo join avesse successo, il secondo non dovrebbe
avvenire), si è preferito inserire la funzione ISNULL(X,Y) che restituisce Y nel
caso in cui X sia, appunto, non valorizzato.
Gli importi vengono moltiplicati per la percentuale di ripartizione
successivamente, mantenendo memoria del valore ante-ripartizione a
permettendo così di effettuare confronti e quadrature.
Pag. 73
6.4 Data mart e Cubo Multidimensionale
La fase progettuale di DM ha comportato uno sforzo particolare per quel che
riguarda la formulazione della tabella dei Fatti, mentre sostanzialmente nessuna
elaborazione per derivare dalla Staging Area le tabelle dimensionali, esclusa la
finalizzazione del processo di de-normalizzazione (per raggiungere la forma
canonica di uno Star Schema).
6.4.1 Studio sulla creazione della tabella dei fatti (Stock)
Come chiarito nella trattazione riguardo le fasi precedenti, la tabella dei fatti
ottenuta alla fine della Staging Area contiene, su ogni tupla, tutte le informazioni
relative ad una precisa rata (quindi principalmente la sua data di scadenza, in cui
era previsto il pagamento, e il suo valore monetario) e tutte le eventuali
informazioni relative alla fattura ad essa associata (principalmente la data di
emissione e il suo valore monetario).
Alla rata è associato un Contratto, come da schema del database transazionale, e
alla coppia rata-fattura è associato un Progetto attraverso il processo già
descritto nel capitolo 6.3.1.
La reportistica richiesta dal Cliente, invece, deve avere un punto di vista
profondamente differente. La rata dev’essere abbandonata come dimensione
chiave e, per ogni periodo in esame, è necessario poter ottenere un’analisi di
sintesi che contenga i seguenti indicatori:
Valore di Stock Iniziale rate scadute
Somma degli importi di tutte le rate scadute in periodi precedenti quello in
esame e fatturate in un periodo uguale o successivo (oppure del tutto non
fatturate)
Valore delle rate scadute nel periodo
Somma degli importi di tutte le rate scadute all’interno del periodo in
esame
Valore delle fatture nel periodo afferenti a rate:
o Scadute nello stesso periodo
Pag. 74
Rate fatturate nel periodo e scadute nello stesso
o Scadute in periodi precedenti, ma nello stesso anno
Rate fatturate nel periodo in esame e scadute in periodi precedenti,
tuttavia all’interno dell’anno in esame
o Scadute in anni precedenti
Rate fatturate nel periodo in esame e scadute in anni precedenti
Valore di Stock finale rate scadute
Calcolabile in due modi distinti: o come somma algebrica delle misure
precedenti (Stock iniziale + Scaduto – Fatturato per rate già scadute =
Stock Finale), oppure definibile come il valore di tutte le rate scadute in
periodi precedenti o in quello in esame e fatturate in un periodo
successivo ad esso (oppure del tutto non fatturate).
Dei due metodi il secondo, la cui logica non è influenzata da possibili
errori commessi nella definizione di misure precedenti, è stato usato per il
calcolo vero e proprio della misura, mentre il primo è stato usato solo ai
fini di quadratura.
Numero di Contratti distinti per ognuno degli indicatori sopra elencati
Numero di contratti distinti per cui esiste almeno una rata in stock
iniziale, scaduta, fatturata o in stock finale.
In un primo studio di fattibilità tecnica si è valutata l’opportunità di replicare,
sostanzialmente, la struttura “per Rate” della tabella dei fatti nei database di
DM. Una volta importata questa nel cubo SSAS, si sarebbe provveduto al
calcolo delle misure di Stock.
Questa ipotesi ci presentava due criticità:
Spostava il carico computazionale dal data warehouse al cubo SSAS e
dunque alla reportistica su Excel: i ricalcoli delle misure dinamiche
sarebbero avvenuti al lancio dei report, con conseguenti ritardi.
Mantenendo le aggregazioni a livello di data warehouse, al contrario,
l’impegno delle risorse sarebbe rimasto concentrato all’avvio notturno dei
caricamenti quotidiani.
Necessitava di una padronanza appropriata del linguaggio MDX: pur
avendo una potenzialità maggiore di SQL in virtù della tecnologia
sottostante, le competenze MDX sono molto meno diffuse e dunque
Pag. 75
l’applicazione risultante sarebbe stata molto meno manutenibile nel lungo
termine.
Per queste ragioni si è scelto di costruire la tabella delle misure di stock
all’interno del data warehouse. Le modalità con cui si è raggiunto questo
risultato sono l’oggetto del capitolo seguente.
6.4.2 Algoritmo di creazione della tabella dei fatti (Stock)
In figura 23 è mostrato il Control Flow SSIS sviluppato per la formulazione
della tabella dei fatti.
Figura 23 - Control Flow per la creazione della Fact Table (Stock)
1
2
3
2 4
2 5
6
7
Pag. 76
Il data mart delle misure di Stock, data la solidità del database sottostante in cui
le logiche di aggiornamento variano a seconda della natura dei dati, è trattato
interamente in logica “Full-refresh”.
Questo permette una manutenzione evolutiva estremamente più rapida
dell’ambiente, che essendo il più vicino alla reportistica è anche quello che,
rispondendo alle esigenze del Cliente, varia con maggior frequenza.
Il punto (1) del flusso elimina tutti i dati delle Rate in fase di DM. Le tabelle,
compresa quella finale di Stock, non vengono vuotate ma eliminate (DROP).
E’ interessante, a riguardo, chiarire perché la sintassi
DROP TABLE […]
SELECT […] INTO […] FROM […]
Sia preferibile in questa fase di sviluppo rispetto a quella:
TRUNCATE […] INSERT INTO […] SELECT […] FROM […]
Parte della risposta è già stata data: innanzitutto la qualità dei dati è stata
certificata in Staging Area e, dunque, essi sono già in quella fase completamente
consistenti.
Il secondo luogo, la manutenzione evolutiva dei database di DM, molto più
frequente rispetto a quella della Staging Area (mentre quella nella fase di Import
dovrebbe essere pressoché nulla), potrebbe richiedere l’aggiunta, la rimozione o
la modifica di colonne dalle tabelle di quest’area.
Prendiamo il semplice caso dell’aggiunta di un nuovo attributo che, su richiesta
del Cliente, sia da portare dalla Staging Area fino alla tabella dei fatti in DM.
Scegliendo il paradigma DROP \ SELECT INTO, sarà sufficiente aggiungere
alla clausola SELECT la nuova colonna.
Scegliendo il paradigma TRUNCATE \ INSERT \ SELECT sarà necessario
modificare la tabella di destinazione, cambiare poi la clausola INSERT e infine
aggiungere la colonna alla clausola SELECT.
Il punto (2) del Control Flow crea una tabella temporanea in cui i dati vengono
raccolti ed elaborati. Memorizzare questo stadio intermedio anziché portarli
direttamente nella destinazione finale garantisce modularità e conseguentemente
la possibilità di intervenire su partizioni limitate del processo in caso di errore.
Pag. 77
Figura 24 - Schema Data Flow (2) tabella temporanea Rate
In figura 24 è rappresentato in maniera compatta quanto viene svolto all’interno
del Data Flow (2). Oltre al filtro imposto sui periodi di interesse, i campi data
vengono convertiti (su colonne aggiuntive) in formato data: questa operazione
non è svolta in Staging Area per la rilevanza e la consistenza dei campi data
anche nel loro formato alfanumerico (AAAAMMGG).
Le Rate\Fatture non rilevanti sono mantenute in un’apposita tabella, così da non
perderle nel caso in cui cambiassero i criteri di significatività.
La procedura SQL in (3) popola la tabella dei fatti temporanea con dei flag,
ossia campi simbolici che indicano una precisa caratteristica della tupla, utili per
le elaborazioni successive. Alcuni di questi, sono “traduzione” più vicina
all’utente di flag esistenti anche nella tabella di SA, mentre altri sono estrapolati
dalle informazioni contenute nella tabella.
Il più importante, tra questi ultimi, è il campo “Stato Rata”, che viene
valorizzato secondo questi criteri:
0 se la rata è scaduta nel passato (data di scadenza presente e inferiore alla
data odierna) e mai fatturata (data di fatturazione non presente a seguito di
Pag. 78
mancato JOIN in Staging Area tra la tabella dei piani di fatturazione e
quella delle fatture)
1 se la rata è scaduta nel passato e fatturata regolarmente dopo la scadenza
2 se la rata è scaduta nel passato ma fatturata anticipatamente
3 se la rata scadrà nel futuro e non è fatturata
4 se la rata non ha data di scadenza (condizione di errore, teoricamente
impossibile da verificarsi dati i filtri precedenti ma inserita per coprire
tutte le casistiche idealmente possibili)
5 se la rata scadrà nel futuro e la sua fatturazione è già stata registrata con
data futura successiva alla scadenza (condizione anomala, non dovrebbero
esistere fatture registrate con data futura)
6 se la rata scadrà nel futuro e la sua fatturazione è già stata registrata con
data futura antecedente alla scadenza (condizione anomala, come sopra)
7 se la rata è scaduta nel passato e la sua fatturazione è già stata registrata
con data futura (condizione anomala, come sopra)
99 se nessuna delle condizioni precedenti è soddisfatta (condizione di
errore nella procedura stessa)
Figura 25 - Possibili valori del flag Stato Rata
Al punto (4) avviene la vera e propria popolazione della nuova tabella di Stock
(in realtà, come detto, non si dovrebbe parlare di popolazione quanto più di
eliminazione e ri-creazione).
Null Futura
Null4: Errore 4: Errore
Futura3 5
Passata0 7
DF > DS:
1
DF < DS:
2Dat
a d
i sca
dan
za (
DS)
Data di fatturazione (DF)
Passata
4: Errore
6
Pag. 79
L’algoritmo di questa query è piuttosto complesso, si procede ora con la sua
descrizione in un linguaggio SQL “mitigato”, più simile a quello naturale.
Si noti, innanzitutto, che la criticità fondamentale sta nel volgere una tabella che
contiene due colonne “Data”, una per la scadenza della rata e una per
l’emissione della fattura, in una che contiene una sola data e, per essa, rimodella
le misure di partenza con vari criteri temporali.
In altre parole si potrebbe dire che le date sono viste come misure nel primo
caso e che l’informazione in esse contenuta deve trasformarsi in una dimensione
tempo del secondo.
Come evidente a questo punto, le misure di stock iniziale e stock finale saranno
quelle che offriranno maggiori spunti di riflessione:
DEFINIZIONI:
[STOCK] := [ Dimensioni:
Periodo [PER] (Coppia Mese\Anno in
notazione AAAAMM),
Cluster di anzianità [ANZ],
Flag di stato della rata [Stato rata],
Contratto [CNT],
Progetto (WBS) [PRG],
Tipo Cliente [TCL]
Fatti:
Tutti quelli di cui al capitolo 6.4.1, per
Ogni casistica della rata è necessario
calcolare numero rate in quella condizione,
valore totale e giorni totali di anzianità
(la media si otterrà successivamente in
MDX, data la sua dipendenza dal livello di
aggregazione. Vd. Cap. 6.4.5)
]
[RATE] := Tabella delle rate in Staging Area risultante
dalle elaborazioni precedenti
[TEMP]:= Una tabella temporanea creata come buffer tra
quella delle rate e quella di stock per non
appesantire le già ingenti elaborazioni
successive.
Pag. 80
-- QUERY
DROP TABLE [STOCK]
-- Come spiegato, la query inizia eliminando la tabella
-- precedente
SELECT [Stato rata]
,[Codice Rata]
,[CNT]
,[PRG]
,[TCL]
,[CNT]
,[Data scadenza rata]
,[(Eventuale) data emissione fattura]
,[Valore netto rata]
,[Valore netto fattura]
,[Anno mese (AAAAMM) scadenza rata] (Mese scad.)
,[Anno mese (AAAAMM) emissione fattura] (Mese fatt.)
INTO [TEMP]
FROM [RATE]
-- Il calcolo del Mese-Anno partendo dalla data richiede
-- elaborazioni sulle date e le stringhe, dettagli tecnici
-- non riportati qui
-- Inizio SELECT INTO per tabella [STOCK]
SELECT
[PER]
,[ANZ]
,[Stato rata]
,[CNT]
,[PRG]
,[TCL]
-- Per ogni misura, come detto numero rata, valore rata e
-- giorni di anzianità, si utilizzano le clausole
-- sum(isnull(MISURA,0)
-- Se la MISURA è nulla, le viene sostituito 0 nella somma
INTO [STOCK]
FROM
(
-- 1° TERMINE DELLE UNION: RATE SCADUTE NEL PERIODO (a
Pag. 81
-- prescindere dallo stato di fatturazione).
-- NB: Sono considerate solo le rate scadute nel passato,
-- essendo il mese “attuale” di interesse solo per quel che -
-- riguarda il passato
SELECT
[Anno mese (AAAAMM) scadenza rata] as PER,
-- […] Tutte le altre colonne
FROM
T
-- “T” è l’anagrafica di tutti i mesi passati oggetto di
-- analisi
LEFT OUTER JOIN
[dbo].[TEMP] A
on T.[Anno mese] = A.[Anno mese (AAAAMM) scadenza rata]
WHERE
[Data scadenza rata] <= GETDATE()
UNION ALL
-- 2° TERMINE DELLE UNION: RATE SCADUTE NEL PASSATO MA
-- FATTURATE ANTICIPATAMENTE
SELECT
[Anno mese (AAAAMM) scadenza rata] as PER,
-- […] Tutte le altre colonne
FROM
T
LEFT OUTER JOIN
[TEMP] A
on T.[Anno mese] = A.[Anno mese (AAAAMM) scadenza rata]
WHERE
[Data scadenza rata]<= GETDATE()
AND
[(Eventuale) data emissione fattura] < [Data scadenza rata]
UNION ALL
-- 3° TERMINE DELLE UNION: RATE A SCADERE IN FUTURO
SELECT
[Anno mese (AAAAMM) scadenza rata] as PER,
-- […] Tutte le altre colonne
Pag. 82
FROM
T
LEFT OUTER JOIN
[TEMP] A
on T.[Anno mese] = A.[Anno mese (AAAAMM) scadenza rata]
WHERE
[Data scadenza rata] > GETDATE()
UNION ALL
-- 4° TERMINE DELLE UNION: FATTURE PER RATE SCADUTE NEL
-- PERIODO ATTUALE
SELECT
[Anno mese (AAAAMM) emissione fattura] as PER,
-- […] Tutte le altre colonne
FROM
T
LEFT OUTER JOIN
[TEMP] A
on T.[Anno mese] = A.[Anno mese (AAAAMM) scadenza rata]
WHERE
[(Eventuale) data emissione fattura] <= GETDATE()
AND
[Anno mese (AAAAMM) emissione fattura] =
[Anno mese (AAAAMM) scadenza rata]
UNION ALL
-- 5° TERMINE DELLE UNION: FATTURE EMESSE NEL PASSATO PER
-- RATE SCADUTE IN PERIODI SUCCESSIVI A QUELLO IN ESAME.
-- Si tratta di un caso particolare molto importante, perché
-- da non includere mai in nessun calcolo di Stock
SELECT
[Anno mese (AAAAMM) emissione fattura] as PER,
-- […] Tutte le altre colonne
FROM
T
LEFT OUTER JOIN
[TEMP] A
on T.[Anno mese] = A.[Anno mese (AAAAMM) emissione fattura]
WHERE
Pag. 83
[(Eventuale) data emissione fattura] <= GETDATE()
AND
[Anno mese (AAAAMM) emissione fattura] <
[Anno mese (AAAAMM) scadenza rata]
UNION ALL
-- 6° TERMINE DELLE UNION: FATTURE PER RATE SCADUTE IN
-- PERIODI PRECEDENTI, MA NELLO STESSO ANNO
SELECT
[Anno mese (AAAAMM) emissione fattura] as PER,
-- […] Tutte le altre colonne
FROM
T
LEFT OUTER JOIN
[TEMP] A
on T.[Anno mese] = A.[Anno mese (AAAAMM) emissione fattura]
WHERE
[(Eventuale) data emissione fattura] <= GETDATE()
AND
[Anno mese (AAAAMM) emissione fattura] >
[Anno mese (AAAAMM) scadenza rata]
-- Il successivo AND verifica che l’anno di emissione della
-- fattura sia lo stesso della scadenza della rata
AND
left([Anno mese (AAAAMM) emissione fattura],4) =
left(Anno mese (AAAAMM) scadenza rata,4)
UNION ALL
-- 7° TERMINE DELLE UNION: FATTURE EMESSE PER RATE SCADUTE IN
-- ANNI PRECEDENTI
SELECT
[Anno mese (AAAAMM) emissione fattura] as PER,
-- […] Tutte le altre colonne
FROM
T
LEFT OUTER JOIN
[TEMP] A
on T.[Anno mese] = A.[Anno mese (AAAAMM) emissione fattura]
WHERE
Pag. 84
[(Eventuale) data emissione fattura] <= GETDATE()
AND
[Anno mese (AAAAMM) emissione fattura] >
[Anno mese (AAAAMM) scadenza rata]
-- Il successivo AND verifica che l’anno di emissione della
-- fattura sia successivo rispetto a quello della scadenza
-- della rata
AND left([Anno mese (AAAAMM) emissione fattura],4) >
left([Anno mese (AAAAMM) scadenza rata],4)
UNION ALL
-- 8° TERMINE DELLE UNION: RATE IN STOCK INIZIALE ALL'INIZIO
-- DEL PERIODO
SELECT
-- Lo stock iniziale deve essere calcolato per ogni periodo,
-- a prescindere dalla presenza o meno di fenomeni contabili
-- in quel mese.
-- Per questo motivo, il periodo riportato non può più essere
-- quello di fatturazione o scadenza di una rata, ma deve
-- provenire direttamente dall’anagrafica dei mesi analizzati
-- (alias della tabella T)
T.[Anno mese] as PER,
-- […] Tutte le altre colonne
FROM
T
LEFT OUTER JOIN
[TEMP] A
on
-- Condizione 1: Rata Scaduta
T.[Anno Mese] > A.[Anno mese (AAAAMM) scadenza rata]
AND
-- Condizione 2: Rata fatturata in periodo successivo oppure
-- non fatturata
(T.[Anno Mese] <= A.[Anno mese (AAAAMM) emissione fattura]
OR A.[Anno mese (AAAAMM) emissione fattura] IS NULL)
UNION ALL
-- 9° TERMINE DELLE UNION: RATE RIMANENTI IN STOCK FINALE
-- ALLA FINE DEL PERIODO: Per il mese corrente, lo stock
-- finale va calcolato AD OGGI.
Pag. 85
SELECT
-- Per questa misura di stock valgono le considerazioni fatte
-- per la precedente
T.[Anno mese] as PER,
-- […] Tutte le altre colonne
FROM
T
LEFT OUTER JOIN
[TEMP] A
on
-- Il join che individua a seconda del mese lo stock finale è
-- Piuttosto complesso per la gestione del mese corrente.
-- In primo luogo si pone il mese di scadenza minore o uguale
-- a quello in esame
A.[Anno mese (AAAAMM) scadenza rata] <= T.[Anno Mese]
AND
(
(
-- La prima condizione prende i mesi passati
T.[Anno Mese] < [Anno Mese CORRENTE]3
AND
(
-- Verifica che la fattura non sia stata emessa
T.[Anno Mese] <
A.[Anno mese (AAAAMM) emissione fattura]
OR
A.[Anno mese (AAAAMM) emissione fattura]
IS NULL
)
)
OR
(
-- La seconda condizione prende il mese attuale
T.[Anno Mese] = [Anno Mese CORRENTE]
AND
(
-- Verifica che la rata sia scaduta “entro oggi”
3 La formula per ottenere la stringa Anno Mese corrente è: Concat
(
datepart(year,getdate()) ,
datepart(month,getdate())
)
Pag. 86
[Data scadenza rata] <= GETDATE()
AND
(
[(Eventuale) data emissione fattura] > GETDATE()
OR
[(Eventuale) data emissione fattura] IS NULL
)
)
)
)
)
-- Come nome “fittizio” per il risultato della query è usato
-- “Retrieve”
AS RETRIEVE
GROUP BY
[PER]
-- Il calcolo delle fasce di anzianità, piuttosto verboso nel
-- codice pur se e funzionalmente semplice, è stato omesso
-- nel riportare la query per mantenere la notazione più
-- pulita. La fascia di anzianità è una delle dimensioni
-- di aggregazione
,[ANZ]
,[Stato rata]
,[CNT]
,[PRG]
,[TCL]
DROP TABLE [TEMP]
-- La tabella temporanea viene eliminata al termine
-- dell’esecuzione
Il punto (5) contiene il TRUNCATE delle tabelle che saranno usate come
anagrafiche nei data mart: esse, infatti, sono riempite al punto (6) con i soli
elementi effettivamente valorizzati nella tabella dei fatti da poco generata.
Questo accorgimento permette di limitare il carico computazionale e,
soprattutto, ridurre la sparsità del cubo. Esso deriverà, come noto, una cella per
ogni possibile combinazione dimensionale (prodotto cartesiano): una piccola
riduzione della numerosità quando questa non è utilizzata per contenere dati
porta ad un grande guadagno di performance.
Pag. 87
Le righe contenenti gli elementi (Contratti e Progetti) non presenti nella tabella
dei fatti4 non sono eliminati ma vengono raccolti in tabelle marcate
appositamente (con la E di Errore), in modo che sia possibile una verifica di
quali elementi non hanno trovato riscontro nella tabella dei fatti.
Il caso di quadratura ricorrente è il seguente: nel caso in cui manchi nella
reportistica un elemento, supponiamo un contratto, è necessario sapere se il
problema risieda nel flusso che costruisce la tabella dei fatti (in tal caso troverò
il contratto nelle tabelle “di errore”) oppure in quello che costruisce le
anagrafiche (in tal caso non si troverà nemmeno lì).
Il punto (7), semplicemente, inserisce nelle due anagrafiche appena ricreate due
elementi “Dummy”, segnaposto fittizi per i casi di errore o di non valorizzazione
dell’attributo.
6.4.3 Denormalizzazione dei dati
Per la teoria sulla normalizzazione dei dati Vd. Cap. 3.2.2.
A posteriori rispetto alla relazione sul suo sviluppo, in questa sezione è mostrato
sinteticamente il profilo dimensionale del modello, soprattutto per quel che
riguarda la normalizzazione dei dati.
In figura 26 è riportato lo Star Schema relazionale del Data Mart da cui i dati
vengono trasferiti nel cubo (il quale a sua volta ricalca questa forma).
4Per “non presenti” si intende per cui non ci sono righe, nella fact table, che li contengano.
Pag. 88
Figura 26 - Star Schema applicativo
Con le “Misure di stock” già presentate all’inizio del capitolo. Si noti come le
gerarchie delle varie dimensioni, la cui più complessa è senza dubbio quella del
Progetto (tra le sue gerarchie è presente la Work Breakdown Structure stessa)
siano state denormalizzate completamente ed inserite nella sola tabella
dimensionale a cui, attraverso chiave surrogata “come da manuale”, si riferisce
la tabella dei fatti.
Questo rende leggibile il data warehouse dal sistema multidimensionale oltre a
ricondurre il modello dati ad uno schema noto e semplice, rendendo più rapide
eventuali query scritte ad hoc in fase di data profiling.
Pag. 89
6.4.4 Implementazione del cubo Analysis Services
Figura 27 - Dimensioni e cubo in SSAS
Come visto parlando di SSAS in termini generali, per lo sviluppo e la messa in
funzione dei cubi multidimensionali è stato necessario:
Impostare la connessione ad una Data source, nel nostro caso lo stadio di
DM contenente i dati organizzati sia per Rate singole che per Stock.
Data la connessione, caricare nel cubo le tabelle utili all’analisi in corso
attraverso la definizione di una Data Source View. Nel nostro caso le
dimensioni di interesse sono Contratto, WBS, Tipo Cliente e Tempo
Definire le dimensioni, esplicitando i criteri di aggregazione, i vincoli di
integrità referenziale e le eventuali gerarchie
Definire il cubo, ossia marcare, all’interno di una tabella dei fatti presente
nella Data Source View, quali siano le misure rilevanti e come queste si
aggreghino lungo le varie risalite dimensionali.
All’interno del modulo di definizione del cubo, definire in linguaggio
MDX le misure calcolate che svolgano operazioni non implementabili
direttamente in SQL Server: è questo il caso delle misure “Conteggio
Pag. 90
contratti”, che a seconda del punto di vista visualizzato in ogni istante nel
report deve effettuare il conteggio di tutti i contratti distinti per cui sia
presente un valore della misura diverso da zero per almeno una rata (o
fattura, dipende da quale misura si tratti)
La parte più interessante del processo, oltre alla descrizione delle dimensioni
notevoli che verrà svolta nel capitolo 7, è l’implementazione in MDX dei
membri calcolati.
6.4.5 Calculated Members in MDX (con cenni sul query language
multidimensionale)
MDX richiama SQL in alcuni aspetti sintattici, ma le sostanziali differenze
tecnologiche sottostanti rendono i due linguaggi profondamente distinti.
Analizziamo, per esempio, una semplice query SQL e il suo “corrispettivo” in
MDX evidenziandone similarità e differenze [15].
Supponiamo di avere a disposizione la seguente “Fact Table”:
Figura 28 - Esempio di tabella dei fatti (Vendite)
Questa, fisicamente una tabella nel caso relazionale, si traduce nel “centro” del
cubo nel caso multidimensionale. Da essa partiranno le tre risalite gerarchiche
delle dimensioni, evidenziate in verde: geografica (elemento foglia “City”),
organizzativa (elemento foglia “Vendor”) e temporale (elemento foglia “Date”).
In rosso le due misure, quantità e ammontare del “fatto vendita”.
Pag. 91
Per valutare la differenza tra i due linguaggi, supponiamo di voler vedere per
ogni Nazione e per ogni giorno l’ammontare delle vendite complessive
effettuate da un venditore specifico, il cui codice è “Test”.
Questo è il corrispondente linguaggio SQL: per effettuare la risalita gerarchica
che dalla città aggruppi per nazione, occorre attingere alla corrispondente tabella
dimensionale (supponiamo per semplicità che l’attributo COUNTRY sia, in
logica Star Schema, disponibile sulla tabella dimensionale che ha come Foreign
Key il riferimento a CITY: chiameremo questa tabella LOOKUP_CITY e il
campo di chiave esterna FK_CITY).
SELECT
B.COUNTRY,
A.DATE,
SUM(A.AMOUNT)
FROM
SALES A
INNER JOIN
LOOKUP_CITY B
ON A.CITY = B.FK_CITY
WHERE
A.VENDOR = ‘Test’
GROUP BY
B.COUNTRY,
A.DATE
L’esempio è volutamente semplice, ed enfatizza il procedimento via JOIN che
consente la risalita gerarchica.
Supponendo che la dimensione corrispondente alla foglia “City” si chiami
“Geography” e che la dimensione temporale si chiami “Time”, vediamo come si
gestirebbe in MDX [16] la necessità di ottenere la stessa informazione (nel
primo caso, la stessa identica tabella):
SELECT
{
[Geography].[Country].ALLMEMBERS *
[Time].CHILDREN
} ON ROWS,
Pag. 92
{
[Measures].[Amount]
} ON COLUMNS
FROM
[SALES]
WHERE
([VENDOR].&[Test])
Vediamo le differenze:
1. Nella clausola SELECT, si nota la separazione tra Righe e Colonne. Il
Cubo è più flessibile dello schema relazionale, e incentiva il pivoting
dimensionale (che grazie alla tecnologia utilizzata non è più oneroso
dell’alternativa tabellare).
2. Nel nostro esempio il pivoting non è necessario, e in riga è richiesto il
prodotto cartesiano tra tutti i membri (ALLMEMBERS)della dimensione
Geography al livello di aggregazione Country e tutte le foglie
(CHILDREN) della dimensione Time.
L’uso della clausola CHILDREN implica che la dimensione Time sia
“piatta”, non gerarchica, ed è solo un esempio di formalizzazione che
dimostra un modo di navigare i dati diverso dal SQL
3. In MDX, non esistendo tabelle, non è necessario alcun “JOIN” tra
strutture dati differenti
4. In MDX ogni misura, raggruppata logicamente nell’insieme Measures, ha
al suo interno una formula standard di aggregazione che non è necessario
ridefinire in ogni query.
Supponendo che quella di “Amount” sia SUM, è sufficiente richiedere
quella misura per vederne la sua somma aggregata.
5. Allo stesso modo, il cubo multidimensionale è pensato per facilitare le
aggregazioni: non è quindi necessario specificare alcun criterio di
raggruppamento, che avviene automaticamente sulla base di cosa è
posizionato in riga o in colonna.
6. La clausola WHERE ha una notazione diversa per specificare l’elemento
su cui filtrare: più che una selezione di un sottoinsieme di righe essa
esegue lo slicing dell’ipercubo
Pag. 93
Dopo questa breve digressione sulla sintassi, vediamo alcuni tra i Calculated
Members (CM) programmati in MDX.
I CM compaiono all’utente finale come misure normali, ma il calcolo che
contengono viene lanciato al momento in cui, dalla reportistica, lo si richiede per
un certo livello di aggregazione.
Per primo è proposto il più semplice, ossia l’elemento calcolato che partendo
dalle tre misure di fatturato (Rate fatturate scadute nel periodo attuale, rate
fatturate scadute in periodi precedenti ma nello stesso anno, rate fatturate
scadute in anni precedenti) ricava la somma delle tre (il fatturato totale nel
periodo).
CREATE MEMBER
CURRENTCUBE.[Measures].[Val Rate fatt Tot]
AS
[Measures].[Val Rate fatt periodo in corso] +
[Measures].[Val Rate fatt periodi prec] +
[Measures].[Val Rate fatt anni prec],
VISIBLE = 1 ,
ASSOCIATED_MEASURE_GROUP = 'Stock';
Si noti che la sintassi inizia con l’espressione CREATE MEMBER, incide
quindi non su una query costruita estemporaneamente ma sulla struttura stessa
del cubo. L’elemento così creato entra a far parte del gruppo di misure “Stock”,
come definito all’ultima riga.
VISIBLE segnala che l’utente finale potrà utilizzare questo elemento per le sue
analisi in Excel (o negli altri sistemi di reporting).
CURRENTCUBE è un segnaposto che permette di non riscrivere il nome del
cubo ad ogni formula.
Un secondo esempio è quello della media pesata dei giorni di anzianità usando
come driver il valore delle rate (per la definizione funzionale dell’elemento così
come compare nella reportistica Vd. Cap. 7.2.1).
Il codice corrispondente, per i giorni medi di anzianità dello Stock Finale, è il
seguente:
Pag. 94
CREATE MEMBER
CURRENTCUBE.[Measures].[Gg medi Anz. Stock Fin]
AS
IIF
(
[Measures].[Val Rate Stock Fin]<>0,
[Measures].[GgVal diff stock fin]5 /
[Measures].[Val rate stock fin],
NULL
),
VISIBLE = 1 ,
ASSOCIATED_MEASURE_GROUP = 'Stock';
In questo esempio è usato un semplice costrutto IIF per evitare la divisione per
zero. Il prodotto del valore da mediare per i pesi è effettuato sul transazionale
(Vd. Nota).
Il valore NULL è preferito a zero perché, nel caso in cui il valore delle rate in
stock finale sia zero, la casella non deve essere valorizzata sul cubo: in tal modo
si risparmia spazio su disco e, soprattutto, molto spazio sulla reportistica.
Il terzo e ultimo esempio è decisamente più complesso e interessante, poiché
opera su diversi livelli di aggregazione contemporaneamente.
Si tratta della misura “Conteggio Contratti” (per la definizione funzionale
dell’elemento così come mostrato in reportistica Vd. Cap. 7.2.2).
CREATE MEMBER
CURRENTCUBE.[Measures].[N Contratti Stock Fin]
AS
AGGREGATE
(
Filter
(
EXISTING
([Contratto].[Cod Contratto].[Cod Contratto]),
[Measures].[N rate stock fin] > 0
),
5 Si è scelto, per non complicare il calcolo multidimensionale e peggiorarne per performance, di dedicare un
campo sul DWH relazionale al prodotto “atomico” del Valore della Rata per i suoi Giorni di Anzianità. In questo
modo, il prodotto del valore da mediare per il suo peso è già presente nella formula ed è sufficiente dividere per
la somma dei pesi.
Pag. 95
[Measures].[CNT Distinct Count]
),
VISIBLE = 1 ,
ASSOCIATED_MEASURE_GROUP = 'Conteggio Contratti';
In questo esempio le potenzialità di MDX emergono più chiaramente che nei
precedenti. Partendo dal livello più interno della query, la keyword EXISTING
forza la valutazione del set di dati richiesto (quello che sarà sottoposto al
FILTER) all’interno del contesto richiamato dall’analisi corrente. Questa
istruzione forza quindi il calcolo al livello di aggregazione richiesto piuttosto
che, come standard, al livello di granularità dell’elemento in esame. Vediamo
più nel dettaglio cosa significhi e perché è necessario per il corretto conteggio.
In primis, supponiamo di utilizzare per il conteggio contratti il solo “CNT
Distinct Count”, ossia il conteggio di contratti distinti per ogni incrocio
dimensionale6.
Questa ipotesi non funziona perché l’informazione che serve non è una singola
misura di conteggio contratti, ma una per ogni “fenomeno di ciclo attivo”
oggetto di analisi (nell’esempio le rate in stock finale).
Per ogni incrocio dimensionale l’utente richiede il numero di contratti con rate
stock iniziale, con rate scadute, fatture e così via.
Supponiamo allora di inserire un filtro, nella forma della funzione FILTER che
sintatticamente è strutturata in questo modo:
Filter
(
Set di dati da filtrare,
Espressione logica booleana
)
Se inserissimo [Contratto].[Cod Contratto].MEMBERS come set da filtrare,
questi verrebbero valutati al massimo livello di granularità possibile: nel caso in
6 Distinct Count è una funzione di aggregazione standard di SSAS che può essere utilizzata per creare
automaticamente membri calcolati. CNT Distinct Count non è quindi un campo di data warehouse ma un
ulteriore sotto-calcolo eseguito dal motore multidimensionale.
Pag. 96
cui io richiedessi l’analisi per cliente (elemento padre gerarchico di Cod
Contratto), ne risulterebbe un conteggio errato.
EXISTING forza, allora, il conteggio al livello gerarchico richiesto dalla singola
query. Il FILTER estrae i soli codici contratto tali per cui è verificata la
condizione booleana successiva.
Ottenuto questo set di dati è necessaria la funzione AGGREGATE, la cui
sintassi è:
Aggregate
(
Set di dati su cui aggregare,
Espressione numerica da calcolare
)
Sul set di contratti calcolati al giusto livello di granularità (e per cui è soddisfatta
la condizione del FILTER) è aggregato il conteggio di contratti distinti, che ora
restituiscono la misura corretta così come definita dalle specifiche funzionali.
L’elaborazione risultante è particolarmente onerosa, tanto da aumentare di circa
quattro volte (circa 20 secondi contro i 4/5 precedenti) il tempo di calcolo dei
report. Per aggirare questo problema, non risolvibili con ottimizzazioni
computazionali, è stata prodotta una versione dei report descritti nel capitolo
successivo priva di questo tipo di misure, utili per analisi che non richiedano
questo dettaglio o siano necessarie “all’istante”.
Pag. 97
7 Fruizione dei dati
7.1 Distribuzione delle informazioni attraverso Intranet aziendale
e Microsoft Excel
Microsoft Excel è lo strumento privilegiato per le analisi approfondite ad opera
di utenti “non IT” (Vd. Cap. 4.2.4), questo a prescindere dal fornitore della suite
di BI utilizzata.
E’ infatti pratica trasversale a tutto il settore (e funzione aggiuntiva di tutte le
suite in commercio) l’esportazione dei risultati di un rapporto in formato *.xlsx,
al fine di poter proseguire nell’ambiente più familiare lo studio dei dati.
La scelta di Microsoft, però, apre alla possibilità di sfruttare integralmente il
potenziale dello strumento affiancato ad un cubo multidimensionale, tutto questo
senza la necessità di installare software aggiuntivi. L’integrazione tra Excel e
SQL Server Analysis Services permette di creare “al volo” una connessione dati
che dal secondo trasferisca direttamente porzioni di cubo all’interno di una Pivot
Table del primo.
Figura 29 - Connessione dati SSAS in Excel 2007
Pag. 98
Questa potenzialità rende particolarmente agevole la realizzazione di report
navigabili, dove dati di uno o più cubi SSAS possono essere restituiti all’interno
di un’unica cartella Excel. Questo può avvenire ad opera di uno sviluppatore
(infatti abbiamo realizzato tutti i report di cui al Cap. 7.4) oppure direttamente
ad opera dell’utente finale, opportunamente formato per svolgere correttamente
una analisi libera (free-analysis).
Si pone, a questo punto, il problema di come distribuire le cartelle così create a
tutti gli stakeholder di processo: lo strumento scelto per ottenere questo risultato
è, come detto, MS SharePoint (Vd. Cap. 4.2.5).
SharePoint gestisce la profilazione degli utenti basandosi su quanto presente in
Active Directory7.
Grazie a questa accortezza, agli utenti dell’ufficio Amministrazione (gruppo già
presente su Active Directory) sono stati associati in pochi click i diritti di
visualizzazione della reportistica.
Accedendo dal loro ufficio, inoltre, non sarà necessario alcun login aggiuntivo
per la fruizione delle informazioni.
Su SharePoint i report sono fruibili in 2 modalità:
Foglio di calcolo via browser, aggiornato all’ultima versione disponibile,
identico all’ultima versione Excel
Foglio di calcolo su Excel, scaricabile e salvabile sul proprio computer
L’utente può, in altre parole, decidere se vedere “al volo” i report dal proprio
browser, riportarsi in Excel per un’analisi più approfondita (eventualmente
spostando parti del report su altri fogli di calcolo per svolgere elaborazioni
personali) oppure aprire direttamente da Excel la free-analysis, con la possibilità
di definire ad hoc le proprie tabelle pivot.
Vediamo per prima quest’ultima ipotesi, ossia come il modello dati viene
visualizzato dall’utente finale in fase di free-analysis.
7 Active Directory è il servizio di Microsoft per la gestione centralizzata delle utenze su reti aziendali
Pag. 99
7.2 Ambito: Rate scadute (Passato)
Il primo cubo si riferisce alle rate immesse a sistema con data di scadenza nel
passato. In figura 30 si riporta la lista dei campi disponibili per la sua analisi via
Pivot Table.
Figura 30 - Lista dei campi disponibili nel cubo “Scadute”
7.2.1 Valori numerici: “Stock”
Il cubo BI fornisce diversi valori numerici all’interno del gruppo “Stock” tra i
quali scegliere per creare un report.
L’unica eccezione all’uso di tale insieme di misure si presenta qualora si
desideri ottenere soltanto informazioni di anagrafica (es. visualizzare la
gerarchia delle WBS, dei contratti etc.).
In particolare, le misure a disposizione dell’Utente sono suddivisibili in 3
tipologie:
N Rate (Numero degli elementi del piano di fatturazione)
Pag. 100
Val Rate (Valore complessivo degli elementi del piano di fatturazione O
delle fatture)
Gg medi anz. (Giorni medi di differenza tra la scadenza della rata e
l’emissione della fattura ad essa relativa. I giorni medi di anzianità delle
rate “fatturate”, ossia associabili ad una fattura, è sinonimo del Lead Time
di fatturazione). Si noti, come accennato in precedenza, che la media non
è aritmetica ma pesata sul valore delle rate.
In questo modo, una rata scaduta di valore doppio rispetto ad un'altra
incide doppiamente sul calcolo dell’anzianità, fornendo un’informazione
più utile sulle performance del processo di fatturazione.
Queste tre tipologie di misure caratterizzano tutti i fenomeni oggetto di
osservazione. Gli elementi dei piani di fatturazione (di seguito, “rate”) sono
infatti catalogati, per ogni periodo, in questi sottoinsiemi:
1. Stock Iniziale
Numero, Valore e giorni medi di anzianità delle rate che, all’inizio del
periodo in esame, erano scadute ma prive di una fattura associata. Si noti
che i “Giorni medi Anzianità Stock Iniziale” sono intesi come differenza
tra la data di scadenza della rata e la data di ingresso nello stock, ossia la
prima data del periodo in esame.
2. Rate fatturate anni precedenti
Numero, Valore fatturato e giorni medi di anzianità delle rate a cui è
associata una fattura nel periodo in esame ma la cui data di scadenza si
trova in anni precedenti rispetto a quello in esame.
3. Rate fatturate periodi precedenti
Numero, Valore fatturato e giorni medi di anzianità delle rate a cui è
associata una fattura nel periodo in esame ma la cui data di scadenza si
trova in mesi precedenti rispetto a quello in esame (e nello stesso anno)
Si noti come, matematicamente, le misure di “rate fatturate” (2) e (3) vanno ad
incidere, per ogni mese, sulle rate presenti in “stock iniziale” (1), ossia su quelle
già scadute all’inizio del periodo.
Pag. 101
4. Rate scadute
Numero e Valore delle rate la cui data di scadenza si trova all’interno del
periodo in esame. Nel caso del mese corrente, sono considerate “scadute”
solo le rate scadute a oggi.
5. Rate fatturate periodo attuale
Numero, valore fatturato e giorni medi di anzianità delle rate scadute nel
periodo in esame a cui è associata una fattura nello stesso periodo.
6. Stock finale
Numero, Valore e giorni medi di anzianità delle rate che, alla fine del
periodo in esame, sono scadute ma prive di una fattura associata. Si noti
che i “Gg medi Anz. Stock Fin”, giorni medi di anzianità dello stock
finale di rate, sono intesi come differenza tra la data di scadenza della rata
e l’ultima data del periodo in esame.
La misura Stock finale discende dalle precedenti secondo la somma algebrica
(6) = (1) – (2) – (3) + (4) – (5)
Altre casistiche gestite dal sistema sono:
7. Rate scadute con fattura anticipata
Numero e Valore delle rate la cui data di scadenza si trova all’interno del
periodo in esame ma che hanno a sistema una fattura già associata con
data in un periodo successivo a quello in esame. Si deduce che questo
“tipo di rate” non sono mai considerate nei calcoli dello Stock iniziale o
finale.
8. Rate fatturate periodi successivi
Numero, Valore fatturato e giorni medi di anzianità (sempre negativi)
delle rate a cui è associata una fattura nel periodo in esame ma la cui data
di scadenza si trova in periodi successivamente. Chiaramente, le rate
contenute in questa tipologia sono la “contropartita” di quelle in (7).
9. Rate fatturate totali
Numero, Valore fatturato e giorni medi di anzianità di tutte le rate
fatturate nel periodo in esame, a prescindere dal loro periodo di scadenza.
Pag. 102
7.2.2 Valori numerici: “Conteggio Contratti”
Le misure Conteggio contratti nascono per poter valutare il numero di contratti
distinti coinvolti in uno o più dei fenomeni descritti nel paragrafo precedente
(sui metodi di calcolo vd. Cap. 6.4.5). Le misure contenute nell’insieme sono:
Numero contratti con rate in stock iniziale
Numero contratti con rate fatturate e scadute in anni precedenti
Numero contratti con rate fatturate e scadute in periodi precedenti dello
stesso anno
Numero contratti con rate fatturate e scadute nel periodo in corso
Numero contratti con rate fatturate (in totale)
Numero contratti con rate scadute nel periodo in corso
Numero contratti con rate in stock finale
7.2.3 Dimensione “Tempo P”
La dimensione “Tempo P” (passato o “Scaduto”) permette di delimitare il
periodo temporale oggetto di analisi. Sia per motivi di leggibilità che per motivi
di efficienza, agli Utenti è stato suggerito di imporre sempre un filtro su questa
dimensione.
I dati osservabili sono quelli a partire da un anno a ritroso rispetto al mese
odierno: questa logica rolling si aggiorna quotidianamente in automatico.
7.2.4 Altre Dimensioni
Alcune funzioni di Excel in combinazione con SSAS sono trasversali a tutte le
dimensioni di analisi: si segnala in particolare la presenza (facoltativa) di un
elemento chiamato Gerarchia (marcato “Ger” nell’applicazione) che, se
utilizzato nella Pivot Table, permette di navigare in maniera gerarchica la
dimensione corrente. In tal modo si abilita una navigazione asimmetrica tipica di
uno strumento di analisi OLAP, in cui ogni membro ad un certo livello può
essere espanso al livello di dettaglio successivo.
Pag. 103
Un esempio di dimensione che contiene una gerarchia, come richiesto dalle
specifiche funzionali, è la WBS: l’utilizzo delle gerarchie è consigliato nei casi
in cui si desideri esplorare in maniera interattiva uno specifico fenomeno,
partendo dal livello di dettaglio più alto di una o più dimensioni e scendendo
progressivamente a livello di dettaglio maggiore.
Nel caso in cui si costruisca un report tradizionale, invece, sono più convenienti,
gli attributi elementari contenuti all’interno nella cartella “More Fields”, che non
sono in rapporto gerarchico tra loro.
Di seguito saranno elencate le dimensioni presenti nel cubo, fornendo ove
necessario alcune considerazioni sull’uso.
Tipo Cliente
La dimensione è popolata basandosi sull’incrocio dei valori di Codice
Committente (attributo dei Contratti) e Convenzione (attributo delle
WBS).
Sul data warehouse questo nuovo attributo è gestito come una dimensione
a parte, politica proseguita sui cubi multidimensionali.
Fascia di Anzianità
E’ il risultato di un raggruppamento per fasce di Giorni medi anzianità.
Utilizzando questa dimensione è possibile individuare in modo più
aggregato, rispetto all’interrogazione dalla misura “Giorni medi”, la
composizione in termini di anzianità.
Stato Rata
Si tratta di una dimensione “di servizio”, utilizzata ai fini di quadratura
per valutare se le rate contate e collocate all’interno di determinati gruppi
di misure fossero effettivamente compatibili.
Contratto
Particolarmente rilevante la risalita gerarchica per Cliente.
WBS (Progetto)
Particolarmente rilevanti le risalite gerarchiche per Area, Mercato,
Responsabile.
Pag. 104
7.3 Ambito: Rate a scadere (Futuro)
Il secondo cubo si riferisce alle rate immesse a sistema con data di scadenza nel
futuro. In figura 31 si riporta la lista dei campi disponibili per la sua analisi via
Pivot Table.
Figura 31 - Lista dei campi disponibili nel cubo “A scadere”
7.3.1 Valori numerici: “A Scadere”
Chiaramente, quanto detto per i valori numerici al paragrafo XXX vale anche
per questi. Gli indicatori messi a disposizione per le rate con scadenza registrata
oltre la data odierna sono:
N rate a scadere (Numero degli elementi del piano di fatturazione)
Val Rate a scadere (Valore complessivo degli elementi del piano di
fatturazione O delle fatture)
N rate fatture anticipate (Numero di fatture emesse per rate che scadranno
successivamente)
Val rate fatture anticipate (Valore complessivo delle fatture emesse per
rate che scadranno successivamente)
Pag. 105
7.3.2 Dimensione “Tempo F”
Anche la dimensione “Tempo F” (futuro o “A scadere”) è strettamente analoga a
quanto visto per il “passato”. I dati osservabili, questa volta, sono quelli a partire
dal mese odierno fino a sei mesi a venire.
7.3.3 Altre Dimensioni
Le dimensioni sono del tutto identiche a quanto visto nel caso precedente, i due
cubi sono stati separati e diversificati per evitare la commistione di dati passati e
futuri in una sola tabella.
7.4 Descrizione della reportistica
Definite le possibilità consegnate agli Utenti per creare reportistica
personalizzata, si passa alla descrizione puntuale dei report realizzati come
definiti dalle specifiche.
7.4.1 Analisi Scaduto per Area e Servizio
Contiene l’analisi dello stock finale per periodo (passato), con un’attenzione
particolare alle dimensioni “Area” e “Servizio”.
Il foglio 1 contiene i KPI puntuali, i filtri applicabili attraverso gli Slicer Excel,
un grafico “Bridge” sull’andamento dello stock nel periodo.
In particolare, con “Brige” si intende un tipo di grafico a barre peculiare, che
enfatizza le variazioni della misura “a stock”, particolarmente indicata per il
nostro ambito.
La prima barra rappresenta, in rosso, lo stock iniziale. Le due successive le rate
per cui è stata emessa una fattura tra quelle in stock iniziale:
Pag. 106
Figura 32 - Esempio grafico "Bridge"
La terza barra, rossa, rappresenta le rate scadute nel periodo e contestualmente
fa salire il livello di stock. La successiva barra blu rappresenta le fatture emesse
per rate scadute nel periodo. Ciò che rimane in stock al termine del periodo è
rappresentato dall’ultima barra rossa.
Il foglio 1 del report si presenta complessivamente in questo modo:
Figura 33 - Analisi Scaduto Area e Servizio (Foglio 1)
Pag. 107
Il foglio 2 contiene una tabella a campi incrociati con le Aree in riga e i Servizi
in colonna (con formattazione condizionale che evidenzia i valori notevoli).
Figura 34 - Analisi Scaduto Area e Servizio (Foglio 2)
7.4.2 Analisi Rate scadute e stock
Contiene l’analisi delle variazioni di stock (nel passato) per tutti i parametri
principali di analisi.
Il foglio 1 contiene i KPI puntuali, i dati necessari a individuare l’andamento
dello stock e i filtri applicabili attraverso gli Slicer Excel (tener premuto e
trascinare il tasto sinistro del mouse per filtrare più di una valore), un grafico a
barre sugli stessi dati sintetizzati.
Pag. 108
Questo foglio contiene le informazioni declinate per “Tipo Contratto”.
Figura 35 - Analisi Rate Scadute e Stock (Foglio 1)
I fogli 2, 3 e 4 contengono le stesse informazioni di dettaglio declinate per
dimensioni di analisi diverse: rispettivamente Area, Mercato, Tipo Cliente.
Figura 36 - Analisi Rate Scadute e Stock (Foglio 2)
Pag. 109
Figura 37 - Analisi Rate Scadute e Stock (Foglio 3)
Figura 38 - Analisi Rate Scadute e Stock (Foglio 4)
7.4.3 Analisi Stock iniziale per anzianità
Contiene tutti i dati di Stock Iniziale (Numero rate, Valore, Numero contratti)
per il periodo in esame, suddivisi per classi di anzianità. In questo modo è
agevole individuare dove insistessero le principali criticità all’inizio del periodo.
Pag. 110
Il foglio 1 presenta queste informazioni declinate per “Tipo contratto” e i filtri
applicabili attraverso Slicer Excel.
Figura 39 - Analisi Stock iniziale per anzianità (Foglio 1)
I fogli 2,3 e 4 contengono le stesse informazioni di dettaglio declinate per
dimensioni di analisi diverse: rispettivamente Area, Mercato, Tipo Cliente.
Figura 40 - Analisi Stock iniziale per anzianità (Foglio 2)
Pag. 111
Figura 41 - Analisi Stock iniziale per anzianità (Foglio 3)
Figura 42 - Analisi Stock iniziale per anzianità (Foglio 4)
7.4.4 Analisi Rate scadute per area con dettaglio Contratto
Contiene tutti i dati di Stock Iniziale (Numero rate, Valore, Numero contratti)
per il periodo in esame, suddivisi per dimensione di analisi.
Il foglio 1 contiene i KPI puntuali, i dati di dettaglio dello stock finale e i filtri
applicabili attraverso gli Slicer Excel un grafico a barre sugli stessi dati
sintetizzati.
Pag. 112
Questo foglio contiene le informazioni declinate per “Area” e “Fascia di
Anzianità”.
Figura 43 - Analisi rate scadute per Area con dettaglio Contratto (Foglio 1)
Il foglio 2 contiene, in maniera inusuale per un report di BI (ma conformemente
alle esigenze del Cliente), i dati di dettaglio per singolo contratto, con tutti gli
attributi di maggior rilevanza di Contratto e WBS.
Figura 44 - Analisi rate scadute per Area con dettaglio Contratto (Foglio 2)
Pag. 113
7.4.5 Analisi Fatturato e LT di fatturazione
Contiene tutti i dati relativi alle rate con fattura associata, suddivisi per
dimensione di analisi.
Il foglio 1 contiene i KPI puntuali, i dati di dettaglio del fatturato e i filtri
applicabili attraverso gli Slicer Excel un grafico a barre sugli stessi dati
sintetizzati.
Questo foglio contiene le informazioni declinate per “Fascia di Anzianità” e
“Tipo Contratto”.
Figura 45 - Analisi Fatturato e LT di fatturazione (Foglio 1)
Il foglio 2 presenta queste informazioni declinate, oltre che per “Fascia di
anzianità” per ogni dimensione di interesse: “Tipo contratto”, “Area”,
“Mercato” e “Tipo Cliente”, consentendo di individuare in quali incroci
organizzativo-funzionali il processo di fatturazione sia stato più lento (o rapido).
Pag. 114
Figura 46 - Analisi Fatturato e LT di fatturazione (Foglio 2)
7.4.6 Analisi rate a scadere
Contiene tutti i dati relativi alle rate a scadere (nel futuro), suddivisi per
dimensione di analisi.
Il foglio 1 contiene i KPI puntuali, i dati di dettaglio del fatturato e i filtri
applicabili attraverso gli Slicer Excel un grafico a barre sugli stessi dati
sintetizzati. Questo foglio contiene le informazioni declinate per “Area” e “Tipo
Contratto”.
Figura 47 - Analisi rate a scadere (Foglio 1)
Pag. 115
Il foglio 2 presenta le stesse informazioni declinate per “Tipo Cliente” e
“Mercato” in una tabella a campi incrociati.
Figura 48 - Analisi rate a scadere per Tipo Cliente \ Mercato (Foglio 2)
Pag. 116
8 Conclusioni
Quanto progettato e realizzato è attualmente operativo: l’applicazione effettua
quotidianamente il caricamento automatico dei dati dal sistema transazionale,
elaborandoli come richiesto e rendendo disponibile agli utenti finali la
reportistica.
Abbiamo provveduto a formare gli utenti, già pratici di Microsoft Excel,
riguardo le nuove possibilità derivate dall’impiego del sistema
multidimensionale.
Con il coinvolgimento degli utenti finali nell’attività di testing, come sempre
accade in progetti di questo tipo, nuove necessità di quadratura e considerazioni
sul modello sono emerse, aprendo a nuovi sviluppi e ampliamenti futuri.
Parallelamente avanzano altri progetti su ambiti funzionali attigui a quello
dell’Amministrazione e su processi più o meno inter-connessi con quello di
Ciclo Attivo, la “filosofia” stessa della Business Intelligence volge l’attenzione
consulenziale ad una futura integrazione tra tutti gli ambiti con l’obiettivo di
fornire alla dirigenza e agli operatori sempre più strumenti di analisi e di
estrazione delle informazioni.
Grazie alla nuova reportistica è ora possibile evidenziare in pochi secondi colli
di bottiglia nel processo di fatturazione, così da consentirne lo snellimento e da
aumentarne la velocità di risposta a eventuali criticità emergenti: i risultati sono
maggiore efficienza operativa, migliori capacità di monitoraggio e, prima
richiesta dell’utenza, immediatezza nel recupero dei dati senza più passare da
operatori dei sistemi informativi.
Pag. 117
9 APPENDICE A: Indice delle figure
Figura 1 - Schema metodologia BE – LEAN........................................................ 7
Figura 2 - Kimball Lifecycle Methodology (Kimball Group) .............................. 9
Figura 3 - Quadrante di Gartner per la BI 2012 .................................................. 12
Figura 4 - Schema tabellare a Snowflake ............................................................ 21
Figura 5 - Schema tabellare a Star ...................................................................... 24
Figura 6 - Cinque architetture di un data warehouse [10] ................................... 26
Figura 7 - Schematizzazione del paradigma R-OLAP ........................................ 33
Figura 8 - Schematizzazione del paradigma M-OLAP ....................................... 33
Figura 9 - Schema architettura HW .................................................................... 34
Figura 10 - SQL Server Integration Services 2012 ............................................. 36
Figura 11 - SQL Server Analysis Services ......................................................... 40
Figura 12 - Screenshot del portale di reportistica ............................................... 44
Figura 13 - Ciclo Attivo per prodotti fisici o di servizi ...................................... 46
Figura 14 - Processo di Ciclo Attivo con rateizzazione (caso di studio) ............ 48
Figura 15 - Analisi globale del LT di fatturazione .............................................. 51
Figura 16 - Schema delle risalite gerarchiche WBS ........................................... 54
Figura 17 - Struttura tabelle dati in SAP ............................................................. 57
Figura 18 - Notazione frecce figura precedente .................................................. 58
Figura 19 - Control Flow generale per la Staging Area in Integration Services 64
Figura 20 - Data Flow di trattamento dei Contratti - Staging Area .................... 66
Figura 21 - Struttura dei JOIN per la creazione della tabella dei fatti in SA ...... 68
Figura 22 - Associazione tra "Fatti" e WBE ....................................................... 69
Figura 23 - Control Flow per la creazione della Fact Table (Stock) .................. 75
Figura 24 - Schema Data Flow (2) tabella temporanea Rate .............................. 77
Figura 25 - Possibili valori del flag Stato Rata ................................................... 78
Figura 26 - Star Schema applicativo ................................................................... 88
Figura 27 - Dimensioni e cubo in SSAS ............................................................. 89
Figura 28 - Esempio di tabella dei fatti (Vendite) .............................................. 90
Figura 29 - Connessione dati SSAS in Excel 2007 ............................................. 97
Figura 30 - Lista dei campi disponibili nel cubo “Scadute” ............................... 99
Figura 31 - Lista dei campi disponibili nel cubo “A scadere” .......................... 104
Pag. 118
Figura 32 - Esempio grafico "Bridge" ............................................................... 106
Figura 33 - Analisi Scaduto Area e Servizio (Foglio 1) ................................... 106
Figura 34 - Analisi Scaduto Area e Servizio (Foglio 2) ................................... 107
Figura 35 - Analisi Rate Scadute e Stock (Foglio 1) ........................................ 108
Figura 36 - Analisi Rate Scadute e Stock (Foglio 2) ........................................ 108
Figura 37 - Analisi Rate Scadute e Stock (Foglio 3) ........................................ 109
Figura 38 - Analisi Rate Scadute e Stock (Foglio 4) ........................................ 109
Figura 39 - Analisi Stock iniziale per anzianità (Foglio 1) ............................... 110
Figura 40 - Analisi Stock iniziale per anzianità (Foglio 2) ............................... 110
Figura 41 - Analisi Stock iniziale per anzianità (Foglio 3) ............................... 111
Figura 42 - Analisi Stock inizialer per anzianità (Foglio 4) ............................. 111
Figura 43 - Analisi rate scadute per Area con dettaglio Contratto (Foglio 1) .. 112
Figura 44 - Analisi rate scadute per Area con dettaglio Contratto (Foglio 2) .. 112
Figura 45 - Analisi Fatturato e LT di fatturazione (Foglio 1) ........................... 113
Figura 46 - Analisi Fatturato e LT di fatturazione (Foglio 2) ........................... 114
Figura 47 - Analisi rate a scadere (Foglio 1) ..................................................... 114
Figura 48 - Analisi rate a scadere per Tipo Cliente \ Mercato (Foglio 2) ......... 115
Pag. 119
10 APPENDICE B: Bibliografia
[1] Boehm, «A Spiral Model of Software Development and Enhancement,»
ACM SIGSOFT Software Engineering Notes, 1986.
[2] Kimball Group, «Kimball Core Concepts - Lifecycle Methodology,»
[Online]. Available: http://bit.ly/SmOdWv. [Consultato il giorno 5
Novembre 2012].
[3] Kimball, Mundy e Thornthwaite, The Microsoft Data Warehouse Toolkit,
Kimball Group, 2006.
[4] Fiocchi, I Sistemi a supporto delle decisioni - La Teoria e le Metodologie di
riferimento, 1998.
[5] Hagerty, Sallam e Richardson, «Magic Quadrant For Business Intelligence
Platforms,» Gartner, 2012.
[6] Bogza e Zaharie, «Business Intelligence as a Competitive Differentiator,»
IEEE, 2008.
[7] Chaudhuri e Narasayya, «New Frontiers in Business Intelligence,» in 37th
International Conference on Very Large Data Bases, Seattle, WA, 2011.
[8] Arghire, «Microsoft’s Office Has over One Billion Users,» 10 Luglio 2012.
[Online]. Available: http://bit.ly/RjPXlR.
[9] Atzeni, Ceri, Paraboschi e Torlone, «La normalizzazione,» in Basi di dati -
Modelli e linguaggi di interrogazione, McGraw-Hill, 2002.
[10] Aiyachandra e Watson, «Which Data Warehouse Architecture is most
successful?,» Business Intelligence Journal, vol 11, #1, 2006.
[11] Pirnau, «General informations about Business intelligence and OLAP
Systems architecture,» in Computer and Automation Engineering (ICCAE),
The 2nd International Conference on, Singapore, 2010.
[12] Henschen, «Microsoft SQL Server 2012 Vs. Oracle: Customers Voting,» 9
Aprile 2012. [Online]. Available: http://bit.ly/QQaFbu.
[13] Microsoft, «Integration Services Data Types,» [Online]. Available:
Pag. 120
http://msdn.microsoft.com/en-us/library/ms141036.aspx. [Consultato il
giorno 6 Novembre 2012].
[14] Booz, Allen e Hamilton, «US Department of Energy - Office of science,»
2011. [Online]. Available: http://science.energy.gov.
[15] IcCube, «IcCube support documentation,» [Online]. Available:
http://www.iccube.com/support/documentation/. [Consultato il giorno 7
Gennaio 2013].
[16] G. Spofford, MDX Solutions, John Wiley & Sons, 2001.
[17] Microsoft, «.NET Framework,» Microsoft, [Online]. Available:
http://www.microsoft.com/net. [Consultato il giorno 7 Gennaio 2013].