La qualificazione dei dati è fondamentale
Wikipedia elenca sette passaggi per un processo di analisi dei dati: 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 un tipo qualsiasi di ottimizzazione commerciale, il nostro processo è molto simile a quello descritto sopra. Tuttavia, c’è un altro passaggio vitale che di solito richiede più della metà di tutti gli sforzi applicati tipicamente dal team di Lokad e che non fa nemmeno parte della lista sopra. Questo passaggio è la qualificazione dei dati.
Ora che il “Big Data” è diventato un termine di moda, miriadi di aziende stanno cercando di fare di più con i loro dati. La qualificazione dei dati è probabilmente la seconda causa più comune di fallimento dei progetti, subito dopo obiettivi aziendali poco chiari o poco saggi - che accade ogni volta che un’iniziativa parte dalla “soluzione” anziché partire dal “problema”. Facciamo luce su questo misterioso passaggio della “qualificazione dei dati”.
I dati come sottoprodotto delle applicazioni aziendali
La stragrande maggioranza del software aziendale è progettato per aiutare a gestire le aziende: il sistema di punto vendita è lì per consentire ai clienti di pagare; il Sistema di Gestione del Magazzino è lì per prelevare e conservare i prodotti; il software di Web Conferencing consente alle persone di svolgere le riunioni online, ecc. Tale software potrebbe anche produrre dati, ma i dati sono solo un sottoprodotto secondario dello scopo principale di questo software.
I sistemi menzionati sono progettati per gestire l’azienda e, di conseguenza, ogni volta che un professionista deve scegliere tra una migliore gestione o migliori dati, la migliore gestione sarà sempre sempre favorita. Ad esempio, se un codice a barre fallisce durante la scansione al punto vendita del tuo ipermercato locale, il cassiere sceglierà invariabilmente un prodotto che ha lo stesso prezzo e lo scannerà due volte; a volte hanno persino un foglio di trucchi con tutti i codici a barre raccolti su un pezzo di carta. Il cassiere ha ragione: la priorità numero uno è far pagare il cliente a prescindere. Generare registri di stock accurati non è un obiettivo immediato rispetto alla necessità urgente di servire una fila di clienti.
Si potrebbe sostenere che il problema della scansione del codice a barre è in realtà un problema di pulizia dei dati. Tuttavia, la situazione è piuttosto sottile: i registri rimangono accurati fino a un certo punto poiché l’importo addebitato al cliente rimane corretto e così 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 entusiasticamente questo modello 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
Lo scopo del passaggio di qualificazione dei dati è chiarire e documentare in modo approfondito la semantica dei dati. La maggior parte delle volte, quando le aziende (grandi) inviano file di dati tabulari a Lokad, ci inviano anche un foglio Excel, in cui ogni colonna presente nei file riceve una breve descrizione, tipicamente come: Prezzo: il prezzo del prodotto. Tuttavia, una tale breve descrizione lascia aperte una miriade di domande:
- quale è la valuta applicabile al prodotto?
- è un prezzo con o senza tasse?
- c’è 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 che non sono ancora venduti?
- ci sono situazioni particolari come zeri per riflettere valori mancanti?
Anche le date sono ottime candidate per ambiguità semantiche quando una tabella ordini contiene una colonna data, il data-ora può riferirsi al momento di:
- convalida del carrello
- registrazione del pagamento
- autorizzazione del pagamento
- creazione dell’ordine nel pacchetto contabile
- spedizione
- consegna
- chiusura dell’ordine
Tuttavia, una lista così breve difficilmente copre le stranezze effettive riscontrate nelle situazioni reali. Di recente, ad esempio, mentre lavoravamo 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 dei fornitori. I fornitori europei spedivano utilizzando camion e la data rifletteva l’arrivo nel magazzino; mentre i fornitori asiatici spedivano utilizzando, beh, navi, e la data rifletteva l’arrivo al porto. Questo piccolo “colpo di scena” di solito comportava una differenza di oltre 10 giorni nel calcolo del tempo di consegna.
Per i dataset legati all’attività aziendale, 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 alla direzione o agli ispettori, ma molto raramente sugli innumerevoli piccoli elementi che esistono all’interno del panorama IT aziendale. Eppure, il diavolo si nasconde nei dettagli.
La qualificazione dei dati non è la pulizia dei dati
La pulizia dei dati ha più senso nelle scienze sperimentali in cui determinati punti dati (outlier) devono essere rimossi perché potrebbero “distorcere” in modo errato gli esperimenti. Ad esempio, le misurazioni dei grafici in un esperimento ottico potrebbero semplicemente riflettere un difetto nel sensore ottico anziché qualcosa di effettivamente rilevante per lo studio.
Tuttavia, questo processo non riflette ciò che è tipicamente necessario durante l’analisi dei dati aziendali. Gli outlier potrebbero essere incontrati quando si tratta dei residui di un recupero del database fallito, ma nella maggior parte dei casi 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 ottimo lavoro nel prevenire le più frequenti e fornisce un buon supporto anche per la correzione successiva. Tuttavia, la qualificazione dei dati è molto diversa nel senso che l’obiettivo non è né quello di rimuovere né di correggere i punti dati, ma piuttosto di 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 è la parte più impegnativa
Mentre lavoravamo a dozzine di progetti basati sui dati legati al commercio, all’aerospaziale, all’ospitalità, alla bioinformatica, all’energia, abbiamo osservato che la qualificazione dei dati è sempre stata la fase più impegnativa del progetto. Gli algoritmi di apprendimento automatico potrebbero sembrare sofisticati, ma finché l’iniziativa rimane all’interno dei confini ben noti dei problemi di regressione o classificazione, il successo nell’apprendimento automatico dipende principalmente dalla conoscenza del dominio. Lo stesso vale per l’elaborazione dei Big Data.
I problemi di qualificazione dei dati sono insidiosi perché non sai cosa ti stai perdendo: questa è la differenza semantica tra la semantica “vera” come dovrebbe essere intesa in termini dei dati prodotti dai sistemi in uso e la semantica “effettiva”, come percepita dalle persone che effettuano l’analisi dei dati. Ciò che non sai può farti del male. A volte, il divario semantico invalida completamente l’intera analisi.
Osserviamo che la maggior parte degli specialisti IT sottovaluta notevolmente la profondità delle “peculiarità” che accompagnano la maggior parte dei dataset aziendali reali. La maggior parte delle aziende non ha nemmeno una riga completa di documentazione per campo di tabella. Eppure, di solito scopriamo che anche con mezza pagina di documentazione per campo, la documentazione è ancora lontana dall’essere completa.
Una delle (molte) sfide affrontate da Lokad è che è difficile addebitare qualcosa che non viene nemmeno percepito come un bisogno in primo luogo. Pertanto, spesso ci troviamo a svolgere il lavoro di qualificazione dei dati sotto mentite spoglie di compiti più nobili come “ottimizzazione di algoritmi statistici” o compiti simili che suonano scientifici.
La realtà del lavoro, tuttavia, è che la qualificazione dei dati non è solo intensiva dal punto di vista delle risorse umane, ma è anche un compito veramente impegnativo di per sé. È un mix tra la comprensione del business, la comprensione di come i processi si diffondono su molti sistemi - alcuni dei quali inevitabilmente di tipo legacy - e il colmare il divario tra i dati come escono e le aspettative del flusso di lavoro di machine learning.
La maggior parte delle aziende investe molto poco nella qualificazione dei dati. Oltre ad essere una sfida sottovalutata, investire in talento per la qualificazione dei dati non porta a una dimostrazione appariscente o a numeri effettivi. Di conseguenza, le aziende si affrettano alle fasi successive del processo di analisi dei dati solo per trovarsi a nuotare nel miele perché niente funziona davvero come previsto. Non esiste una soluzione rapida per una comprensione effettiva dei dati.
