Di solito non ha ragione nessuno dei due, perché a nessuno dei due è mai stato detto cosa significa “giusto”. Quando una dashboard e la pipeline che la alimenta non coincidono, la causa è quasi sempre una definizione mancante, oppure un passaggio che cambia il numero senza che nessuno se ne accorga. La trovi seguendo un solo numero, per un periodo breve, attraverso ogni livello, finché le due cifre si separano. La risolvi con una definizione scritta e un test automatico che la verifica. Serve una definizione più un test, non un nuovo strumento.
Sembra un dettaglio, e non lo è. Quando le persone smettono di fidarsi di un numero, se lo ricostruiscono nel proprio foglio Excel, e i numeri diventano tre. Il costo vero sono tutte le riunioni che iniziano con “ma questa è quale versione?”.
Prima verifica che misurino la stessa cosa
Prima di fare debug, chiedi a entrambe le parti di spiegare in una frase cosa conta il loro numero. Spesso scopri che il problema è di nome. Il “fatturato” dell’amministrazione è l’importo fatturato al netto dei resi, per data fattura. Il “fatturato” della dashboard è il valore dell’ordine al checkout, compresi gli ordini poi annullati.
Possono essere corretti entrambi. Rispondono a domande diverse. Se è questo il caso, dai loro due nomi diversi e decidi quale guarda la direzione. Non serve nessun intervento tecnico.
Se invece dovrebbero davvero essere lo stesso numero, passa alla ricostruzione.
Come seguire un numero dalla fonte al grafico
Scegli una metrica e un periodo breve. Un solo giorno è l’ideale. Un mese nasconde troppo.
Poi ricalcola il numero a ogni livello che attraversa:
- Il sistema di origine. Il database dell’applicazione, il gestionale, il CRM. Quello che l’azienda considera il registro di ciò che è successo.
- I dati grezzi nel data warehouse o nel database di analisi, così come li ha caricati la pipeline.
- Ogni modello o trasformazione tra i dati grezzi e la tabella di reporting.
- La query che esegue la dashboard, compresi i filtri impostati direttamente nello strumento di BI.
A ogni passaggio annota due cose: il totale e il numero di righe. Il passaggio in cui uno dei due cambia rispetto al precedente è dove sta il problema. A quel punto scendi ai singoli record: trova un ordine che compare da una parte e non dall’altra, e seguilo.
Un esempio, a scopo illustrativo. La dashboard mostra 412 ordini per il 3 settembre. Il database di origine ne mostra 398. La tabella grezza nel warehouse: 398. Il modello degli ordini puliti: 398. La tabella di reporting: 412. I 14 ordini in più nascono quindi nell’ultima trasformazione. Guardandoli, sono tutti ordini con due spedizioni, e il modello di reporting unisce ordini e spedizioni con una join. Un pomeriggio e qualche query. Nessuno strumento nuovo.
Due consigli pratici. Fai la ricostruzione insieme a qualcuno che conosce il processo aziendale, perché “questo record va contato?” è una domanda di business. E salva ogni query che scrivi lungo la strada: diventeranno i tuoi test.
Le cinque cause tipiche della discrepanza
Nella nostra esperienza, la separazione nasce quasi sempre da una di queste.
1. Definizioni diverse. Lordo o netto. IVA inclusa o esclusa. I clienti in prova contano come clienti oppure no. Una parte esclude gli account interni e di test, l’altra no. È la causa più frequente, e quella che nessuna tecnologia risolve da sola.
2. Il tempo. A quale data appartiene un record: creazione, pagamento, spedizione, fattura? In quale fuso orario? Un ordine fatto alle 23:30 a Milano l’ultimo giorno del mese finisce nel mese successivo se la pipeline lavora in UTC. Le chiusure mensili sono il primo posto dove te ne accorgi.
3. Aggiornamento e dati in ritardo. La dashboard legge una tabella aggiornata alle 6:00. L’estrazione dell’amministrazione è delle 11:00. Oppure una fonte manda i dati in ritardo, un reso arriva tre giorni dopo l’ordine, e nessuno ricalcola il periodo precedente. Entrambi i numeri erano giusti nel momento in cui sono stati presi.
4. Join che duplicano o perdono righe. Come nell’esempio sopra: unire gli ordini a una tabella con più righe per ordine li moltiplica. Succede anche il contrario: una inner join con l’anagrafica clienti elimina in silenzio gli ordini il cui cliente manca. I totali si spostano e nessun errore compare.
5. Logica nascosta nella dashboard. Un filtro impostato nello strumento di BI, un campo calcolato aggiunto da qualcuno l’anno scorso, un estratto in cache che ha smesso di aggiornarsi. Questa logica non si vede dal warehouse, quindi chi gestisce la pipeline non la vede e chi gestisce la dashboard si è dimenticato che esiste.
C’è una sesta causa, più rara ma più dolorosa: è cambiata la fonte. Un nuovo stato dell’ordine, un campo rinominato, un prodotto passato a un altro piano di fatturazione. La pipeline continua a girare e produce, senza avvisare, un numero diverso.
Il rimedio: una definizione più un test
Una volta trovata la causa, correggere quel singolo bug è facile. Il lavoro vero è fare in modo che il prossimo venga intercettato prima che qualcuno lo metta in una slide.
Scrivi la definizione. Un paragrafo breve per metrica: cosa conta, cosa è escluso, quale data, quale fuso orario, quale valuta, chi ne è responsabile. Mettila accanto all’SQL che la calcola, sotto controllo di versione, così documento e codice cambiano insieme. Se la definizione vive in un wiki e la logica nello strumento di BI, prima o poi divergono.
Togli la logica dalla dashboard. Filtri e campi calcolati che definiscono una metrica vanno nelle tabelle modellate, dove sono versionati e testabili. La dashboard deve solo mostrare i numeri.
Trasforma la ricostruzione in test. Le query che hai scritto per trovare il problema sono i test che ti servono. Quelli tipici:
- La tabella di reporting ha esattamente una riga per ordine (un test di unicità alla granularità attesa).
- Il totale della tabella di reporting coincide con quello della fonte per il giorno precedente, entro una tolleranza concordata.
- Ogni ordine ha un cliente corrispondente, oppure quelli senza cliente vengono contati e segnalati.
- Ogni tabella di origine è stata aggiornata entro la finestra prevista.
Strumenti come dbt rendono questi test facili da scrivere e da eseguire a ogni build, e la sua documentazione sui data test è un buon punto di partenza. Anche semplici controlli SQL lanciati da uno scheduler vanno bene. Conta che un test fallito arrivi a una persona che può intervenire, come succederebbe con un controllo fallito su un servizio in produzione.
Nomina un responsabile. Ogni metrica chiave ha bisogno di una persona o di un team che decide cosa significa quando il business cambia. Senza un responsabile, la definizione invecchia e la discussione ritorna.
Quando questo consiglio è sbagliato
Quando la differenza non conta. Se i due numeri differiscono di poco e nessuna decisione cambierebbe, scrivi perché differiscono e vai avanti. Inseguire l’ultima unità su una metrica di facciata è un pessimo uso della settimana di chiunque.
Quando la fonte è il registro ufficiale. Per il fatturato, conta la contabilità: è quella che vedono il commercialista, i revisori e il fisco. Se la dashboard non coincide con la contabilità, ha torto per definizione, e il compito è allinearla o spiegare la differenza.
Quando hai una dashboard e un analista. Se una sola persona costruisce la pipeline e il grafico e li legge entrambi, un catalogo formale delle definizioni è un costo inutile. Correggi il bug, aggiungi uno o due test e vai avanti. Formalizza quando un secondo team inizia a citare quel numero.
Quando il vero problema è che nessuno guarda. A volte la discrepanza sopravvive per mesi perché nessuno dei due numeri guida una decisione. In quel caso la mossa giusta può essere eliminarne uno.
FAQ
Perché i numeri della dashboard non corrispondono al database?
Di solito per una differenza di definizione, di gestione delle date, di orario di aggiornamento, di join o di filtri impostati nello strumento di BI. Ricostruisci un giorno di dati attraverso ogni livello e confronta totali e numero di righe a ogni passaggio per trovare dove si separano.
Conviene comprare uno strumento di data observability?
Non come primo passo. Questi strumenti aiutano quando sai già cosa controllare e hai molte tabelle da sorvegliare. Se non hai ancora scritto cosa significano le tue metriche chiave, uno strumento ti avviserà delle cose sbagliate. Parti dalle definizioni e da qualche test SQL.
Chi dovrebbe essere responsabile della definizione di una metrica?
Il team che prende decisioni con quella metrica, di solito coinvolgendo l’amministrazione per tutto ciò che riguarda il fatturato. Il team dati implementa e testa la definizione. Il business decide cosa significa.
Come lo affrontiamo
Questo tipo di problema sta esattamente sul confine tra infrastruttura e analisi, ed è per questo che li seguiamo entrambi con un solo team. Ricostruiamo i tuoi numeri chiave dalla fonte alla dashboard, sistemiamo i punti in cui divergono e lasciamo definizioni e test nel tuo repository. Se il problema è nelle pipeline, è il nostro lavoro su piattaforme dati e pipeline. Se è nelle definizioni e nelle dashboard, guarda analisi dati e dashboard KPI.