Quando il saving crea costo: il paradosso delle negoziazioni ICT
Contenuto articolo
Introduzione
Un provider cloud offre uno sconto del 22% su un piano triennale. Nelle negoziazioni ICT va così: il procurement chiude, segna il saving. Sei mesi dopo il reparto IT ha cambiato stack. I committed use restano.
Il risparmio che sposta il problema
La negoziazione aggressiva nei contratti ICT segue quasi sempre la stessa logica: abbassa il prezzo unitario, allunga il periodo di commitment, ottiene volumi. È una vittoria misurabile, riportabile, celebrabile nel report trimestrale.
Il problema è che il prezzo unitario è solo una delle variabili. Le altre — flessibilità, possibilità di riduzione del volume, clausole di uscita anticipata, diritto di migrazione — hanno un valore che non appare in nessuna riga del contratto ma che si materializza puntuale nel momento sbagliato.
Chi ha negoziato aggressivamente sul prezzo ha quasi sempre ceduto su quelle variabili. Non per incompetenza: perché il vendor le presenta come dettagli tecnici, non come leve di costo. E perché chi approva il contratto valuta il saving dichiarato, non il costo potenziale di ciò a cui si sta rinunciando.
Il vendor sa già quali clausole di flessibilità cederai per ottenere lo sconto. Le presenta come dettagli tecnici standard perché sa che chi approva il contratto guarda il saving, non il perimetro di rischio. Flessibilità, riduzione volumi e diritto di migrazione non sono dettagli — sono il costo nascosto dello sconto.
Il paradosso delle negoziazioni ICT: il saving che diventa costo strutturale
Il paradosso funziona così: il saving riduce la spesa visibile, ma aumenta la rigidità del contratto. E la rigidità, nei contesti ICT dove i bisogni cambiano ogni sei-dodici mesi, è un costo strutturale.
Non appare nel TCO. Non appare nel budget. Appare quando un progetto slitta, un fornitore cambia, una tecnologia diventa obsoleta — e non puoi uscire senza pagare penali che nessuno aveva previsto perché sembravano un’ipotesi remota. È il costo strutturale che non finisce nel TCO finché non è troppo tardi per gestirlo.
Come ho analizzato sul tema della prevedibilità della spesa cloud, il problema non è il livello assoluto di spesa ma la capacità di governarla nel tempo. Una negoziazione che ottimizza il prezzo a discapito della flessibilità fa esattamente il contrario: rende il contratto conveniente il giorno della firma e rigido nei dodici mesi successivi. Lo stesso meccanismo che trasforma le assunzioni non validate in costi che nessuno aveva messo a budget.
Un saving del 20% su un contratto rigido può costare il doppio se l’uscita anticipata diventa necessaria. Questo calcolo raramente viene fatto prima della firma — quasi sempre viene fatto dopo, quando il contratto è già chiuso e il vendor sa che non puoi andartene.
Il CFO vede il saving. Non vede il costo opportunità di non poter uscire quando l’infrastruttura cambia. Nessuno glielo porta.
Cosa cambia in chi negozia diversamente
Chi ha capito questo schema nelle negoziazioni ICT negozia in modo diverso: non parte dal prezzo, parte dal perimetro di rischio.
Prima di chiudere un contratto triennale, si chiede: cosa succede se tra un anno il consumo si dimezza? Se il progetto principale si chiude? Se arriva un’offerta migliore da un competitor? Le risposte devono essere nel contratto, non nell’ottimismo del business plan.
Questo non significa rinunciare allo sconto. Significa metterlo in prospettiva: nelle negoziazioni che funzionano, il procurement porta al tavolo due numeri — il risparmio ottenibile con lo sconto e il costo potenziale della rigidità. Solo quando entrambi sono visibili la decisione ha senso.
Il saving è una metrica di processo, non un indicatore di valore. Un procurement che viene valutato solo sul saving dichiarato ha un incentivo strutturale a negoziare aggressivamente sul prezzo — e a cedere su tutto il resto. Il problema non è chi firma il contratto: è come viene misurato chi lo negozia.
Il saving è una metrica. Non è un obiettivo.
Chi usa il saving come KPI primario nelle negoziazioni ICT ottimizza per il report, non per l’azienda. La negoziazione aggressiva risolve il problema di questo trimestre e lo rimanda al prossimo anno — quando il contratto è già firmato e il vendor sa già che non puoi andartene.
Approfondimenti utili
Flexera 2026 State of the Cloud Report
Perché uno sconto su un contratto ICT può diventare un costo?
Perché gli sconti vengono quasi sempre ottenuti cedendo flessibilità: commitment più lunghi, volumi fissi, penali di uscita. Se il bisogno cambia prima della scadenza — e nei contesti cloud cambia spesso — la rigidità del contratto costa più dello sconto ottenuto.
Cosa sono i committed use nel cloud e perché sono rischiosi?
Sono impegni di spesa minima garantita verso il provider, in cambio di tariffe scontate. Diventano un problema quando il consumo effettivo scende sotto il volume impegnato: si paga comunque, indipendentemente dall’utilizzo reale.
Come si valuta la flessibilità di un contratto ICT prima di firmarlo?
Verificando tre elementi prima dello sconto: le condizioni di riduzione del volume a metà contratto, le penali di uscita anticipata, e il diritto di migrazione dati senza costi aggiuntivi. Se nessuna di queste voci è negoziabile, lo sconto ha già un prezzo nascosto.
Condividi questo articolo