Ogni volta che parlo di Kanban succede una cosa prevedibile quanto il traffico il lunedì mattina: arrivano le obiezioni. Non sempre le stesse parole, ma quasi sempre gli stessi concetti. E va benissimo così: sono obiezioni legittime, sensate… e anche superabili.
Anzi, col tempo ho imparato a vederle come un passaggio naturale: non sono ostacoli, ma porte che si aprono con le giuste chiavi. In questo articolo condivido le tre più ricorrenti — e qualche spunto per affrontarle con più leggerezza (e un po’ di Kanban).
1. “Kanban può funzionare altrove, ma non nella nostra organizzazione…”
(Piccola, grande, media — a scelta.)
Questa è la classica obiezione da zona di comfort. Se l’organizzazione è piccola: “Siamo troppo piccoli per strutturarci.” Se è grande: “Siamo troppo complessi per queste cose da startup agile.” Insomma, qualsiasi dimensione è perfetta per non mettersi in gioco.
La verità? Kanban non è un vestito taglia unica: è una maglia elastica. Funziona perché si adatta. Puoi iniziare in piccolo, anche solo gestendo il lavoro di un unico flusso. Non serve ristrutturare l’organizzazione, basta iniziare a rendere visibile e gestire ciò che prima era invisibile: il caos.
Se Kanban “funziona solo per gli altri”, chiediti: quali abitudini stai difendendo mascherandole da unicità?
2. “Non abbiamo tempo per cambiare. Lo faremo quando saremo più tranquilli.”
Ecco un paradosso interessante: non si ha tempo di cambiare perché si è troppo occupati a gestire… il disordine che Kanban aiuterebbe a ridurre.
Dire che adotterai Kanban quando avrai più tempo è come dire che inizierai a risparmiare quando sarai ricco. Spoiler: quel momento non arriva mai.
Kanban è pensato per essere introdotto senza fermare nulla. Non richiede un progetto titanico: puoi iniziare domani con tre colonne su una lavagna e alcuni post-it di colori e dimensioni diversi. È un metodo evolutivo, non rivoluzionario. Aspettare il “momento giusto” è solo un modo elegante per dire: “Non sono sicuro di volerlo fare davvero.” Ma possiamo parlarne e iniziare a fare qualcosa insieme.
3. “Il nostro lavoro è troppo imprevedibile. Non è standardizzabile.”
Perfetto. Proprio per questo Kanban è quello che vi serve.
Kanban non serve a standardizzare il contenuto del lavoro, ma il modo in cui lo si gestisce. È pensato per fare ordine nei flussi di lavoro imprevedibili, dinamici, dove il cambiamento è la norma. Non ti chiede di prevedere il futuro, ma di rispondere meglio al presente.
Dire “il nostro lavoro è troppo caotico per Kanban” è come dire “la nostra casa è troppo disordinata per usare un armadio.” Appunto.
In conclusione
Se ti sei ritrovato in una di queste obiezioni, Kanban non è il problema. Forse il problema è che il cambiamento fa un po’ paura, e ci stiamo aggrappando al caos che conosciamo, invece di esplorare un ordine che ci renderebbe davvero più liberi.
Il punto non è “fare Kanban”. Il punto è smettere di sopravvivere e cominciare a lavorare meglio.
E per questo, il momento giusto è adesso. Anzi, era ieri.
In un mio precedente articolo (che potete rileggere qui), parlando di rischi operativi, ho evidenziato un comportamento piuttosto comune in ambienti a bassa maturità organizzativa: la presunta complessità del contesto viene spesso usata come scusa per giustificare le proprie prestazioni inadeguate.
In questi contesti, le difficoltà esterne sono invocate come cause uniche del caos organizzativo, mentre si evita di riconoscere le responsabilità interne, sia individuali che sistemiche. Questo porta alla cosiddetta abdicazione della leadership, che alimenta una mentalità vittimistica e passiva nel team.
Ma come si costruisce un ambiente di lavoro che responsabilizza, invece di deresponsabilizzare? Come si promuove un contesto in cui ognuno si sente autorizzato ad agire da leader?
Uno degli strumenti concreti più efficaci in questo senso è la definizione e la condivisione di uno scopo (purpose) chiaro, che ispiri e orienti l’azione.
Immagine generata da DALL-E
Leadership a tutti i livelli: un principio fondamentale
Uno dei quattro principi base del metodo Kanban afferma:
“Incoraggia atti di leadership a tutti i livelli.”
Significa abilitare ogni individuo – non solo i manager – a migliorare attivamente il sistema. Ma affinché ciò accada, serve più di un metodo visuale o una board Kanban: serve senso. E il senso si costruisce a partire da uno scopo condiviso.
l’organizzazione riconosce che non tutto è fuori controllo;
inizia a discernere tra variabilità sistemica e problemi di metodo;
definisce uno scopo che guida il comportamento, orienta le decisioni e responsabilizza.
Nei livelli di maturità più alti (4 e 5), questo scopo viene interiorizzato a livello di cultura organizzativa: diventa parte del DNA del team.
Esempio pratico: uno scopo che guida le azioni
Prendiamo un team di informatici che sviluppa un’app per la gestione finanziaria personale. Iniziano a usare Kanban per migliorare il flusso, ma si accorgono che senza un orientamento chiaro, le decisioni restano frammentate. Decidono allora di formulare insieme uno scopo condiviso:
“Aiutiamo le persone a sentirsi sicure e in controllo delle proprie finanze attraverso soluzioni semplici, affidabili e accessibili.”
Questo scopo viene:
reso visibile sulla Kanban board;
usato come criterio per dare priorità;
richiamato nei momenti di review e miglioramento.
Risultato?
Un designer propone una nuova funzione utile non richiesta dal backlog.
Uno sviluppatore junior evidenzia un rischio sulla fiducia dell’utente.
Il team rifiuta collettivamente una richiesta del marketing che va contro il purpose.
Tutti questi sono atti di leadership distribuita, resi possibili dallo scopo.
Conclusione: lo scopo come antidoto alla mentalità vittimistica
Uno scopo chiaro è molto più di una dichiarazione d’intenti: è una fonte di libertà e responsabilità. È lo strumento con cui un’organizzazione può contrastare la mentalità vittimistica, valorizzare il contributo individuale e coltivare una cultura in cui tutti si sentono parte attiva del miglioramento.
Nel linguaggio del KMM, questo è ciò che distingue i sistemi maturi da quelli che abdicano: non è la complessità esterna a fare la differenza, ma la chiarezza interna sul perché si fa ciò che si fa.
Uno degli aspetti che trovo più affascinanti e rivoluzionari di Kanban è l’abolizione della pianificazione nel senso tradizionale del termine. Un’affermazione che, in ambito aziendale, spesso suscita sguardi perplessi e il sospetto che si tratti di una mera provocazione. Eppure, il punto è proprio questo: Kanban elimina la pianificazione perché essa, semplicemente, non funziona. Il motivo? L’impossibilità di prevedere ogni variabile in modo deterministico.
Al suo posto, Kanban introduce un approccio diverso, basato sull’analisi del rischio e dell’incertezza. Più che pianificare, si adotta un approccio di forecasting che è sorprendentemente vicino a quello della “navigazione stimata” nella barca a vela. Proprio come un’imbarcazione che si muove sulla superficie al confine tra due fluidi e adatta la sua rotta alle condizioni del vento e del mare, un sistema Kanban si muove in un contesto dinamico e complesso, dove la realtà non segue schemi prestabiliti. E forse è proprio questa la sua forza: accettare l’incertezza, invece di combatterla con previsioni che spesso si rivelano illusorie, e imparare a navigarla con agilità.
La navigazione stimata
La navigazione stimata in barca a vela è un metodo per determinare la propria posizione e tracciare la rotta basandosi su calcoli e osservazioni di punti di riferimento, venti, correnti e condizioni meteorologiche. Si parte da un punto noto e, tenendo conto della velocità dell’imbarcazione, della direzione del vento, della corrente e del tempo trascorso, si stima dove ci si trova in un dato momento. Questo approccio non è statico, ma dinamico: man mano che si procede, si raccolgono nuove informazioni – ad esempio, cambiamenti nelle condizioni meteo o nella direzione e intensità del vento – e si adatta la rotta e la previsione di viaggio di conseguenza. Proprio come in un sistema Kanban, la chiave della navigazione stimata non è pianificare rigidamente, ma correggere il percorso in base alla realtà del momento, accettando l’incertezza come parte integrante del viaggio.
Parallelismi tra la navigazione stimata e Kanban
Dipendenza dalle condizioni attuali
Sia in mare che nei progetti, le condizioni iniziali sono solo un punto di partenza. Un navigatore si basa su venti, correnti e posizione attuale per prendere decisioni consapevoli e adattare continuamente la rotta. Allo stesso modo, un team Kanban osserva il flusso di lavoro, identifica i colli di bottiglia, e modifica le modalità di gestione del flusso di lavoro in base a ciò che emerge. L’attenzione si concentra su ciò che è “in corso”, limitando il carico di lavoro per garantire che ogni attività sia completata prima di iniziarne un’altra.
Previsioni e non certezze
Un navigatore può prevedere la durata del viaggio, ma sa che condizioni non del tutto previste possono influenzare il percorso e utilizza in modo costante le previsioni meteomarine, che sono basate su analisi di tipo probabilistico. Similmente, in Kanban si utilizzano misure basate su dati storici per prevedere la durata delle attività, tenendo però sempre conto della loro variabilità statistica per fare un’analisi di probabilità.
Adattamento continuo alle condizioni
Il viaggio di una barca a vela non è mai lineare. I navigatori correggono costantemente la rotta, sfruttando le nuove informazioni e reagendo agli imprevisti. Anche in Kanban, la gestione del flusso è un processo iterativo, dove si acquisiscono informazioni e si incontrano ostacoli imprevisti lungo il percorso e si adatta il modo di lavorare di conseguenza.
Monitoraggio continuo
Il navigatore utilizza gli strumenti di bordo e i rilevamenti per verificare la posizione e confrontarla con il percorso pianificato. In Kanban le metriche come il lead time e il throughput aiutano a capire se il sistema sta funzionando correttamente e dove sono necessari interventi.
Importanza della comunicazione
Una buona comunicazione è vitale sia a bordo di una barca a vela che in un team Kanban. I membri dell’equipaggio devono condividere informazioni sulle condizioni del mare e sulle manovre necessarie. Analogamente, la trasparenza e la collaborazione sono essenziali in Kanban per garantire che tutti i membri del team siano allineati e informati.
Flessibilità e feedback
La navigazione stimata privilegia l’adattamento alle circostanze rispetto a un piano rigido, un navigatore pone costante attenzione ai segnali ambientali e sviluppa la capacità di anticipare i cambiamenti. In Kanban allo stesso modo, i cicli di feedback costanti e la flessibilità sono fondamentali per reagire tempestivamente ai cambiamenti e garantire il successo dei progetti e dei servizi.
Gestione delle dipendenze
Come un navigatore deve considerare le maree e le correnti, un team Kanban deve gestire le dipendenze tra le attività. Questo richiede accorgimenti e meccanismi opportuni per garantire che il flusso di lavoro non venga interrotto.
Orientamento al flusso
In barca a vela, uno degli obiettivi fondamentali è mantenere l’imbarcazione in movimento, adattandosi continuamente alle condizioni del vento e del mare. Il navigatore controlla costantemente il movimento della barca, regolando le vele per mantenere la rotta. Se la barca si ferma o perde troppo slancio, ripartire diventa difficile e inefficiente. Lo stesso principio si applica al concetto di flusso in Kanban, l’obiettivo è mantenere il flusso costante, garantendo che il lavoro proceda senza intoppi, riducendo blocchi e interruzioni.
Non conta partire, conta arrivare
In barca a vela, ciò che conta davvero non è la velocità assoluta dell’imbarcazione, ma la Velocity Made Good (VMG) on course, ovvero la velocità effettiva con cui ci si sta avvicinando alla destinazione. Una barca può muoversi rapidamente, ma se la direzione non è quella giusta, il progresso reale sarà minimo. Lo stesso principio si applica a Kanban, non è importante quanto velocemente si lavora in un dato momento, ma quanto lavoro viene effettivamente consegnato. L’obiettivo non è essere sempre impegnati o lavorare al massimo della velocità, ma completare il lavoro nel modo più efficiente possibile, riducendo sprechi e rallentamenti. Come in navigazione, l’essenziale non è l’illusione del movimento, ma il progresso reale verso la meta.
Conclusione
Kanban e la navigazione stimata in barca a vela condividono un principio fondamentale: il successo non dipende da piani rigidi, ma dalla capacità di osservare, misurare, adattarsi e rispondere ai cambiamenti. In entrambi i casi, l’obiettivo non è fissare una rotta immutabile, ma ottimizzare il flusso per avanzare in modo efficiente e consapevole. Così come un velista parte con una direzione generale, sfrutta previsioni e stime per tracciare il percorso, ma è sempre pronto a correggere la rotta in base alle condizioni reali, allo stesso modo Kanban permette di gestire il lavoro in modo dinamico, adattandosi alle sfide man mano che emergono. Questa flessibilità non è solo una necessità, ma la chiave per navigare con successo la complessità, trasformando ogni progetto o servizio in un viaggio in cui conta non solo la meta, ma anche il modo in cui la si raggiunge.
L’Arsenale di Venezia, un tempo il più grande complesso industriale d’Europa, e il metodo Kanban potrebbero sembrare non avere alcuna correlazione. Tuttavia, un’analisi più attenta e approfondita rivela sorprendenti somiglianze e interessanti spunti di riflessione. L’esempio che sto per raccontarvi ci condurrà alla scoperta di una straordinaria storia che affonda le sue radici nel passato.
Un modello pionieristico di produzione industriale
L’Arsenale di Venezia, fondato nel XII secolo, rappresenta uno dei primi e più avanzati esempi di complesso industriale integrato nella storia. Si trattava di un cantiere navale gestito dalla Repubblica di Venezia, specializzato nella costruzione e nella manutenzione delle navi da guerra e mercantili della Serenissima. Per secoli, è stato il cuore pulsante della potenza marittima veneziana, grazie a una straordinaria organizzazione del lavoro che anticipava molti dei principi della produzione industriale moderna.
Con una forza lavoro che raggiungeva le 16.000 unità, l’Arsenale era in grado di costruire e allestire una galea al giorno, grazie a un’organizzazione del lavoro altamente specializzata e a una divisione delle fasi produttive. Questa struttura permetteva una produzione efficiente e standardizzata delle navi.
L’entrata dell’Arsenale dipinta da Canaletto, 1732
L’organizzazione della produzione nell’Arsenale di Venezia
L’Arsenale funzionava come una gigantesca macchina produttiva, organizzata secondo un modello che garantiva velocità, efficienza e qualità nella costruzione delle navi. La produzione era suddivisa in una serie di fasi altamente specializzate, ciascuna affidata a operai esperti detti “arsenalotti”. Questi artigiani erano suddivisi in corporazioni a seconda del loro ruolo nel processo produttivo.
La gestione del flusso di lavoro
La costruzione di una nave all’interno dell’Arsenale seguiva un percorso ben definito, che prevedeva le seguenti fasi principali:
Preparazione del legname: Il legno proveniva dalle foreste del Cadore e di altri territori sotto il controllo della Serenissima. Dopo essere stato selezionato e stagionato, veniva trasportato all’Arsenale per essere lavorato.
Assemblaggio dello scafo: Gli operai specializzati nelle strutture in legno lavoravano con una precisione quasi standardizzata. L’impiego di modelli e tecniche di produzione ripetitive permetteva di costruire scafi in tempi rapidi.
Placcatura e rinforzi: Dopo la realizzazione dello scheletro della nave, si procedeva alla placcatura esterna con tavole di legno, fissate con chiodi e resine impermeabilizzanti. Le navi veneziane erano rinomate per la loro robustezza e leggerezza.
Installazione delle sovrastrutture e dell’attrezzatura di bordo: In questa fase venivano installati gli alberi, le vele, i remi e le decorazioni, oltre alle cabine per l’equipaggio e i capitani.
Armamento e rifinitura: Le navi da guerra erano dotate di cannoni e altre attrezzature belliche prima di essere varate e messe in servizio.
Questa suddivisione del lavoro consentiva di realizzare una galea in tempi straordinariamente brevi per l’epoca, arrivando, nei momenti di massima efficienza, a costruire una nave al giorno.
Un sistema Kanban ante litteram
Uno degli aspetti più innovativi dell’Arsenale di Venezia era la sua capacità di funzionare in maniera simile a un moderno sistema di produzione Kanban. Il processo di costruzione delle navi era altamente standardizzato e suddiviso in reparti specializzati, con un flusso di materiali e manodopera ottimizzato per garantire la massima produttività.
Gli arsenalotti utilizzavano un sistema di prefabbricazione in cui le diverse sezioni della nave, come ordinate, paratie e fasciame, venivano prodotte separatamente e contrassegnate con numeri o segni distintivi. Queste parti venivano poi trasportate nei punti di assemblaggio finale, dove venivano montate in sequenza, riducendo significativamente i tempi di costruzione. La numerazione delle parti facilitava il lavoro degli operai specializzati, assicurando che ogni componente fosse posizionato correttamente senza margine di errore.
A differenza di altri cantieri navali dell’epoca, dove la costruzione avveniva in modo artigianale e disperso, nell’Arsenale veneziano la produzione era centralizzata e organizzata in una sequenza precisa. Questa innovazione permetteva di ottenere navi di qualità uniforme e di ridurre i tempi di realizzazione, garantendo a Venezia una flotta costantemente rinnovata e aggiornata.
La gestione delle risorse e il controllo della qualità
La Repubblica di Venezia esercitava un controllo rigoroso sulle risorse necessarie alla produzione navale. Le materie prime, come il legno, il ferro e la pece, erano gestite direttamente dallo Stato, che ne garantiva la disponibilità e la qualità. Anche la manodopera era regolata da un sistema preciso: gli arsenalotti godevano di salari stabili e privilegi che li incentivavano a trasmettere le loro competenze alle nuove generazioni.
Inoltre, ogni fase della costruzione era soggetta a controlli rigorosi per garantire la massima qualità delle imbarcazioni. La Serenissima aveva compreso l’importanza della standardizzazione e della manutenzione preventiva per mantenere la propria supremazia marittima.
Valori del metodo Kanban riconoscibili nel sistema dell’Arsenale di Venezia
Il metodo Kanban si basa su valori e pratiche che possiamo sorprendentemente ritrovare nell’organizzazione dell’Arsenale di Venezia. Di seguito analizziamo le principali corrispondenze.
1. Trasparenza
Kanban enfatizza la trasparenza dei processi di lavoro attraverso strumenti visivi, come le Kanban board. Allo stesso modo, nell’Arsenale di Venezia, l’organizzazione della produzione era chiara e strutturata:
Le diverse fasi della costruzione navale erano visibilmente organizzate nei vari reparti dell’Arsenale.
Ogni lavoratore sapeva esattamente quale fosse la sua mansione e il contributo alla fase produttiva.
2. Collaborazione
Il metodo Kanban incoraggia la collaborazione tra team per migliorare il flusso di lavoro. L’Arsenale era un esempio di lavoro collettivo su larga scala:
Le diverse corporazioni di mestieri (falegnami, calafati, fabbri, velai) collaboravano strettamente per completare ogni nave nel minor tempo possibile.
Il processo produttivo era suddiviso in team specializzati che operavano in modo interdipendente, simile ai team Kanban moderni.
3. Equilibrio
Kanban aiuta a bilanciare la domanda e la capacità produttiva. L’Arsenale manteneva un equilibrio attraverso:
Produzione su richiesta, evitando scorte eccessive. Le navi venivano costruite in base alle esigenze della Repubblica di Venezia, evitando surplus inutili.
Una gestione delle risorse centralizzata, assicurando che ogni reparto ricevesse materiali in modo coordinato.
4. Focalizzazione sul cliente
Il metodo Kanban incoraggia a lavorare su ciò che porta valore al cliente finale. L’Arsenale aveva una forte attenzione al bisogno della Serenissima:
La produzione di navi era ottimizzata per garantire potenza navale e velocità di risposta alle esigenze militari e commerciali di Venezia.
La capacità di costruire una galea al giorno era una risposta diretta alle necessità strategiche di difesa e commercio.
5. Leadership a tutti i livelli
Kanban valorizza il ruolo di ogni membro del team nel miglioramento continuo. Anche nell’Arsenale:
Gli arsenalotti non erano semplici operai, ma specialisti altamente qualificati, il cui sapere era tramandato di generazione in generazione.
L’organizzazione del lavoro lasciava spazio all’iniziativa individuale, permettendo ai maestri d’arte di migliorare continuamente le tecniche costruttive.
Pratiche del metodo Kanban riconoscibili nel sistema dell’Arsenale di Venezia
1. Visualizzare il lavoro
Nel metodo Kanban, i flussi di lavoro vengono visualizzati su una board. Nell’Arsenale:
Il layout fisico dell’Arsenale permetteva una visualizzazione naturale, dove ogni fase di costruzione aveva una posizione ben definita.
Le navi in costruzione erano assemblate lungo un canale e le attività assegnate a ogni squadra erano chiaramente visibili.
2. Limitare il lavoro in corso (WIP – Work In Progress)
Il metodo Kanban limita il numero di attività in corso per evitare sovraccarico e sprechi. Nell’Arsenale:
La costruzione era organizzata per fasi specifiche e sequenziali, evitando congestioni di lavoro.
Il numero di navi in produzione era attentamente regolato per non sovraccaricare le risorse e ottimizzare i tempi.
3. Gestire il flusso di lavoro
Kanban aiuta a identificare colli di bottiglia e ottimizzare il flusso. Nell’Arsenale:
La suddivisione del lavoro in reparti specializzati assicurava un flusso regolare e prevedibile della produzione.
Ogni squadra di operai riceveva i materiali e i componenti nel momento giusto, garantendo un processo continuo, l’Arsenale era sostanzialmente un sistema ‘pull’.
4. Rendere le regole di processo esplicite
Kanban suggerisce di rendere le regole operative chiare per tutti. Nell’Arsenale:
Il lavoro era rigidamente regolato da norme statali e procedure definite.
I mestieri erano organizzati in corporazioni con ruoli e compiti ben definiti, simili alle policy documentate nei sistemi Kanban.
5. Implementare feedback loop
Nel metodo Kanban, i feedback sono la vera e propria catena di trazione del miglioramento continuo. Nell’Arsenale:
La produzione era monitorata costantemente, per correggere errori e ottimizzare i processi.
Venezia investiva nella formazione continua degli arsenalotti, trasmettendo le conoscenze per migliorare le tecniche produttive.
6. Migliorare collaborando ed evolvere sperimentando
Il metodo Kanban incoraggia cambiamenti incrementali per ottimizzare il sistema. Nell’Arsenale:
I metodi di costruzione delle navi si evolvevano continuamente, adattandosi alle nuove esigenze belliche e commerciali.
L’innovazione tecnologica era costante, con l’introduzione di miglioramenti nei materiali e nelle tecniche di assemblaggio.
Conclusione
L’Arsenale di Venezia rappresentava un modello industriale e di organizzazione del lavoro sorprendentemente vicino ai principi di Lean e del metodo Kanban. La suddivisione delle fasi produttive, la gestione del flusso, il controllo delle risorse e della qualità hanno reso questo straordinario cantiere navale uno dei più avanzati della storia.
Il modello produttivo veneziano non solo garantì alla Serenissima una flotta potente ed efficiente, che dominò i mari per quasi un millennio, ma gettò anche le basi per quelli che sono stati i successivi sviluppi nel campo della produzione industriale. Sebbene sviluppato in un contesto preindustriale, il metodo veneziano dimostra come l’efficienza nella gestione del lavoro sia un principio senza tempo.
Quando un cliente richiede un intervento a un fornitore, il suo obiettivo principale è ottenere una soluzione rapida ed efficace alla propria richiesta. Non è interessato alle eventuali difficoltà interne del fornitore, come un carico di lavoro elevato o altre sfide organizzative. Questa realtà pone una pressione significativa sui fornitori, ma offre anche un’opportunità per migliorare l’organizzazione utilizzando strumenti come le Classi di Servizio definite dal metodo Kanban.
Gestione di tre classi di servizio al gate di un aeroporto
Il cliente e le aspettative di risposta
La settimana scorsa, erano i primi giorni del nuovo anno dopo le festività natalizie, ho chiesto un intervento a un fornitore e ho ricevuto questa risposta:
“Buongiorno, oggi pomeriggio verrete contattati da Mario (nome di fantasia) e verrà fornito un preventivo per gli interventi da svolgere. Ci scusiamo per l’attesa, ma abbiamo un carico di lavoro abbastanza elevato in questi giorni e stiamo cercando di evadere tutte le richieste in maniera più celere possibile. Grazie”
Ho preso questa come esempio, ma risposte dello stesso tenore sono abbastanza comuni nei servizi. Alle volte sono anche verbose e forniscono giustificazioni articolate, tipicamente imputando la responsabilità a fattori esterni. Tuttavia al cliente non interessa quale carico di lavoro abbia il fornitore né il perché. Mi chiedo sempre perché chi scrive tali risposte non rifletta mai sul fatto che, quando si trova a sua volta a essere cliente di qualcuno, non è affatto interessato ai problemi di chi sta dall’altra parte.
Per un’organizzazione che vuole migliorare il proprio livello di maturità, è fondamentale smettere di dedicare tempo alle giustificazioni e investire invece lo stesso tempo nello sviluppo di un sistema organizzativo. Il metodo Kanban ci può aiutare e nello specifico ci possono aiutare le Classi di Servizio.
Perché il cliente non è interessato ai problemi del fornitore?
Il cliente si trova al centro della propria esperienza e il suo problema è la sua priorità. Ecco alcuni motivi per cui il cliente non considera rilevanti le difficoltà interne del fornitore:
Aspettative elevate: I clienti si aspettano risposte rapide e soluzioni efficaci, soprattutto quando hanno già atteso un certo periodo di tempo.
Concorrenza sul mercato: Se un fornitore non è in grado di rispondere tempestivamente, il cliente può rivolgersi a un concorrente.
Percezione del valore: Il cliente valuta il servizio in base al risultato finale e alla qualità dell’interazione, non agli ostacoli incontrati dal fornitore lungo il percorso.
Questa disconnessione di prospettive sottolinea l’importanza di un’organizzazione interna che permetta di gestire al meglio le richieste, anche in periodi di alta domanda.
Vediamo quali sono le tipiche Classi di Servizio che possono essere utilizzate per garantire i livelli di servizio, anche a fronte di un carico di lavoro elevato.
1. Classe Urgente (Expedite)
Questa classe è dedicata alle richieste che richiedono attenzione immediata e non possono aspettare. Nel contesto del servizio clienti, potrebbe includere:
Problemi critici che bloccano le operazioni del cliente.
Emergenze che richiedono un intervento immediato.
Le richieste in questa classe devono essere gestite con la massima priorità, interrompendo temporaneamente il lavoro su altre attività. Perciò il numero di richieste di Classe Urgente gestibili deve essere limitato, definendo bene le policy per l’assegnazione di questa classe alle richieste.
2. Classe a Data Fissa (Fixed Date)
Alcune richieste hanno una scadenza specifica, ma non richiedono attenzione immediata. Ad esempio:
La maggior parte delle richieste rientra normalmente in questa classe. Sono importanti, ma non urgenti e non hanno una scadenza specifica. Il loro costo del ritardo cresce linearmente e devono essere gestite entro un ‘periodo ragionevole’. Nei sistemi organizzativi maturi il fornitore è in grado di definire tale ‘periodo ragionevole’ e offrire al cliente un livello di servizio standard basato sulla misura del Lead Time. Il fornitore è anche in grado di calcolare un livello di rischio operativo rispetto al livello di servizio offerto. Ho scritto un articolo al proposito che potete leggere qui.
4. Classe Intangibile
Questa classe è riservata a lavori che migliorano i processi interni o riducono i rischi futuri, ma che non hanno un impatto immediato sul cliente. Il costo del ritardo è appunto ‘intangibile’. Ad esempio:
Ottimizzazione dei sistemi.
Formazione del personale.
Queste richieste svolgono un ruolo importante nei periodi di bassa domanda da parte dei clienti, perché costituiscono una riserva di lavoro che consente di mantenere costante il carico di lavoro del sistema.
Differenziazione dei prezzi in base alle Classi di Servizio
Un aspetto interessante delle Classi di Servizio è la possibilità di applicare prezzi differenziati, come avviene in settori come quello ferroviario o aereo. Ad esempio:
Classe Urgente: Può comportare un costo più elevato per garantire un trattamento prioritario e la disponibilità immediata delle risorse.
Classe a Data Fissa: Un prezzo intermedio, che riflette la necessità di una pianificazione specifica ma senza l’urgenza.
Classe Standard: Un prezzo adeguato al livello di servizio standard offerto.
Classe Intangibile: In molti casi, questa classe potrebbe non essere addebitata direttamente al cliente ma rappresentare un investimento interno.
Definire una struttura tariffaria in funzione delle Classi di Servizio non solo permette di allocare meglio le risorse, ma può anche aiutare i clienti a scegliere il livello di servizio più adatto alle loro esigenze, aumentando la loro soddisfazione complessiva.
Come implementare le Classi di Servizio nella gestione delle richieste
Un approccio di base alla disciplina del triage prevede un lavoro continuativo rispetto ai seguenti punti:
Identificazione delle richieste: Classificare ogni richiesta in base al costo del suo ritardo utilizzando le Classi di Servizio.
Comunicazione con il cliente: Informare il cliente su quando e come la sua richiesta verrà gestita, migliorando la trasparenza.
Allocazione delle risorse: Assegnare le risorse in base alle classi, evitando il sovraccarico di un singolo team o operatore.
Monitoraggio e miglioramento continuo: Utilizzare metriche come il Lead Time e il tempo di ciclo (Cycle Time) per monitorare le prestazioni e apportare miglioramenti.
Conclusione
Un carico di lavoro elevato non deve diventare un ostacolo alla soddisfazione del cliente. Implementando le Classi di Servizio del metodo Kanban ed eventualmente introducendo una differenziazione dei prezzi, i fornitori possono migliorare la gestione delle richieste, garantire tempi di risposta adeguati e mantenere alta la soddisfazione del cliente. In questo modo, è possibile trasformare una sfida organizzativa in un’opportunità per ottimizzare i processi e fidelizzare i clienti.
Quando si implementa un sistema Kanban è importante evitare di complicare inutilmente le cose. In particolare un aspetto con cui mi confronto spesso è come riuscire a ricavare, appunto senza complicazioni inutili, le prime metriche di flusso su cui lavorare.
Iniziare da quello che si sta facendo ora
Kanban ci insegna a iniziare da quello che si sta facendo ora e tipicamente i team dispongono già di sistemi informativi, quali che siano. Un approccio relativamente semplice per ottenere dati sui Lead Time è quindi quello di estrarre dai sistemi esistenti le marche temporali (timestamp) relative alle varie attività e lavorare su quelle in un foglio di calcolo, per ricavare le metriche. Così ho fatto anche recentemente, salvo che mi sono trovato davanti a una situazione che mi ha fatto riflettere. Voglio raccontarvi l’episodio perché è rappresentativo di un approccio che si incontra spesso e che però è dannoso.
Una soluzione inutilmente complicata
Il flusso di lavoro in questione (per la gestione dell’iscrizione a un servizio e la firma di un contratto) consta di 5 step. Ho chiesto al fornitore del sistema informativo già esistente di poter estrarre una tabella con le marche temporali dei passaggi di stato tra i cinque step. Semplicissimo, il resto lo avrei fatto io sul mio foglio di calcolo. Ho ottenuto la seguente risposta (la ho modificata e decontestualizzata per ovvie ragioni di riservatezza, ma ne ho conservato il senso):
“Per rispondere alla richiesta basterebbe aggiungere 5 campi alla form di iscrizione, che verrebbero valorizzati ad ogni passaggio di stato. (T0 – Creazione, T1 – Risposta, T2 – Verifica, T3 – Firma, T4 – Completata)
Però, durante i primi utilizzi del sistema è emersa la necessità di “forzare lo stato” dell’iscrizione per riportarlo indietro e dunque si potrebbe verificare che un determinato T registrato nel sistema possa essere sovrascritto (es. “T3 – Firma” se ripercorro uno step precedente verrebbe sovrascritto).
A tal proposito quanto sopra proposto non sarebbe più valido e la nostra soluzione diventa quella di disabilitare il campo di stato dell’iscrizione e implementare un’azione “Cambia Stato” dove si dovrà selezionare il nuovo stato che si vuole assegnare all’iscrizione, oltre all’inserimento di una motivazione.
I campi sopra proposti non sarebbero più necessari e addirittura fuorvianti e dunque la form sopra descritta alimenterebbe un elenco di “Audit”, in cui ogni singola riga rappresenta un singolo cambio di stato della singola iscrizione. (Autore, Ora e Motivazione).
Saranno messi a disposizione i seguenti elenchi: …”
Il messaggio terminava con la lista degli elenchi messi a disposizione e una quotazione della soluzione proposta.
La soluzione semplice
Le prime tre righe in realtà avevano già risposto alla mia richiesta, sarebbe bastato fare una quotazione di quello (che però non è stata fatta). Invece chi ha risposto ha preso spunto da alcune eccezioni che si erano verificate nel flusso e si è impegnato nell’immaginare una gestione di tali eccezioni. Che peraltro nessuno aveva richiesto. Tanto però è bastato per convincere i miei colleghi a rimandare la richiesta.
Ho dovuto discutere, prima con i miei colleghi, poi con il fornitore, per farli recedere dalla ‘gestione delle eccezioni’ e convincerli ad adottare la semplice soluzione che anche il fornitore aveva perfettamente delineato nelle prime tre righe della risposta. Una volta convinti, e a qualche settimana di distanza dall’implementazione (per raccogliere i primi dati), la nostra Flow Review si è arricchita di una utilissima metrica di distribuzione dei Lead Time. E le eccezioni? Le ho semplicemente tolte dai dati e trattate a parte, per il momento.
Morale della storia
Che lezione possiamo trarre da questa storia?
Il metodo Kanban incoraggia la semplicità e l’efficienza, iniziando con i processi esistenti, migliorandoli in modo incrementale e concentrandosi sul flusso di valore. Nel caso descritto è stata sufficiente la semplice estrazione dei dati per analizzare le prime metriche e valutare insieme al team le successive azioni di miglioramento del servizio da sperimentare. Senza inutili complicazioni.
Una delle caratteristiche principali del metodo Kanban è la semplicità e l’efficacia nel visualizzare il flusso di lavoro. Un esempio sorprendentemente chiaro di Kanban in azione si può trovare in una pizzeria tradizionale e in quello che reputo uno degli strumenti più antichi del mondo: lo spillone porta comande.
Lo spillone porta comande come sistema Kanban
Come è ancora facile osservare in molte pizzerie e ristoranti, le comande vengono tradizionalmente appuntate su foglietti di carta e infilate in uno spillone vicino alla cucina. Questo semplice strumento è un esempio intuitivo di sistema Kanban. Riflettiamo su come funziona:
1. Visualizzazione del lavoro
Ogni foglietto rappresenta un ordine da preparare. Lo stato del lavoro è visibile in tempo reale:
I foglietti infilati sullo spillone sono gli ordini ricevuti e ancora da iniziare.
Quelli che vengono tolti dallo spillone e messi sul bancone del pizzaiolo o in cucina sono in corso di lavorazione.
Gli ordini completati vengono rimossi dal sistema.
2. Limitazione del lavoro in corso
Il numero massimo di foglietti che lo staff può gestire contemporaneamente è limitato dalla capacità operativa della cucina. Se la pila dei foglietti cresce troppo, il sistema segnala un sovraccarico e suggerisce la necessità di gestire meglio la capacità o rallentare l’accettazione di nuovi ordini.
3. Gestione del flusso
I foglietti si spostano lungo un percorso implicito:
Ingresso: L’ordine viene preso dal cameriere e aggiunto allo spillone.
Elaborazione: Il pizzaiolo o la cucina preparano i piatti in ordine di arrivo.
Uscita: Una volta completato, l’ordine viene servito e il foglietto viene eliminato.
4. Feedback immediato
Lo spillone offre feedback istantaneo sullo stato del lavoro:
Se il numero di foglietti aumenta rapidamente, è chiaro che c’è un collo di bottiglia.
Se la pila si riduce o si svuota, il flusso sta funzionando in modo ottimale.
Vantaggi del sistema
Semplicità: Non richiede tecnologia avanzata o competenze tecniche.
Trasparenza: Tutti i membri dello staff possono vedere lo stato degli ordini.
Adattabilità: Si adatta automaticamente alla capacità della cucina.
Miglioramento continuo: I dati visivi sul flusso di lavoro aiutano a identificare e risolvere i problemi.
Conclusione
Uno spillone porta comande in una pizzeria è un esempio tangibile di come i principi del Kanban possano essere applicati in qualunque contesto di servizi. Questa semplicità dimostra che i metodi di gestione visuale del lavoro possono migliorare l’efficienza e la trasparenza ovunque ci sia un flusso di lavoro, dalla cucina di una pizzeria a un team di sviluppo software. Una lezione preziosa per chiunque desideri ottimizzare i propri processi!
Un breve articolo che ho letto in questi giorni mi ha ricordato una grande verità: nessuno si ricorderà o renderà merito agli eroi silenziosi che giorno per giorno, con piccoli costanti cambiamenti, permettono alle organizzazioni di prosperare prevenendo i problemi ed evitando i rischi.
Così come tutti si ricordano i pompieri che hanno spento un incendio e salvato vite ma nessuno si ricorda di chi altrove, con un lavoro nascosto e costante di prevenzione, ne ha evitati magari a decine con un impatto reale molto maggiore.
Ne avevo già parlato a proposito del ruolo di project manager in un precedente post che potete rileggere qui, ma vale per qualunque ruolo aziendale. Non servono eroi, servono risk manager.
Riporto l’articolo originale di Dimitar Bakardzhiev (la traduzione è mia):
“Avete mai notato che gli ingranaggi organizzativi di solito girano senza alcun plauso per le menti che li guidano?
Ciò evidenzia la realtà del management: gli stessi individui o le iniziative che guidano la trasformazione sono spesso trascurati o sottovalutati.
Questi eroi non celebrati – manager che risolvono silenziosamente i conflitti, implementano sistemi che prevengono il caos o motivano i team a superare le aspettative – raramente fanno notizia.
Eppure, sono le ancore che tengono a galla e fanno prosperare le organizzazioni. Il loro contributo, anche se impercettibile, è la spina dorsale del progresso.
Forse è giunto il momento di fermarsi e chiedersi: stiamo davvero riconoscendo i catalizzatori nelle nostre organizzazioni o lasciamo che il successo metta in ombra i suoi architetti silenziosi?
Iniziamo a celebrare non solo i risultati, ma anche le menti umili che li rendono possibili.”
La pratica di guardare al programma settimanale tipico e di fare un’analisi personale della capacità produttiva rispetto alle diverse attività da svolgere – che ho chiamato Personal Capacity Planning – è un esercizio che da oltre un decennio suggerisco alle persone a cui faccio da coach in molte organizzazioni. E ha sempre aumentato la loro produttività.
Primo passo: cercare i modelli settimanali personali
Il metodo applicato è molto empirico e pragmatico. Non vengono fatte stime o pianificazioni delle attività, che sarebbero dispendiose in termini di tempo e di denaro; l’idea è invece quella di ricordare ciò che è stato fatto in media nelle ultime settimane, alla ricerca di un modello. Un approccio alternativo consiste semplicemente nel tenere traccia e registrare ciò che viene fatto nell’arco di due o tre settimane.
Personal Capacity Planning su lavagna del 2011
Ciò che emerge è di solito un modello di come i carichi sono tipicamente distribuiti per mantenere il livello di attività corrente, e la cosa che mi ha sempre sorpreso è come si possano individuare modelli sensati anche in organizzazioni piuttosto caotiche (livello di maturità tra 0 e 3 del Modello di Maturità Kanban). È come se le persone in queste organizzazioni tendessero istintivamente a compensare il caos che le circonda dandosi delle routine prevedibili a livello personale. Inoltre, mantiene la sua utilità anche nelle organizzazioni con un livello di maturità più elevato.
Secondo passo: regolare i modelli per far evolvere il flusso di lavoro
L’aspetto interessante è che questa tendenza istintiva può essere sfruttata per evolvere e stabilizzare i flussi di lavoro. Il solo fatto che le persone visualizzino la loro settimana tipo e ne diventino più consapevoli, tende a stabilizzare il loro comportamento e quindi il sistema. Inoltre, applicando altre pratiche Kanban insieme al team, come la visualizzazione del lavoro, l’analisi dei flussi di lavoro, la raccolta delle metriche iniziali e la comprensione delle azioni che possono migliorare il flusso di lavoro, il team può agire in modo condiviso sui modelli personali di pianificazione delle capacità, cercando di modificarli per facilitare il miglioramento del flusso di lavoro nella direzione desiderata. All’interno delle cadenze Kanban, in primo luogo il Team Kanban Meeting ma anche la Service Delivery Review, il team può discutere e condividere come eseguire esperimenti safe-to-fail regolando ogni singolo pattern per far evolvere i flussi di lavoro, in modo che con successivi aggiustamenti nel tempo i flussi di lavoro possano essere stabilizzati e ottimizzati.
Ho trovato questa pratica particolarmente utile quando le persone sono impegnate in diversi team e in diversi flussi di lavoro, e ho sempre osservato empiricamente una tendenza a riequilibrare le prestazioni tra i flussi, ad esempio rallentando i flussi di lavoro che stanno ottenendo risultati migliori rispetto agli SLA (livelli di servizio concordati) a favore di un’accelerazione dei flussi di lavoro che sono sottoperformanti.
Personal Capacity Planning su supporto elettronico del 2024
Terzo passo: riservare la capacità secondo le proprie esigenze
Regolare e riequilibrare la capacità personale permette anche di riservare della capacità, se necessario. Quando ho attuato questa pratica per la prima volta, nel 2011, ero il delivery manager di un’azienda di software e guidavo un gruppo di project manager. Il problema principale di allora era che molte risorse impegnate nei progetti erano condivise ed erano anche impegnate in altre attività di manutenzione operativa. È stato allora che ci è venuta l’idea di riservare degli “slot” di capacità, in modo da evitare conflitti con i progetti e assicurarci che la capacità disponibile per i progetti fosse realistica.
La reazione iniziale all’introduzione di questa pratica è sempre stata di sospetto, come se volessi farmi gli affari del team e controllarli mettendoli in una sorta di “gabbia”. Dopo qualche tempo, però, le persone hanno sempre scoperto che non si tratta di una “gabbia”, ma di un metodo gestito autonomamente dal team stesso e finalizzato a sostenere la stabilità e la prevedibilità del loro sistema di lavoro, indipendentemente da fattori esterni di disturbo. Una maggiore stabilità e prevedibilità del sistema significa che le persone, e i team di cui fanno parte, hanno nel tempo un controllo sempre più efficace sui livelli di servizio che offrono ai clienti e quindi, in ultima analisi, diventano padroni del proprio destino.
Questa pratica non limita, non rinchiude il team in una “gabbia”, ma fa l’opposto, sollevando il team dalla pressione esterna. È un concetto controintuitivo che può essere compreso appieno solo sperimentando una pratica che si integra perfettamente con il Metodo Kanban ed è pienamente in linea con i suoi principi.
“Sii il cambiamento che desideri vedere nel mondo” – Mahatma Gandhi
OpenArt AI generated image
“Queste sono le metriche della settimana scorsa, ragazzi”. “Sei sicuro papà?” “Sì, sono sicuro, controlla, figlio mio”. “Non hai fatto molto, vero?”. “Prego?” “Il tuo numero di foglietti è la metà di quello della mamma…”. “Fammi controllare…. sì, è così, ma…”. “… ma anche tu, papà, devi raggiungere la mamma!”. “Esatto, io devo raggiungere la mamma, tu devi raggiungere me, tutti noi dobbiamo raggiungere la mamma! Facciamo qualcosa questa settimana”. “Mi sembra giusto, prima tu per favore”. “Inizio prima io, naturalmente.” “Grazie papà”.
Questa conversazione e i personaggi in essa rappresentati sono puramente fittizi, al fine di spiegare il metodo Kanban ai lettori.
