Data quality e Data visualization
“I numeri parlano chiaro”. Quante volte sentiamo questa frase: per rafforzare una considerazione, per supportare una strategia, per giustificare una decisione. Nel mondo analytics questo intervento è probabilmente più evidente a livello di Data visualization. Non c’è infatti storytelling automatico che regga il confronto con il delicato, quasi chirurgico lavoro umano atto a stabilire quali informazioni servano realmente e, soprattutto, quali siano i metodi migliori per renderle chiare e incontrovertibili. Solo con gli ingredienti giusti si può preparare un buon piatto. Quando parliamo di analytics i nostri ingredienti sono i dati. Per certificarne la “bontà”, ovvero l’idoneità, e iniziare così la nostra ricetta senza (troppi) pensieri è necessario compiere tutta una serie di attività che possiamo definire “preliminari” all’utilizzo vero e proprio dei dati stessi, e che possiamo far rientrare tutte sotto il termine Data quality.
Il ricorso a una tabella invece che a un grafico e, nel caso, il tipo di grafico; le modalità di interazione (drill-down e drill-through); i colori (sì, importanti pure quelli); la politica di profilazione, ovvero chi vede cosa. E, soprattutto, la decisione su quali informazioni mostrare (e quindi quali no). Tutte scelte, dettate dal confronto tra gruppi di lavoro e basate sulle esperienze dei singoli componenti, che determinano il modo in cui far parlare i numeri. L’“obiettività” di chi è coinvolto nel difendere una visione del dato (e quindi un’informazione) che dia un quadro reale della situazione, anche se talvolta amaro, risulta determinante.
Data quality, fase preliminare all’utilizzo dei dati
Si tratta di una fase molto onerosa e solo apparentemente poco gratificante. Per una serie di motivi:
– lavora fondamentalmente sulla ricerca dell’errore, sulla presenza di valori palesemente assurdi, su dati mancanti, su campi tra loro non coerenti; e, sulla base di queste rilevanze, deve ricercare una plausibile soluzione “a monte” (ovvero nei sistemi da cui i dati vengono estratti) oppure “a valle” (nei sistemi di business intelligence, dopo che questi dati sono stati estratti). Soprattutto nel primo caso si tratterà di coinvolgere altre persone (tipicamente i responsabili dei sistemi source) che di certo non saranno entusiaste di doversi occupare anche di questi che possiamo tranquillamente definire “problemi”;
– richiede competenze non solo tecniche, anche se a prima vista potrebbe sembrare, ma anche relative al contesto in cui si sta operando. È necessaria, in altre parole, una sensibilità del dato di cui si vuole certificare la qualità: ad esempio, devo sapere che una data deve essere “logicamente” meno recente di un’altra per poter certificare i record come “buoni”, così come devo sapere come distinguere materia prima da prodotto finito così da evidenziare situazioni in cui l’uno o l’altro sia collocato nel magazzino sbagliato. In altre parole, la qualità del dato non è da vedersi solo da un punto di vista tecnico, ma anche logico;
– è una fase generalmente vista dal cliente come una seccatura non prevista e addirittura non necessaria, a cui pertanto dedicare il minor budget possibile.
La Data quality in tre punti
Invece la fase di Data quality è una parte fondamentale quanto delicata dalla quale dipende l’esito della “ricetta analytics”. Senza avere la pretesa di coprire tutti i possibili impatti di questa fase sul risultato finale, di seguito riportiamo solo tre considerazioni per dimostrarne l’importanza:
- Coerenza: nel caso di più tabelle dati, estratte da fonti diverse anche se simili, da aggregare in un sistema di Data visualization per la formazione di un “key performance indicator” o più genericamente di una metrica di sintesi, è evidente che le modalità di creazione ed estrazione dovranno essere le stesse per tutti i sistemi di origine. Questo, che a prima vista può sembrare scontato, spesso non lo è. Perché anche se tecnicamente tutto funziona (cioè il dato viene estratto correttamente) il tema è di coerenza logica del dato o meglio dell’informazione risultante. Se due laboratori periferici inviano al sistema della sede centrale i risultati dei test su due prodotti, ma uno di questi utilizza un processo logicamente differente dall’altro, ad esempio preselezionando i casi da sottoporre al test che voglio misurare, ne risulta che l’aggregazione in un’unica metrica di sintesi sarà logicamente errata, e come tale potrà portare a considerazioni fuorvianti (un esempio lampante e tristemente attuale è il tasso di positività globale del Covid, che non tiene conto delle diverse modalità di calcolo del totale dei tamponi effettuati nelle varie regioni).
- Importanza: così come nell’online, dove è fatalmente un prerequisito per procedere, anche nel retail offline, dalla grande distribuzione al fashion, la fidelizzazione del cliente finale è un obiettivo fondamentale, che almeno in teoria dovrebbe consentire un’analisi del cliente stesso per definire, ad esempio, strategie mirate di marketing o di demand planning. In un altro scenario, l’inserimento corretto e completo dei dati anagrafici relativi ai clienti B2B o ai fornitori all’interno di un sistema informativo aziendale dovrebbe consentire un’analisi descrittiva a livello es. geografico o di tipologia del soggetto. In entrambe le situazioni sopra descritte il tema è più che altro “culturale”, perché si tratta di trasmettere a chi si occupa di raccogliere e inserire questi dati che “tutto è importante”, anche quegli attributi che magari non sembrano a prima vista tali: sesso, città, età, composizione familiare (nel B2C), nazione/regione/provincia, dimensione, tipologia di rapporto (nel B2B). Trascurare la raccolta di alcuni dati perché considerati “accessori”, non controllandone la corretta gestione fino magari a inserire dati “fake” per velocizzare le operazioni, rischia di limitare fortemente la possibilità di analisi o, ancor peggio, di produrre analisi – e quindi alla fine strategie – potenzialmente erronee. Ancor più se si ha l’ambizione di utilizzare anche dati esterni, magari open, a integrazione dei dati disponibili all’interno dei sistemi aziendali.
- Durata: un progetto di Data quality non termina mai, o meglio non può essere considerato immutabile. La certificazione del dato deve essere sempre vista come una meta raggiunta a fatica ma non per questo definitiva, anzi. Ogni evoluzione, tecnica o di business, nello scenario in cui si opera potrebbe impattare su quanto fatto fino ad allora, costringendo a repentine azioni “a ritroso” per riportare il processo al livello precedentemente conseguito. Per farsi trovare pronti a situazioni di questo tipo occorre prevedere un ambiente di analytics “ad hoc” dedicato al Data quality: una specie di “sistema di alerting” che, tramite report o ancor meglio dashboard specifici, evidenzi i casi sospetti così da agire prontamente evitando che accada la cosa peggiore per un responsabile di analytics: ovvero, che arrivi la segnalazione (meglio, la lamentela) dall’utente. Questo sistema dedicato deve essere tenuto in considerazione nella definizione di un adeguato “effort” per la fase di Data quality.
Conclusioni
Si può dire che la fase di Data quality per la certificazione del dato rappresenta il primo – in termini sequenziali – ma forse anche il più insidioso e importante aspetto da considerare per realizzare un sistema solido di analytics, descrittivo o “advanced” che sia. Ma attenzione: Data quality non significa “il dato deve essere a posto sempre e comunque”.
Spesso ci si può imbattere in situazioni che, per essere risolte, devono essere necessariamente palesate al fruitore finale. Situazioni in cui l’evidenza della non qualità del dato avviene in un contesto di Data visualization, dove solo all’utente di business potrà risultare chiara l’incoerenza logica (e non tecnica) di quanto rappresentato. Questo probabilmente porterà a decisioni aziendali in termini di correzione e ottimizzazioni dei processi interni di creazione e raccolta del dato, così da garantire quella coerenza mancante e, in ultima istanza, la possibilità di avere informazioni solide. Ed è qui che trova soddisfazione, evidenza e forse addirittura gratificazione il duro lavoro di chi si occupa di Data quality.
