Che i dati siano il nuovo petrolio e che l’informazione sia ormai digitale è evidente anche dalla risonanza mediatica generata dai tentativi di appropriazione fraudolenta e dalla sempre più alta attenzione ai temi della privacy e dell’identità (e memoria) digitale. Raffinare questo materiale per produrre informazione a valore aggiunto richiede tecniche di analisi avanzate (data/text mining, machine learning, deep learning) ed un metodo non lineare, poco rassicurante per chi è solito trattare sistemi informatici tradizionali, nei quali un problema è sempre traducibile in una stima piuttosto definita e ben controllabile in termini di spesa e risultato.
Quali le competenze necessarie per trarre informazioni dai dati
Parlando di competenze, siamo oltre il perimetro della statistica descrittiva e si fa riferimento alla figura del data scientist, ormai in esplosione quale professionalità del futuro più prossimo. Un profilo non nuovo ma rivitalizzato dal trend big data, centrato sul filone delle scienze fisico/matematiche/linguistiche piuttosto che sulla competenza informatica. Servono infatti un’attitudine a lavorare con i dati, un pensiero meno condizionato da nessi diretti causa-effetto, meno deterministico, in grado di elaborare una teoria verosimile senza l’urgenza del quantificare ma con l’attenzione alla qualificazione e valutazione.
Il dominio in cui si opera non è un’invariante e serve considerare la tipologia di fenomeno che si studia, poiché un ambito meccanico ha caratteristiche strutturali diverse da un sistema di molecole organiche o da un rilevatore di segnali in frequenza e potenza. Anche il formato del dato porta una sua specificità, poiché trattare valori alfanumerici strutturati piuttosto che immagini, testi brevi o lunghi, stream video/audio implica l’utilizzo di tecniche specifiche. Servono sicuramente conoscenze specialistiche ma una sola specializzazione è quasi sempre insufficiente. Per questo è fondamentale poter attingere a competenze diverse con una capacità di dialogo mediato da un linguaggio preciso ma non troppo settoriale.
Se la competenza informatica non è quella qualificante per il profilo del data scientist, bisogna però considerare anche il contesto in cui si opera. Se si lavora con tool grafici, che offrono il grande vantaggio ma anche il limite di poter disporre di funzioni pronte all’uso, allora quell’affermazione è sicuramente vera, ed è questo un ambito molto frequentato dagli statistici. Lo stesso vale quando si lavora su architetture tradizionali e l’operato del data scientist si può applicare a data set trattabili con ragionevoli performance su una singola macchina. Se però siamo in un’architettura big data, in cui la preparazione dei dati e l’esecuzione degli algoritmi necessitano della potenza di un cluster per poter distribuire carichi e processi, allora la competenza informatica non è più trascurabile. Infatti, se è vero che un data scientist è sicuramente in grado di ipotizzare un buon modello teorico e implementarlo con un linguaggio di programmazione, non è altrettanto vero che sia immediatamente in grado di produrre anche buon codice, soprattutto quando il tema del computing distribuito, del risparmio di risorse e dell’efficienza in performance sia fondamentale.
Data scientist: il metodo di lavoro
Per quanto riguarda il metodo di lavoro, siamo in un modello data-driven, assolutamente incompatibile con la rigidità e chiarezza di metodi tradizionali come il waterfall, ma molto più vicino alle più recenti metodologie di sviluppo agile.
Un approccio data-driven significa iniziare dai dati e non dai processi, da quelli materialmente prodotti in una specifica realtà e non solo teoricamente offerti da un certo sistema. Infatti, a parità di tracciato dati e di applicativo di raccolta, due realtà diverse potranno produrre dati molto differenti: immaginiamo, ad esempio, quanto diversi possano essere i dati raccolti dal modulo SAP VM (gestione magazzino) di un’azienda aeronautica o di un’azienda di grande distribuzione, così come saranno ben lontani i dati di CRM di una società che venda beni di lusso rispetto a quelli di una che commercializzi oggetti di largo consumo. Pur trattando formalmente gli stessi dati, magari gestiti anche dagli stessi rigidi applicativi, i contenuti saranno molto diversi, per numerosità, per distribuzione dei valori, per grado di movimentazione e per completezza stesso del dato. In altri termini, la distribuzione delle variabili, le campionature e le casistiche da trattare in fase di preparazione del dato, dipendono fortemente dai singoli contesti; ciò significa anche che non è affatto scontato che un modello realizzato in una certa realtà sia immediatamente utilizzabile in un’altra, anche se affine.
Qualunque ipotesi di studio, anche in ambienti ben noti, non può prescindere da una prima attività di data profiling, volta a capire la distribuzione dei valori (variabili) e a far emergere tutte le particolarità di contesto che si riflettono in casistiche specifiche da affrontare per la corretta preparazione dei dati. L’importanza di queste fasi preliminari, di molto sottovalutate, cresce esponenzialmente quando si voglia trattare un dato meno noto e per il quale potrebbero essere necessari modelli non deterministici già nei momenti più esplorativi o per controllare e trasformare in conoscenza la loro stessa variabilità.
Un approccio data-driven, deve fare i conti fino in fondo con l’incertezza del risultato in un tempo definito, nella consapevolezza però che un risultato è possibile quasi sempre e potenzialmente può essere anche molto importante. Quando i dati ci sono, di fatto si tratta solo di tempo e capacità; il metodo non può che essere iterativo ed euristico, per cicli di apprendimento successivi, dove un risultato c’è sempre, almeno a livello di conoscenza. Se può spaventare la non garanzia del risultato in tempi certi, in realtà questo approccio si sposa bene con i princìpi guida delle metodologie agili: iterazioni controllate, validazione dei risultati anche con il coinvolgimento dell’utente di business, correzioni e cambiamenti di rotta in itinere seguendo i filoni di indagine più promettenti che emergono durante il percorso.
Data-driven non significa però senza obiettivo, perché anche le iterazioni diventano più rapide quanto più sono orientate verso una chiara finalità; tuttavia bisogna sempre ammettere la possibilità dell’insuccesso, almeno nelle prime iterazioni che serviranno comunque ad affinare l’obiettivo o la strategia implementativa.
Un modello process-driven, una volta chiarito, strutturato, implementato e verificato si può considerare concluso, nel senso che verrà utilizzato ma il suo potenziale è del tutto espresso. Al contrario, un modello data-driven non raggiunge mai la sua conclusione proprio perché i dati cambiano nel tempo generando continuamente nuovo potenziale. Per questo, un’azienda data-driven dovrebbe prevedere una continua attività esplorativa sui dati e un laboratorio di data science permanente.
Possiamo quindi concludere dicendo che, per distillare valore dalla moltitudine di dati disponibili, non basta cambiare architettura tecnologica, ma serve sicuramente cambiare modello di sviluppo e qualche volta anche modello organizzativo.
Grazia Cazzin
