Vendor lock-in: non è tecnico, è una decisione presa male all’inizio
Contenuto articolo
Introduzione
Un’azienda media firma un contratto triennale con un vendor cloud. Dopo diciotto mesi, il CTO vuole cambiare piattaforma. Il procurement apre il contratto per valutare l’uscita anticipata. Trova una penale pari al 60% del valore residuo, clausole di migrazione dati con costi “a consuntivo” e un’architettura proprietaria che renderebbe il porting un progetto da sei mesi.
Nessuno ha commesso un errore tecnico. L’errore è avvenuto molto prima, al tavolo di valutazione, quando nessuno ha scritto “e se volessimo uscire?”.
Il lock-in non nasce nell’IT. Nasce nel procurement.
La narrativa più diffusa sul vendor lock-in lo descrive come un problema tecnologico: API proprietarie, formati dati incompatibili, dipendenza dall’ecosistema del vendor. Questa lettura è vera ma parziale — e pericolosa, perché sposta la responsabilità nel posto sbagliato.
Il lock-in tecnologico è quasi sempre la conseguenza di una decisione contrattuale presa in anticipo. E quella decisione la prende chi negozia, non chi implementa.
I meccanismi sono semplici e replicabili:
- Le clausole di uscita anticipata vengono negoziate in fase di gara, quando il vendor è motivato a vincere e il procurement è motivato a chiudere. Vengono raramente rilette dopo.
- I contratti pluriennali con sconti volumetrici creano dipendenza economica prima ancora che tecnica: uscire prima del termine non è impossibile, ma il costo finanziario lo rende impraticabile.
- Le architetture proprietarie diventano vincoli contrattuali quando nessuno ha incluso nella valutazione iniziale il costo di migrazione futura.
Chi firma capisce il problema solo quando è troppo tardi per tornare indietro. A quel punto, le opzioni rimaste sono negoziare in posizione di debolezza o continuare a pagare.
Il vendor lock-in più costoso non è quello tecnico — è quello che nessuno ha nominato durante la valutazione iniziale. Una volta firmato il contratto, le leve si chiudono quasi tutte. L’unica che rimane è il rinnovo, e a quel punto il vendor lo sa meglio di te.
Come si valuta il lock-in prima di firmare
Non serve un audit legale complesso. Bastano tre domande che raramente vengono poste esplicitamente durante la negoziazione:
1. Qual è il costo reale di uscita?
Non solo la penale contrattuale — anche il costo di migrazione dati, il tempo di porting, la riconfigurazione delle integrazioni, la formazione su una nuova piattaforma. Questo numero va costruito internamente, non chiesto al vendor.
2. Quanto velocemente si crea dipendenza tecnica?
Alcune piattaforme diventano pervasive in pochi mesi — si integrano con i processi, vengono usate da team diversi, accumulano dati storici che non è semplice esportare. Più è alta la pervasività, prima va valutata l’opzione di uscita.
3. Chi controlla i dati?
Le clausole di portabilità dei dati sono spesso presenti nei contratti, ma formulate in modo vago. “Esportazione su richiesta” può significare un file CSV da ricomporre manualmente o un’API strutturata e documentata. La differenza operativa è sostanziale.
In una valutazione che ho seguito, il trigger era arrivato dall’esterno: un vendor alternativo aveva presentato un’offerta sensibilmente più competitiva durante una gara parallela. La direzione voleva capire se esistesse margine per muoversi.
Quando abbiamo riaperto il contratto in corso, le sorprese erano due.
La prima era la penale di uscita — mai calcolata come importo assoluto, sempre percepita come una “clausola standard”. La seconda era più sottile: novanta giorni di preavviso obbligatorio prima ancora di poter avviare qualsiasi procedura di uscita. In pratica, la finestra utile per agire si era già chiusa prima ancora di iniziare la conversazione con il vendor attuale.
Nessuno aveva ignorato quella clausola al momento della firma. Era lì, era chiara. Ma non era mai diventata un numero dentro il modello decisionale iniziale.
Il Contract Renewal Planner disponibile su questo sito è stato costruito esattamente per questo: mappare i contratti ICT attivi, calcolare il costo di rigidità di ciascuno (penale × 0,5 + saving potenziale × 0,3) e visualizzare quali scadenze nei prossimi 90 giorni aprono una finestra di rinegoziazione reale. Se non hai mai fatto questo calcolo sui tuoi contratti, è il momento giusto.
Cosa cambia nelle decisioni
Chi gestisce bene il rischio di lock-in non lo fa durante il contratto — lo fa prima. La differenza operativa è concreta:
Prima della firma, costruisce internamente le ipotesi di uscita — incluso il confronto tra soluzioni alternative, che cambia il perimetro della negoziazione prima ancora di aprirla. Non come scenario catastrofista, ma come parte della valutazione economica: il contratto vale X, il costo di uscita anticipata è Y, la dipendenza tecnica matura in Z mesi. Con questi numeri in mano, la negoziazione sulle penali ha un perimetro definito.
Durante l’esecuzione, monitora i segnali di lock-in progressivo: quanti team usano la piattaforma, quanti processi dipendono da essa, quanti dati storici si stanno accumulando in formati proprietari. Non per uscire — per sapere quanto costa farlo se necessario.
Al rinnovo, non si presenta senza alternative. Anche se non intende cambiare vendor, ha fatto la valutazione. E il vendor lo percepisce.
Il procurement che arriva al rinnovo senza aver mai calcolato il costo di uscita non sta negoziando — sta ratificando.
Approfondimenti utili
- Le assunzioni che nessuno scrive nei contratti ICT
- Quando la decisione sbagliata non è il prezzo
- Gartner — Cloud Strategy and Vendor Lock-in
Cos’è il vendor lock-in in ambito ICT e perché è difficile uscirne?
Il vendor lock-in è la dipendenza da un fornitore tecnologico che rende costoso o impraticabile il cambiamento. Nasce spesso dalle clausole contrattuali e dall’architettura proprietaria scelte durante la valutazione iniziale — non dall’implementazione tecnica.
Come si calcola il costo di uscita da un contratto ICT in corso?
Il costo reale include la penale contrattuale, i costi di migrazione dati, il tempo di porting tecnico e la formazione su una nuova piattaforma. Va costruito internamente prima del rinnovo, non chiesto al vendor.
Quando è il momento giusto per valutare il rischio di lock-in?
Prima di firmare — non durante o dopo. Il momento della negoziazione iniziale è l’unico in cui si ha ancora leva sulle clausole di uscita, la portabilità dei dati e le condizioni di rinnovo.
Condividi questo articolo