Il procurement ICT non fallisce sui costi. Fallisce sulle ipotesi.
Quando le assunzioni di partenza non vengono mai scritte, verificate o messe in discussione, il contratto è già perso prima di essere firmato.
Contenuto articolo
Introduzione
Lavoro in un cloud provider. Vedo regolarmente aziende approvare spese ICT con business case solidi sulla carta. I numeri tornano, il budget è rispettato, il vendor — spesso noi — ha risposto punto per punto al capitolato. Qualche mese dopo, i consumi reali divergono dalle previsioni e nessuno sa esattamente dove si è sbagliata la valutazione.
Non si è sbagliato il calcolo. Si sono sbagliate le ipotesi su cui era costruito.
Le ipotesi che nessuno scrive
Ogni valutazione economica in ambito ICT poggia su una serie di assunzioni: quanti utenti useranno davvero la piattaforma, con quale frequenza, per quanto tempo, con quale intensità. Queste assunzioni raramente vengono scritte da qualche parte in forma esplicita. Vivono nelle teste di chi ha costruito il business case, nelle slide della presentazione al CDA, in qualche foglio Excel che nessuno aggiornerà mai.
Il problema non è che le ipotesi esistano — è inevitabile farle. Il problema è che restando implicite, non possono essere contestate, riviste o confrontate con la realtà. Quando qualcosa non torna, non c’è un punto di riferimento a cui tornare. L’unica cosa che rimane è il contratto firmato.
È una dinamica che vedo ripetersi: il business case viene costruito su tassi di adozione che nessuno ha mai messo nero su bianco. Quando l’utilizzo reale diverge — e diverge quasi sempre — il contratto è corretto, i prezzi erano competitivi, ma l’intero modello economico era costruito su un’aspettativa condivisa, non su un’ipotesi verificabile.
Quando le ipotesi non sono nemmeno tue
C’è un secondo livello, più scomodo.
Quando le assunzioni vengono esplicitate — e capita, soprattutto nei progetti più strutturati — spesso non sono costruite internamente. Sono le stime fornite dal vendor: proiezioni di utilizzo, benchmark di settore, scenari di adozione. Dati presentati con autorevolezza, spesso difficili da verificare in autonomia, quasi sempre orientati a supportare l’acquisto.
Chi arriva al tavolo con i numeri è il vendor. Chi arriva con impressioni sei tu.
Le proiezioni del vendor partono da un interesse preciso e da dati aggregati di mercato che potrebbero non riflettere il tuo contesto. Il risultato è una valutazione economica che sembra solida, ma che poggia su fondamenta che non appartengono a chi deve poi viverle.
Una proiezione di utilizzo fornita dal vendor non è una previsione neutrale. È una stima costruita da chi ha interesse a vendere, su dati aggregati di mercato che potrebbero non riflettere il tuo contesto. Trattarla come dato di input senza verifica interna è uno dei rischi più sottovalutati nelle valutazioni ICT.
Il momento in cui saperlo non serve più
Il punto più critico non è che le ipotesi siano sbagliate. È che il sistema non prevede un momento reale per verificarle prima che diventino vincoli.
I contratti ICT vengono valutati al momento della firma. Le clausole di revisione esistono, ma vengono negoziate raramente e attivate ancora meno. Il monitoraggio operativo — quando c’è — misura consumi e performance tecniche, non lo scostamento rispetto alle ipotesi originali.
Quando i dati reali emergono con chiarezza — dopo 9, 12, 18 mesi — il contratto è già in esecuzione. Il vendor ha incassato, il team ha cambiato priorità, il rinnovo si avvicina. L’unica leva rimasta è la negoziazione del prossimo ciclo, spesso in posizione di debolezza perché nel frattempo si è creata dipendenza.
Il procurement ICT è strutturato per valutare al momento dell’acquisto. Non è strutturato per imparare durante l’esecuzione. Questo gap — tra la decisione e la verifica — è dove si concentra la maggior parte degli sprechi che nessuno riesce a ricondurre a una causa precisa.
Chi gestisce meglio non aspetta il rinnovo per fare i conti. Costruisce fin dall’inizio un set minimo di ipotesi esplicite — scritte, condivise, con un owner — e definisce quando e come verranno confrontate con i dati reali.
Esempio minimo: “Adozione prevista 70% entro 6 mesi — owner: IT Manager — verifica: Q2”. Tre campi, un owner, una data. È tutto quello che serve per rendere un’ipotesi verificabile.
Il contratto non è il punto di arrivo della valutazione. È il momento in cui smetti di poterla correggere. Per questo le ipotesi vanno scritte prima — non per essere giuste, ma per poter essere sbagliate nel modo giusto.
Approfondimenti utili
- Procurement digitale, cloud e dati ICT: il quadro reale
- Quando un KPI mente: cosa non dicono i numeri del procurement
- Gartner — IT Spending Forecast (press release)
Perché i progetti ICT sforano quasi sempre il budget previsto?
Nella maggior parte dei casi non si sbaglia il calcolo, si sbaglia l’ipotesi di partenza: tasso di adozione, volumi di utilizzo, durata effettiva. Queste assunzioni raramente vengono scritte in forma esplicita e quasi mai vengono verificate durante l’esecuzione del contratto.
Come si evita di basare una valutazione ICT sulle proiezioni del vendor?
Il punto di partenza è costruire internamente un set minimo di ipotesi esplicite — con un owner e una data di verifica — prima di confrontarle con le stime del vendor. Non per contestarle, ma per avere un riferimento autonomo da cui partire nella negoziazione.
Quando è il momento giusto per verificare le ipotesi di un contratto ICT?
Non al rinnovo — a quel punto il contratto è già eseguito e le leve sono limitate. Il momento utile è tra i 6 e i 12 mesi dall’avvio, quando i dati reali di utilizzo sono disponibili ma il vendor non ha ancora consolidato la posizione di rinnovo.
Condividi questo articolo