Il debito tecnico entra nel bilancio: perché CIO e CFO devono misurarlo

Nelle grandi organizzazioni il patrimonio tecnologico viene ancora trattato, nei fatti, come un asset fisso: si svaluta linearmente, si ammortizza secondo piani pluriennali, si sostituisce quando “conviene”. È un modello contabile pulito. Il problema è che non descrive quello che succede davvero nei sistemi informativi.

L’accumulo di codice obsoleto, architetture rigide e integrazioni frammentate costituisce una vera e propria passività finanziaria fuori bilancio, i cui effetti incidono direttamente sul conto economico e sulla capacità competitiva dell’impresa.

Riconoscere il debito tecnico come voce strategica richiede un cambio di paradigma contabile e manageriale: dal tradizionale modello basato su interventi straordinari in conto capitale (CAPEX) a una logica di ottimizzazione continua sostenuta da spese operative (OPEX) e da metriche di bilancio condivise tra CEO, CFO e CIO.

Un ritardo strutturale, non una svista di manutenzione

In Italia, l’Osservatorio Cloud Ecosystem & Sovereignty del Politecnico di Milano stima che il 39% del portafoglio applicativo delle grandi aziende richieda un intervento di modernizzazione.

Il dato va letto considerando che il campione comprende in larga parte imprese trend-setter nell’adozione del cloud. Non consente quindi di quantificare direttamente la situazione dell’intero tessuto industriale italiano, ma suggerisce che il fabbisogno di modernizzazione potrebbe essere ancora più esteso nelle organizzazioni meno mature sul cloud e dotate di stack applicativi mediamente più datati.

Il debito tecnico nasce quando, per rispettare scadenze o privilegiare nuove funzionalità, l’organizzazione rinvia interventi necessari su codice, architetture, dati, integrazioni e sicurezza.

Il modello di Kano, elaborato negli anni Ottanta da Noriaki Kano per classificare le caratteristiche di prodotto in base al loro effetto sulla soddisfazione del cliente, aiuta a spiegare questo comportamento: ciò che genera valore visibile riceve attenzione, mentre ciò che deve semplicemente funzionare tende a essere dato per scontato.

Applicato ai sistemi informativi, il modello mostra perché il business privilegi funzionalità e risultati visibili, mentre tende a sottovalutare le caratteristiche “must be”: architettura, infrastrutture, qualità del codice, manutenibilità, integrazioni, dati, sicurezza e capacità evolutiva.

Questi elementi raramente producono benefici immediatamente percepibili, ma la loro assenza emerge con forza quando rallenta il cambiamento o aumenta il rischio operativo.

Così le scorciatoie si accumulano: una soluzione tattica consente di rispettare una scadenza, poi ne serve un’altra, e progressivamente, ogni cambiamento richiede più tempo, più risorse e comporta più rischio. Finché ciò che sembrava un problema tecnico diventa un vincolo alla capacità dell’impresa di evolvere.

Quando il debito tecnico influenza il time to market, la resilienza, la sicurezza, i costi operativi e la capacità di adottare nuove tecnologie, oggi soprattutto l’AI, il tema non può più essere considerato una questione di esclusiva competenza del CIO: diventa un tema di governance dell’impresa. Anche CEO, CFO e il board devono essere coinvolti, ma questi necessitano di strumenti adeguati a comprenderlo, monitorarlo e includerlo nella valutazione dei rischi strategici e della capacità di trasformazione dell’azienda.

La domanda fondamentale, inoltre, dovrebbe andare oltre l’intuitivo: “Quanto ci costa eliminare il debito tecnico?”. Dovrebbe essere: “Quanto valore futuro stiamo rinunciando a generare perché continuiamo ad accumularlo?”

Capitale e interessi: la lettura finanziaria del debito tecnico

Questo ritardo non nasce da negligenza operativa, ma da un modello di finanziamento non più adeguato alla natura del problema.

Il patrimonio tecnologico viene storicamente trattato dai modelli contabili standard come un asset immobilizzato, soggetto a svalutazione lineare. Tale rappresentazione presuppone che un software mantenga intatta la propria utilità marginale fino alla scadenza del ciclo ammortizzabile.

Tuttavia, la realtà dei sistemi informativi aziendali evidenzia dinamiche opposte: il software non si usura meccanicamente, ma subisce un decadimento strutturale dovuto all’evoluzione del contesto operativo, normativo e di mercato. Inoltre, l’accumulo progressivo di ritardi di manutenzione per rispettare scadenze di breve termine crea un debito latente che non viene rilevato nei prospetti contabili tradizionali.

Molte imprese affrontano la modernizzazione per episodi: accumulano debito tecnico per anni e stanziano un budget straordinario in conto capitale, il classico rip-and-replace, soltanto quando il sistema esistente diventa insostenibile. Questa logica concentra costi e rischi nel momento peggiore. La difficoltà di ottenere lo stanziamento, inoltre, prolunga il ricorso a soluzioni tattiche e aggrava progressivamente l’impatto operativo fino a rendere inevitabile l’intervento.

Per capire perché l’approccio “CAPEX straordinario” fallisca sistematicamente e favorire una convergenza decisionale tra il CIO e la direzione finanziaria (CEO/CFO), conviene tradurre il debito tecnico nel linguaggio del Conto Economico (Profit & Loss) e dello Stato Patrimoniale.

Lo studio di McKinsey Digital

Questa lettura è proposta nell’articolo “Tech debt: Reclaiming tech equity”, pubblicato da McKinsey Digital nell’ottobre 2020. L’articolo presenta i risultati di una survey condotta nel luglio 2020 su 50 CIO di aziende dei settori financial services e technology con ricavi superiori al miliardo di dollari.

Il debito tecnico, secondo questo studio, si comporta come una passività finanziaria vera e propria, con due componenti distinte:

1. Il capitale. Il capitale rappresenta l’ammontare complessivo degli investimenti tecnologici necessari per riportare lo stack applicativo corrente a uno stato di efficienza, sicurezza e allineamento architetturale. Comprende il differimento degli aggiornamenti di versione, la presenza di personalizzazioni proprietarie che bloccano l’applicazione delle patch dei vendor e l’inadeguatezza del codice rispetto ai parametri di cybersecurity. Le rilevazioni quantitative quantificano il capitale del debito tecnico tra il 20% e il 40% del valore totale dell’intero patrimonio tecnologico aziendale prima degli ammortamenti. Per un’azienda con bilanci IT di centinaia di milioni di euro, questo valore corrisponde a passività invisibili nell’ordine di decine di milioni di euro.
2. Gli interessi. Gli interessi costituiscono la tassa sulla complessità sostenuta quotidianamente dall’organizzazione. Si manifestano nella riduzione della velocità di sviluppo, nella proliferazione di integrazioni punto-punto e nell’instabilità dei processi operativi. McKinsey stima che tra il 10% e il 20% dei budget destinati alla creazione di nuovi prodotti o alla digitalizzazione venga prosciugato per risolvere criticità derivanti dal debito preesistente. Nelle organizzazioni con elevata stratificazione legacy, la quota di tempo impiegata dai team d’ingegneria per la mera gestione delle emergenze e della manutenzione ordinaria può raggiungere il 75%, riducendo al 25% la capacità produttiva destinata all’innovazione a valore aggiunto.

Lo stesso studio riporta un dato che vale la pena evidenziare: il 60% dei CIO intervistati percepiva il proprio debito tecnico in crescita negli ultimi tre anni, nonostante gli investimenti correnti in modernizzazione. È la controprova che gestire il debito debba essere un processo continuo, non un progetto: se il debito cresce mentre si continua a investire “come sempre”, significa che il modello di investimento – non la sua entità – è il problema.

Dal “grande evento” alla “modernizzazione continua”

La soluzione sostenibile per interrompere la stratificazione del debito tecnico risiede nella transizione verso un modello operativo di “modernizzazione continua“. Tale approccio supera l’idea della ristrutturazione come evento eccezionale, convertendo la manutenzione evolutiva dell’architettura in un processo permanente integrato nell’operatività aziendale ordinaria.

Le aziende a elevata maturità digitale possono riservare stabilmente una quota del budget IT ordinario alla bonifica sistematica del debito tecnico. Una forchetta del 10%-15% rappresenta un possibile riferimento operativo, da calibrare in funzione della criticità del portafoglio, del livello di debito rilevato e degli obiettivi di trasformazione.

Questo modello rende più prevedibile la spesa per la modernizzazione, riduce la dipendenza da grandi interventi straordinari e permette al CFO di valutare gli interventi in base al loro impatto sull’efficienza produttiva, sulla riduzione del rischio e sull’accelerazione del time-to-market.

I benefici non sono solo tecnici:

• i sistemi restano costantemente allineati agli standard di sicurezza e alle esigenze del business, invece di accumulare rischio fino al prossimo intervento straordinario;
• il conto economico si stabilizza: i picchi CAPEX diventano un flusso OPEX prevedibile, più facile da pianificare e da giustificare in sede di board;
• i team di ingegneria vengono liberati dalla gestione perenne delle emergenze, e possono spostare capacità dalla “tassa legacy” all’innovazione — lo stesso spostamento dal 75% al 25% descritto sopra.

Una domanda di governance, non di tecnologia

Il punto centrale non è tecnico, è di governance. Finché il debito tecnico resta un dato interno all’IT – non misurato, non tradotto in P&L, non discusso in board con la stessa disciplina riservata a un covenant finanziario – continuerà a essere gestito per emergenze, con tutti i costi (di capitale e di interessi) che questo comporta.

La domanda che vale la pena portare al proprio comitato esecutivo non è “quanto ci costa modernizzare i sistemi”, ma “quanto ci sta già costando non averlo fatto in modo continuativo” – e chi, in azienda, ha oggi la responsabilità di saperlo con precisione.

Per trasformare la gestione del debito tecnico in una leva strategica, l’organizzazione deve definire un modello di governance condiviso ai vertici aziendali. La responsabilità non può ricadere esclusivamente sulla struttura IT: CEO, CFO e CIO devono concorrere alla definizione delle priorità, dei criteri di allocazione del capitale e delle soglie di rischio, attraverso un presidio coerente con la struttura di governo dell’impresa.

I pilastri per l’attuazione del framework comprendono:

• Inclusione del debito tecnico nel risk management aziendale. Il debito tecnico dovrebbe essere quantificato e inserito nella mappa dei rischi aziendali valutata dal Consiglio di Amministrazione. Un accumulo importante di debito tecnico dovrebbe essere trattato alla stregua di un’esposizione finanziaria non garantita, i cui impatti possono paralizzare piani di fusione, acquisizione (M&A) o diversificazione di business.
• Formalizzazione dei criteri di allocazione del budget. Il budget IT dovrebbe prevedere una quota vincolata per la rifattorizzazione dell’architettura sottostante. Se un progetto non include la copertura finanziaria necessaria per pagare il debito residuo delle componenti toccate dall’intervento, esso genera un costo occulto per l’organizzazione.
• Istituzione di comitati di architettura. È opportuna l’introduzione di comitati guidati dal CIO e dagli Enterprise Architect con potere di veto sui progetti che introducono integrazioni punto-punto, violano il modello dati aziendale o comportano l’adozione di prodotti software non allo stato dell’arte tecnologica. Questo presidio garantisce che il bilancio tecnologico dell’azienda mantenga nel tempo un rapporto coerente tra valore degli asset ed efficienza operativa.

Trattare il debito tecnico come una questione puramente informatica costituisce un errore di natura contabile e strategica. Nelle grandi aziende italiane, dove l’esigenza di modernizzare i portafogli applicativi coesiste con stringenti vincoli normativi ed operativi, la permanenza di modelli di finanziamento basati unicamente su progetti straordinari in conto capitale rischia di erodere progressivamente i margini operativi.

Il superamento di questa spirale inefficiente richiede una decisione di vertice: formalizzare la passività tecnologica, abbandonare la scorciatoia del lift-and-shift non pianificato ed erogare finanziamenti continui dedicati alla revisione architetturale dei sistemi e delle applicazioni.

Questa impostazione consente a CIO e CFO di liberare progressivamente risorse finanziarie e umane, ridurre la tassa sulla complessità legacy e riallocare capacità verso innovazione e crescita. Ma perché il principio possa orientare decisioni di investimento, la diagnosi qualitativa non basta: il debito tecnico deve diventare una grandezza misurabile, confrontabile e associata a soglie decisionali. Parlare di “debito tecnico” in astratto non può infatti essere sufficiente ad un CIO che deve ottenere l’approvazione del budget.

Finché il debito tecnico rimane una metafora, il CFO non può governarlo. Il passo successivo è trasformarlo in una misura sufficientemente robusta da orientare l’allocazione del capitale. Ne parleremo nel prossimo articolo.