Il TCO è inutile se non sai cosa stai davvero comprando
Contenuto articolo
Introduzione
Un’azienda nel settore dei servizi finanziari firma un contratto con un provider cloud enterprise.
Il TCO è stato fatto: tre anni, costi di licenza, supporto, infrastruttura.
Il numero è solido. La direzione approva.
Diciotto mesi dopo, i costi reali superano del 60% il modello originale.
Nessun errore di calcolo. Nessuna clausola nascosta scoperta tardivamente.
Il TCO era corretto — ma calcolava la cosa sbagliata.
Il problema non è il foglio Excel
Nel procurement ICT, il TCO viene costruito su quello che sai già. Licenze: le quote le ha fornite il vendor. Infrastruttura: i sizing li ha stimati l’IT. Supporto: il livello è nel contratto.
Tutto questo è reale. Ma è il perimetro che il vendor ha contribuito a definire.
Quello che non entra nel modello non è difficile da calcolare — è difficile da vedere finché non è già successo. Il personale interno che gestisce il contratto giorno per giorno non è mai nel TCO. La governance — le riunioni di steering, le escalation, il tempo del procurement nella gestione ordinaria — non è mai nel TCO. I costi di migrazione a fine periodo, quando le clausole di lock-in sono mature, non sono mai nel TCO perché al momento della firma sembrano un’ipotesi remota.
Il costo operativo interno — personale dedicato, governance, monitoraggio, compliance — raramente compare nell’offerta iniziale. Non perché sia marginale, ma perché al momento della firma è distribuito nell’organizzazione e non ha un owner esplicito. Nessuno lo porta nel modello perché nessuno lo possiede.
In contratti cloud di media complessità, questo blocco di costi può pesare tra il 30% e il 50% del costo dichiarato.
Stima basata su esperienza diretta — non è un dato da fonte terza. L’ordine di grandezza varia in base alla maturità del team ICT interno e alla complessità dell’integrazione. Il punto non è la percentuale esatta: è che nella maggior parte dei TCO questa voce vale zero.
È qui che il TCO inizia a divergere dalla realtà. Non sul canone — su tutto quello che serve per farlo funzionare.
Chi definisce il perimetro
Questa è la parte che non viene detta abbastanza chiaramente: il perimetro del TCO lo decide quasi sempre chi ha un incentivo a tenerlo stretto.
Il vendor presenta il suo modello di costo. È ottimizzato per rendere la propria soluzione competitiva nel confronto. Le voci che favorirebbero un confronto onesto — exit cost, complessità di integrazione, dipendenza tecnica matura — non compaiono nella presentazione e raramente vengono aggiunte da chi compra.
L’articolo sul vendor lock-in mostra esattamente questo meccanismo: la dipendenza non è tecnica, è economica — e si consolida nei mesi successivi alla firma, non al momento della scelta.
Il procurement, dal suo lato, tende a costruire il TCO su quello che è verificabile e difendibile in fase di approvazione. I costi certi (licenze, canoni) sono facili da documentare. I costi incerti o impliciti (governance, rischio downtime, debito tecnico accumulato) richiedono assunzioni che qualcuno deve fare proprie — e che qualcuno potrebbe contestare.
Il risultato è un TCO che non è sbagliato. È semplicemente incompleto per costruzione.
Il perimetro del TCO lo costruisce quasi sempre chi ha un incentivo a tenerlo stretto. Se parti dall’offerta del vendor per aggiungere voci, stai già lavorando sul suo modello — non sul tuo.
TCO procurement ICT: cosa cambia quando allarghi il perimetro
Ho sviluppato il TCO Calculator ICT — uno strumento Python open source — proprio per rendere visibile questo meccanismo su dati reali. Distribuisce la spesa su tre livelli: costi diretti, costi operativi interni e costi nascosti. L’output chiave è l’Indice di Costo Invisibile: il rapporto tra costi indiretti e costo dichiarato, espresso in percentuale.
Nello scenario sintetico precaricato — contratto cloud enterprise da €120.000/anno su tre anni — il TCO reale supera del 106% il dichiarato. I costi nascosti (exit cost, lock-in, migrazione, integrazione) da soli pesano €94.000 sull’intero periodo. Non sono cifre inventate: sono ordini di grandezza coerenti con contratti cloud di media complessità.
Il dato non è isolato. Il Flexera 2026 State of the Cloud Report rileva che il 29% della spesa cloud viene sprecato ogni anno — e la percentuale è tornata a salire. Non perché le aziende non abbiano gli strumenti per misurarlo, ma perché non hanno definito cosa misurare.
Il punto non è il numero finale. È la domanda che quel numero obbliga a fare: queste voci le hai già portate al tavolo negoziale, o stai ancora discutendo solo del canone?
Come si negozia con un perimetro corretto
Chi ha capito il problema cambia il momento in cui costruisce il TCO — non solo il contenuto.
Il modello viene costruito prima del confronto con il vendor, non dopo. Questo cambia tutto: invece di partire dall’offerta e aggiungere voci, si parte dal ciclo di vita reale del servizio e si mappa ogni categoria di costo. Diretti, operativi, nascosti. Il vendor viene poi invitato a portare i propri numeri su un perimetro già definito.
Il modello viene costruito prima del confronto con il vendor, non dopo. Questo cambia tutto: invece di partire dall’offerta e aggiungere voci, si parte dal ciclo di vita reale del servizio e si mappa ogni categoria di costo. Diretti, operativi, nascosti. Il vendor viene poi invitato a portare i propri numeri su un perimetro già definito. È anche il motivo per cui il procurement arriva quasi sempre troppo tardi — quando il perimetro è già stato negoziato da qualcun altro.
Come con le negoziazioni aggressive che ottimizzano il prezzo e peggiorano la rigidità, anche qui il rischio è portare al tavolo il numero sbagliato — un TCO che non include i costi che emergeranno nei dodici mesi successivi alla firma.
L’altra differenza riguarda la distribuzione temporale. Il problema della prevedibilità della spesa cloud non è solo una questione di variabilità mensile: è che certi costi si concentrano negli anni due e tre del contratto, quando il lock-in è maturo e le alternative sono più costose da percorrere. Un TCO che non modella questa curva non è uno strumento di analisi — è un documento di approvazione.
Il TCO è uno strumento di governance, non di giustificazione
La differenza tra un TCO che funziona e uno che non funziona non è nella precisione del calcolo. È in chi ha definito le domande prima di compilarlo.
Se le domande le ha fatte il vendor, il perimetro serve al vendor.
Se le hai fatte tu, il perimetro serve alla decisione.
Cosa si intende per TCO nel procurement ICT?
Il Total Cost of Ownership in ambito ICT include tutti i costi legati a un contratto o una tecnologia nel suo ciclo di vita: non solo il canone dichiarato, ma anche costi operativi interni, governance, integrazione, formazione ed exit cost. Il problema più comune non è calcolarlo male, ma calcolarlo su un perimetro troppo stretto.
Quali sono i costi nascosti più frequenti in un contratto cloud?
I più frequenti sono: costi di uscita anticipata e migrazione dati, overhead di governance interna (tempo del team ICT e procurement), complessità di integrazione con sistemi esistenti, e il costo implicito del vendor lock-in che matura nei mesi successivi alla firma. Raramente compaiono nell’offerta — quasi sempre compaiono in fattura.
Come si costruisce un TCO corretto prima della negoziazione?
Partendo dal ciclo di vita reale del servizio, non dall’offerta del vendor. Si mappano tre livelli di costo — diretti, operativi e nascosti — prima di aprire il confronto con il fornitore. Questo inverte la logica: è il vendor a portare i propri numeri su un perimetro già definito internamente, non il contrario.
Condividi questo articolo