Autore: Bruno Sfogliarini – Professore Data Analysis IULM Milano
Sarà capitato a tutti i genitori, almeno a quelli che i propri figli li ascoltano anche quando sono piccoli…, di affrontare il “periodo del perché”, e mi riferisco alla prima fase più violenta e faticosa. I bambini a un certo punto dell’infanzia e per un lasso di tempo limitato, tipo qualche mese, chiedono sempre la stessa cosa, “perché?”, insistentemente e apparentemente senza nemmeno ascoltare le risposte dei genitori. Dico apparentemente ricordando che invece mia figlia dopo un paio di turni di domanda-risposta alla fine smetteva e sembrava soddisfatta, almeno per qualche decina di minuti. Non è che io sia mai stato un papà perfetto, anzi penso tutt’altro, solo ho seguito l’esempio di mio padre che rispondeva sempre ai miei perché, sempre che fossero giustificati e logici. Non è che Giulia sia una figlia perfetta, e non credo nemmeno lei lo pensi, però so che vuole sempre arrivare in fondo ai problemi e, se umanamente possibile, risolverli con stile e originalità. D’altra parte da due genitori matematici poteva solo venire fuori un’artista come il nonno…
Questa minima digressione privata mi serve per trattare il primo fondamentale passo del processo di data science proposto da Microsoft Azure (TDSP), cioè il “Business Understanding”. In pratica e come sembra logico anche all’uomo della strada, meglio non cominciare un lavoro se non si ha chiaro in testa cosa si vuole realizzare e con quali mezzi. Ecco, una delle tecniche più conosciute e consolidate per arrivare alle vere ragioni di un progetto è proprio quella dei “5 perché”.
La tecnica, sviluppata in origine da Sakichi Toyoda, si basa su un’analisi dei sintomi per arrivare alla descrizione delle cause del problema. Il percorso utilizzato per individuare le vere cause scatenanti di un problema è quello di iterare almeno 5 volte, o comunque tutte le volte che serve dato che 5 è solo un numero indicativo (oltre che un bel numero dispari ma questi son gusti…) la domanda “perché”. Così facendo, si riduce il rischio di considerare quelli che sono in realtà fattori di superficie come vere cause del problema.
Più formalmente, il Business Understanding consiste nella definizione di due elementi:
- Obiettivi del processo (il “cosa” della Data
Science), espressi in termini di:
- Variabili chiave da prevedere (model targets) e relative metriche associate (es. previsione delle vendite in valore e suo MAPE)
- Domande tipiche a cui rispondere con un metodo
altrettanto tipico, e sono cinque:
- In che quantità o in che numero? (regressione)
- Quale categoria? (classificazione)
- Quale gruppo? (clustering)
- È strano? (rilevamento anomalie)
- Quale opzione scegliere? (suggerimento)
- Team di progetto, in termini di ruoli e responsabilità
- Le metriche del successo, che devono essere SMART
- Fonti dati (i “mezzi” della Data Science), che
contengano esempi conosciuti di risposte alle domande chiave. Si cercano in primo luogo:
- Dati pertinenti alla domanda. Sono presenti misure del target e funzionalità correlate al target?
- Dati che rappresentano una misurazione accurata del target di modello e delle funzionalità di interesse.
Si può ad esempio scoprire che i sistemi esistenti devono raccogliere e registrare tipi di dati aggiuntivi per risolvere il problema e raggiungere gli obiettivi del progetto. In questo caso si possono cercare origini dati esterne o aggiornare i sistemi per raccogliere nuovi dati.
Il Business Understanding produce tre risultati tangibili:
- Documento di dichiarazione d’intenti
- Origini dati
- Dizionari dei dati
Senza questi elementi diventa inutile partire con l’esecuzione del piano d’attività, si perderebbe solo tempo e denaro. Insomma, proprio quando le cose si fanno più serie e si rischia di sbagliare di brutto ecco che ritrovando il bambino che è in noi facciamo la cosa giusta!
Commenti recenti