Tra le varie definizioni che si possono dare della qualità, la più aderente a un approccio oggettivo è quella che la descrive come “l’insieme delle caratteristiche che determinano la rispondenza di un bene alla funzione cui è destinato”. La qualità è quindi una dote relativa, e ciò vale non solo per i beni materiali, ma per tutte le cose cui il concetto si può applicare, quindi anche per la conoscenza, le informazioni, i dati. Questa riflessione ci fa capire come, prima di avviare un qualsiasi progetto di qualità e governo dei dati, si debba stabilire ciò che i destinatari dei dati si aspettano di avere e come sia utile che queste attese siano formalizzate in un Data Quality Service Level Agreement (DQ Sla) che permetta di monitorare la conformità dei dati e dei processi associati a quanto stabilito e indichi ruoli e responsabilità dei gestori dei dati in modo da intervenire con azioni mirate.
Esattamente come nel concetto classico di Sla, il DQ Sla è un contratto tra fornitori e utenti dei dati che specifica le attese di questi ultimi rispetto a una serie di parametri di qualità; fino a che punto si possa accettare uno scostamento da quanto stabilito ed entro quali termini questo vada corretto per ripristinare la normalità. Un ‘white paper’ pubblicato da DataFlux, software house specializzata in soluzioni di Enterprise data quality, data integration e Master data management, acquisita nel 2000 da Sas, suggerisce un modello in base al quale stilare un DQ Sla. Perché sia efficace, il documento deve descrivere in dettaglio: i valori in base ai quali definire le attese degli utenti (cioè il livello di qualità dei dati); i criteri in base ai quali attuarne il monitoraggio e controllo; i punti da determinare affinché i livelli di qualità attesi siano soddisfatti e i processi da porre in atto qualora non lo siano. Quest’ultima parte risulta, per gli aspetti di processo coinvolti, la più complessa da realizzare e dalla quale le altre due sono, di fatto, dipendenti. Per questo conviene che, sia pur brevemente, venga trattata in modo più approfondito.
Una check-list per il Data Quality Sla
Un Service level agreement sulla qualità dei dati deve, secondo DataFlux, considerare in dettaglio tutti i seguenti elementi:
1. Identificare i punti, nel flusso dei processi di business, che vanno coperti dallo Sla.
2. Identificare gli elementi critici dei dati che vanno coperti dallo Sla.
3. Identificare i parametri qualitativi associati ad ogni elemento critico dei dati.
4. Stabilire i livelli di qualità attesi per ciascun parametro degli elementi di cui al punto 2.
5. Definire regole di data quality che formalizzino i livelli attesi di cui al punto 4.
6. Valutare gli impatti sul business dovuti alla non conformità alle regole di cui al punto 5.
7. Definire i metodi per misurare l’eventuale non conformità alle regole di qualità dei dati.
8. Stabilire lo scostamento massimo accettabile per ciascun parametro misurato.
9. Stabilire come e dove i problemi relativi alla data quality debbano essere categorizzati, definiti secondo priorità e documentati.
10. Identificare le persone che devono essere avvisate al superamento dei limiti di cui al punto 8.
11. Definire i tempi attesi per risolvere o rimediare ai problemi di cui ai punti precedenti.
12. Definire un metodo di tracciatura del processo di ripristino della qualità dei dati.
13. Definire una strategia e una gerarchia di escalation delle operazioni qualora i tempi di cui al punto 11 non possano essere rispettati.
Per trarre vantaggio dalle attività suggerite da un DQ Sla (specie per i punti 5, 7, 9 e 12) occorre dotarsi di opportuni sistemi di supporto. In particolare questi sono necessari per la gestione delle regole di data quality, per il monitoraggio, misura e notifica degli eventi e per la classificazione, assegnazione priorità e tracciamento degli incidenti.
Le dimensioni della qualità
È importante, nella stesura di un DQ Sla, rendersi conto di come i problemi di qualità dei dati e i relativi interventi siano quasi sempre legati alla struttura dei processi di business, i quali determinano anche il tipo di qualità dati attesa degli utenti. Una volta che questa sia stata identificata (punti 1 e 2 della check-list) occorre formalizzarla, definendola secondo alcune ‘dimensioni’ identificabili nei seguenti parametri:
– Accuratezza: è il grado di precisione con il quale il dato rappresenta l’entità del mondo ‘reale’ cui si riferisce e può essere valutato rapportandolo a fonti ritenute accurate.
– Completezza: è la presenza di tutti gli elementi ritenuti necessari. Si misura sul rispetto di regole che definiscano gli attributi obbligatori, quelli opzionali e quelli inapplicabili.
– Aggiornamento: è l’intervallo di tempo tra l’evento e le disponibilità del dato che lo rappresenta. Si misura in funzione del tempo di aggiornamento degli elementi presenti nel dato e del tempo di propagazione di un nuovo dato nelle applicazioni.
– Attendibilità: è una caratteristica chiamata anche reasonability in quanto associata alla ’ragionevole aspettativa’ di consistenza degli attributi del dato rispetto a quelli di dati preesistenti o di differenti data-set, come ad esempio una serie storica.
– Consistenza strutturale: indica la consistenza nella rappresentazione di attributi di valore similare sia all’interno dello stesso data-set, sia nei data model associati e relative tabelle. Indica anche il grado di consistenza tra la rappresentazione dei valori archiviati e i tipi di dati usati per lo scambio d’informazioni.
– Identificabilità: si riferisce alla denominazione e rappresentazione univoca degli oggetti cui i dati si riferiscono. Una misura dell’identificabilità è, per esempio, la garanzia che non si possa creare un nuovo record se già ne esiste uno relativo alla stessa entità. L’unicità degli oggetti presenti in un data-set fa sì che si possa creare una chiave per accedere in modo univoco a una specifica entità e solo a quella.
Il controllo della qualità
Errori e inconvenienti che disattendono i principi che sono stati sopra elencati alterano o impediscono il flusso di informazioni che è alla base dei processi aziendali. Un DQ SLA deve quindi definire un sistema di controllo di qualità in grado di identificare quanto prima possibile un problema che possa impattare sui processi di business (come ai punti 1 e 2 della check-list) in modo da porvi tempestivamente rimedio. In particolare si deve essere certi che: 1) i controlli scattino nel momento in cui si verifica un evento pericoloso per la qualità dei dati; 2) vengano attuate le previste azioni a riparo o riduzione del danno; 3) le azioni correttive siano attuate in un tempo ragionevole; 4) un controllo relativo a un dato evento non venga ripetuto nel prosieguo del flusso informativo. Quest’ultima verifica dà agli utenti la garanzia che ogni problema a monte di un dato punto del flusso dati (vedi punto 1 della check-list) sia già stato identificato e risolto in tempo per non impattare sulle attività del punto successivo.
I controlli sui dati possono essere applicati a più livelli di granularità (sugli elementi dei dati, sul record completo e sull’intero data-set) e vanno istituiti lungo il processo di business coperto dal DQ Sla nei punti in cui il dato passa dalla produzione al consumo. Il processo di monitoraggio misura la conformità alle attese di quanto rilevato secondo regole che si possono applicare automaticamente grazie a uno specifico ‘motore’, ma vanno definite dal team responsabile della data quality nel metodo di misura, nell’unità di misura e nel livello di soglia riguardo le attese del business. Per concludere con un esempio: se la funzione commerciale si aspetta che l’indirizzo di tutti i clienti comprenda la provincia, ma può tollerare l’1% di errore, tale attesa va soddisfatta con la verifica della completezza del dato secondo la granularità relativa ai singoli elementi (metodo); con il controllo della percentuale dei record conformi alle specifiche (unità di misura) e ponendo il livello di soglia al 99%.
