Ci sono miglioramenti che falliscono molto prima di essere avviati.
Non falliscono quando il progetto rallenta, quando il team incontra resistenze o quando emergono vincoli tecnici, economici e organizzativi. Non falliscono nemmeno quando la prima soluzione scelta si rivela incompleta.
Falliscono ancora prima: nel momento in cui vengono pensati.
Succede quando un’organizzazione decide di migliorare un servizio partendo subito dalla soluzione, senza aver compreso abbastanza bene il punto di partenza. Succede quando si confonde il miglioramento continuo con una grande iniziativa di cambiamento. Succede quando si guarda ciò che non funziona e si conclude troppo rapidamente che l’unica strada sia rifare tutto da zero.
Un nuovo processo.
Un nuovo strumento.
Una nuova automazione.
Una nuova dashboard.
Una nuova procedura.
Un nuovo modello organizzativo.
Tutte possibilità legittime, certo. Ma non sempre necessarie. E soprattutto non sempre risolutive.
Nel service management, il miglioramento continuo non dovrebbe nascere dall’entusiasmo per ciò che si potrebbe costruire, ma dalla lucidità con cui si osserva ciò che esiste già.
La domanda più importante non è:
“Che cosa vogliamo introdurre?”
La domanda più importante è:
“Che cosa sta accadendo davvero nel servizio oggi?”
Sembra una domanda semplice, quasi banale. In realtà è una delle più difficili, perché costringe a guardare il servizio senza abbellimenti. Costringe a osservare processi incompleti, strumenti usati male, abitudini consolidate, dati poco chiari, ticket ricorrenti, feedback ignorati, canali aggirati e responsabilità distribuite in modo confuso.
Ma è proprio da lì che nasce il miglioramento continuo.
Non dalla versione ideale del servizio.
Dalla sua realtà quotidiana.
Il miglioramento continuo non parte dalla soluzione.
Uno degli errori più frequenti è pensare che il miglioramento inizi trovando l’idea giusta.
In realtà, il miglioramento continuo non parte dall’idea. Parte dalla comprensione.
Prima di decidere cosa cambiare, bisogna capire cosa non sta funzionando, perché non sta funzionando, per chi rappresenta un problema e quale impatto produce sul valore del servizio.
Senza questa fase, ogni miglioramento rischia di trasformarsi in una reazione.
Il sistema di ticketing è complicato? Cambiamolo.
Gli utenti aprono richieste incomplete? Aggiungiamo campi obbligatori.
Il team è saturo? Automatizziamo.
I tempi sono lunghi? Inseriamo una nuova procedura.
Le escalation aumentano? Creiamo un nuovo livello di controllo.
A volte queste risposte sono corrette. Ma diventano pericolose quando arrivano troppo presto.
Perché un servizio non è mai fatto da un solo elemento. È un intreccio di persone, processi, strumenti, dati, abitudini, aspettative, vincoli e comunicazioni. Se si interviene su un punto senza capire le relazioni con il resto, si rischia di spostare il problema invece di risolverlo.
Un esempio semplice: gli utenti aprono ticket incompleti.
La risposta immediata potrebbe essere aggiungere altri campi obbligatori. In questo modo il service desk riceverà più informazioni, almeno in teoria. Ma se il problema reale è che l’utente non capisce quale categoria scegliere, non sa quali dati servano o trova il portale troppo complesso, aggiungere campi obbligatori può peggiorare l’esperienza. L’utente farà più fatica, userà canali alternativi o compilerà i campi in modo casuale pur di andare avanti.
Il miglioramento, nato per aiutare il team, finisce così per aumentare l’attrito e peggiorare la situazione.
Ecco perché il miglioramento continuo richiede pazienza diagnostica.
Non basta individuare un sintomo. Bisogna comprenderlo.
Un ticket incompleto è davvero un problema di attenzione dell’utente? Oppure è un problema di linguaggio? Di interfaccia? Di formazione? Di processo? Di fiducia nel canale? Di categorie troppo tecniche? Di aspettative non chiarite?
Finché queste domande non vengono poste, il rischio è costruire soluzioni eleganti per problemi capiti male.
Partire dallo stato attuale non significa accontentarsi.
Nel miglioramento continuo, partire dallo stato attuale è fondamentale.
Ma questa espressione viene spesso fraintesa.
Partire dallo stato attuale non significa difendere ciò che esiste. Non significa rassegnarsi a processi inefficienti, strumenti superati o abitudini sbagliate. Non significa dire: “Abbiamo sempre fatto così, quindi continuiamo così”.
Significa una cosa diversa: riconoscere che ciò che esiste contiene informazioni preziose.
Anche un processo fragile racconta qualcosa, così come uno strumento usato male, un workaround, una procedura aggirata o un’abitudine informale.
A volte raccontano inefficienza. A volte raccontano adattamento. Altre volte mostrano che le persone hanno trovato un modo per far funzionare il servizio nonostante limiti, vincoli e mancanze organizzative.
Per questo buttare via tutto può essere una scelta rischiosa.
C’è una forte tentazione, quando qualcosa non funziona, di immaginare un nuovo inizio. Un processo completamente nuovo, uno strumento nuovo, una struttura nuova, una procedura riprogettata da zero.
Sulla carta è molto affascinante e spesso sembra la strada più semplice.
Nella realtà, però, ciò che esiste non è solo disordine. È anche memoria operativa. È esperienza accumulata. È conoscenza implicita. È un insieme di adattamenti che, pur con tutti i loro difetti, hanno permesso al servizio di reggere fino a quel momento.
Il miglioramento continuo non dovrebbe cancellare tutto indistintamente. Dovrebbe selezionare.
Cosa va eliminato?
Cosa va conservato?
Cosa va semplificato?
Cosa va potenziato?
Cosa va standardizzato?
Cosa può essere riutilizzato in modo migliore?
Una delle casistiche più diffuse in molte organizzazioni è l’entropia dei processi. Esiste uno stesso bisogno comune, che però viene gestito da team diversi con pratiche diverse. Quando si parla di miglioramento continuo e standardizzazione dei processi, la prima reazione potrebbe essere imporre un processo unico completamente nuovo. Ma una strada più intelligente è osservare i processi già esistenti, capire quali parti funzionano, quali non funzionano e costruire uno standard che recuperi i punti di forza invece di ignorarli.
Ma attenzione: migliorare non significa sempre aggiungere.
Spesso significa togliere, adattare, riordinare e rendere più leggibile ciò che già esiste.
Quando il miglioramento nasce da ciò che esiste già.
Mi è capitato di vedere questo principio in modo molto concreto qualche anno fa, lavorando su un processo di rilascio delle modifiche al servizio.
Diversi gruppi di lavoro avevano la stessa esigenza: tracciare e automatizzare il processo di rilascio. Il problema era che ognuno lo faceva a modo proprio. Alcuni gruppi avevano un processo manuale, altri semi-automatizzato, altri ancora utilizzavano strumenti e regole costruiti nel tempo per rispondere alle proprie necessità operative.
In un gruppo particolarmente numeroso, la situazione era ancora più frammentata: ogni sottogruppo aveva sviluppato le proprie modalità di gestione. Modalità che, in alcuni casi, entravano perfino in conflitto con quelle del resto del team, generando problemi frequenti in produzione.
La direzione finale era chiara: standardizzare il processo, renderlo tracciato e automatizzato.
Quell’obiettivo era necessario, perché serviva a capire dove volevamo arrivare. Ma non è stato il punto da cui siamo partiti per costruire il cambiamento.
La prima vera attività è stata un’altra: capire cosa esisteva già.
Abbiamo analizzato i processi adottati dai singoli gruppi di lavoro, le motivazioni dietro quelle modalità operative e le principali difficoltà che ciascun team stava affrontando. In quella fase è emersa una cosa molto interessante: gruppi diversi avevano problemi diversi, ma spesso quei problemi erano già stati risolti da altri team, magari in modo parziale, informale o non ancora standardizzato.
Questo ci ha permesso di identificare i punti di forza di ogni processo.
Alcuni passaggi funzionavano bene perché erano semplici. Altri perché garantivano maggiore controllo. Altri ancora perché riducevano il rischio di errori in produzione. Presi singolarmente erano soluzioni locali. Messi insieme, potevano diventare la base di un processo più solido per tutti.
Il lavoro vero, quindi, non è stato cancellare ciò che esisteva e imporre un modello nuovo dall’alto.
È stato selezionare.
Capire cosa mantenere, cosa semplificare, cosa potenziare e cosa trasformare. L’obiettivo non era creare un processo più complesso solo perché più strutturato. Al contrario, dovevamo costruire qualcosa di fluido e semplice da utilizzare. Gli utenti non dovevano percepire un ulteriore carico operativo, ma una semplificazione del lavoro quotidiano.
Quando il meccanismo di base è stato pronto, abbiamo iniziato a far utilizzare il nuovo strumento.
Le resistenze iniziali non sono mancate.
Ricordo ancora una riunione in cui, alla fine del confronto, una persona mi disse chiaramente che quel processo non lo avrebbero mai utilizzato. Non era una semplice obiezione tecnica. Era una chiusura netta, quasi una dichiarazione di incompatibilità tra il nuovo modello e il modo in cui il suo team lavorava.
In quel momento sarebbe stato facile leggere quella resistenza come opposizione al cambiamento.
In realtà, era un feedback.
Un feedback espresso male, forse. Molto diretto, sicuramente. Ma comunque un segnale da ascoltare.
Per questo organizzammo una sessione dedicata. Gli chiesi di elencarmi tutti i motivi per cui, secondo lui, quel processo era inutilizzabile per il suo team. Uno alla volta, li analizzammo. Alcuni erano fraintendimenti. Altri erano problemi reali. Altri ancora erano esigenze specifiche che non avevamo considerato abbastanza.
La parte più importante fu il modo in cui affrontammo quelle richieste.
Non adattammo il processo solo per accontentare un singolo gruppo. Ogni modifica venne valutata con una domanda precisa: questa esigenza può diventare un valore aggiunto anche per gli altri team?
Quando la risposta era sì, intervenivamo.
In questo modo il feedback non diventava un’eccezione locale, ma un’occasione per migliorare lo standard comune.
Alla fine, quella stessa persona che inizialmente aveva detto che non avrebbe mai usato il processo è diventata uno degli utilizzatori più assidui. Con il tempo, il nuovo modello è stato considerato fondamentale per le attività quotidiane del gruppo.
Questo risultato non è arrivato perché avevamo progettato un processo perfetto fin dall’inizio.
È arrivato perché siamo partiti da ciò che esisteva già: dai punti di forza, dalle difficoltà, dalle pratiche reali e dai feedback di chi avrebbe dovuto usare quello strumento ogni giorno.
Non abbiamo calato un processo dall’alto.
Lo abbiamo costruito progressivamente, partendo dal campo.
E proprio il confronto iniziale, insieme agli aggiustamenti periodici nei primi mesi, ha permesso al processo di adattarsi e diventare davvero un valore aggiunto. Non solo è stato accettato, ma è stato migliorato dagli stessi team con caratteristiche che, all’inizio, non avevamo nemmeno previsto.
Perché rifare tutto da zero è una tentazione pericolosa.
L’idea di rifare tutto da zero è una delle più seducenti nei percorsi di miglioramento.
Dà la sensazione di controllo, di pulizia e persino la percezione di poter eliminare finalmente tutte le complessità accumulate nel tempo.
Il problema è che i servizi non vivono in un laboratorio.
Vivono dentro organizzazioni reali, con persone reali, clienti reali, urgenze reali, vincoli reali e continuità operativa da garantire ogni giorno.
Un servizio non si ferma perché abbiamo deciso di migliorarlo.
I ticket continuano ad arrivare. Gli utenti continuano ad avere bisogno di supporto. I clienti continuano a chiedere risposte. I team continuano a gestire attività ordinarie, incident, scadenze, emergenze e priorità che cambiano.
Quando il miglioramento viene progettato come una rivoluzione troppo ampia, rischia di diventare un secondo lavoro che si aggiunge al lavoro quotidiano.
All’inizio c’è energia.
Poi arrivano i ritardi, le urgenze operative riprendono spazio, le riunioni iniziano a essere annullate e il nuovo modello resta a metà. Alla fine, le persone tornano alle vecchie abitudini.
Non perché siano contrarie al cambiamento. Spesso perché il cambiamento è stato pensato in modo troppo distante dalla loro capacità reale di assorbirlo.
Il miglioramento continuo, invece, ha bisogno di entrare nella quotidianità.
Un servizio migliora davvero quando il cambiamento diventa praticabile. Quando le persone capiscono cosa cambia, perché cambia e quale beneficio produce. Quando il nuovo modo di lavorare non resta confinato in una slide, ma diventa più semplice, più utile o più efficace del modo precedente.
Per questo il miglioramento continuo dovrebbe diffidare delle grandi trasformazioni non accompagnate da passaggi intermedi.
Una rivoluzione promette molto e spesso promette risultati rapidi, ma chiede tanto prima di restituire qualcosa.
Un miglioramento graduale, invece, può produrre fiducia più rapidamente. E la fiducia è uno degli ingredienti più importanti di qualsiasi cambiamento.
Feedback e dati: capire prima di cambiare.
Per partire dallo stato attuale non basta osservare da lontano.
Servono dati, feedback e segnali raccolti dal servizio mentre il servizio lavora.
I dati aiutano a capire cosa sta accadendo: volumi, tempi di risposta, tempi di risoluzione, ticket ricorrenti, riaperture, escalation, code, picchi, arretrati, categorie più frequenti.
I feedback aiutano a capire come tutto questo viene vissuto: frustrazione, confusione, soddisfazione, fiducia, percezione di lentezza, difficoltà nel trovare informazioni, senso di abbandono o mancanza di chiarezza.
Usare solo i dati è rischioso.
Usare solo le percezioni lo è altrettanto.
Un service desk può rispettare i tempi medi e avere utenti insoddisfatti. Può chiudere molti ticket ma non risolvere i problemi ricorrenti. Può avere indicatori positivi e produrre comunque un’esperienza percepita come fredda, frettolosa o poco chiara.
Allo stesso tempo, una singola lamentela molto forte non sempre rappresenta l’intera realtà. Un feedback negativo può essere prezioso, ma va interpretato. Una percezione va ascoltata, ma anche messa in relazione con altri segnali.
Il miglioramento continuo nasce dall’incrocio tra dati e osservazioni.
Se aumentano i ticket su una funzionalità e gli utenti segnalano difficoltà di utilizzo, probabilmente c’è un problema di esperienza. Se i tempi di risoluzione sono buoni ma aumentano le riaperture, forse le chiusure sono troppo rapide o le soluzioni poco definitive. Se diminuiscono i ticket ma aumentano richieste via email, chat o telefono, forse il canale ufficiale non è percepito come utile.
Il service desk, in questo senso, è una fonte preziosa.
Ogni richiesta può raccontare qualcosa dello stato del servizio. Ogni sollecito può segnalare un’aspettativa non gestita. Ogni lamentela può indicare una frizione. Ogni ticket ricorrente può rivelare un problema che merita di essere affrontato alla radice.
Il punto non è raccogliere più informazioni possibili.
Il punto è trasformare le informazioni in comprensione.
Prima di cambiare, bisogna capire.
Prima di ottimizzare, bisogna osservare.
Prima di progettare una soluzione, bisogna ascoltare il servizio.
Quick wins: piccoli miglioramenti che creano fiducia.
Il miglioramento continuo non ha bisogno di dimostrare tutto subito.
Ha bisogno di iniziare bene.
Le quick wins, o piccole vittorie rapide, servono proprio a questo: rendere visibile che il miglioramento è possibile.
Non a caso, anche ITIL 4 valorizza un approccio iterativo al miglioramento, basato su piccoli incrementi gestibili e su un ciclo costante di feedback.
Non sono scorciatoie. Non sono interventi superficiali. Non sono piccoli cambiamenti fatti per dare l’impressione che qualcosa si stia muovendo.
Una quick win utile nasce da un problema reale e produce un beneficio concreto.
Può essere la semplificazione di un modulo di richiesta.
La riscrittura di una comunicazione poco chiara.
La rimozione di un passaggio inutile.
La revisione di una categoria di ticket usata male.
La creazione di una risposta standard per una richiesta ricorrente.
L’introduzione di un aggiornamento intermedio per i ticket più lunghi.
La pubblicazione di una guida semplice su un problema frequente.
Sono interventi piccoli, ma non irrilevanti.
Nei servizi, infatti, il valore si perde spesso nei dettagli quotidiani: un passaggio poco chiaro, un’informazione mancante, una comunicazione ambigua, una richiesta che rimbalza tra team, una procedura che richiede più fatica del necessario.
Intervenire su questi punti può produrre un impatto immediato.
Le quick wins sono importanti anche per il team. Quando le persone vedono che un miglioramento produce davvero un effetto, aumenta la disponibilità a continuare. Il cambiamento smette di essere un concetto astratto e diventa qualcosa che migliora il lavoro quotidiano.
Naturalmente, le quick wins non bastano da sole.
Non sostituiscono una visione. Non risolvono problemi strutturali. Non eliminano la necessità di interventi più profondi.
Ma creano energia.
E in un percorso di miglioramento continuo, l’energia iniziale conta. Perché permette di passare dalla critica alla costruzione, dalla frustrazione alla possibilità, dalla diagnosi al movimento.
Il segreto è scegliere quick wins coerenti con la direzione complessiva.
Piccole sì.
Casuali no.
Migliorare significa imparare dal servizio.
Il miglioramento continuo fallisce prima di iniziare quando parte già scollegato dalla realtà.
Quando nasce da una soluzione preconfezionata.
Quando vuole rifare tutto da zero senza capire cosa salvare.
Quando ignora lo stato attuale.
Quando non ascolta feedback e segnali operativi.
Quando guarda solo i numeri o solo le percezioni.
Quando propone cambiamenti troppo grandi per essere assorbiti.
Quando promette una rivoluzione, ma non costruisce fiducia.
Migliorare un servizio non significa renderlo perfetto in un solo intervento.
Significa imparare da ciò che il servizio racconta ogni giorno.
Dai ticket che si ripetono ai feedback che tornano dagli utenti. Dalle richieste incomplete ai processi aggirati. Dalle metriche che non tornano alle lamentele che sembrano isolate ma si ripresentano.
Da tutte quelle piccole frizioni che, se ignorate, diventano problemi strutturali.
Il miglioramento continuo è una disciplina di osservazione.
Chiede di guardare meglio prima di cambiare. Di capire prima di correggere. E di usare ciò che esiste, invece di scartarlo automaticamente.
Chiede di scegliere piccoli interventi concreti, misurarne gli effetti e correggere la direzione.
È meno spettacolare di una rivoluzione.
Ma è molto più sostenibile.
Perché un servizio non migliora quando viene ridisegnato perfettamente su una slide.
Migliora quando l’organizzazione impara a leggerlo con più lucidità, ad ascoltarlo con più attenzione e a intervenire con più continuità.
