Quando i saving IT richiedono più di un target
La maggior parte dei grandi programmi di costo IT mostra un pattern familiare: target ambizioso a inizio anno, status verde sicuro durante Q1 e Q2, slittamento che inizia in Q3 e silenzioso rinvio della porzione non realizzata all'anno successivo. Raramente si tratta di un problema di intento. È disconnessione strutturale tra logica finanziaria e realtà di delivery.
Diagnostico
Il tuo programma di saving IT sta andando alla deriva?
- I target di saving sono stati definiti top-down senza essere mappati a leve tecniche specifiche, owner e milestone con date precise.
- La stessa voce è riportata come "saved" da IT e "non ancora realizzata" dalla Finance — e la discrepanza resta irrisolta.
- Nessun individuo nominato è proprietario di ogni leva; solo uno sponsor esecutivo è proprietario del totale di programma.
- Le regole di evidenza ("quando un saving conta?") non sono mai state concordate per iscritto con la controller community.
- Il re-baselining di fine anno spinge silenziosamente i saving non realizzati nel piano successivo invece di riconoscerli come miss.
Contesto
I programmi di riduzione costi iniziano con un target top-down. Il numero può essere corretto, ma non spiega come i saving saranno creati, quando saranno riconosciuti né quale evidenza sarà accettata. Senza traduzione in leve specifiche di proprietà di persone nominate, il target galleggia sopra il piano operativo — reale sulla carta, non realizzato sul general ledger.
Cosa va tipicamente male
I saving sono distribuiti su infrastruttura, applicazioni, contratti e cambiamenti di operating model, ma le leve tecniche non sono collegate al forecast finanziario. Gli owner sono nominali. Le milestone sono morbide. Le regole di evidenza sono assenti. Il programma riporta saving che IT riconosce e Finance no — e la discrepanza emerge solo a fine anno, quando il replanning è già iniziato.
Cinque elementi per ogni leva: driver, owner, milestone, evidenza tecnica, evidenza finanziaria riconciliata al general ledger.
Dove i saving vivono fisicamente
I saving reali nascono da mosse tecniche specifiche: dismissione di un parco server legacy, terminazione di licenze software inutilizzate, riduzione della capacità cloud, automazione di un processo manuale di run. Ogni target finanziario deve essere mappato all'azione specifica che lo produce. Senza quella mappatura, il saving è una proiezione.
La domanda è il re-inflator
I programmi di costo che non controllano la crescita della domanda non producono alcun saving netto. La crescita business re-gonfia la base di costo alla stessa velocità con cui i saving tecnici si realizzano. La governance della domanda — business case, charge-back, gate di prioritizzazione — deve essere in scope, non rinviata a un'iniziativa separata.
Il libro mastro è l'arbitro
Ogni saving realizzato deve essere riconciliato al general ledger dalla controller community. Se finance e IT non concordano che un saving si è materializzato, non si è materializzato. Le regole di evidenza devono essere definite a design del programma — non negoziate a fine anno.
Forum che rivedono per leva — non per colore
Se il forum esecutivo rivede i saving per categoria e status RAG, l'accountability si diluisce. Se rivede per leva, owner ed evidenza — con la milestone tecnica sul tavolo — il framework regge attraverso slittamenti ed escalation.
"La differenza tra un target di saving e un beneficio realizzato è la governance."
— Prospettiva RSV Consult
Cosa funziona nella pratica
Un modello di value capture collega ogni saving a un driver — dismissione, riduzione capacità, razionalizzazione licenze, cambio di sourcing, ridisegno operating model. Ogni leva ha un owner, una catena di dipendenze, una data di milestone e una regola di evidenza finanziaria. La governance rivede per leva e owner, non per categoria e colore.
I primi 90 giorni
Inventario e traduzione
Mappare ogni target di saving annunciato a una leva tecnica specifica, owner nominato, data di milestone e regola di evidenza. Rifiutare ogni voce che non può essere tracciata. L'output è un unico registro di value capture che sostituisce il tracker di programma.
Baseline e strumentazione
Riconciliare la baseline del programma al general ledger con la controller community. Bloccare per iscritto le regole di evidenza. Configurare la reportistica a livello di leva, non di categoria — così finance e IT leggono lo stesso numero.
Ridisegno del forum
Sostituire la reportistica solo a RAG con una review mensile che decide a livello di leva e owner. Lo slittamento diventa visibile alla milestone tecnica — non al re-baselining di fine anno — quindi può ancora essere recuperato.
Cosa cambia quando questo funziona
I programmi che girano su un framework di value capture funzionante convertono i saving annunciati in riduzioni riconosciute dal general ledger a tassi materialmente più alti rispetto ai programmi gestiti per categoria e RAG. Lo slittamento è identificato a livello tecnico, settimane prima, quando c'è ancora tempo per mitigarlo attraverso decisioni di scope, sequencing o sourcing. Finance e IT smettono di discutere se i saving sono reali e iniziano a lavorare insieme su quale leva recuperi il gap. Il CFO non sente più "abbiamo risparmiato €X" da IT e "non lo abbiamo visto" dal controller — lo stesso numero arriva in entrambe le reportistiche.
La trasformazione dei costi riesce quando finance e tecnologia parlano lo stesso linguaggio basato sull'evidenza. Se il saving non può essere riconciliato al general ledger, è un forecast — non un saving.