Un codice articolo duplicato può sembrare un difetto amministrativo. Quando entra in un modello di previsione, divide lo storico, altera la domanda e produce un suggerimento sbagliato sugli acquisti. La stessa dinamica vale per clienti classificati in modo incoerente, tempi ciclo mai aggiornati o ordini chiusi fuori sistema. L’AI non ripara automaticamente il dato aziendale: ne moltiplica la portata.
Nel 2025 il mercato italiano del Data Management & Analytics ha raggiunto 4,1 miliardi di euro, in crescita del 20%, ma solo il 38% delle grandi aziende ha definito una strategia di valorizzazione dei dati. Il dato dell’Osservatorio Big Data & Business Analytics mostra una tensione concreta: gli strumenti avanzano più rapidamente della capacità di governarli. La qualità del dato ERP deve quindi diventare un processo operativo, con ruoli, soglie e controlli.
La qualità del dato è un processo operativo continuo: l'AI amplifica errori, ritardi e definizioni incoerenti, quindi controlli e responsabilità devono agire nel punto in cui il dato nasce.
L'ERP fornisce identità e contesto condiviso: anagrafiche, transazioni ed eventi rendono riconciliabili le informazioni provenienti da funzioni e sistemi diversi.
La qualità dipende dal caso d'uso: accuratezza, completezza, tempestività e granularità vanno valutate rispetto alla decisione, evitando bonifiche estese ma prive di impatto.
Governance significa ownership e tracciabilità: data owner, steward, lineage, log e soglie trasformano le correzioni in un processo verificabile, prioritizzato per rischio e valore.
Un modello apprende relazioni dai dati storici e usa informazioni correnti per produrre l’output. Errori sistematici diventano regole implicite; buchi e ritardi riducono copertura; definizioni incoerenti confondono il contesto. Il problema può restare invisibile, perché la risposta dell’AI conserva una forma convincente anche quando la base è debole.
La governance serve a prevenire, rilevare e correggere questi difetti nel punto in cui nascono. Non coincide con una bonifica straordinaria prima del progetto AI. È il modo con cui l’azienda mantiene affidabili anagrafiche ed eventi lungo il loro ciclo di vita.
L’ERP non è soltanto il sistema in cui vengono registrati ordini, movimenti e anagrafiche. È il luogo in cui molte informazioni aziendali assumono un significato operativo: un articolo è collegato a una distinta, un cliente a condizioni commerciali, un ordine a una priorità, una transazione a un impatto economico. Per questo diventa una base essenziale per rendere l’AI più contestualizzata.
L’ERP contiene identità e relazioni: articoli, clienti, fornitori, risorse, conti, ordini, movimenti, costi e stati. Le anagrafiche descrivono gli oggetti; le transazioni registrano cambi economici e logistici; gli eventi raccontano che cosa è accaduto nel processo. Questa combinazione dà all’AI il contesto necessario per distinguere, per esempio, una domanda reale da un trasferimento interno.
Allo stesso tempo, vendite, acquisti, produzione, logistica e controllo devono leggere le stesse entità, pur con viste diverse. L’ERP può offrire questa base condivisa se codici e regole non vengono aggirati da archivi locali. Non deve essere l’unica fonte: MES, CRM, WMS e piattaforme esterne aggiungono dettaglio, ma le chiavi e le definizioni devono restare riconciliabili.
La qualità del dato non coincide con l’assenza generica di errori. Un dato può essere formalmente corretto ma non utile, completo ma non aggiornato, disponibile ma non pertinente al caso d’uso. Per questo la qualità va letta come insieme di dimensioni operative, da valutare rispetto alla decisione che il dato deve sostenere.
Un dato è accurato quando rappresenta correttamente la realtà ed è valido quando rispetta formato, dominio e regole. Un CAP formalmente corretto può appartenere al cliente sbagliato; un lead time numerico può essere valido e tuttavia obsoleto. I controlli devono coprire entrambe le dimensioni.
Altrettanto importanti sono completezza e coerenza. La completezza verifica la presenza dei campi necessari al caso d’uso; la coerenza controlla che valori collegati non si contraddicano tra sistemi, periodi o gerarchie. Non ogni campo deve essere obbligatorio: va resa obbligatoria l’informazione che modifica una decisione.
Infine, contano tempestività, unicità e pertinenza. Un avanzamento registrato il giorno dopo non sostiene la schedulazione intraday; lo stesso cliente o articolo non dovrebbe vivere sotto codici diversi; una previsione per famiglia può tollerare una granularità che sarebbe insufficiente per allocare una specifica variante. La qualità è sempre relativa allo scopo: per questo il profilo del dataset va confrontato con la decisione AI, evitando bonifiche indiscriminate prive di impatto.
Gli errori nei dati non nascono quasi mai da un’unica causa tecnica. Spesso sono il risultato di abitudini operative, regole poco chiare, sistemi non allineati o processi paralleli che aggirano l’ERP. Individuare l’origine dell’errore è importante quanto correggere il singolo record, perché permette di intervenire sul meccanismo che lo produce.
Campi liberi, default accettati senza verifica e controlli spostati a valle generano errori ripetibili. Il rimedio consiste nel semplificare l’inserimento, validare nel punto di origine e spiegare l’effetto operativo del dato, senza moltiplicare i vincoli.
Altri problemi derivano da duplicati, codifiche locali e sistemi non allineati. Acquisizioni, sedi e applicazioni verticali producono codifiche diverse; senza mapping e responsabilità comuni, il reporting riconcilia a mano e l’AI riceve versioni discordanti. Master data management e chiavi condivise riducono il problema, ma richiedono decisioni organizzative su quale fonte prevale.
C’è poi una terza fonte, spesso meno visibile: i processi che aggirano il sistema. Un processo può apparire pulito nel database perché le eccezioni vengono risolte via email o foglio di calcolo. Quei passaggi sottraggono segnali importanti: motivo del cambio, approvatore, durata, impatto. Prima di addestrare un modello conviene cercare il lavoro parallelo che il sistema non vede.
La governance del dato funziona solo se traduce le responsabilità in ruoli concreti. Non basta dichiarare che il dato deve essere “di qualità”: bisogna stabilire chi definisce le regole, chi presidia il dominio, chi corregge gli errori, chi approva le modifiche più sensibili e quando un problema deve salire di livello.
Il data owner decide significato, regole e priorità di un dominio. Il data steward presidia qualità e coordinamento quotidiano. Gli utenti di processo creano e correggono il dato nel lavoro reale. IT garantisce piattaforme e controlli, ma non può stabilire da solo che cosa renda corretta un’anagrafica commerciale o produttiva.
Le modifiche ad alto impatto, come coordinate bancarie, distinta base o listino, richiedono approvazioni proporzionate. Gli errori ricorrenti devono aprire escalation verso la causa, non una coda infinita di correzioni. Soglie e tempi rendono la governance eseguibile.
Un dato non va governato solo nel momento in cui viene creato. Deve restare affidabile quando viene modificato, utilizzato da altri sistemi, storicizzato o archiviato. Questo è particolarmente importante per l’AI, perché modelli e dataset possono dipendere da informazioni prodotte molto prima del progetto che le utilizza.
Ogni dominio deve avere criteri di creazione, versionamento, stato e dismissione. Un articolo cessato non va cancellato se serve a interpretare lo storico; deve essere escluso dai nuovi processi con uno stato chiaro. Le modifiche devono conservare decorrenza e responsabile.
I controlli devono combinare prevenzione e verifica successiva. I controlli preventivi bloccano valori impossibili o richiedono conferme; quelli a posteriori cercano anomalie, duplicati e deviazioni. Il mix dipende dal rischio: bloccare ogni dubbio rallenta il lavoro, correggere tutto dopo rende il dato inaffidabile nel momento della decisione.
Per usare i dati nei processi AI non basta sapere che un valore è presente. Bisogna poter ricostruire da dove arriva, come è stato trasformato, chi lo ha modificato e in quale contesto viene utilizzato. Tracciabilità e spiegabilità rendono il dato verificabile e aiutano a capire se un errore dipende dalla fonte, da una regola o da una trasformazione successiva.
Il lineage descrive da quale sistema arriva il dato, quali trasformazioni subisce e dove viene usato. È indispensabile quando un output AI aggrega ERP e fonti esterne. La scorecard di qualità deve poter risalire alla tabella, alla regola e all’evento che hanno generato lo scostamento.
Anche log, versioni e audit delle correzioni sono essenziali. Registrare chi ha modificato cosa, quando e perché rende la correzione verificabile. NIST, nelle risorse sull’AI Risk Management Framework, lega la governance dei dati alla capacità di identificare provenienza, trasformazioni e rischi. I log non servono soltanto all’audit: aiutano a riconoscere regole che producono errori ripetuti.
La qualità del dato deve essere misurata con la stessa disciplina degli altri processi aziendali. Senza indicatori, soglie e responsabilità, la governance resta una dichiarazione di principio. Una scorecard permette invece di capire quali domini sono affidabili, quali campi generano più problemi e quali errori hanno un impatto reale sulle decisioni.
Per clienti, prodotti, fornitori o risorse si possono misurare percentuale di record completi, duplicati, violazioni, età dell’ultimo aggiornamento e tempo di correzione. Ogni indicatore deve avere formula, frequenza, owner e soglia. La media aziendale va accompagnata dal dettaglio sui campi critici.
La priorità, però, non dipende solo dalla frequenza dell’errore. Un errore raro può essere prioritario se blocca pagamenti o sicurezza; una percentuale elevata di campi secondari mancanti può avere impatto nullo. La priorità combina frequenza, valore economico, rischio, diffusione e dipendenza dei casi d’uso AI.
Preparare i dati per l’AI non significa estrarre copie manuali e congelarle in un ambiente separato. Il rischio, in quel caso, è creare un dataset apparentemente pulito ma presto disallineato rispetto alle fonti operative. Il dataset deve invece essere una vista governata delle fonti, con trasformazioni documentate e possibilità di aggiornamento.
Feature store, data platform o layer semantici possono aiutare, purché mantengano chiavi, lineage e responsabilità collegati all’ERP. In questo modo l’AI lavora su dati preparati per il caso d’uso, ma ancora riconducibili ai processi aziendali che li generano.
La qualità del dato non si risolve con una bonifica iniziale. Dopo il rilascio cambiano processi, volumi, prodotti e comportamenti; anche i dati, quindi, cambiano forma e significato. Per questo la qualità deve essere monitorata insieme alla performance del modello, non trattata come una fase preliminare da chiudere una volta per tutte.
Drift, crescita delle eccezioni e aumento delle correzioni manuali possono segnalare un problema di dato prima che emerga nel KPI finale. Un modello operativo continuo permette di intercettare questi segnali, correggere le regole e mantenere il legame tra dati, processi e decisioni.
Conviene scegliere un dominio trasversale e con impatto visibile: articoli per forecast e scorte, clienti per credito e servizio, fornitori per approvvigionamenti. Si mappano decisioni, campi critici, fonti e responsabilità; si misura la baseline; si applicano controlli al punto di origine; si verifica l’effetto su un caso d’uso concreto.
La governance diventa credibile quando riduce una decisione contestata, un ordine bloccato o una previsione distorta. L’AI può accelerare l’analisi, ma la fiducia nasce prima: nel modo in cui l’azienda crea, corregge e rende spiegabile il dato che le chiede di usare.