lead time | Kanban & l'arte della Maratona

Pillole di Kanban: Il paradosso del pendolare e l’illusione delle vecchie metriche

Per anni, il mio viaggio in treno verso l’ufficio di un cliente è stato il mio laboratorio personale di Kanban. Avevo costruito una metrica di Lead Time estremamente affidabile, un set di dati consolidati che mi permetteva di calcolare al minuto l’istante esatto in cui uscire di casa per essere puntuale, senza sprecare un solo secondo. Era il trionfo della prevedibilità.

Poi, come per tutti, il mondo è cambiato. Tra la pandemia e un’evoluzione delle mie attività professionali, ho iniziato a usare quasi esclusivamente l’auto. Recentemente, però, ho avuto l’opportunità di tornare alle vecchie abitudini e riprendere il treno. Convinto della solidità della mia esperienza passata, ho ripreso in mano i miei vecchi dati. Mi sono fidato di quella ‘verità’ storica per pianificare il mio arrivo.

Mentre camminavo verso la mia destinazione finale, riflettendo sul fallimento della mia pianificazione, ho iniziato a concepire questo articolo. Mi sono reso conto di aver commesso lo stesso errore che spesso rimprovero alle aziende con cui collaboro: ho agito basandomi su metriche scadute in un sistema che non è più lo stesso.

L’invecchiamento delle metriche: quando i dati diventano il tuo rischio

Il mio errore non è stato di calcolo, ma di contesto. Quelle metriche, che anni prima garantivano la mia puntualità, erano diventate inutili, anzi, pericolose. Le ferrovie sono cambiate: l’infrastruttura è meno affidabile, i guasti più frequenti. Quel giorno, un imprevisto tecnico mi ha causato un ritardo di 15-20 minuti, mandando in fumo la mia pianificazione.

Come Kanban Coach, parlo spesso di stabilità del processo. Una metrica non è una verità ontologica; è una fotografia di un sistema in un determinato stato di equilibrio. Se il contesto muta, che sia per una crisi globale o per un degrado strutturale, la metrica subisce un processo di obsolescenza (Metric Decay). Usare il Lead Time del 2019 nel 2026 è come navigare una costa rocciosa usando una mappa del secolo scorso. Il territorio è cambiato, e lo schianto è quasi certo.

Mediocristan vs. Extremistan: comprendere la natura del mondo

Per navigare l’incertezza, dobbiamo capire in quale dominio stiamo operando. Nassim Taleb distingue tra Mediocristan, dove le fluttuazioni sono scarse e seguono una distribuzione Gaussiana, prevedibile. Ed Extremistan, il regno degli eventi estremi, dove un singolo evento può invalidare ogni previsione.

Senza metriche fresche e aggiornate, perdiamo la capacità di distinguere tra questi due mondi.

Se non so più quanto sia affidabile il treno, non posso più permettermi il lusso dell’efficienza. Sono costretto a un enorme dispendio di capacità residua: per essere sicuro di arrivare puntuale, dovrei partire un’ora prima. Questo è il costo economico del non sapere: senza dati, siamo costretti a un sovraccarico di precauzioni costante. Trattiamo ogni banale spostamento come se fosse un potenziale cigno nero, un evento catastrofico.

Costruire l’antifragilità: sopravvivere al caos per disaccoppiamento

Quando il sistema ferroviario ha fallito e le mie metriche sono saltate, ho cercato una via d’uscita. Ma ho scoperto che le soluzioni standard erano fragili quanto il treno stesso:

Taxi e Bus (sistemi dipendenti): erano entrambi paralizzati dal traffico urbano. Se la strada è bloccata, il taxi e l’autobus condividono lo stesso destino. In termini sistemici, le loro probabilità di fallimento sono correlate.
Andare a piedi (sistema antifragile/robusto): alla fine, ho scelto di camminare, anche se era la soluzione più lenta.

Camminare è una soluzione vincente perché è disaccoppiata dall’infrastruttura complessa. Non dipende dai segnali ferroviari, dai motori elettrici o dal traffico stradale. Mentre il taxi restava bloccato, la mia progressione costante a piedi non degradava con il fallimento del sistema circostante. In un mondo in cui non puoi misurare con precisione il Lead Time degli altri, l’unica strategia razionale è avere opzioni che non dipendano dalle fragilità altrui.

Conclusione: il costo del non sapere

Le metriche non servono solo a “misurare quanto siamo bravi”. Servono a definire la natura del mondo in cui stiamo operando. Se i tuoi dati sono obsoleti, non hai più una bussola: ogni fluttuazione statistica si trasforma in un evento da Extremistan che può travolgere la tua operatività.

Il costo di non avere metriche aggiornate è il tempo perso in cautele eccessive, o nel rischio di trovarsi a gestire l’imprevisto senza alcuna preparazione.

Vi lascio con una provocazione: siete sicuri che i dati che state usando oggi per guidare il vostro team non siano solo il ricordo di un sistema che non esiste più? Perché senza una metrica, ogni imprevisto è un caso di Extremistan.

Ho pubblicato originariamente questo articolo per il portale Kanban Help, al quale collaboro insieme al collega Luca Gambetti.
Visita Kanban Help – www.kanban.help – per conoscere gli strumenti formativi e di coaching che ti possono aiutare a introdurre il metodo Kanban nella tua azienda.

Anticipare o differire? Come leggere il proprio flusso per decidere al momento giusto

Nel management operativo si confrontano costantemente due impulsi opposti: agire subito per non farsi trovare impreparati, oppure aspettare per decidere con più informazioni. Entrambi gli impulsi sono razionali. Entrambi possono essere sbagliati.

Il metodo Kanban non sceglie dogmaticamente tra i due. In articoli precedenti abbiamo esplorato la logica del differimento – perché posticipare le decisioni è un vantaggio competitivo, come calcolare il Last Responsible Moment – e la logica dell’anticipazione – come la Teoria dei Vincoli protegge il collo di bottiglia, perché i buffer condivisi del Critical Chain reggono meglio dei margini individuali.

La domanda che questi articoli lasciano aperta è: come si sceglie tra le due strategie? La risposta non è di gusto, né di filosofia manageriale. È statistica. Dipende da come si comporta il flusso di lavoro della propria organizzazione e dalle caratteristiche del contesto in cui ci si trova ad operare.

Due logiche, entrambe valide, in contesti diversi

La Teoria dei Vincoli dice: identifica il collo di bottiglia, ottimizza il suo carico di lavoro, proteggilo con un buffer immediatamente a monte, sincronizza tutto il resto al suo ritmo. Come abbiamo visto nell’articolo sul Drum-Buffer-Rope, questa logica funziona bene quando il collo di bottiglia è stabile e identificabile.

Lean e Kanban dicono invece: non impegnarti finché non devi, tieni aperte le opzioni, usa il Last Responsible Moment come punto limite di impegno. Il differimento riduce il lavoro abortito, migliora la qualità delle decisioni, libera capacità per le urgenze reali.

Il Critical Chain Project Management – che abbiamo esplorato di recente – trova una sintesi parziale: elimina i buffer individuali (fonte di spreco) e li aggrega in buffer condivisi di progetto, che vengono però allocati in anticipo. È anticipazione al servizio del sistema, non del singolo elemento di lavoro.

Queste logiche non si contraddicono: operano bene in domini diversi. Il problema è che molte organizzazioni applicano l’una o l’altra per abitudine, senza chiedersi quale sia appropriata al loro contesto specifico.

Il criterio: leggere la distribuzione del Lead Time

Nell’articolo sulla gestione proattiva dei rischi abbiamo introdotto la distinzione di Nassim Taleb tra Mediocristan ed Extremistan come modello di riferimento per classificare il rischio organizzativo. Quella distinzione diventa qui uno strumento operativo per la scelta strategica tra anticipazione e differimento.

Mediocristan è il dominio in cui le distribuzioni sono gaussiane o super-esponenziali (thin-tail): la media è significativa, la variabilità è contenuta entro limiti prevedibili, gli eventi estremi sono rari e di impatto limitato. Tecnicamente, il rapporto tra il valore di coda e la mediana è inferiore a 5.6. In questo dominio la Legge di Little funziona come strumento previsionale affidabile – a patto di avere almeno 70-100 punti dati per validare il tipo di distribuzione.

In Mediocristan l’anticipazione è una copertura legittima del rischio. I buffer della Teoria dei Vincoli hanno senso, la Critical Chain funziona, le scadenze fisse sono gestibili perché la distribuzione dei tempi di completamento è prevedibile. Impegnarsi in anticipo non è una scommessa: è una protezione calcolata.

Extremistan è il dominio delle distribuzioni a coda lunga (fat-tail), dove la variabilità non è contenuta e gli eventi estremi sono frequenti e di impatto sproporzionato. Il rapporto coda/mediana supera 5.6: un singolo elemento di lavoro può durare 10 o 100 volte la mediana, e la media non rappresenta nulla di utile.

In Extremistan anticipare è pericoloso. Chi pianifica su una media che non rappresenta la distribuzione reale si espone sistematicamente ai cosiddetti Cigni Neri: eventi nella coda lunga che distruggono le previsioni e con esse la fiducia del cliente. La strategia corretta è il differimento estremo: mantenere l’opzionalità il più a lungo possibile, impegnarsi solo quando l’incertezza si è sufficientemente ridotta.

Lo strumento diagnostico è già a disposizione di qualsiasi organizzazione che misuri i propri Lead Time: l’istogramma della distribuzione. Una distribuzione con una coda lunga e asimmetrica verso destra – magari con un picco visibile tra il corpo principale e pochi valori anomali molto distanti – è il segnale che si opera in Extremistan. Una distribuzione più compatta e simmetrica indica Mediocristan. Prima di scegliere la strategia, bisogna guardare la forma della curva e il rapporto coda/mediana.

Il principale motore che spinge un flusso verso Extremistan sono le dipendenze esterne: fornitori, approvazioni regolamentari, decisioni di terze parti. Una singola dipendenza esterna non governata può allungare la coda in modo molto significativo. In questi casi i sistemi di prenotazione (Reservation Systems) sono lo strumento per mitigare il rischio di coda senza rinunciare all’opzionalità.

Le implicazioni per le Classi di Servizio

La distinzione Mediocristan/Extremistan non è solo teorica: cambia concretamente il significato del triage e le sue politiche per ciascuna classe di servizio.

Le classi Expedite e Fixed Date funzionano nel Mediocristan, dove la scadenza ha un fondamento statistico. La data fissa è gestibile perché la distribuzione dei tempi di completamento è prevedibile; la classe Expedite indica un’urgenza reale perché il costo del ritardo cresce in modo identificabile. In Extremistan, una Fixed Date è spesso una scommessa: si fissa una data attesa senza sapere se la distribuzione dei tempi di completamento permetterà di rispettarla. Tra una data attesa e una data prevista c’è una grande differenza. L’urgenza Expedite rischia di diventare la norma, non l’eccezione.

La classe Standard segue il Last Responsible Moment in entrambi i domini, ma con una differenza critica: il calcolo del 50° percentile è significativo solo in Mediocristan, dove la mediana è stabile e rappresentativa. In Extremistan la mediana stessa può essere instabile con campioni ridotti.

La classe Intangible diventa il rifugio naturale per gli elementi di lavoro in Extremistan: si entra nel flusso solo quando l’incertezza è scesa a un livello gestibile, trattando il lavoro come opzione reale fino a quel momento. È la classe che meglio preserva l’opzionalità in condizioni di alta variabilità.

La maturità organizzativa come percorso verso la scelta consapevole

Il Kanban Maturity Model (KMM) descrive un percorso di evoluzione organizzativa che è anche, in questo contesto, un percorso verso la capacità di scegliere consapevolmente tra anticipazione e differimento.

Nelle organizzazioni che si affacciano per la prima volta alla gestione del flusso, la misurazione sistematica del Lead Time è assente o sporadica. Non si ha nemmeno l’istogramma per capire in quale dominio si opera. La scelta tra anticipazione e differimento è inconsapevole: si anticipa per ansia, si differisce per inerzia, senza un criterio. L’urgenza Expedite è endemica perché nessuno ha mai separato le urgenze vere dalle urgenze percepite.

Man mano che l’organizzazione matura – introducendo limiti al lavoro in corso, misurando i Lead Time, stabilizzando il flusso – emerge la capacità di leggere la distribuzione. A quel punto la scelta diventa informata: si può identificare se si opera in Mediocristan o Extremistan, applicare la politica di triage appropriata, calcolare il Last Responsible Moment con basi statistiche solide.

Le organizzazioni più mature compiono un passo ulteriore: lavorano attivamente per spostare il proprio flusso verso Mediocristan attraverso il trimming della coda – l’eliminazione sistematica dei valori anomali che allungano la distribuzione. La resilienza non si costruisce accettando la coda lunga come un dato di fatto: si costruisce attrezzando il sistema per identificarla e ridurla. A quel livello, l’anticipazione diventa possibile su basi sempre più ampie.

Il Two-Phase Commit come sintesi pratica

Come convivere con entrambe le logiche in un sistema reale? La risposta operativa è la separazione dell’impegno in due fasi distinte – un concetto introdotto nell’articolo sul Last Responsible Moment e che trova qui la sua collocazione strategica più ampia.

La prima fase – l’impegno a fare il lavoro – è possibile in entrambi i domini. L’organizzazione accetta la richiesta e la inserisce nel flusso, garantendo al cliente che il lavoro verrà fatto. Questo impegno non dipende dalla prevedibilità della distribuzione.

La seconda fase – l’impegno su una data di consegna specifica – è affidabile solo in Mediocristan, o quando un elemento di lavoro in Extremistan ha percorso abbastanza strada all’interno del flusso da uscire dalla coda lunga e diventare più prevedibile. Dare una data prima di questo punto non è trasparenza verso il cliente: è una scommessa che si scarica sul cliente stesso quando la previsione fallisce.

Questa separazione è la risposta concreta alla domanda di apertura. Non si tratta di scegliere una volta per tutte tra anticipazione e differimento: si tratta di applicare la logica giusta al momento giusto, su basi statistiche, con la consapevolezza di quale dominio si sta attraversando.

Gestire l’incertezza nei progetti: come il Critical Chain Project Management supporta il metodo Kanban

Chi lavora con il metodo Kanban impara presto a gestire il flusso: visualizza il lavoro, limita il WIP, misura il lead time. Quando il lavoro si fa più complesso – progetti con scadenze fisse, risorse condivise tra più attività e dipendenze articolate – è utile affiancare anche il Critical Chain Project Management (CCPM).

Sviluppato da Eliyahu M. Goldratt, il padre della Teoria dei Vincoli, il CCPM parte da una domanda scomoda: perché, nonostante pianificazioni meticolose e stime prudenti, i progetti finiscono quasi sempre in ritardo? La risposta di Goldratt ribalta alcune delle convinzioni più radicate su come gestiamo il tempo e le risorse – e per chi lavora con Kanban, più di un punto risulterà familiare.

La vera causa dei ritardi: non le attività, ma le risorse

La gestione dei progetti tradizionale, basata sul Metodo del Percorso Critico (CPM), si concentra esclusivamente sulla sequenza di attività più lunga per determinare la durata del progetto. L’innovazione fondamentale del CCPM è identificare, invece, la Catena Critica: la sequenza più lunga che considera sia le dipendenze tra i compiti sia le limitazioni delle risorse.

Questo è un cambio di prospettiva radicale. Il vero collo di bottiglia che determina la durata di un progetto non è quasi mai la lista delle cose da fare, ma una persona, un team o un’attrezzatura specifica condivisa tra più attività.

Per capire la differenza, immaginiamo un progetto semplice. Due attività possono partire in parallelo dopo una fase iniziale comune, ma richiedono entrambe la stessa risorsa critica: l’ingegnere capo. Il Metodo del Percorso Critico non vedrebbe problemi, ma il CCPM riconosce subito che le due attività non possono avvenire contemporaneamente. La vera sequenza più lunga – la Catena Critica – deve quindi includere la scelta di quale attività fare prima, rivelando un vincolo che altrimenti resterebbe invisibile fino al momento dell’esecuzione.

L’illusione della sicurezza: come i margini individuali rallentano tutto

L’idea controintuitiva più potente del CCPM riguarda i margini di sicurezza. Tradizionalmente, ogni membro del team aggiunge un margine di tempo alla stima di ogni singola attività per proteggersi dagli imprevisti. Fred, uno dei personaggi del romanzo Critical Chain di Goldratt, porta dati reali della sua azienda: quasi metà delle attività finisce esattamente alla scadenza, pochissime finiscono prima, e circa un terzo finisce con un 10-20% di ritardo rispetto alla stima originale. La sua conclusione è che il margine di sicurezza individuale non protegge né il singolo step né il progetto nel suo insieme.

Questa tolleranza incoraggia comportamenti controproducenti. La sindrome dello studente – termine coniato da Goldratt – descrive il meccanismo per cui, avendo tempo a disposizione, si procrastina fino all’ultimo: quando si inizia a lavorare, il cuscinetto è già stato consumato, e l’attività finisce comunque in ritardo. A questo si aggiunge la Legge di Parkinson: il lavoro si espande fino a occupare tutto il tempo disponibile.

Il CCPM elimina questi margini individuali nascosti. Le stime delle attività diventano più aggressive, basate sul tempo effettivamente necessario per completarle. La sicurezza rimossa viene aggregata e resa esplicita in “buffer” condivisi che proteggono l’intero progetto:

Project Buffer: posto alla fine della catena critica per proteggere la data di consegna finale dall’incertezza accumulata.
Feeding Buffer: inseriti dove le catene di attività secondarie si collegano alla catena critica, per evitare che i ritardi su percorsi non critici impattino su quello principale.
Resource Buffer: utilizzati per garantire che le risorse critiche siano pronte e disponibili esattamente nel momento in cui sono necessarie.

Questo approccio trasforma l’incertezza da un problema individuale a una responsabilità collettiva.

La figura mostra un esempio di rete CCPM. La catena critica – in giallo – segue il percorso A→C→E→F→H. Due percorsi non critici convergono su di essa: il primo attraverso B e D, che si aggancia in H tramite feeding buffer; il secondo attraverso G e I, che si aggancia in F tramite feeding buffer. Il project buffer finale protegge la data di consegna dall’incertezza accumulata sull’intero progetto.

La psicologia del progetto efficace: il project multitasking come causa sistemica dei ritardi

Il CCPM scoraggia attivamente il multitasking, e non si riferisce solo all’abitudine individuale di saltare da un compito all’altro. La forma più dannosa è quella organizzativa: aprire troppi progetti in contemporanea. È una dinamica comune – ogni progetto sembra urgente al momento dell’approvazione, il portfolio cresce, le stesse risorse critiche vengono distribuite su tutto. Il risultato è che nessun progetto avanza davvero, perché ogni risorsa chiave è costantemente interrotta, richiamata, riassegnata.

Goldratt dimostra questo con un esempio quantitativo: una persona che lavora in multitasking su tre attività da dieci giorni ciascuna, alternandosi ogni cinque giorni, vede il Lead Time di ognuna raddoppiare – e questo senza considerare il tempo perso nei cambi di contesto. Il meccanismo diventa poi sistemico: più progetti aperti allungano i Lead Time, Lead Time più lunghi significano più progetti in corso contemporaneamente, e il ciclo si autoalimenta. Goldratt lo definisce esplicitamente “il principale killer del Lead Time”.

La soluzione proposta è controintuitiva: aprire meno progetti contemporaneamente. Non per fare meno, ma per finire di più – perché le risorse critiche possono finalmente completare un lavoro prima di passare al successivo. Chi conosce il metodo Kanban riconoscerà qui la logica dei WIP limit: ridurre il lavoro in corso non è una limitazione, ma la condizione che rende stabile il flusso.

La figura mostra l’effetto in modo immediato: lavorare sulle attività di tre progetti in parallelo raddoppia il lead time di ciascuno. Lo stesso principio del WIP limit si applica sia alle singole attività, che ai progetti presenti nel portfolio.

Un nuovo modo di misurare: non le scadenze, ma il consumo del buffer

Nel project management tradizionale, la domanda chiave è: “Siamo in linea con la tabella di marcia?”. Nel CCPM diventa: “Quanta parte del nostro buffer abbiamo consumato rispetto ai progressi fatti?”.

Per rispondere, il CCPM introduce il Fever Chart (“grafico della febbre”): un grafico che mette in relazione la percentuale di completamento della catena critica con la percentuale di buffer consumato. Le tre zone (verde, gialla e rossa) funzionano come un termometro. La sua forza è predittiva: trovarsi nella zona gialla non significa che il progetto è in ritardo, ma che il rischio di un futuro ritardo è aumentato. Un approccio familiare a chi usa le metriche di flusso del Kanban, come i CFD: anche lì l’obiettivo è anticipare i problemi, non certificare i ritardi.

Il Fever Chart mette in relazione l’avanzamento del progetto con il consumo del project buffer. La curva bianca mostra l’andamento reale: nel nostro esempio il progetto entra in zona rossa nella prima metà, per poi rientrare in zona gialla verso la fine – uno strumento predittivo che non certifica i ritardi, ma li anticipa in tempo utile per intervenire.

Risultati concreti: cosa dicono i casi reali

Il CCPM non è un esperimento accademico. La NASA lo ha utilizzato per gestire le gallerie del vento al Langley Research Center, riuscendo a mantenere il volume di test nonostante un taglio del 50% del personale. Procter & Gamble Pharmaceuticals lo ha adottato nel 2004 per gestire un aumento del carico di lavoro senza risorse aggiuntive, riducendo i tempi di ciclo nei trial clinici. In letteratura le riduzioni documentate delle durate di progetto vanno dal 20% al 40% rispetto ai metodi tradizionali.

Conclusione

Il CCPM è molto più di una tecnica di pianificazione: è una filosofia manageriale che rende l’incertezza visibile, misurabile e gestibile. La vera sfida non è tecnica ma culturale: rinunciare alla protezione individuale per contribuire a una riserva comune. È un cambio di mentalità che richiede fiducia nel sistema – e nella capacità collettiva di tenere insieme ciò che il lavoro individuale tende a frammentare.

Bibliografia

Eliyahu M. Goldratt, Critical Chain, Gower Publishing, 1997.
Andrew G. Hagemann, Use of the Critical Chain Project Management Technique at NASA Langley Research Center, 20th Digital Avionics Systems Conference (DASC), IEEE, 2001.
Michelle Smith, CCPM: A Sustaining Strategy at Procter & Gamble Pharmaceuticals, Pharmaceutical Processing World, 2004.

L’arte del timing strategico: l’importanza del Last Responsible Moment (LRM) nell’impresa resiliente

Nel panorama della gestione organizzativa moderna, l’ossessione per la velocità ha spesso oscurato la qualità del processo decisionale. Tuttavia, nel quadro del Kanban Maturity Model (KMM), la vera agilità non risiede nel decidere il più velocemente possibile, ma nel decidere al momento giusto. Il concetto di Last Responsible Moment (LRM) emerge non come una forma di procrastinazione, ma come una scelta strategica di gestione del rischio economico.

In un contesto caratterizzato da incertezza e complessità, decidere troppo presto è un errore pari a quello di decidere troppo tardi: impegna risorse preziose su basi informative incomplete, precludendo la possibilità di adattarsi a nuovi dati. L’LRM invece rappresenta il punto immediatamente precedente alla perdita di fattibilità di un’opzione. Comprendere l’LRM è il primo passo per evolvere da una cultura dell’urgenza reattiva a una gestione proattiva del flusso, dove il tempo è una variabile economica controllata e non un nemico da rincorrere.

La logica del differimento: perché “aspettare” è un vantaggio competitivo

Il differimento dell’impegno (deferred commitment) è una delle pratiche più controintuitive dell’enterprise agility. Permettere a un elemento di lavoro di rimanere nello stato di opzione il più a lungo possibile riduce drasticamente l’impatto della failure demand, ovvero il lavoro abortito e i rifacimenti (rework). Da un punto di vista del senior management, differire l’impegno significa mantenere maggiore liquidità del sistema – capacità produttiva non ancora congelata in scommesse premature, e quindi disponibile per essere allocata quando le informazioni sono più complete.

I tre benefici strategici del differimento dell’impegno sono:

Acquisizione di conoscenza: più a lungo si attende, più informazioni si raccolgono su mercato, tecnologie ed esigenze reali dei clienti.
Riduzione dell’incertezza: il tempo permette di dissipare l’incertezza decisionale, trasformando intuizioni rischiose in decisioni basate su evidenze.
Aumento del tasso di scarto delle opzioni non valide: un sistema che differisce l’impegno seleziona solo le opzioni che sopravvivono all’evoluzione del contesto, eliminando lo spreco alla radice.

Fonte Kanban University – dettaglio del poster Triage Tables

Anatomia matematica del Last Responsible Moment e del rischio temporale

L’LRM non è un’intuizione soggettiva, ma un calcolo basato sulla distribuzione statistica dei tempi di completamento (Lead Time). In un sistema evoluto, la determinazione del momento in cui iniziare un lavoro dipende dalla data di consegna desiderata (Desired Delivery Date – DDD) e dalla probabilità di completamento entro quella data.

Operativamente, l’LRM è definito come il 50° percentile del Lead Time calcolato a ritroso rispetto alla DDD. Iniziare un lavoro esattamente al LRM significa che, in base alla distribuzione storica dei tempi di consegna (Lead Time), c’è solo una possibilità su due (50%) di consegnare entro la data desiderata (DDD). Per le organizzazioni a ML2/ML3, questo rappresenta il punto di equilibrio tra rischio di consegna tardiva e costo del ritardo.

Concetto	Definizione operativa	Implicazione economica
Last Responsible Moment	Decisione consapevole basata sul 50° percentile della distribuzione del Lead Time.	Rischio gestito: equilibrio tra informazione acquisita, Cost of Delay e probabilità di consegna puntuale.
Irresponsibly Late	Decisione presa oltre la finestra di confidenza statistica.	Scommessa probabilistica: l’organizzazione subisce le conseguenze di un eventuale fallimento invece di gestire il rischio.

Un pilastro tecnico fondamentale è l’Urgenza, definita come la derivata (pendenza) della funzione Probable Cost of Delay in Starting (PCoDS). Senza entrare in tecnicismi matematici, la PCoDS è una curva che indica il rischio economico immediato derivante dal non iniziare un lavoro in una data specifica.

Il Last Responsible Moment e la disciplina del triage: ora, dopo, mai

L’integrazione dell’LRM trasforma il Replenishment Meeting in un processo di triage rigoroso. Basandoci sulla valutazione delle opzioni reali, comprendiamo che queste hanno valore e hanno una scadenza; pertanto, non si deve mai decidere in anticipo senza un motivo esplicito.

Il triage categorizza il lavoro in tre direzioni:

Ora: elementi che hanno raggiunto il proprio LRM e devono essere messi in lavorazione per onorare la promessa di consegna.
Dopo: opzioni che non hanno ancora raggiunto l’LRM e restano in attesa perché si possa acquisire ulteriore conoscenza relativa alla loro lavorazione.
Mai: opzioni scartate perché superate da nuove informazioni.

Questa logica di triage è applicabile esclusivamente a opzioni per le quali i dati storici sono significativi. Se il valore dell’opzione è incerto o imprevedibile l’LRM perde di efficacia e l’elemento deve essere gestito tramite allocazione di capacità dedicata come classe Intangible.

Il compromesso strategico: Classi di Servizio e Costo del Ritardo

Differire l’impegno fino all’LRM comporta un trade-off. Se si attende troppo vicino al limite, il sistema viene caricato di rischi temporali che possono richiedere classi di servizio costose per garantire la consegna.

Le quattro classi di servizio canoniche riflettono la sensibilità al tempo e alla PCoDS:

Expedite: per elementi con urgenza critica e pendenza della PCoDS altissima. Richiedono un intervento immediato, spesso violando i limiti al lavoro in corso (WIP).
Fixed Date: elementi con data di consegna fissa e costo elevato per il superamento della scadenza. Richiedono impegno vicino all’LRM con priorità di pianificazione alta.
Standard: il cuore del sistema, gestito solitamente tramite logica FIFO (First-In, First-Out) per garantire massima prevedibilità e stabilità del Lead Time.
Intangible: elementi con basso costo del ritardo immediato ma alto valore a lungo termine. Fungono da protezione rispetto al rischio strategico: la loro presenza nel sistema crea lo spazio necessario per assorbire le richieste Expedite senza destabilizzare il flusso.

Evoluzione organizzativa: dal caos alla resilienza

La padronanza dell’LRM evolve man mano che le organizzazioni si strutturano:

ML2 (Customer Awareness): le decisioni sono spesso emotive o reattive. Il Flow Manager inizia a raccogliere dati, ma la mancanza di stabilità rende il calcolo dell’LRM ancora approssimativo.
ML3 (Fit-for-Purpose): emergono i ruoli chiave. Il Service Request Manager (SRM) diventa il custode delle opzioni e dell’LRM, mentre il Service Delivery Manager (SDM) garantisce la stabilità della capacità del sistema. Il triage diventa sistematico.
ML4 (Risk-Hedged): l’LRM non è più una stima generale al 50° percentile, ma un calcolo specifico per ogni elemento di lavoro ad alto valore, basato su simulazioni Monte Carlo e profili PCoDS personalizzati.

Conclusione: il Last Responsible Moment come pilastro della prosperità aziendale

Il Last Responsible Moment non è un tecnicismo, ma il fondamento della resilienza strategica. La sua applicazione sposta l’attenzione dalla mera efficienza delle risorse (tenere le persone occupate) alla efficienza di flusso e alla resilienza economica.

Il traguardo finale di questa disciplina è l’allineamento tra identità aziendale, strategia (perché/cosa) e decisioni operative quotidiane (come/chi). Quando un’organizzazione sa perché decide e quando è il momento di farlo, smette di subire il mercato e inizia a guidarlo.

La leadership dell’organizzazione deve investire nella raccolta rigorosa dei dati sui Lead Time e nella modellizzazione dei costi del ritardo. Solo trasformando l’LRM da concetto astratto a strumento guidato dai dati, l’organizzazione potrà prosperare a lungo termine in un mondo volatile.

Metriche di flusso: cosa misuriamo davvero quando misuriamo la produttività?

In molte organizzazioni, quando si parla di produttività degli uffici, si parte da un’intuizione apparentemente ragionevole: se le persone sono occupate, il lavoro avanza. Se le ore registrate aumentano, la produttività aumenta. Peccato che questa logica, portata alla prova dei dati, si riveli quasi sempre sbagliata.

Il problema dell’effort

Misurare le ore di lavoro – l’effort – dice quanto tempo le persone hanno dedicato a qualcosa. Non dice quanto lavoro è stato effettivamente completato. Sono due cose diverse, e confonderle genera decisioni sbagliate.

Un ufficio che gestisce pratiche amministrative può essere pieno di persone impegnate tutto il giorno, eppure produrre meno output di un ufficio più snello e meno saturo. Il motivo è semplice: quando le persone sono troppo occupate, il sistema si inceppa alla minima perturbazione – una richiesta urgente, un’assenza, una dipendenza esterna. Il lavoro si accumula, i tempi si allungano, e nessuno capisce esattamente perché.

La misura che conta, invece, è il Throughput: quante pratiche vengono effettivamente completate in un dato periodo. Registrazioni, contratti, acquisti, variazioni – qualsiasi cosa rappresenti un’unità di lavoro conclusa. Se il Throughput aumenta a parità di organico, la produttività sta crescendo. Non ci sono interpretazioni: è un dato empirico, diretto, semplice da raccogliere.

Livelli di servizio: sapere non basta, bisogna collegare

Una volta che si inizia a misurare il Throughput, emerge naturalmente una seconda domanda: in quanto tempo completiamo le pratiche? È qui che entrano in gioco i Service Level Agreement (SLA), ovvero gli impegni misurabili che un ufficio può comunicare ai propri interlocutori interni ed esterni.

Un esempio concreto: l’ottantacinquesimo percentile dei Lead Time è di 15 giorni. Che in termini semplici significa: l’85% delle richieste di un determinato servizio viene gestito entro 15 giorni. È un dato reale, ricavato dai sistemi in uso, ma da solo non dice ancora nulla di utile. La domanda che conta non è “è tanto o è poco?”, ma: qual è l’impatto reale sull’organizzazione se questi tempi restano invariati, si allungano, o si accorciano?

Senza questa misura di impatto, qualsiasi target è arbitrario. Fissare un obiettivo di 8 giorni invece di 15 potrebbe essere un miglioramento significativo o uno spreco di risorse, dipende da cosa succede a valle. Finché non colleghiamo le metriche operative alle conseguenze organizzative, stiamo ottimizzando nel vuoto.

Questo è il nodo: spesso non è che manchino i dati. Manca il collegamento tra i dati e le decisioni.

Gestire i picchi con i dati storici

Molte organizzazioni di servizio, e anche molti uffici amministrativi, vivono di stagionalità: certi periodi dell’anno concentrano volumi di lavoro molto superiori alla media. Pensate per esempio un ufficio paghe: avrà dei picchi di lavoro da evadere in corrispondenza di ogni fine mese.

Il modo tradizionale di gestire questi picchi è reattivo: si aspetta che il sistema si inceppi, poi si aggiunge personale o si fanno straordinari. Il modo alternativo è usare i dati storici per anticipare i picchi e attivare risorse aggiuntive – interne o esterne – solo quando e dove servono davvero. Una capacità extra controllata invece di un’emergenza ricorrente.

Capacity planning: vedere la coperta prima che sia troppo corta

Quando un ufficio gestisce attività diverse, la sfida non è solo fare di più, ma bilanciare. La coperta è sempre potenzialmente corta, e senza una mappa dell’allocazione reale delle risorse è impossibile sapere dove concentrare l’attenzione.

La settimana tipo è uno strumento semplice: si mappa come viene effettivamente distribuito il tempo del team tra le diverse categorie di attività, e si confronta questa distribuzione con i volumi di lavoro in arrivo. Questo confronto rende visibili i colli di bottiglia prima che diventino crisi, e permette di spostare risorse in modo consapevole invece di rincorrere le urgenze.

Ho diffusamente parlato di questa pratica in un’articolo al quale rimando per gli approfondimenti.

Il lavoro sommerso

C’è un ultimo problema, forse il più sottovalutato: il lavoro invisibile. In ogni ufficio esiste una quota significativa di attività che non viene tracciata – richieste gestite via email, richieste urgenti, eccezioni, supporto informale. Questo lavoro sommerso consuma capacità reale, ma non appare in nessuna metrica. Risultato: le analisi partono da dati incompleti, e le decisioni che ne derivano sono distorte.

La soluzione non è burocratizzare ogni attività, ma rendere visibile almeno la massa del lavoro sommerso – anche in modo aggregato – per avere una visione sistemica e bilanciata della situazione.

Le cadenze: dove avviene il vero miglioramento

Tutto questo – throughput, SLA, capacity planning, visibilità sul lavoro sommerso – è necessario ma non sufficiente. Le metriche contano solo se vengono usate con regolarità per fare domande precise: cosa sta cambiando? Cosa proviamo a migliorare? Come misuriamo se l’intervento ha funzionato?

Questo è il principio del miglioramento continuo: non un progetto straordinario, ma un meccanismo ordinario. Si fissa una cadenza di revisione – settimanale, bisettimanale, mensile – si guardano i dati, si formula un’ipotesi di miglioramento, si prova, si misura l’effetto. Se funziona, si consolida nel metodo. Se non funziona, si cambia strada.

È un metodo forse noioso da farsi, ma sorprendentemente foriero di risultati nel tempo.

In sintesi

Cosa misurare	Perché
Throughput	Misura il lavoro realmente completato, non l’occupazione di tempo
Lead time / SLA	Permette di prendere impegni misurabili con gli interlocutori interni ed esterni
Distribuzione per attività	Rende visibili i colli di bottiglia e bilancia i carichi
Volume storico	Permette di anticipare i picchi invece di subirli
Cadenze di revisione	Trasforma i dati in decisioni e iniziative di miglioramento continuo

Nessuno di questi strumenti richiede tecnologie complesse. Richiedono disciplina, continuità, e la disponibilità a prendere decisioni basate sui dati invece che sulle sensazioni. Il metodo Kanban offre esattamente questo: un sistema di pratiche, cadenze e metriche progettato per rendere tutto ciò ordinario – non un progetto straordinario, ma il modo normale di lavorare.

Un’ultima cosa: non è una questione di settore

C’è una storia che vale la pena raccontare, perché smonta un alibi molto comune.

Toyota è oggi il produttore di auto più grande al mondo. Produce 2 milioni di auto in più rispetto a Volkswagen (11 milioni circa contro 9 milioni circa), con circa la metà del personale. Non è successo perché fanno auto, perché sono giapponesi, o perché hanno avuto accesso a tecnologie particolari. È successo perché hanno applicato per più di settant’anni con rigore e continuità il metodo scientifico ai propri processi: osservare, misurare, formulare un’ipotesi, sperimentare, misurare di nuovo. Consolidare ciò che funziona, abbandonare ciò che non funziona. Ricominciare.

Chi dice “da noi non funzionerebbe, il nostro settore è diverso” di solito non sta descrivendo una realtà, sta descrivendo una resistenza. Il metodo scientifico non conosce settori. Funziona dove si è disposti a guardare i dati e a cambiare idea quando i dati lo chiedono.

Un ufficio amministrativo o una organizzazione di servizi non è una fabbrica di automobili. Ma le domande sono le stesse: quanto lavoro stiamo completando? In quanto tempo? Dove si accumula? Cosa succede se cambiamo qualcosa? La differenza tra chi migliora e chi resta fermo non è mai nella complessità degli strumenti, è nella disponibilità a fare quelle domande ogni settimana, senza mai smettere.

Perché vediamo solo quello che facciamo noi

C’è un esperimento mentale che mi piace proporre durante i workshop. Immagina due persone che dividono un compito al cinquanta per cento. Per metà del tempo lavorano insieme, visibili l’una all’altra. Per l’altra metà, ciascuna lavora per conto proprio, fuori dalla vista dell’altra. Dopo qualche ora, chiedi a entrambe quanto pensano di aver contribuito.

La risposta, quasi invariabilmente, è di avere lavorato il doppio dell’altra persona.

Due terzi ciascuna. Il cento per cento sommato fa centotrenta. Qualcosa non torna, eppure entrambe sono convinte della propria stima.

Non si tratta di malafede. Si tratta di come funziona il nostro cervello.

WYSIATI: quello che vedi è tutto quello che c’è

Daniel Kahneman, nel suo lavoro sulla cognizione e le decisioni umane, ha descritto con precisione il meccanismo alla base di questa distorsione. Lo ha sintetizzato con l’acronimo WYSIATI – What You See Is All There Is: quello che Kahneman chiama il Sistema 1 del nostro cervello, quello veloce e automatico, costruisce la propria narrativa esclusivamente a partire dalle informazioni disponibili, senza rendersi conto di ciò che manca. Non considera i “known unknowns” – le cose che sa di non sapere – e men che meno gli “unknown unknowns” – le cose che non sa di non sapere. Si limita a costruire la storia più coerente possibile con quello che ha davanti, e la tratta come se fosse completa.

Uno dei meccanismi con cui WYSIATI si manifesta concretamente è l’euristica della disponibilità: tendiamo a giudicare la probabilità o l’importanza di qualcosa in base a quanto facilmente riusciamo a richiamarla alla mente. Non in base a dati oggettivi, non in base a frequenze reali, ma in base alla facilità di accesso all’informazione.

Gli incidenti aerei fanno notizia. I voli sicuri no. Risultato: sovrastimiamo drammaticamente la pericolosità dell’aereo rispetto all’automobile, anche quando i numeri dicono l’esatto contrario. I divorzi tra attori e attrici ci sembrano frequentissimi, perché ne sentiamo parlare spesso. I divorzi tra idraulici ci sembrano rari, perché non fanno notizia. Eppure le statistiche reali raccontano una storia molto diversa.

Il problema si manifesta ogni giorno, nei team

Torniamo all’esperimento delle due persone. Perché ciascuna si attribuisce due terzi del lavoro?

Perché il proprio contributo è sempre visibile a sé stessi – si ricorda ogni singola attività svolta, ogni problema risolto, ogni ora investita. Il contributo dell’altro, invece, è parzialmente invisibile: si vede solo la metà del tempo trascorsa insieme. L’altra metà, quella in cui l’altro ha lavorato da solo, è semplicemente assente dalla propria esperienza.

L’euristica della disponibilità fa il resto: ciò che non si vede non viene pesato. Ciò che si vede viene sovrastimato.

Questo non è un problema teorico. È la fonte di una quota enorme di attriti nei team di lavoro. “Faccio tutto io.” “Nessuno si accorge di quanto mi impegno.” “Gli altri non contribuiscono quanto dovrebbero.” Queste frasi non nascono necessariamente da egocentrismo o da conflitto: nascono da una distorsione cognitiva sistematica, condivisa da tutti i membri del team, ciascuno convinto, in buona fede, di fare di più degli altri.

Lo stesso meccanismo si ripete nelle relazioni personali, nei progetti interfunzionali, nelle collaborazioni tra reparti. Ogni volta che una parte del lavoro è invisibile, la percezione si distorce.

La soluzione non è solo lavorare di più sulla cultura

La risposta istintiva a questi problemi è spesso di tipo culturale: migliorare la comunicazione, costruire fiducia, lavorare sull’empatia. Tutte cose valide, ma non sufficienti se si ignorano le radici cognitive del problema.

Se il problema è che il cervello non elabora ciò che non vede, la soluzione non può essere solo culturale. Deve essere strutturale: rendere visibile ciò che altrimenti non lo è.

Visualizzare il lavoro non è un esercizio estetico. Non è una questione di bacheche colorate o di post-it ordinati. È un atto cognitivo: portare nel campo percettivo di tutti le informazioni che altrimenti resterebbero inaccessibili e quindi, secondo WYSIATI, inesistenti.

Una Kanban board, nella sua forma più semplice come nella sua versione più sofisticata, fa esattamente questo: rende esplicito chi fa cosa, in quale stato si trova ogni attività, e – se ben configurata – quanto lavoro è in corso contemporaneamente. Quando il flusso è visibile per tutti, le distorsioni della disponibilità si riducono. Non si discute più di percezioni, si discute di fatti condivisi.

Misurare chiude il cerchio

La visualizzazione, da sola, non basta. Perché anche una board ben costruita mostra solo uno snapshot: il presente, o al massimo il recente passato. Per ragionare su tendenze, capacità, colli di bottiglia, distribuzione reale del carico, serve misurare.

La misurazione trasforma le osservazioni qualitative in dati confrontabili. Strumenti come il Cumulative Flow Diagram mostrano come il lavoro si accumula o scorre nel tempo, rendendo visibili i blocchi sistemici che la percezione quotidiana tende a normalizzare. Metriche come il Lead Time e il Throughput permettono di rispondere a domande che l’intuizione non può risolvere: quanto tempo passa un’attività in attesa? Dove si accumula il lavoro? Chi o cosa è sistematicamente sottovalutato?

Senza misura, anche i team più collaborativi continuano a navigare a vista. E la navigazione a vista, come Kahneman ha dimostrato in decenni di ricerca, favorisce sempre le distorsioni cognitive rispetto alla realtà.

Non si tratta di sorvegliare. Si tratta di vedere.

Vale la pena essere chiari su un punto: visualizzare e misurare non significa sorvegliare le persone. Non significa costruire un sistema di valutazione delle performance individuali basato su metriche. Significa dare a tutti – al team nel suo insieme – una visione condivisa della realtà.

Quando il lavoro è visibile, la conversazione cambia registro. Si passa dal “secondo me” al “secondo i dati”. Si passa dall’attribuzione soggettiva del merito alla comprensione sistemica di come fluisce il lavoro. Si passa, in ultima analisi, dalla difesa della propria percezione alla collaborazione intorno a una percezione comune.

L’euristica della disponibilità non si elimina. È cablata nel nostro modo di pensare, e Kahneman è stato il primo a sperimentare che anche chi conosce le distorsioni cognitive non ne è immune. Ma si può progettare il proprio ambiente di lavoro in modo che le informazioni rilevanti siano sempre disponibili – non solo quelle che capitano sotto gli occhi di chi fa il proprio pezzo di compito nell’angolo della stanza.

Il cervello vede solo quello che ha davanti. Il nostro compito, come team e come organizzazioni, è decidere con cura cosa mettere davanti al cervello.

Controllare la prevedibilità e la qualità per migliorare i risultati aziendali

Lo scorso 23 luglio ho tenuto un webinar, all’interno della nuova serie dedicata ai Kanban Basics, frutto di una collaborazione con Kanban+ e Kanban University. Ho esplorato come il metodo Kanban possa aiutare le organizzazioni a migliorare la prevedibilità e la qualità dei loro servizi, portando a migliori risultati di business. Ho cercato di portare nel webinar consigli pratici e approfondimenti basati sull’esperienza reale.

Qui di seguito riporto una sintesi in italiano dei contenuti, mentre è possibile rivedere la registrazione del webinar in inglese cliccando sull’immagine qui sotto.

La sfida della prevedibilità operativa

Molte organizzazioni, pur utilizzando pratiche e framework consolidati (come per esempio best practice ITSM), faticano a rispondere a domande fondamentali come “quanto tempo ci vuole per fare le cose?” o “cosa promettiamo ai nostri clienti?”. Questa difficoltà rivela una consapevolezza ridotta del rischio operativo, che può essere definito come il rischio che eventi interni o esterni possano causare un allungamento dei tempi di completamento del lavoro rispetto alle attese.

Le risposte comuni a queste domande sono spesso un numero singolo o un punto di domanda, raramente una metrica basata sulla distribuzione dei tempi. Per affrontare questa indeterminatezza, in Kanban viene introdotto il concetto di lead time, inteso come il tempo che intercorre tra l’inizio (colonna “to-do”) e la fine (colonna “done”) di un elemento di lavoro (un “work item”, cioè un elemento di lavoro richiesto da un cliente), se lo rappresentiamo su una board Kanban di base.

È cruciale capire che il lead time non è un valore singolo, ma una distribuzione di valori che mostra variabilità. La rappresentazione visiva di questa distribuzione (frequenza vs. unità di tempo) rivela che alcuni valori si ripetono più spesso, ma esiste sempre una variazione significativa.

L’insidia dei bias cognitivi nelle previsioni

Quando si chiede quale valore prendere come riferimento per una previsione, le risposte più comuni sono:

• La media: somma dei valori divisa per il numero di valori, che però viene confusa con la mediana.

• La mediana (50° percentile): il valore per cui metà delle volte il lavoro impiega meno tempo e metà delle volte impiega di più. Promettere la mediana implica un rischio del 50% di essere in ritardo, che i clienti solitamente non sono disposti ad accettare.

• La moda: il valore più frequente, ovvero il picco della curva di distribuzione. Tuttavia, nelle distribuzioni tipiche dei lead time, la moda è spesso a sinistra della mediana, il che significa che prometterla comporta un rischio di ritardo ancora maggiore del 50%.

Questi approcci intuitivi sono soggetti a bias cognitivi, portando a stime troppo ottimistiche e a rischi inaccettabili per le previsioni.

La soluzione di Kanban: rischio accettabile e qualità

L’approccio Kanban suggerisce di invertire la prospettiva: partire dalla probabilità di essere in ritardo che i clienti sono disposti ad accettare. Questo spesso mette in discussione la base su cui sono stati definiti gli attuali Service Level Agreements (SLA), che potrebbero essere stati stabiliti senza un’adeguata misurazione storica.

Una buona misura per la prevedibilità è l’85° percentile, che implica un rischio del 15% di essere in ritardo (una volta su sette). Questo è generalmente considerato un rischio accettabile per i servizi. Tuttavia, per servizi critici con implicazioni legali o di business, potrebbe essere necessario optare per percentili più alti, come il 95°, per ridurre ulteriormente il rischio (ad esempio, al 5%).

Il metodo Kanban offre una soluzione per aumentare la prevedibilità e, di conseguenza, migliorare la qualità del servizio. La qualità, infatti, è un “bonus” della prevedibilità: un sistema prevedibile consente una maggiore concentrazione e affidabilità, fattori che nel tempo porteranno a un miglioramento della qualità.

Gestire le code grasse (fat tail) di distribuzione

L’85° percentile potrebbe però non fornire un valore sufficientemente affidabile da utilizzare a scopo previsionale. Un problema comune nelle distribuzioni dei lead time infatti è la presenza di una coda grassa (fat tail), ovvero una porzione estesa a destra del grafico che indica che, se si è in ritardo, il ritardo può essere estremamente lungo (ad esempio, decine di giorni oltre il previsto). Tali ritardi, anche se rari, minano rapidamente la fiducia del cliente.

Per affrontare questo, Kanban promuove come prima cosa il taglio della coda (trimming the tail) per ottenere una distribuzione con una coda sottile (thin tail). Questo si ottiene in due modi:

1. Analisi delle occorrenze individuali: Le lunghe code sono spesso composte da pochi valori anomali. Analizzare questi casi specifici permette di comprendere le cause radice dei ritardi estremi e di affrontare i problemi sottostanti, riducendo la probabilità che si ripetano.

2. Limiti al lavoro in corso (WIP Limits): Una delle pratiche fondamentali di Kanban è limitare la quantità di lavoro in corso. Questo costringe il team a concentrarsi su pochi elementi di lavoro alla volta, promuovendo il completamento piuttosto che l’avvio di nuove attività. È un concetto controintuitivo: limitare la capacità fa sì che si vada più veloci e si completino più cose (aumentando il throughput, ovvero il tasso di consegna). Si riduce il “context switching” e si migliora la qualità complessiva.

Un esempio di successo reale: HR Onboarding

Ho condiviso un caso reale di successo con un processo di onboarding HR. Inizialmente, il processo era totalmente inaffidabile, con tempi di completamento che variavano da 1 a 96 giorni. Attraverso l’applicazione delle pratiche Kanban (senza nemmeno implementare una nuova board, ma utilizzando il sistema di workflow esistente), l’azienda ha raggiunto un livello di prevedibilità del 97% di onboarding completati entro 6 giorni, riducendo il rischio a solo il 3%. Questo è stato cruciale, data la natura critica e le implicazioni legali del servizio di onboarding. Il progetto ha anche portato a standardizzazione, scalabilità e capacità di prevedere i carichi di lavoro futuri, il tutto con un investimento contenuto.

E’ possibile leggere il caso di studio completo in inglese cliccando qui.

Ho raccontato il medesimo caso di studio in un precedente webinar in italiano che può essere rivisto cliccando qui.

Domande e risposte

Durante la sessione di Q&A, sono emersi ulteriori elementi:

• Lead Time vs. Cycle Time: Il lead time è la misura che interessa il cliente (dal momento della richiesta alla consegna finale), mentre il cycle time misura il tempo in cui il lavoro è attivamente in corso (escludendo il tempo di attesa in coda). Spesso, i problemi di efficienza risiedono nella coda piuttosto che nell’esecuzione del lavoro. Concentrarsi sulla distribuzione del tempo in coda e definire classi di servizio basate sul costo del ritardo (cost of delay) può essere molto efficace.

• Kanban vs. overhead di Scrum: Kanban mira a ridurre l’overhead inutile, come il grooming del backlog, che può essere uno spreco di effort. In Kanban, si assegna una classe di servizio e si procede. Le cadenze (riunioni periodiche) in Kanban sono minimizzate per essere pragmatiche e orientate all’azione, pur mantenendo la sincronizzazione del lavoro. A differenza degli sprint di Scrum (che possono essere troppo lunghi o troppo corti), Kanban promuove un flusso continuo e stabile, riducendo lo stress di fine sprint e il “context switching”, portando a un passo sostenibile e a una maggiore efficienza. L’implementazione Kanban è altamente personalizzabile e non prescrittiva, per cui le cadenze possono essere adattate o combinate. È anche possibile applicare principi e pratiche Kanban all’interno di uno sprint Scrum per migliorarne l’efficacia.

Per maggiori informazioni sull’implementazione di Kanban insieme a Scrum potete cliccare qui.

Sintesi

In sintesi, il metodo Kanban offre un percorso pragmatico ed evolutivo per migliorare la prevedibilità e la qualità dei servizi professionali, aiutando le aziende a gestire meglio i rischi e a costruire la fiducia dei clienti attraverso consegne più affidabili.

Il cuore del controllo del rischio operativo: il valore del Flow nel metodo Kanban

Nel panorama economico odierno, caratterizzato da rapidi cambiamenti e incertezza, la capacità di un’organizzazione di dare valore ai propri clienti in modo rapido, prevedibile e sostenibile, mantenendo sotto controllo il rischio operativo, è fondamentale per il successo a lungo termine. Il metodo Kanban, con la sua enfasi sul valore del Flow (flusso), offre un approccio efficace per raggiungere questa capacità. Ma cosa significa esattamente Flow e perché è così cruciale?

Cos’è il Flow nel contesto del metodo Kanban?

In Kanban, il Flow si riferisce al movimento continuo e regolare degli elementi di lavoro attraverso un sistema, dalla loro richiesta iniziale fino alla consegna finale al cliente. Non si tratta solo di “fare le cose”, ma di assicurarsi che il lavoro si muova senza intoppi, ritardi o interruzioni. L’obiettivo principale della gestione del flusso è ottenere una creazione e consegna di valore per il cliente che sia veloce, fluida, sostenibile e prevedibile, minimizzando al contempo rischi e costi di ritardo.

I benefici trasformativi di un flusso ottimizzato

Un flusso efficace porta a numerosi vantaggi, sia a livello operativo che strategico:

Sollievo dal sovraccarico: molte organizzazioni sono afflitte dal sovraccarico di lavoro (muri), che porta a stress, bassa qualità e rilavorazioni. Implementando il Flow, si riduce la quantità di lavoro in corso (WIP), permettendo alle persone di concentrarsi su meno elementi e di completarli con maggiore qualità. Questo porta a un miglioramento della soddisfazione e del benessere del personale.
Maggiore prevedibilità e velocità di consegna: quando il lavoro fluisce senza interruzioni e accumuli eccessivi, i tempi di consegna (lead time) si riducono e diventano più prevedibili. Le organizzazioni che si concentrano sul Flow possono iniziare a soddisfare costantemente le aspettative dei clienti, costruendo fiducia e credibilità.
Miglioramento della qualità e riduzione delle rilavorazioni: un flusso più fluido significa meno interruzioni e cambi di contesto, il che si traduce in meno difetti e rilavorazioni.
Comprensione profonda del lavoro: la gestione del Flow richiede di identificare e visualizzare i tipi di domanda e come vengono elaborati, rendendo visibili impedimenti e ritardi. Questa trasparenza porta a una comprensione collettiva di come il lavoro viene svolto e dove possono essere apportati miglioramenti.
Migliore gestione del rischio e delle opportunità: un flusso prevedibile migliora la gestione del rischio offrendo un numero maggiore di opzioni a disposizione dei decisori. La prevedibilità permette infatti di posticipare le decisioni fino all’ultimo momento responsabile, quando si hanno più informazioni a disposizione. Questo riduce il rischio di lavorare su elementi che potrebbero essere scartati o diventare obsoleti.
Crescita dell’agilità organizzativa: Le organizzazioni che padroneggiano il Flow sviluppano la capacità di adattarsi rapidamente ai cambiamenti delle esigenze dei clienti e delle condizioni di mercato. Questo è fondamentale per la resilienza e la sostenibilità a lungo termine.

Un percorso di evoluzione continua

Il percorso verso un flusso ottimizzato è un viaggio di evoluzione continua, non un cambiamento una tantum.

Nelle fasi iniziali dell’adozione del metodo Kanban, l’attenzione è spesso rivolta al sollievo dal sovraccarico a livello individuale o di team. I team iniziano a visualizzare il proprio lavoro e a impostare limiti semplici per concentrarsi sul completamento delle attività. In questa fase, le prestazioni possono variare, ma si inizia a percepire una maggiore consapevolezza del lavoro e una motivazione a migliorare.
Man mano che un’organizzazione progredisce, si concentra sullo sviluppo di una maggiore consistenza nei processi. Inizia a considerare il lavoro dal punto di vista del cliente e a vedere le proprie attività come servizi. Si sviluppa la capacità di coordinare il lavoro tra i diversi team che collaborano per fornire un servizio end-to-end. Vengono introdotte metriche più significative legate al flusso, come i tempi di consegna (lead time), e si inizia a gestire attivamente blocchi e rilavorazioni.
Le organizzazioni più evolute riescono a ottenere un flusso fluido su vasta scala, concentrandosi sul bilanciamento della domanda e della capacità e sulla gestione delle aspettative dei clienti. I clienti percepiscono che i servizi sono “adatti allo scopo” (fit-for-purpose) e affidabili. La collaborazione si estende tra team e con i clienti stessi.
Successivamente, le organizzazioni rafforzano la propria robustezza attraverso una gestione quantitativa del rischio e l’ottimizzazione economica del flusso. Le dipendenze complesse vengono gestite in modo dinamico e la prevedibilità del servizio raggiunge livelli elevati. Le decisioni sono sempre più basate su dati e analisi quantitative.
Le organizzazioni che continuano a perfezionare il loro Flow diventano nel tempo leader di mercato, capaci di anticipare le esigenze dei clienti e di innovare costantemente. La loro attenzione si sposta sulla capacità di mettere in discussione cosa fanno e come lo fanno, cercando la perfezione e l’eccellenza.
Infine, le organizzazioni più evolute raggiungono la capacità di reinventarsi completamente – persino il loro scopo e la loro identità – in risposta a stravolgimenti di mercato o cambiamenti drastici. Questa è la massima espressione di antifragilità e garantisce la sopravvivenza a lungo termine.

Pratiche per sviluppare il Flow

Per coltivare un flusso efficace, il metodo Kanban suggerisce l’implementazione di diverse pratiche:

Visualizzazione: rendere visibile il lavoro, le fasi del flusso, le policy e gli impedimenti (come blocchi o elementi divenuti obsoleti) è il primo passo per comprendere e migliorare il Flow. Le Kanban board, le card colorate e gli indicatori visivi sono strumenti essenziali per questo scopo.
Limitazione del lavoro in corso (WIP): impostare limiti al numero di elementi che possono essere “in lavorazione” in un dato momento previene il sovraccarico e incoraggia il completamento prima di iniziare nuovo lavoro. Questo trasforma un sistema “push” (a spinta) in un sistema “pull” (a chiamata), che accetta il lavoro solo quando c’è capacità produttiva disponibile.
Gestione esplicita delle policy: definire chiaramente le regole per la gestione del lavoro – come vengono accettate le richieste, quando un elemento può essere spostato alla fase successiva, o come vengono trattate le diverse classi di servizio – garantisce coerenza e promuove l’autonomia.
Implementazione di cicli di feedback: riunioni regolari come il Kanban Meeting, il Replenishment Meeting e le Service Delivery Review sono essenziali per riflettere sul Flow, identificare problemi e guidare il miglioramento continuo. Questi cicli permettono di adeguare il sistema in base alle osservazioni e ai dati raccolti.
Comprensione delle Classi di Servizio: utilizzare diverse classi di servizio (es. Expedite, Fixed Date, Standard, Intangible) in base al costo del ritardo associato agli elementi di lavoro, permette di gestire le priorità in modo strategico e di bilanciare le esigenze dei clienti con gli obiettivi economici dell’organizzazione.
Gestione delle dipendenze: riconoscere e gestire le dipendenze tra i diversi servizi o team è fondamentale per mantenere un Flow fluido, specialmente in sistemi complessi. Tecniche come i parking lot e le classi di dipendenza aiutano a mitigare i rischi di blocco.

Conclusione

Il Flow non è solo una componente del metodo Kanban; è la sua ragione d’essere. Concentrarsi sul Flow significa adottare una mentalità che privilegia la velocità di consegna, la prevedibilità e la capacità di soddisfare costantemente le esigenze dei clienti e degli stakeholder. Indipendentemente dalla fase di sviluppo in cui si trova un’organizzazione, la ricerca di un Flow sempre più fluido, efficiente e prevedibile è il percorso verso una maggiore resilienza, agilità e successo nel dinamico mondo del business.

Prossimo webinar

Per conoscere i concetti alla base del valore del Flow potete iscrivervi al webinar gratuito del prossimo 23 luglio alle ore 18:00 in collaborazione con Kanban University e Kanban+. Parlerò di come il metodo Kanban può trasformare radicalmente il modo in cui gestite i vostri servizi, riducendo il rischio operativo e gli errori previsionali e migliorando significativamente la prevedibilità e la qualità.

Webinar: Mastering Predictability & Quality for Better Business Outcomes

Gestite i servizi professionali della vostra organizzazione e vi chiedete come affrontare le incertezze del lavoro quotidiano? Vi tovate spesso a fare previsioni che poi si rivelano inesatte, mettendo a rischio la puntualità e la soddisfazione dei clienti?

Partecipate al webinar gratuito in collaborazione con Kanban University e Kanban+ e scoprirete come il metodo Kanban può trasformare radicalmente il modo in cui gestite i vostri servizi, riducendo il rischio operativo e gli errori previsionali, e migliorando significativamente la prevedibilità e la qualità.

Il problema che affrontiamo insieme: molte organizzazioni si trovano di fronte a un rischio operativo, ovvero la possibilità che il lavoro richieda più tempo del previsto a causa di eventi interni o esterni. Spesso, quando ci viene chiesto quanto tempo ci vuole per evadere una richiesta, la risposta fornita è un numero singolo, vago, senza considerare la variabilità delle circostanze. Questo porta a previsioni poco affidabili e a un’elevata probabilità di ritardo.

Perché le vostre previsioni attuali potrebbero non funzionare: durante il webinar, esploreremo perché affidarsi a concetti come la media (più propriamente la mediana o cinquantesimo percentile) o il valore più frequente (moda) per fare previsioni è rischioso. Utilizzando la mediana, avreste il 50% di probabilità di essere in ritardo, e utilizzando invece la moda, questa probabilità sarebbe ancora più alta! Questo accade perché siamo tutti soggetti a bias cognitivi, come l’euristica della disponibilità, che ci porta ad adottare il valore più frequente senza renderci conto dei rischi inaccettabili che stiamo correndo.

La soluzione di Kanban: gestione del rischio e prevedibilità basata sui dati. Il webinar introdurrà al concetto di Lead Time, ovvero il tempo che ogni richiesta di lavoro (chiamata Work Item) impiega per essere completata. Scopriremo che il Lead Time non è un valore unico, ma una distribuzione di valori.

Vi guideremo attraverso:

Come misurare e visualizzare i Lead Time per ottenere una comprensione reale della variabilità del tuo lavoro.
Come utilizzare l’ottantacinquesimo percentile come valore previsionale, accettando un rischio di ritardo molto più contenuto (normalmente il 15%). Questo valore è comunemente adottato per i servizi, ma può essere diverso in funzione del rischio accettabile per il servizio.
L’importanza di limitare il lavoro in corso (WIP), una pratica fondamentale di Kanban che riduce il sovraccarico e migliora la prevedibilità dei tempi di consegna, facendo emergere i colli di bottiglia e aumentando l’efficienza del flusso.
Come il metodo Kanban, oltre a gestire il rischio operativo, è un approccio evolutivo e sostenibile che facilita l’adozione di pratiche che migliorano continuamente i modelli previsionali, stabilizzano i flussi di lavoro e portano a una migliore gestione del servizio.

Kanban: non solo per l’IT, ma per tutti i servizi professionali. Sebbene Kanban sia spesso associato al settore IT e si integri perfettamente con popolari framework di settore, ad esempio ITIL, la sua applicazione è universale. Kanban aiuta a gestire efficacemente le operazioni quotidiane (Enterprise Services Management) e funge da catalizzatore per la trasformazione e l’evoluzione strategica delle organizzazioni (Enterprise Services Transformation). La sua forza sta nel promuovere un cambiamento incrementale, senza imporre stravolgimenti drastici, ma lavorando con ciò che già esiste per far evolvere le pratiche organizzative.

A chi è rivolto questo webinar? Questo webinar è pensato per persone che vogliono rendere la loro attività più efficace, con servizi prevedibili e di alta qualità. Kanban è il punto di partenza ideale.

Cosa imparerete? Acquisirete una comprensione iniziale di come:

Migliorare la vostra capacità di fare previsioni accurate.
Gestire in modo più efficace il vostro flusso di lavoro.
Prendere decisioni basate su dati reali, non su intuizioni soggettive.

Non perdete l’opportunità di migliorare la prevedibilità e la qualità dei vostri servizi professionali!

Iscrivetevi ora al webinar gratuito, il prossimo 23 luglio alle ore 18:00.

Pillole di Kanban applicato: quando un approccio pragmatico ed evolutivo evita di complicare inutilmente le cose

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.