Negli ultimi anni le imprese hanno continuato a investire in trasformazione digitale. Cloud, cybersecurity, modernizzazione applicativa, piattaforme dati, intelligenza artificiale: difficilmente il problema è stato la mancanza di iniziative. I budget destinati all’innovazione sono cresciuti e, nella maggior parte delle organizzazioni, le roadmap tecnologiche sono diventate sempre più ricche di progetti.
Eppure molti programmi di trasformazione continuano a rallentare, ad accumulare ritardi o a produrre risultati inferiori alle aspettative. Alcune migrazioni vengono rinviate per anni, i sistemi legacy rimangono operativi ben oltre il loro ciclo di vita, le architetture “temporanee” diventano permanenti e numerosi progetti pilota non arrivano mai alla fase di industrializzazione.
Quando questo accade, la spiegazione viene spesso ricercata nella scarsità di risorse economiche, nella complessità tecnologica o nella resistenza al cambiamento. Sono certamente fattori rilevanti, ma non sempre rappresentano la causa principale.
In molte organizzazioni il vero collo di bottiglia è meno evidente: non riguarda la capacità di sviluppare nuove soluzioni, bensì quella di assumere decisioni nei tempi necessari. Il problema, in altre parole, non è soltanto fare innovazione, ma decidere quando, come e soprattutto quando smettere di rimandare.
Da questa osservazione nasce una riflessione che merita di essere approfondita. Accanto al debito tecnico, concetto ormai consolidato nella cultura dell’Information Technology, esiste una forma di debito molto meno visibile ma potenzialmente altrettanto impattante: il debito decisionale.
Dal debito tecnico al debito decisionale
Il concetto di debito tecnico, introdotto nei primi anni Novanta da Ward Cunningham, descrive il costo futuro derivante dall’adozione consapevole di soluzioni progettuali meno ottimali per soddisfare esigenze immediate. È una metafora ormai entrata stabilmente nel lessico dell’IT: ogni scorciatoia tecnologica può generare un interesse da pagare nel tempo sotto forma di maggiori costi di manutenzione, minore flessibilità o maggiore complessità evolutiva.
Il debito decisionale nasce invece da un meccanismo diverso. Non deriva da una scelta progettuale, ma dall’assenza di una scelta definitiva.
Si accumula quando decisioni importanti vengono sistematicamente rinviate, lasciate in sospeso o affidate implicitamente al futuro senza definire chi dovrà assumerle, entro quale orizzonte temporale e sulla base di quali condizioni dovranno essere riesaminate.
Nella pratica quotidiana assume forme estremamente familiari.
“Per il momento manteniamo l’attuale piattaforma.”
“Ne riparleremo dopo il go-live.”
“Aspettiamo di capire come evolve il mercato.”
“Quest’anno concentriamoci su altre priorità.”
Considerate singolarmente, queste affermazioni possono rappresentare decisioni pienamente razionali. In alcuni contesti attendere è la scelta migliore: riduce l’incertezza, evita investimenti prematuri e consente di raccogliere maggiori informazioni.
Il rischio emerge quando il rinvio perde le caratteristiche di una decisione governata. Una decisione differita dovrebbe sempre conservare quattro elementi fondamentali: una motivazione esplicita, un responsabile, una data di riesame e criteri oggettivi che consentano di riaprirla.
Quando questi elementi scompaiono, il rinvio smette di essere una scelta tattica e diventa una condizione permanente. È in quel momento che inizia ad accumularsi il debito decisionale.
Il debito tecnico nasce dalle decisioni che abbiamo preso. Il debito decisionale nasce da quelle che continuiamo a rinviare.
Anche una non-decisione, infatti, produce conseguenze. La differenza è che raramente compare in un business case, in un registro dei rischi o in un piano di progetto. Rimane invisibile fino a quando gli effetti iniziano a manifestarsi sotto forma di maggiore complessità, minore agilità e progressiva riduzione delle alternative disponibili.
Quando il debito decisionale rende permanente il provvisorio
Pochi sistemi informativi nascono già “legacy”. Più spesso lo diventano nel tempo.
È raro che un CIO o un comitato di direzione deliberino esplicitamente di mantenere per dieci o quindici anni un’applicazione ormai superata. Nella maggior parte dei casi il percorso è molto diverso: il sistema viene mantenuto “ancora per un anno”, in attesa di completare un altro progetto, di liberare risorse o di chiarire le priorità strategiche.
Quello che inizialmente rappresenta un rinvio limitato finisce però per ripetersi. Cambiano il management, il contesto competitivo, i fornitori, le tecnologie disponibili, ma la decisione continua a essere posticipata.
Nel frattempo il sistema viene integrato con nuove applicazioni, riceve ulteriori personalizzazioni, diventa dipendente da processi sempre più numerosi e coinvolge un numero crescente di utenti. Il costo di una sua sostituzione aumenta progressivamente, fino a rendere il cambiamento percepito come troppo rischioso.
A quel punto la motivazione originaria del rinvio è spesso scomparsa. Rimane soltanto il vincolo. È così che il provvisorio diventa strutturale.
Legacy, cloud e architetture in divenire
Questo meccanismo non riguarda esclusivamente i sistemi legacy. È osservabile in numerosi ambiti della governance IT.
Una migrazione al cloud prevista nell’arco di due anni viene rinviata in attesa di condizioni considerate più favorevoli.
Nel frattempo vengono sviluppate nuove integrazioni con l’infrastruttura esistente, vengono acquistate ulteriori licenze on-premise e aumentano le personalizzazioni da migrare.
Quando il progetto viene finalmente riavviato, il contesto non è più quello originario. Il progetto non diventa più semplice: diventa semplicemente più complesso.
Lo stesso accade nei programmi di consolidamento applicativo. Organizzazioni cresciute attraverso acquisizioni continuano spesso a mantenere applicazioni differenti che svolgono le medesime funzioni. La razionalizzazione viene riconosciuta come necessaria, ma resta in sospeso perché ogni sistema presenta specificità, utenti da coinvolgere e processi da riallineare. Nel frattempo, le interdipendenze aumentano e la finestra di intervento si restringe.
Anche i progetti pilota seguono spesso questa dinamica. Un POC nasce con l’obiettivo di validare una tecnologia o un modello operativo. Dovrebbe concludersi con una decisione: industrializzare la soluzione oppure interromperla. In molte realtà, invece, il progetto continua ben oltre l’orizzonte iniziale, senza diventare un servizio pienamente governato né essere realmente dismesso. Rimane così in una sorta di limbo operativo, assorbe risorse, genera aspettative e aumenta la complessità complessiva del portafoglio applicativo.
C’è poi una quarta situazione particolarmente frequente: le architetture ibride nate come soluzione temporanea. L’integrazione tra sistemi cloud e on-premise rappresenta spesso una fase fisiologica della trasformazione digitale. Diventa però critica quando l’architettura di transizione perde la propria natura provvisoria e si trasforma nel modello definitivo, senza che qualcuno abbia assunto formalmente questa decisione.
Infine, una delle manifestazioni meno evidenti del debito decisionale riguarda il rinnovo automatico di contratti e licenze software. Ogni rinnovo appare economicamente sostenibile e organizzativamente conveniente. Tuttavia, anno dopo anno, il mantenimento dello status quo sostituisce progressivamente una reale valutazione delle alternative disponibili. La decisione iniziale non viene confermata: semplicemente non viene più rimessa in discussione.
Questi esempi hanno un elemento in comune. Nessuno di essi deriva necessariamente da una scelta errata. La criticità emerge quando una decisione temporanea perde il proprio orizzonte temporale e smette di essere oggetto di riesame.
In questo senso, il debito decisionale non coincide con il risultato di una cattiva decisione. Coincide con il progressivo accumularsi di decisioni mai realmente concluse.
Il costo economico del debito decisionale
Ogni organizzazione conosce il costo di un investimento. Più difficile è quantificare il costo di una decisione che non viene presa.
Proprio per questo il debito decisionale tende a rimanere invisibile. Non compare in un business case, non genera immediatamente un incidente operativo e raramente produce effetti tali da richiedere un’escalation. I suoi impatti emergono lentamente, distribuiti nel tempo e su aree differenti dell’organizzazione.
Una prima categoria riguarda i costi diretti. Continuare a mantenere applicazioni non più strategiche significa sostenere spese di manutenzione, rinnovi contrattuali, canoni di licenza, infrastrutture dedicate e competenze specialistiche che, in molti casi, potrebbero essere progressivamente riallocate verso soluzioni di maggiore valore.
Esistono poi costi operativi, spesso più significativi dei precedenti. Processi duplicati, riconciliazioni manuali, integrazioni ridondanti, eccezioni gestite al di fuori dei flussi standard e crescente dipendenza da conoscenze individuali rallentano l’operatività quotidiana e riducono la capacità di risposta dell’organizzazione.
Vi sono infine i costi di opportunità: probabilmente i più difficili da misurare, ma anche i più rilevanti. Ogni decisione rinviata può posticipare l’introduzione di nuovi servizi, limitare l’adozione di modelli operativi più efficienti, rallentare iniziative di innovazione o impedire la riallocazione di risorse verso attività a maggiore valore aggiunto. In altre parole, il costo non consiste soltanto in ciò che l’organizzazione continua a spendere, ma anche in ciò che rinuncia a realizzare.
Con il passare del tempo si verifica inoltre un effetto meno intuitivo ma particolarmente critico: la progressiva riduzione delle opzioni disponibili.
Ogni rinvio genera nuove dipendenze, nuove personalizzazioni, nuovi processi e nuovi stakeholder. Di conseguenza, le alternative percorribili diminuiscono. La decisione futura diventa più onerosa, più rischiosa e più difficile da condividere.
Si innesca così un meccanismo ricorrente: proprio perché la decisione è diventata più complessa, viene ulteriormente rinviata.
Il debito decisionale, quindi, non aumenta soltanto i costi. Riduce progressivamente la libertà di scelta dell’organizzazione.
Come rendere visibile il debito decisionale nella governance IT
Il primo passo per governare un problema è renderlo osservabile.
Il debito tecnico dispone ormai di strumenti consolidati: analisi del codice, indicatori di qualità, assessment architetturali, vulnerability management e Application Portfolio Assessment consentono di individuare molte delle criticità accumulate nel tempo.
Il debito decisionale, invece, rimane spesso privo di strumenti dedicati.
Le decisioni rinviate sono distribuite tra verbali di riunione, roadmap, backlog progettuali, documentazione incompleta o, più semplicemente, nella memoria delle persone che hanno seguito l’evoluzione dell’organizzazione. Quando queste persone cambiano ruolo o lasciano l’azienda, anche le motivazioni originarie tendono a scomparire.
Per questo motivo potrebbe essere utile introdurre un Registro del Debito Decisionale, non come un ulteriore adempimento burocratico, ma come uno strumento di governo da affiancare al portfolio applicativo, al registro dei rischi e alla roadmap tecnologica.
L’obiettivo non sarebbe censire ogni decisione rinviata, ma rendere esplicite quelle che possono produrre un impatto significativo sull’evoluzione dei sistemi informativi.
Per ciascun elemento dovrebbero essere almeno identificati:
- la decisione da assumere;
- le motivazioni del rinvio;
- il responsabile della decisione;
- i costi associati al mantenimento dello status quo;
- i rischi derivanti dal non decidere;
- le principali dipendenze coinvolte;
- la data prevista per il riesame;
- i criteri che consentiranno di assumere la decisione.
Più che un archivio storico, il registro dovrebbe diventare uno strumento periodico di governance. Serve a riportare all’attenzione del management quelle scelte che, con il passare del tempo, rischiano di trasformarsi in vincoli strutturali.
I segnali del debito decisionale che un CIO non deve ignorare
Il debito decisionale raramente si manifesta attraverso eventi improvvisi.
Nella maggior parte dei casi emerge da piccoli segnali ricorrenti che, osservati singolarmente, possono sembrare trascurabili.
Frasi come “È sempre stato fatto così”, “Nessuno ricorda perché sia stata presa questa decisione”, “Ne riparleremo il prossimo anno” oppure “Non è chiaro chi debba decidere” rappresentano spesso il sintomo di una governance che ha progressivamente perso il controllo di alcune scelte.
Proprio per questo, questi segnali possono essere trasformati in indicatori misurabili, utili a osservare non solo lo stato delle tecnologie, ma anche la qualità del processo con cui vengono governate.
Indicatori per misurare il processo decisionale
Tra gli indicatori più utili potrebbero rientrare:
- numero di Proof of Concept aperte da oltre dodici mesi;
- sistemi classificati come “temporanei” ancora operativi dopo alcuni anni;
- applicazioni duplicate che svolgono la stessa funzione;
- contratti e licenze rinnovati automaticamente senza una rivalutazione del loro valore;
- decisioni strategiche prive di un owner o di una data di riesame.
Più che misurare la qualità delle tecnologie, questi indicatori consentono di misurare la qualità del processo decisionale che governa il patrimonio informativo dell’organizzazione.
Intelligenza artificiale e nuovo debito decisionale
L’attuale accelerazione dell’intelligenza artificiale introduce una riflessione ulteriore.
Ogni settimana il mercato propone nuovi modelli, nuove piattaforme e nuovi strumenti destinati alla GenAI. Le opportunità di sperimentazione aumentano rapidamente e molte organizzazioni stanno avviando iniziative parallele su più fronti.
Questo rappresenta un’opportunità straordinaria, ma introduce anche un nuovo rischio.
Quando il numero delle alternative cresce più rapidamente della capacità decisionale dell’organizzazione, aumenta la probabilità di accumulare nuovo debito decisionale.
Proof of Concept che non evolvono in progetti industriali, sperimentazioni che rimangono isolate, piattaforme introdotte senza una strategia di consolidamento e casi d’uso che convivono senza una governance comune rischiano di moltiplicare la complessità anziché ridurla.
Paradossalmente, l’intelligenza artificiale potrebbe accelerare lo sviluppo delle soluzioni tecnologiche, mentre il vero collo di bottiglia resterebbe la capacità delle organizzazioni di decidere quali iniziative consolidare, quali interrompere e quali integrare nella propria strategia digitale.
In questo scenario il vantaggio competitivo non dipenderà soltanto dalla velocità con cui sarà possibile sperimentare nuove tecnologie, ma dalla capacità di trasformare rapidamente le sperimentazioni in decisioni.
Quali decisioni stanno invecchiando?
Il debito decisionale non sostituisce il concetto di debito tecnico. Lo completa.
Il primo riguarda le conseguenze delle scelte progettuali; il secondo nasce dall’assenza di una scelta definitiva.
Entrambi producono costi. Entrambi riducono la capacità evolutiva dei sistemi informativi. Ma mentre il debito tecnico è generalmente visibile e può essere analizzato con strumenti consolidati, il debito decisionale tende a rimanere nascosto fino a quando i suoi effetti diventano difficilmente reversibili.
Per questo motivo la governance IT non dovrebbe limitarsi a chiedersi quali tecnologie adottare o quali architetture progettare. Dovrebbe interrogarsi anche su quali decisioni stanno invecchiando.
Ogni organizzazione convive con scelte rinviate. Non tutte rappresentano un problema e, in molti casi, attendere è una decisione pienamente razionale. Il rischio nasce quando il rinvio perde il proprio carattere temporaneo e diventa la modalità ordinaria con cui vengono gestite questioni strategiche.
In un contesto in cui il cambiamento tecnologico accelera continuamente, la vera capacità distintiva delle organizzazioni potrebbe non essere quella di adottare più innovazione, ma quella di decidere con maggiore consapevolezza, nei tempi necessari e sulla base di criteri espliciti.
Perché, in fondo, ogni sistema legacy racconta una storia tecnica. Molti raccontano soprattutto una storia di decisioni rimandate. E sono proprio queste ultime, spesso invisibili, a rappresentare il debito più difficile da estinguere.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Roberto Zanna
Source link
