Cos'è un critical data element?

Un critical data element è un elemento di dato la cui inesattezza, indisponibilità o perdita causa un danno concreto e misurabile: un mancato adempimento normativo, un impatto finanziario diretto, una decisione sbagliata su un processo core dell'azienda. La definizione nasce dal lavoro dell'EDM Council, che ha pubblicato una guida dedicata alla selezione dei CDE nell'ambito del framework DCAM, ed è entrata anche nella vigilanza bancaria: i principi BCBS 239 sull'aggregazione dei dati di rischio presuppongono che le banche sappiano identificare quali dati di rischio siano davvero critici prima di poterli governare. Il punto non è la qualità del dato, che riguarda tutti i dati indistintamente, ma la selezione: tra le migliaia di dati che un'azienda produce e consuma ogni giorno, quali meritano un owner nominato, soglie di qualità documentate e un controllo continuo, perché governare ogni campo di ogni tabella con lo stesso rigore è un programma senza fine, che nessuna organizzazione porta a termine.

Come si decide cosa è critico

Il criterio di materialità non è tecnico, riguarda l'impatto: un dato è critico se un suo errore genera una conseguenza che qualcuno in azienda deve poter nominare, non se è "importante" in senso vago. Tre domande separano un CDE da un campo qualsiasi: alimenta un bilancio, un report di vigilanza o una decisione di prezzo? Il suo errore arriva a un cliente o un'autorità prima che qualcuno lo intercetti? Esiste già un obbligo normativo che lo nomina? La decisione non spetta al team dati da solo: il responsabile del processo che consuma il dato deve firmare la lista, perché è lui a subire il danno se il dato è sbagliato. La lista va documentata con la motivazione della criticità accanto a ogni voce, non solo il nome del campo: senza motivazione la lista si allunga per abitudine e perde senso. Una volta identificato, il CDE riceve un owner, soglie di qualità misurate e non dichiarate, e in genere un data contract che formalizza l'impegno tra chi produce quel dato e chi lo consuma; il suo lineage completo diventa un requisito, perché quando un CDE risulta sbagliato serve sapere in minuti da dove arriva.

Un esempio enterprise

Una banca vigilata ha migliaia di campi nei suoi sistemi core, ma solo una parte finisce nella lista dei CDE: l'esposizione aggregata verso una controparte, il rating interno di un cliente, la data di default di un'esposizione in sofferenza. Sono i campi che alimentano segnalazioni di vigilanza sui dati di rischio, dove un errore genera una risposta scorretta a un'autorità, non solo una dashboard sbagliata. Il campo "note interne" sullo stesso cliente non entra nella lista: nessuna conseguenza normativa dipende dalla sua accuratezza. Il rischio opposto è altrettanto reale: un'azienda manifatturiera che dichiara critico ogni campo del suo ERP finisce con un programma che non chiude mai la prima release. Il dato che alla fine causa un fermo produzione, spesso il codice di un componente critico nella distinta base, non era nella lista perché nessuno aveva applicato il criterio di materialità: era stato dato per scontato.

Perché conta per chi decide

Il costo di sbagliare la selezione si paga in due direzioni opposte. Una lista troppo ampia produce un programma di governance infinito, che consuma budget senza arrivare mai a un rilascio completo, screditando l'iniziativa agli occhi di chi la finanzia. Una lista troppo stretta lascia scoperto esattamente il dato che, quando si rompe, genera il danno che la governance avrebbe dovuto prevenire. Chiedere "quali sono i nostri dieci dati più critici e chi ne è responsabile oggi" è spesso la domanda più rivelatrice per un programma dati: se la risposta richiede settimane, la selezione non è mai stata fatta sul serio.