I silos organizzativi sono uno dei nemici più sottovalutati nella gestione dei servizi.
Non fanno rumore. Non si presentano sempre come conflitti espliciti. Non bloccano necessariamente un’attività da un giorno all’altro. Spesso si manifestano in modo più sottile: un’informazione che non circola, un cambiamento non comunicato, una decisione presa dentro un gruppo senza coinvolgere chi dovrà subirne gli effetti, un documento aggiornato da una parte ma non conosciuto dalle altre.
All’inizio sembrano piccoli problemi di coordinamento.
Poi, lentamente, diventano rallentamenti, incomprensioni, rilavorazioni, errori, tensioni tra team e perdita di fiducia da parte degli utenti.
Il punto è che i silos organizzativi non danneggiano solo il modo in cui le persone lavorano internamente. Danneggiano il valore del servizio.
Perché un servizio non viene mai creato da un solo gruppo.
Anche quando agli occhi dell’utente appare come qualcosa di semplice, dietro quel risultato ci sono processi, strumenti, persone, responsabilità, fornitori, decisioni tecniche, comunicazioni e passaggi operativi che devono funzionare insieme.
Quando queste parti collaborano, il servizio scorre.
Quando invece restano chiuse dentro confini rigidi, il servizio inizia a perdere coerenza.
Ed è lì che il valore si rompe.
Il servizio non vive dentro un solo reparto.
Uno degli errori più comuni nelle organizzazioni è pensare che ogni team possa gestire il proprio pezzo di servizio in modo autonomo, senza preoccuparsi troppo degli altri.
Il team di sviluppo guarda il codice.
Il service desk guarda le segnalazioni.
Il gruppo funzionale guarda i requisiti.
Il reparto commerciale guarda il cliente.
Il management guarda i risultati.
L’utente, però, guarda una cosa sola: il servizio.
Non gli interessa sapere quale gruppo abbia generato l’errore. Non gli interessa capire se il problema nasce da una modifica tecnica, da una comunicazione mancata, da un requisito non condiviso o da una procedura aggiornata male.
Dal suo punto di vista, il servizio non funziona.
E quando il servizio non funziona, la distinzione interna tra team ha pochissimo valore.
È lo stesso principio richiamato anche da McKinsey: i clienti si aspettano che un’organizzazione si presenti come un’unica realtà, anche quando internamente il servizio è prodotto da funzioni diverse.
Questo è il motivo per cui lavorare in silos è così pericoloso. Ogni gruppo può anche essere efficiente nel proprio perimetro, ma se manca collaborazione tra le parti, il risultato complessivo può comunque essere pessimo.
Un team può aver fatto bene il proprio lavoro dal punto di vista tecnico, ma aver creato un problema operativo a qualcun altro. Un processo può essere stato migliorato localmente, ma aver generato un rallentamento altrove. Una modifica può essere corretta per chi l’ha progettata, ma incomprensibile per chi deve gestirne gli effetti sul cliente.
Il valore del servizio non nasce dalla somma di parti isolate.
Nasce dal modo in cui quelle parti riescono a lavorare insieme.
Un esempio concreto riguarda proprio il diverso focus dei team all’interno di un’organizzazione.
Team diversi possono avere obiettivi, scadenze e priorità differenti. Questo è normale. Il problema nasce quando ogni gruppo guarda solo il proprio risultato e perde di vista l’obiettivo principale dell’intera organizzazione: produrre valore per gli utenti.
Qualche settimana fa mi sono trovato a gestire una situazione nata proprio da questa dinamica.
Alcuni colleghi avevano apportato una modifica all’infrastruttura di rete una sera di venerdì, senza comunicarlo agli altri team coinvolti. Dal loro punto di vista, l’obiettivo era chiaro: ridurre alcuni costi infrastrutturali. La modifica, secondo la loro valutazione, non avrebbe dovuto creare disservizi.
Il giorno dopo, però, la produzione non funzionava.
Il problema è rimasto aperto per tutto il weekend, fino al lunedì mattina, quando i team sono tornati operativi. A quel punto ci è servita quasi un’intera mattinata per capire che una parte dell’infrastruttura era cambiata, anche perché quel livello non era direttamente visibile dal nostro perimetro di gestione.
La giustificazione è stata semplice: l’obiettivo del team era diminuire i costi di infrastruttura, quindi era stata fatta un’azione coerente con quella priorità.
Il problema è che, nel frattempo, i clienti non avevano potuto lavorare per quasi due giorni.
Questo è il punto critico dei silos organizzativi: ogni team può avere una motivazione legittima, ma se manca coordinamento il servizio complessivo può peggiorare. In quel caso, una condivisione preventiva avrebbe portato benefici molto concreti: evitare una modifica di venerdì sera, verificare la copertura del supporto nel weekend, pianificare dei test, avvisare i team coinvolti e predisporre un piano di rollback.
Non serviva bloccare il cambiamento.
Serviva governarlo.
Quando un cambiamento non comunicato diventa un problema per tutti.
Uno degli esempi più chiari di silos organizzativi riguarda i cambiamenti non condivisi.
Un team modifica un processo, aggiorna una funzionalità, cambia un requisito di input, introduce una nuova regola o rilascia una nuova versione di un componente. Dal suo punto di vista, l’attività è conclusa. Il cambiamento è stato fatto, il proprio obiettivo è stato raggiunto.
Il problema nasce quando quel cambiamento ha effetti su altri gruppi che non sono stati informati.
Ricordo un’esperienza legata a un momento abbastanza significativo per uno dei servizi che gestisco.
Uno dei team che sviluppava un servizio, a cui il nostro si appoggiava, decise di modificare una funzionalità per renderla conforme a nuove normative di settore. Dopo un’analisi sul proprio perimetro tecnologico, il team valutò di modificare una chiamata API in modo che ricevesse in input un dato aggiuntivo e restituisse maggiori informazioni al richiedente.
Dal loro punto di vista, la modifica aveva una logica. Serviva ad adeguare il servizio, migliorarlo e renderlo più completo rispetto ai nuovi requisiti.
Il problema è che quella modifica venne rilasciata senza avvisare nessuno.
Dopo il rilascio in produzione, il servizio che gestivo iniziò a bloccarsi per un numero consistente di clienti. In prima battuta non riuscivamo a capire cosa fosse accaduto. Iniziammo a cercare la causa nel nostro codice, nell’infrastruttura, nei log, in qualche modifica recente che poteva esserci sfuggita.
Solo dopo diverse ore di analisi ci accorgemmo che a cambiare non era stato il nostro servizio, ma quello da cui dipendevamo.
Il team che aveva fatto la modifica aveva raggiunto il proprio obiettivo: adeguare il servizio alle nuove esigenze normative. Ma lo aveva fatto lavorando completamente isolato, senza preoccuparsi dell’ecosistema che ruotava intorno a quella funzionalità.
Ed è proprio qui che i silos organizzativi diventano pericolosi: un team può raggiungere il proprio obiettivo locale e, nello stesso momento, generare un disservizio rilevante per gli utenti finali.
Chi genera il cambiamento vede solo il proprio perimetro.
Chi subisce l’impatto lo scopre troppo tardi.
Chi riceve le segnalazioni dall’utente si trova a gestire le conseguenze.
Chi usa il servizio percepisce semplicemente un peggioramento.
In questi casi, il problema non è solo tecnico.
È organizzativo.
Perché non è mancata soltanto una comunicazione. È mancata la consapevolezza che un cambiamento locale può produrre effetti sistemici.
Nel service management, ogni modifica dovrebbe essere osservata anche attraverso una domanda molto semplice: “Chi altro deve sapere questa cosa prima che produca impatti?”
Questa domanda, da sola, eviterebbe molti problemi.
Collaborare non significa solo lavorare insieme.
Quando si parla di collaborazione, spesso si pensa alla disponibilità personale: essere gentili, rispondere ai colleghi, partecipare a una riunione, aiutare quando serve.
Tutto questo è importante, ma non basta.
Collaborare davvero significa rendere visibile ciò che si sta facendo, condividere le informazioni rilevanti, coinvolgere le persone giuste prima che sia troppo tardi e costruire decisioni che tengano conto degli impatti sul servizio complessivo.
La collaborazione non è un atteggiamento generico.
È una pratica operativa.
In concreto, collaborare vuol dire comunicare un cambiamento prima del rilascio, spiegare perché una modifica è necessaria e coinvolgere chi dovrà gestirne gli effetti.
Vuol dire anche aggiornare la documentazione, verificare se altri processi dipendono da ciò che stiamo cambiando e chiedere feedback a chi osserva il servizio da un punto di vista diverso dal nostro.
Questo vale per i team interni, ma anche per clienti, fornitori, partner e utenti.
Ogni stakeholder vede una parte diversa del servizio. Nessuno possiede da solo la visione completa. Per questo la collaborazione non serve solo a “essere allineati”, ma ad aumentare la qualità delle decisioni.
Un team tecnico può vedere vincoli che il cliente non conosce.
Il cliente può vedere esigenze che il team tecnico sottovaluta.
Il service desk può vedere segnali ricorrenti che non emergono nei tavoli di progettazione.
Il management può vedere priorità e vincoli che i gruppi operativi non hanno.
Il valore nasce quando queste prospettive iniziano a parlarsi.
Collaborare, quindi, non significa soltanto “tenersi informati”.
Significa creare le condizioni perché le informazioni rilevanti arrivino alle persone giuste prima che diventino problemi. Significa impedire che un cambiamento resti chiuso dentro il perimetro di chi lo ha prodotto. Significa riconoscere che ogni scelta locale può avere effetti sul servizio complessivo.
Da qui nasce un punto importante: i silos organizzativi non dipendono sempre dalla cattiva volontà delle persone. Molto spesso sono il risultato di come l’organizzazione è stata progettata.
I silos organizzativi nascono anche dalla struttura.
Sarebbe comodo pensare che i silos organizzativi dipendano solo da persone poco collaborative.
A volte è così.
Ci sono individui e team che difendono il proprio perimetro, comunicano poco, vedono gli altri come ostacoli e trattano ogni richiesta esterna come un’invasione.
Ma spesso i silos non nascono dalla cattiva volontà.
Nascono dalla struttura.
Processi progettati per soddisfare solo una parte dell’organizzazione.
Sistemi che non parlano tra loro.
Documentazione separata.
Obiettivi misurati a livello di singolo team.
Riunioni chiuse sempre agli stessi partecipanti.
Responsabilità poco chiare.
Canali di comunicazione informali e non tracciati.
In un contesto di questo tipo, anche persone disponibili possono finire per lavorare in modo isolato.
Se ogni team viene misurato solo sui propri obiettivi, tenderà a proteggere il proprio risultato. Se i processi non prevedono momenti di confronto, la collaborazione dipenderà dalla buona volontà dei singoli. Se le informazioni non sono accessibili, chi non le riceve resterà fuori.
Il problema, quindi, non si risolve dicendo semplicemente: “Dobbiamo collaborare di più”.
Questa frase, da sola, non cambia nulla.
Bisogna creare condizioni concrete perché la collaborazione diventi possibile.
Per rendere possibile la collaborazione servono processi che prevedano visibilità, strumenti condivisi, responsabilità chiare e momenti di confronto progettati bene.
Anche le metriche dovrebbero essere ripensate: non dovrebbero premiare solo il successo locale del singolo team, ma anche il contributo al valore complessivo del servizio.
Altrimenti il messaggio sarà sempre lo stesso: collaborate, ma continuate a essere misurati come se foste isole separate.
Il cliente non può restare fuori dalla collaborazione.
Quando si parla di stakeholder, spesso si pensa prima alle funzioni interne.
In realtà, uno degli stakeholder più importanti è il cliente.
Il cliente non deve essere coinvolto in ogni dettaglio tecnico, ovviamente. Non sempre ha tempo, competenze o interesse per partecipare a tutte le fasi di progettazione o miglioramento. Però escluderlo completamente dal processo decisionale è rischioso.
Perché il cliente porta una prospettiva che l’organizzazione non possiede fino in fondo: quella dell’utilizzo reale del servizio.
Può segnalare esigenze che internamente non vengono percepite. Può evidenziare frizioni che nei processi sembrano invisibili. Può raccontare aspettative, priorità e difficoltà che nessun documento tecnico riesce a rappresentare completamente.
Collaborare con il cliente non significa chiedergli di progettare il servizio al posto nostro.
Significa trovare il modo giusto per coinvolgerlo.
A volte può bastare una richiesta di feedback. In altri casi può servire un workshop, un gruppo di lavoro, una sessione di revisione, una validazione intermedia o un confronto sulle priorità.
Non tutti gli stakeholder devono essere coinvolti allo stesso livello. Alcuni possono partecipare attivamente alla progettazione, altri possono essere consultati in momenti specifici, altri ancora possono limitarsi ad approvare o validare.
Il punto non è coinvolgere tutti sempre.
Il punto è coinvolgere le persone giuste, nel momento giusto, con il livello di dettaglio giusto.
Senza questa attenzione, il rischio è costruire servizi formalmente corretti ma poco aderenti alle esigenze reali.
E quando questo accade, il valore percepito diminuisce.
La mentalità collaborativa non è buonismo.
Collaborare, però, non significa cercare di accontentare tutti.
Questo è un equivoco pericoloso.
Una mentalità collaborativa non nasce dal desiderio di evitare conflitti o di trovare sempre un compromesso comodo. Nasce dalla volontà di creare più valore per il servizio.
A volte collaborare significa ascoltare una prospettiva diversa dalla propria. Altre volte significa mettere in discussione abitudini consolidate. In alcuni casi significa accettare che il proprio modo di lavorare non sia più adeguato al contesto attuale.
Ed è qui che spesso emergono le resistenze.
“Abbiamo sempre fatto così.”
“Questa pratica non ci ha mai dato problemi.”
“Da trent’anni lavoriamo in questo modo.”
“Chi viene da un altro gruppo non può capire davvero il nostro lavoro.”
Frasi di questo tipo sembrano difendere l’esperienza. In realtà, spesso difendono l’immobilità.
L’esperienza è preziosa quando aiuta a leggere meglio la realtà. Diventa un ostacolo quando viene usata per chiudere ogni possibilità di cambiamento.
Una mentalità collaborativa parte da un principio diverso: nessun gruppo possiede da solo tutta la verità sul servizio.
Ogni team vede un pezzo. Ogni ruolo intercetta segnali diversi. Ogni stakeholder porta un punto di vista parziale ma utile.
Collaborare significa mettere insieme questi punti di vista senza trasformarli in una competizione continua.
Non è facile.
Richiede ascolto attivo, fiducia, apertura, capacità di negoziare e volontà di comprendere le esigenze degli altri. Richiede anche maturità, perché non tutte le idee possono essere accolte e non tutti i compromessi sono utili.
Il compromesso, infatti, non dovrebbe servire a rendere tutti temporaneamente soddisfatti. Dovrebbe servire a proteggere l’obiettivo principale: creare valore attraverso il servizio.
Rompere i silos significa proteggere il valore.
I silos organizzativi distruggono valore perché separano ciò che, nell’esperienza dell’utente, arriva come un unico servizio.
All’interno dell’organizzazione possono esistere reparti, competenze, processi e responsabilità diverse. È normale. In molti casi è necessario.
Rompere i silos non significa eliminare le specializzazioni.
Significa collegarle.
Significa creare visibilità, favorire il confronto, rendere accessibili le informazioni, costruire processi che permettano alle persone di vedere oltre il proprio perimetro.
Perché il valore di un servizio non nasce solo da ciò che ogni team fa singolarmente.
Nasce soprattutto da ciò che i team riescono a costruire insieme. E se questa collaborazione manca, prima o poi l’utente se ne accorge.
Magari non saprà mai quale reparto non ha comunicato con quale altro reparto. Non conoscerà il nome del sistema che non è stato aggiornato. Non saprà quale processo interno ha fallito.
Saprà soltanto che il servizio non ha funzionato come avrebbe dovuto.
Ed è proprio lì che i silos organizzativi smettono di essere un problema interno.
Diventano un problema di valore.
