Il progetto è finito, la dashboard funziona, i grafici sono puliti, i colori sono quelli aziendali. Prima riunione di presentazione, tutti soddisfatti.

Poi il direttore commerciale fa una domanda semplice: “questo calo sul cliente Bianchi, riguarda tutte le famiglie di prodotto o solo una?”

Silenzio. La dashboard non sa rispondere. Non perché manchi un grafico, ma perché il dato non è mai stato caricato a quel livello di dettaglio. Per rispondere bisogna tornare all’estrazione, rifare il caricamento, ricostruire le relazioni. Due settimane di lavoro per una domanda che in azienda si fa tutti i mesi.

Questa scena non è un incidente. È il modo standard in cui falliscono i progetti di business intelligence nelle PMI, e il motivo è quasi sempre tecnico, non organizzativo. Il modello dati sotto la dashboard è stato costruito male, o non è stato costruito affatto.

La granularità, l’unica decisione che non si può correggere dopo

C’è una regola che vale in tutti i progetti di dati e non ha eccezioni: si può sempre sommare, non si può mai scomporre.

Se carichi il fatturato mensile per cliente ottieni una tabella leggera, veloce, elegante. E completamente inutile alla seconda domanda che ti fanno, perché dentro quel numero non c’è più traccia di quale articolo, quale agente, quale ordine, quale giorno.

La granularità corretta, per quasi tutte le PMI, è la riga di documento: la riga di fattura, la riga d’ordine, il movimento di magazzino, la dichiarazione di produzione. Con la sua data effettiva, il suo codice articolo, il suo codice cliente, la sua quantità.

L’obiezione che arriva sempre è il volume. Un’azienda che emette centomila righe di fattura all’anno pensa di avere un problema di dimensioni. Non ce l’ha. Quel problema esisteva con i fogli di calcolo, non esiste con i motori analitici di oggi, che gestiscono milioni di righe occupando poche decine di megabyte.

Il vero problema non è mai lo spazio. È aver deciso troppo presto quali domande l’azienda avrebbe fatto.

Le anagrafiche, il punto dove i progetti muoiono davvero

Le tabelle degli eventi contengono i numeri. Le anagrafiche contengono il modo in cui quei numeri si leggono. Sono la parte meno interessante del progetto e quella che ne determina la sopravvivenza.

Nelle PMI il quadro tipico è questo: lo stesso cliente esiste con tre codici diversi tra sede, filiale e gruppo, il campo famiglia di prodotto è compilato al 60%, esistono due articoli identici nati in momenti diversi, la classificazione dei centri di costo risale a una riorganizzazione di sei anni fa.

Finché i dati restano nel gestionale il problema si tollera, perché ogni persona sa correggere a mente. Quando i dati finiscono in una dashboard il problema diventa visibile e distruttivo, perché il numero sbagliato viene proiettato in riunione.

Tre cose vanno decise prima di scrivere una riga di codice.

La prima è chi possiede ogni anagrafica. Non una funzione, una persona. Chi può creare un nuovo codice cliente, chi deve compilare la famiglia di prodotto, chi verifica che sia stato fatto.

La seconda sono le gerarchie. Cliente, gruppo, canale, area, agente. Articolo, famiglia, linea, marchio. Se questi livelli non esistono in modo pulito, ogni analisi si ferma al singolo codice e nessuno riesce a leggere l’insieme.

La terza è la storicizzazione, ed è quella che nessuno affronta. Se l’agente Bianchi passa dal Nord al Centro, le vendite dell’anno scorso restano attribuite al Nord o si spostano con lui? Entrambe le risposte sono legittime, ma vanno scelte una volta sola e scritte da qualche parte. Se la scelta non viene fatta, ogni report costruito in momenti diversi darà numeri diversi e nessuno saprà spiegare perché.

Le relazioni, dove nasce il numero che non torna

In un modello dati esistono due famiglie di tabelle: quelle che registrano eventi con dei numeri sopra, vendite, acquisti, produzione, movimenti di magazzino, e quelle che descrivono, clienti, articoli, agenti, centri di costo, calendario.

Lo schema che regge nel tempo è sempre lo stesso: le tabelle descrittive stanno intorno, le tabelle degli eventi stanno al centro, e ogni collegamento avviene attraverso un codice, mai attraverso una descrizione.
Gli errori ricorrenti sono quattro, e producono tutti lo stesso sintomo, cioè numeri che non tornano.

Collegare direttamente due tabelle di eventi, tipicamente ordini e fatture, genera duplicazioni e gonfia il fatturato senza che nessuno se ne accorga subito.

Costruire relazioni molti a molti e poi farle funzionare con un artificio significa creare un modello in cui nessuno sa più cosa filtra cosa.
Collegare le tabelle su campi di testo invece che su codici significa accettare che “ROSSI SRL” e “Rossi S.r.l.” siano due clienti diversi, perché per un computer lo sono.

Non avere una tabella calendario unica, infine, rende impossibile confrontare vendite e acquisti sullo stesso periodo. Quella tabella deve contenere anche settimane, giorni lavorativi, esercizio fiscale e chiusure di stabilimento, altrimenti il confronto tra agosto e settembre è privo di senso.

Il test in tre domande

Per capire se un modello regge, bastano tre domande.

La prima: riesco a rispondere a una domanda che non era prevista quando l’ho costruito? Se ogni nuova esigenza richiede una nuova estrazione, quello non è un modello, è un report travestito.

La seconda: lo stesso numero, calcolato in due punti diversi della dashboard, dà lo stesso risultato? Se no, il problema è nelle relazioni, non nelle formule.

La terza: se domani cambia il gestionale, quanto del lavoro sopravvive? In un modello ben costruito sopravvive quasi tutto, perché cambia solo il primo strato di estrazione.

Perché il tempo speso qui vale il triplo

In un progetto di business intelligence fatto bene, la ripartizione del tempo è più o meno questa: dal 60 al 70% su estrazione, granularità, anagrafiche e relazioni, un 20% sulle regole di calcolo, un 10% sulla parte visiva.

Quando la proporzione si inverte si ottiene una dashboard bellissima che dura tre mesi.

Rifare le fondamenta dopo costa tre o quattro volte tanto, perché nel frattempo sopra ci sono state costruite misure, report, abitudini e, soprattutto, decisioni.

Una dashboard non è un oggetto grafico. È la punta visibile di un modello. Se il modello è solido, la grafica si cambia in un pomeriggio. Se il modello è sbagliato, nessuna grafica lo salva.