La qualificazione dei dati è critica
Wikipedia elenca sette fasi per un processo di data analysis: requisiti dei dati, raccolta dei dati, elaborazione dei dati, pulizia dei dati, analisi esplorativa dei dati, modellazione dei dati, e infine la generazione dei risultati di produzione. Quando Lokad prevede l’inventario, ottimizza i prezzi, o ogni volta che affrontiamo una qualche forma di ottimizzazione commerciale, il nostro processo è molto simile a quello descritto sopra. Tuttavia, c’è un’altra fase vitale che tipicamente richiede oltre la metà dello sforzo generalmente applicato dal team di Lokad e che non fa nemmeno parte dell’elenco sopra. Questa fase è la qualificazione dei dati.
Ora che il “Big Data” è diventato una parola d’ordine, innumerevoli aziende stanno cercando di fare di più con i loro dati. La qualificazione dei dati è probabilmente la seconda causa principale dei fallimenti dei progetti, subito dopo obiettivi di business poco chiari o sconsiderati - cosa che accade ogni volta che un’iniziativa parte dalla “soluzione” anziché dal “problema”. Facciamo un po’ luce su questo misterioso passaggio di “qualificazione dei dati”.
I dati come sottoprodotto delle applicazioni aziendali
La stragrande maggioranza dei software aziendali è progettata per aiutare a gestire le aziende: il sistema di Punto vendita è lì per permettere ai clienti di pagare; il sistema di gestione del Magazzino è lì per prelevare e immagazzinare prodotti; il software per videoconferenze permette alle persone di svolgere le riunioni online, ecc. Questo software potrebbe produrre anche dati, ma i dati sono solo un sottoprodotto secondario dello scopo primario di questo software.
I sistemi menzionati sono progettati per gestire l’azienda e, di conseguenza, ogni volta che un operatore deve scegliere tra operazioni migliori o dati migliori, le operazioni migliori saranno sempre preferite. Ad esempio, se un codice a barre non funziona durante la scansione al punto vendita del tuo ipermercato locale, il cassiere sceglierà invariabilmente un prodotto che per caso ha lo stesso prezzo e lo scannerà due volte; a volte utilizza persino un foglio con una lista di codici a barre come promemoria. Il cassiere ha ragione: la priorità numero uno è far pagare il cliente a ogni costo. Generare registrazioni di stock accurate non è un obiettivo immediato se paragonato all’urgente necessità di servire una fila di clienti.
Si potrebbe sostenere che il problema della scansione dei codici a barre sia in realtà un problema di pulizia dei dati. Tuttavia, la situazione è piuttosto sottile: i record rimangono accurati in una certa misura, poiché l’importo addebitato al cliente rimane corretto, così come anche il conteggio degli articoli nel carrello. Filtrare ingenuamente tutti i record sospetti farebbe più male che bene per la maggior parte delle analisi.
Eppure, osserviamo che troppo spesso le aziende – e anche i loro fornitori di software – ignorano con entusiasmo questo schema fondamentale per quasi tutti i dati aziendali generati, passando direttamente dall’elaborazione dei dati alla pulizia dei dati.
La qualificazione dei dati riguarda la semantica dei dati
L’obiettivo della fase di qualificazione dei dati è chiarire e documentare in modo approfondito la semantica dei dati. La maggior parte delle volte, quando le aziende (di grandi dimensioni) inviano file dati in formato tabellare a Lokad, ci inviano anche un foglio Excel, in cui ogni colonna presente nei file viene accompagnata da una breve riga di documentazione, tipicamente come: Price: il prezzo del prodotto. Tuttavia, una documentazione così breve lascia aperte una miriade di domande:
- qual è la valuta applicabile per il prodotto?
- si tratta di un prezzo con o senza tasse?
- esiste qualche altra variabile (come uno sconto) che influisce sul prezzo effettivo?
- è davvero lo stesso prezzo per il prodotto su tutti i canali?
- il valore del prezzo dovrebbe avere senso per i prodotti non ancora venduti?
- esistono casi limite come gli zero per indicare valori mancanti?
Le date sono anche ottime candidate per ambiguità semantiche quando una tabella orders contiene una colonna date, in quanto la data e l’ora possono riferirsi al momento di:
- la validazione del carrello
- l’inserimento del pagamento
- la conferma del pagamento
- la creazione dell’ordine nel software contabile
- la spedizione
- la consegna
- la chiusura dell’ordine
Tuttavia, una lista così breve copre a malapena le stranezze reali riscontrate nelle situazioni di vita reale. Recentemente, ad esempio, lavorando per una delle più grandi aziende online europee, ci siamo resi conto che le date associate agli ordini di acquisto non avevano lo stesso significato a seconda del paese di origine delle fabbriche fornitrici. I fornitori europei spedivano con camion e la data rifletteva l’arrivo in magazzino, mentre i fornitori asiatici spedivano, insomma, con navi, e la data rifletteva l’arrivo al porto. Questa piccola svolta rappresentava tipicamente una differenza di oltre 10 giorni nel calcolo del lead time.
Per i set di dati legati al business, la semantica dei dati dipende quasi sempre dai processi e dalle pratiche aziendali sottostanti. La documentazione relativa a tali processi, quando esiste, si concentra tipicamente su ciò che interessa al management o agli auditor, ma molto raramente sulla miriade di minuscoli elementi che esistono nell’ambiente IT aziendale. Tuttavia, il diavolo sta nei dettagli.
La qualificazione dei dati non è la pulizia dei dati
La pulizia (o cleansing) dei dati ha più senso nelle scienze sperimentali, dove alcuni punti dati (outlier) devono essere rimossi perché altrimenti distorcerebbero in modo errato gli esperimenti. Ad esempio, le misurazioni di un grafico in un esperimento di ottica potrebbero semplicemente riflettere un difetto nel sensore ottico piuttosto che qualcosa di realmente rilevante per lo studio.
Tuttavia, questo processo non riflette ciò che è tipicamente necessario nell’analisi dei dati aziendali. Gli outlier potrebbero essere riscontrati gestendo i residui di un recupero del database andato male, ma per lo più gli outlier sono marginali. L’integrità (dal punto di vista aziendale) della stragrande maggioranza dei database attualmente in produzione è eccellente. Esistono voci errate, ma la maggior parte dei sistemi moderni fa un buon lavoro nel prevenire le più frequenti, e supporta in modo adeguato anche la loro correzione successiva. Tuttavia, la qualificazione dei dati è molto diversa in quanto l’obiettivo non è rimuovere o correggere i punti dati, ma piuttosto fare luce sui dati nel loro insieme, in modo che l’analisi successiva abbia davvero senso. L’unica cosa che viene “alterata” dal processo di qualificazione dei dati è la documentazione originale dei dati.
La qualificazione dei dati rappresenta la maggior parte dello sforzo
Lavorando con decine di progetti basati sui dati relativi al commercio, all’aerospazio, all’ospitalità, alla bioinformatica, all’energia, abbiamo osservato che la qualificazione dei dati è sempre stata la fase più impegnativa del progetto. Gli algoritmi di Machine learning potrebbero sembrare sofisticati, ma finché l’iniziativa rimane entro i confini ben noti dei problemi di regressione o classificazione, il successo nel machine learning è principalmente una questione di conoscenza pregressa del dominio. Lo stesso vale per l’elaborazione dei Big Data.
I problemi di qualificazione dei dati sono insidiosi perché non sai cosa ti manca: questo è l’abisso semantico tra la semantica “vera”, così come dovrebbe essere intesa in termini dei dati prodotti dai sistemi in uso, e la semantica “effettiva”, come percepita dalle persone che eseguono l’analisi dei dati. Ciò che non conosci può farti male. A volte, l’abisso semantico invalida completamente l’intera analisi.
Osserviamo che la maggior parte degli operatori IT sottovaluta enormemente la profondità delle peculiarità che accompagnano la maggior parte dei dataset aziendali reali. La maggior parte delle aziende non dispone nemmeno di una riga completa di documentazione per ogni campo della tabella. Eppure, di solito constatamo che anche con mezza pagina di documentazione per campo, la documentazione è tutt’altro che esaustiva.
Una delle (numerose) sfide che Lokad deve affrontare è che è difficile far pagare qualcosa che non è nemmeno percepito come una necessità in primo luogo. Pertanto, spesso inglobiamo il lavoro di qualificazione dei dati sotto il nome di compiti più nobili come la “messa a punto di algoritmi statistici” o attività simili dal suono scientifico.
La realtà del lavoro, tuttavia, è che la qualificazione dei dati non è solo intensiva dal punto di vista della manodopera, ma è anche un compito davvero impegnativo in sé. È un mix tra la comprensione del business, la comprensione di come i processi si distribuiscono su molti sistemi - alcuni dei quali inevitabilmente di tipo legacy - e il superamento del divario tra i dati in uscita e le aspettative della pipeline di machine learning.
La maggior parte delle aziende investe poco nella qualificazione dei dati. Oltre a essere una sfida sottovalutata, investire talento nella qualificazione dei dati non si traduce in una demo appariscente o addirittura in numeri concreti. Di conseguenza, le aziende si precipitano nelle fasi successive del processo di analisi dei dati, solo per ritrovarsi a nuotare nel melassa perché nulla funziona davvero come previsto. Non esiste una soluzione rapida per una reale comprensione dei dati.
