Un direttore operativo stampa il report di marzo, lo firma e lo allega alla riunione con la proprietà. Tre settimane dopo, per curiosità, riapre lo stesso report. I numeri sono diversi. Non di poco: un margine che a marzo risultava del 22% adesso è al 19%. Nessuno ha toccato la dashboard. Qualcuno, semplicemente, ha corretto un ordine registrato male in magazzino, o una fattura riclassificata, e quella correzione si è propagata all'indietro, silenziosamente, fino al report già firmato.
Se lavori con dati aziendali — vendite, produzione, magazzino, KPI contrattuali con clienti o fornitori — probabilmente questa situazione ti è familiare. E probabilmente ti sei chiesto se il problema fosse un bug della piattaforma di business intelligence. Non lo è. È un problema di architettura, ed è molto più comune di quanto si pensi.
Perché succede
La maggior parte dei sistemi di reporting legge i dati "in diretta" dalle fonti transazionali: il gestionale, il CRM, l'ERP, il sistema di produzione. Ma il problema non riguarda solo chi legge in diretta: capita anche a chi importa i dati in un datawarehouse con un caricamento ciclico, ogni notte o ogni settimana. Se quel caricamento si limita a fotografare lo stato attuale delle fonti, ogni nuova importazione sovrascrive comunque i mesi già chiusi. È un'impostazione che sembra un vantaggio — il report è sempre aggiornato — ma nasconde un difetto strutturale. Se un operatore corregge una riga inserita male due mesi fa, quella modifica non resta confinata al presente: riscrive anche il passato, perché il report ricalcola tutto ogni volta che viene aperto o aggiornato.
In un contesto interno, questo è al massimo fastidioso. Ma quando il report è legato a penali contrattuali, premi di risultato, provvigioni o rendicontazioni verso enti terzi — un cliente, una banca, un ente pubblico — il problema cambia natura. Un numero che si sposta dopo essere stato firmato non è più un dettaglio tecnico: è un rischio legale. Chi ha firmato quel documento lo ha fatto sulla base di un dato che, tecnicamente, non esiste più.
L'analogia che aiuta a capire
Pensa a come funziona la contabilità. Un bilancio di marzo, una volta chiuso e depositato, non cambia più — anche se a maggio scopri un errore relativo a marzo. Quella correzione non riscrive il passato: entra in contabilità come rettifica, con una data propria, una causale, e resta nel periodo in cui è stata effettivamente registrata. Il bilancio di marzo, firmato, resta quello che era. Chi vuole capire perché i numeri di aprile sono un po' diversi dal previsto può andare a vedere la rettifica e capire da dove arriva.
La business intelligence, oggi, quasi mai funziona così. Tratta ogni dato come se fosse sempre "aperto", modificabile all'infinito. Ed è proprio questo che genera sfiducia: un manager che vede il proprio report cambiare da solo, senza una ragione visibile, smette di fidarsi dello strumento — anche se i numeri, in teoria, sono più corretti di prima.
Come si risolve: tre livelli e un congelamento
La soluzione non è impedire le correzioni — succederanno sempre, ed è giusto che sia possibile farle. Il punto è dove e quando quella correzione produce effetto.
Un'architettura dati ben progettata separa i dati in tre livelli. Un primo livello contiene i dati grezzi, esattamente come arrivano dalle fonti, senza filtri. Un secondo livello li pulisce e li standardizza — stessi formati, stesse unità di misura, stessi codici. Il terzo livello è quello certificato: è la versione dei dati che alimenta davvero i report ufficiali, ed è qui che entra in gioco il concetto chiave.
Ogni periodo (un mese, tipicamente) rimane aperto per una finestra di tempo definita dopo la sua chiusura — quattordici giorni è un punto di partenza ragionevole, ma la finestra giusta dipende dalla fonte: i dati di un sistema di produzione possono avere tempi di consolidamento diversi da quelli di un CRM commerciale o di un gestionale acquisti. Durante quella finestra, le correzioni sui dati di origine si riflettono normalmente nei report. Passato quel termine, il periodo viene "congelato": qualunque modifica avvenga dopo, alla fonte, non altera più i numeri già certificati per quel mese.
Se una correzione tardiva arriva comunque — e arriverà — non riscrive il passato. Viene registrata come conguaglio esplicito nel periodo successivo, oppure resa disponibile come versione alternativa dello stesso report, chiaramente etichettata. In entrambi i casi resta tracciato chi ha modificato cosa, quando, e perché il dato attuale è diverso da quello firmato tre settimane prima.
Il pezzo che manca quasi sempre: qualcuno deve chiudere
Fin qui la parte tecnica. Ma il freeze, da solo, non parte da solo: qualcuno deve premere il bottone. E qui la maggior parte delle aziende scopre che il vero ostacolo non è la piattaforma, è l'organizzazione.
Nelle aziende dove i report cambiano in continuazione, quasi sempre manca una figura precisa: qualcuno che, entro una data definita — il 14° giorno del mese, per esempio — si prenda la responsabilità di dire "i dati del mese scorso sono sufficientemente affidabili, chiudiamo il periodo". Senza questa decisione, i dati restano aperti a modifiche indefinite, non perché sia tecnicamente necessario, ma perché nessuno vuole essere quello che dice "va bene così" quando in teoria potrebbe arrivare ancora una correzione. Il risultato è che tutti possono cambiare tutto, i report cambiano di continuo, e alla fine nessuno si fida più di niente.
Anche qui vale il parallelo con la contabilità: chi chiude un bilancio non aspetta che ogni fattura sia perfetta all'ultimo centesimo, aspetta che i dati siano sufficientemente affidabili per il periodo, poi chiude e gestisce il resto come rettifiche successive. Non serve la perfezione, serve una soglia accettabile e qualcuno che se ne assuma la responsabilità.
Introdurre un "responsabile della qualità del dato mensile" — anche part-time, anche come estensione naturale di un ruolo già esistente in azienda — è il vero cambiamento che sblocca il valore della BI. Non è un ruolo tecnico: è un ruolo di responsabilità organizzativa, simile a chi firma la chiusura contabile. La tecnologia del freeze, per quanto ben progettata, resta inutile se non c'è qualcuno che, ogni mese, prende la decisione di chiudere il periodo.
Cosa cambia, concretamente
Il report che hai firmato a marzo resta identico a se stesso per sempre. Se i numeri di aprile sono diversi da quanto ti aspettavi, la causa è sempre ricostruibile in due minuti, non è un mistero da indagare con l'IT. E soprattutto, quando qualcuno — un revisore, un ente pubblico, un socio — ti chiede conto di un numero firmato, puoi rispondere con certezza, non con un "verifico e ti richiamo".
La business intelligence non deve essere uno specchio che riflette in tempo reale ogni movimento delle fonti almeno in ambito aziendale/amministrativo. Deve essere un archivio certificato, capace di dire con precisione: "questo era il dato al momento in cui è stata presa questa decisione, e resterà questo per sempre". È una differenza di progettazione, non di strumento — e vale la pena affrontarla prima che un numero firmato diventi un problema in tribunale, non solo in una riunione.
Se i tuoi report cambiano da soli e vuoi capire come strutturare un'architettura dati che li renda affidabili nel tempo, contatta Deimos Engineering: analizziamo la tua situazione e ti aiutiamo a progettare la soluzione giusta per la tua azienda.