La decisione viene presa in una riunione. Qualcuno apre una dashboard, indica un numero e la sala annuisce. Ricavo per cliente, tasso di conversione, rotazione dell'inventario — qualunque sia la metrica, sembra autorevole perché proviene dal sistema.
Ecco cosa nessuno chiede: quel numero significa ancora ciò che pensiamo significhi?
La maggior parte delle aziende opera su dati che erano accurati due anni fa, prima della soluzione di ripiego, prima che il campo venisse riutilizzato, prima che l'integrazione iniziasse a fallire silenziosamente. La dashboard si aggiorna ancora, quindi tutti presumono che vada bene. Di solito non è così.
I quattro modi in cui i dati si guastano silenziosamente
I dati non si corrompono tutti in una volta. Derivano, e ogni tipo di deriva ha un pattern.
1. Deriva della definizione
Un campo significava una cosa quando è stato creato, poi qualcuno aveva bisogno di tracciare qualcosa di adiacente e il posto più facile dove metterlo era il campo esistente. Ora la stessa colonna significa due cose a seconda del contesto, e ogni query deve sapere quale contesto sta guardando.
La versione classica: un campo stato con valori come in_attesa, approvato, completato — poi qualcuno aggiunge in_attesa_revisione e approvato_con_eccezioni. Sei mesi dopo, metà dei tuoi report filtrano per approvato e perdono le eccezioni. L'altra metà le include. Nessuno è d'accordo sul tasso di approvazione effettivo perché il campo ora codifica due concetti.
Come individuarlo: Cerca campi con più di cinque valori distinti, o valori che includono separatori (trattini bassi, trattini, barre). Entrambi sono sintomi che un singolo campo sta facendo più lavori.
2. Deriva del processo
Il modello dati riflette un processo che non avviene più come una volta. L'azienda si è adattata — un passaggio è stato saltato, un handoff si è spostato, è stato aggiunto uno strato di approvazione — ma il sistema no, quindi le persone lo aggirano.
Esempio: un CRM dove le trattative dovrebbero muoversi attraverso cinque fasi, ma i venditori hanno imparato che la fase tre viene sempre approvata, quindi saltano direttamente dalla due alla quattro. Il sistema ha ancora la fase tre, i report misurano ancora il tempo nella fase tre, e quella metrica ora è sempre zero. Nessuno la guarda più, ma è ancora nella dashboard esecutiva.
Come individuarlo: Trova metriche che non cambiano mai, o campi che hanno sempre lo stesso valore. Poi chiedi a qualcuno che fa il lavoro quotidianamente se quel passaggio accade ancora.
3. Deriva dell'integrazione
Due sistemi si sincronizzavano pulitamente. Poi uno di loro è cambiato — un campo è stato rinominato, un endpoint API deprecato, un parametro richiesto aggiunto — e l'integrazione ha continuato a funzionare ma ha iniziato a fallire silenziosamente.
La modalità di guasto è specifica: il processo di sincronizzazione non genera errori, semplicemente smette di spostare certi record. I nuovi clienti si sincronizzano bene, ma gli aggiornamenti a quelli esistenti no. Oppure funziona per i record creati dopo una certa data, e tutto quello precedente è congelato. Il sintomo sono dati accurati per alcune cose e sottilmente obsoleti per altre, che è peggio di completamente rotto perché è più difficile da notare.
Come individuarlo: Confronta i conteggi dei record e i timestamp di ultimo aggiornamento tra sistemi che dovrebbero combaciare. Una discrepanza crescente significa che qualcosa non si sincronizza.
4. Deriva dell'assunzione
I dati vanno bene. La metrica è sbagliata.
Un report è stato costruito su un'assunzione — "chiudiamo trattative in 30 giorni in media" — e la logica lo riflette. Poi il mercato è cambiato, i cicli di vendita si sono allungati, e ora la metrica esclude tutto quello oltre i 45 giorni come outlier. Il numero sulla dashboard è ancora etichettato "ciclo medio di vendita", ma è in realtà "ciclo medio di vendita per trattative che si chiudono velocemente", che non è la stessa cosa.
Come individuarlo: Qualsiasi metrica con un filtro o esclusione che è stata aggiunta dopo il report originale. Chiedi cosa sta filtrando, e se quell'esclusione ha ancora senso.
L'audit che trova davvero questo
Il solito audit dei dati controlla valori mancanti e duplicati. Quelli contano, ma non è lì che sono le bugie. Le bugie sono nei campi che sembrano a posto ma significano qualcosa di diverso da quello che significavano.
Ecco l'audit che lo fa emergere:
- Elenca le tue prime dieci decisioni. Quelle con budget allegato. Piani di assunzione, ordini di inventario, spesa marketing, cambiamenti di prezzo.
- Per ogni decisione, nomina il numero che l'ha guidata. Ricavo per regione, costo per acquisizione, rotazione inventario, qualunque fosse.
- Traccia quel numero fino alla query. Non la dashboard — la vera SQL o definizione del report che lo produce.
- Leggi la query con qualcuno che fa il lavoro. Non l'analista che l'ha scritta — la persona in operations o vendite che crea i record. Chiedigli di spiegare cosa ogni campo rappresenta davvero oggi.
Troverai deriva in almeno tre su dieci. La domanda è se una di quelle tre ha influenzato una decisione che ora è difficile da invertire.
La soluzione non è sempre tecnica
A volte la deriva è nel processo e i dati lo riflettono semplicemente in modo onesto. Un campo che contiene otto concetti diversi è un problema, ma il problema non è il campo — è che il tuo processo ha otto casi limite e nessuno ha deciso come gestirli in modo coerente.
Pulire i dati senza sistemare il processo significa solo che deriveranno di nuovo in sei mesi. La sequenza che tiene:
- Trova la deriva (l'audit sopra).
- Decidi cosa il campo dovrebbe significare andando avanti.
- Aggiorna il processo in modo che le persone possano effettivamente registrarlo in quel modo.
- Migra i vecchi dati per combaciare, o marcali chiaramente come legacy.
- Aggiorna ogni report che lo tocca.
Il punto tre è quello che viene saltato. Se il sistema non può esprimere la cosa che le persone devono tracciare, troveranno una soluzione di ripiego, e quella soluzione diventerà la prossima deriva.
Quando farlo
Tre momenti in cui un audit dei dati vale il tempo:
- Prima di una grande decisione. Se stai per impegnare sei mesi di lavoro di ingegneria o un budget materiale basato su una metrica, spendi due giorni a controllare se quella metrica riflette ancora la realtà.
- Prima di un consolidamento. Migrare dati sbagliati in un nuovo sistema significa solo che il nuovo sistema è autorevole sulla cosa sbagliata. Il passaggio di migrazione campione menzionato nell'articolo sul consolidamento è dove trovi questo.
- Quando un report smette di avere senso. Se i numeri sembrano sbagliati, o due report che dovrebbero concordare non lo fanno, non è un bug nella query — è un sintomo che il modello dati e la realtà sono divergiti.
Come appare una buona affidabilità dei dati
Non è deriva zero — quello è irrealistico. Le aziende cambiano, e i modelli dati restano indietro. Ciò che conta è sapere dove è la deriva.
Un sistema dati affidabile è uno dove:
- Ogni campo ha una definizione documentata, e quella definizione viene rivista quando il processo cambia.
- Le integrazioni registrano i loro fallimenti in modo visibile, non silenzioso.
- Le metriche includono le loro assunzioni ed esclusioni nell'etichetta, non solo nella SQL.
- Qualcuno è responsabile di notare quando un numero della dashboard smette di cambiare.
Quest'ultimo è il più difficile da assegnare, perché sta tra dati e operations e la maggior parte degli organigrammi non ha una casella per questo. Ma se nessuno ne è responsabile, non succede, e sei di nuovo a prendere decisioni su numeri che sembrano autorevoli perché provengono da un sistema.
I dati più pericolosi non sono quelli mancanti — sono presenti, formattati e sbagliati.
Se stai per consolidare sistemi o migrare dati e vuoi un secondo parere su dove la deriva potrebbe nascondersi, è una cosa ragionevole da coprire in una prima chiamata. Prenotane una, o leggi prima le FAQ se vuoi sapere cosa comporta.