Solo più data visualization?

cruscotto

L’altro ieri

Se torno indietro con la memoria ai software di analytics, anni fa al centro era l’analisi del dato, che richiedeva competenze specifiche e un solido background statistico da parte dell’analista. La visualizzazione del dato era poi affidata a una figura specifica, che utilizzando i dati elaborati dall’analista provvedeva a “metterli in bella” – spesso in altri software, vuoi fogli di calcolo o programmi di presentazione. Erano due fasi del processo nettamente distinte e il business user sapeva della necessità di entrambe le figure. E soprattutto non s’illudeva di poter saltare a piè pari la fase di analisi, deputata a un esperto, e passare direttamente alla visualizzazione del dato, importando dati grezzi e giocando con le funzionalità di un applicativo di data visualization.

Ieri

Negli ultimi anni le cose sono molto cambiate. I produttori di software hanno realizzato (e realizzano) applicativi che fondono insieme analisi e visualizzazione del dato, mettendo a disposizione dell’utente interfacce molto gradevoli, apparentemente (!) semplificate. Mi riferisco a concetti quali self service analysis, self discovery. A mio avviso, la diffusione di queste piattaforme, se non è supportata da una solida conoscenza della statistica, equivale a dare le chiavi di una Ferrari a un neopatentato: si corre inevitabilmente qualche rischio! Una semplice interfaccia oggi consente in pochi clic, anche a chi sia inesperto, di visualizzare i numeri attraverso grafici che sarebbe assai complesso elaborare, applicando eventualmente funzioni statistiche a lui sconosciute. Alla fine siamo sicuri che il business user, capace di realizzare in autonomia un grafico o una statistica importando i dati da un dwh o da diverse fonti esterne, sia in grado di interpretare correttamente i risultati? Il modello di dati da lui creato ha subito il corretto processo di ETL ed è analizzabile al giusto livello di granularità? Il nostro business user sa cosa comporta l’uso di un left join invece di un inner join? Un elenco di domande che potrebbe diventare assai lungo. Di recente ho assistito a presentazioni di software durante le quali è stata messa in evidenza la semplicità d’uso, il fatto che l’utente “finalmente si libera dalle pastoie dell’IT”, che può ricavare insights in piena autonomia e via dicendo. Tutto ciò, a mio avviso, nasconde una realtà che rimane innegabile: senza un valido background, o senza l’aiuto del data analyst, o data scientist, definiamolo come vogliamo,si corre il rischio di avere a disposizione strumenti molto potenti, in apparenza di semplice utilizzo, ma di non riuscire a sfruttarli appieno o, nel caso peggiore, di formulare analisi non del tutto corrette.

QlikView è un ottimo strumento, assai potente: pochi step per importare i dati e creare degli oggetti grafici. Sia ben chiaro, qui non è affatto in discussione la comprovata qualità di QlikView. Ma il nostro business user è consapevole di come QlikView mette in join le tabelle? Come può evitare un’eventuale chiave sintetica? E se volesse creare dei KPI? indipendenti dai filtri applicati dall’utente? o gestire la set analysis? Ancora una volta, una cosa è la semplicità d’uso, innegabile, un’altra è padroneggiare lo strumento nella preparazione del data model. Non a caso, QlikView separa nettamente il learning path del Business User&Business Analyst da quello del Data Architect

Oggi

E così succede che, per colmare il gap degli utenti, produttori di software come SAS mettono gratuitamente a disposizione materiale di e-learning con slide ed esercitazioni per chi vuole imparare la statistica e il prodotto SAS University(che contiene Base SAS®, SAS/STAT®, SAS/IML®, SAS/ACCESS® Interface to PC Files, and SAS® Studio). Anni fa una scelta simile sarebbe stata difficilmente ipotizzabile.

Per chiudere, recentemente Microsoft ha rilasciato Power BI Desktop , un tool gratuito di semplice utilizzo per realizzare grafici con un data model che attinge alle fonti più disparate. Affascinante. Rimane il fatto che è bene sapere come strutturare i dati e per lavorare al meglio è utile conoscere, per esempio, il linguaggio DAX, non certo di semplice apprendimento. A proposito, è sapientemente spiegato da due italiani, Marco Russo e Alberto Ferrari: il loro blog SQLBI è un’ottima risorsa, contenente articoli e video che aiutano ad approfondire e padroneggiare DAX (ma non solo!) al fine di realizzare un valido data model, che potrà poi essere “consumato” dal nostro business user in (presunta…) autonomia.

Lunga vita al data scientist.