Un navigatore del DFM per data warehouse per facilitare le comunicazioni e i processi decisionali.
Il concetto
Federico Ravaldi, CEO e fondatore di Iconsulting, ci racconta di aver avuto l’idea nel 2013, andando a trovare un suo Cliente nel suo ufficio. Alle sue spalle, trova appeso un poster di circa 2 x 1 metro del DFM che Iconsulting ha realizzato per lui. Pensa che il motivo sia piuttosto estetico o tutt’al più una passione personale per il data visualization.
“Lo vedi questo fatto qui?” gli dice invece il Cliente, indicando una tabellina in alto a destra.
“E lo vedi questo qui?”, indicandone un’altra in basso.
“Ora so che esistono dei collegamenti tra loro e che posso chiedere alla business intelligence questi dati. Sono importantissimi per le mie analisi strategiche. Finalmente ho una visione globale di tutto il nostro business model.”
Tornato in azienda, Ravaldi decide di esplorare questo suggerimento creando un piccolo team interno fatto da Piergiorgio Grossi (vice president innovation e product owner), Manuel Spezzani (CTO), Gabriele Gattucci, Ciro Caiazzo e Alessio Cavaleri (team di sviluppo). Obiettivo: concepire un prodotto che consenta agli utenti l’esplorazione del sistema informativo della Business Intelligence attraverso il DFM e ipotizzare una roadmap per realizzarne l’MVP.
Il contesto
In 10 righe, abbiamo parlato di fatti, DFM, data warehouse, business intelligence….
Facciamo un passo indietro.
Iconsulting è uno dei più grandi System Integrator indipendenti italiani specializzato in progetti di Data Warehouse, Business Intelligence e Corporate Performance Management. Ora, avete presente Alice che entra nella tana del Bianconiglio? Ricordate cosa succede in Matrix, quando Neo sceglie la pillola rossa? Ecco, per noi lavorare per Iconsulting è stato un viaggio in un mondo completamente sconosciuto e inesplorato, popolato da persone che parlano una lingua ignota.
E così, siamo entrati nel mondo dei data warehouse, abbiamo scoperto quanta competenza, ingegno e progettazione richiedono, quanti big data producono e la loro importanza strategica. Abbiamo iniziato a capire in quanti modi questi dati vengono usati dalle imprese o dalle organizzazioni.
In oltre 10 anni di consulenze e progetti, Iconsulting ha capito che l’accesso alla conoscenza di questi dati è tanto cruciale quanto averli strutturati e integrati bene.
“In altre parole: a che cosa serve integrare in modo eccellente un sistema di data warehouse e business intelligence di un’organizzazione, se poi solo alcuni dei loro tecnici ne conoscono la struttura, sanno come accedervi e consultarla?”
Abbiamo anche scoperto che esiste una lunga letteratura accademica su quale sia il modo più corretto ed efficace di rappresentare una struttura di dati complessa e multilivello come quella di un data warehouse. Iconsulting, che da anni collabora con l’Università di Bologna, ha scelto il Dimensional Fact Model dei professori Stefano Rizzi e Matteo Golfarelli.
Da diversi mesi, gli ingegneri di Iconsulting progettano data warehouse basandone il modello concettuale sul DFM e hanno notato conseguenze molto positive sui progetti che stanno svolgendo. Tra le tante, hanno visto un enorme miglioramento nella comunicazione e comprensione di un argomento così tecnico e cruciale. Un miglioramento di cui stanno beneficiando gli ingegneri di Iconsulting, quando usano il DFM per spiegare come stanno progettando il data warehouse di un loro Cliente al top management, ai team di business intelligence o ai controller; e di cui beneficiano i Clienti stessi, perché si riferiscono a una rappresentazione dei dati che trovano comprensibile, perché capiscono se alcuni dati hanno senso quando sono messi in relazione ad altri e perché sanno spiegare quali dati gli servono.
È una delle domande che abbiamo fatto a Piergiorgio quando ci ha descritto il progetto. Iconsulting è un nome consolidato nel panorama internazionale e, per quanto riguarda i system integrator, sono considerati “quelli bravi”. La risposta che avremmo voluto sentire è stata proprio quella che ci ha dato Piergiorgio:
"Dopo anni di servizio e consulenza, abbiamo voglia di cimentarci su un prodotto. Vogliamo capire come si fa, imparare a renderlo sostenibile, fare tesoro dell’esperienza, apprendere...
Iconsulting oggi può permettersi di esplorare un’idea incubandola come una lean startup e dedicandogli un team. Abbiamo già un potenziale bacino di early adopters e sappiamo che il problema esiste. Comunque vada, sarà un’esperienza di cui faremo tesoro e che contribuirà a far crescere il know-how di Iconsulting, che è ciò per cui è famosa.
E quindi, perché non farlo?"
Il nostro ruolo
“Ce lo immaginiamo come un Google Maps del DFM.” ci ha riepilogato Piergiorgio. “Ma quando proviamo a disegnarlo non sappiamo da che parte iniziare.” queste invece sono parole di Manuel, ingegnere e sviluppatore. Iconsulting ci ha chiamato per accompagnare il team di sviluppo fino alla prima milestone del prodotto, scoprendolo insieme, iterazione per iterazione. Il “navigatore del DFM” è un progetto di lean ux design praticamente da manuale, va capito e costruito a poco a poco, testato spesso e ripensato ad ogni rilascio.
Il nostro ruolo è stato quello di proporre soluzioni, certamente. Ma soprattutto quello di far emergere dubbi e domande, introducendo approcci ed elementi di design che aiutassero a trovare risposte, con il minimo effort possibile. Abbiamo impostato la prima parte della progettazione in modo da ottenere un prodotto aperto alla raccolta di feedback e all'apprendimento e abbiamo fatto il possibile per evitare che la presenza o l'assenza di funzionalità viziassero le risposte degli utenti, perché in quel caso ci avrebbero mostrato il loro adattamento alla user experience proposta, non la loro propensione all'uso e il loro interesse sul prodotto.
Discovery
Abbiamo ascoltato tutte le idee sul prodotto sia dal product owner che dagli stakeholders, le abbiamo messe in priorità individuando un MVP consegnabile entro le date previste. Poi abbiamo ipotizzato una roadmap fissando come prima cosa 2 sessioni di confronto con gli utenti, che corrispondevano alle proto-personas individuate durante il kickoff meeting. Entrambe avevano lo scopo di validare le idee, solo che la prima sessione andava fatta a inizio progetto, la seconda sulla prima demo del prodotto. Il team dev di Iconsulting si è impegnato a organizzare le interviste e a rispettare il loro piano di sviluppo in modo da arrivare preparati al secondo appuntamento. Durante la prima giornata di interviste c’erano tutti: il team dev, il product owner, i professori e un team di early adopters già molto interessato e propenso all'utilizzo. Mentre gli intervistati ci raccontavano i problemi quotidiani e le loro abitudini, noi provavamo a schizzare le possibili soluzioni. Riferendosi agli schizzi, ci raccontavano quello che avrebbero fatto se avessero potuto usare una funzionalità di quel tipo. A loro insaputa, stavano suggerendoci le user stories, solo che qualcuna di quelle era tanto ovvia per gli loro quanto inaspettata per il team Iconsulting. Per loro, il prodotto doveva fare solo alcune cose, ma gli intervistati, toccando e indicando gli schizzi, gli stavano raccontando invece che nella loro vita reale era ovvio che il prodotto funzionasse anche come ce lo stavano descrivendo, altrimenti per loro sarebbe stato di scarso interesse. È stato divertente vedere team dev e professori agitarsi sulle sedie e non poter ribattere ai loro primi potenziali Clienti. La funzionalità che ci stavano raccontando richiedeva mesi di sviluppo? Avevamo un problema noi, non loro.
Al termine di questa prima giornata, per Iconsulting il dubbio emerso era questo: il prodotto è vendibile se avrà le funzionalità che ci hanno descritto gli intervistati o gli intervistati non sono le personas primarie per cui il prodotto è pensato?
Il nostro approccio
Mantenere tutto il team unito e saldo sugli obiettivi e sugli insight avuti, orientare le scelte in base ai racconti ascoltati dalle persone, scegliere gli strumenti giusti dalla nostra toolbox e poi adattarli, invece che applicarli come da manuale: è questo il cuore del nostro approccio ed è il valore che contraddistingue il nostro modo di fare design.
Per questo progetto, dopo le prime interviste abbiamo scritto le storie intestandole a loro e non ad attori generici. Le abbiamo accompagnate con schede riepilogative e l'experience map (o, in questo caso, story map) emergente e abbiamo invitato tutto il team a stamparle e attaccarle vicino alle loro postazioni di lavoro, in modo da ricordarsi ogni giorni che stavano sviluppando un prodotto per loro.
