Quando si gestiscono contemporaneamente IT e Operations, si ha il privilegio, e la responsabilità, di vedere entrambi i lati. Si capisce come ragiona un sistema informativo e come ragiona una linea operativa. E si impara, con il tempo, che il vero disallineamento non sta nelle tecnologie, nelle strutture organizzative, o nella buona volontà delle persone. Sta nei meccanismi invisibili che regolano come si decide, come si lavora, come si anticipano i problemi. Sta in cinque segnali specifici che ho imparato a riconoscere e che, ogni volta che li ho identificati per tempo, mi hanno permesso di intervenire prima che diventassero un problema strutturale.
Li descrivo qui non come patologie rare, ma come fasi normali di una trasformazione: ostacoli che ogni organizzazione incontra nel percorso verso un allineamento vero tra IT e Operations. Riconoscerli è il primo passo per superarli.
Indice degli argomenti
Segnale 1 – I dati esistono, ma non guidano le decisioni
Dashboard ovunque. Report settimanali. KPI aggiornati in tempo reale. Quando si costruisce un sistema informativo moderno, la tentazione è di misurare tutto e la tentazione viene quasi sempre assecondаtа.
Eppure, in più di una fase del mio percorso ho dovuto fare i conti con una realtà scomoda: i dati c’erano, ma le decisioni operative continuavano ad arrivare in ritardo, o a essere prese sulla base di percezioni e abitudini consolidate. Non per negligenza. Perché IT aveva costruito gli strumenti, ma non aveva ancora lavorato con Operations per costruire il significato di quei dati il modo in cui dovevano entrare nei processi decisionali reali.
Il lavoro di allineamento, in questo caso, non è tecnico. È culturale: si tratta di costruire un linguaggio comune tra chi produce i dati e chi deve usarli per decidere. Quando questo lavoro viene fatto, i numeri smettono di essere report e diventano strumenti di azione.
Come si riconosce: le riunioni operative si aprono con dati e si chiudono con opinioni. Nessuno mette in discussione il numero, ma nessuno lo usa per decidere.
Segnale 2 – IT implementa, Operations si adatta
Ogni volta che ho avviato un progetto di implementazione tecnologica, ho imparato che la velocità con cui si rilascia un sistema non è la variabile che conta. Conta la velocità con cui le persone lo adottano davvero.
Nelle prime fasi di una trasformazione, il rischio è quasi sempre lo stesso: i sistemi arrivano “dall’alto”, i processi vengono forzati dentro le logiche della piattaforma, e Operations si adatta come può. Il risultato sono workaround non ufficiali, adozione bassa, inefficienze nascoste che non emergono nei report ma si sentono nell’operatività quotidiana.
La svolta arriva quando si inverte il processo: non si parte dalla tecnologia per adattare il processo, ma dal processo per scegliere e configurare la tecnologia. Questo richiede che IT e Operations lavorino insieme fin dal primo giorno di progetto e non solo dalla fase di rollout.
Come si riconosce: i sistemi vengono usati per rispettare l’obbligo formale di registrazione. Il lavoro vero avviene altrove, con strumenti informali che nessuno ha autorizzato ma tutti conoscono.
Segnale 3 – I problemi emergono sempre dopo
Uno degli obiettivi che mi sono posto in ogni contesto in cui ho lavorato è costruire un’organizzazione che anticipi i problemi invece di rincorrerli. Non è un obiettivo banale. Richiede che i flussi informativi tra IT e Operations siano davvero integrati, che chi legge i segnali nei sistemi sia in contatto costante con chi gestisce i processi operativi.
Nelle fasi in cui questo allineamento non era ancora consolidato, ho vissuto la modalità reattiva: si interviene quando qualcosa si è già rotto. L’escalation è la norma. Le riunioni di crisi sono più frequenti delle riunioni di pianificazione. Non perché le persone non siano capaci ma perché i due mondi non hanno ancora costruito i ponti necessari per leggere insieme i segnali deboli.
Quando l’integrazione matura, il cambiamento è netto: si smette di spegnere incendi e si inizia a prevenirli. È uno dei risultati più concreti e più visibili di un allineamento ben costruito per il business.
Come si riconosce: i problemi vengono scoperti dai clienti o dalla linea operativa prima che IT ne sia a conoscenza. Il monitoring tecnico e il monitoraggio operativo non dialogano.
Segnale 4 – Ogni funzione ottimizza il proprio pezzo
Questo è forse il paradosso più insidioso, perché si nasconde dietro risultati positivi. L’ IT migliora i sistemi e i numeri di performance IT migliorano. Operations ottimizza i processi e gli indicatori operativi migliorano. Tutti lavorano bene, tutti mostrano progressi. Eppure la performance complessiva non si muove.
L’ho vissuto in prima persona: è il momento in cui ci si rende conto che ottimizzare i singoli pezzi non basta. Che la somma delle efficienze locali non produce un’efficienza globale. Che serve qualcuno, e quel qualcuno deve avere sia la visione che l’autorità, che guardi l’impatto complessivo del sistema, non i singoli indicatori.
Avere la responsabilità di entrambe le funzioni mi ha dato il vantaggio di poter fare questa domanda senza mediazioni: “Stiamo migliorando il sistema, o stiamo spostando il problema da una parte all’altra?” È una domanda scomoda. È anche l’unica che porta a risposte utili.
Come si riconosce: ogni funzione ha i propri KPI, e nessuno di questi indica chiaramente il valore generato per il cliente finale o per il business nel suo complesso.
Segnale 5 – Le decisioni attraversano troppi livelli
Nelle fasi iniziali di ogni percorso di integrazione, ho osservato una costante: il tempo che intercorre tra l’identificazione di un’opportunità e la prima azione concreta è sempre troppo lungo. Non per burocrazia, non per mancanza di volontà. Perché ogni decisione deve essere tradotta, mediata e rinegoziata tra i due mondi prima di poter procedere.
IT e Operations, quando non condividono linguaggio e criteri di valutazione, trasformano ogni scelta in un processo di allineamento infinito. I progetti vengono approvati in linea di principio e poi rimangono bloccati nell’esecuzione senza un motivo tecnico chiaro. La frustrazione si accumula su entrambi i lati.
La soluzione che ho trovato più efficace non è semplificare i processi decisionali per decreto. È costruire la fiducia reciproca e un vocabolario comune che permettano ai due team di decidere insieme, velocemente, senza dover risalire ogni volta alla catena di comando.
Come si riconosce: ogni progetto richiede allineamenti infiniti prima di partire. La velocità di esecuzione non rispecchia la qualità delle persone coinvolte.
Non è un tema tecnico. È un tema di leadership.
Costruire l’allineamento tra IT e Operations è un percorso, non un progetto con una data di fine. Ho attraversato tutte e cinque le fasi descritte in questo articolo, in contesti diversi e con gradi di complessità diversi. Ognuna mi ha insegnato qualcosa.
La cosa che ho imparato con più chiarezza nel tempo è questa: quando IT e Operations sono davvero allineati, le decisioni accelerano, i processi si semplificano e la tecnologia smette di essere un costo per diventare un generatore di valore reale. Non perché siano stati introdotti nuovi sistemi. Perché le persone hanno iniziato a lavorare verso lo stesso obiettivo, con gli stessi strumenti concettuali.
Questo non si ottiene con la tecnologia. Si ottiene creando le condizioni organizzative perché i due mondi si incontrino, si capiscano e si muovano nella stessa direzione. È il lavoro più difficile. Ed è anche quello che fa la differenza.
