METODI E STRUMENTI DI BUSINESS INTELLIGENCE PER I PROCESSI DI CICLO ATTIVO: un caso di studio in un azienda di servizi

Transcript

1 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

2 Indice 1 Introduzione Sommario Company profile ICONSULTING Cenni sulla metodologia progettuale BE - LEAN Business Intelligence e Decision Support System Aspetti storici del settore e della proposta Microsoft Data warehousing e Business Intelligence Teoria Relazionale Teoria della Normalizzazione Star Schema & Snowflake Schema Struttura di un DSS, studio su diverse alternative Import Staging Area Data Mart Cubi Multidimensional OLAP Aspetti tecnici e strumenti utilizzati Specifiche HW Specifiche SW SQL Server SSIS SSAS Interfaccia Excel MS SharePoint Analisi funzionale del caso Processi di Ciclo Attivo Contingenze al caso specifico Rateizzazione e Fatturazione Pag. 1

3 5.2.2 Work Breakdown Structure Bacino d utenza Modello dei dati Analisi del database sottostante il sistema Transazionale IMPORT Criticità dei dati in ingresso Scelta del criterio incrementale\full-refresh Algoritmo di Upsert per la gestione dei dati incrementali STAGING AREA Relazione con i Work Breakdown Elements Data mart e Cubo Multidimensionale Studio sulla creazione della tabella dei fatti (Stock) Algoritmo di creazione della tabella dei fatti (Stock) Denormalizzazione dei dati Implementazione del cubo Analysis Services Calculated Members in MDX (con cenni sul query language multidimensionale) Fruizione dei dati Distribuzione delle informazioni attraverso Intranet aziendale e Microsoft Excel Ambito: Rate scadute (Passato) Valori numerici: Stock Valori numerici: Conteggio Contratti Dimensione Tempo P Altre Dimensioni Ambito: Rate a scadere (Futuro) Valori numerici: A Scadere Dimensione Tempo F Altre Dimensioni Descrizione della reportistica Pag. 2

4 7.4.1 Analisi Scaduto per Area e Servizio Analisi Rate scadute e stock Analisi Stock iniziale per anzianità Analisi Rate scadute per area con dettaglio Contratto Analisi Fatturato e LT di fatturazione Analisi rate a scadere Conclusioni APPENDICE A: Indice delle figure APPENDICE B: Bibliografia Ringraziamenti... Error! Bookmark not defined. Pag. 3

5 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. 4

6 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. 5

7 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 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. 6

8 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. 7

9 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. 8

10 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. 9

11 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. 10

12 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 semiautomatizzata 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. 11

13 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. 12

14 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. 13

15 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. 14

16 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. 15

17 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. 16

18 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. 17

19 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) 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. 18

20 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) Bologna Milano Regione di nascita Emilia-Romagna Lombardia Pag. 19

21 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 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. 20

22 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. 21

23 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. 22

24 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. 23

25 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. 24

26 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. 25

27 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. 26

28 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. 27

29 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. 28

30 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. 29

31 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 ). Pag. 30

32 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. 31

33 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. 32

34 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. 33

35 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. 34

36 Ospitare il web server, su piattaforma coerentemente.net 1, 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 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. 35

37 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] 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. 36

38 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. 37

39 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.X A, A.Y A, A.Z A,, B.W B FROM A LEFT OUTER JOIN B ON A.X A = B.X A 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(X A ) AS X A, Y A, Z A,, G(Y A ) AS Y2 A 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. 38

40 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 X A, Y A, SUM(NA) FROM A GROUP BY X A,Y A 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. 39

41 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. 40

42 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. 41

43 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 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. 42

44 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. 43

45 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 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. 44

46 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. 45

47 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. 46

48 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. 47

49 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. 48

50 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 ). 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. 49

51 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 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 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. 50

52 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. 51

53 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. 52

54 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. 53

55 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. 54

56 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 ). Pag. 55

57 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. 56

58 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. 57

59 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. 58

60 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 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. 59

61 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 ). 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. 60

62 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. 61

63 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 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. 62

64 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 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. 63

65 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 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. 64

66 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 ) 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. 65

67 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 Pag. 66

68 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 ) 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. 67

69 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. 68

70 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 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. 69

71 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 è 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. 70

72 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. 71

73 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. 72

74 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) 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 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. 73

75 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. 74

76 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 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) Pag. 75

77 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. 76

78 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. 77

79 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) Data di scadanza (DS) Null Futura Passata Data di fatturazione (DF) Null Futura Passata 4: Errore 4: Errore DF > DS: 1 Figura 25 - Possibili valori del flag Stato Rata 4: Errore 6 DF < DS: 2 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). Pag. 78

80 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 ) ] [RATE] := [TEMP]:= Tabella delle rate in Staging Area risultante dalle elaborazioni precedenti Una tabella temporanea creata come buffer tra quella delle rate e quella di stock per non appesantire le già ingenti elaborazioni successive. Pag. 79

81 -- 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. 80

82 -- 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. 81

83 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. 82

84 [(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. 83

85 [(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. 84

86 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. 85

87 [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. 86

88 Le righe contenenti gli elementi (Contratti e Progetti) non presenti nella tabella dei fatti 4 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 Denormalizzazione dei dati Per la teoria sulla normalizzazione dei dati Vd. Cap 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). 4 Per non presenti si intende per cui non ci sono righe, nella fact table, che li contengano. Pag. 87

89 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. 88

90 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. 89

91 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 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. 90

92 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. 91

93 { [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. 92

94 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 ). Il codice corrispondente, per i giorni medi di anzianità dello Stock Finale, è il seguente: Pag. 93

95 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 ). 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. 94

96 ), [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 dimensionale 6. 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. 95

97 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. 96

98 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 ), 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. 97

99 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 ). SharePoint gestisce la profilazione degli utenti basandosi su quanto presente in Active Directory 7. 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. 98

100 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 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. 99

101 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. 100

102 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. 101

103 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 ). 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 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 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. 102

104 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. 103

105 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 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. 104

106 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 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 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. 105

107 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. 106

108 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) 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. 107

109 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. 108

110 Figura 37 - Analisi Rate Scadute e Stock (Foglio 3) Figura 38 - Analisi Rate Scadute e Stock (Foglio 4) 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. 109

111 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. 110

112 Figura 41 - Analisi Stock iniziale per anzianità (Foglio 3) Figura 42 - Analisi Stock iniziale per anzianità (Foglio 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. 111

113 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. 112

114 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. 113

115 Figura 46 - Analisi Fatturato e LT di fatturazione (Foglio 2) 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. 114