Categoria: Come funziona Kanban

Pubblicato il

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.

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

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

Sotto il 65%: quando la variabilità abbassa la soglia di efficienza del flusso

In un articolo precedente ho utilizzato la Teoria delle Code – e nello specifico la Legge di Little come caso particolare – per spiegare perché un sistema di flusso raggiunga la sua massima efficienza intorno al 65% del carico massimo teorico. Questo articolo si rivolge a chi vuole approfondire le basi matematiche di quel risultato e capire cosa succede quando le ipotesi semplificatrici del modello di partenza vengono rilassate.

Il modello sottostante, che ora possiamo nominare esplicitamente, si chiama M/M/1: una coda con un unico canale di servizio (1), arrivi casuali senza memoria secondo una distribuzione di Poisson (la prima M, da Markovian) e tempi di servizio con distribuzione esponenziale (la seconda M). In notazione estesa di Kendall si scriverebbe M/M/1/∞, dove ∞ indica che non c’è limite alla lunghezza della coda, ma per convenzione il quarto elemento si omette quando è infinito.

C’è però un’assunzione nascosta, che vale la pena portare in superficie: il modello M/M/1 fissa la variabilità del sistema a un valore preciso e implicito. Il 65% è corretto, ma solo per quel livello di variabilità. Se il sistema è più regolare, la soglia si alza. Se è più caotico, si abbassa.

La formula che permette di generalizzare questo risultato si chiama formula di Kingman, o equazione VUT. È il punto di arrivo naturale del ragionamento che abbiamo iniziato.

Cosa mancava nel modello precedente

Nel modello M/M/1, sia gli arrivi che i tempi di servizio seguono distribuzioni con una proprietà specifica: il loro coefficiente di variazione – il rapporto tra deviazione standard e media – è esattamente pari a 1.

Questo significa che stavamo implicitamente assumendo una variabilità “standard” sia per gli arrivi che per i tempi di lavorazione. Nella realtà queste assunzioni reggono raramente. Un sistema in cui gli elementi di lavoro (work item) arrivano a ondate – fine mese, fine sprint, richieste urgenti in cluster – ha una variabilità degli arrivi ben superiore a 1. Un sistema in cui alcuni task richiedono un’ora e altri una settimana ha una variabilità dei tempi di servizio anch’essa superiore a 1.

La domanda diventa: come cambia il Tempo di Ciclo quando la variabilità non è quella “standard” del modello M/M/1?

La formula di Kingman

La risposta la fornisce John Kingman, matematico britannico, con una formula che generalizza M/M/1 a sistemi con distribuzioni arbitrarie di arrivi e servizi. La formula calcola una approssimazione accettabile del tempo medio di attesa in coda (Wq), cioè il tempo che un work item trascorre in attesa prima di essere preso in carico:

  • Ca² = quadrato del coefficiente di variazione degli arrivi
  • Cs² = quadrato del coefficiente di variazione dei tempi di servizio
  • ρ = λ / μ = tasso di utilizzazione del sistema, dove λ è il tasso di arrivo dei work item e μ è la capacità produttiva
  • Te = tempo medio di servizio

La formula si legge come il prodotto di tre fattori distinti:

  1. Il fattore di variabilità: (Ca² + Cs²) / 2 – cresce all’aumentare dell’irregolarità del sistema
  2. Il fattore di utilizzazione: ρ / (1 − ρ) – esplode quando ci si avvicina al 100% di carico
  3. Il tempo di servizio base: Te – scala il risultato all’unità di misura del sistema

Il tempo totale di permanenza nel sistema – il Tempo di Ciclo che ci interessa (W) – si ottiene sommando il tempo di attesa in coda con il tempo di servizio: W = Wq + Te.

M/M/1 come caso particolare

Se sostituiamo nella formula di Kingman i valori propri del modello M/M/1, ovvero Ca² = 1 e Cs² = 1, otteniamo come tempo medio di attesa in coda (Wq):

Il tempo totale nel sistema (W), che include anche il tempo di servizio, diventa:

Sostituendo Te = 1/μ e ρ = λ/μ:

Che è esattamente la formula del Ws usata nell’articolo precedente. M/M/1 è dunque un caso particolare di Kingman, valido quando la variabilità di arrivi e servizi è esattamente pari a 1.

Per completezza vale la pena notare che le formule esatte per code con distribuzioni specifiche furono sviluppate da Agner Krarup Erlang già a inizio ‘900. Kingman generalizza quel lavoro a distribuzioni arbitrarie, al prezzo di un’approssimazione, sufficientemente accurata per le analisi che ci interessano. Più recentemente Donald Reinertsen in The Principles of Product Development Flow si riferisce alla formula di Allen-Cuneen, che esprime lo stesso risultato in termini di lunghezza media della coda (Lq) anziché di tempo di attesa (Wq) – le due formule sono equivalenti e collegate dalla Legge di Little: Lq = λ · Wq.

Cosa cambia con la variabilità

Il fattore (Ca² + Cs²) / 2 è il moltiplicatore che modifica il tempo di attesa in coda (Wq) rispetto al caso M/M/1. Se è uguale a 1, siamo nel caso precedente. Se è maggiore di 1, Wq cresce proporzionalmente. Se è minore di 1, il sistema regge meglio il carico. Il tempo totale W = Wq + Te cambia di conseguenza, ma in misura attenuata perché Te rimane fisso.

Riprendiamo il sistema dell’articolo precedente: capacità produttiva μ = 10 work item al giorno per ogni giornata lavorativa di 8 ore.

Carico (λ)Utilizzo (ρ)W – bassa variabilità (Ca²=Cs²=0,5)W – M/M/1 (Ca²=Cs²=1)W – alta variabilità (Ca²=Cs²=2)
550%1h 12min1h 36min2h 24min
660%1h 24min2h3h 12min
770%1h 44min2h 40min4h 32min
880%2h 24min4h7h 12min
990%4h 24min8h15h 12min

La struttura è la stessa: il Tempo di Ciclo esplode avvicinandosi al 100%. Ma la scala cambia in modo significativo. Con alta variabilità, già al 50% di carico il sistema impiega quasi due ore e mezza per evadere un singolo work item e al 70% di carico il sistema impiega quasi cinque ore, laddove con bassa variabilità lo stesso carico del 70% sarebbe invece ancora ampiamente gestibile.

Il 65% potrebbe essere ottimistico

Il risultato pratico è diretto: la soglia del 65% vale per il caso M/M/1, cioè per un sistema con variabilità “standard”. Nel lavoro di concetto (knowledge work) e nei servizi dove le richieste arrivano in modo irregolare e i tempi di lavorazione possono variare molto da un task all’altro, Ca² e Cs² sono tipicamente superiori a 1.

Questo significa che il 65% è, in molti contesti reali, una stima ottimistica. La soglia di efficienza reale si abbassa. Un sistema con alta variabilità può richiedere di operare al 50% o anche meno per mantenere Tempi di Ciclo accettabili.

Le leve per migliorare il flusso

“Festina lente” (Affrettati lentamente – Svetonio)

Reinertsen suggerisce e rende esplicite tre leve distinte per la gestione delle code, con efficacia e natura diverse. Vale la pena passarle in rassegna.

1. Ridurre il carico (ρ) – leva dominante

È la leva del limite al lavoro in corso (WIP limit): tenere il sistema al di sotto della soglia di saturazione. Il fattore di utilizzazione ρ/(1−ρ) cresce in modo superlineare, a ρ=0,9 vale 9, a ρ=0,95 vale 19. Agire su ρ produce effetti sproporzionatamente grandi rispetto all’entità dell’intervento.

2. Ridurre la variabilità (Ca² e Cs²) – leva incrementale

Il fattore di variabilità entra nella formula in modo lineare rispetto a Ca² e Cs²: raddoppiare la variabilità raddoppia Wq, nulla di più. Nel concreto significa regolarizzare il flusso degli arrivi e ridurre la dispersione dei tempi di lavorazione – standardizzazione, suddivisione dei task in unità più omogenee. Nel knowledge work tuttavia la variabilità è difficile da comprimere per ragioni strutturali: è nella natura del lavoro cognitivo. La riduzione della variabilità è un miglioramento incrementale sopra la leva dominante, non un’alternativa ad essa.

3. Gestire la sequenza della coda – leva compensativa

Quando la coda esiste, l’ordine con cui i work item vengono processati ha un valore economico misurabile. Nel manifatturiero, dove i job sono di solito omogenei per durata e costo del ritardo, FIFO (First-In-First-Out) è ottimale e non c’è nulla da ottimizzare nella sequenza. Nel lavoro di concetto i work item sono eterogenei per definizione, e una disciplina di gestione della coda (queueing discipline) esplicita crea valore. Le due euristiche di base: a parità di durata, prima il job con costo del ritardo più alto; a parità di costo del ritardo, prima il job più corto. Nel linguaggio Kanban, questa leva si traduce in classi di servizio e policy di replenishment.

Vale però sottolineare che la queueing discipline è uno strumento compensativo: serve perché siamo lontani dall’ottimo, non è una soluzione strutturale. L’obiettivo ideale è avere code così piccole da non richiedere discipline di priorità e ci si arriva agendo sulle prime due leve.

Un vantaggio comune alle leve 1 e 3

Limitare il WIP e gestire la sequenza della coda sono interventi su variabili soft: si attuano con una decisione di policy, sono immediati e reversibili. Aumentare la capacità produttiva (μ) è invece una variabile hard: assumere, formare, riorganizzare sono azioni lente e costose. Questa asimmetria pratica rafforza ulteriormente la priorità delle leve operative rispetto all’investimento in capacità.

Quanto costa non avere capacità in eccesso

Fino a qui abbiamo ragionato in termini di flusso. C’è però una formalizzazione economica del problema che vale la pena esplicitare, particolarmente utile quando si deve giustificare una scelta di capacity management a un imprenditore o un responsabile aziendale.

Il costo totale di un sistema in coda è la somma di due componenti che si muovono in direzioni opposte:

  • Cc = costo unitario della capacità (il costo di avere una persona in più, un server in più)
  • CD = costo unitario del ritardo (il valore economico del tempo perso in attesa)
  • Cc·μ = costo totale della capacità, che cresce linearmente con μ
  • CD·λ/(μ−λ) = costo totale del ritardo, che decresce all’aumentare di μ e diverge quando μ converge verso il valore di λ

Il minimo del costo totale si trova in:

La lettura è diretta: la capacità ottimale è sempre superiore al tasso di arrivo – operare al 100% non è mai ottimale economicamente. La distanza dall’ottimo dipende dal rapporto CD/Cc: quanto più il costo del ritardo è alto rispetto al costo della capacità, tanto più conviene investire in capacità in eccesso.

Per chi deve prendere queste decisioni, il ragionamento si traduce in una domanda concreta: quanto costa, nella mia organizzazione, un giorno di ritardo su un work item tipico? Se la risposta è “molto” – cliente che aspetta, opportunità che sfuma, deadline contrattuale a rischio – allora la capacità in eccesso non è uno spreco, è un investimento con un rendimento calcolabile. Operare “al risparmio” sulla capacità può essere la scelta economicamente peggiore.

Conclusione

La Legge di Little ci dice che WIP (L), tasso di arrivo (λ) e Tempo di Ciclo (W) sono legati. Il modello M/M/1 mostra come il Tempo di Ciclo esploda avvicinandosi alla saturazione. Kingman completa il quadro: l’esplosione è amplificata dalla variabilità, e variabilità e utilizzazione si moltiplicano, non si sommano.

Il 65% rimane un riferimento utile. Ma in un sistema ad alta variabilità, come può essere il knowledge work, è una soglia da cui partire verso il basso, non un obiettivo da raggiungere. Le leve per migliorare il flusso esistono, hanno efficacia diversa, e – cosa non trascurabile – le più potenti sono anche le più facili da azionare.

Bibliografia

  1. John F.C. Kingman, The single server queue in heavy traffic, Mathematical Proceedings of the Cambridge Philosophical Society, 1961
  2. Paul Newbold, Principles of Management Science, Prentice-Hall, 1986
  3. Donald G. Reinertsen, The Principles of Product Development Flow, Celeritas Publishing, 2009

Pubblicato il

Dal caos al flusso: note a margine della presentazione di un libro

Il 7 maggio scorso, con Paolo Cavicchioli e con Leonarda Vanicelli che ha moderato la conversazione, abbiamo presentato Dal caos al flusso alla Cascina Sant’Alberto di Milano. Quello che segue non è un resoconto dell’evento, ma un tentativo di mettere a fuoco alcune idee che la conversazione ha fatto emergere – idee che, in parte, non avevo articolato così chiaramente nemmeno nel libro.

Come nasce un libro che non pensavo nemmeno di scrivere

Il libro non nasce da un piano editoriale. Nasce da un blog: una serie di risposte scritte a problemi reali, con un filo narrativo implicito ma non evidente. Quando mi si è presentata l’occasione di utilizzare i contenuti del blog per guidare un’implementazione end-to-end del metodo Kanban in un contesto aziendale articolato, ho cercato una referenza sistematica da dare alle persone coinvolte. Quello che era un archivio di articoli è diventato un indice, e quell’indice è diventato un manoscritto.

La versione disponibile oggi comprende una presentazione di David J. Anderson, che ha visto nel libro un testo scritto a partire dall’esperienza diretta, con spunti pragmatici e attuabili.

Doxee: una fabbrica dell’immateriale

Uno dei casi di studio del libro – e quello centrale della conversazione del 7 maggio – è Doxee, azienda multinazionale con base a Modena che trasforma dati grezzi in documenti dinamici su volumi che Paolo Cavicchioli, suo CEO, ha quantificato in circa 9 miliardi di documenti l’anno. Un numero che, detto così, rischia di scivolare via. Vale la pena fermarcisi un momento: significa che il problema della variabilità, dei picchi di domanda, della sincronizzazione tra reparti con logiche diverse non è un problema marginale. È il problema centrale dell’organizzazione.

Doxee lavora su tre linee: tecnologia proprietaria, prodotti SaaS, e gestione di progetti su commessa. Quest’ultima era storicamente la parte più esposta alle inefficienze sistemiche, con il team di delivery compresso tra una forza commerciale che vende e una tecnologia che evolve, spesso senza che le due cose possano allinearsi con sufficiente anticipo. È in questo contesto che ciò che solo successivamente è stato inquadrato come metodo Kanban ha trovato un terreno non banale su cui misurarsi.

Oggi il team di delivery dialoga con gli altri reparti con pari dignità e gode del “privilegio” di poter affermare con autorevolezza quando qualcosa non è possibile, basandosi su dati oggettivi.

Il problema non era il metodo

Una delle cose che ho raccontato durante la presentazione, e che ribadisco sempre, è che ciò che è stato introdotto in Doxee non lo è stato perché qualcuno aveva letto un libro e voleva provare. È stato introdotto perché il team di delivery stava pagando un costo reale – in ore extra, in turnover, in qualità degradata. Vale anche la pena ricordare che quella implementazione è avvenuta prima che il metodo Kanban venisse codificato formalmente a livello internazionale: era, in senso proprio, un proto-Kanban, una risposta empirica a un problema reale che solo in seguito ha trovato corrispondenza in un metodo. Non è stato calato dall’alto su un’organizzazione. È cresciuto insieme a essa.

E lo strumento decisivo è stato un report all’interno del quale avevo inserito quella che avevo definito, un po’ provocatoriamente, “tolleranza di Marco Re”: una contingency del 15% nella pianificazione, con il mio nome esplicito come referente in caso di critiche. L’idea era semplice: fare da scudo al team mentre si stabilizzava il nuovo regime. Ma l’effetto non era scontato. Funziona solo se chi fa da scudo riesce ad avere credibilità sufficiente da rendere il gesto credibile, e se il team percepisce che lo scudo è reale e non simbolico.

La prevedibilità delle consegne, che nella fase iniziale era molto bassa, ha progressivamente raggiunto valori superiori al 90% dopo la piena implementazione del sistema. Non è un risultato che si ottiene facilmente: richiede disciplina nel limitare il lavoro in corso, l’abitudine di pianificare la capacità in anticipo di settimane, e soprattutto la volontà e il coraggio di dire di no quando la domanda supera la capacità disponibile.

WIP limits, capacità, traffico cognitivo

Tre strumenti hanno fatto la differenza pratica.

Il primo sono stati i limiti al lavoro in corso. Ho usato durante la presentazione l’analogia delle autostrade svizzere, che regolano l’accesso al traffico per evitare gli ingorghi: meno veicoli in ingresso significa velocità più sostenuta per chi è già in carreggiata, maggiore numero di veicoli a destinazione per unità di tempo. Lo stesso principio vale per i team: ridurre il numero di attività in corso aumenta la quantità di attività completate.

Il secondo è stato il capacity planning su orizzonte lungo – fino a dodici mesi – con slot di disponibilità aggiornati regolarmente. La conversazione tra chi vende e chi produce cambia registro quando entrambe le parti guardano lo stesso dato.

Il terzo è stato la strutturazione delle riunioni come momenti di sincronizzazione deliberata, non di escalation improvvisata. Bloccare la pianificazione per periodi di quindici giorni – nessuna nuova priorità inserita senza accordo esplicito e una solida ragione per farlo – ha ridotto il traffico cognitivo asincrono che logora i team più di qualsiasi carico di lavoro.

Un elemento trasversale a tutti e tre è il passaggio dalle stime analitiche al forecast statistico. Invece di cercare di stimare analiticamente ogni attività – esercizio costoso e spesso illusorio nel software – si identificano pattern ricorrenti nel lavoro e si usano distribuzioni storiche per prevedere i tempi. Non è una rinuncia alla precisione: è una forma di precisione più onesta, che riconosce la variabilità invece di ignorarla.

T-shape e contaminazione disciplinare

Paolo Cavicchioli ha portato all’evento una riflessione che merita di essere riportata, perché tocca un tema più ampio della gestione di progetto. La sua esperienza in Doxee con i cosiddetti profili T-shape – persone con una competenza verticale profonda e una capacità orizzontale di collaborare con discipline diverse dalla propria – lo ha convinto che la contaminazione tra culture diverse non è un esercizio di inclusività aziendale, ma un vantaggio competitivo concreto.

L’esempio che ha citato è quello di un laureato in storia, diventato un elemento chiave del team tecnico proprio per la capacità di costruire metafore comprensibili, di semplificare senza banalizzare, di tenere presente la prospettiva dell’utente finale in un contesto dominato da logiche ingegneristiche. Lo stesso ragionamento vale per la gestione di team internazionali: le differenze culturali tra contesti lavorativi italiani, tedeschi e austriaci non si governano ignorandole, ma riconoscendone le logiche e trovando un terreno comune su cui il flusso possa continuare a scorrere.

Nel tempo, Doxee è diventata anche un luogo dove i giovani talenti crescono, sviluppano competenze, e in alcuni casi maturano abbastanza da avviare percorsi imprenditoriali autonomi. È un indicatore di salute organizzativa che non compare in nessun report, ma che dice qualcosa di preciso sulla qualità dell’ambiente di lavoro che si è costruito.

Una nota finale sul miglioramento continuo

C’è un rischio che ho imparato a riconoscere nel tempo e che nel libro chiamo “plateau della presunta eccellenza”: la tendenza delle organizzazioni a fermarsi non appena i risultati diventano accettabili. I miglioramenti iniziali sono spesso rapidi e visibili, il che può essere paradossalmente un problema, perché crea l’illusione che il sistema sia “a posto”.

Il caso Doxee lo conferma: il miglioramento continuo non è uno stato che si raggiunge. È un’abitudine, e come tutte le abitudini, si coltiva con costanza o si perde per inerzia. La differenza tra le organizzazioni che sostengono i risultati nel tempo e quelle che dopo un po’ regrediscono non sta nella qualità degli strumenti adottati, ma nella capacità di continuare a fare domande scomode anche quando le cose vanno bene. È più facile interrogarsi sui propri processi in una fase di crisi che in una fase di successo. Eppure è proprio nel successo che si creano le condizioni per la crisi successiva, se si smette di interrogarsi.

Pubblicato il

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.

ConcettoDefinizione operativaImplicazione economica
Last Responsible MomentDecisione 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 LateDecisione 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:

  1. Ora: elementi che hanno raggiunto il proprio LRM e devono essere messi in lavorazione per onorare la promessa di consegna.
  2. Dopo: opzioni che non hanno ancora raggiunto l’LRM e restano in attesa perché si possa acquisire ulteriore conoscenza relativa alla loro lavorazione.
  3. 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:

  1. Expedite: per elementi con urgenza critica e pendenza della PCoDS altissima. Richiedono un intervento immediato, spesso violando i limiti al lavoro in corso (WIP).
  2. 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.
  3. Standard: il cuore del sistema, gestito solitamente tramite logica FIFO (First-In, First-Out) per garantire massima prevedibilità e stabilità del Lead Time.
  4. 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.

Pubblicato il

Cicli di Feedback: il sistema nervoso dell’agilità organizzativa

Un’altra domanda che mi è stata fatta durante la presentazione del mio libro riguardava i Cicli di Feedback, che nel libro descrivo come vera catena di trazione di un sistema Kanban. Vale la pena approfondire questo tema e nel farlo affidarsi a una analisi fatta da Andreas Bartel, che ha dato un significativo contributo alla definizione e rappresentazione delle cadenze Kanban così come le conosciamo oggi nel Kanban Maturity Model (KMM). Ho tratto i concetti di questo articolo da un intervista fatta allo stesso Bartel nel 2023, ho indicato il link al video originale nelle Fonti.

Immaginate di fare trekking tra le vette delle Alpi. Per raggiungere la meta in un ambiente così dinamico, non basta la forza muscolare; serve un dialogo costante tra voi, la mappa e la bussola. Questo rapporto è un sistema chiuso di retroazione: la bussola fornisce una direzione, voi agite camminando e il mutamento della vostra posizione offre nuovi dati allo strumento. Nel management moderno, questo fenomeno prende il nome di Ciclo di Feedback. Sebbene le aziende ne siano immerse, questi cicli sono spesso invisibili o, peggio, ignorati. Eppure, comprendere la meccanica dei cicli di feedback non è un mero esercizio accademico: è l’essenza stessa della navigazione in condizioni di incertezza, il confine sottile tra un’organizzazione che evolve e una che declina senza nemmeno rendersene conto.

I Cicli di Feedback sono fenomeni naturali, non invenzioni umane

Un ciclo di feedback è una relazione bidirezionale intrinseca: l’output di una parte diventa l’input dell’altra, creando una circolarità continua. È fondamentale liberarsi dell’idea che i cicli di feedback siano “processi burocratici” o semplici riunioni istituite dal management. Essi esistono in natura – regolano il clima e le popolazioni animali – e proliferano spontaneamente in ogni azienda sotto forma di network organizzativi informali o sistemi di retroazione ombra. Le conversazioni non strutturate davanti alla macchinetta del caffè sono cicli di feedback tanto quanto i report finanziari.

I cicli di feedback sono agnostici rispetto a qualsiasi cosa l’uomo possa inventare o introdurre in un’organizzazione, perché esistono comunque. Riconoscere questa natura spontanea e non governabile dei feedback è il primo passo per smettere di subirli e iniziare a gestirli consapevolmente.

La polarità del successo: perché il feedback negativo può salvarci

In teoria dei sistemi, i cicli di feedback non sono tutti uguali; possiedono polarità distinte che determinano il comportamento dell’organizzazione:

  • Ciclo di Feedback positivo (rinforzante): amplifica la direzione attuale. Pensate all’interesse composto: più capitale genera più interessi, che aumentano il capitale. È il motore della crescita, ma se non regolato, può condurre all’esplosione o al collasso del sistema.
  • Ciclo di Feedback negativo (bilanciante): funziona come un meccanismo di stabilizzazione. In natura, è il rapporto preda-predatore (ghepardo-gazzella): l’aumento dei predatori riduce le prede, il che alla fine riduce i predatori, riportando il sistema in equilibrio.

L’intuizione paradossale per un leader è che, mentre il business insegue ossessivamente il “positivo”, è la capacità di innescare cicli negativi a garantire la stabilità e la sopravvivenza a lungo termine, impedendo al sistema di andare fuori giri.

L’errore fatale di Kodak e la metafora delle neuroscienze

Perché aziende leader falliscono nonostante vedano arrivare il cambiamento? Bartel introduce una potente analogia tratta dalle neuroscienze. Un ciclo di feedback interrotto (broken feedback loop) agisce come una patologia delle aree motorie: il cervello percepisce l’ambiente, ma il circuito neurale verso i muscoli è danneggiato. L’individuo vuole afferrare un oggetto, ma non riesce a coordinare il movimento.

Il caso Kodak è l’esempio clinico di un’organizzazione con i “circuiti motori” distrutti. L’azienda aveva percepito il segnale della fotografia digitale, ma non è riuscita a tradurre il segnale in azione, continuando a rinforzare gli investimenti nelle vecchie competenze analogiche. Il fattore critico, però, non è tecnico: è umano. I decisori possono percepire chiaramente i segnali del mercato e tuttavia scegliere di non agire, o di agire nella direzione sbagliata. L’inerzia non è ignoranza: è spesso il risultato di pressioni politiche interne, di identità aziendali consolidate, di incentivi che premiano la continuità piuttosto che il cambiamento. In Kodak, il circuito percettivo funzionava; era il passaggio dal segnale all’azione ad essere bloccato da decenni di successo.

La vera agilità è la gestione della polarità

Per un esperto di business agility, un’organizzazione eccellente non è quella che cresce linearmente, ma quella capace di cambiare polarità in modo fluido.

La vera agilità consiste nella capacità sistemica di accendere o spegnere i cicli positivi e negativi. Se il mercato cambia, bisogna avere il coraggio di attivare un ciclo negativo per “smorzare” e disinvestire in settori storici, liberando capacità per costruire nuove competenze. Molte aziende restano vittime di un ciclo negativo disfunzionale che protegge lo status quo: ogni tentativo di cambiamento viene “rimbalzato” dal sistema, che torna pigramente al punto di partenza. L’agilità è, in ultima analisi, il potere di decidere quale ciclo alimentare e quale interrompere, prima che sia il sistema a decidere per noi.

Riunioni vs. Cadenze: riprendere il controllo del sistema

È vitale distinguere il ciclo di feedback (il fenomeno naturale) dalla Cadenza (lo strumento di controllo). Se i cicli di feedback avvengono ovunque, la cadenza è il ritmo regolare che rende questi cicli espliciti e governabili. In ambito Kanban, abbiamo otto cadenze, delle quali tre essenziali:

  1. Replenishment Meeting: il momento della selezione strategica. Si decide cosa iniziare, prendendo in carico il lavoro in base alle reali priorità degli stakeholder.
  2. Kanban Meeting: una cadenza operativa che agisce come regolatore del flusso di lavoro. Non è un semplice aggiornamento, ma una prospettiva operativa per gestire la pipeline e assicurare la fluidità della consegna.
  3. Service Delivery / Flow Review: un momento di riflessione profonda sulla qualità e l’efficacia del sistema. La frequenza di questa cadenza dipende dal livello di maturità dell’organizzazione e dalla velocità con cui il sistema necessita di apprendere dai propri errori.

Una questione di adattamento evolutivo

La storia economica dimostra che il successo non è legato alla forza, ma alla qualità dei cicli di feedback. Le organizzazioni che prosperano sono quelle che hanno trasformato il feedback in un meccanismo evolutivo: percepiscono il cambiamento, regolano i meccanismi interni e rispondono con senso. Non è solo efficienza, è adattamento biologico applicato al business.

Il contraltare di Kodak esiste, ed è istruttivo proprio perché non racconta una trasformazione semplice. Fujifilm percepì lo stesso identico segnale – la fotografia digitale avrebbe reso obsoleta la pellicola – e scelse di cambiare polarità. Non abbandonò il passato, ma lo usò come piattaforma: le competenze in chimica delle emulsioni fotografiche vennero reindirizzate verso cosmetici, materiali ottici e farmaceutica. Fujifilm non sopravvisse nonostante i suoi successi; li usò come punto di partenza per diventare qualcos’altro.

La tua organizzazione ha il coraggio di cambiare polarità e andare oltre i successi del passato, o sta aspettando che sia il mercato a scegliere per lei?

Fonti

  1. David J. Anderson, Teodora Bozheva, Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention – 2nd Edition, Kanban University Press, 2021
  2. Andreas Bartel, Understanding Feedback Loops. KMM Plus Talks to Andreas Bartel: full interview, canale YouTube Kanban+ di Kanban University, 2023
Pubblicato il

Dal vittimismo al sogno: come si accende una leadership vera

Durante la presentazione del mio libro, mi è stato chiesto: Come si porta un team dal “non è colpa mia” al “me ne faccio carico”?

È una domanda che mi sono posto anche nel 2010. Avevo un gruppo di persone capaci, ma bloccate. Il mercato era difficile, le risorse scarse, e in quelle condizioni è facile scivolare nella narrativa della vittima: il sistema non funziona, i piani alti non capiscono, il budget non c’è. Non era pigrizia. Era qualcosa di più sottile: una progressiva abdicazione della responsabilità, fatta di piccoli passi, quasi invisibile.

In quel periodo seguivo Mourinho – lo seguivo da prima che arrivasse all’Inter, perché avevo visto e letto qualcosa di suo e, a prescindere da certi suoi atteggiamenti e dal tifo calcistico, mi ero accorto che quell’uomo aveva qualcosa da dire sulla motivazione, sulla gestione della pressione, sulla capacità di far credere le persone in qualcosa di grande. Nel 2010, alla vigilia della semifinale di Champions League contro il Barcellona, disse una cosa che mi rimase impressa: “Noi vogliamo andare dietro al nostro sogno, per loro la finale è un’ossessione – e la differenza è molto grande.”

Quella distinzione – sogno contro ossessione – mi diede una chiave pratica. L’ossessione genera paura del fallimento, blocca il talento, trasforma ogni ostacolo in una conferma che le cose non possono andare bene. Il sogno libera energia, permette di farsi carico di fatiche che altrimenti sembrerebbero insensate. Trassi ispirazione da quella frase per motivare i miei ragazzi. Non come slogan, ma come specchio: state inseguendo un sogno o state cercando di sopravvivere a un’ossessione? Qualcosa si mosse. Anni dopo avrei scoperto che il metodo Kanban descrive esattamente questo approccio: per far evolvere un’organizzazione, il leader si comporta come un allenatore sportivo.

Frankl e il carburante del coraggio

Ma perché funziona? La risposta più profonda non me la ha data il calcio. Me la ha data Viktor Frankl.

Frankl era uno psichiatra viennese. Sopravvisse ad Auschwitz, e da quella esperienza – che non ha paragoni possibili con nessuna difficoltà aziendale, sia chiaro – trasse un’osservazione radicale sulla natura umana: anche privato di tutto, anche ridotto ai minimi termini, un essere umano che riesce a darsi un senso trova la forza di resistere. Chi non lo trova, si sgretola. Non per debolezza morale, ma perché il senso è una necessità costitutiva dell’essere umano, non un lusso. Per riassumere questo concetto Frankl citava spesso Nietzsche:

“Chi ha un perché per vivere, sopporta quasi ogni come.”

Ma Frankl va oltre la resilienza. Propone quella che chiama una rivoluzione copernicana del senso: non dobbiamo chiederci cosa ci aspettiamo dalla vita, ma capire che è la vita a interrogarci.

“Vivere significa rispondere alle domande che la vita ci pone, assumendoci la responsabilità di ogni istante.”

Vivere – e lavorare – non è attendere che le condizioni migliorino. È rispondere, agire, farsi carico.

Ed è qui che senso e coraggio si intrecciano. Senza senso, il costo del coraggio è troppo alto: ci si espone, si rischia, ci si fa carico di qualcosa che potrebbe andare male, e se non si sa perché, a un certo punto ci si ferma. Il senso non è una consolazione, è il carburante del coraggio.

La promessa onesta

Tutto questo ha conseguenze molto concrete su come si gestiscono le persone.

Quando in un’azienda con cui collaboravo anni dopo abbiamo assunto una persona per un ruolo di responsabilità, le condizioni oggettive non erano un argomento di vendita. L’azienda non era strutturata. La retribuzione era bassa. Potevo raccontarle una favola. Non l’ho fatto. Le ho detto con tutta la sincerità che riuscivo a trovare: “Non ti prometto un lavoro facile. Ti prometto anni entusiasmanti a costruire qualcosa che oggi non esiste.” Lei ha scelto quella proposta e quella scelta era un atto di coraggio, non di ingenuità. Il coraggio di chi ha trovato un senso abbastanza solido da giustificare il rischio. Oggi, quando attraversa un momento di sconforto, a volte è utile ricordare insieme quella conversazione. Non come retorica motivazionale, ma come riaggancio al senso originario.

La leadership diffusa nel metodo Kanban

Tutto questo ha un nome preciso nel metodo Kanban: “incoraggia atti di leadership a tutti i livelli.”

Non è un invito a ignorare la gerarchia. È il riconoscimento che la leadership – nel senso di iniziativa, responsabilità, cura del sistema – non può essere monopolio di chi ha un titolo o un ruolo di responsabilità. Un designer che propone un’interfaccia più semplice senza che nessuno glielo abbia chiesto, uno sviluppatore junior che blocca un rilascio perché ha visto un problema che mina la fiducia dell’utente, un team che rifiuta un compito perché non è coerente con lo scopo dichiarato: questi sono atti di leadership diffusa.

Ma attenzione: questo senso non può essere imposto dall’alto. Un purpose scritto dal CEO e affisso in sala riunioni non accende nulla. Il senso che dà coraggio è quello che il team costruisce insieme, attraverso la conversazione, il confronto, la partecipazione alle decisioni. È per questo che Kanban insiste sulla collaborazione e sul rispetto delle persone come condizioni strutturali, non come valori decorativi.

E quando quel senso è davvero condiviso, i comportamenti cambiano. Il coraggio di esporsi, di dire una cosa scomoda, di assumersi la responsabilità di un’azione non richiesta diventa possibile. Senza senso, il costo dell’iniziativa è troppo alto e le persone, razionalmente, si ritraggono. Nel Kanban Maturity Model, questo salto avviene al Livello 3: l’organizzazione smette di rincorrere l’efficienza per sé stessa e inizia a definire uno scopo che orienta ogni decisione. Il fit-for-purpose non è più un’etichetta tecnica, diventa qualcosa che le persone hanno costruito e interiorizzato insieme, e che dà loro il coraggio di agire.

L’unica metrica che conta

La vera metrica del successo di un leader non è un bilancio, un OKR, un NPS.

È quello che succede anni dopo. Alcuni di quei ragazzi con cui lavoravo allora hanno preso strade imprenditoriali. Parlando con loro di recente, ho capito – e uno me l’ha detto esplicitamente – che stanno ancora inseguendo quel sogno. L’azienda è cambiata, il contesto è cambiato, tutto è cambiato. Ma il germe è rimasto.

Se fossi il Faust di Goethe, direi: “attimo, fermati, sei bello!”.

Non perché sia un risultato mio, non lo è. Ma perché significa che il senso che avevamo trovato insieme era reale, abbastanza reale da durare oltre le circostanze che lo avevano generato. E questo, per me, è l’unica eredità che vale la pena costruire.

Pubblicato il

Le quattro dimensioni della leadership in Kanban: il catalizzatore del cambiamento evolutivo

Nel contesto del Kanban Maturity Model (KMM), la leadership non è una posizione gerarchica, ma l’energia cinetica necessaria per superare l’inerzia e la resistenza naturale al cambiamento. A differenza dei modelli prescrittivi, che impongono strutture rigide rischiando il rigetto organizzativo, il modello evolutivo di Kanban utilizza la leadership come motore per passare dal caos (ML0) all’antifragilità (ML6).

Il ruolo del leader è paragonabile a quello di un allenatore sportivo: egli conosce il manuale di gioco e applica intenzionalmente un livello di stress positivo per provocare una reazione antifragile nel sistema. L’obiettivo è stimolare il miglioramento senza mai superare il punto di rottura che causerebbe una regressione organizzativa. Questa leadership trasforma lo stress in un catalizzatore evolutivo, guidando l’azienda verso la maturità attraverso quattro dimensioni critiche.

Dimensione 1: gli Atti di Leadership

Gli Atti di Leadership sono la scintilla che rompe l’inerzia ai primi stadi della maturità. Non si tratta di direttive burocratiche, ma di gesti che dimostrano i valori Kanban – trasparenza, equilibrio, rispetto – prima ancora che le pratiche siano consolidate.

Capitale sociale e status

Un principio cardine del KMM è che la leadership deve emergere a tutti i livelli. Quando un individuo compie un atto di leadership assumendosi un rischio che altri non prenderebbero, egli acquisisce status sociale e accumula capitale sociale. Questo prestigio guadagnato sul campo è essenziale per catalizzare l’azione collettiva.

  • Leadership per ispirazione: fornire uno scopo superiore che trascenda le frizioni quotidiane.
  • Leadership per esempio: manifestare coerenza tra parole e azioni (es. rispettare i limiti WIP anche sotto pressione).
  • Leadership per direzione: fornire chiarezza decisionale nei momenti di ambiguità sistemica.

L’impatto: chi si assume un rischio che gli altri evitano guadagna rispetto, e con esso la capacità di muovere il gruppo. Senza atti di leadership, le pratiche rimangono gusci vuoti; con essi, il sistema inizia a muoversi verso la collaborazione.

Dimensione 2: empatia e rispetto (dignità e psicologia sociale)

Un equivoco frequente confonde la leadership con la simpatia: il leader che ammorbidisce i toni, evita i conflitti, cerca il consenso. In Kanban, questa non è empatia, è compiacenza. La vera empatia riconosce il bisogno dell’altro senza rinunciare alla chiarezza. Questo concetto è strettamente legato al thymos, il bisogno umano primordiale di riconoscimento e dignità.

Dallo psicoterapeuta dilettante all’allenatore sportivo

Molti coach cadono nella trappola di comportarsi da psicoterapeuta dilettante, cercando di curare la psiche individuale o l’autoconsapevolezza dei singoli. Nel KMM, l’empatia è ortogonale all’autoconsapevolezza individuale. Non è necessario che un lavoratore conosca perfettamente se stesso per sapere se conduce una vita professionale dignitosa.

  • Focus sulla sociologia: il leader agisce sul gruppo e sulle dinamiche di sistema, non sulla psicoterapia individuale.
  • Rispetto come virtù: il rispetto non è mera cortesia o educazione; è il riconoscimento del valore generato attraverso l’assunzione virtuosa dei ruoli.

L’impatto: definire ruoli chiari e responsabilità non è un atto burocratico, ma un profondo gesto di empatia. Ridurre il sovraccarico (muri) e l’ansia derivante dall’ambiguità è il modo reale in cui la leadership restaura la dignità professionale, aumentando l’autostima collettiva del team.

Dimensione 3: scopo e unità di intenti

Al raggiungimento di ML3, la leadership deve costruire l’unità attraverso un orientamento al servizio. Lo scopo (Purpose) funge da collante sociale per abbattere le barriere dipartimentali e allineare l’intera catena del valore verso la Fitness-for-Purpose per il cliente.

Ruoli critici e congruenza

L’unità di intenti si manifesta attraverso ruoli specializzati che gestiscono il rischio lungo il flusso di lavoro:

  • Service Request Manager (SRM): agisce come Risk Manager per le attività di upstream. È il custode della Definition of Ready, assicurando che solo opzioni di valore e ben comprese vengano prese in carico.
  • Service Delivery Manager (SDM): garantisce che il servizio sia erogato secondo le aspettative, gestendo il flusso downstream e facilitando il miglioramento continuo.

L’impatto: l’unità di intenti è possibile solo se esiste congruenza tra decisioni strategiche e capacità operativa. Se la strategia aziendale ignora la realtà visualizzata dal sistema Kanban, il leader agisce senza congruenza. L’unità nasce quando i processi consistenti sostituiscono gli “eroi” e la strategia riflette fedelmente ciò che il sistema può effettivamente produrre.

Dimensione 4: equilibrio e giustizia quantitativa

Verso il ML4, la leadership compie il passaggio verso la gestione analitica. L’equità non è più un’intuizione emotiva, ma una giustizia quantitativa basata su modelli probabilistici.

Mediocristan vs. Extremistan

Una distinzione fondamentale riguarda la natura del rischio:

  • Mediocristan: è il mondo della statistica tradizionale (distribuzione gaussiana), gli eventi variano attorno a una media e i casi estremi sono rari e non influenzano significativamente il totale. Qui, la priorità è gestita tramite Triage e Classi di Servizio standard.
  • Extremistan: è il mondo dell’innovazione radicale, della ricerca, del cinema o dell’editoria. Qui la media è priva di significato perché un singolo evento poco probabile – un cigno nero – può dominare l’intera distribuzione. Il leader non può gestire questo dominio con il semplice Triage: deve riservare capacità dedicata alla classe di servizio Intangible, garantendo all’innovazione uno spazio protetto dalle pressioni urgenti del Mediocristan.

Il Two-Phase Commit: fiducia e aspettative

Il leader utilizza il Two-Phase Commit per gestire le promesse. Si tratta di separare due momenti distinti: l’impegno a prendere in carico il lavoro, e la promessa di una data di consegna. Il primo può essere dato subito; il secondo solo quando i dati lo supportano. Questo approccio, basato sull’onestà intellettuale e sui dati di lead time storici, protegge l’organizzazione da stress inutili e sorprese economiche.

L’impatto: l’uso di previsioni probabilistiche invece di stime deterministiche (spesso inaffidabili) costruisce un rapporto di fiducia con gli stakeholder. La leadership quantitativa trasforma l’organizzazione in un partner affidabile che decide sulla base di evidenze matematiche, garantendo stabilità economica e operativa.

Sintesi dei ruoli di leadership

L’evoluzione dei ruoli attraverso i livelli di maturità riflette il passaggio dalla gestione dei compiti alla gestione del rischio e del sistema.

Livello di maturitàRuolo di leadershipFocus principaleCompetenza chiave richiesta
ML2 (emergente)Flow ManagerSollievo dal sovraccarico locale e efficienza del flusso.Facilitazione dei meeting e raccolta dati di base.
ML3 (consolidata)Service Delivery Manager/Service Request ManagerValore del servizio e Fitness-for-Purpose.Gestione della presa in carico e negoziazione dei livelli di servizio.
ML4 (ottimizzata)Risk/Operations ManagerGiustizia quantitativa e bilanciamento del rischio economico.Valutazione del rischio e previsioni probabilistiche (Monte Carlo).
ML5 (eccellente)Service Delivery Director/Product ExecutiveRicerca della perfezione e ottimizzazione dell’efficienza economica tramite guadagni marginaliSperimentazione guidata da ipotesi scientifiche e gestione di domini ad alto rischio (Extremistan)
ML6 (antifragile)Senior ExecutiveSopravvivenza a lungo termine, congruenza strategica e reinvenzione dell’identità aziendaleDouble-loop learning (mettere in discussione il “chi” e il “perché”) e sviluppo della cultura per l’antifragilità

Conclusione: verso una leadership antifragile

Cosa significa in pratica reinventare l’identità aziendale sotto pressione? L’esempio di Fujifilm e Kodak lo rende concreto. Entrambe le aziende hanno visto la stessa disruption: la fotografia digitale che rendeva obsoleto il loro core business. Kodak ha risposto difendendo il modello esistente, incapace di mettere in discussione non solo i propri processi, ma il proprio “perché”. Fujifilm ha fatto qualcosa di più radicale: ha applicato il double-loop learning al livello più profondo, chiedendosi non solo “come miglioriamo la pellicola” ma “chi siamo davvero”. La risposta – un’azienda chimica con competenze avanzate in materiali e trattamenti molecolari – ha aperto la strada a mercati completamente nuovi nel settore cosmetico e farmaceutico. La congruenza tra strategia e capacità reale, che nei livelli precedenti si costruisce pazientemente sul flusso di lavoro quotidiano, a ML6 diventa la bussola per reinventare l’intera identità dell’organizzazione.

A questo punto il ruolo dell’allenatore si trasforma. Nei livelli iniziali calibrava lo stress positivo per non superare il punto di rottura, accompagnando il sistema verso pratiche stabili e flusso prevedibile. A ML6 il leader guida un’organizzazione che è diventata capace di dare il meglio di sé sotto pressione. Come certe squadre di calcio che, rimaste in dieci, riorganizzano il gioco e finiscono per vincere proprio perché la riduzione di risorse ha attivato risorse latenti – coesione, intelligenza tattica collettiva, lettura condivisa del campo – l’organizzazione antifragile non gestisce l’imprevisto, lo utilizza come leva per uscirne più forte di prima. È questo il risultato di una leadership che ha costruito, nel tempo, la capacità di trasformare ogni vincolo in vantaggio competitivo.

Pubblicato il

L’A3 Thinking nelle cadenze Kanban: risolvere i problemi giusti nel modo giusto

Ogni organizzazione ha riunioni. Poche organizzazioni hanno riunioni che cambiano davvero qualcosa.

Il metodo Kanban prevede un sistema di cadenze – incontri ricorrenti con scopi precisi – progettate per mantenere il flusso di lavoro sotto controllo e far evolvere il sistema nel tempo. Ma c’è un rischio concreto: senza un approccio strutturato al problem solving, le cadenze diventano sessioni di aggiornamento in cui si osservano i problemi senza capirli e risolverli davvero.

L’A3 Thinking è uno strumento che trasforma questo rischio in un’opportunità.

Single-loop e double-loop learning: due modi di imparare

Immagina un termostato. Quando la temperatura scende sotto la soglia impostata, accende il riscaldamento. Quando la raggiunge, si spegne. Il termostato corregge l’errore in modo efficiente, ma non si chiede mai se la temperatura impostata sia quella giusta per chi vive in quella casa.

Questo è il single-loop learning: si rileva uno scarto tra il risultato atteso e quello ottenuto, e si corregge il comportamento. È utile, necessario, e costituisce la base di quasi tutto il miglioramento operativo. Un team che analizza il proprio Lead Time, identifica un collo di bottiglia e modifica un limite WIP sta facendo single-loop learning e lo sta facendo bene.

Il double-loop learning aggiunge una domanda diversa: non “come correggiamo lo scarto?” ma “perché abbiamo impostato quella temperatura?” Nel contesto organizzativo, significa mettere in discussione i modelli mentali e i presupposti che stanno dietro al sistema, non solo le sue regole operative. Non “come gestiamo meglio le urgenze?” ma “la nostra definizione di urgenza riflette davvero le priorità del cliente? Il servizio che stiamo ottimizzando è ancora quello giusto da offrire?”

Nel Kanban Maturity Model, questa distinzione ha un peso preciso. I livelli da ML1 a ML5 si muovono nel territorio del single-loop learning: l’organizzazione impara progressivamente a fare meglio quello che già fa, gestire il flusso, ridurre la variabilità, coordinare servizi interdipendenti. È al livello ML6 che il double-loop learning emerge pienamente, quando l’organizzazione sviluppa la capacità di interrogarsi sulle quattro domande fondamentali: Come lavoriamo è ancora competitivo? Cosa offriamo è ancora rilevante? Perché esistiamo ha ancora senso nel mercato attuale? Chi siamo è ancora adeguato al contesto?

Perché è importante chiarirlo prima di parlare di A3 Thinking? Perché l’A3 è uno strumento potente per il single-loop learning strutturato e questo non è poco. Trasforma le cadenze Kanban da sessioni di aggiornamento in motori di apprendimento sistematico. Ma il suo contributo al double-loop learning, quando arriva, non riguarda la gestione dei blocchi o l’ottimizzazione del Lead Time: riguarda la capacità di usare i dati del sistema per mettere in discussione la direzione stessa dell’organizzazione.

Il Kanban Maturity Model: un’evoluzione per livelli

Il Kanban Maturity Model (KMM) articola la crescita organizzativa in sei livelli e l’A3 Thinking non è rilevante allo stesso modo per tutti i livelli.

Ai livelli ML1 e ML2, dove il lavoro dipende ancora dagli individui e dal loro buon senso, mancano ancora le basi – dati affidabili, policy esplicite, cultura del feedback – per usarlo efficacemente. È a partire da ML3, quando l’organizzazione arriva a gestire il lavoro come un vero sistema end-to-end, che l’A3 diventa uno strumento di evoluzione reale, ed è ai livelli superiori che esprime tutto il suo potenziale come motore di single-loop learning strutturato, costruendo le fondamenta su cui, a ML6, può emergere il double-loop learning.

Cos’è l’A3 Thinking (e come si usa nelle cadenze Kanban)

L’A3 Thinking è un metodo di problem solving sviluppato in Toyota. Il nome viene dal foglio di carta formato A3: l’idea originale era che un problema – dalla descrizione alla soluzione – dovesse stare tutto su un singolo foglio. Non per superficialità, ma per disciplina. È una forma di slow thinking, pensiero lento e profondo: se non riesci a sintetizzare un problema su una pagina, probabilmente non lo hai ancora capito abbastanza bene.

Il template si compone di cinque sezioni, distribuite su un foglio A3 o su fronte e retro di un foglio A4.

Definizione del problema. Prima ancora di cercare soluzioni, bisogna capire cosa si sta osservando e perché conta. Nelle cadenze di revisione periodica – la Service Delivery Review o la Risk Review – questa è la domanda di apertura: qual è il gap tra la performance attuale del servizio e quello che il cliente si aspetta? Definire bene il problema in questa fase evita di sprecare energie su sintomi invece che su cause.

Analisi del problema. È la sezione più importante, e quella più spesso saltata. L’analisi non si fa a parole, ma con i dati di flusso: quanto tempo impiega mediamente un elemento di lavoro ad attraversare il sistema? Dove si accumula? Quanto tempo passa in attesa rispetto al tempo in cui qualcuno ci sta lavorando davvero? Il modo più efficace per rispondere a queste domande non è scrivere una lista di osservazioni, ma incollare direttamente sul foglio A3 i grafici che raccontano la storia: un Cumulative Flow Diagram (CFD) che mostra dove il lavoro si accumula, un grafico di Lead Time che rivela la variabilità del sistema, un aging chart che evidenzia cosa è fermo da troppo tempo. L’A3 non è un documento di testo con qualche numero: è uno strumento visivo, e la differenza si vede.

Nelle cadenze operative – il Kanban Meeting quotidiano – questa mentalità analitica serve a leggere i blocchi non come eccezioni da risolvere in fretta, ma come segnali che raccontano qualcosa sul sistema. La domanda non è “chi lo sblocca?”, ma “perché si è bloccato?”.

Esperimento e piano di implementazione. Una volta identificata la causa, si progetta un intervento – non una soluzione definitiva, ma un esperimento. Questa distinzione è importante: un esperimento ha un’ipotesi verificabile (“se modifichiamo il limite di lavoro in corso in questo punto, il tempo di attraversamento dovrebbe ridursi”), mentre una soluzione è spesso solo un’opinione con più autorevolezza. Il piano di implementazione definisce chi fa cosa, in quale cadenza si osserveranno i risultati, e quali metriche si useranno per giudicare se l’esperimento ha funzionato. Un esperimento per volta, altrimenti non si riesce a capire cosa ha funzionato e che cosa no.

Risultati dell’esperimento. La cadenza naturale per questa sezione è la Service Delivery Review: si torna sui dati dopo un ciclo sufficiente a produrre segnale, e si misura l’effetto reale dell’intervento. Anche qui, i risultati non si raccontano a parole: si mostrano. Lo stesso grafico usato nell’analisi, aggiornato dopo l’esperimento, dice immediatamente se qualcosa è cambiato e in che direzione. Se il Lead Time si è stabilizzato, il CFD mostra bande più uniformi, se si è ridotto l’aging chart ha meno elementi in zona critica. La continuità visiva tra analisi e risultati è parte del metodo: rende evidente il confronto e riduce lo spazio per le interpretazioni di comodo. Questo passaggio è quello che trasforma un’opinione in apprendimento. Senza di esso, il sistema non impara, accumula solo iniziative.

Prossimi passi. Se l’esperimento ha funzionato, il risultato non è “problema risolto” ma “nuova policy da codificare”. Una regola di ingresso rivista, un criterio di priorità esplicitato, una soglia di allerta definita. È qui che il cambiamento smette di dipendere dalla memoria delle persone e diventa parte del sistema. Se invece l’esperimento non ha prodotto i risultati attesi, i prossimi passi riportano all’analisi con nuove informazioni.

Questa struttura ciclica è ciò che distingue l’A3 da una normale checklist: non si compila una volta, si percorre più volte, ciascuna con una comprensione più profonda del problema.

Il problema che l’A3 risolve nelle cadenze Kanban

Nelle organizzazioni ai livelli ML1 e ML2, i problemi vengono ancora affrontati in modo reattivo: è single-loop learning, ma applicato in modo caotico e inconsapevole, senza che l’organizzazione ne tragga apprendimento stabile.

Il salto verso ML3 non è un salto verso il double-loop learning: è il passaggio a un single-loop learning maturo, strutturato e consapevole. L’A3 Thinking può supportare questo passaggio spostando il focus dalle persone al sistema. La domanda non è “chi ha sbagliato?” ma “cosa nel nostro modo di lavorare produce questo risultato?” È una distinzione che Deming aveva reso famosa decenni fa, e che ancora oggi fatica a entrare nella cultura di molte aziende.

Ai livelli ML4 e ML5, quando le decisioni si basano su modelli probabilistici e il miglioramento si estende oltre i confini del singolo team, l’A3 consolida questo percorso: aiuta a orchestrare il miglioramento tra servizi interdipendenti, a gestire il rischio in modo strutturato, a rendere l’apprendimento operativo una pratica normale e non un evento eccezionale. Sempre nell’ambito del single-loop learning, ma portato alla sua massima maturità, come preparazione al salto qualitativo che avviene a ML6.

Dall’analisi alla policy: il cambiamento che rimane

Un problema risolto una volta non è un problema risolto. Lo è solo quando la soluzione viene codificata in una regola esplicita che il sistema segue anche quando chi ha trovato la soluzione non c’è più.

L’A3 Thinking, in questo percorso, è uno strumento che aiuta a costruire le fondamenta. Senza la disciplina del single-loop learning strutturato – senza la capacità di analizzare, sperimentare e codificare – il double-loop rimane un esercizio intellettuale senza radici operative. Le organizzazioni che arrivano a ML6 non saltano i livelli precedenti: li attraversano, e l’A3 è parte di come lo fanno.

Una nota finale

W. Edwards Deming diceva che l’apprendimento non è obbligatorio, così come non lo è la sopravvivenza. L’A3 Thinking nelle cadenze Kanban non è una tecnica sofisticata riservata alle organizzazioni avanzate. È il modo in cui si fa sul serio con il miglioramento continuo a partire da ML3: guardare i dati, capire il sistema, cambiare le regole. E ricominciare.

Pubblicato il

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 misurarePerché
ThroughputMisura il lavoro realmente completato, non l’occupazione di tempo
Lead time / SLAPermette di prendere impegni misurabili con gli interlocutori interni ed esterni
Distribuzione per attivitàRende visibili i colli di bottiglia e bilancia i carichi
Volume storicoPermette di anticipare i picchi invece di subirli
Cadenze di revisioneTrasforma 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.

Pubblicato il

Il tuo cliente non è il problema. Il tuo sistema di gestione sì.

Lavorare con i clienti oggi assomiglia sempre più a un tentativo di domare un incendio con un bicchiere d’acqua. “È urgente”, “Serve per ieri”, “Questa è la priorità assoluta”: sono i mantra di un’apnea operativa che prosciuga energie e qualità. Molti professionisti accettano questo stato di perenne emergenza come un destino ineluttabile, una sorta di tassa sul fatturato da pagare al “caos del mercato”.

Ma la verità è un’altra: il disordine non è una fatalità, è un fenomeno che può essere governato. La differenza tra un team che affoga e uno che domina la scena non sta nella fortuna di avere clienti “educati”, ma nel possedere gli strumenti mentali per processare l’imprevisto. Il caos non va subito, va gestito con un sistema.

1. Diventare campioni delle ‘palle alzate male’: la lezione di Velasco

Nel management, come nella pallavolo di alto livello, la vera maestria non si vede quando tutto è perfetto. È facile fare punto quando l’alzata è precisa e il tempo è giusto. Ma la realtà è fatta di situazioni critiche, imprecise, disturbate. Julio Velasco, oltre che grande allenatore di Volley, un vero filosofo del pragmatismo e avversatore della cultura degli alibi, ha codificato questo concetto parlando di file delle soluzioni. Un professionista di valore non è quello che aspetta le condizioni ideali, ma quello che si è addestrato a colpire anche quando tutto va storto.

Come ci ricorda Velasco in un suo famoso speech che potete rivedere cliccando qui:

“…io voglio schiacciatori che schiacciano bene palloni alzati male, voglio questi. Perché questi, poi, quelli alzati bene li schiacciano benissimo, non bene. Uno che schiaccia bene i palloni alzati male, quelli alzati bene li schiaccia benissimo, voglio quelli lì. Quindi non ne parliamo, risolviamo. Se la realtà è come è, e non come io voglio che sia, se la palla è bassa, il mio cervello – che è un computer straordinario – deve aprire tutti i file con il titolo ‘palla alzata bassa’ e in questi file ci sono le soluzioni per le palle alzate basse, che sicuramente non è schiacciarla come se fosse alta….”

La competenza risiede nella varietà delle risposte che abbiamo codificato. Non dobbiamo sperare che il cliente smetta di inviarci ‘palle alzate male’; dobbiamo arricchire il nostro archivio interno affinché nessuna situazione ci trovi impreparati. Gestire l’imprevisto non è un atto di improvvisazione, è l’applicazione di una soluzione già studiata per un problema che sapevamo sarebbe arrivato.

2. Smascherare le false urgenze con la ‘Via Negativa’

Per non soccombere, bisogna imparare l’arte della distinzione. Quando tutto è prioritario, nulla lo è. Qui entra in gioco la ‘Via Negativa’ di Nassim Taleb: la capacità di decidere cosa non fare o cosa rimandare per preservare l’integrità del sistema.

Per farlo, dobbiamo analizzare il Cost of Delay (costo del ritardo). Invece di subire l’urgenza del cliente, proviamo a sottoporre una domanda coraggiosa e provocatoria: “se tolgo questa specifica funzionalità o consegna, succede qualcosa di irreparabile domani mattina?”. Se la risposta è no, il Costo del Ritardo è basso. Non è un’urgenza, è solo rumore.

Vi racconto un caso reale. Era agosto, ero al mare, quando ricevo la chiamata di uno dei project manager di cui ero responsabile, disperato: un cliente pretendeva la consegna dell’intero progetto per il 1° ottobre. Una richiesta tecnicamente impossibile per la nostra capacità produttiva. Invece di cedere alla pressione emotiva, abbiamo applicato la Via Negativa. Il project manager ha negoziato con il cliente, distinguendo ciò che era vitale da ciò che era solo desiderio. Il risultato? Abbiamo consegnato le funzionalità essenziali il 20 ottobre (con fatica, ma con successo) e abbiamo scaglionato tutto il resto fino a gennaio. Il mondo non è crollato; al contrario, il nostro sistema ha retto e il cliente ha ottenuto ciò che gli serviva davvero per operare, non ciò che pensava di volere “per ieri”.

3. Studiare la fenomenologia del cliente per giocare d’anticipo

C’è un errore fatale che molti commettono: considerare le urgenze dei clienti come eventi casuali e imprevedibili. Non è così. Sebbene non possiamo controllare la volontà del cliente, possiamo analizzare i suoi pattern di comportamento. La fenomenologia del cliente ci dice che la casualità è meno casuale di quanto sembri.

La Customer Awareness non è cortesia, è intelligence. Significa mappare i comportamenti dei committenti come dati statistici e trasformarli in una variabile del nostro piano operativo:

  1. Identificazione dei pattern: analizziamo quante volte e in quali periodi arrivano le richieste “prima di subito”. Se succede ogni mese, non è un’urgenza, è un dato prevedibile. Smettiamo di sperare che non arrivino e iniziamo a costruire il nostro sistema intorno a questa certezza statistica.
  2. Modellazione della fenomenologia: trattiamo il disordine del cliente come una variabile del sistema. Se sappiamo che un certo cliente cambia idea tre volte prima della chiusura, non pianifichiamo l’esecuzione finale finché non ha superato il suo terzo ‘ripensamento’ statistico.
  3. Difesa preventiva: usiamo questi dati per pre-allocare le risorse e gestirne le aspettative prima ancora che il cliente alzi il telefono.

Se analizziamo statisticamente i dati, scopriamo che le urgenze arrivano con una frequenza e una ciclicità misurabili. Mappare questi schemi permette di smettere di farsi sorprendere. La strategia non è far cambiare il cliente, ma mappare la sua imprevedibilità per trasformarla in una variabile del nostro piano operativo.

4. La Capacity Reservation: il segreto per non essere mai in ritardo

Una volta compresa la fenomenologia, nel metodo Kanban la soluzione tecnica è un sistema dinamico di Capacity Reservation (prenotazione della capacità). L’errore fatale di molti manager è saturare la capacità produttiva al 100%. Non funziona, un sistema saturo al massimo della capacità ha tempi di attesa infiniti al primo intoppo. È necessario invece lasciare sempre un buffer di capacità non allocata, gestito in modo dinamico.

Il meccanismo è chirurgico e si basa di nuovo sul Cost of Delay:

  • Classe di servizio Expedite: qui inseriamo solo le urgenze vere, quelle dove ogni giorno di ritardo costa all’azienda soldi o reputazione. Queste attività occupano la capacità che abbiamo tenuto libera.
  • Gestione del backlog: e se l’urgenza non arriva? Non restiamo con le mani in mano. Quella capacità riservata viene usata per avanzare con il lavoro meno urgente in attesa in coda.

Questo approccio ribalta la dinamica della performance professionale. Il mantra diventa: “se ci dice bene siamo in anticipo, se ci dice male siamo puntuali”. Ci liberiamo finalmente dalla trappola tossica del “se va bene siamo puntuali, se va male siamo in ritardo”. La puntualità non è più una speranza, ma una garanzia del sistema.

Basta alibi: gestire il disordine è una scelta

È ora di smetterla di usare il “disordine italiano” o l’indisciplina dei clienti come scusa per una cattiva gestione interna. Incolpare il cliente per la propria disorganizzazione è un fallimento manageriale. Affermare che i clienti sono impossibili da gestire è l’ultimo alibi di chi non ha costruito un sistema capace di assorbire la realtà.

L’efficienza non dipende dalla natura del cliente, ma dalla robustezza della nostra architettura di lavoro. Attraverso la misurazione dei flussi, la visualizzazione dei pattern e l’applicazione di pratiche Kanban avanzate, possiamo governare anche i contesti più turbolenti. Il disordine esterno non giustifica il caos interno: la gestione dei sistemi complessi è una responsabilità organizzativa, non una questione di fortuna.

Conclusione: la serenità professionale è una scelta tecnica

Gestire il disordine non è una dote naturale. È un’architettura che si costruisce, mattone dopo mattone, a partire da una scelta consapevole.

Il futuro della tua attività non dipende da quanto diventeranno disciplinati i tuoi clienti, ma da quanto diventerà solido il tuo sistema di gestione. La domanda che ti lascio è provocatoria ma necessaria: preferisci continuare a subire l’indisciplina del mercato, o vuoi iniziare a mappare i tuoi problemi per risolverli una volta per tutte?

La serenità professionale è una scelta tecnica. E quella scelta inizia oggi.