Come implementare un processo di qualità dei dati

La qualità dei dati (DQ) nei sistemi di data warehouse sta diventando sempre più importante. I crescenti requisiti normativi, ma anche la crescente complessità delle soluzioni di data warehouse, costringono le aziende a intensificare (o avviare) un'iniziativa per la qualità dei dati.

L'obiettivo principale di questo articolo sarà il data warehousing "tradizionale", ma la qualità dei dati è anche un problema in concetti più "moderni" come i data lake. Mostrerà alcuni punti principali da considerare e anche alcune insidie ​​comuni da evitare quando si implementa una strategia di qualità dei dati. Non copre la parte sulla scelta della giusta tecnologia/strumento per costruire un framework DQ.

Uno dei problemi più ostruttivi di un progetto DQ è il fatto che a prima vista crea molto lavoro per le unità aziendali senza fornire alcuna funzionalità aggiuntiva. Un'iniziativa sulla qualità dei dati di solito ha forti sostenitori solo se:

• Ci sono problemi di qualità dei dati con un grave impatto sul business.
• Gli organismi di regolamentazione applicano standard di qualità dei dati (ad esempio, BCBS 239 nel settore finanziario).

Il trattamento di DQ è simile a quello dei test nello sviluppo del software: se un progetto esaurisce il tempo e/o il budget, questa parte tende a essere ridotta per prima.

Questa, ovviamente, non è tutta la verità. Un buon sistema di qualità dei dati aiuta a rilevare gli errori in anticipo, accelerando così il processo di fornitura di dati di qualità "sufficientemente buona" agli utenti.

Definizione dei termini

Prima di discutere l'argomento, è importante una comprensione comune dei termini utilizzati.

Data Warehouse (DWH)

Un data warehouse (DWH) è un sistema non operativo utilizzato principalmente per il supporto alle decisioni. Consolida i dati dei sistemi operativi (tutti o un sottoinsieme più piccolo) e fornisce dati ottimizzati per le query per gli utenti del sistema DWH. Il data warehouse dovrebbe fornire "una versione unica della verità" all'interno dell'azienda. Un data warehouse è solitamente costituito da fasi/livelli:

I dati operativi vengono memorizzati per lo più invariati in un livello di staging . Il livello principale contiene dati consolidati e unificati. La fase successiva facoltativa è un'area di derivazione , che fornisce dati derivati ​​(ad esempio, un punteggio cliente per le vendite) e aggregazioni. Il livello data mart contiene dati ottimizzati per un determinato gruppo di utenti. I data mart contengono spesso aggregazioni e molte metriche derivate. Gli utenti del data warehouse spesso lavorano solo con il livello del data mart.

Tra ogni fase, avviene una sorta di trasformazione dei dati. Di solito, un data warehouse viene periodicamente caricato con estrazioni delta dei dati operativi e contiene algoritmi per mantenere i dati storici.

Qualità dei dati

La qualità dei dati è generalmente definita come una metrica su quanto un prodotto soddisfa i requisiti degli utenti. Utenti diversi potrebbero avere requisiti diversi per un prodotto, quindi l'implementazione dipende dal punto di vista dell'utente ed è importante identificare queste esigenze.

La qualità dei dati non significa che i dati debbano essere completamente o quasi privi di errori, ma dipende dai requisiti degli utenti. Un approccio "abbastanza buono" è una buona scelta per cominciare. Al giorno d'oggi, le aziende più grandi hanno "una politica del governo sui dati (o sull'informazione)" e la qualità dei dati ne fa parte. Una politica del governo dei dati dovrebbe descrivere come la tua azienda gestisce i dati e come si assicura che i dati abbiano la giusta qualità e che le regole sulla privacy dei dati non vengano violate.

La qualità dei dati è un argomento in corso. Deve essere implementato un circuito DQ (vedi capitolo successivo). I requisiti normativi e le regole di conformità hanno anche un impatto sulla qualità dei dati necessaria, come il TCPA (US Telephone Consumer Protection Act) o il GDPR in Europa per problemi di privacy, ma anche norme specifiche del settore come Solvency II per le assicurazioni nell'UE, BCBS 239 e altri per operazioni bancarie e così via.

Circuito di qualità dei dati

Come per tutti gli argomenti di qualità, DQ è un'attività continua progettata per mantenere una qualità soddisfacente. Come risultato di un progetto DQ, deve essere implementato un circuito simile a quello seguente:

I passaggi all'interno di questo ciclo verranno descritti nei capitoli successivi.

Ruoli di qualità dei dati

Per implementare un'iniziativa DQ di successo, sono necessari i seguenti ruoli:

• Titolare dei dati. Il titolare dei dati è responsabile della qualità dei dati, ma anche della protezione della privacy dei dati. Il proprietario dei dati "possiede" un dominio di dati, controlla l'accesso ed è responsabile di garantire la qualità dei dati e di agire per correggere i risultati. Nelle organizzazioni più grandi, è comune trovare diversi proprietari di dati. I domini dei dati potrebbero essere, ad esempio, dati di marketing, dati di controllo, ecc. Se in un'azienda esiste più di un titolare dei dati, dovrebbe esserci una persona (proprietario dei dati o qualcun altro) responsabile del processo generale di qualità dei dati. Un proprietario dei dati dovrebbe avere una forte autorità per far rispettare la qualità dei dati e supportare il processo di DQ; pertanto, i proprietari dei dati sono spesso stakeholder senior. Una buona comprensione del dominio aziendale insieme a buone capacità di comunicazione sono importanti.
• Responsabile dei dati. Un data steward aiuta a implementare la qualità dei dati all'interno di un'impresa, supportando gli utenti dei dati su domande su come interpretare i dati/il modello dei dati, problemi di qualità dei dati, ecc. I data steward sono spesso il personale del proprietario dei dati o possono essere organizzati in un centro di competenza sulla qualità dei dati o una squadra DQ. I data steward possono avere un background IT o aziendale, ma dovrebbero conoscere entrambe le parti. Le capacità analitiche insieme a una buona comprensione del dominio aziendale che supportano, combinate con forti capacità di comunicazione, sono i prerequisiti principali per un data steward di successo.
• Utente dei dati. Questi sono utenti del data warehouse che lavorano con i dati. Gli utenti dei dati in genere lavorano con il livello del data mart e sono responsabili dei risultati del lavoro con i dati. Gli utenti dei dati si assicurano che ci siano adeguati controlli della qualità dei dati per il livello di qualità di cui hanno bisogno. Gli utenti dei dati necessitano di una profonda comprensione dei propri dati, del dominio aziendale e delle capacità analitiche richieste per interpretare i dati. È ragionevole trovare alcune persone tra gli utenti di dati in ogni business unit che saranno responsabili dei problemi di qualità dei dati.

Per garantire il successo, è importante che questi ruoli siano chiaramente definiti e ampiamente accettati all'interno dell'organizzazione nelle prime fasi del progetto DQ. È altrettanto importante trovare specialisti di dati competenti per questi ruoli che supportano il progetto.

Definisci le regole

Trova e implementa utili controlli/regole DQ. La definizione delle regole DQ richiede una buona comprensione del data warehouse e del suo utilizzo.

Come trovare le regole DQ?

Come discusso in precedenza, gli utenti dei dati (e il proprietario dei dati) sono responsabili dell'utilizzo dei dati e quindi anche del livello necessario di qualità dei dati. Gli utenti dei dati dovrebbero avere una buona comprensione dei propri dati in modo da poter fornire il miglior input per regole utili sulla qualità dei dati.

Sono anche quelli che analizzano i risultati delle regole sulla qualità dei dati, quindi è sempre una buona idea lasciare che definiscano le proprie regole. Ciò migliora ulteriormente l'accettazione di controllare e valutare il risultato delle regole DQ assegnate a un'unità utente di dati (vedere il capitolo "Analisi").

Lo svantaggio di questo approccio è che gli utenti dei dati normalmente conoscono solo il livello del data mart, non i livelli precedenti del data warehouse. Se i dati sono stati danneggiati nelle fasi "inferiori", ciò non verrà rilevato controllando solo il livello "superiore" del tuo data warehouse.

Affrontare gli errori

Che tipo di errori noti potrebbero verificarsi in un data warehouse?

• Logica di trasformazione errata nel data warehouse
  • Più complesso è il tuo panorama IT, più complessa tende ad essere la logica di trasformazione. Questi sono i problemi DQ più comuni e l'effetto di tali errori può essere dati "persi", duplicati, valori errati, ecc.
• Processo di carico instabile o movimentazione errata dei carichi
  • Il carico di un data warehouse può essere un processo complesso che potrebbe includere errori nella definizione dell'orchestrazione dei lavori (lavori avviati troppo presto o troppo tardi, lavori non eseguiti, ecc.). Errori dovuti all'intervento manuale (ad esempio, alcuni lavori vengono saltati, alcuni lavori vengono avviati con una data di scadenza errata o con i file di dati di ieri) si verificano spesso quando il processo di caricamento è fuori banda a causa di qualche interruzione.
• Trasferimento dati errato delle origini dati
  • Il trasferimento dei dati è spesso implementato come compito del sistema di origine. Anomalie o interruzioni nei flussi di lavoro potrebbero causare la consegna di dati vuoti o incompleti.
• Dati operativi errati
  • I dati nel sistema operativo contengono errori finora non riconosciuti. Può sembrare strano, ma è banale nei progetti di data warehouse che la qualità dei dati operativi spesso non si vede fino a quando i dati non vengono inclusi in un DWH.
• Interpretazione errata dei dati
  • I dati sono corretti, ma gli utenti non sanno come interpretarli correttamente. Questo è un "errore" molto comune che non è strettamente un problema di qualità dei dati, ma qualcosa che ha a che fare con la governance dei dati ed è un compito per gli steward dei dati.

Questi problemi sono spesso causati da persone prive del know-how e delle competenze appropriate per definire, implementare, eseguire e lavorare con una soluzione di data warehouse.

Dimensioni della qualità dei dati

Le dimensioni DQ sono un modo comune per identificare e raggruppare i controlli DQ. Esistono molte definizioni e il numero di dimensioni varia considerevolmente: potresti trovarne 16 o anche più dimensioni. Da un punto di vista pratico, è meno confuso iniziare con alcune dimensioni e trovarne una comprensione generale tra i tuoi utenti.

• Completezza: tutti i dati richiesti sono disponibili e accessibili? Tutte le fonti necessarie sono disponibili e caricate? I dati sono stati persi tra le fasi?
• Coerenza: ci sono dati errati/in conflitto/incoerenti? Ad esempio, la data di cessazione di un contratto in stato “Terminato” deve contenere una data valida maggiore o uguale alla data di inizio del contratto.
• Unicità: ci sono duplicati?
• Integrità: tutti i dati sono collegati correttamente? Ad esempio, ci sono ordini collegati a ID cliente inesistenti (un classico problema di integrità referenziale)?
• Tempestività: i dati sono aggiornati? Ad esempio, in un data warehouse con aggiornamenti giornalieri, mi aspetto che i dati di ieri siano disponibili oggi.

Anche i dati generati dal processo di caricamento del data warehouse possono essere utili.

• Tabelle con dati scartati. Il tuo data warehouse potrebbe avere processi per saltare/ritardare i dati che non possono essere caricati a causa di problemi tecnici (ad es. conversione del formato, valori obbligatori mancanti, ecc.).
• Informazioni di registrazione. Problemi evidenti potrebbero essere scritti nelle tabelle di registrazione o nei file di registro.
• Bolla di consegna. Alcuni sistemi utilizzano le “bolle di consegna” per i dati forniti dai sistemi operativi (es. numero di record, numero di chiavi distinte, somme di valori). Questi possono essere utilizzati per i controlli di riconciliazione (vedi sotto) tra il data warehouse ei sistemi operativi.

Tieni presente che ogni controllo di qualità dei dati deve essere analizzato da almeno un utente dei dati (vedi capitolo “Analisi”) nel caso vengano rilevati errori, per i quali avrai bisogno di qualcuno responsabile e disponibile che si occupi di ogni controllo implementato.

All'interno di un complesso data warehouse, potresti ritrovarti con molte (a volte migliaia) regole DQ. Il processo per eseguire le regole sulla qualità dei dati dovrebbe essere robusto e sufficientemente veloce per gestirlo.

Non controllare i fatti che sono garantiti dall'implementazione tecnica. Ad esempio, se i dati sono archiviati in un DBMS relazionale, non è necessario verificare se:

• Le colonne definite come obbligatorie contengono valori NULL.
• I valori dei campi della chiave primaria sono univoci in una tabella.
• Non sono presenti chiavi esterne in una tabella con i controlli di integrità relazionale abilitati.

Detto questo, tieni sempre presente che un data warehouse è in continua evoluzione e che la definizione dei dati di campi e tabelle potrebbe cambiare nel tempo.

Le pulizie sono molto importanti. Le regole definite da diverse unità utente di dati potrebbero sovrapporsi e dovrebbero essere consolidate. Più complessa è la tua organizzazione, più lavori di pulizia saranno necessari. I proprietari dei dati dovrebbero implementare un processo di consolidamento delle regole come una sorta di "regole sulla qualità dei dati per la qualità dei dati". Inoltre, i controlli sulla qualità dei dati potrebbero diventare inutili se i dati non vengono più utilizzati o se la sua definizione è cambiata.

Classi di regole di qualità dei dati

Le regole sulla qualità dei dati possono essere classificate in base al tipo di test.

• Controllo della qualità dei dati. Il caso "normale", il controllo dei dati all'interno di un livello di data warehouse (vedere la Figura 1) all'interno di una tabella o di un insieme di tabelle.
• Riconciliazione. Regole che controllano se i dati sono stati trasportati correttamente tra i livelli di data warehouse (vedere la figura 1). Queste regole vengono utilizzate principalmente per verificare la dimensione DQ di "Completezza". La riconciliazione può utilizzare una singola riga o un approccio di riepilogo. Il controllo delle singole righe è molto più granulare, ma dovrai riprodurre i passaggi di trasformazione (filtraggio dei dati, modifiche ai valori dei campi, denormalizzazione, join, ecc.) tra i livelli confrontati. Più livelli sono saltati, più complessa è la logica di trasformazione da implementare. Pertanto, è una buona scelta eseguire la riconciliazione tra ogni livello e il suo predecessore invece di confrontare lo staging con il livello del data mart. Se è necessario implementare trasformazioni nelle regole di riconciliazione, utilizzare la specifica, non il codice del data warehouse! Per una riconciliazione riepilogativa, trova campi significativi (ad es. riepilogo, conteggio di valori distinti, ecc.).
• Monitoraggio. Un data warehouse di solito contiene dati storici ed è caricato con estratti delta di dati operativi. Esiste il pericolo di un divario in lento aumento tra il data warehouse ei dati operativi. La creazione di serie temporali riepilogative di dati aiuta a identificare problemi come questo (ad esempio, confrontando i dati del mese scorso con i dati del mese corrente). Gli utenti dei dati con una buona conoscenza dei propri dati possono fornire misure e soglie utili per le regole di monitoraggio.

Come quantificare un problema di qualità dei dati

Una volta definito cosa controllare, dovrai specificare come quantificare i problemi identificati. Informazioni come "cinque righe di dati violano la regola DQ con ID 15" non hanno molto senso per la qualità dei dati.

Mancano le seguenti parti:

• Come quantificare/contare gli errori rilevati. Potresti contare il "numero di righe", ma potresti anche utilizzare una scala monetaria (ad esempio, esposizione). Tieni presente che i valori monetari potrebbero avere segni diversi, quindi dovrai indagare su come riassumerli in modo significativo. Potresti prendere in considerazione l'utilizzo di entrambe le unità di quantificazione (conteggio di righe e riepilogo) per una regola di qualità dei dati.
• Popolazione. Qual è il numero di unità controllate dalla regola della qualità dei dati? "Cinque righe di dati su cinque" ha una qualità diversa da "cinque su 5 milioni". La popolazione dovrebbe essere misurata utilizzando la stessa/e quantificazione/e degli errori. È comune mostrare il risultato di una regola di qualità dei dati in percentuale. La popolazione non deve essere identica al numero di righe in una tabella. Se una regola DQ controlla solo un sottoinsieme dei dati (ad esempio, solo i contratti risolti nella tabella dei contratti), lo stesso filtro dovrebbe essere applicato per misurare la popolazione.
• Definizione del risultato. Anche se un controllo della qualità dei dati rileva problemi, ciò non deve sempre causare un errore. Per la qualità dei dati, è molto utile un sistema a semaforo (rosso, giallo, verde) che utilizza valori di soglia per valutare i risultati. Ad esempio, verde: 0-2%, giallo: 2-5%, rosso: sopra il 5%. Tieni presente che se le unità utente dati condividono le stesse regole, potrebbero avere soglie molto diverse per una determinata regola. Un'unità aziendale di marketing potrebbe non preoccuparsi di una perdita di alcuni ordini, mentre un'unità contabile potrebbe preoccuparsi anche di centesimi. Dovrebbe essere possibile definire soglie in percentuale o in cifre assolute.
• Raccogli righe di errore di esempio. È utile se una regola di qualità dei dati fornisce un campione degli errori rilevati: normalmente, le chiavi (aziendali!) ei valori dei dati verificati sono sufficienti per esaminare l'errore. È una buona idea limitare il numero di righe di errore scritte per una regola di qualità dei dati.
• A volte, potresti trovare "errori noti" nei dati che non verranno corretti ma vengono rilevati da utili controlli di qualità dei dati. Per questi casi, si consiglia l'uso di whitelist (chiavi di record che dovrebbero essere saltate da un controllo della qualità dei dati).

Altri metadati

I metadati sono importanti per instradare l'"analisi" e monitorare le fasi del ciclo di controllo della qualità dei dati.

• Articoli controllati. Aiuta ad assegnare le tabelle e i campi selezionati a una regola di qualità dei dati. Se disponi di un sistema di metadati avanzato, ciò potrebbe aiutare ad assegnare automaticamente gli utenti dei dati e un proprietario dei dati a questa regola. Per motivi normativi (come BCBS 239), è inoltre necessario dimostrare come i dati vengono verificati da DQ. Tuttavia, l'assegnazione automatica di regole agli utenti/proprietari di dati tramite la linea di dati (*) potrebbe essere un'arma a doppio taglio (vedi sotto).
• Utente dei dati. Ogni regola DQ deve avere almeno un utente dati/unità utente dati assegnata per verificare il risultato durante la fase di "Analisi" e decidere se e come un risultato influenza il loro lavoro con i dati.
• Titolare dei dati. A ogni regola DQ deve essere assegnato un proprietario dei dati.

(*) La linea dei dati mostra il flusso di dati tra due punti. Con la derivazione dei dati, puoi trovare tutti gli elementi di dati che influenzano un determinato campo target all'interno del tuo magazzino.

L'utilizzo della derivazione dei dati per assegnare gli utenti alle regole può essere problematico. Come accennato in precedenza, gli utenti aziendali di solito conoscono solo il livello del data mart (e il sistema operativo), ma non i livelli inferiori del data warehouse. Effettuando la mappatura tramite la derivazione dei dati, agli utenti dei dati verranno assegnate regole con cui non hanno familiarità. Per i livelli inferiori, potrebbe essere necessario personale IT per valutare un risultato sulla qualità dei dati. In molti casi, può essere utile una mappatura manuale o un approccio misto (mappatura tramite derivazione dei dati solo all'interno del data mart).

Misurare la qualità dei dati

Misurare la qualità dei dati significa eseguire le regole di qualità dei dati disponibili, che dovrebbero essere eseguite automaticamente , innescate dai processi di caricamento del data warehouse. Come abbiamo visto in precedenza, potrebbe esserci un numero notevole di regole sulla qualità dei dati, quindi i controlli richiederanno molto tempo.

In un mondo perfetto, un data warehouse verrebbe caricato solo se tutti i dati sono privi di errori. Nel mondo reale, questo è raramente il caso (realisticamente, non è quasi mai il caso). A seconda della strategia di caricamento complessiva del data warehouse, il processo di qualità dei dati dovrebbe o non dovrebbe (quest'ultimo è molto più probabile) governare il processo di caricamento. È un buon progetto avere processi di qualità dei dati (reti di lavoro) paralleli e collegati ai processi di caricamento del data warehouse “normali”.

Se ci sono accordi sul livello di servizio definiti, assicurati di non ostacolare i carichi del data warehouse con i controlli della qualità dei dati. Errori/anomalie nei processi di qualità dei dati non dovrebbero interrompere il normale processo di caricamento. Gli errori imprevisti all'interno dei processi di qualità dei dati dovrebbero essere segnalati e mostrati per la fase di “Analisi” (vedi capitolo successivo).

Tieni presente che una regola di qualità dei dati potrebbe bloccarsi a causa di errori imprevisti (forse la regola stessa è stata implementata in modo errato o la struttura dei dati sottostante è cambiata nel tempo). Sarebbe utile se il tuo sistema di qualità dei dati fornisse un meccanismo per disattivare tali regole, soprattutto se la tua azienda ha poche versioni all'anno.

I processi DQ dovrebbero essere eseguiti e segnalati il ​​prima possibile , idealmente, subito dopo il caricamento dei dati controllati. Ciò consente di rilevare gli errori il prima possibile durante il caricamento del data warehouse (alcuni carichi complessi del sistema di warehouse hanno una durata di diversi giorni).

Analizzare

In questo contesto, "analizzare" significa reagire ai risultati sulla qualità dei dati. Questa è un'attività per gli utenti dati assegnati e il proprietario dei dati.

Il modo di reagire dovrebbe essere chiaramente definito dal progetto sulla qualità dei dati. Gli utenti dei dati dovrebbero essere obbligati a commentare una regola con risultati (almeno regole con semaforo rosso), spiegando quali misure vengono prese per gestire il risultato. Il titolare dei dati deve essere informato e dovrebbe decidere insieme all'utente o agli utenti dei dati.

Sono possibili le seguenti azioni:

• Problema serio: il problema deve essere risolto e il caricamento dei dati ripetuto.
• Il problema è accettabile: prova a risolverlo per futuri carichi di dati e gestisci il problema all'interno del data warehouse o del reporting.
• Regola DQ difettosa: correggi la regola DQ problematica.

In un mondo perfetto, ogni problema di qualità dei dati verrebbe risolto. Tuttavia, la mancanza di risorse e/o tempo spesso porta a soluzioni alternative.

Per poter reagire in tempo, il sistema DQ deve informare gli utenti dei dati sulle "loro" regole con i risultati. L'utilizzo di una dashboard della qualità dei dati (magari con l'invio di messaggi che è emerso qualcosa) è una buona idea. Prima gli utenti vengono informati sui risultati, meglio è.

La dashboard sulla qualità dei dati dovrebbe contenere:

• Tutte le regole assegnate a un determinato ruolo
• I risultati delle regole (semaforo, misure e righe di esempio) con la possibilità di filtrare le regole per risultato e dominio dei dati
• Un commento obbligatorio che gli utenti dei dati devono inserire per i risultati
• Una funzionalità che facoltativamente "sovrastalla" il risultato (se la regola di qualità dei dati segnala errori dovuti a un'implementazione difettosa, ad esempio). Se più di una business unit ha la stessa regola di qualità dei dati assegnata, l'"overruling" è valido solo per la business unit dell'utente dei dati (non per l'intera azienda).
• Mostrare regole che non sono state eseguite o che sono state modificate

Il dashboard dovrebbe anche mostrare lo stato corrente del processo di caricamento del data warehouse recente, offrendo agli utenti una visione a 360 gradi del processo di caricamento del data warehouse.

Il proprietario dei dati è responsabile di assicurarsi che ogni risultato sia stato commentato e che lo stato della qualità dei dati (originale o annullato) sia almeno giallo per tutti gli utenti dei dati.

Per una rapida panoramica, sarebbe utile creare una sorta di semplici KPI (indicatori chiave di prestazione) per gli utenti/proprietari dei dati. Avere un semaforo generale per tutti i risultati delle regole associate è abbastanza facile se a ciascuna regola viene assegnato lo stesso peso.

Personalmente, penso che calcolare un valore complessivo della qualità dei dati per un determinato dominio di dati sia piuttosto complesso e tenda ad essere cabalistico, ma potresti almeno mostrare il numero di regole complessive raggruppate per risultato per un dominio di dati (ad es. "100 regole DQ con il 90% di risultati verdi, 5% gialli e 5% rossi”).

È compito del proprietario dei dati garantire che i risultati vengano corretti e la qualità dei dati migliorata.

Miglioramento dei processi

Poiché i processi del data warehouse cambiano spesso, anche il meccanismo della qualità dei dati necessita di manutenzione.

Un titolare dei dati dovrebbe sempre occuparsi dei seguenti punti:

• Tienilo aggiornato. I cambiamenti nel data warehouse devono essere catturati nel sistema di qualità dei dati.
• Migliorare. Implementare nuove regole per gli errori che non sono ancora coperti dalle regole sulla qualità dei dati.
• Semplifica. Disabilita le regole di qualità dei dati che non sono più necessarie. Consolidare le regole sovrapposte.

Monitoraggio dei processi di qualità dei dati

Il monitoraggio dell'intero processo di qualità dei dati aiuta a migliorarlo nel tempo.

Le cose che vale la pena guardare sarebbero:

• La copertura dei tuoi dati con regole sulla qualità dei dati
• La percentuale di risultati sulla qualità dei dati all'interno delle regole attive nel tempo
• Il numero di regole di qualità dei dati attive (tienilo d'occhio: ho visto utenti di dati risolvere i loro risultati semplicemente disabilitando un numero sempre maggiore di regole di qualità dei dati).
• Il tempo necessario all'interno di un carico di dati per avere tutti i risultati valutati e corretti

Conclusione

Molti dei seguenti punti sono importanti in qualsiasi tipo di progetto.

Anticipare la resistenza. Come abbiamo visto, se non ci sono problemi di qualità urgenti, la qualità dei dati è spesso vista come un onere aggiuntivo senza offrire nuove funzionalità. Tieni presente che potrebbe creare un carico di lavoro aggiuntivo per gli utenti dei dati. In molti casi, la conformità e le richieste normative possono aiutarti a convincere gli utenti a considerarlo un requisito inevitabile.

Trova uno sponsor. Come notato sopra, DQ non è un articolo di vendita rapida, quindi è necessario un potente sponsor/stakeholder: più in alto nella gestione, meglio è.

Trova alleati. Come con lo sponsor, chiunque condivida l'idea di una forte qualità dei dati sarebbe molto utile. Il circuito DQ è un processo continuo e ha bisogno di persone per mantenere vivo il circuito.

Inizia in piccolo. Se finora non è stata adottata una strategia DQ, cerca una business unit che necessiti di una migliore qualità dei dati. Costruisci un prototipo per mostrare loro il vantaggio di dati migliori. Se il tuo compito è migliorare o addirittura sostituire una determinata strategia di qualità dei dati, osserva le cose che funzionano bene/sono accettate nell'organizzazione e mantienile.

Non perdere di vista l'intero quadro. Sebbene inizi in piccolo, tieni presente che alcuni punti, in particolare i ruoli, sono prerequisiti per una strategia DQ di successo.

Una volta implementato, non lasciarti andare. Il processo di qualità dei dati deve essere parte dell'uso del data warehouse. Nel tempo, l'attenzione sulla qualità dei dati tende a perdersi un po' e sta a te mantenerla.