L’obiettivo di questi report è verificare se le tempistiche, concordate per ogni contratto, sono state rispettate. Quindi sarà utile osservare, per tutti i contratti di manutenzione preventiva e correttiva, il numero di interventi per ogni tipologia di verifica e il numero di volte in cui non si sono rispettate le tempistiche riportate sui contratti.
Requisito 1
“Per tutti i cespiti e i relativi contratti di una determinata azienda, mostrare , per l’anno
2018, il numero di interventi totali di manutenzione correttiva e il numero di volte in cui
le tempistiche contrattuali non sono state rispettate (tempo FM, tempo risoluzione e tempo
risposta)”.
Per svolgere questa richiesta è stato selezionato sulle righe i numeri di inventario dei cespiti e gli idrec dei contratti mentre sulle colonne è stato inserito l’anno 2018 ed una determinata azienda. Le misure selezionate sono state “MC numero interventi totali”, “MC interventi non rispettanti tempo fermo macchina”, “MC interventi non rispettanti tempo risoluzione” e “MC interventi non rispettanti tempo risposta”. Il risultato finale è mostrato in Figura 8.8.
Figura 8.8: Report 1 contratti Requisito 2
“Per tutti i contratti relativi ad un centro di costo, mostrare il numero totale di manuten-
zioni preventive e il numero di volte in cui il tempo di intervento non è stato rispettato”. Per eseguire questa richiesta è stato selezionato sulle righe gli idrec dei contratti mentre sulle colonne è stato inserito uno specifico centro di costo. Le misure selezionate sono state “MP numero interventi totali” e “MP interventi non rispettanti tempo intervento”. Il risultato finale è mostrato in Figura 8.9.
Capitolo 9
CONCLUSIONI
Questo lavoro di tesi, svolto presso l’azienda Consorzio Metis, ha avuto come obiettivo principale la progettazione e la realizzazione di un sistema di Business Intelligence per l’analisi di quattro processi aziendali, con particolare attenzione al processo di data ware- housing.
Lo scopo fondamentale era quello di progettare e costruire un sistema di Business Intelli- gence, utilizzando solo prodotti open source, finalizzato a supportare la gestione dei beni materiali delle aziende sanitarie della Toscana e della Regione.
L’implementazione ha seguito le fasi di progettazione di un data warehouse: l’analisi dei requisiti, la progettazione concettuale e logica, le fasi di estrazione, trasformazione e ca- ricamento dei dati e la creazione della reportistica. Particolare attenzione è stata posta per le attività di raccolta e di specifica dei requisiti, che ha consentito una realizzazione lineare che non ha richiesto modifiche sostanziali al modello formulato in prima istanza, e per l’attività di estrazione e trasformazione dei dati, con lo scopo di renderli aderenti alla logica di business del sistema di analisi.
all’utilizzo della suite Pentaho che ha permesso la realizzazione di una soluzione flessibile e di facile utilizzo per l’utente finale. La realizzazione di dashboard, inoltre, arricchisce il sistema fornendo un insieme preconfigurato di report grafici navigabili e interattivi. Le soluzioni possono essere migliorate sia attraverso uno studio più approfondito lato back- end che con l’arricchimento delle informazioni rappresentate e la creazione di nuovi report per mostrare fenomeni non ancora evidenziati.
Per gli sviluppi futuri si prevedono le realizzazioni di nuovi data mart sulle manutenzioni per analizzarne i costi, il tasso di guasto e di fuori uso delle apparecchiature.
Nel complesso questa esperienza lavorativa è stata particolarmente interessante e costrut- tiva, sia perché ha permesso di confrontarsi con la complessità di una realtà aziendale, sia perché ha consentito di acquisire dimestichezza con la suite Pentaho, una tecnologia non affrontata in ambito universitario, e di confrontarsi con le problematiche relative alla progettazione e sviluppo del processo di data warehousing su un caso di studio reale.
Appendice A
Caso di Studio: Contratti
Quest’appendice è rivolta a presentare come si applica la metodologia di progettazione e realizzazione di un data mart e di un data warehouse di un reale caso aziendale, nello specifico solo per il Processo Contratti.
Analisi dei requisiti
La prima fase per la costruzione di un data mart o del data warehouse è l’analisi dei requisiti. Essa si divide in due sotto fasi: raccolta dei requisiti e specifica dei requisiti.
Raccolta dei requisiti
Il Consorzio Metis sviluppa software per le Aziende USL socie tra cui il sistema della gestione dei beni materiali per le aziende nel settore sanitario e per la Regione Toscana. Lo scopo è quello di utilizzare un data warehouse per il monitoraggio dei contratti. I contratti sono legati alle manutenzioni preventive e correttive dei cespiti. L’obiettivo è verificare per ogni anno se le tempistiche, concordate per ogni contratto, sono state rispettate. In particolare per le manutenzioni preventive è utile osservare, per ogni cespite,
quanti interventi di questa tipologia sono stati effettuati e quanti di questi non hanno rispettato il tempo di intervento, mentre per le manutenzioni correttive occorre osservare, per ogni cespite, quanti interventi di questa tipologia sono stati effettuati, quanti di questi interventi non hanno rispettato il tempo di risposta (tempo che intercorre tra la richiesta di intervento e l’arrivo del tecnico in sede), il tempo di risoluzione (tempo che intercorre tra la richiesta di intervento e la risoluzione del problema) e il tempo di fermo della macchina. Inoltre interessa sapere per ogni contratto l’identificativo e la denominazione dell’azienda, l’identificativo e la denominazione del centro di costo ed il cespite con il suo numero, la sua classe, il suo modello e la ditta costruttrice. Di ogni contratto è utile sapere la sigla che lo identifica, chiamata Idrec.
I requisiti di analisi richiesti sono stati i seguenti:
Requisiti di analisi del processo Contratto 1 Per tutti i cespiti e i relativi contratti di una determinata azienda, mostrare, per l’anno 2018, il numero di interventi totali di manutenzione correttiva e il numero di volte in cui le tempistiche contrattuali non sono state rispettate (tempo FM, tempo risoluzione e tempo risposta)
2 Per tutti i contratti relativi ad un centro di costo, mostrare il numero totale di manutenzioni preventive e il numero di volte in cui il tempo di intervento non è stato rispettato
Successivamente si è verificato che i dati operazionali a disposizione fossero compatibili con i requisiti di analisi raccolti.
Specifica dei requisiti
Per ogni requisito del processo si produce una specifica delle analisi dei dati che consenta di identificare le dimensioni (con gli attributi tra parentesi), le misure interessanti e si definisce la granularità dei fatti. Di seguito è riportata la specifica dei requisiti del processo Contratto.
Requisiti Contratto N Requisito di analisi Dimensioni Misure Metriche
1 Per tutti i cespiti e i rela- tivi contratti di una deter- minata azienda, mostra- re, per l’anno 2018, il nu- mero di interventi tota- li di manutenzione corret- tiva e il numero di vol- te in cui le tempistiche contrattuali non sono sta- te rispettate (tempo FM, tempo risoluzione e tempo risposta) Cespite, azienda, contratto, anno NInterventiMC, NIn- terventiMC_FM, NInterventiMC_risol, NInterventiMC_risp Totale NInterven- tiMC,Totale NInter- ventiMC_FM,Totale NInterven- tiMC_risol,Totale NInterventiMC_risp
2 Per tutti i contratti rela- tivi ad un centro di costo, mostrare il numero totale di manutenzioni preventi- ve e il numero di volte in cui il tempo di intervento non è stato rispettato
Contratto, cdc, anno NInterventiMP, NIn- terventiMP_int Totale NInter- ventiMP, Totale NInterventiMP_int
Dalla specifica dei requisiti emerge la seguente granularità dei fatti:
Fatto Contratto Descrizione Dimensioni preliminari Misure preliminari Un fatto è l’informazione, per
cespite, contratto e anno, sul numero di manutenzioni pre- ventive e correttive effettua- te e sul numero di volte che le tempistiche, previste da contratto, non sono state rispettate
Cespite, azienda, contratto, anno, cdc NInterventiMC, NIn- terventiMC_FM, NInterventiMC_risol, NInterventiMC_risp, NInterventiMP, NInterventiMP_int
Progettazione concettuale iniziale
Il Dimensional Fact Model (DFM) è utilizzato per rappresentare a livello concettuale, me- diante un formalismo grafico, la struttura di un data mart o di un data warehouse. I fatti si modellano con un rettangolo diviso in due parti contenenti il nome del fatto e l’elenco delle misure interessanti che descrivono aspetti quantitativi rilevanti per l’analisi. Le mi- sure possono mancare quando interessa rappresentare solo il verificarsi dei fatti, oppure essere calcolate, cioè si possono derivare da altre misure. Le dimensioni si modellano con degli archi uscenti dal rettangolo che terminano con un cerchio, etichettato con il nome della dimensione. In generale una dimensione è caratterizzata da un insieme di attributi dimensionali. Una dimensione priva di attributi è detta degenerata.
In presenza di attributi dimensionali, ai fini delle operazioni di analisi dei dati, un aspetto interessante da considerare sono particolari relazioni gerarchiche fra gli insiemi dei loro
valori, dette gerarchie dimensionali. Per esempio, i valori dell’attributo “Numero Cespi- te” sono in gerarchia con la “Classe” (Numero Cespite → Classe) nel senso che ad una “Classe” appartengono più “Numero Cespite” e ad un “Numero Cespite” corrisponde una sola “Classe”. Nella terminologia del modello dei dati relazionale ogni arco della gerarchia modella una dipendenza funzionale fra due attributi.
Di seguito si riporta lo schema concettuale iniziale del data mart Contratto.
Figura A.1: Schema concettuale iniziale
Progettazione concettuale finale
Per implementare questa fase è stato utile analizzare ulteriori aspetti del sistema sorgente per capire se fosse possibile estrapolare ulteriori informazioni dalle tabelle presenti. Allo scopo di permettere analisi a diversi livelli di dettaglio per il processo Contratto sono state aggiunte le dimensioni Presidio e Reparto.
Di seguito viene rappresentato lo schema concettuale finale del data mart Contratto.
Figura A.2: Schema concettuale finale
Progettazione logica del data mart
Si decide di generare uno schema a stella per il data mart, definendo per la tabella dei fatti dello schema concettuale la tabella dei fatti dello schema a stella. Per ogni dimensione si definisce la relativa tabella in relazione con la tabella dei fatti, indicando in modo oppor- tuno le chiavi primarie surrogate e le chiavi esterne. Le dimensioni che non presentano attributi sono inserite direttamente nella tabella dei fatti e sono chiamate degenerate. Di seguito viene raffigurato lo schema logico del data mart Contratto.
Figura A.3: Modellazione logica Contratto
Modello multidimensionale a cubo
Il modello multidimensionale a cubo è utile per illustrare sia le tipiche operazioni OLAP interattive di analisi dei dati che i concetti di cubo esteso e di cuboidi. Le analisi dei dati vengono solitamente effettuate in modo interattivo con strumenti che offrono interfacce grafiche per formulare le richieste.
Lo strumento di Business Intelligence utilizzato in questo caso è Pentaho che, attraverso l’applicazione Saiku, permette la navigazione nei cubi e tramite la quale sono stati realizzati i report e, grazie all’applicazione CDE, sono state realizzate delle dashboard. Di seguito vengono riportati alcuni esempi.
Figura A.4: Report 1 contratti
Bibliografia
[AV98] C. Adamson e M. Venerable. Data Warehouse Design Solutions. John Wiley & Sons, 1998.
[CK04] J. Caserta e R. Kimball. The Data Warehouse ETL Toolkit: Practical Tech- niques for Extracting, Cleaning, Conforming, and Delivering Data. Wiley Pu- blishing, Inc, 2004.
[AR17] A. Albano e S. Ruggieri. Decision Support Databases Essentials. University of Pisa, set. 2017.
Sitografia
[PEDOC] Documentazione Sito Ufficiale di Pentaho. url: https://help.pentaho. com/Documentation/7.1/0D0/Pentaho_Business_Analytics.
[PSD18] Python Software Foundation e JetBrains. Python Developers Survey 2018 Re- sults. url: https://www.jetbrains.com/research/python-developers- survey-2018/.
[OAST] Organizzazione Aziende Sanitarie Toscana. url: http : / / www . regione . toscana.it/sst/organizzazione/aziende-sanitarie.
[SCM] Sito Consorzio Metis. url: https://www.consorziometis.it/.
[SUPE] Sito Ufficiale di Pentaho. url: https : / / www . hitachivantara . com / go / pentaho.html.
[SUPC] Sito Ufficiale di PyCharm. url: https://www.jetbrains.com/pycharm/. [SUPY] Sito Ufficiale di Python. url: https://www.python.org/.