1
RIASSUNTO
Il processo di controllo e gestione della spesa in momenti di difficolt`a economica `e una tra le prime attivit`a che il Manager mette in atto al fine di mantenere dell’equi-librio economico-finanziario dell’azienda. In questo ambito i sistemi di business intelligencericoprono un ruolo fondamentale. Essi permettono di estrarre, aggre-gare e presentare i dati aziendali in modo tale da ricavare informazioni utili per il processo decisionale. In questo lavoro di tesi viene mostrato come, a partire dai requisiti di analisi del cliente, viene progettato e realizzato un sistema di business intelligenceper l’analisi della spesa per un’azienda operante dell’industria alimen-tare. Partendo dal processo di acquisto del cliente e dalla specifica dei requisiti di analisi, viene mostrata la progettazione della base di dati per l’analisi del processo. Viene descritta la progettazione dei processi di caricamento dei dati operazionali verso la base dati e viene mostrato il sistema di reportistica utilizzato dai Manager per l’accesso e la presentazione dei dati.
Indice
1 INTRODUZIONE 5
1.1 Presentazione del problema . . . 5
1.2 Rassegna della letteratura . . . 8
1.3 Contenuto della tesi . . . 8
2 PRESENTAZIONE DEL CASO 11 2.1 Descrizione del processo di acquisto . . . 11
2.1.1 Natura e confini dell’impresa . . . 12
2.1.2 Glossario di progetto . . . 12
2.1.3 Descrizione del processo . . . 14
2.2 Raccolta dei requisiti . . . 16
2.3 Riassunto . . . 26
3 SPECIFICA DEI REQUISITI 27 3.1 Processo Ordine di Acquisto . . . 27
3.1.1 Specifica dei requisiti di analisi . . . 27
3.1.2 Progettazione Concettuale . . . 33
3.1.3 Progettazione Logica . . . 34
3.2 Processo Ricevimento Articoli . . . 35
3.2.1 Specifica dei requisiti di analisi . . . 36
3.2.2 Progettazione Concettuale . . . 37
3.2.3 Progettazione Logica . . . 39
3.3 Processo Fatturazione . . . 39
3.3.1 Specifica dei requisiti di analisi . . . 40
3.3.2 Progettazione Concettuale . . . 42
3.3.3 Progettazione Logica . . . 43
3.4 Processo Richiesta Nuovi Fornitori . . . 43
3.4.1 Specifica dei requisiti di analisi . . . 44
3.4.2 Progettazione Concettuale . . . 44
3.4.3 Progettazione Logica . . . 45
3.5 Riepilogo delle misure e delle dimensioni . . . 46
3.6 Riassunto . . . 46 3
4 INDICE
4 I PROCESSI DI CARICAMENTO DATI 47
4.1 Estrazione . . . 48
4.2 Trasformazioni . . . 48
4.3 Caricamento . . . 49
4.4 Organizzazione della Staging Area . . . 50
4.5 Il software utilizzato: IBM InfoSphere DataStage . . . 52
4.5.1 L’aggiornamento della dimensione Originatore . . . 53
4.6 Riassunto . . . 57
5 LA REPORTISTICA 59 5.1 Il software utilizzato: Microstrategy . . . 59
5.2 Selezione degli oggetti del Data Warehouse . . . 61
5.3 Creazione delle metriche . . . 65
5.4 Report semplici . . . 66
5.5 Report relativamente difficili senza SQL analitico . . . 69
5.6 Riassunto . . . 77 A FUNZIONI SUI DATI SUPPORTATE IN MICROSTRATEGY 9.2 79
BIBLIOGRAFIA 83
Capitolo 1
INTRODUZIONE
1.1
Presentazione del problema
Sotto molti aspetti, negli ultimi trent’anni `e cambiato il mondo in cui viviamo ed il modo con cui si fa impresa. Lo sviluppo dell’ICT (Information and Comunication Technology) con l’avvento di Internet, lo sviluppo delle telecomunicazioni a livello globale, l’evoluzione dei computer e del software hanno cambiato il modo con il quale le imprese fanno business.
La concezione tradizionale dell’organizzazione `e stata quella secondo la quale l’impresa manteneva il controllo di tutte le fasi progettuali, produttive, commer-ciali e gestionali. Questo approccio privilegiava la logica “del fare” rispetto quella “dell’acquistare”, facendo della capacit`a di creare economie di scala e del manteni-mento stretto delle conoscenze i fattori distintivi dell’impresa; per quanto riguarda i servizi, anch’essi erano generalmente prodotti internamente.
Questo tipo di organizzazioni si sono sviluppate in condizioni di mercato com-pletamente diverse da quelle attuali, nelle quali la maggior parte dei mercati non erano ancora maturi: la differenziazione di prodotto bastava per raggiungere la red-ditivit`a attesa acquisendo nuove quote di mercato. I costi di approvvigionamento e produzione erano meno critici di quanto non lo siano oggi. L’evoluzione delle tecnologie, con l’aumento della complessit`a dei prodotti e dei processi produtti-vi, ha reso sempre pi`u necessario rivolgersi all’esterno per acquistare prodotti o competenze per i quali non sarebbe economico attrezzarsi internamente.
Oggi le imprese non acquistano solo fattori di produzione elementari ma ester-nalizzano interi processi e dipendono dal fornitore per quanto riguarda il risulta-to finale. Le strategie di business delle grandi aziende sono incentrate non tanrisulta-to sulla produzione di beni quanto sull’acquisizione e conservazione del know-how di prodotto e mercato, instaurando partnership di lungo termine con fornitori e clienti.
Dal punto di vista gestionale, il risultato di queste scelte porta ad una modi-fica sostanziale del conto economico. I costi interni diminuiscono ed insieme ad essi diminuisce in modo significativo il valore aggiunto della produzione, mentre
6 CAPITOLO 1. INTRODUZIONE aumenta la spesa esterna. Questa in molti casi si avvicina all’ottanta per cento dei costi totali, e diviene il principale fattore che determina il risultato economico dell’azienda. Acquistare dall’esterno servizi o beni che altrimenti sarebbero stati prodotti internamente ribalta la proporzione tra acquisti e costi interni che esiste-va in passato, ed ogni esiste-variazione del volume di spesa si riflette direttamente sul risultato economico dell’impresa.
La riduzione della spesa `e il primo strumento che il management cerca di uti-lizzare per raggiungere gli obiettivi di redditivit`a dell’impresa in condizioni eco-nomiche non favorevoli e su mercati maturi. Infatti, agendo sul valore della produ-zione (quindi sulle vendite), sarebbe necessario un impegno molto maggiore, con un’ampia incertezza sul risultato. Diventa quindi pi`u efficace agire sulla leva dei costi piuttosto che sui ricavi.
La gestione della spesa (termine utilizzato comunemente anche nella sua tradu-zione inglese Spend Management) `e il processo sistematico di controllo, ottimiz-zazione e bilanciamento tra le voci di spesa, la domanda interna e l’offerta esterna in relazione agli obiettivi dell’impresa. La domanda interna `e rappresentata dalla domanda di fattori produttivi che i clienti interni all’impresa richiedono siano ac-quistati all’esterno; l’offerta esterna `e rappresentata dalle quantit`a e dai prezzi che si formano sul mercato di scambio dei fattori produttivi.
Governare la domanda significa assicurarne la coerenza con gli obiettivi azien-dali, evitando sprechi (eccessi di quantit`a, qualit`a e prezzo), che incidono negati-vamente sul risultato economico, o risparmi eccessivi, che possono penalizzare il business privandolo delle risorse necessarie. E’ quindi necessario ottimizzare la soddisfazione della domanda sfruttando al meglio le caratteristiche del mercato.
Governare il mercato dell’offerta significa essere in grado di mettere in atto la migliore strategia commerciale, sia nella ricerca e gestione delle fonti di approv-vigionamento, che nelle modalit`a di acquisto, per ridurre, oltre al prezzo, anche i costi indiretti indotti, come ad esempio i servizi accessori, gli oneri finanziari.
Uno degli obiettivi principali della gestione della spesa quindi `e la riduzione strutturale dei costi in ottica strategica, questa riduzione dovrebbe essere perseguita non soltanto migliorando il processo di acquisto, ma come conseguenza di una gestione oculata della domanda interna e dell’impiego ottimale dell’offerta esterna. Una corretta gestione della spesa non pu`o attuarsi senza prima aver predisposto un sistema informativo di rilevazione e controllo: l’analisi della spesa (in inglese Spending Analysis) `e il processo di aggregazione, classificazione e analisi dei dati relativi alla spesa e permette di dare visibilit`a alle opportunit`a di riduzione dei costi e di bilanciamento tra domanda interna e offerta esterna. In massima sintesi, nel breve periodo, permette di individuare chi sta acquistando (o chi semplicemente ne sta facendo richiesta), che cosa, da parte di chi e a quale prezzo. Nel lungo periodo permette di effettuare analisi con un maggior grado di aggregazione individuando alcuni indicatori chiave, quali:
• La spesa associata ad ogni centro di costo.
1.1. PRESENTAZIONE DEL PROBLEMA 7 • Gli articoli maggiormente acquistati.
• Il trend di spesa per gli articoli maggiormente acquistati negli ultimi me-si/anni.
• Articoli sui quali si possono avere margini di riduzione dei costi.
• I fornitori pi`u importanti per l’azienda dal punto di vista sia economico che strategico.
• Prestazione dei fornitori (in termini di tempi di consegna, qualit`a della mer-ce, ecc).
• La spesa per quei fornitori ritenuti importanti e per quei fornitori invece secondari oppure scarsi dal punto di vista delle prestazioni.
• La percentuale di spesa gestita mediante contratti commerciali.
In assenza di un progetto di analisi della spesa l’azienda non conoscerebbe la natura della sua spesa e la propria struttura dei costi, non avrebbe margini di manovra sulla razionalizzazione della spesa e non conoscerebbe le leve sulle quali agire per ottenere i risultati desiderati. Per fare ci`o `e necessario individuare ed organizzare i dati del sistema informativo in modo tale che possano essere presentati e facilmente analizzati dal management aziendale.
Da un punto di vista tecnologico un sistema di analisi della spesa si pu`o pre-disporre in diversi modi: acquistando strumenti software progettati ad-hoc oppure utilizzando fogli elettronici per l’elaborazione e presentazione dei dati. Ad oggi le tecnologie maggiormente utilizzate per la loro completezza e flessibilit`a di anali-si sono i anali-sistemi di buanali-siness intelligence. In accordo con [Albano 12] la buanali-siness intelligence `e: “[. . . ] un insieme di metodologie e sistemi informatici interattivi per l’analisi dei dati al fine di produrre informazione utile ai processi decisionali”. Tipicamente questi progetti sono altamente personalizzati sulle esigenze del clien-te. Una volta selezionati ed estratti i dati di interesse dai vari sistemi (contabile, gestionale, ecc) vengono opportunamente consolidati in una base di dati apposita-mente progettata chiamata Data Warehouse; la quale viene poi acceduta dai sistemi di reportistica. Questo insieme di strumenti, come varr`a meglio spiegato di seguito, mettono in condizioni il management di effettuare sessioni di analisi estremamente flessibili, in tempo reale e su grandi volumi di dati.
Il caso di studio in oggetto nasce dell’esigenza dell’azienda di monitorare ed analizzare la spesa relativa agli acquisti attraverso un sistema di business intel-ligence. Il sistema mediante indicatori chiave e report di dettaglio, permette al management e alla funzione acquisti di controllare giornalmente i dati relativi alla spesa.
8 CAPITOLO 1. INTRODUZIONE
1.2
Rassegna della letteratura
Lo sviluppo di progetti di business intelligence richiede diverse competenze tecni-che sugli strumenti software necessari per la loro progettazione e realizzazione. I principali componenti di questi sistemi sono essenzialmente tre:
• Il data warehouse, ovvero la base di dati che consente di eseguire le analisi sui dati di interesse.
• Il sistema di caricamento dei dati operazionali nel data warehouse.
• I sistemi di reportistica, che permettono di presentare le informazioni agli utenti finali.
Per quanto riguarda la progettazione del data warehouse i testi di riferimento sono stati [Kimball 02] e [Albano 12].
Per quanto riguarda la parte relativa al caricamento dei dati all’interno del data warehouse `e stato necessario sviluppare due tipologie di competenze: una proget-tuale ed una tecnica. I processi di caricamento dei dati operazionali all’interno del data warehouse sono la parte pi`u delicata del sistema. In questa fase i dati vengono estratti dai sistemi operazionali, trasformati e caricati all’interno del data warehouse. Questa fase `e particolarmente onerosa perch`e occorre riorganizzare ed elaborare grandi quantit`a di dati in un tempo relativamente ristretto.
Dal punto di vista progettuale occorre quindi organizzare correttamente tutti i flussi di dati. Kimball in [Kimball 04] suggerisce di dividere il processo di carica-mento in tre fasi: nella prima i dati vengono estratti dal sistema sorgente all’interno della staging area in file di testo per velocizzarne l’astrazione; nella seconda fase i dati contenuti nei file di testo vengono trasformati e inseriti in tabelle relazionali; nella terza ed ultima fase vengono eseguite le operazioni di aggiornamento delle tabelle dimensionali e delle tabelle dei fatti tra i nuovi dati e i dati storici.
Dal punto di vista tecnico `e stato necessario sviluppare competenze sullo stru-mento software utilizzato per realizzare i processi di caricastru-mento. Lo strustru-mento utilizzato `e stato IBM InfoSphere DataStage, le competenze sono state sviluppa-te mediansviluppa-te affiancamenti insviluppa-terni e consultando il manuale pratico del prodotto [Alur 08].
Per quanto riguarda il sistema di reportistica, anche qui si `e reso necessario lo sviluppo di competenze sullo strumento software. In particolare lo strumen-to utilizzastrumen-to `e stastrumen-to Microstrategy, le competenze sono state sviluppate anche in questo caso mediante affiancamenti interni e consultando i manuali [Mstr33 11], [Mstr57 11] e [Mstr47 11].
1.3
Contenuto della tesi
Il lavoro di tesi qui esposto `e frutto di un’esperienza di stage durata sei mesi presso Deloitte XBS Italia. Deloitte XBS `e una societ`a di consulenza che offre servizi di:
1.3. CONTENUTO DELLA TESI 9 implementazione sistemi ERP (soluzioni SAP e Oracle), Application Management e Technology Integration.
Nel Capitolo 2 viene presentato il caso di studio, descrivendo il processo di acquisto dell’azienda cliente, le principali figure coinvolte ed elencando i requisiti di analisi espressi dal cliente.
Nel Capitolo 3 i requisiti di analisi vengono tradotti nei costrutti della proget-tazione di data warehouse, vengono presentate le soluzioni adottate, mostrando gli schemi concettuali e logici.
Nel Capitolo 4 viene mostrata l’organizzazione dei processi di caricamento dei dati e come questi sono stati realizzati con l’ausilio del prodotto IBM InfoSphere DataStage.
In fine nel Capitolo 5 viene mostrata la parte di reporting del progetto. Non vengono presentati i report creati per il cliente bens`ı viene mostrato il modo con cui lo strumento Microstrategy genera il codice SQL per l’interrogazione del data warehouse.
Capitolo 2
PRESENTAZIONE DEL CASO
Solitamente siamo portati a pensare l’impresa esclusivamente dal punto di vista della produzione e vendita di beni, mentre si tende a non dare la giusta importanza ai processi che organizzano gli scambi commerciali a monte della catena, come l’acquisizione dei fattori produttivi e l’organizzazione dei loro trasferimenti, sen-za i quali non esisterebbe ne’ la produzione ne’ la vendita. Uno degli aspetti pi`u sorprendenti - come anche accennato nell’introduzione - della gestione delle im-prese `e il peso che hanno gli scambi commerciali che avvengono a monte del ciclo produttivo.
Con il termine approvvigionamenti si intende quel complesso di attivit`a svolte per assicurare la regolare disponibilit`a nei tempi, nelle quantit`a, nelle qualit`a e nei luoghi dei beni e dei servizi necessari per lo svolgimento delle funzioni dell’im-presa. Con il termine acquisti si intende invece quella parte delle attivit`a di ap-provvigionamento che consiste nel perfezionamento dei contratti di scambio con i fornitori.
Il progetto nasce dell’esigenza dell’azienda di monitorare ed analizzare il pro-cesso di acquisto attraverso un sistema di business intelligence che, attraverso indi-catori chiave e report di dettaglio, permetta al management e alla funzione acquisti di controllare giornalmente i dati relativi alla spesa.
In questo capitolo sar`a presentato il caso di studio introducendo il contesto di business e descrivendo il processo di acquisto dell’azienda. Verranno elencate le tipologie di analisi richieste, insieme ad esempi di report sia in formato grafico che tabellare. Sar`a riportato anche un breve glossario con i termini pi`u comuni in ambito acquisti.
2.1
Descrizione del processo di acquisto
Il processo di acquisto `e uno dei processi fondamentali che accomuna tutte le attivit`a produttive e consiste nel reperimento delle materie prime, beni o servizi necessari al funzionamento dell’impresa.
12 CAPITOLO 2. PRESENTAZIONE DEL CASO In questo paragrafo, dopo aver presentato l’azienda e dato alcune definizioni utilizzate in ambito acquisti, viene descritto il processo di acquisto, senza entrare in dettagli, ma comunque in modo completo: l’obiettivo `e quello di introdurre tutte le attivit`a, i ruoli ed i concetti necessari per comprendere le analisi dei paragrafi seguenti.
2.1.1 Natura e confini dell’impresa
L’azienda opera nel settore agroalimentare, produce e commercializza carni da ta-volo, principalmente: pollo, tacchino e suino. L’azienda possiede diversi stabili-menti industriali, filiali e agenzie in Italia, ed opera sul mercato italiano con:
• 6 incubatoi. • 4 mangimifici.
• 6 stabilimenti di trasformazione e lavorazione. • 23 tra filiali e agenzie.
• 3 piattaforme primarie, che smistano fino a 250.000 casse di merce al giorno. • Circa 350 agenti e 700 automezzi per il trasporto secondario che servono,
quasi giornalmente, circa 17.000 clienti con 500 prodotti.
Inoltre possiede allevamenti di propriet`a a gestione diretta (oltre 1.100.000 mq) che producono il 40% del fabbisogno totale di animali vivi e 3.700 ettari di terreno su cui insistono gli allevamenti.
2.1.2 Glossario di progetto
La stesura del glossario di progetto `e una fase importante perch´e permette a persone con conoscenze diverse e provenienti da ambiti differenti di ragionare e confrontar-si su concetti condiviconfrontar-si. Di seguito sono riportate le definizioni dei termini utilizzati dalla funzione acquisti.
Ordine di acquisto (OdA): `e il documento inviato al fornitore con il quale ordina uno o pi`u prodotti, specificandone la quantit`a ed eventualmente le caratteri-stiche. Un ordine di acquisto pu`o contenere pi`u righe d’ordine, ogni riga raggruppa prodotti identici e ne specifica la quantit`a ordinata. Da un punto di vista formale un ordine `e un insieme di coppie hprodotto, quantit`ai. Nella testata del documento sono presenti diverse informazioni come: la ragione sociale del fornitore e della societ`a, la partita iva, il numero dell’ordine, il tipo di documento.
Originatore: non tutti i dipendenti possono fare richiesta di un ordine, l’origi-natore `e quel dipendente che essendo abilitato alla richiesta di fornitura, da inizio al processo di acquisto.
Approvatore: prima che la richiesta di un ordine diventi effettivamente un ordine di acquisto deve essere approvata da un dipendente abilitato ad approvare
2.1. DESCRIZIONE DEL PROCESSO DI ACQUISTO 13 quel determinato tipo di ordine. Anche se non `e una regola, solitamente questa per-sona viene identificata con il responsabile dell’area funzionale in oggetto e viene definito approvatore.
Buyer: `e il dipendente dell’ufficio acquisti che si occupa dell’organizzazione e della gestione dell’ordine di fornitura e avvia le trattative commerciali con i nuovi fornitori.
Listino: i prodotti per i quali `e gi`a avvenuta una fornitura oppure `e stata con-clusa una trattativa commerciale con il fornitore, sono inseriti a listino, insieme alle informazioni relative al fornitore e al prezzo.
Categoria merceologica: classificazione degli articoli acquistati (oppure ven-duti) su diversi livelli di dettaglio. Spesso sulla categoria merceologica insiste una gerarchia merceologica.
Ricevimento: con questo termine si indica il momento in cui la merce inviata dal fornitore arriva presso uno degli stabilimenti dell’azienda. Ogni ricevimento merce `e accompagnato da un documento di trasporto (DDT).
Documento di trasporto (DDT): Viene emesso per giustificare il trasferimen-to di merce da fornitrasferimen-tore a cliente, spesso viene chiamatrasferimen-to anche bolla di accompa-gnamento. Il documento riporta i seguenti dati:
• Il numero progressivo. • La data.
• Le generalit`a del cedente, del cessionario e dell’eventuale incaricato al tra-sporto.
• La quantit`a dei beni trasportati.
• la descrizione dei beni trasportati con l’indicazione della natura e qualit`a degli stessi.
Plateaux: `e quantit`a minima di ricevimento fornitura.
Fattura passiva: `e la fattura emessa dal fornitore verso il cliente a fronte di un acquisto. La fattura `e un documento composto da una parte descrittiva e una parte tabellare. La parte descrittiva contiene1:
• I dati identificativi del venditore (indirizzo, partita IVA, nome, cognome, ditta, ecc.).
• Dati identificativi del compratore. • Data di emissione.
• Numero di fattura.
• Condizioni generali di vendita (tipo consegna, tipo imballaggio, tipo paga-mento ecc.).
1
14 CAPITOLO 2. PRESENTAZIONE DEL CASO La parte tabellare contiene:
• La quantit`a e la descrizione delle merci.
• Il prezzo unitario e l’importo complessivo di ciascuna merce. • Gli sconti mercantili concessi al compratore.
• Eventuali spese accessorie a carico del compratore (assicurazione, trasporto, ecc.).
• Base imponibile su cui si calcola l’IVA. • Aliquota IVA (4% - 10% - 21%). • Totale fattura.
Saving: per saving o saving generato si intendono risorse finanziarie non spese a fronte di una razionalizzazione od ottimizzazione della spesa.
Compliance procedure: si intende la conformit`a ed il rispetto delle procedure definite dall’azienda da parte del personale.
KPI: un Key Performance Indicator, letteralmente: indicatore chiave di pre-stazione; `e un indice che monitora in termini quantitativi un particolare processo aziendale, spesso `e definito a partire da un preciso obiettivo di risultato che si vuole ottenere sul processo.
2.1.3 Descrizione del processo
Il processo di acquisto inizia con la richiesta di fornitura da parte di un soggetto abilitato (originatore), al proprio responsabile (approvatore); la richiesta pu`o essere respinta o accettata dal responsabile: nel caso venga respinta essa viene registrata come respinta e il processo termina; nel caso venga accettata viene invece registrata come ordine di acquisto.
L’ordine di acquisto `e trattato dall’ufficio acquisti: una risorsa del personale (buyer) prende in carico l’ordine e nel caso la fornitura sia a listino provvede a contattare il fornitore inviando l’ordine di acquisto, nel caso in cui la fornitura non sia a listino il buyer inizia la ricerca del fornitore quindi la trattativa.
Se confermato, l’ordine viene preso in carico dal fornitore e, secondo i modi e i tempi prestabiliti dalle parti, la fornitura viene consegnata al cliente insieme alla bolla di accompagnamento: la fornitura viene quindi registrata come ricevimento fornitura. E’ bene ricordare che i metodi e tempi di consegna cambiano da fornitore a fornitore a seconda delle esigenze, dal tipo di merce e dalla quantit`a; inoltre la consegna pu`o avvenire a scaglioni. Successivamente il cliente riceve la fattura dal fornitore la quale viene registra in contabilit`a e pagata secondo i metodi e i tempi prestabiliti. In fine il pagamento viene registrato in contabilit`a generale (CO.GE.).
2.1. DESCRIZIONE DEL PROCESSO DI ACQUISTO 15 Il sistema informativo dell’azienda
L’azienda utilizza per la governance dei processi aziendali un sistema informativo basato sul sistema Oracle JD Edwards, un moderno sistema gestionale per il sup-porto e l’integrazione delle attivit`a e delle risorse aziendali. Con il termine sistemi gestionali si intendono identificare i sistemi integrati di gestione, cio`e insiemi di applicazioni software integrate, che gestiscono tutte le informazioni rilevanti del-l’azienda in un’unica base dati centralizzata e che consentono di gestire in modo coordinato alcune - o tutte - le attivit`a dell’azienda. In particolare la contabilit`a, gli approvvigionamenti e gli ordini sono interamente coordinati dal software gestio-nale. Questo garantisce che i dati provenienti dai vari dipartimenti siano sempre aggiornati, coerenti e consistenti tra loro. Inoltre ha permesso di avere un’unica base dati sorgente dal quale vengono estratti i dati per l’alimentazione del data warehouse.
Origine dei dati per gli indicatori
Le fonti dati per gli indicatori sono varie e la loro scelta dipende dalla finalit`a della misurazione. Per l’analisi dei dati di consuntivo la scelta ideale sono le fatture, ma per analizzare il processo di gestione dell’ordine la fonte pi`u opportuna sono gli ordini d’acquisto.
Come illustrato in Figura 2.1 i dati che vengono dalle stime fatte durante il bud-get o in pianificazione permettono di avere un ampio orizzonte temporale per agire, ma i dati sono incerti. I dati che provengono dalle fatture invece, hanno un’eleva-ta accuratezza ma la disponibilit`a dal dato arriva troppo in riun’eleva-tardo per permettere azioni correttive. Quindi la necessit`a di mediare tra orizzonte temporale sufficiente per avviare azioni correttive e accuratezza del dato rendono gli ordini di acquisto la miglior fonte del dato.
Figura 2.1: Accuratezza del dato e tempi di azione in relazione alle fasi del processo di acquisto.
Relazioni tra ordini, fatture e ricevimenti
Scendendo maggiormente nel dettaglio del processo `e utile vedere come gli ordini, le fatture e i ricevimenti di merce sono gestiti sia dal punto di vista organizzativo sia dal punto di vista del sistema informativo. In Figura 2.2 sono schematizzate
16 CAPITOLO 2. PRESENTAZIONE DEL CASO - utilizzando un diagramma di tipo Entity-Relation - il tipo di relazioni che inter-corrono tra i tipi di documento: ordini, fatture e ricevimenti. Le stesse relazioni si applicano alle singole righe dei documenti. Si hanno i seguenti casi:
• Ad un ordine `e associata una oppure, nel caso l’ordine sia aperto (cio`e si `e in attesa di ricevere la merce), nessuna fattura.
• Ad una fattura sono associati pi`u ordini se nel mese vengono emessi pi`u ordi-ni verso uno stesso forordi-nitore (tipicamente la fatturazione viene contabilizzata con scadenza mensile, in questo caso il fornitore inserisce tutti gli ordini del mese nella stessa fattura) oppure nessun ordine se il personale dell’ufficio ac-quisti si accorda direttamente con il fornitore senza prima emettere l’ordine (questo comportamento `e potenzialmente non compliance perch`e l’addetto non rispetta le normali procedure di acquisto).
• Ad un ordine sono associati pi`u ricevimenti di merce (la consegna pu`o avve-nire a scaglioni), oppure nessun ricevimento nel periodo in cui si attende la merce.
• Ad un ricevimento sono associati uno o pi`u ordini nel caso il fornitore sod-disfi pi`u ordini mediante una sola spedizione.
Figura 2.2: Relazioni tra ordini, fatture e ricevimenti.
2.2
Raccolta dei requisiti
L’azienda ha svolto uno studio volto alla definizione dei KPI (Key Performance Indicator), dei report e dei cruscotti con l’obiettivo di realizzare un’applicazione che renda possibile agli utenti:
• L’analisi multidimensionale sui dati di spesa corrente per identificarne le cause di variabilit`a e le opportunit`a di riduzione.
• Il controllo dei processi interni rispetto a specifici target:
– Performance ufficio acquisti in termini di saving generato e soddisfa-zione clienti interni.
– Compliance procedure. – Costi interni.
2.2. RACCOLTA DEI REQUISITI 17 Gli indicatori dovranno permettere di scomporre la spesa secondo diverse dimen-sioni e permettere analisi di dettaglio a seconda della tipologia:
• Merceologia. • Materiali. • Fornitori.
• Buyer/ufficio acquisti. • Stabilimento.
Gli indicatori del processo acquisti possono essere scomposti in tre macro-famiglie: • Misurazione delle performance dell’ufficio acquisti relative a:
– Efficacia: saving ottenuti e nuovi fornitori introdotti.
– Efficienza: spending controllato, fornitori gestiti da pi`u buyer, fornitori per categoria.
– Livello di servizio: tempo di attraversamento e soddisfazione clienti interni.
• Compliance processi/procedure: misurazione del rispetto delle procedure definite da parte del team acquisti, ma anche dei clienti interni; misurazione effettuata sul tempo di attraversamento, transazioni effettuate e rispetto dei processi definiti.
• Costi interni di processo: costi relativi al processo, inclusi personale, tec-nologia, servizi interni. Essi vengo misurati relativamente allo spending ge-stito o al saving generato, piuttosto che rispetto alle transazioni (costo per ordine/fornitore).
Nelle Tabelle 2.1 - 2.4 vengono elencate le necessit`a di analisi del cliente, a se-guire ogni requisito viene poi presentato mediante un report di esempio in formato tabellare. Le analisi sono raggruppate in quattro tipologie:
1. Analisi degli ordini di acquisto. 2. Analisi dei ricevimenti di fornitura. 3. Analisi delle fatture.
4. Analisi delle richieste di nuovi fornitori.
Il primo gruppo di requisiti riguarda l’analisi della spesa vera e propria, ovvero l’analisi dei dati provenienti dalla contabilit`a fornitori. Essi aggregano la spesa per: articolo, fornitore e buyer facendone una classifica che mostra solo i 5 pi`u importanti (requisiti 1-5). Inoltre analizza la base fornitura gestita da ogni buyer,
18 CAPITOLO 2. PRESENTAZIONE DEL CASO sia in termini quantitativi (numero di fornitori) che economici (fatturato) (requisiti 6 e 7).
Analisi sugli ordini di acquisto
1 Numero di ordini di acquisto mensili per originatore, il dato deve riguardare sia il mese in corso che lo stesso mese dell’anno precedente (Tabella 2.5) 2 Numero righe di ordini di acquisto mensili per originatore, il dato deve
ri-guardare sia il mese in corso che lo stesso mese dell’anno precedente (Tabella 2.5)
3 Spesa media e in valore assoluto mensile per originatore, il dato deve riguardare sia il mese in corso che lo stesso mese dell’anno precedente (Tabella 2.5) 4 Numero di ordini di acquisto mensili per buyer, il dato deve riguardare sia il
mese in corso che lo stesso mese dell’anno precedente (Tabella 2.6)
5 Numero righe di ordini di acquisto mensili per buyer, il dato deve riguardare sia il mese in corso che lo stesso mese dell’anno precedente (Tabella 2.6) 6 Spesa media e in valore assoluto mensile per buyer, il dato deve riguardare sia
il mese in corso che lo stesso mese dell’anno precedente (Tabella 2.6) 7 Numero e importo righe ordini di acquisto mensili a listino per originatore, il
dato deve riguardare il valore assoluto mensile, il valore cumulato (da inizio anno al mese corrente), il valore totale nell’anno precedente e il valore medio (righe ordini a listino su righe totali) (Tabella 2.7)
8 Numero e importo righe ordini di acquisto mensili urgenti per originatore, il dato deve riguardare il valore assoluto mensile, il valore cumulato (da inizio anno al mese corrente), il valore totale nell’anno precedente e il valore medio (righe ordini a urgenti su righe totali) (Tabella 2.8)
Tabella 2.1: Elenco dei requisiti di analisi sugli ordini di acquisto.
Il secondo gruppo riguarda l’analisi degli ordini di acquisto, cio`e il numero e l’im-porto degli ordini raggruppati per originatore e per buyer (requisiti 8-13). Vengono inoltre analizzati il numero di ordini a listino (requisito 14) e il numero di ordini urgenti (requisito 15). Il terzo gruppo mostra le richieste di introduzione di nuovi fornitori (requisito 16).
Analisi sui ricevimenti di fornitura
9 Quantit`a di merce ricevuta in metri quadrati, per fornitore (Tabella 2.9) 10 Quantit`a di merce ricevuta in metri quadrati per articolo, per deposito (Tabella
2.10)
2.2. RACCOLTA DEI REQUISITI 19
Analisi delle fatture
11 I primi 5 articoli pi`u acquistati mensilmente raggruppati per categoria merceo-logica, i dati devono riguardare sia il mese in corso che lo stesso mese dell’anno precedente e devono essere espressi in valore assoluto e in valore percentuale sul totale della spesa (Tabella 2.11)
12 I primi 5 fornitori per i quali si ha la maggior spesa mensile, i dati devono riguardare sia il mese in corso che lo stesso mese dell’anno precedente e devono essere espressi in valore assoluto e in valore percentuale sul totale della spesa (Tabella 2.12)
13 I primi 5 fornitori per i quali si ha la maggior spesa mensile per categoria merceologica, i dati devono riguardare sia il mese in corso che lo stesso me-se dell’anno precedente e devono esme-sere espressi in valore assoluto e in valore percentuale sul totale della spesa (Tabella 2.13)
14 I primi 5 buyer che hanno acquistato maggiormente nel mese, i dati devono riguardare sia il mese in corso che lo stesso mese dell’anno precedente e devono essere espressi in valore assoluto e in valore percentuale sul totale della spesa (Tabella 2.14)
15 I primi 5 buyer che hanno acquistato maggiormente nel mese per categoria merceologica, i dati devono riguardare sia il mese in corso che lo stesso me-se dell’anno precedente e devono esme-sere espressi in valore assoluto e in valore percentuale sul totale della spesa (Tabella 2.15)
16 Numero di fornitori gestiti per buyer (Tabella 2.16) 17 Spesa media annua gestita per buyer (Tabella 2.16)
Tabella 2.3: Elenco dei requisiti di analisi sui dati di fatturazione.
In fine il quarto gruppo analizza i ricevimenti di merce, aggregando i dati per for-nitore, articolo e deposito (requisiti 17 e 18). Questi ultimi due requisiti di analisi sono applicati a tutti i ricevimenti di merce: alcune categorie di articoli maggior-mente acquistati e sul quale `e richiesto di condurre analisi sono: mangimi, animali vivi/non vivi e contenitori di packaging.
Analisi sulle richieste di nuovi fornitori
18 Numero di richieste di inserimento nuovi fornitori suddivisi per tipologia: creazione, modifica, trasformazione e totale (Tabella 2.17)
Tabella 2.4: Elenco dei requisiti di analisi sulle richieste di nuovi fornitori.
Analisi degli ordini di acquisto Di seguito sono mostrati report per l’analisi degli ordini di acquisto. I requisiti di analisi sono essenzialmente due: ordine medio per originatore (Tabella 2.5) e ordine medio per buyer (Tabella 2.6). Per ordine medio si intende l’importo medio degli ordini richiesti, cio`e il rapporto tra la sommatoria degli ordini e il numero di ordini gestiti per originatore e per buyer;
20 CAPITOLO 2. PRESENTAZIONE DEL CASO inoltre si richiede di calcolare il numero di ordini e il numero di righe d’ordine sia per l’anno in corso che per l’anno precedente.
Analisi ordini per originatore Originatore Spesa media (e) Righe d’ordine (#) Righe d’or-dine anno preceden-te(#) Ordini (#) Ordini anno pre-cedente (#) O1 ... ... ... ... ... O2 ... ... ... ... ... .. . ... ... ... ... ...
Tabella 2.5: Esempio di report per l’analisi ordini per originatore (requisiti 8-10).
Analisi ordini per buyer Buyer Spesa media (e) Righe d’ordine (#) Righe d’or-dine anno preceden-te(#) Ordini (#) Ordini anno pre-cedente (#) B1 ... ... ... ... ... B2 ... ... ... ... ... .. . ... ... ... ... ...
Tabella 2.6: Esempio di report per l’analisi ordini per buyer (requisito 11-14).
In Tabella 2.7 invece `e mostrata l’analisi degli ordini a listino. Un parametro chiave per misurare il rispetto da parte dei dipendenti delle procedure definite dal team acquisti (compliance procedure) `e l’analisi del numero di ordini richiesti a listino. Il listino, come descritto nel glossario di progetto, `e una lista contenente tutti i prodotti per i quali in precedenza `e stata avviata una trattativa commerciale con il fornitore. L’ordine a listino indica una corretta procedura di acquisto. Le metriche sono espresse sia in termini quantitativi (numero di ordini) che economici (importo ordini).
2.2. RACCOLTA DEI REQUISITI 21
Analisi righe d’ordine a listino per originatore Originatore Articoli a listino (#) Articoli a listino (%) Articoli a listino cumulati (#) Articoli a listino anno pre-cedente(#) O1 ... ... ... ... O2 ... ... ... ... .. . ... ... ... ...
Tabella 2.7: Esempio di report per l’analisi ordini a listino (requisito 15).
Un’altra analisi importante sugli ordini di acquisto `e quella mostrata in Tabella 2.8 che analizza il numero di ordini urgenti per originatore. L’analisi degli ordini urgenti `e un buon indicatore per misurare la soddisfazione dei clienti interni: un numero ridotto di ordini urgenti significa una maggiore efficienza dell’ufficio ac-quisti e quindi una maggior soddisfazione del personale interno. Anche in questo caso le metriche sono espresse sia in termini quantitativi (numero di ordini urgenti) che economici (importo ordini).
Analisi righe d’ordine urgenti per originatore Originatore Articoli urgenti (#) Articoli urgenti (%) Articoli urgenti cumulati (#) Articoli urgenti anno pre-cedente(#) O1 ... ... ... ... O2 ... ... ... ... .. . ... ... ... ...
Tabella 2.8: Esempio di report per l’analisi ordini urgenti (requisito 16).
Analisi dei ricevimenti di fornitura Con la realizzazione dei report mostrati in Tabella 2.9 e 2.10 si vogliono monitorare i ricevimenti di fornitura. Questo al fine di individuare quali sono gli articoli maggiormente richiesti e i depositi maggior-mente utilizzati. Nell’esempio in Tabella 2.9 `e mostrato un caso particolare, in cui vengono analizzati in dettaglio le forniture di materiali di packaging, nel report sono considerati esclusivamente i fornitori principali: IP, FustelPack e Scatolifi-cio Sandra. Il report in Tabella 2.10 riguarda l’analisi degli articoli ricevuti (non solo packaging, opportunamente convertiti in metri quadrati per avere un’unit`a di misura di confronto) per i depositi principali di Cesena, S. Sofia, Teramo e Brescia.
22 CAPITOLO 2. PRESENTAZIONE DEL CASO
Quantit`a di merce ricevuta per fornitore Fornitore Plateaux (Mq)
IP ...
FustelPack ... Scatolificio Sandra ...
Tabella 2.9: Esempio di report di dettaglio per l’analisi delle quantit`a di articoli di packaging ricevuti dai tre fornitori principali (requisito 18).
Quantit`a di merce ricevuta per articolo, per deposito Articolo Deposito Plateaux (Mq) A1 Cesena ... S. Sofia ... Teramo ... Brescia ... A2 Cesena ... S. Sofia ... Teramo ... Brescia ... .. . ... ...
Tabella 2.10: Esempio di report per l’analisi delle quantit`a di merce ricevuta per articolo, per deposito (requisito 19).
Analisi delle fatture Nei seguenti report si passa all’analisi dei dati di fattura-zione, cio`e all’analisi della spesa effettivamente avvenuta.
Di seguito `e riportato un esempio di report per l’analisi della spesa aggrega-ta per categoria merceologica dell’aricolo acquisaggrega-tato (Tabella 2.11). La categoria merceologica dell’articolo si pone ad un basso livello di dettaglio, solitamente in questa voce rientrano: le spese per materiali di imballaggio, spese per attrezzature e spese per carburante. Il report mostra soltanto le prime 5 categorie per le quali si `e speso maggiormente.
2.2. RACCOLTA DEI REQUISITI 23
Top 5 categorie articoli pi`u acquistati nel mese Categoria articolo Spesa (e) Spesa (%) Spesa anno precedente (e) Spesa anno precedente (%) C1 ... ... ... ... C2 ... ... ... ... C3 ... ... ... ... C4 ... ... ... ... C5 ... ... ... ...
Tabella 2.11: Esempio di report per le prime 5 categorie di articoli in ordine di spesa (requisito 1).
La stessa logica viene ripetuta per i fornitori: vengono calcolati i primi 5 fornitori per i quali si `e speso di pi`u. Questa analisi permette di quantificare quali sono i fornitori pi`u importanti per l’azienda.
Top 5 fornitori per spesa nel mese
Fornitore Spesa (e) Spesa (%) Spesa anno precedente (e) Spesa anno precedente (%) F1 ... ... ... ... F2 ... ... ... ... F3 ... ... ... ... F4 ... ... ... ... F5 ... ... ... ...
Tabella 2.12: Esempio di report per i primi 5 fornitori in ordine di spesa (requisito 2).
Il report in Tabella 2.13 aggrega i dati delle precedenti analisi in modo da avere per ogni fornitore le 3 categorie merceologiche maggiormente acquistate.
24 CAPITOLO 2. PRESENTAZIONE DEL CASO
Top 5 fornitori per spesa nel mese per categoria articolo
Fornitore Categoria articolo Spesa (e) Spesa (%) Spesa anno precedente (e) Spesa anno precedente (%) F1 C1 ... ... ... ... C2 ... ... ... ... C3 ... ... ... ... F2 C2 ... ... ... ... C4 ... ... ... ... C5 ... ... ... ... .. . ... ... ... ... ...
Tabella 2.13: Esempio di report per i primi 5 fornitori in ordine di spesa per categoria articolo (requisito 3).
Il buyer `e quelle figura che si occupa della gestione dell’ordine e dei rapporti con i fornitori. Nel report in Tabella 2.14 sono mostrati i 5 buyer della funzione acquisti che gestiscono pi`u spesa.
Top 5 buyer per spesa gestita nel mese
Buyer Spesa (e) Spesa (%) Spesa anno precedente (e) Spesa anno precedente (%) B1 ... ... ... ... B2 ... ... ... ... B3 ... ... ... ... B4 ... ... ... ... B5 ... ... ... ...
Tabella 2.14: Esempio di report per i primi 5 buyer in ordine di spesa gestita (requisito 4).
In Tabella 2.15 la spesa viene aggregata prima per buyer poi per categoria merceo-logica. In questo modo per ogni buyer si ha il dettaglio sulla tipologia di fornitura sui quali sono “specializzati”.
2.2. RACCOLTA DEI REQUISITI 25
Top 5 buyer per spesa gestita nel mese per categoria articolo
Buyer Categoria articolo Spesa (e) Spesa (%) Spesa anno precedente (e) Spesa anno precedente (%) B1 C1 ... ... ... ... C2 ... ... ... ... C3 ... ... ... ... B2 C2 ... ... ... ... C4 ... ... ... ... C5 ... ... ... ... .. . ... ... ... ... ...
Tabella 2.15: Esempio di report per i primi 5 buyer in ordine di spesa gestita per categoria articolo (requisito 5).
In Tabella 2.16 per ogni buyer viene riportato il numero di fornitori e la spesa media gestita, intesa come il rapporto tra la spesa totale (per buyer) e il numero di fornitori gestiti.
Numero fornitori e spesa media per buyer Buyer Fornitori
ge-stiti (#) Spesa media gestita (e) B1 ... ... B2 ... ... .. . ... ...
Tabella 2.16: Esempio di report per l’analisi del numero di fornitori e spesa media per buyer (requisiti 6 e 7).
Analisi delle richieste di nuovi fornitori Il report in Tabella 2.17 calcola una serie di metriche relative al numero di richieste di nuovi fornitori che il personale avanza all’ufficio acquisti al fine di mantenere monitorato il numero totale di forni-tori ed evitarne una proliferazione non giustificata che renderebbe meno efficiente il processo di acquisto.
26 CAPITOLO 2. PRESENTAZIONE DEL CASO
Analisi richieste nuovi fornitori Tipo Richieste (#) Inserimento ...
Modifica ... Trasformazione ... Totale ...
Tabella 2.17: Esempio di report per l’analisi delle richieste di inserimento nuovi fornitori (requisito 17).
2.3
Riassunto
In questo capitolo `e stato presentato il caso di studio per l’analisi degli acquisti. Dopo una breve presentazione dell’azienda e un glossario con i termini utilizzati in ambito acquisti `e stato descritto il processo di acquisto. Inoltre `e stato dettagliato un aspetto di tipo contabile-organizzativo relativo al legame tra ordini di acquisto, fatture e bolle di accompagnamento necessario per capire la natura dei dati. I requisiti di analisi sono stati descritti utilizzando i termini propri degli utenti di business, successivamente, per ogni requisito, `e stato inserito un report di esempio per mostrare meglio il tipo di analisi.
Capitolo 3
SPECIFICA DEI REQUISITI
In questo capitolo i requisiti di analisi descritti nel capitolo precedente vengono analizzati e tradotti nei costrutti tipici della progettazione di data warehouse: fatti, misure, dimensioni e gerarchie.
I contenuti del capitolo sono suddivisi per soggetto di analisi: la Sezione 3.1 analizza il processo relativo agli ordini di acquisto, la Sezione 3.2 il processo di ricevimento degli articoli ordinati, la Sezione 3.3 analizza il processo di fattura-zione, mentre la Sezione 3.4 analizza le richieste di nuovi fornitori. Ogni sezione `e composta da tre sotto sezioni: specifica dei requisiti, progettazione concettuale e progettazione logica dei data mart. Dal momento che i quattro data mart han-no molte dimensioni in comune, la struttura delle dimensioni viene presentata nel dettaglio solo la prima volta in ordine di lettura del testo.
3.1
Processo Ordine di Acquisto
3.1.1 Specifica dei requisiti di analisi
I requisiti di analisi presentati precedentemente vengono riportati nella tabella se-guente aggiungendo per ognuno le dimensioni di analisi, le metriche e le misure coinvolte. Successivamente per ogni dimensione vengono definiti gli attributi di-mensionali e le relazioni gerarchiche tra questi, inoltre, per ogni attributo, viene riportato un esempio di valore. Successivamente vengono definite le tabelle dei fatti, la loro granularit`a e le misure utilizzate.
28 CAPITOLO 3. SPECIFICA DEI REQUISITI
Analisi ordini di acquisto N Requisito di analisi Dimensioni Metriche Misure 1 Numero di ordini di
ac-quisto per originatore, per mese in corso e stesso mese dell’anno precedente.
Data
(Anno, Mese), Originatore.
# OdA,
# OdA mese a.p..
-2 Numero di righe ordini di acquisto per origina-tore, per mese in corso e stesso mese dell’anno precedente.
Data
(Anno, Mese), Originatore.
# Righe OdA,
# Righe OdA mese a.p..
-3 Spesa media e in valo-re assoluto per origina-tore, per mese in corso e stesso mese dell’anno precedente.
Data
(Anno, Mese), Originatore.
Importo OdA / # OdA, Importo OdA,
Importo OdA mese a.p. / # OdA mese a.p., Importo OdA mese a.p..
Importo riga OdA.
4 Numero di ordini di ac-quisto per buyer, per mese in corso e stes-so mese dell’anno pre-cedente. Data (Anno, Mese), Buyer. # OdA, # OdA a.p..
-5 Numero di righe ordi-ni di acquisto per buyer, per mese in corso e stesso mese dell’anno precedente.
Data
(Anno, Mese), Buyer.
# Righe OdA,
# Righe OdA mese a.p..
-6 Spesa media e in va-lore assoluto per buyer, per mese in corso e stesso mese dell’anno precedente.
Data
(Anno, Mese), Originatore.
Importo OdA / # OdA, Importo OdA,
Importo OdA mese a.p. / # OdA mese a.p., Importo OdA mese a.p..
Importo riga OdA.
7 Numero e importo ri-ghe ordini di acquisto a listino per originato-re, per mese in re assoluto e in valo-re cumulato (da inizio anno al mese corrente), il valore totale nell’an-no precedente e il valo-re medio (righe ordini a listino su righe totali)
Data
(Anno, Mese), Originatore, Listino.
# Righe OdA da listino, # Righe OdA da listino / # Righe OdA,
# Righe OdA da listino cumulate,
# Righe OdA da listino anno precedente, Importo righe OdA da li-stino,
Importo righe OdA da listino / importo righe OdA,
Importo righe OdA da li-stino cumulate,
Importo righe OdA da listino anno precedente.
Importo riga OdA.
8 Numero e importo ri-ghe ordini di acquisto urgenti per originatore, per mese in valore as-soluto e in valore cu-mulato (da inizio an-no al mese corrente), il valore totale nell’an-no precedente e il valo-re medio (righe ordini a urgenti su righe totali)
Data
(Anno, Mese), Originatore, OrdineUrgente.
# OdA urgenti, # OdA urgenti / # OdA, # OdA urgenti cumulati, # OdA urgenti anno pre-cedente,
Importo OdA urgenti, Importo OdA urgenti / importo OdA,
Importo OdA urgenti cu-mulati,
Importo OdA urgenti an-no precedente.
Importo riga OdA.
3.1. PROCESSO ORDINE DI ACQUISTO 29 Tabella dei fatti Le tabelle dei fatti sono le tabelle primarie dove i dati numerici che misurano le prestazioni del processo vengono salvate. Il termine “fatto” sta ad indicare un evento accaduto al quale sono associati uno o pi`u quantit`a numeriche che lo descrivono e lo “misurano”. Gli attributi della tabella dei fatti vengono appunto chiamati misure.
Fatto (ordine di acquisto) Descrizione Dimensioni Misure
La granularit`a del fatto `e la sin-gola riga d’ordine per avere il dettaglio sull’articolo
Data, Originatore, Buyer, Listi-no, OrdineUrgente
Importo riga OdA
Tabella delle dimensioni Le tabelle dimensionali contengono le descrizioni te-stuali delle entit`a di business. Esse hanno lo scopo di descrivere le misure con-tenute nella tabella dei fatti, gli attributi dimensionali consentono di selezionare e raggruppare le misure della tabella dei fatti secondo le logiche di analisi scelte dell’utente.
Dimensioni (ordini di acquisto) Nome Descrizione Granularit`a Degenere Data Dimensione temporale Giorno No Fornitore Anagrafica fornitori Fornitore No Articolo Classificazione merceologica
aziendale
Articolo No Buyer Anagrafica buyer Buyer No Originatore Anagrafica personale abilitato alla
richiesta di ordini
Originatore No NumeroOrdine Numero progressivo associato
al-l’ordine di acquisto
Ordine S`ı Listino Flag: indica se l’ordine `e a listino Riga ordine S`ı OrdineUrgente Flag: indica se l’ordine `e urgente Ordine S`ı
Di seguito, per ogni dimensione presentata nella tabella precedente, vengono de-scritti gli attributi dimensionali presenti nella dimensione.
Data Attributo Descrizione Esempio
Valore Giorno Data del giorno in formato aaaammgg 20121024 Settimana Numero della settimana da inizio anno 50 Mese Mese dell’anno in formato aaaamm 201210 Trimestre Descrizione testuale del trimestre
(quar-ter)
Q4 Anno Anno, in formato aaaa 2012
30 CAPITOLO 3. SPECIFICA DEI REQUISITI
Fornitore Attributo Descrizione Esempio
Valore CodiceFornitore Codice del fornitore 11070
NomeFornitore Nome / ragione sociale MCDONALD’S
DEU-TSCHLAND INC. CodiceResponsabile Codice del responsabile del fornitore A10 NomeResponsabile Nome e Cognome del responsabile del
fornitore
Franco Briani CodiceTerminePag Codice del termine di pagamento del
fornitore
104 DescrizioneTerminePag Descrizione del termine di pagamento
del fornitore
90 GG Data Fattura CodiceMetodoDiPag Codice del termine di pagamento del
fornitore
X DescrizioneMetodoPag Descrizione del termine di pagamento
del fornitore
Bonifico estero CodiceNazionalit`a Codice della nazionalit`a del fornitore GB
DescrizioneNazionalit`a Nazionalit`a del fornitore Gran Bretagna Cardinalit`a: ∼10.000
Articolo Attributo Descrizione Esempio
Valore CodiceArticolo Codice articolo 01111
NomeArticolo Nome descrittivo dell’articolo Pol petto MTR43086 fr CodiceSottoFamiglia Codice sotto-famiglia articolo IHC NomeSottoFamiglia Nome descrittivo sotto-famiglia
dell’ar-ticolo
CESTINI POL-LO
CodiceFamiglia Codice famiglia articolo CA3
NomeFamiglia Nome descrittivo famiglia articolo Pollo Tz Evi-scerato CodiceLinea Codice linea articolo B50
NomeLinea Nome descrittivo linea articolo Sem. pollo x elaborati CodiceGruppo Codice gruppo articolo BG1 NomeGruppo Nome descrittivo gruppo articolo Semilavorati
Cooperative CodiceCategoria Codice categoria 18
NomeCategoria Nome descrittivo categoria articolo Diretti Cardinalit`a: ∼60.000
3.1. PROCESSO ORDINE DI ACQUISTO 31
Buyer Attributo Descrizione Esempio
Valore CodiceBuyer Codice associato al buyer 9046 NomeArticolo Nome e cognome del buyer VALZANIA
PIERLUIGI CodiceGruppoBuyer Codice associato al gruppo del buyer 315795 NomeGruppoBuyer Nome del gruppo del buyer ACQUISTI DI
GRUPPO Cardinalit`a: ∼500
Originatore Attributo Descrizione Esempio
Valore CodiceOriginatore Codice dell’originatore dell’ordine ROSSIMA NomeOriginatore Nome e cognome dell’originatore
del-l’ordine
ROSSI MAURI-ZIO
Cardinalit`a: ∼1000
Listino Attributo Descrizione Esempio
Valore Listino Flag: 1 se l’articolo `e a listino, 0
altrimenti
1
Cardinalit`a: 2
OrdineUrgente Attributo Descrizione Esempio
Valore OrdineUrgente Flag: 1 se l’ordine `e urgente, 0
altrimenti
1
Cardinalit`a: 2
NumeroOrdine Attributo Descrizione Esempio
Valore NumeroOrdine Numero progressivo associato
all’ordi-ne di acquisto
8736
Cardinalit`a: ∼6.000.000 da Gen. 2011 a Giu. 2012
Tabella delle gerarchie dimensionali Le gerarchie definiscono le relazioni fra gli attributi di una stessa dimensione e il criterio di aggregazione dei dati. Ove possibile `e sempre consigliato definire gerarchie tra gli attributi delle dimensioni perch´e consentono di offrire all’utente un’analisi interattiva sui dati, passando da un livello di dattaglio ad un altro in un unica sessione di analisi.
32 CAPITOLO 3. SPECIFICA DEI REQUISITI Di seguito sono riportate le gerarchie per le dimensioni di progetto: Data, Fornitore, Articolo, Buyer.
Gerarchie dimensionali Dimensione Descrizione gerarchia Tipo gerarchia Data Giorno → Mese → Anno Bilanciata
Giorno → Settimana Bilanciata Fornitore CodiceFornitore → CodiceTerminePagamento Bilanciata
CodiceFornitore → CodiceResponsabileFornitore
Bilanciata CodiceFornitore → CodiceNazionalita Bilanciata CodiceFornitore → CodiceMetodoPagamento Bilanciata Articolo CodiceAricolo → CodiceSottoFamiglia →
CodiceFamiglia → Bilanciata CodiceLinea → CodiceGruppo CodiceAricolo → CodiceSottoFamiglia → CodiceFamiglia → Bilanciata CodiceLinea → CodiceCategoria
Buyer CodiceBuyer → CodiceGruppoBuyer Bilanciata
Tabella delle misure Come `e stato detto in precedenza l’additivit`a delle misure `e una propriet`a molto importante per i sistemi di analisi, poich´e permette di aggrega-re le misuaggrega-re lungo l’intera gerarchia della dimensione mediante l’operatoaggrega-re somma. Le misure semi-additive invece, possono essere sommate solamente attraverso un sottoinsieme delle dimensioni, mentre le misure non-additive non possono essere sommate in alcun modo: `e possibile solamente eseguire operazioni di conteggio righe o calcoli sul valore medio.
Come mostrato nella tabella successiva, nel progetto tutte le misure sono addi-tive su tutte le dimensioni di analisi.
Misure Misura Descrizione Aggregabilit`a Derivata Importo Importo riga d’ordine Additiva No
Tabella degli attrubuti descrittivi del fatto Questo tipo di attributi vengono valorizzati direttamente nella tabella dei fatti e hanno lo scopo di descrivere la misurazione (il fatto).
Come mostrato nella tabella seguente, le tabelle dei fatti sugli ordini, sulle fat-ture e sui ricevimenti hanno l’attributo Causale che rappresenta appunto la causale della riga del documento.
Attributi descrittivi del fatto Fatto Attributo Descrizione
3.1. PROCESSO ORDINE DI ACQUISTO 33 3.1.2 Progettazione Concettuale
Il modello concettuale ha lo scopo di rappresentare il contesto di analisi dei dati dando una descrizione formale e completa ma indipendente dai criteri di rappre-sentazione utilizzati nei sistemi di gestione delle basi di dati. Il modello permette di descrivere l’organizzazione dei dati ad un alto livello di astrazione, senza tenere conto degli aspetti implementativi.
Il formalismo grafico utilizzato per rappresentare il modello concettuale `e di tipo MCF (Multidimensional Fact Model): i fatti sono modellati con un rettangolo diviso in due parti, nella parte superiore viene riportato il nome del fatto, in quella inferiore la lista delle misure che lo compongono. Le dimensioni sono rappresen-tate da archi uscenti, il pallino pieno denota il nome della dimensione. Gli altri attributi dimensionali sono rappresentati da pallini vuoti e le rette che li congiun-gono denotano le dipendenze funzionali tra gli attributi. Le dimensioni degeneri hanno un solo pallino pieno, mentre gli attributi descrittivi dei fatti non hanno il pallino.
La granularit`a della tabella dei fatti per l’analisi degli ordini di acquisto `e la riga dell’ordine ed il fatto `e di tipo istantanea. Il modello concettuale `e mostrato in Fi-gura 3.1 e comprende una misura, otto dimensioni, di cui 3 degeneri, e un attributo descrittivo dei fatti. La misura della tabella dei fatti `e: Importo, ovvero l’impor-to della riga d’ordine. Le dimensioni degeneri sono: (i) NumeroOrdine, contiene il numero progressivo che il gestionale assegna all’ordine di acquisto, questa in-formazione permette di fare analisi a livello di ordine; (ii) Listino, `e un flag che indica se l’articolo `e presente a listino oppure no; (iii) Urgente indica se l’ordine per quell’articolo `e urgente oppure no. La dimensione Causale `e una dimensione descrittiva dei fatti contenente una descrizione/causale dell’articolo ordinato.
Tutti gli oggetti dimensionali del progetto hanno due campi: un codice e una descrizione. Il campo codice `e il codice proveniente dal gestionale, mentre cam-po descrizione `e una stringa che descrive l’oggetto. La scelta di cam-portarsi anche i codici del gestionale `e stata guidata da due motivi: primo perch`e spesso i codici stessi hanno nomi parlanti, quindi utilizzabili da parte degli utenti durante le ana-lisi; secondo questa informazione potrebbe rivelarsi utile in un’ottica di sviluppi futuri, per esempio nel caso si volesse trasformare una dimensione statica in una dimensione che cambia.
34 CAPITOLO 3. SPECIFICA DEI REQUISITI
Figura 3.1: Schema concettuale del data mart per l’analisi degli ordini.
3.1.3 Progettazione Logica
Si presenta qui la progettazione logica del data mart per l’analisi degli ordini (Fi-gura 3.2), ma lo stesso procedimento di progettazione vale anche per gli altri data mart del progetto. Lo schema relazionale adottato `e di tipo star schema: ogni di-mensione di analisi `e modellata mediante una tabella relazionale. La sottolineatura nei nomi dei campi denota che il campo `e o fa parte della chiave primaria della tabella, i campi con postfisso “ ID” denotano le chiavi surrogate delle tabelle di-mensionali, mentre i campi con postfisso “ FK” denotano le chiavi esterne verso le tabelle dimensionali. La chiavi surrogate delle tabelle dimensionali sono valori nu-merici generati automaticamente in fase di caricamento. Ogni tabella dimensionale possiede il valore di default “Non definito” per gestire i casi in cui non esistono va-lori della dimensione per il fatto, evitando cos`ı di inserire vava-lori nulli nella tabella dei fatti. Inoltre tutte le chiavi primarie delle tabelle dimensionali e tutti i campi di chieve esterna delle tabelle dei fatti dei data mart sono indicizzati con indici di tipo Bitmap.
3.2. PROCESSO RICEVIMENTO ARTICOLI 35
Figura 3.2: Schema logico del data mart per l’analisi degli ordini di acquisto.
La chiave primaria della tabella dei fatti si compone dai campi NumeroOrdine e Articolo FK. La dimensione degenere NumeroOrdine contiene il numero progres-sivo assegnato all’ordine (univoco a livello di ordini), mentre Articolo FK contiene la chiave surrogata relativa all’articolo ordinato (univoca a livello di singolo ordine dal momento che a livello di riga d’ordine gli articoli uguali vengono raggruppati insieme con l’indicazione della quantit`a). NumeroOrdine e Articolo FK insieme determinano la chiave primaria della tabella dei fatti con granularit`a a livello di riga d’ordine.
3.2
Processo Ricevimento Articoli
A grandi linee lo scenario del contesto di business dei ricevimenti merce `e questo: il mezzo, contenente la fornitura, arriva presso uno dei depositi dell’azienda, effet-tua il check-in e consegna la bolla di accompagnamento ad un operatore, il quale inserisce i dati della fornitura nel gestionale, il sistema in automatico aggiorna i dati relativi all’ordine corrispondente. Per un ordine di acquisto si possono avere pi`u consegne, quindi pi`u ricevimenti e ad ogni ricevimento corrisponde una bolla di accompagnamento.
36 CAPITOLO 3. SPECIFICA DEI REQUISITI
3.2.1 Specifica dei requisiti di analisi
Analisi ricevimenti articoli N Requisito di analisi Dimensioni Metriche Misure 1 Quantit`a di merce
rice-vuta in metri quadrati, per fornitore, per mese.
Data (Anno, Mese), Fornitore. Mq ricevu-ti. Mq ricevu-ti.
2 Quantit`a di merce ri-cevuta in metri qua-drati per articolo, per deposito, per mese.
Data (Anno, Mese), Articolo, Deposito. Mq ricevu-ti. Mq ricevu-ti.
Fatto (ricevimenti articoli) Descrizione Dimensioni Misure
Il fatto `e la singola riga della bolla di accompagnamento per avere il dettaglio sull’articolo
Data, Fornitore, Depo-sito, Articolo
Mq ricevuti
Dimensioni (ricevimenti articoli) Nome Descrizione Granularit`a Degenere Data Dimensione temporale Giorno No Fornitore Anagrafica fornitori Fornitore No Articolo Classificazione merceologica
aziendale
Articolo No Buyer Anagrafica buyer Buyer No Deposito Anagrafica dei depositi Deposito NumeroRicevimento Numero progressivo associato al
ricevimento di merce
Ricevimento S`ı
Deposito Attributo Descrizione Esempio
Valore CodiceDeposito Codice del deposito 0FC NomeDeposito Riferimento geografico del deposito Cesena
3.2. PROCESSO RICEVIMENTO ARTICOLI 37
NumeroRicevimento Attributo Descrizione Esempio
Valore NumeroRicevimento Numero progressivo associato al
ricevi-mento di merce
9375
Cardinalit`a: ∼6.000.000 da Gen. 2011 a Giu. 2012
Misure Misura Descrizione Aggregabilit`a Derivata Mq ricevuti Quantit`a di merce ricevuta Additiva No
espressa in metri quadrati
Attributi descrittivi del fatto Fatto Attributo Descrizione
Riga ricevimento articoli Causale Causale del ricevimen-to
3.2.2 Progettazione Concettuale
In Figura 3.5 `e mostrato il modello concettuale del data mart per l’analisi degli articoli ricevuti. L’unica misura della tabella dei fatti `e MQRicevuti, che contie-ne la quantit`a di merce ricevuta espressa in metri quadrati. Il valore della metrica MQRicevuti viene calcolato moltiplicando la quantit`a ricevuta per un fattore di ingombro associato ad ogni tipologia di articolo. Per quanto riguarda le dimensio-ni invece, questo modello possiede un sottoinsieme delle dimensiodimensio-ni del modello precedentemente descritto: Data, Articolo, Fornitore, Buyer, con l’aggiunta della dimensione Deposito e della dimensione degenere NumeroRicevimento al posto di NumeroOrdine.
38 CAPITOLO 3. SPECIFICA DEI REQUISITI
3.3. PROCESSO FATTURAZIONE 39 3.2.3 Progettazione Logica
La progettazione logica `e simile a quella del data mart per l’analisi degli ordini. La chiave primaria della tabella dei fatti `e composta dai campi NumeroRicevimento e Articolo FK per garantire l’univocit`a a livello di singola riga di documento.
Figura 3.4: Schema logico del data mart per l’analisi dei ricevimenti merce.
3.3
Processo Fatturazione
In questa fase la fattura del fornitore viene ricevuta e registrata in contabilit`a. Nella Sezione 3.3.1 vengono elencati i requisiti di analisi sui dati di fatturazione.
40 CAPITOLO 3. SPECIFICA DEI REQUISITI 3.3.1 Specifica dei requisiti di analisi
Analisi fatture N Requisito di analisi Dimensioni Metriche Misure 1 Primi 5 articoli pi`u
acquistati mensilmente raggruppati per catego-ria merceologica, per mese in corso e stes-so mese dell’anno pre-cedente (a.p.). Dati espressi in valore as-soluto e in valore per-centuale sul totale della spesa. Data (Anno, Mese), Articolo (Categoria). Fatturato, % Fatturato, Fatturato mese a.p., % Fatturato mese a.p..
Importo riga fattura.
2 Primi 5 fornitori per i quali si ha la maggior spesa mensile, per se in corso e stesso me-se dell’anno preceden-te. Dati espressi in va-lore assoluto e in valo-re percentuale sul totale della spesa. Data (Anno, Mese), Fornitore. Fatturato, % Fatturato, Fatturato mese a.p., % Fatturato mese a.p..
Importo riga fattura.
3 Primi 5 fornitori per i quali si ha la maggior spesa mensile per cate-goria merceologica, per mese in corso e stes-so mese dell’anno pre-cedente. Dati espressi in valore assoluto e in valore percentuale sul totale della spesa
Data (Anno, Mese), Fornitore, Articolo (Categoria). Fatturato, % Fatturato, Fatturato mese a.p., % Fatturato mese a.p..
Importo riga fattura.
4 Primi 5 buyer che han-no acquistato maggior-mente nel mese, per mese in corso e stes-so mese dell’anno pre-cedente. Dati espressi in valore assoluto e in valore percentuale sul totale della spesa.
Data
(Anno, Mese), Buyer.
Fatturato, % Fatturato, Fatturato mese a.p., % Fatturato mese a.p..
Importo riga fattura.
5 Primi 5 buyer che hanno acquistato mag-giormente nel mese per categoria merceo-logica, per mese in corso e stesso mese dell’anno precedente. Dati espressi in valore assoluto e in valore percentuale sul totale della spesa. Data (Anno, Mese), Buyer, Articolo (Categoria). Fatturato, % Fatturato, Fatturato mese a.p., % Fatturato mese a.p..
Importo riga fattura.
6 Numero di fornitori ge-stiti per buyer.
Data (Anno), Buyer, Fornitore.
# Fornitori.
-7 Spesa media annua ge-stita per buyer.
Data (Anno), Buyer.
Fatturato buyer / # Forni-tori buyer.
Importo riga fattura.
3.3. PROCESSO FATTURAZIONE 41
Fatto (fatture) Descrizione Dimensioni Misure
Il fatto `e la singola riga del-la fattura per avere il dettaglio sull’articolo
Data, Fornitore, Buyer, Artico-lo
Importo riga fattura, Tempo di attraversa-mento
Dimensioni (fatture) Nome Descrizione Granularit`a Degenere Data Dimensione temporale Giorno No Fornitore Anagrafica fornitori Fornitore No Articolo Classificazione merceologica
aziendale
Articolo No Buyer Anagrafica buyer Buyer No NumeroFattura Numero progressivo associato alla
fattura
Fattura S`ı
NumeroFattura Attributo Descrizione Esempio
Valore NumeroFattura Numero progressivo associato alla
fat-tura
2735
Cardinalit`a: ∼11.000 al mese
Misure Misura Descrizione Aggregabilit`a Derivata Importo Importo riga fattura Additiva No
Attributi descrittivi del fatto Fatto Attributo Descrizione
42 CAPITOLO 3. SPECIFICA DEI REQUISITI 3.3.2 Progettazione Concettuale
La tabella dei fatti per l’analisi delle fatture possiede una sola misura:Importo; che esprime l’importo della riga di fattura (quantita unitaria x prezzo unitario).
3.4. PROCESSO RICHIESTA NUOVI FORNITORI 43 3.3.3 Progettazione Logica
La progettazione logica `e simile a quella del data mart per l’analisi degli ordini. La chiave primaria della tabella dei fatti `e composta dai campi NumeroFattura e Articolo FK per garantire l’univocit`a a livello di singola riga di documento.
Figura 3.6: Schema logico del data mart per l’analisi delle fatture.
3.4
Processo Richiesta Nuovi Fornitori
Vengono qui specificati i requisiti di analisi per le richieste di intruduzione di nuo-vi fornitori dell’azienda. Questo tipo di analisi serve per monitorare il numero di fornitori e per cercare di evitare: possibili clientelismi, la perdita di capacit`a di acquisto su scala (solitamente maggiore `e l’ordine, minore `e il prezzo unitario della merce) e relazioni con fornitori non affidabili (la capacit`a di instaurare rap-porti commerciali di lungo periodo con fornitori affidabili e qualificati pu`o dare vantaggio competitivo rispetto la concorrenza).
44 CAPITOLO 3. SPECIFICA DEI REQUISITI 3.4.1 Specifica dei requisiti di analisi
Analisi richieste nuovi fornitori N Requisito di analisi Dimensioni Metriche Misure 1 Numero richieste di
in-serimento, di modifi-ca, di trasformazione e totali di nuovi fornitori.
Data (Anno, Mese), TipoRichiesta # Richieste, # Richieste inserimento, # Richieste modifica, # Richieste trasformazio-ne
-Fatto (richieste nuovi fornitori) Descrizione Dimensioni Misure
Il fatto rappresenta la richiesta di inserimento in anagrafica di un nuovo fornitore
Data, TipoRichiesta
-Dimensioni (richieste nuovi fornitori) Nome Descrizione Granularit`a Degenere Data Dimensione temporale Giorno No TipoRichiesta Anagrafica delle tipologie di
richie-ste di inserimento nuovi fornitori
Tipologia No
TipoRichiesta Attributo Descrizione Esempio
Valore CodiceTipoRichiesta Codice del tipo di richiesta 1
DescrizioneTipoRichiesta Descrizione del tipo di richiesta Inserimento nuovo fornitore
Cardinalit`a: 4
3.4.2 Progettazione Concettuale
Per questo tipo di analisi non sono necessarie misure, il fatto rappresenta la richie-sta di inserimento, da parte un dipendente, di un nuovo fornitore nell’anagrafica fornitori. Quello che si richiede di analizzare quindi `e il numero di richieste di nuovi fornitori, per fare ci`o `e sufficiente contare le righe della tabella dei fatti, il modello quindi non possiede misure. La dimensione di analisi TipoRichiesta con-sente di “spaccare” il dato per: “Inserimento Nuovo Fornitore”, “Trasformazioni Cliente in Fornitore” e “Modifica Fornitore”.
3.4. PROCESSO RICHIESTA NUOVI FORNITORI 45
Figura 3.7: Schema concettuale del data mart per l’analisi numerica delle richieste di nuovi fornitori.
3.4.3 Progettazione Logica
In questa progettazione logica non `e prevista la chiave primaria nella tabella dei fatti dal momento che i campi TipoRichiesta e Data insieme non garantiscono l’u-nivocit`a del fatto e la creazione di un campo chiave ad-hoc non avrebbe molta utilit`a sia dal punto di vista delle analisi e che delle performance. Inoltre sono stati creati indici di tipo Bitmap sia sulla chiave surrogata della tabella dimensionale TipoRichiesta che sulle chiavi esterne della tabella dei fatti (TipoRichiesta FK e Data FK).
Figura 3.8: Schema logico del data mart per l’analisi numerica delle richieste di nuovi fornitori.
46 CAPITOLO 3. SPECIFICA DEI REQUISITI
3.5
Riepilogo delle misure e delle dimensioni
Nelle due tabelle che seguono viene riassunto il modello relazionale a costellazione per l’analisi della spesa descrivendo per tutte le tabelle dei fatti del progetto le dimensioni e le misure coinvolte.
Riepilogo delle misure Misura Fornitori Ordini Ricevimenti Fatture Importo riga OdA X
Importo riga fattura X
Tempo di attraversamento X
Mq ricevuti X
Riepilogo delle dimensioni Dimensione Fornitori Ordini Ricevimenti Fatture
Data X X X X Fornitore X X X Articolo X X X Buyer X X X Originatore X Deposito X TipoRichiesta X NumeroRicevimento X NumeroOrdine X Listino X Urgente X NumeroFattura X
3.6
Riassunto
In questo capitolo i requisiti di analisi sono stati tradotti nei costrutti tipici della progettazione di data warehouse: fatti, misure e dimensioni. Dai requisiti sono emersi quattro soggetti di analisi: gli ordini di acquisto, i ricevimenti di merce, le fatture e le richieste di introduzione di nuovi fornitori. Ognuno dei quattro soggetti di analisi `e stato modellato mediante un data mart separato. I modelli concettuali dei data mart sono stati formalizzati graficamente utilizzando la rappresentazione MCF (Multidimensional Fact Model) e successivamente sono stati progettati dal punto di vista relazionale.
Dal momento che i quattro data mart possiedono alcune dimensioni in comune gli schemi relazionali costituiscono uno schema a costellazione, ovvero uno sche-ma con pi`u tabelle dei fatti che condividono le tabelle dimensionali in comune: nell’ultima parte del capitolo lo schema relazionale a costellazione viene riassunto in due tabelle contenenti le relazioni esistenti tra le tabelle dei fatti, le misure e le dimensioni del progetto.
