Quando la tecnologia esce dall'IT: progettare il Technology Operating Model come sistema di responsabilità

La tecnologia aziendale non coincide più con l'organizzazione IT. Piattaforme, automazioni, prodotti digitali, analytics e sistemi di AI entrano direttamente nei processi delle funzioni operative, commerciali e amministrative. Questo spostamento cambia il problema di governance: l'organizzazione deve continuare a presidiare rischio, architettura, sicurezza e valore anche quando la capacità tecnologica è distribuita fra funzioni diverse.

Gartner descrive questa trasformazione da tempo in termini di funzioni che finanziano e costruiscono tecnologia in autonomia. In un'indagine su oltre 2.800 "business technologist" — dipendenti che creano capacità tecnologiche o analitiche pur riportando fuori dall'IT — Gartner ha rilevato che il 74% degli acquisti tecnologici è finanziato almeno in parte da unità di business esterne all'IT, contro un 26% finanziato interamente dall'organizzazione IT. Nella stessa area di ricerca, Gartner rileva che circa la metà dei business technologist produce capacità utilizzate da persone al di fuori del proprio reparto o della propria funzione.

Il tema è più ampio dell'AI. Una direzione operations può acquistare una piattaforma per ottimizzare la manutenzione; il marketing può introdurre strumenti di personalizzazione; una funzione finanziaria può automatizzare parte dei controlli; un'amministrazione pubblica può affidare a un fornitore una piattaforma di interoperabilità. La tecnologia entra così nell'organizzazione attraverso molte porte, mentre responsabilità architetturali, cybersecurity, dati e procurement restano spesso organizzate secondo una struttura centralizzata.

Questo produce una tensione concreta. Centralizzare ogni scelta rallenta l'execution e rende l'IT un collo di bottiglia. Distribuire completamente le decisioni aumenta invece il rischio di duplicazioni, architetture incompatibili, accessi non governati e costi difficili da ricostruire.

Un Technology Operating Model maturo deve quindi rendere espliciti almeno quattro elementi: dove possono essere prese le decisioni tecnologiche, quali capacità restano comuni, quali standard sono vincolanti e chi risponde del risultato quando più funzioni contribuiscono alla stessa soluzione.

Nel trasporto pubblico il problema è facilmente visibile. Ticketing, AVM, sistemi di esercizio, manutenzione, CRM, app e piattaforme dati possono avere owner differenti. Un'esperienza passeggero apparentemente semplice attraversa invece numerosi sistemi e responsabilità. Se ogni progetto viene ottimizzato localmente, l'architettura complessiva diventa progressivamente più difficile da governare.

La stessa dinamica riguarda utility, industria, sanità e Pubblica Amministrazione. La questione non è stabilire se la tecnologia debba essere centralizzata o decentralizzata in assoluto. Serve distinguere le capacità che beneficiano dell'autonomia locale da quelle che richiedono una disciplina comune: identity, cybersecurity, data governance, integrazione, vendor management, observability e architettura sono esempi evidenti.

L'AI rende questo problema più urgente perché introduce componenti che cambiano nel tempo — modelli che vengono aggiornati, comportamenti che si spostano, dipendenze da fornitori che evolvono. Un modello operativo pensato per un sistema stabile, valutato una volta e poi lasciato invariato, fatica ad adattarsi a componenti che richiedono monitoraggio e revisione continui, non un'approvazione iniziale seguita da anni di silenzio.

Per il management ne deriva una conseguenza operativa. Un programma di trasformazione non dovrebbe limitarsi a definire il nuovo sistema o il nuovo processo. Dovrebbe specificare anche chi possiede la capacità dopo il go-live, quali decisioni può assumere autonomamente, quali controlli restano condivisi e come l'organizzazione modifica il modello quando cambiano tecnologia e priorità.

Il Technology Operating Model diventa quindi il punto in cui strategia digitale e organizzazione smettono di essere due esercizi separati. La capacità tecnologica può essere distribuita. La responsabilità sulla sua coerenza deve restare progettata.