Tutti pensano che la Data Science (DS) e l’Intelligenza Artificiale (AI per Artificial Intelligence) possano magicamente risolvere qualsiasi problema, ma come molti di noi sanno l’esperienza sul campo è molto diversa. Le aspettative sono alte da parte delle aziende e molto spesso vengono disattese per motivi diversi, che vanno dalla scarsa disponibilità di dati, a una cattiva comprensione del problema, per arrivare all’incapacità di ingegnerizzare adeguatamente il processo sulle adeguate infrastrutture informatiche. In principio c’è un vizio di forma.
Si arriva in azienda con la valigetta magica degli algoritmi, come se tutto possa prescindere dalla realtà di business che si vuole affrontare. L’AI si pone come Mr Wolf del noto film ‘Pulp Fiction’: ‘Risolvo problemi!’.
E questo molto spesso è il preludio del fallimento. È noto che statisticamente una percentuale alta di progetti in questo settore fallisce semplicemente per mancanza di dati.
Magari si analizza bene il problema, l’esigenza di business è chiara, e fin qui tutto bene, ma poi si va avanti dando per scontato che le fonti dati saranno sufficienti in quantità e diversificazione, per poi accorgersi che non è così.
Perché la Data Science possa avere un senso e quindi avere successo in un contesto di business possiamo ipotizzare due scenari: uno lean e uno strutturato.
Il caso lean parte dall’inizio da una verticalizzazione ‘problema di business’ -> algoritmo -> dati, che deve però subito arrivare in fondo alla catena, per poi essere ripercorso all’indietro.
Lo possiamo scomporre in questi passi:
- ho un problema di business ben definito, per il quelo posso quantificare dei KPI di successo e metriche di ROI;
- posso individuare degli analytics/algoritmi che possono ‘risolvere’ questo problema, estraendo il valore/soluzione da opportuni dati;
- determino quali sono esattamente i dati che mi servono e li cerco tra il mio patrimonio informativo interno e potenzialmente esterno.
La strategia corretta è arrivare subito al punto (3) eseguendo i punti due sulla carta e spendendo un bel po’ di tempo sul punto (3). La difficoltà classica è che credo di avere tutti i dettagli che servirebbero dal mio applicativo di fatturazione, ma di fatto non riesco ad estrarli perché lo stesso applicativo non ha delle API o il mio vendor non me le concede. Oppure alcuni altri dati sono disponibili da fornitore esterni, ma sono troppo cari e il ROI va a pallino.
Questa fase deve durare il più possibile ma non si conclude in un processo lineare che a ritroso passa per i punti (2) e (1), perché in ogni caso dovrò fare una prima verifica che i dati che ho ipotizzato siano quelli giusti lo siano davvero, applicando gli algoritmi e verificando che questi algoritmi risolvano il problema, producendo i corretti KPI e mantenendo un ROI sostenibile. Il processo deve essere iterativo. L’errore che si fa sempre di iterare i punti (1) e (2) con dati fasulli, non rappresentativi, solo per verificare un’ipotesi analytics<>’business case’.
L’approccio struttura differisce dal precedente solo per il fatto che il problema dei dati viene estensivamente risolto a monte. Cioè l’azienda prende una decisione strategica e stabilisce che ha bisogno di una nuova infrastruttura, tipicamente di Data Lake, e comincia a far convergere in questa infrastruttura tutti i dati potenzialmente utili alle diverse tipologie di problemi, andando subito a verificare per i vari applicativi interni, cosa può essere estratto e ponendosi anche il problema di un’armonizzazione semantica.
Il tipico passaggio successivo per il consumo interno di questi dati è quello di costruire un Data Catalog, che facilita la ricerca e l’accesso ai dati, anche da fruitori non tecnici, che lavorano nei dipartimenti business, senza che debbano essere esperti di API e linguaggi di programmazione.
Un Data Catalog è uno strumento molto potente non solo per affrontare problemi noti, ma anche per fare esplorazioni e sperimentazioni in campo libero, e rappresenta una solida base per tutte le attività di R&D legate alla Data Science, e cosa più importante non pone delle barriere tecniche orizzontalmente nell’organizzazione aziendale.
Per il resto poi il procedimento da seguire è lo stesso descritto nel caso lean, col vantaggio che la risposta al problema dell’esistenza dei dati giusti si raggiunge molto più velocemente. Anche in questo senso una scelta strategica da parte dell’azienda che decide in principio di dotarsi di un Data Lake viene ripagata nel medio periodo dall’accorciamento dei tempi di sviluppo e di verifica di nuovi processi di Data Science.