“Ma quella volta avevi fatto così”.
È una frase che, prima o poi, arriva in quasi tutti i team. Di solito compare quando qualcuno chiede di rispettare un passaggio operativo che in un’altra occasione era stato saltato. Può riguardare l’apertura di un ticket, un’autorizzazione, un controllo prima del rilascio o il canale attraverso cui inoltrare una richiesta. L’obiezione sembra ragionevole: se quella volta è stato possibile lavorare diversamente, perché oggi non dovrebbe esserlo?
Il passaggio più insidioso avviene quando l’eccezione diventa la regola senza che nessuno lo abbia deciso davvero.
Le organizzazioni ricordano con grande precisione ciò che è stato permesso, ma molto meno chiaramente perché lo sia stato. Il comportamento viene separato dalle condizioni che lo avevano reso necessario e trasformato in un precedente. Da quel momento l’eccezione non viene più letta come risposta a una circostanza specifica: diventa la prova che il processo può essere aggirato.
Questo non significa che ogni deviazione sia sbagliata. Un servizio deve continuare a funzionare anche quando il processo ordinario non è applicabile, quando gli strumenti non sono disponibili o quando un incidente impone tempi incompatibili con il flusso abituale.
Difendere una procedura fino a bloccare il servizio non è maturità operativa. È rigidità.
Il problema nasce quando non sono chiare le condizioni che aprono e chiudono la modalità eccezionale. Se nessuno dichiara che cosa sta accadendo, chi può autorizzare la deroga, per quali attività vale e quando terminerà, il team non vede un processo alternativo. Vede soltanto una regola che, sotto pressione, smette di valere. E ciò che smette di valere una volta può essere messo in discussione ogni volta.
Il giorno in cui il sistema di ticketing smise di funzionare.
Ogni volta che mi sono trovato a gestire un team di service desk, una regola è rimasta ferma: a ogni richiesta di supporto doveva corrispondere una segnalazione nel sistema di ticketing.
Non per amore della burocrazia.
Il ticket serve ad assegnare una priorità, distribuire il lavoro, rendere visibile il backlog, ricostruire le attività svolte e proteggere il team dalle richieste che arrivano da ogni direzione.
Per questo chiedevamo agli utenti di aprire direttamente la segnalazione. Non erano spettatori esterni al processo, ma una delle sue parti. Una telefonata poteva aiutare a chiarire il problema; non poteva però sostituire il passaggio che rendeva la richiesta tracciabile.
Poi, un giorno, fu proprio il sistema di ticketing a non essere disponibile. Rimase completamente offline per qualche giorno e gli utenti non sapevano più come entrare in contatto con noi. Applicare la regola alla lettera avrebbe prodotto un risultato paradossale: per rispettare il processo di supporto avremmo dovuto smettere di fornire supporto.
Attivammo quindi una modalità operativa diversa. Le segnalazioni venivano raccolte tramite e-mail e telefono, valutate dal team e gestite senza attendere il ripristino dello strumento. Non avevamo deciso che il ticket non fosse più necessario. Avevamo riconosciuto un evento preciso — l’indisponibilità del sistema — e adottato temporaneamente canali compatibili con quella condizione.
Qualche tempo dopo arrivò l’osservazione prevedibile: «Però quella volta è bastata una telefonata per farti fare l’attività». Era vero, ma il ricordo era incompleto. La telefonata non aveva sostituito il processo ordinario perché qualcuno aveva insistito abbastanza o perché la richiesta sembrava importante. Era parte di un protocollo di emergenza attivato da una condizione oggettiva.
Tolta quella condizione, il precedente perdeva la propria validità.
Un’eccezione non equivale a lavorare senza processo.
Nel linguaggio quotidiano chiamiamo “eccezione” situazioni molto diverse. La prima è la deroga arbitraria: qualcuno salta un passaggio per comodità, pressione o posizione gerarchica. Un manager pretende la gestione immediata senza ticket, un collega contatta direttamente il tecnico che conosce, una modifica viene eseguita senza il controllo previsto. Non esiste un criterio condiviso; esiste soltanto qualcuno che riesce a ottenere un trattamento diverso.
La seconda situazione è un’eccezione operativa governata. Si verifica un evento riconoscibile che rende il flusso ordinario inapplicabile o rischioso: il ticketing è offline, un incidente critico richiede una risposta immediata, il normale autorizzatore non è raggiungibile oppure un picco straordinario di domanda impone una gestione temporanea delle priorità. Qui il processo non scompare. Cambia forma.
La differenza non dipende dal canale utilizzato o dal fatto che un passaggio venga rinviato. Dipende dall’esistenza di condizioni, responsabilità e controlli. Durante un’emergenza, per esempio, si può intervenire prima di completare tutta la registrazione, purché sia chiaro chi autorizza l’intervento, quali attività rientrano nella deroga e come verranno ricostruite a posteriori. La velocità non deve cancellare la memoria operativa.
Un processo maturo, quindi, non è quello che pretende di valere nello stesso modo in qualsiasi circostanza. È quello che contempla anche la propria temporanea inapplicabilità. Prevede una modalità alternativa capace di preservare ciò che conta davvero: priorità, responsabilità, tracciabilità, sicurezza e continuità del servizio.
Quando manca questa distinzione, ogni adattamento sembra dimostrare che la procedura fosse inutile. Quando invece l’eccezione è governata, il messaggio è opposto: il processo resta credibile proprio perché sa adattarsi senza perdere il controllo.
Le persone imparano soprattutto da ciò che vedono accettare.
Le procedure spiegano come l’organizzazione dichiara di voler lavorare. I comportamenti mostrano come si lavora davvero. Di fronte a una contraddizione, le persone tendono comprensibilmente a fidarsi della seconda fonte: osservano quali scorciatoie vengono tollerate, chi può saltare un passaggio, quali urgenze ottengono attenzione e che cosa viene premiato.
Per questo ogni eccezione produce anche un messaggio culturale. Se un responsabile chiede al team di gestire fuori processo la richiesta di un cliente importante senza chiarire il motivo e il perimetro, non sta autorizzando soltanto una singola attività. Sta insegnando che l’importanza percepita del richiedente può sostituire le regole.
Se poi lo stesso comportamento porta un risultato immediato e non genera conseguenze visibili, sarà ancora più facile ripeterlo.
Il rischio non è soltanto che aumentino le richieste dirette. Con il tempo diventa difficile distinguere ciò che è possibile da ciò che è consentito. Il favore diventa un’aspettativa, l’urgenza una scorciatoia, la scorciatoia una regola non scritta. Chi prova a ripristinare il processo appare improvvisamente rigido, perché deve contrastare una prassi che l’organizzazione stessa ha contribuito a creare.
È qui che «ma quella volta avevi fatto così» diventa più di un’obiezione. È la prova di un apprendimento avvenuto senza che ce ne accorgessimo.
La persona ha registrato il comportamento, non le condizioni che lo giustificavano.
Chi guida un team ha quindi una responsabilità aggiuntiva: non basta prendere la decisione corretta nell’emergenza. Occorre renderne leggibile la logica. Bisogna dire che si sta entrando in una modalità diversa, spiegare perché, indicare a chi si applica e ricordare che non costituisce un precedente generale.
Altrimenti il team colmerà i vuoti con la spiegazione più semplice: la regola vale soltanto finché nessuno ha abbastanza fretta, influenza o insistenza per farla saltare.
Governare l’eccezione significa darle un inizio e una fine.
Per evitare che una deroga diventi una nuova regola non serve progettare un manuale per ogni imprevisto. Servono poche domande, poste nel momento giusto.
Quale evento rende legittima la modalità alternativa?
Chi può dichiararla?
A quali servizi, clienti o attività si applica?
Come lavoriamo mentre è attiva?
Quali controlli minimi dobbiamo conservare?
Che cosa ci farà tornare alla normalità?
Come recupereremo le informazioni non registrate durante l’emergenza?
Nel caso del ticketing offline, le risposte possono essere molto concrete. L’attivazione coincide con l’indisponibilità verificata della piattaforma. Il service manager o il responsabile di turno dichiara l’emergenza. E-mail e telefono diventano canali temporaneamente autorizzati. Le richieste vengono annotate in un registro provvisorio con richiedente, orario, impatto, priorità e assegnatario. Dopo il ripristino, le attività vengono riconciliate nel sistema e si comunica il ritorno al canale ordinario.
Quest’ultimo passaggio è spesso il più trascurato. Le organizzazioni annunciano l’emergenza, ma raramente ne dichiarano la conclusione con la stessa chiarezza. Così i comportamenti adottati per due giorni continuano per settimane, non perché qualcuno abbia deciso di mantenerli, ma perché nessuno ha detto esplicitamente di interromperli.
Una breve revisione successiva permette inoltre di capire se l’eccezione ha funzionato, quali informazioni sono andate perse e se il protocollo debba essere migliorato. Il recupero non serve soltanto a sistemare i dati: ricuce il legame tra la modalità straordinaria e il sistema ordinario.
Un processo credibile non è quello che non ammette eccezioni. È quello che sa riconoscerle, governarle e chiuderle. La solidità non nasce dalla rigidità, ma dalla capacità di adattarsi senza rendere negoziabile ogni regola.
In questo modo, quando qualcuno dirà «ma quella volta avevi fatto così», la risposta non dovrà difendere un’incoerenza: potrà richiamare una condizione precisa, una decisione esplicita e un’eccezione che aveva già una fine.
