Dashboard perfette, decisioni sbagliate: dove si rompe il processo
Contenuto articolo
Introduzione
La riunione dura quarantacinque minuti. La dashboard è proiettata sul muro, i grafici sono puliti, i colori sono quelli giusti. Tutti guardano i numeri. Nessuno mette in discussione cosa misurano. Alla fine si decide di rinnovare il contratto. Tre mesi dopo emerge che i costi reali erano il doppio di quelli visibili nella dashboard.
La dashboard non aveva mentito. Aveva mostrato esattamente quello che le era stato chiesto di mostrare. Il problema era già successo prima — quando qualcuno aveva deciso quali domande fare.
Il nesso tra dashboard e decisioni sbagliate raramente sta nei dati. Sta nel momento prima — quando qualcuno ha scelto cosa misurare.
La dashboard mostra quello che le hai chiesto
Ogni dashboard nasce da un momento in cui qualcuno ha compilato un form, scritto una specifica o risposto a una domanda del tipo “cosa vuoi vedere?”. In quel momento vengono scelti i KPI, la frequenza di aggiornamento, la baseline di confronto, il perimetro dei dati inclusi. La dashboard che si legge in riunione è la risposta fedele a quelle scelte — non una fotografia oggettiva della realtà.
Il problema è che quel momento iniziale viene dimenticato. La dashboard diventa “i dati”. Viene letta come se fosse neutrale, come se mostrasse tutto quello che c’è da sapere. E quando i numeri sono verdi, la decisione sembra ovvia — anche se i numeri verdi rispondono alle domande sbagliate.
Come mostra l’analisi sul contesto decisionale nel procurement, chi costruisce il perimetro informativo controlla implicitamente lo spazio delle risposte disponibili. Una dashboard costruita sulle metriche che il vendor ha proposto non è uno strumento di controllo — è uno strumento di conferma.
La dashboard non mente. Mostra esattamente quello che le è stato chiesto. Il problema è che nessuno ricorda più chi ha fatto le domande — e perché.
Dashboard e decisioni sbagliate: dove si rompe il processo
Il processo si rompe in tre momenti precisi — raramente nel momento in cui si legge il report.
Il primo è la selezione dei KPI. Chi li ha scelti, con quale criterio, in quale contesto? In molte organizzazioni i KPI di un contratto vengono definiti durante la fase di implementazione, quando il vendor è ancora presente e collabora alla configurazione del sistema. È il momento in cui la dashboard viene impostata — ed è il momento in cui il vendor ha più interesse a proporre metriche che valorizzino la sua piattaforma. Se il procurement non era in quella stanza, ha perso il momento che contava.
Il secondo è la baseline. Ogni variazione si misura rispetto a un punto di partenza. Se la baseline è stata scelta in un momento favorevole — un trimestre con utilizzo alto, un periodo senza incidenti — la dashboard mostrerà sempre una performance positiva, indipendentemente da cosa succede dopo. In un contratto cloud triennale, una baseline fissata nel trimestre di go-live — quando i volumi sono ancora bassi e i problemi operativi non si sono ancora manifestati — può rendere invisibile un deterioramento del 20-30% nelle performance reali nei trimestri successivi. La baseline non viene quasi mai rinegoziata nel corso del contratto.
Il terzo è il perimetro dei dati inclusi. Una dashboard sulla performance del servizio cloud include i tempi di risposta, la disponibilità, il throughput. Non include il tempo del team interno per gestire le eccezioni, il costo delle workaround operative, il debito tecnico accumulato nelle configurazioni. Queste voci non compaiono perché nessuno le ha chieste — non perché non esistano.
Un caso concreto illustra bene questo meccanismo. In una revisione contrattuale che ho seguito, la dashboard mostrava indicatori pienamente in linea con gli SLA concordati. Il vendor rispettava tutte le metriche previste dal contratto. Quello che la dashboard non mostrava era il tempo che il team interno dedicava ogni settimana alla gestione delle eccezioni operative e delle attività manuali necessarie per mantenere il servizio allineato ai processi aziendali. Formalmente il servizio funzionava. Operativamente stava consumando molte più risorse di quanto apparisse dai report. La dashboard era corretta. Il perimetro di misurazione era incompleto.
Il momento della decisione è prima della riunione
La riunione in cui si guarda la dashboard non è dove si decide. È dove si ratifica quello che è già stato deciso — implicitamente, a monte, quando qualcuno ha scelto cosa misurare.
Chi capisce questo cambia il proprio punto di intervento. Non aspetta la riunione per fare domande sui numeri. Interviene prima — quando i KPI vengono definiti, quando la baseline viene scelta, quando il perimetro dei dati viene impostato. In quel momento le variabili sono ancora aperte. Nella riunione non lo sono più.
È la stessa logica descritta nell’analisi sul procurement che fallisce sulle ipotesi: le assunzioni che guidano la decisione vengono fatte prima che il processo formale inizi. Chi non è presente quando vengono fatte lavora sempre dentro un perimetro che altri hanno già definito.
L’ICT Spend Analysis Dashboard è costruita su un perimetro diverso da quello che il vendor propone: distribuisce la spesa per categoria di costo reale — diretta, operativa, nascosta — e non per voce contrattuale. Il dato è lo stesso. Le domande che genera sono diverse. E quelle domande portano a una riunione diversa.
Una dashboard perfetta costruita sulle domande sbagliate produce decisioni sbagliate con grande precisione.
Dashboard perfette, processi sbagliati
Il problema non è la tecnologia. Non è la qualità dei dati. Non è la frequenza di aggiornamento o la chiarezza dei grafici. Il problema è strutturale: il processo che alimenta la dashboard è stato disegnato da qualcuno, in un momento specifico, con incentivi specifici. Se quel processo non viene messo in discussione, la dashboard migliorerà nel tempo — e le decisioni sbagliate diventeranno sempre più precise.
Approfondimenti utili
Perché una dashboard perfetta può portare a decisioni sbagliate?
Perché la dashboard mostra esattamente quello che le è stato chiesto di mostrare.
Se i KPI, la baseline e il perimetro dei dati sono stati scelti con criteri
sbagliati — o da chi aveva interesse a tenerli stretti — la dashboard sarà
tecnicamente impeccabile e informativamente fuorviante.
Dove si rompe il processo decisionale in una revisione contrattuale ICT?
In tre momenti precisi: quando vengono scelti i KPI (spesso durante
l’implementazione, con il vendor presente), quando viene fissata la baseline
di confronto, e quando viene definito il perimetro dei dati inclusi. Questi
tre momenti precedono la riunione — e in quella riunione non si decide più nulla.
Come si può costruire una dashboard più utile per il procurement ICT?
Partendo dal perimetro di costo reale, non da quello che il vendor propone.
Includere costi operativi interni, governance e dipendenza dal vendor —
non solo i KPI contrattuali. E soprattutto, essere presenti quando le
domande vengono definite, non solo quando i numeri vengono letti.
Condividi questo articolo