Lungo, complesso, difficilmente misurabile, dall’esito incerto. Ma, allo stesso tempo, strategico e ormai fondamentale. Realizzare un progetto di analytics, nei fatti, non è un’impresa semplice né banale. Certo, l’obiettivo è ambizioso: sfruttare i dati che si hanno a disposizione per trasformarli in informazioni, a reale supporto delle decisioni aziendali, sia a livello manageriale che operativo.
Nella pianificazione iniziale di un progetto di analytics si disegna un percorso “ideale”, prevedendo anche un minimo di “contingency” per gestire tutte le variabili in gioco. Tuttavia, non tutto è prevedibile fin dall’inizio. Molte possono essere le insidie nascoste che si incontreranno durante il percorso.
Sistemi “paralleli”
Uno dei principali rischi di un sistema di analytics aziendale è che questo, una volta rilasciato, non venga effettivamente utilizzato dagli utenti. Oppure che venga sì utilizzato, ma solo come strumento intermedio per esportare dati grezzi in file Excel locali, input per successive e misteriose rielaborazioni operative a cura degli stessi utenti finali. In tale scenario sono poi queste rielaborazioni – e non il sistema di analytics – a costituire il risultato finale, presentato al management e battezzato come “corretto” anche se tutt’altro che certificato (proprio per quanto detto sopra).
Entrambi i casi descritti sono la spia dell’esistenza di sistemi di analytics “paralleli” rispetto a quello che dovrebbe essere invece l’unico e ufficiale ambiente. I motivi di una situazione del genere possono essere molti: dall’esigenza (in parte condivisibile) di integrare i dati ufficiali con informazioni extra-sistema – caso tipico, il budget – fino all’esigenza (molto meno condivisibile) di mettere mano ai dati ufficiali talvolta per renderli più accettabili agli occhi del management.
Per evitare queste situazioni diventa fondamentale impostare un’iniziale, attenta e scrupolosa fase di “assessment” sui contenuti di business che la nostra soluzione analytics dovrà contenere. Fotografare l’”as is” e intercettare il “to be” in termini di report, analisi ecc., senza disprezzare a priori i file Excel dei singoli utenti ma cercando di capire le ragioni per cui esistono, sono attività onerose a metà tra il tecnico e il politico; tuttavia, se fatte bene, si ripagano abbondantemente durante lo svolgimento del progetto.
Data source dipartimentali
In un’azienda strutturata, specialmente se multinazionale o comunque ramificata in più “anime”, è frequente che lo scenario dei data source dipartimentali si evolva nel corso del tempo. Quando si fa partire un sistema centrale di analytics lo si fa tenendo conto della situazione attuale. È importante che questa situazione venga monitorata attentamente nel tempo. L’adozione, ad esempio, di un nuovo software per la gestione dei dati locali da parte di una singola filiale, piuttosto che un’area di business, può portare alla nascita di quei sistemi “paralleli” di analytics di cui si è parlato nel paragrafo precedente.
Roadmap di prodotto e compatibilità tecnologiche
Progettare un sistema di analytics significa ovviamente anche scegliere un software rispetto a un altro: in termini di database di Data Warehouse, flussi di ETL, front end, ambienti cloud, ecc. Al di là dell’ovvia attenzione da prestare agli “economics”, è utile se non necessario indagare su quanto questi software rappresentino asset centrali per i rispettivi vendor, ovvero quanto per essi sia garantita una roadmap evolutiva a cui fare affidamento per un progetto che, per definizione, è fatto per durare ed evolvere nel tempo. Parallelamente, serve anche indagare su eventuali limiti tecnici nella mole di dati gestibili (ad esempio, se si sta operando in ambito “big data” e si scopre troppo tardi che il software di ETL ha un limite superiore nel numero di record processabili), così come sulle famigerate “matrici di compatibilità” verso le altre componenti tecnologiche già presenti in azienda, con le quali il nostro sistema di analytics dovrà, volente o nolente, collaborare.
Metadati
Ovvero, il modo in cui l’utente finale vede i dati. In altre parole, le etichette che trasformano i nomi tecnici spesso incomprensibili dei campi provenienti dai data source in titoli comprensibili e “di business”: “Valore ordinato €”, “Quantità spedita”, “Nome cliente” e così via. A questa fase spesso si dedica un’attenzione marginale, forse perché è sequenzialmente l’ultima che viene sviluppata e, rispetto alle precedenti, sembra la più semplice e noiosa. Però, proprio perché essa costituisce di fatto la lingua con cui gli utenti finali dialogheranno con il sistema di analytics, diventa un fattore importante nell’utilizzo dello stesso. Vale quindi la pena prendersi tutto il tempo per elaborare una proposta di “data dictionary”, frutto dall’esperienza maturata in precedenti progetti di questo tipo, da condividere con i futuri utenti. Ed eventualmente, assieme a loro, apportare le modifiche necessarie.
Conclusioni
Infine. Si parla tanto di “self service”, cioè la possibilità per gli utenti finali di costruirsi autonomamente le proprie analisi “on demand”, in modo semplice e rapido. Tutti i software del settore si stanno muovendo in questo senso. È importante però che questa “libertà” data all’utente finale non vada mai però a scapito delle performance, ovvero dei tempi di risposta del sistema. Altrimenti, per il progetto in generale, sarebbe un clamoroso autogol.
Il rilascio un cruscotto aziendale (o “dashboard”), interattivo nella scelta dei filtri e nella navigazione ma non modificabile dall’utente finale a livello di struttura di base, è probabilmente il risultato anche di una fase precedente di performance test, in cui siano stati applicati tutti gli accorgimenti tecnici tali da ottimizzare i tempi di risposta (partizionamenti, indici, eventuali opzioni di “in memory”, ecc.).
Quando però si rilascia un ambiente di self service, in cui l’utente possa muoversi quasi senza vincoli, il rischio che sia stato lasciato spazio per generare query con prodotti cartesiani o con piani di esecuzione non ottimizzati è reale.
La soluzione può essere vincolare il sistema a livello di tool finale o a livello di data model alla base dello stesso, ad esempio non consentendo “fisicamente” il collegamento tra campi di “fact table” diverse e incompatibili da un punto di vista logico di business. Occorre peraltro considerare, anche se non soprattutto per ambienti di questo tipo, una fase di “User Acceptance Test” in cui il nostro sistema venga messo davvero sotto stress dai “key users” aziendali.
Perché si sa, l’innamoramento degli utenti verso un sistema di analytics è intenso, ma fuggevole e fragile.
