Hai i dati. Non hai le domande. Il motivo per cui le dashboard non fanno fatturare

Le hai pagate, sono belle, e non le apre nessuno

Fai un esperimento, adesso. Apri l’ultima dashboard che hai fatto costruire — quella per cui hai speso tempo e soldi, magari con un consulente, magari con lo strumento «che fa tutto». Guarda la data dell’ultimo accesso. Chiediti chi, in azienda, l’ha aperta questa settimana per prendere una decisione. Nella maggior parte dei casi la risposta è deprimente: nessuno, da settimane, e comunque non per decidere niente.

Le dashboard che non si usano sono uno dei fallimenti più costosi e più silenziosi delle aziende che «investono nei dati». Silenziosi perché nessuno li dichiara: la dashboard c’è, tecnicamente funziona, i grafici si aggiornano. Semplicemente non cambia niente. È diventata carta da parati digitale: bella, presente, e ininfluente. E la cosa frustrante è che il problema quasi mai sono i dati — quelli ci sono. Il problema è che mancano le domande.

E non è un problema di aziende arretrate: succede soprattutto a quelle che hanno investito, che hanno preso lo strumento buono e la persona giusta. Proprio perché hanno fatto «le cose per bene» sul piano tecnico, non si spiegano perché il risultato sia un silenzio. La spiegazione, quasi sempre, è che hanno comprato risposte prima di avere le domande.

Questo articolo è per chi ha già dei numeri e delle dashboard ma non ne cava valore, e per chi sta per assumere o incaricare qualcuno «di fare le dashboard» pensando che il problema sia produrre più grafici. Vediamo perché il self-service BI fallisce quasi sempre, perché senza domande i dati sono solo decorazione, come si tirano fuori le domande giuste (che è un lavoro, non un’illuminazione), e cosa distingue un mucchio di grafici da un data product aziendale che si usa davvero.

Il mito del self-service BI

Negli ultimi anni ci hanno venduto un sogno: compra lo strumento giusto (Power BI, Tableau, Looker, quello che vuoi), collega i dati, e «le persone si faranno le loro analisi da sole». Self-service business intelligence. Democratizzazione dei dati. Ogni manager diventa analista. È un sogno bellissimo, e per la stragrande maggioranza delle PMI è esattamente il motivo per cui il self-service BI fallisce.

Perché fallisce? Perché presuppone due cose che quasi mai sono vere. La prima: che le persone abbiano tempo e voglia di esplorare i dati. Non ce l’hanno. Il titolare, il responsabile vendite, il capo reparto hanno un lavoro da fare, e «giocare con la dashboard per scoprire insight» non è quel lavoro. La seconda, più profonda: che sappiano quali domande fare. E qui sta il punto. Dare a qualcuno uno strumento potente e mille dati senza dargli le domande giuste è come dare a qualcuno una biblioteca e dirgli «impara». Impara cosa? Da dove comincio?

Il risultato del self-service è prevedibile: dopo l’entusiasmo iniziale, quasi nessuno apre lo strumento. Chi lo apre si perde tra decine di grafici e lo richiude. E la dashboard costosa diventa il monumento a un’idea sbagliata: che il problema fosse la mancanza di accesso ai dati, quando il problema era la mancanza di domande a cui i dati rispondono. Lo strumento non è inutile: è che è arrivato prima della domanda, e senza domanda non serve.

Senza domande, i dati sono solo grafici

Facciamo chiarezza su una distinzione che sembra filosofica e invece è la più pratica di tutte. Un dato è un fatto: «ieri abbiamo venduto 12.000 euro». Un grafico è quel fatto disegnato. Ma né il dato né il grafico, da soli, valgono niente per il business. Valgono qualcosa solo quando rispondono a una domanda che precede una decisione.

«Abbiamo venduto 12.000 euro» non serve a niente se non sai rispetto a cosa. Rispetto a ieri? Alla media? All’obiettivo? E soprattutto: cosa farai se il numero è alto o basso? Se non c’è una decisione dietro, il numero è trivia. La sequenza sana è sempre: decisione → domanda → numero → grafico. Prima decidi quali decisioni prendi (cosa riordinare, chi richiamare, dove spingere), poi da lì derivano le domande, poi i numeri che rispondono, poi il modo di mostrarli.

Il self-service e le dashboard-cimitero fanno il percorso al contrario: partono dai dati disponibili, ne fanno grafici, e sperano che qualcuno ci trovi dentro una decisione. Non succede quasi mai, perché è come costruire risposte e cercare le domande. Una dashboard nata così è tecnicamente ineccepibile e praticamente inutile: mostra tutto ciò che si può mostrare invece di ciò che serve per decidere.

Questo è strettamente legato al problema dei KPI sbagliati e delle vanity metrics: una dashboard senza domande finisce inevitabilmente per riempirsi dei numeri più facili da mostrare — visite, totali, medie — che sono anche i meno legati a una decisione. La mancanza di domande e l’abbondanza di vanity sono la stessa malattia vista da due lati.

Come si tirano fuori le domande (è un lavoro, non un’illuminazione)

La buona notizia è che le domande giuste non arrivano per ispirazione: si tirano fuori con un metodo. È la parte di lavoro più preziosa e più sottovalutata, quella che trasforma un reportificio in un data product. Ecco come si fa, in pratica.

Si parte non dai dati, ma dalle decisioni ricorrenti di chi comanda. Ti siedi con il titolare, o il responsabile commerciale, o il capo operations, e chiedi: «quali decisioni prendi ogni settimana, ogni mese, e su cosa vorresti basarle?». Non «quali grafici vuoi», che porta sempre a «dammi tutto»: quali decisioni. Le risposte sono concrete: decido cosa riordinare, decido a chi dare priorità, decido se una promo continua, decido dove serve personale.

Per ogni decisione, si scava fino alla domanda che la guida. «Decido cosa riordinare» → la domanda è «cosa sta accelerando e cosa sta rallentando, per prodotto, rispetto alle ultime settimane?». «Decido se la promo continua» → «la promo sta aumentando il margine totale o solo il fatturato?». Nota che queste domande non sono ovvie, e spesso costringono a chiarire cosa si vuole davvero — che è già metà del valore.

Da un workshop così, di poche ore, esce una lista di 5-10 domande vere: quelle che, se avessero una risposta affidabile ogni mattina, cambierebbero davvero le decisioni. Quella lista, non i dati disponibili, è il capitolato del data product. È l’esatto opposto del self-service: invece di dare a tutti tutto e sperare, dai a ciascuno le poche risposte che gli servono per decidere meglio.

Un accorgimento pratico che sblocca i workshop timidi: invece di chiedere «quali domande avete?», chiedi «raccontami l’ultima volta che hai preso una decisione importante al buio, senza il numero che ti serviva». Le persone ricordano benissimo i momenti in cui hanno dovuto decidere a naso, e ogni ricordo è una domanda mancante. Da lì si risale facilmente al numero che sarebbe servito. È molto più efficace che chiedere le domande in astratto, perché parte dal dolore concreto invece che dalla teoria.

Le domande da cui quasi sempre si parte

Ogni azienda ha le sue, ma dopo tanti workshop certe domande tornano quasi sempre, perché nascono da decisioni universali. Usarle come innesco aiuta a sbloccare la discussione — ma poi vanno calate sul tuo business, non copiate.

• Cosa sta accelerando e cosa rallentando, per prodotto o linea, rispetto alle ultime settimane? (decisione: cosa spingere, cosa riordinare)
• Quali clienti stiamo perdendo, cioè ordinavano e non ordinano più? (decisione: chi richiamare)
• Dove sta il margine vero, per prodotto, cliente o canale? (decisione: dove concentrare gli sforzi)
• Cosa è a rischio: ritardi, scorte sotto soglia, scadenze? (decisione: dove intervenire oggi)
• Quali promo o sconti funzionano davvero sul margine, non solo sul fatturato? (decisione: cosa continuare)
• Come sta andando oggi rispetto all’obiettivo e allo stesso periodo di prima? (decisione: se cambiare rotta)

Nota che ognuna è agganciata a una decisione esplicita, tra parentesi. Una domanda senza una decisione dietro non entra nella lista: è curiosità, non strumento. Il test è sempre lo stesso: se avessi la risposta a questa domanda ogni mattina, cosa farei di diverso? Se non sai rispondere, non è una domanda da data product — è un grafico in cerca di uno scopo.

Chi deve essere nella stanza del workshop

Il workshop delle domande funziona se nella stanza ci sono le persone giuste, e fallisce se ci mandi solo l’IT o solo un consulente. Chi serve davvero:

• Chi decide — il titolare, i responsabili — perché sono loro che prendono le decisioni da cui nascono le domande. Senza di loro, il workshop produce domande teoriche.
• Chi conosce il lavoro sul campo — chi vende, chi produce, chi sta al bancone — perché conosce le eccezioni e le domande vere che ci si fa ogni giorno, non quelle da manuale.
• Chi conosce i dati — internamente o il fornitore — perché serve a capire subito quali domande sono rispondibili con ciò che c’è e quali richiedono di raccogliere qualcosa di nuovo.

Chi non basta da solo: l’IT. Sa collegare e mostrare, ma non ha le decisioni in mano, quindi non può decidere le domande. Un workshop guidato solo dall’IT produce, di nuovo, grafici tecnicamente corretti che nessuno userà. Le domande nascono dove si prendono le decisioni, non dove si gestiscono i database.

Ogni domanda ha un proprietario e una frequenza

Una lista di domande non basta: perché diventino un prodotto vivo, ogni domanda ha bisogno di due attributi che quasi nessuno assegna. Un proprietario e una frequenza.

Il proprietario è la persona di cui è quella domanda: quella che la userà per decidere e che si accorgerà se la risposta è strana o manca. Una domanda senza proprietario è una domanda che non guarderà nessuno — esattamente come i grafici del self-service. «La promo aumenta il margine?» è del responsabile marketing; «cosa riordinare?» è del responsabile acquisti. Assegnare il proprietario trasforma un numero astratto in uno strumento di qualcuno.

La frequenza è ogni quanto quella domanda va guardata, perché non tutte hanno lo stesso ritmo. «Quanto abbiamo venduto ieri?» è giornaliera; «quali clienti stiamo perdendo?» forse settimanale; «qual è il margine per linea?» magari mensile. Assegnare la frequenza evita due errori opposti: annegare le persone in numeri quotidiani che cambiano decisione una volta al trimestre, e nascondere in un report mensile un numero che andrebbe visto ogni giorno.

Con proprietario e frequenza, ogni domanda diventa un piccolo contratto: questa persona guarda questo numero con questo ritmo per prendere questa decisione. Una dashboard costruita così non è un mucchio di grafici per tutti: è un insieme di strumenti, ciascuno con un padrone e un ritmo. Ed è per questo che si usa, mentre il cimitero di grafici no. È lo stesso principio per cui assumere un data analyst senza un sistema non basta: senza domande con proprietario, anche la persona più brava produce report che nessuno apre.

Perché «aggiungere più dati» peggiora le cose

C’è una reazione istintiva, quando una dashboard non viene usata: «forse mancano dei dati, aggiungiamone». È l’esatto contrario di ciò che serve, e peggiora il problema. Più dati e più grafici su una schermata già ignorata non la rendono più utile: la rendono più intimidatoria. Chi la apre si trova davanti un cruscotto d’aereo e la richiude più in fretta di prima.

Il motivo è che il problema non è mai stato la quantità di informazione, ma la sua messa a fuoco. Una dashboard che non si usa non soffre di carenza di dati: soffre di assenza di domande. Aggiungere dati a un’assenza di domande è come alzare la voce con qualcuno che non ti ha chiesto niente. La cura è togliere, non aggiungere: ridurre a poche schermate, ognuna che risponde a una domanda con un proprietario. Un data product che funziona è quasi sempre più piccolo di quello che non funzionava, perché la differenza non è nei dati, è nella domanda. Quando qualcuno propone «aggiungiamo più metriche» come soluzione al non-utilizzo, sta curando la febbre con altra febbre.

L’ordine giusto: la domanda prima dello strumento

Riassumo il principio che attraversa tutto l’articolo, perché è quello che fa la differenza tra spendere bene e spendere male: la domanda viene prima dello strumento. Sempre. Il self-service, le dashboard-cimitero, l’AI sui dati falliscono tutti per lo stesso motivo — mettono lo strumento prima della domanda, e sperano che la domanda emerga. Non emerge.

L’ordine che funziona è l’opposto, e non è negoziabile: prima le decisioni che prendi, poi le domande che le guidano, poi le definizioni dei numeri che rispondono, poi lo strumento che li mostra. Ogni volta che un progetto parte dallo strumento («compriamo Power BI e vediamo cosa ci facciamo») o dai dati («abbiamo tanti dati, tiriamoci fuori qualcosa»), sta partendo dal pezzo sbagliato, e il risultato sarà l’ennesima dashboard che non si apre. Non è una questione di budget o di bravura tecnica: è una questione di ordine. Lo stesso strumento, gli stessi dati, gli stessi soldi danno un cimitero o un prodotto vivo a seconda che tu parta dalla domanda o no.

Dal notebook alla schermata che si usa

C’è un altro modo in cui i progetti dati falliscono, più tecnico ma altrettanto comune: l’analisi resta un artefatto da analista e non diventa mai un prodotto per l’azienda. L’analista bravo trova l’insight — «i clienti che comprano X entro 30 giorni valgono il triplo» — lo mette in un notebook, in una slide, in un’email. Bellissimo. Poi? Poi niente, perché quell’insight non è agganciato a nessuna schermata che qualcuno guarda per decidere. Resta una scoperta una tantum, non uno strumento ricorrente.

La differenza tra un’analisi e un data product è questa: l’analisi risponde a una domanda una volta; il prodotto risponde alla stessa domanda ogni volta che serve, da solo, nel posto dove chi decide guarda. Trasformare l’una nell’altro è lavoro vero — di dati, di interfaccia, di aggancio alle decisioni — ed è esattamente il lavoro che distingue un analyst che «fa report» da un analyst che costruisce prodotto.

Un modo semplice per capire se sei davanti a un’analisi o a un prodotto: chiediti se, tra sei mesi, quella risposta ci sarà ancora, aggiornata, nel posto dove serve — oppure se sarà un’email dimenticata in un archivio. L’analisi invecchia il giorno dopo; il prodotto resta vivo. Il valore ricorrente sta nel secondo, ed è per questo che vale la pena fare il lavoro in più di trasformare l’insight in strumento.

È anche il motivo per cui la figura giusta, quando i dati devono fare la differenza, non è chi sa fare i grafici più belli, ma chi sa portare una domanda di business fino a una schermata che si usa ogni giorno. Un profilo raro e prezioso, che pensa in termini di prodotto (chi lo usa, per decidere cosa, quando) e non in termini di analisi (che dato interessante). La consulenza che vale non è «ti faccio le dashboard»: è «ti trasformo le domande giuste in strumenti che le persone useranno».

LLM sui dati: potenti, e pericolosi se le definizioni ballano

Oggi c’è una tentazione nuova che promette di saltare tutto questo lavoro: «mettiamo un’AI sui nostri dati, così chiunque fa domande in linguaggio naturale e ottiene risposte». Sulla carta è il self-service definitivo. Nella pratica, senza le fondamenta giuste, è il modo più veloce di ottenere risposte sbagliate con la massima sicurezza.

Il problema è sempre lo stesso: le definizioni. Se chiedi a un modello «quanto abbiamo venduto a Milano a novembre?» e in azienda «vendita» non è definita in modo univoco, il modello sceglierà una interpretazione — quale, non lo sai — e ti darà un numero preciso e plausibile, che potrebbe essere quello sbagliato. Un umano che non è sicuro chiede «intendi ordini o fatture?»; un modello, di default, tira a indovinare con tono sicuro. Su dati con definizioni che ballano, un LLM non democratizza i numeri: democratizza gli errori.

Questo non vuol dire che l’AI sui dati sia da buttare — vuol dire che va dopo, non prima. Prima le domande, le definizioni firmate, il data product che le rispetta; poi, eventualmente, un livello conversazionale sopra, che interroga numeri già calcolati bene con regole verificabili. L’ordine è tutto: l’AI sopra un data product solido è utile; l’AI sopra un caos di definizioni è un generatore di sicurezze false. La scorciatoia non salta il lavoro delle domande: lo rende solo più pericoloso saltarlo.

Un caso tipo: la dashboard morta risuscitata da tre domande

Un profilo tipico, architetturale, senza nomi. Azienda manifatturiera media, aveva speso bene: un consulente, uno strumento BI serio, una dashboard con venti grafici che copriva vendite, produzione, magazzino. Tecnicamente ottima. Dopo tre mesi, l’ultimo accesso era di sei settimane prima. Il titolare era convinto di aver buttato i soldi nei dati.

Non aveva buttato i dati: aveva saltato le domande. Ci siamo seduti con lui e i due responsabili per due ore, e invece di guardare i grafici abbiamo elencato le decisioni: cosa mandi in produzione per primo, quando avvisi un cliente di un ritardo, quando riordini una materia prima. Da lì sono uscite tre domande vere e precise, che la dashboard da venti grafici non rispondeva chiaramente pur avendo tutti i dati per farlo.

Cosa si è fatto: si sono buttati quindici grafici su venti. Si sono costruite tre schermate, una per domanda, con un proprietario e una frequenza. La schermata «cosa è a rischio ritardo» è diventata la prima cosa che il responsabile di produzione guarda ogni mattina. Dopo un mese la usavano tutti i giorni — non perché gliel’avessero imposto, ma perché rispondeva a una domanda che si facevano comunque. Stessi dati, stesso strumento: cambiava solo che ora partivano dalle domande. Il consulente precedente non aveva fatto un cattivo lavoro tecnico: aveva fatto il lavoro nell’ordine sbagliato.

Il costo nascosto delle dashboard che non si usano

Le dashboard morte costano più di quanto sembri, e su tre fronti. Il primo è ovvio: i soldi spesi per costruirle, più le licenze degli strumenti che continui a pagare anche se non le apre nessuno. Il secondo è più sottile: le decisioni prese comunque a naso, mentre la risposta era lì, in un grafico che nessuno guardava. Avere il dato e non usarlo è quasi peggio che non averlo, perché paghi per un’informazione che non converti in azione.

Il terzo costo è il più insidioso: la sfiducia. Dopo una o due dashboard morte, in azienda si diffonde l’idea che «i dati da noi non funzionano», «abbiamo già provato, non è servito». Quella sfiducia è cara, perché blocca anche i progetti giusti: la prossima volta che qualcuno propone di partire dalle domande, si scontra con «sì, ci avevamo provato con le dashboard». Il fallimento silenzioso non resta silenzioso: diventa un pregiudizio che rende più difficile fare la cosa giusta. Ecco perché conviene affrontare il problema alla radice — le domande — invece di aggiungere l’ennesimo grafico e sperare.

«Ma noi vogliamo poter esplorare»: il malinteso finale

Un’obiezione ricorrente, quando proponi pochi data product mirati invece del self-service: «ma noi vogliamo poter esplorare i dati liberamente, non solo poche schermate fisse». È legittima, e la risposta non è «o l’uno o l’altro». Un data product ben fatto ha due livelli: davanti, le poche schermate che rispondono alle domande che contano e che si usano ogni giorno; dietro, la possibilità di scendere nel dettaglio ed esplorare quando serve.

La differenza col self-service puro è l’ordine di priorità. Si parte dalle domande e dalle schermate d’uso quotidiano, e l’esplorazione è un di più, non il piatto principale. Il self-service fallisce perché mette l’esplorazione al centro e le domande da nessuna parte; un buon prodotto mette le domande al centro e lascia l’esplorazione come possibilità per chi, ogni tanto, ne ha bisogno e capacità. E c’è un dettaglio che quasi sempre si rivela vero: quando le persone dicono «vogliamo esplorare», in realtà vogliono che le loro domande abbiano una risposta pronta. Quella la dà il prodotto, non il libero accesso a mille grafici in cui perdersi.

Cosa consegnare: un prodotto, non un file

Se stai valutando un progetto dati — con un interno o un fornitore — la domanda giusta da fare è: cosa mi consegni? E la risposta che distingue un lavoro serio da un reportificio è netta. Non un file, non una slide, non «l’accesso a Power BI»: un prodotto.

Un data product, concretamente, è fatto di:

• Una lista di domande con proprietario e frequenza, che è il capitolato condiviso.
• Le definizioni firmate dei numeri che rispondono a quelle domande.
• Un sistema che calcola le risposte da solo, aggiornandole con la frequenza giusta.
• Le schermate dove chi decide guarda quelle risposte, con gli allarmi quando qualcosa esce dalla norma.
• Un piano perché il prodotto resti vivo: le domande cambiano, il business cambia, e il prodotto va aggiornato.

Nota cosa non c’è: «trenta grafici che coprono ogni possibile analisi». Un data product fa poche cose, quelle che contano, e le fa bene. È la differenza tra un attrezzo e un negozio di ferramenta: il negozio ha tutto, ma è l’attrezzo giusto in mano alla persona giusta che avvita la vite. Se ciò che ti propongono è il negozio — «ecco tutti i dati, esplorali» — stai comprando un cimitero di grafici. Se ti propongono gli attrezzi giusti per le tue decisioni, stai comprando un prodotto.

Segnali di fallimento a 60 giorni

Come fai a sapere, presto, che un progetto dati sta diventando l’ennesima dashboard che non si usa? Ci sono segnali chiari già a 60 giorni, e riconoscerli in tempo ti fa correggere prima di aver buttato il budget.

• Nessuno la apre spontaneamente. Se l’unico momento in cui qualcuno guarda la dashboard è quando glielo chiedi tu, non è uno strumento: è un compito. Uno strumento vero si apre perché serve, non perché è richiesto.
• Non ha cambiato nessuna decisione. Chiedi: «quale decisione hai preso diversamente grazie a questo, negli ultimi due mesi?». Se la risposta è vaga o assente, il prodotto non funziona, per quanto bello sia.
• Si aggiungono grafici invece di toglierli. Se la reazione al «non la usa nessuno» è «aggiungiamo più metriche», stai diluendo il problema. I prodotti che funzionano dimagriscono, non ingrassano.
• Nessuno si accorge se si rompe. Se un numero è sbagliato per una settimana e nessuno lo nota, vuol dire che nessuno lo stava usando per decidere. Un numero usato davvero ha qualcuno che si accorge quando è strano.
• Le domande di partenza non esistono. Se non c’è una lista scritta di domande con proprietario, il progetto è partito dai dati e non dalle decisioni: il fallimento era nel DNA.

Se riconosci due o tre di questi segnali, non serve buttare tutto: serve tornare indietro alla domanda mancante. Ripartire dalle decisioni, tirare fuori le domande vere, assegnare proprietari, e ricostruire il prodotto attorno a quelle. Quasi sempre il problema non è il tool né i dati: è che si è saltato il passo delle domande.

Il ruolo del titolare: le domande non le puoi delegare

C’è una responsabilità che, in tutto questo, non puoi delegare: decidere le domande. Puoi affidare a un fornitore la pipeline, a un analista i calcoli, a uno strumento la visualizzazione. Ma quali decisioni contano davvero per la tua azienda, e quindi quali domande devono avere una risposta ogni mattina, lo sai solo tu e la tua direzione. È il pezzo di lavoro che sembra il meno tecnico e invece è il più decisivo.

Questo è anche il motivo per cui i progetti dati delegati in blocco — «pensateci voi, fatemi le dashboard» — falliscono così spesso. Chi arriva da fuori può facilitare, può portare metodo, può costruire benissimo; ma non può sapere, al posto tuo, cosa ti tiene sveglio la notte e quali scelte fai ogni settimana. Due ore del tuo tempo nel workshop delle domande valgono più di mesi di lavoro tecnico costruito al buio. Se un fornitore serio ti chiede quelle due ore, è un buon segno; se ti promette le dashboard senza chiedertele, sta per costruirti un altro cimitero.

È per te se / non è per te se

È per te se: hai già dashboard o report che nessuno apre; hai «tanti dati» ma le decisioni le prendi ancora a naso; ti hanno venduto il self-service BI e dopo l’entusiasmo iniziale è tutto fermo; stai per incaricare qualcuno «di fare le dashboard» e sospetti che il problema sia un altro.

Non è per te se: hai già domande chiare con proprietario e le tue dashboard vengono usate per decidere ogni settimana (allora sei a posto); non hai ancora i dati di base (prima servono i numeri, poi le domande su cosa chiedergli); cerchi «più grafici» e non «più decisioni» — perché la strada qui è togliere e mettere a fuoco, non aggiungere.

Domande frequenti

Il self-service BI è sempre sbagliato? No: funziona in organizzazioni con una cultura del dato matura e persone che hanno tempo e competenza per esplorare. Nella maggior parte delle PMI, però, arriva prima della cultura e senza le domande, e diventa uno strumento costoso che non apre nessuno. Meglio pochi data product mirati che un self-service per tutti.

Come faccio a capire quali sono le domande giuste? Partendo dalle decisioni, non dai dati. Siediti con chi decide e chiedi quali scelte fa ogni settimana e su cosa vorrebbe basarle. Da lì derivano le domande. È un workshop di poche ore, e vale più di mesi di dashboard costruite al buio.

Serve per forza un data analyst? Serve qualcuno che sappia portare una domanda di business fino a una schermata usata — che è un profilo diverso dal «fa grafici». Può essere un interno con testa di prodotto o un fornitore. Quello che non serve è assumere per produrre report senza aver prima definito le domande.

Posso usare l’AI per interrogare i miei dati a voce? Sì, ma dopo aver messo a posto definizioni e data product, non prima. Un LLM su dati con definizioni ambigue dà risposte sicure e potenzialmente sbagliate. Prima il prodotto solido, poi eventualmente il livello conversazionale sopra.

Quanto ci vuole per trasformare le dashboard morte in un prodotto usato? Meno di quanto pensi, perché spesso i dati ci sono già: manca il passo delle domande. Un workshop per le domande, l’assegnazione di proprietari e frequenze, e la ricostruzione delle poche schermate che contano possono dare risultati in poche settimane.

Come faccio a sapere se sto per rifare lo stesso errore? Fatti una domanda prima di partire: questo progetto comincia da uno strumento, da dei dati, o da una lista di decisioni? Se la risposta è «strumento» o «dati», stai per costruire un altro cimitero. Se è «decisioni e domande», sei sulla strada giusta. L’ordine da cui parti predice il risultato più di qualsiasi tecnologia.

E se ogni reparto vuole domande diverse? Benissimo: ogni reparto ha le sue decisioni e quindi le sue domande, con i suoi proprietari. L’importante è che poggino sulle stesse definizioni di base, così i numeri non si contraddicono. Domande diverse sopra, definizioni comuni sotto.

Devo buttare le dashboard che ho già? Quasi mai del tutto. Spesso i dati e parte del lavoro sono buoni: manca il passo delle domande. Si recupera ciò che serve, si buttano i grafici inutili e si ricostruisce attorno a poche domande con proprietario. Ricostruire dalla base giusta è più veloce che ripartire da zero.

Come coinvolgo le persone perché usino il nuovo prodotto? Coinvolgendole prima, nel workshop delle domande. Le persone usano ciò che hanno contribuito a definire e che risponde a una domanda che si facevano già. Uno strumento calato dall’alto, per quanto bello, viene ignorato; uno nato dalle loro decisioni viene aperto ogni giorno.

In una riga

Se hai speso in dashboard e non le apre nessuno, il problema non sono i dati: sono le domande. Il self-service BI fallisce perché dà a tutti i dati sperando che trovino le domande da soli; un data product fa il contrario — parte dalle decisioni, ne ricava le poche domande che contano, assegna a ognuna un proprietario e una frequenza, e le trasforma in schermate che si usano davvero. Non ti serve più grafici: ti serve la domanda giusta, agganciata a una decisione. È il filo che lega tutta la guida ai cruscotti e ai prodotti dati, di cui questo articolo è la tappa finale.

Se vuoi trasformare i tuoi numeri fermi in un prodotto che qualcuno apre ogni mattina per decidere, guarda i progetti che ho costruito o scrivimi due righe: partiamo dalle decisioni che devi prendere, non dai dati che hai.