Il budget fatto di preventivi
In molte aziende il budget IT si costruisce così: si prendono i preventivi dell'anno prima, si aggiungono i rinnovi, si lascia un po' di margine. Poi arrivano le emergenze: il server che si guasta, il firewall che il produttore non aggiorna più, il cliente importante che chiede di dimostrare le tue misure di sicurezza. Si paga, d'urgenza e al prezzo dell'urgenza.
Il risultato è un budget che descrive cosa hanno proposto i fornitori, non cosa serve all'azienda. Costruirlo al contrario significa partire dai rischi e dagli obiettivi, e arrivare ai preventivi solo alla fine. È il lavoro dell'IT governance: priorità, budget e criteri di scelta dei fornitori.
Prima distinzione: tenere acceso e cambiare
Il primo passo è separare due spese che di solito finiscono nella stessa riga. La spesa corrente (in inglese «run») fa funzionare quello che c'è. I progetti («change») servono a cambiare: un sistema nuovo, una migrazione, un intervento di sicurezza.
| Run (spesa corrente) | Change (progetti) | |
|---|---|---|
| Cosa comprende | Licenze e canoni, assistenza, connettività, manutenzione, sostituzioni programmate | Nuovi sistemi, migrazioni, progetti di sicurezza, integrazioni |
| Come si stima | Dai contratti in essere e dall'inventario, con le scadenze | Dal progetto: perimetro, fasi, ore interne ed esterne |
| Rischio tipico | Cresce in silenzio, un abbonamento alla volta | Viene tagliato per primo, anche quando riduce un rischio grave |
Separarle mostra quanta parte del budget serve solo a restare dove sei. Se la spesa corrente assorbe tutto, i progetti slittano e i sistemi invecchiano.
Ogni sistema ha una data di scadenza
PC, server, firewall, sistemi operativi e applicazioni hanno una data di fine supporto, dopo la quale il produttore non rilascia più correzioni. Quella data si conosce in anticipo, spesso di anni. Scriverla nell'inventario e pianificare le sostituzioni trasforma un acquisto d'urgenza in una spesa prevista. I rischi di un sistema a fine vita sono spiegati nella guida sul patch management.
Conta anche il costo totale di possesso (TCO, Total Cost of Ownership): il prezzo d'acquisto è solo l'inizio. Un sistema costa anche in installazione, licenze, assistenza, formazione, ore interne e, alla fine, dismissione e migrazione dei dati. Due offerte con lo stesso prezzo possono avere costi totali molto diversi.
Poi ci sono gli abbonamenti in cloud, che entrano un reparto alla volta: il commerciale attiva uno strumento, il marketing un altro, qualcuno se ne va e la licenza resta. Una revisione annuale, con chi li usa e chi li paga, di solito trova qualcosa da disdire.
Il debito tecnico, spiegato a un direttore amministrativo
Ogni volta che si rimanda un aggiornamento, si sceglie una soluzione provvisoria o si tiene in vita un sistema vecchio «perché funziona», si risparmia oggi e si contrae un debito. Come un finanziamento, il debito tecnico produce interessi: ogni anno costa di più in assistenza, tempo perso ed esposizione agli attacchi, e la migrazione rimandata diventa più cara. Non serve azzerarlo, ma va conosciuto e ripagato con un piano, prima che un guasto lo renda esigibile tutto insieme.
Come si costruisce, passo per passo
- Parti dall'inventario: sistemi, contratti, licenze e abbonamenti, con scadenze e date di fine supporto.
- Elenca rischi e obiettivi con la direzione: cosa non deve succedere (il gestionale fermo durante la chiusura di mese) e dove vuole andare l'azienda (una nuova sede, l'e-commerce).
- Separa run e change, e stima la spesa corrente dai contratti reali, non dall'anno precedente.
- Metti in ordine i progetti con una matrice rischio/valore. Vengono prima gli obblighi: se rientri nella NIS2, le misure di gestione del rischio non sono una scelta e gli organi di amministrazione ne rispondono (vedi la guida sulla NIS2 per le PMI). Poi ciò che riduce un rischio grave, come backup mai provati. Poi ciò che porta valore.
- Disegna una roadmap su tre anni: il primo anno nel dettaglio, il secondo e il terzo a grandi linee, con le sostituzioni già in calendario. Un passaggio al cloud, per esempio, occupa spesso più di un esercizio.
- Lascia un margine per gli imprevisti, dichiarato come tale.
- Rivedila ogni trimestre: cosa è stato fatto, cosa è cambiato, cosa scala di priorità.
Come presentarlo alla direzione
Una richiesta scritta in termini tecnici («serve un firewall di nuova generazione») si confronta male con le altre voci. La stessa richiesta, scritta in termini di rischio, diventa una decisione che la direzione sa prendere: quale processo protegge, cosa succede se non si fa, quanto costerebbe un fermo. Per l'ultima domanda puoi partire dal simulatore del costo del fermo, con i numeri della tua azienda.
Diffida dei confronti con quanto spenderebbero «le aziende come la tua»: sono medie che non conoscono il tuo settore né i rischi che hai già ridotto. Il budget si giustifica con i tuoi rischi, non con quelli degli altri.
Gli errori più comuni
- Rinnovare tutto per inerzia, senza chiedersi se serve ancora.
- Tagliare per prima la sicurezza, perché non produce nulla di visibile finché non succede qualcosa.
- Nessun margine per gli imprevisti, che poi arrivano comunque e scavalcano le priorità decise.
- Una roadmap scritta e mai riaperta, che dopo sei mesi è già vecchia.
In sintesi
Un budget IT costruito sui preventivi dell'anno prima descrive i fornitori, non l'azienda. Si parte da inventario, rischi e obiettivi, si separa la spesa corrente dai progetti e si pianificano le sostituzioni sulle date di fine supporto. La roadmap su tre anni si rivede ogni trimestre e si presenta alla direzione in termini di rischio e di costo del fermo.