Francesco ConsiglioExecutive Strategy Lab

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

La tecnologia è sempre più distribuita nelle funzioni aziendali, mentre rischio, architettura e accountability restano responsabilità comuni. Il Technology Operating Model deve governare questa distanza senza trasformare l'IT in un collo di bottiglia.

Francesco Consiglio

· 4 min

Centro operativo del trasporto pubblico in cui esercizio, manutenzione e assistenza coordinano una criticità ferroviaria
Indice dell'articolo
  1. 01La tecnologia non coincide più con l'IT
  2. 02Molte porte, una sola architettura da presidiare
  3. 03Il caso del trasporto pubblico
  4. 04Perché l'AI rende il problema più urgente
  5. 05Cosa deve specificare un programma di trasformazione
  6. 06Implicazioni manageriali
  7. 07Fonti

La tecnologia non coincide più con l'IT

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 anni. In un'indagine pubblicata nel marzo 2022 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. In una ricerca del 2021 sui «business technologist» — dipendenti che creano capacità tecnologiche o analitiche pur riportando fuori dall'IT — circa la metà produce capacità usate da persone fuori dal proprio reparto. Sono indagini di un analista, di alcuni anni fa e non specifiche del trasporto: danno l'ordine di grandezza del fenomeno, non lo misurano oggi.

Molte porte, una sola architettura da presidiare

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.

Matrice dei diritti decisionali su tre livelli, autonomia locale, piattaforma condivisa e controllo aziendale vincolante: Scelta dello strumento applicativo: autonomia locale; Modello di dati e API di integrazione: piattaforma condivisa; Identity e gestione degli accessi: controllo aziendale vincolante; Cybersecurity e gestione del rischio: controllo aziendale vincolante; Vendor management e procurement: piattaforma condivisa; Observability e architettura complessiva: controllo aziendale vincolante.
  1. Scelta dello strumento applicativo: autonomia locale
  2. Modello di dati e API di integrazione: piattaforma condivisa
  3. Identity e gestione degli accessi: controllo aziendale vincolante
  4. Cybersecurity e gestione del rischio: controllo aziendale vincolante
  5. Vendor management e procurement: piattaforma condivisa
  6. Observability e architettura complessiva: controllo aziendale vincolante
Configurazione esemplificativa: il punto segna dove ricade tipicamente il diritto decisionale, un criterio da rendere esplicito per ogni capacità, non una regola universale.Executive Strategy Lab — grafica editoriale

Il caso del trasporto pubblico

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.

Ipotizzo che la stessa dinamica riguardi 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.

Perché l'AI rende il problema più urgente

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.

Cosa deve specificare un programma di trasformazione

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.

Fatto, meccanismo e decisione. Fatto: In un'indagine Gartner del 2022, il 74% degli acquisti tecnologici è finanziato almeno in parte da unità di business esterne all'IT. Meccanismo: Quando la capacità è distribuita, rischio, architettura e accountability restano comuni: serve una divisione esplicita dei diritti decisionali. Decisione: Specificare chi possiede la capacità dopo il go-live, quali decisioni assume in autonomia, quali controlli restano condivisi e come il modello si aggiorna.
  1. Fatto: In un'indagine Gartner del 2022, il 74% degli acquisti tecnologici è finanziato almeno in parte da unità di business esterne all'IT.
  2. Meccanismo: Quando la capacità è distribuita, rischio, architettura e accountability restano comuni: serve una divisione esplicita dei diritti decisionali.
  3. Decisione: Specificare chi possiede la capacità dopo il go-live, quali decisioni assume in autonomia, quali controlli restano condivisi e come il modello si aggiorna.
Fatto documentato, lettura dell'autore e decisione manageriale, tenuti distinti. Sintesi editoriale, non parte della fonte.Executive Strategy Lab — grafica editoriale

Framework applicato

Decision Layer Framework

Il Decision Layer Framework aiuta a distinguere, dentro il Technology Operating Model, il livello a cui una decisione tecnologica deve essere presa da quello a cui deve solo essere eseguita — la stessa distinzione che rende un modello operativo governabile invece che solo descritto.

  1. 01System Layer
  2. 02Data Layer
  3. 03Governance Layer
  4. 04Decision Layer
Esplora Decision Layer Framework →

Implicazioni manageriali


Fonti

  • Gartner13 marzo 2022

    Comunicato stampa

  • Gartner21 settembre 2021

    Comunicato stampa

Dal Radar

  • Guida o standardAggiornato il

    ERP transformation: misurare l'adozione oltre il go-live

    Prosci distingue le metriche di attività del change management (formazione completata, comunicazioni inviate) da quelle che verificano se le persone usano davvero il nuovo sistema in autonomia dopo il go-live.

Tutto il Radar →

Analisi correlate

Nodo ferroviario europeo in cui treni di operatori diversi si connettono con tram e autobus
02Segnale strategicoDigital Transformation

Dalla consegna del sistema all'orchestrazione dell'ecosistema

Passenger Package, specifiche ferroviarie armonizzate ed eFTI mostrano la stessa direzione: il valore non è più contenuto in un solo sistema, ma nella capacità di più organizzazioni di scambiare dati, applicare standard e far funzionare processi condivisi.

· 4 min