Un progetto di Advanced Analytics è per sua natura un percorso pieno di ostacoli, più o meno prevedibili. E, forse sorprendentemente, più delle incognite di tipo tecnico sono quelle “non tecniche” a essere le più pericolose. La ricerca di una sponsorship interna, la gestione coerente di un gruppo di lavoro composto da risorse interne ed esterne, la corretta comunicazione sui possibili vantaggi dell’iniziativa nel suo complesso sono aspetti che, se non affrontati con la giusta attenzione, rischiano di compromettere l’intero progetto.
Ecco alcuni piccoli consigli per cercare di indirizzare questo percorso nei giusti binari.
Integrare “Descriptive” e “Advanced”
Si assiste spesso a un curioso quanto fuorviante sforzo concettuale volto a escludere, in un progetto di Advanced Analytics, tutto ciò che rientra nell’analisi di tipo descrittivo, che mostra cioè lo stato delle cose, l’accaduto fino a oggi. Si tende cioè a partire direttamente dalla previsione del “to be”. In realtà le due tipologie non dovrebbero essere messe in contrapposizione ma, al contrario, essere considerate tra loro complementari e strettamente connesse all’interno di un unico ecosistema di comprensione dei dati.
Se ad esempio in un contesto di GDO l’obiettivo è convincere l’azienda ad adottare un algoritmo di correlazione tra prodotti su cui basare le future strategie promozionali, probabilmente sarà utile introdurre il concetto descrivendo la situazione attuale in termini di vendite al dettaglio dei vari prodotti, evidenziando il peso che questi già hanno nel fatturato o che ancora non hanno (descrizione) ma che grazie all’algoritmo potrebbero avere (previsione). Così come, nell’analisi dei clienti registrati, un’analisi descrittiva classica di tipo RFM (Recency Frequency Monetary) può essere (anzi, è) un prezioso assist verso l’applicazione di tecniche avanzate di clustering.
Cercare (ostinatamente) il ROI
Se in ambito descrittivo la dimostrazione del possibile ROI (Return On Investment) di progetto può far leva in primis sull’efficientamento dei processi di back end e sulla diminuzione di costi e tempi necessari ad avere le informazioni aziendali (sforzo già di per sé complicato), quando si passa all’analisi avanzata questo esercizio può rivelarsi paradossalmente più semplice nel momento in cui la comunicazione del “risultato” venga accompagnato dalla consapevolezza di sua insita aleatorietà, cioè dall’evidenza della probabilità con cui esso possa effettivamente verificarsi. Il messaggio può essere: “l’analisi svolta porta a prevedere, nel caso vengano messe in campo strategie aziendali suggerite, il raggiungimento di un risultato di business X con una probabilità di Y%”. D’altro canto, un progetto di Advanced Analytics, ancor più di un progetto “classico”, dovrebbe partire da un’esigenza aziendale specifica, circoscritta e condivisa: in questo caso, proprio il “risultato di business X”.
Il machine learning non fa miracoli
Forse il peccato più comune che si commette durante un progetto di Advanced Analytics è la superbia. Supporre cioè che l’applicazione di un algoritmo di Machine Learning dia risultati a prescindere dal contesto specifico, e che quindi il confronto con le risorse aziendali si limiti a chiedere i dati su cui applicare l’algoritmo stesso.
I rischi di un tale atteggiamento sono principalmente i seguenti:
- proporsi come gli “esperti” del settore, armati solo di conoscenze statistico-informatiche, di fronte a persone di business che in quel settore magari ci lavorano da sempre e che così, invece di diventare gli sponsor di progetto, ne diventano i principali oppositori.
- trascurare tutti gli elementi non scientifici ma potenzialmente rilevanti per la previsione, ovvero (anche qui) la conoscenza di abitudini, comportamenti e particolarità nei processi aziendali non rilevabili dai dati, e che solo un approfondito confronto con il business può rendere evidenti al data scientist.
- non mettersi in discussione, certificando già come ottimali i risultati di una prima applicazione del metodo avanzato e trascurando così quel margine d’errore e quelle variazioni di scenario su cui invece sarebbe fondamentale rimanere vigili per perfezionare il metodo stesso.
Usare un linguaggio comprensibile
È abbastanza evidente come in tutto questo, il compito di chi disegna l’ambiente di Data Visualization sia cruciale. Si parla tanto di “storytelling”, che potrebbe essere tradotto anche nel “mettere al centro l’utente”. È infatti l’utente fruitore di quanto realizzato che dovrà essere idealmente preso per mano e accompagnato per tutto il percorso nella spiegazione dei contenuti. L’importante è che non si dia nulla per scontato, o ancor peggio che si utilizzi un linguaggio “da data scientist” in cui gli indici statistici, probabilmente incomprensibili per l’utente di business, la facciano da padrone.
A scanso di equivoci: l’ambiente di Data Visualization deve includere in sé una parte più statistica, ovvero una o più aree (dashboard) in cui rendere palese e inattaccabile la metodologia applicata. Tuttavia, deve prevedere anche un’area in cui questi risultati “scientifici” trovino una loro traduzione in numeri di business: quanto potrebbe aumentare la vendita di quel prodotto (in quantità e valore), quanto potrebbe aumentare lo scontrino medio con una promozione mirata su una certa tipologia di clienti registrati, e così via. Il tutto tramite un layout chiaro e accattivante allo stesso tempo.
Advanced Analytics: non lasciare solo il data scientist
L’integrazione tra analisi descrittiva e avanzata deve chiaramente trovare un riflesso nell’organizzazione del gruppo Analytics che lavora al progetto. Spesso, infatti, il o la data scientist vive in uno “splendido isolamento” dal quale esce solo per avere dal resto del team le informazioni strettamente necessarie per procedere con l’applicazione e la verifica dei propri algoritmi. Ne consegue che il compito di chi ha a gestione del gruppo Analytics dovrà essere duplice: da una parte coinvolgere questa risorsa anche nella parte “descrittiva” della business intelligence, dall’altra chiedere una chiara quanto dettagliata condivisione di quanto fatto per non dare un’idea, sia all’interno che all’esterno, di un team “a due velocità”.
