NOZIONI BASE DI SELF-BI. GETTING STARTED CON POWERPIVOT

23 gennaio 2017

EVIDENZA

PERCHE’  SELF-BI

Nelle recenti trattazioni viene sempre più spesso richiamato il termine Self BI o Self Service BI ad indicare quella parte di Business Intelligence che ha l’obiettivo di ampliare il panorama degli utilizzatori verso soggetti privi delle tradizionali conoscenze e competenze informatiche cui la BI tradizionale generalmente si rivolge.

La Self-Bi viene definita da Gartner come “Self-service business intelligence is defined here as end users designing and deploying their own reports and analyses within an approved and supported architecture and tools portfolio.”1. La definizione proposta trova nella capacità dell’utente di creare report ed effettuare analisi in modo autonomo l’elemento differenziale rispetto alle tradizionali tecniche di Business Intelligence.

A seguire ci si concentrerà in maniera diretta su uno dei principali e più diffusi software di Self-Bi, Powerpivot di Microsoft.

POWERPIVOT

PowerPivot è stato il primo componente di Self BI distribuito da Microsoft e, nella sua prima versione, costituiva un add-in di Microsoft Excel. Oggi, dopo il rilascio del pacchetto Office 2013, PowerPivot è presente in modo nativo nelle versioni di Excel destinate all’utenza business.

La finalità di tale componente, sin dall’origine, è quella di permettere agli utilizzatori di Excel di eseguire complesse analisi di dati senza l’intervento di personale specializzato o consulenti esperti in BI, inserendo così il prodotto in una posizione intermedia tra Excel e una soluzione di BI tradizionale.

Il nome PowerPivot fa intuire come lo strumento sia la naturale evoluzione delle tabelle Pivot, utilizzate dagli utenti esperti di Excel per eseguire analisi basilari sui dati. In realtà PowerPivot integra al proprio interno un vero e proprio motore di database in-memory che organizza dati, crea relazioni e fornisce un modo semplice e rapido per analizzare le informazioni, attraverso l’utilizzo di una tradizionale tabella Pivot.

Le principali caratteristiche di PowerPivot sono:

  • organizzare diverse tabelle attraverso relazioni senza necessità di utilizzare complesse funzioni di ricerca tra una tabella e un’altra;
  • presenza di un database in-memory che può gestire una elevata quantità di dati senza le normali limitazioni di righe e colonne presenti in Excel;
  • un linguaggio di programmazione definito Data Analysis Expressions (DAX) che permette di elaborare funzioni ed espressioni, anche complesse, sui dati importati nel database;
  • capacità di acquisire dati da fonti diverse, quali data base relazionali o semplici fogli elettronici e di testo;
  • efficiente compressione dei dati caricati.
  • velocità di elaborazione dei dati in-memory particolarmente performante.

Dopo aver illustrato un breve case study circa un progetto di implementazione di un sistema di Self-Bi, ci si concentrerà su quello che è il cuore di PowerPivot, il linguaggio DAX.

IL PROGETTO DI SELF BI DI UNA PMI VENETA

L’azienda oggetto di studio è situata in Veneto e l’attività prevalente è costituita dalla commercializzazione di prodotti ortofrutticoli, acquisiti per la maggior parte da produttori locali.

Vengono inoltre svolte, in misura residuale, delle lavorazioni sui prodotti acquistati, le quali consistono nel cambio delle confezioni in funzione delle richieste della clientela (rilavorazioni). Trattandosi di beni deperibili la rotazione del magazzino è particolarmente elevata e gli acquisti di merci vengono suddivisi in lotti per garantirne la tracciabilità.

Nel corso del 2011, complice l’aumento dei volumi di vendita e delle dimensioni aziendali, è stato introdotto un sistema informativo integrato in sostituzione del precedente gestionale, il quale presentava forti limitazioni di personalizzazione e di gestione dei lotti. La scelta fu stata di affidarsi alla soluzione ERP di Microsoft destinata alla PMI: Microsoft Dynamics NAV.

Con l’implementazione del sistema ERP, l’azienda è riuscita a gestire i processi aziendali in modo integrato, a partire dall’ordine di acquisto sino all’incasso della fattura di vendita, avendo costantemente monitorato il flusso fisico della merce attraverso la gestione non solo dei lotti, ma del singolo collo, grazie ad una efficiente governo del magazzino, basato su codici a barre.

Gli evidenti miglioramenti nella gestione e organizzazione dell’azienda hanno però interessato solo in modo marginale il processo di informazione verso l’alta direzione.

I vantaggi connessi al nuovo sistema non hanno tuttavia dispiegato effetti sul processo di reporting verso l’alta direzione che è rimasto pressoché immutato. Con cadenza mensile, l’ufficio amministrativo predisponeva dei riepiloghi degli andamenti economici del mese su un foglio di lavoro creato con Microsoft Excel.

Per l’aggiornamento dei valori veniva eseguita una stampa della situazione contabile dei movimenti rilevati nel mese e riportata su un foglio di calcolo. I valori venivano quindi raggruppati e rielaborati per ottenere una sintesi delle principali voci di costo e di ricavo, nonché, attraverso opportune rettifiche, una situazione che rispecchiasse i valori di competenza del mese. L’elaborato processo di reporting, basato su strumenti non idonei alle dimensioni aziendali e la completa mancanza di qualsiasi automazione, generava forti ritardi nella consegna dei report e, nella maggior parte delle volte, una scarsa attendibilità dei valori presentati.

OBIETTIVI E ORGANIZZAZIONE DEL PROGETTO

Il progetto di Self BI nasce dunque dall’esigenza dell’alta direzione di avere report sintetici sull’andamento economico dell’azienda, nonché di introdurre un processo di budget che si sviluppa su un orizzonte temporale di un anno. Contestualmente si voleva poter analizzare l’andamento economico secondo un’ottica di suddivisione per centro di costo.

La richiesta della direzione era di migliorare l’attuale processo di reporting senza, o comunque in misura limitata, coinvolgimento di consulenze esterne specializzate. Il progetto è stato dunque organizzato tenendo in considerazione le dimensioni aziendali, gli strumenti a disposizione e le competenze presenti in azienda secondo un piano condiviso che prevedeva le seguenti fasi:

  • mappatura dei principali processi aziendali e definizione dei centri di costo;
  • definizione di un processo di budget;
  • condivisione con la direzione di una riclassificazione di conto economico con evidenza della marginalità di vendita secondo più configurazioni di costo;
  • scelta dello strumento tecnologico;
  • predisposizione della reportistica.

Il progetto si è sviluppato in una arco temporale di circa sei mesi ed ha interessato prevalentemente il reparto amministrativo con periodico coinvolgimento della direzione aziendale soprattutto nelle fasi di valutazione dei prototipi di reporting e di definizione della struttura di conto economico riclassificato e dei centri di costo.

SOLUZIONE AL PROBLEMA DELLA DATA DI COMPETENZA

La prima attività è stata quella di individuare le origini dati e di verificarne la completezza rispetto agli obiettivi.

Durante l’analisi e verifica delle tabelle del sistema ERP è emersa la mancanza di un dato essenziale per la successiva attività di analisi: la data di competenza.

Nei riepiloghi mensili predisposti in Excel i valori di contabilità generale venivano rettificati per ottenere il risultato economico di competenza del mese. Tale rettifica si rendeva necessaria in quanto le stampe venivano prodotte in funzione della data di registrazione e, come noto, per addivenire ad un valore di competenza, è necessario perlomeno:

  • sospendere i costi e i ricavi di competenza di periodi successivi;
  • elidere i costi e i ricavi rilevati nel periodo ma di competenza di periodi precedenti;
  • inserire costi e ricavi che non hanno ancora avuto manifestazione numeraria;
  • imputare i costi relativi a beni strumentali secondo un piano di ammortamento legato allo sfruttamento tecnico economico dei beni.

Al vero la complessità e la numerosità di alcune delle operazioni mal si conciliavano con le tempistiche necessarie per soddisfare la richiesta della direzione di avere un report con cadenza mensile.

Si sono pertanto adottate delle semplificazioni per le quali alcune rettifiche non venivano eseguite ovvero erano stimate in modo forfettario e non puntuale. La scelta di inserire tali valori solamente nel foglio Excel (data entry) è dettata dal fatto che l’eventuale rilevazione in contabilità generale, oltre a necessitare di più tempo, costringeva l’ufficio ad eseguire delle scritture di storno con l’inizio del periodo successivo.

Per risolvere questa problematica è intervenuto il rivenditore che ha introdotto due nuove implementazioni nell’ERP:

  • aggiunta della data di competenza alle registrazioni di contabilità generale e nelle rilevazione delle fatture di vendita e di acquisto;
  • sviluppo di una funzione automatica di rilevazione di scritture contabili simulate per gli ordini di acquisto e di vendita.

Con l’introduzione della data di competenza nelle rilevazioni di contabilità generale è quindi possibile prescindere dalla data di registrazione e del documento, andando ad imputare correttamente il costo o il ricavo nel periodo cui riferisce.

La seconda implementazione invece è finalizzata a rilevare automaticamente nel periodo di competenza gli ordini di acquisto e di vendita evasi per i quali non erano ancora pervenute le fatture di acquisto o non erano ancora state emesse le fatture di vendita.

Si verificava spesso, soprattutto per fornitori nazionali, che le fatture pervenissero con molto ritardo, pertanto risultava particolarmente difficile stimare correttamente i costi di competenza.

La modifica al sistema fa sì che, nel momento di evasione di un ordine di vendita o all’arrivo della merce relativa ad un ordine di acquisto, venga rilevata una scrittura simulata per l’ammontare del costo o del ricavo, con data di competenza uguale alla data di spedizione o di arrivo della merce.

Al momento di emissione della fattura di vendita o di registrazione della fattura acquisto il sistema procede autonomamente a stornare la scrittura simulata che invece è sostituita dalla scrittura di contabilità generale con uguale data di competenza. Tutte queste operazioni vengono archiviate su una tabella separata rispetto a quella di contabilità generale, senza quindi interferire con le rilevazioni prescritte dalla normativa civilistica e fiscale.

La tabella delle scritture simulate è stata quindi utilizzata anche per le altre transazioni non automatiche, quali:

  • quote di ammortamento dei beni materiali e immateriali;
  • storno parziale di costi con competenza di più periodi (ad esempio per le assicurazioni);
  • rilevazione della quota di costi di competenza di periodi precedenti;
  • rilevazione delle rimanenze iniziali e finali di merci.

DEFINIZIONE DELLA STRUTTURA DI CONTO ECONOMICO RICLASSIFICATO

In aderenza agli obiettivi del progetto sono state popolate le tabelle del budget, dei centri di costo e della riclassifica del conto economico.

Il sistema ERP prevede la possibilità di generare più budget economici, ognuno dei quali può essere gestito inserendo i valori sia per le voci del piano dei conti di contabilità generale sia per centro di costo. Non essendo ancora utilizzati i centri di costo l’inserimento è stato limitato alle diverse voci di piano dei conti.

Per l’inserimento del piano dei centri di costo e della riclassifica di conto economico è stata invece utilizzata una specifica tabella del sistema ERP denominata “dimensioni”. Anche in quest’ambito c’è stato un successivo intervento del fornitore del software che ha introdotto, per le fatture di acquisto di merci e di servizi di trasporto, nonché per le fatture di vendita, degli automatismi che hanno permesso l’inserimento automatico dei centri nelle rilevazioni di contabilità generale.

La riclassifica del conto economico, condivisa con l’alta direzione, è stata sviluppata su due livelli di dettaglio con quattro risultati intermedi:

  • Margine lordo commerciale: margine di vendita considerando esclusivamente il costo di acquisto delle merci.
  • Margine netto commerciale: margine di vendita considerando anche i costi accessori e diretti.
  • Margine operativo lordo: risultato dell’attività operativa al netto degli ammortamenti e dei noleggi finanziari (leasing).
  • Reddito operativo: evidenzia il risultato operativo escludendo la gestione finanziaria, straordinaria e le imposte.

Nella tabella a seguire si riporta la riclassifica di conto economico che è stata quindi impostata nel sistema ERP.

RICLASSIFICA DI CONTO ECONOMICO

IMPLEMENTAZIONE DELLA CONTABILITA’ ANALITICA

A seguire è stato introdotto il processo di contabilità analitica con l’introduzione dei centri di costo. L’obiettivo della direzione era quello di avere non solo una situazione contabile con suddivisione dei costi per natura, tipica della struttura di conto economico civilistico, ma anche una evidenza dei costi di ogni reparto aziendale.

I centri di costo sono stati quindi definiti con una logica molto snella in funzione del reparto al quale ciascun costo riferisce. In aggiunta sono stati introdotti dei centri relativi ai costi generali e un centro di costo residuale dove gli operatori potevano allocare un costo in attesa di valutarne la corretta allocazione (c.d. centro bidone per ribaltamento).

Nella seguente tabella sono riepilogati i centri di costo inseriti a sistema.

CENTRI DI COSTO

SCELTA DELLO STRUMENTO TECNOLOGICO

La scelta di utilizzare la piattaforma di Self BI di Microsoft è dipesa da diversi fattori. Innanzitutto i componenti della suite sono degli add-in di Microsoft Excel liberamente scaricabili (per i possessori delle versioni professional), pertanto non sono richiesti ulteriori investimenti in termini di applicativi software. Inoltre la possibilità di continuare ad utilizzare il foglio di calcolo Excel, ampliato con le nuove funzionalità, garantisce minori tempi di formazione del personale, essendo l’interfaccia già familiare e le principali funzioni già conosciute. Infine gioca un ruolo fondamentale la facilità di costruzione e modifica dei report e, di conseguenza, il tempo di implementazione particolarmente ridotto.

La velocità di sviluppo è legata alla forte integrazione tra il sistema informativo ed i componenti della suite di Self BI. Il sistema ERP presente in azienda, Microsoft Dynamics NAV, si basa su un database SQL Server 2008, pertanto la connessione alla base dati tramite PowerPivot non ha richiesto driver aggiuntivi ed è stata immediata non appena acquisite le credenziali di accesso al server.

COSTRUZIONE DEL MODELLO DATI IN POWERPIVOT

Dopo l’analisi preliminare, modifica e alimentazione del sistema di ERP si è passati alla fase di connessione al database del sistema e di creazione del modello dati in PowerPivot.

Per la connessione a SQL Server 2008 dove sono ospitati i dati di Microsoft Dynamics Nav, si è preferito di utilizzare direttamente PowerPivot, senza sfruttare il componente PowerQuery.

Le motivazioni di tale scelta erano prevalentemente due: in primo luogo al momento dell’inizio del progetto il componente era ancora in versione preview (con il nome Data Explorer) e non garantiva sufficiente stabilità per l’utilizzo in un ambiente di produzione, in secondo luogo la connessione all’origine dati, essendo sempre in ambiente Microsoft, era facilmente configurabile già con PowerPivot.

I primi dati acquisiti sono quelli della contabilità generale. Per evitare di appesantire il modello, si è deciso di non importare tutte le scritture presenti nella tabella ma di filtrare solamente le operazioni rilevanti per le finalità del progetto.

Per l’applicazione dei filtri si è preferito utilizzare la funzionalità di PowerPivot di creazione visuale di un’istruzione SQL. In questa fase sono state utilizzate le tabelle di contabilità generale [G_L ENTRY] e del piano dei conti [G_L ACCOUNT], messe in relazione attraverso un’istruzione SQL di Inner Join sulla chiave esterna del codice del conto contabile. L’analisi dei dati ha permesso di individuare le seguenti regole di esclusione:

Filtri di esclusione record di contabilità generale

Terminata l’importazione della tabella di contabilità generale è stato applicato il medesimo modello per l’acquisizione delle scritture simulate, ovvero quelle rilevazioni che non confluiscono nella giornale di contabilità, così come richiesto dalle normative civili e fiscali, ma che sono periodicamente inserite dall’amministrazione per rettificare i movimenti contabili secondo una logica di competenza. Anche in questo caso è stata definita una query SQL che permette di acquisire solamente i movimenti di conto economico.

L’ultima tabella, cosiddetta dei “fatti” è quella relativa ai dati di Budget per l’esercizio successivo. A differenza delle due importazioni precedenti, in questo caso non erano necessari particolari filtri né tantomeno eseguire relazioni.

Si è preferito dunque utilizzare la procedura guidata di selezione e applicazione di filtri nelle tabelle di origine. Attraverso questa modalità, la tabella di origine si presenta come qualsiasi tabella di un foglio di calcolo e l’applicazione dei filtri avviene con le stesse modalità di una comune tabella Excel. Terminata l’operazione è sufficiente confermare affinché il motore di PowerPivot esegua l’operazione di selezione senza alcuna necessità di istruzioni SQL.

Infine si passa all’importazione delle tabelle delle dimensioni.

La prima dimensione è il piano dei conti. Questa tabella sarà relazionata con tutte e tre le tabelle dei fatti e contiene gli attributi di ogni conto contabile.

Anche in questo caso sono stati importati solamente i conti riferibili ad elementi economici, escludendo quelli patrimoniali e i conti d’ordine. Il filtro è stato applicato sulla colonna [INCOME_BALANCE] per il valore “0”, il quale rappresenta i conti di tipo economico. Inoltre la colonna [DIRECT POSTING], che indica se il conto è movimentabile (valore “0”) ovvero di riepilogo (valore “1”), è stata filtrata per il valore 1.

Le altre dimensioni importate riguardano la decodifica dei centri di costo e le riclassificazioni di conto economico. Queste due tabelle sono archiviate nell’origine dati in un’unica tabella denominata [DIMENSION VALUE] nella quale la colonna [DIMENSION CODE] presenta valori differenti a seconda della dimensione.

In particolare la colonna assume valore “BUDGET” per la riclassifica di conto economico e “CDC” per i centri di costo.

I dati dei clienti e fornitori, al contrario, erano suddivisi in più tabelle. Nelle rilevazioni di contabilità generale e nelle scritture simulate era presente il codice del cliente, del fornitore o della banca nel campo [SOURCE NO_].

Il modello dati di PowerPivot non permette tuttavia di creare relazioni multiple sullo stesso campo. Si è dunque scelto di eseguire un’istruzione di SQL di unione di più tabelle. In fase di elaborazione, per ogni record, viene assegnata la tipologia di anagrafica che può assumere i seguenti valori: Fornitore, Cliente o Banca.

Terminata la fase di importazione dei dati si è proceduto a individuare e creare le relazioni tra le diverse tabelle, ed in particolare tra le tabelle dei fatti con le rispettive dimensioni, attraverso l’individuazione e l’utilizzo di chiavi univoche FK (Foreign Key).

Nella successiva figura sono raffigurate le relazioni create nel modello dati.

Relazioni nel modello dati di PowerPivot

Il modello dati permetteva dunque di estrarre autonomamente dal sistema ERP i dati di contabilità generale e di budget alimentando le tabelle di PowerPivot, nonché di mettere in relazione le tabelle dei fatti con le dimensioni.

Prima della creazione dei report alimentati dal modello dati di PowerPivot è stata definita con la direzione la struttura dei diversi report di analisi, costruendo dei prototipi su fogli di calcolo.

La struttura di partenza è quella che veniva già utilizzata dall’ufficio amministrativo, con le modifiche secondo la riclassificazione di conto economico e i centri di costo definiti in precedenza, nonché con l’introduzione di nuovi valori ritenuti utili per comprendere l’andamento economico aziendale.

In particolare, la direzione voleva in un unico prospetto per ogni voci di riclassificazione di conto economico e per ogni centro di costo i seguenti valori:

  • Il consuntivo rilevato in uno specifico periodo;
  • il consuntivo nello stesso periodo dell’anno precedente;
  • il valore budget di periodo;
  • il valore di budget totale dell’anno;
  • l’importo ‘a finire’ per raggiungere il budget dell’anno.

Per la costruzione dei report, destinati successivamente ad essere stampati, si è scelto di utilizzare le tabelle Pivot del foglio elettronico. La necessità di inserire in un’unica tabella valori riferiti a periodi temporali differenti, nonché di determinare lo scostamento tra due valori, è stato risolto mediante la creazione di campi calcolati.

I campi calcolati in PowerPivot vengono realizzati eseguendo delle istruzioni in linguaggio DAX. Come si è detto in precedenza tale linguaggio è molto simile alle formule del normale foglio Excel e permette di eseguire dalle più semplici formule matematiche, come la differenza tra due valori, sino alle più complesse istruzioni che modificano il contesto di calcolo nella tabella Pivot, come la variazione del periodo temporale dei valori considerati.

I REPORT DI ANALISI

La costruzione dei report di analisi è stata sviluppata seguendo un processo suddiviso in due fasi.

Dopo l’esame preliminare dei report in precedenza realizzati dall’ufficio amministrativo sono state definite le strutture di conto economico riclassificato e dei centri di costo.

Terminata la fase di realizzazione e di condivisione dei prototipi si è passati alla creazione dei report definitivi.

Dal confronto con la direzione è stato deciso di realizzare quattro differenti prospetti che andavano a formare un fascicolo da presentare mensilmente all’amministratore delegato entro il decimo giorno di ogni mese.

Il primo report riportava, sia informa sintetica (solo i primi due livelli di riclassificazione) che analitica (tutti i livelli di riclassificazione), il risultato economico del periodo selezionato nonché del periodo precedente.

I due valori, espressi anche in percentuale rispetto ai ricavi di vendita, vengono raffrontati e viene esplicitato l’incremento o la riduzione, in valore assoluto, di ogni voce di riclassifica.

Nell’evidenza dello scostamento è stato inserto un KPI che indica graficamente se il valore è aumentato o diminuito, attraverso una freccia verde rivolta verso l’alto o una freccia rossa rivolta verso il basso.

E’ inoltre stato inserito il valore di budget per il medesimo periodo temporale e, come per i valori dell’anno precedente, lo scostamento rispetto al consuntivo rilevato nel periodo.

Da ultimo è stato inserito il valore di budget dell’intero anno, prescindendo dunque dal periodo temporale selezionato, e l’ammontare necessario per raggiungerlo rispetto ai dati consuntivi (erosione budget).

Quest’ultimo indicato viene espresso anche in forma percentuale e attraverso un KPI grafico rappresentato da una barra nella stessa cella dove è stata inserita la percentuale.

Report di conto economico riclassificato

Il secondo report invece sposta il focus sulla contabilità analitica.

Report di analisi centri di costo

Il terzo e il quarto report che andranno a formare il fascicolo per la direzione evidenziano solamente i valori consuntivi, espressi sia in valore assoluto che in percentuale rispetto ai ricavi di vendita, suddivisi in colonna per i mesi dell’anno. I due report si differenziano per la diversa configurazione di conto economico: il primo sulla base della riclassifica per natura, il secondo suddiviso per centri di costo.

CONCLUSIONI SUL PROGETTO DI SELF BI 

Dall’esame del caso di implementazione del progetto si possono trarre diverse considerazioni su benefici e limiti della Self BI, sia sotto l’aspetto tecnico-operativo che organizzativo.

Dal punto di vista tecnico operativo i vantaggi dell’adozione della sono:

  • Costi ridotti: le piattaforme di Self BI si contraddistinguono rispetto ai classici sistemi di BI per il costo particolarmente ridotto se non nullo. Nel caso aziendale oggetto di studio è stata utilizzata la piattaforma di Self BI di Microsoft che si presenta come un add-in gratuito del diffuso foglio elettronico della stessa casa.
  • Facilità di utilizzo: la piattaforma di Self BI è stata sviluppata con un approccio user-friendly, dove le attività di importazione ed elaborazione dei dati si possono eseguire con procedure guidate e prevalentemente senza la necessità di conoscere complicati linguaggi di programmazione. Anche qualora si manifestasse la necessità di eseguire dei calcoli più elaborati, il linguaggio DAX ha sostanzialmente la stessa forma delle già ampiamente conosciute formule di Excel.
  • Condivisione dei report di analisi: i diversi strumenti della piattaforma, in quanto add-in di Microsoft Excel, completano e aumentano le potenzialità del classico foglio di calcolo. Il modello dati ed i report di analisi sono quindi salvati all’interno dello stesso file di Excel. Per la condivisione dei report è sufficiente trasferire il file e con esso verrà trasferito l’intero modello dati, con le istruzioni di importazione e aggiornamento dei dati, nonché i report generati.

Dall’analisi del caso aziendale sono emersi tuttavia alcuni limiti della piattaforma, e in particolare:

  • Mancanza di una funzione di aggiornamento automatico dei dati. I tradizionali sistemi di Business Intelligence prevedono la possibilità di pianificare attività di importazione dati in modo autonomo ad orari prestabiliti. Lo strumento di Self BI di Microsoft ne è invece sprovvisto.
  • Limiti nella gestione delle relazioni tra i dati. PowerPivot non permette la creazione di relazioni diverse da uno-ad-uno. Per quanto non siano così diffuse, la mancanza della possibilità di definire relazioni molti-a-molti o uno-a-molti, può rappresentare un forte elemento invalidante dell’intero modello dati.
  • Utilizzo di database in-memory: La scelta di utilizzare una base dati che viene interamente caricata nella memoria volatile dell’elaboratore presenta il vantaggio di poter eseguire velocemente le operazioni di elaborazione, ma richiede l’utilizzo di client con una discreta quantità di memoria RAM. Gli strumenti di BI sono solitamente costruiti secondo una logica client-server, per la quale i calcoli vengono eseguiti dal server e i client si limitano ad esporre i risultati delle elaborazioni.

CENNI DI DAX

DAX è una raccolta di funzioni, operatori e costanti utilizzabili in una formula, o espressione, per il calcolo o la restituzione di uno o più valori.

Più semplicemente, DAX consente di creare nuove informazioni da dati già disponibili nel modello in uso (fonte: support.office).

Un’espressione DAX può ritornare sia un valore scalare che una tabella.

Il DAX può essere utilizzato per definire colonne calcolate e misure.

Una colonna calcolata è un insieme di dati valutati per ogni riga della tabella del database:

GROSS MARGIN:=Sales[sales_amount]-Sales[product_cost]

Le misure, invece, sono espressioni DAX valutate in un contest fatto costituito da un set specific di righe di dati.

TOTAL SALES:=SUM(Sales[sales_amount])

Trattasi di un ‘campo calcolato’ che nella fattispecie presentata definisce il totale delle vendite.

Le principali funzioni DAX per iniziare a creare i primi report con PowerPivot sono SUM, CALCULATE, SAMEPERIODLASTYEAR.

FUNZIONE DI SUM

Somma tutti i valori di una colonna di una specifica tabella.

Sintassi: SUM(<column>)

Esempio: SUM[sales_amount] à restituisce il totale del valore di vendita.

Il campo inserito in una tabella pivot evidenzierà le vendite per ciascuna dimensione di analisi. Lo stesso comportamento si avrebbe trascinando il campo [sales_amount] all’interno di una tabella pivot, senza dover scrivere una misura. Non si tratta di un doppione, in quanto la formula SUM è utilizzata in contesti più complessi, ad esempio all’interno di CALCULATE.

SUM

 

FUNZIONE CALCULATE

Valuta un’espressione in un contesto modificato dai filtri specificati.

Sintassi: CALCULATE(<expression>,<filter1>,<filter2>…)

Esempio: VALORE BUDGET TOT:= CALCULATE(SUM([Valore BDG]);ALL(Tabella_Data_Filtro[data]) à restituisce il valore totale del Budget, indipendentemente dal periodo selezionato.

Il sistema andrà a calcolare (CALCULATE) la somma (SUM) a livello di colonna del fatturato di budget (composto nel data base dalle righe delle singole vendite), andando ad escludere (ALL) tutti i filtri temporali, ma mantenendo i rimanenti.

La colonna VALORE BUDGET TOT pertanto restituirà l’ammontare annuo previsto a budget, senza risentire delle selezioni temporali. Questa funzione è molto utile per calcolare le % di completamento a finire.

CALCULATE

FUNZIONE SAMEPERIODLASTYEAR

Restituisce una tabella contenente un set di dati riferiti ad un anno indietro nel tempo rispetto alle date specificate nella colonna dates del contesto corrente.

Sintassi: SAMEPERIODLASTYEAR(<dates>)

Esempio: Sales LY:=CALCULATE(SUM([Sales_Amount]);SAMEPERIODLASTYEAR(Tabella_Data_Filtro[data]))

 

Tuttavia, le formule di Time Intelligence, per lavorare correttamente, necessitano di avere un set di date contigue senza interruzioni. Ecco che risulta indispensabile utilizzare una tabella date strutturata senza interruzioni di valori. Tale tabella verrà quindi agganciata alle altre e sarà poi utilizzata in tutti i filtri temporali (Timeline) dei report.

TABELLA RIEPILOGATIVE FORMULE UTILIZZATE

RIEPILOGO FORMULE

ARTICOLO CONTENUTO IN “SFC – Rivista di Strategia Finanza e Controllo”  N° 10 –
Sfoglia la Rivista

  1. 1.http://www.gartner.com/it-glossary/self-service-business-intelligence.