Perché il procurement arriva sempre “troppo tardi”
Contenuto articolo
Introduzione
Nel procurement ICT la tempistica di ingresso è tutto — eppure raramente viene gestita. In molte trattative enterprise, il procurement entra quando il vendor è già stato scelto informalmente da settimane — a volte mesi.
Il perimetro è già definito. Le condizioni economiche sono già state discusse informalmente. Il vendor sa già che la trattativa è avanzata. Il procurement entra con una sola leva reale: il prezzo. E spesso neanche quella.
Il problema non è la velocità
La spiegazione più comune è organizzativa: il procurement è lento, burocratico, non allineato con i tempi dell’IT. È una lettura comoda — e quasi sempre sbagliata. Il procurement non arriva tardi perché lavora male. Arriva tardi perché il processo è costruito in modo che arrivi tardi.
In molte organizzazioni, il procurement ICT viene attivato nella fase finale del ciclo decisionale. Chi sceglie la tecnologia è l’IT. Chi gestisce il budget è il CFO. Chi ha il rapporto con il vendor è spesso un business owner. Il procurement entra quando tutte le parti hanno già trovato un accordo di massima — e il suo ruolo diventa ratificare, non decidere.
Il risultato è che le variabili su cui il procurement potrebbe incidere di più — perimetro contrattuale, clausole di uscita, struttura dei costi nel tempo — sono già state implicitamente definite prima che lui arrivi al tavolo.
Quando il procurement entra a contratto già impostato, la sua unica leva è il prezzo. Ma il prezzo è spesso la variabile meno rilevante nel TCO reale di un contratto ICT triennale.
È una dinamica che produce effetti visibili soprattutto nei rinnovi pluriennali. In un caso tipico, il procurement può ottenere un saving immediato sul canone annuale intervenendo nella fase finale della trattativa, ma senza riuscire a modificare commitment minimi, meccanismi di crescita o clausole di uscita. Nei 12-24 mesi successivi, l’aumento dei volumi operativi e il costo di dipendenza dal vendor tendono ad assorbire rapidamente il vantaggio economico iniziale.
Cosa si perde arrivando tardi
Il momento in cui il procurement entra determina cosa può negoziare. Entrare tardi non significa solo avere meno potere contrattuale — significa non poter più toccare le voci che contano di più nel lungo periodo.
Le clausole di uscita si negoziano prima della firma, non dopo. I meccanismi di revisione prezzi si costruiscono nella struttura contrattuale iniziale. La portabilità dei dati, le penali di lock-in, i commitment minimi — sono tutti elementi che si definiscono quando il vendor ha ancora interesse a chiudere. Una volta firmato, ogni modifica richiede una rinegoziazione in cui la posizione di partenza è di svantaggio.
Come mostra l’analisi sul TCO nel procurement ICT, il perimetro di costo dichiarato al momento della firma copre in media meno della metà del costo reale sul ciclo di vita del contratto. La parte restante — governance, exit cost, dipendenza operativa — si cristallizza nei mesi successivi, quando il procurement non ha più voce in capitolo.
Non a caso, nei contratti cloud più complessi i costi che sfuggono alla governance non emergono al momento della firma — emergono nei trimestri successivi, quando le scelte architetturali sono già consolidate e modificarle ha un costo reale.
Il punto critico è che il lock-in economico non nasce al rinnovo: nasce molto prima, nella fase in cui vengono definiti volumi, dipendenze operative e commitment tecnici. È per questo che i framework di Total Cost of Ownership insistono sempre meno sul prezzo iniziale e sempre di più sui costi di ciclo di vita, governance ed evoluzione operativa, come evidenziato anche nelle analisi Gartner sul Total Cost Ownership e sui modelli di costo enterprise (Gartner – Unlocking Value: Principles of Total Cost Ownership).
Il costo del ritardo strutturale
C’è un secondo problema, meno visibile del primo. Quando il procurement arriva tardi in modo sistematico, smette di accumulare la conoscenza che gli servirebbe per arrivare prima la volta successiva.
Chi non è presente nella fase di valutazione tecnologica non capisce perché certe scelte vengono fatte. Non conosce i vincoli tecnici che hanno orientato la selezione. Non sa quali alternative sono state scartate e per quale motivo. Il suo contributo resta circoscritto alla negoziazione finale — e la negoziazione finale, senza contesto, produce risultati limitati.
È la stessa logica descritta in l’articolo sulle ipotesi che guidano le decisioni ICT: il problema non è che le assunzioni siano sbagliate, è che chi dovrebbe verificarle non è nel processo quando vengono fatte.
Il procurement che arriva tardi non impara dal ciclo precedente. Ogni contratto ricomincia dallo stesso punto — senza memoria delle variabili che avrebbero fatto la differenza.
Quando il procurement può ancora cambiare qualcosa
La finestra utile non è al rinnovo — a quel punto il lock-in è maturo e le alternative sono costose. La finestra utile è nei 60-90 giorni prima che la valutazione tecnologica venga finalizzata. In quel momento il vendor non ha ancora una posizione consolidata, le opzioni sono ancora reali e le clausole contrattuali sono ancora negoziabili senza costi di contesto.
Entrare in quella finestra richiede una cosa sola: sapere quando si apre. Non è un problema tecnico — è un problema di visibilità sul pipeline decisionale interno. Chi nel procurement ICT ha accesso alle roadmap tecnologiche dell’IT, anche in forma aggregata, può anticipare il momento di coinvolgimento. Chi non ce l’ha aspetta di essere chiamato.
Il Contract Renewal Planner nasce esattamente da questa necessità: non gestire il rinnovo quando arriva, ma strutturare le scadenze in anticipo — con visibilità sui contratti in scadenza entro 90 giorni, sul costo di rigidità di ciascuno e sul saving potenziale disponibile prima che la finestra si chiuda. Il procurement che lavora con questo strumento non aspetta di essere chiamato: sa già quando è il momento di sedersi al tavolo.
La domanda non è “come negoziamo meglio?”. È “come entriamo prima nel processo, quando le variabili che contano sono ancora aperte?”
Come si cambia il punto di ingresso
Non esiste una soluzione organizzativa unica — dipende dalla struttura dell’azienda e dal rapporto tra procurement e IT. Ma ci sono due leve che funzionano indipendentemente dal contesto.
La prima è la visibilità anticipata. Il procurement ICT deve avere accesso, anche informale, alle conversazioni tecnologiche prima che si trasformino in richieste d’acquisto. Un incontro trimestrale con l’IT per capire la roadmap dei prossimi 6-12 mesi è sufficiente per identificare quando aprire i dossier contrattuali. Il valore reale di questi incontri non è discutere i contratti già attivi, ma intercettare segnali anticipatori: workload in migrazione, nuovi progetti SaaS, aumenti previsti di licenze, rinnovi infrastrutturali o cambiamenti architetturali pianificati. Anche una roadmap ad alto livello è sufficiente per capire quali dossier aprire prima che la trattativa sia già implicitamente chiusa.
La seconda è la documentazione delle assunzioni. Ogni valutazione tecnologica poggia su ipotesi implicite — tassi di adozione, volumi, durata effettiva. Come evidenziato nell’analisi sul vendor lock-in, la dipendenza si consolida molto prima della firma. Se il procurement contribuisce a rendere esplicite e verificabili queste ipotesi fin dall’inizio, il suo ruolo smette di essere burocratico e diventa analitico — una differenza che il CFO percepisce, e che cambia il peso del procurement nel processo decisionale.
La tempistica nel procurement ICT: finché il processo lo permette
Il ritardo del procurement ICT non è un problema di competenze o di velocità. È un problema di architettura del processo decisionale. Finché la tecnologia viene scelta da una parte e acquistata da un’altra, il procurement opererà sempre a valle delle variabili che contano.
Cambiare questo richiede una sola cosa: entrare prima. Non per controllare le scelte tecnologiche — non è il suo ruolo — ma per essere presente quando le condizioni economiche del contratto sono ancora plasmate da chi compra, non da chi vende.
Perché il procurement ICT arriva sempre tardi nelle decisioni tecnologiche?
Nella maggior parte delle organizzazioni il procurement viene attivato nella fase finale
del ciclo decisionale, quando tecnologia e vendor sono già stati scelti dall’IT o dal
business. Non è un problema di velocità — è come il processo è costruito. Il procurement
entra per ratificare, non per decidere.
Cosa si perde quando il procurement entra a contratto già definito?
Le variabili che contano di più nel lungo periodo: clausole di uscita, meccanismi di
revisione prezzi, penali di lock-in, portabilità dei dati. Tutti elementi che si negoziano
prima della firma, quando il vendor ha ancora interesse a chiudere. Dopo, ogni modifica
parte da una posizione di svantaggio.
Come può il procurement ICT anticipare il proprio coinvolgimento?
La leva principale è la visibilità sulla roadmap tecnologica dell’IT, anche in forma
informale. Un incontro trimestrale per capire le valutazioni in corso nei 6-12 mesi
successivi è sufficiente per identificare quando aprire i dossier contrattuali — prima
che il vendor abbia già una posizione consolidata.
Condividi questo articolo