Il report delle vendite dà un totale, il gestionale un altro e nessuno sa quale usare per decidere: in molte aziende italiane il problema nasce prima dell’analisi, quando mancano regole condivise sui dati. Una data governance efficace assegna responsabilità e criteri per gestire le informazioni, ma il modello giusto dipende da chi le usa e dai rischi associati.
Una governance efficace chiarisce chi decide e con quali regole
- Governance significa definire responsabilità, standard e diritti di accesso; il data management applica queste regole nei processi e nei sistemi.
- Parti da un dominio e da un problema misurabile, per esempio il disallineamento tra anagrafica clienti e fatture.
- Data owner e data steward coprono responsabilità diverse: il primo risponde del dato dal lato business, il secondo ne presidia qualità e definizioni operative.
- Il Data Act si applica dal 12 settembre 2025; alcuni obblighi di accessibilità dei dati riguardano i prodotti connessi immessi sul mercato dal 12 settembre 2026.
La governance decide chi può fidarsi di un dato
Quando due reparti usano la stessa parola per indicare cose diverse, anche una dashboard ben fatta può portare a decisioni sbagliate. La governance serve a fissare significato, responsabilità, qualità attesa e accessi, così che il dato sia utilizzabile nel contesto corretto.
La distinzione aiuta a evitare un errore comune: confondere le regole con gli strumenti. La data governance stabilisce, per esempio, chi approva la definizione di “cliente attivo”; il data management traduce quella decisione in procedure, controlli e modifiche ai sistemi. La tecnologia applica le regole, ma non può decidere da sola quale definizione aziendale sia corretta.
Nel modello DAMA-DMBOK, la governance è una disciplina del data management, accanto ad ambiti come qualità, architettura e metadati. La presentazione del framework curata da DAMA Italy lo rende un riferimento utile per orientarsi, non un organigramma da copiare senza adattamenti. Credo che una governance leggera, con responsabilità esplicite, sia più efficace di un comitato che approva tutto e rallenta il lavoro.
Un dominio pilota evita di governare tutto insieme
Un programma esteso a ogni database parte spesso con ambizioni alte e finisce per produrre documenti che pochi consultano. Conviene scegliere un dominio circoscritto che abbia un problema visibile, un responsabile nel business e un risultato verificabile, come ridurre le anagrafiche duplicate o rendere coerenti i ricavi tra CRM e contabilità.
Immagina un’impresa che scopre che il report commerciale considera “cliente attivo” chi ha effettuato un ordine negli ultimi dodici mesi, mentre il sistema amministrativo usa l’ultimo pagamento. La prima decisione non è comprare un catalogo dati: è far stabilire alle funzioni coinvolte quale definizione risponde all’obiettivo, documentarla e indicare dove si applica. Solo dopo ha senso automatizzare i controlli e correggere i flussi.
Per ridurre il rischio di un progetto senza esito, usa questa regola pratica: se il problema ha un impatto economico o operativo misurabile e un referente business disposto a decidere, avvia un pilota; se manca una delle due condizioni, chiarisci prima obiettivo e mandato. Il catalogo completo dell’azienda può aspettare. La prima vittoria deve dimostrare che le regole cambiano una decisione reale.
Data owner e data steward non sono ruoli intercambiabili
Quando la qualità peggiora, la domanda “chi è responsabile?” non dovrebbe generare un giro di email tra IT e business. Il data owner rappresenta la responsabilità di business per un dominio e decide definizioni, priorità e accessi; il data steward segue più da vicino le definizioni operative, i controlli e la gestione delle anomalie.
La stessa persona può ricoprire più incarichi in una piccola azienda, purché le responsabilità restino chiare. L’IT custodisce e protegge l’infrastruttura, ma non dovrebbe essere l’unico arbitro del significato di “margine”, “fornitore” o “ordine evaso”: sono definizioni con conseguenze commerciali e amministrative.
| Situazione | Possibile causa | Decisione operativa |
|---|---|---|
| Due report mostrano numeri diversi per lo stesso indicatore | Definizione o periodo di riferimento non condivisi | Il data owner approva la definizione; lo steward la documenta e verifica i report |
| Un utente non sa se può esportare dati personali | Ruoli e finalità di accesso non sono espliciti | Verifica autorizzazioni, finalità e policy con i referenti privacy e sicurezza |
| Il dato è corretto nel sistema sorgente ma errato nella dashboard | Trasformazione o aggiornamento lungo il flusso | Traccia il percorso del dato e assegna la correzione al responsabile del passaggio difettoso |
| Le anomalie si ripetono e nessuno le prende in carico | Manca un processo di escalation o un responsabile nominato | Definisci soglie, tempi interni di presa in carico e un referente per il dominio |
Le regole europee richiedono una mappa dei dati condivisi
Una governance interna deve anche distinguere i dati che restano nei sistemi aziendali da quelli condivisi con clienti, fornitori o piattaforme. Il Data Governance Act disciplina, tra l’altro, il riutilizzo di determinate categorie di dati pubblici protetti e i servizi di intermediazione; il Data Act stabilisce regole più ampie sull’accesso e sull’uso dei dati, con attenzione ai prodotti connessi.
Il Data Act si applica dal 12 settembre 2025. Una disposizione specifica dell’articolo 3, paragrafo 1, riguarda i prodotti connessi e i servizi correlati immessi sul mercato dal 12 settembre 2026: per questi prodotti si applicano requisiti di accessibilità dei dati per l’utente. Le date e le condizioni sono riportate nel Regolamento UE 2023/2854, il Data Act. Per un’impresa che produce o vende dispositivi connessi, la governance deve quindi comprendere anche come i dati vengono generati, resi accessibili e descritti.
Questo non equivale a un permesso indiscriminato di circolazione: se i dati personali sono coinvolti, restano da considerare le regole di protezione dei dati e la finalità del trattamento. Perciò, prima di attivare uno scambio, identifica quali dati escono, chi li riceve, per quale scopo e con quali controlli.
Per i progetti di AI, la qualità va misurata nel flusso
Un modello può restituire una risposta convincente anche quando la fonte è incompleta o incoerente. In un’indagine italiana riportata da 01net sulle aziende e la governance dei dati per l’AI, il 24% delle imprese italiane intervistate attribuisce risultati inferiori alle aspettative a problemi di qualità del dato. È un segnale utile, pur senza trasformarlo in una stima universale per ogni settore: un progetto pilota di AI va valutato anche sulle fonti, non soltanto sulle prestazioni del modello.
Per un assistente che risponde sulle politiche di reso, per esempio, controlla che il documento usato sia aggiornato, che le eccezioni siano presenti e che la risposta rimandi alla fonte corretta. Registra poi errori come definizioni obsolete, campi mancanti e dati duplicati. Un indicatore medio di accuratezza può nascondere proprio gli errori più costosi, come una risposta sbagliata su un prodotto o una condizione contrattuale.
La prima regola da scrivere è quella che sblocca una decisione
Un buon avvio può stare in una pagina: dominio scelto, definizione dei dati prioritari, responsabili, utenti autorizzati, controlli di qualità e percorso per correggere gli errori. Dopo il pilota, estendi il modello ai domini che condividono problemi simili, senza imporre lo stesso livello di controllo a informazioni con rischi diversi.
Se vuoi rendere il lavoro verificabile, misura un esito operativo, come il tempo necessario per correggere un’anomalia o la quota di record che supera i controlli concordati. Quando un dato torna a produrre lo stesso significato nei reparti e nei sistemi, l’azienda può usarlo con maggiore fiducia, anche per analytics e AI.