Tag: Kanban Maturity Model

Pubblicato il

ITIL5 e le metriche del ciclo di vita: dove entra Kanban e dove serve l’intelligenza artificiale

Ho appena terminato di tenere un corso ITIL 5 Foundation. Mentre raccontavo le otto attività del nuovo ciclo di vita dei prodotti e dei servizi, a ciascuna era associato un elenco di metriche di successo, e continuavo a vedere passare metriche che conosco molto bene: sono quelle tipiche dei sistemi Kanban. Avrei voluto fermarmi a raccontare cosa dice il Kanban Maturity Model (KMM) su quelle misure. Chi segue un corso come questo spesso vorrebbe anche capire come si fa nella pratica, ma un corso ITIL deve attenersi al contenuto dell’esame e non è il luogo per approfondire la parte pratica. Allora provo a farlo in questo articolo, almeno per dare qualche spunto.

Un secondo punto mi ha fatto riflettere durante il corso. ITIL 5 collega l’intelligenza artificiale alla visione olistica, quella che in Kanban chiamiamo visione sistemica (Systems Thinking), e all’individuazione dei colli di bottiglia, e dice che i miglioramenti del flusso vanno concentrati proprio lì. È un buon punto di partenza. Io ci aggiungo dove applicarla concretamente: a monte del collo di bottiglia intasa ancora di più, a valle accelera qualcosa che non ne ha bisogno. In aula ho fatto un breve accenno al concetto, qui vorrei provare a spiegarlo meglio.

Cosa introduce ITIL 5

ITIL 5 introduce un modello di ciclo di vita di prodotti e servizi digitali con otto attività: Discover, Design, Acquire, Build, Transition, Operate, Deliver, Support. ITIL precisa che non vanno eseguite come un ciclo: dal punto di vista dell’organizzazione formano la catena del valore, cioè l’insieme delle attività che abilitano il valore. Ogni organizzazione ne include alcune o tutte e le combina, secondo il proprio contesto, nei flussi del valore (value stream).

La novità rispetto a ITIL 4 è che a ciascuna attività è associato un elenco di metriche chiave di successo. In ITIL 4 le metriche stavano nelle pratiche. Cycle time, wait time e lead time c’erano già, ma a livello di flusso e di pratiche, non di attività.

Guardando l’insieme delle metriche, alcune saltano all’occhio. La soddisfazione compare in tutte e otto le attività: quella degli stakeholder in sette, quella di clienti e utenti in Deliver e in Support. L’aderenza alla roadmap o alla strategia in sette. Un tempo esplicito compare in quattro: Design, Acquire, Build e Transition, a cui si aggiunge la velocità di ripristino in Support. Discover, Operate e Deliver non hanno nessuna metrica di tempo.

Le metriche e il Kanban Maturity Model

Le corrispondenze con il KMM sono molte.

Per la transizione ITIL misura il numero e l’impatto degli errori di transizione, cioè dei rilasci andati male. Un rilascio andato male genera rilavorazioni, e il lavoro che ne nasce nel KMM si chiama failure demand: la domanda che arriva perché la qualità iniziale non bastava.

Per la qualità ITIL misura specifiche, risorse e soluzioni. Nel KMM la qualità si misura sul risultato finale: la quota di richieste consegnate senza rilavorazione. Quando si registra una rilavorazione, occorre risalire a quali specifiche, risorse o soluzioni l’hanno generata.

Per Deliver e Support ITIL misura la performance rispetto agli SLA concordati. Nel KMM corrispondono la puntualità di consegna e gli impegni di servizio basati sui percentili di lead time.

Per la soddisfazione di stakeholder, clienti e utenti ITIL ha una misura in ogni attività. Nel KMM corrispondono gli indicatori di fitness for purpose, ricavati dai criteri con cui il cliente sceglie il servizio.

Poi in ITIL troviamo le metriche di tempo: design cycle time, acquire cycle time, building cycle, transition cycle e velocità di ripristino. Nel KMM le grandezze corrispondenti sono lead time e cycle time, che si leggono come percentili sulle rispettive curve di distribuzione.

Cosa ITIL 5 dice sul livello operativo

ITIL 5 fornisce la cornice concettuale, il modello di ciclo di vita e i principi guida per orientare le decisioni, e lascia il dettaglio delle procedure operative ad altre fonti: le ITIL Practice Guide ufficiali, DevOps, PRINCE2 per il project management. Lo stesso ITIL dichiara che nessun framework da solo basta. Tratta anche il flusso, con la mappatura dei flussi del valore, e usa le metriche di tempo per individuare colli di bottiglia e ritardi.

Su Kanban dice due cose. Lo definisce come un metodo per visualizzare il lavoro, individuare blocchi e conflitti di risorse e gestire il lavoro in corso. E cita le Kanban board tra gli strumenti per dare visibilità agli stakeholder. Non compaiono né il funzionamento pull né i limiti al lavoro in corso. A mio avviso la rappresentazione che ITIL offre di Kanban è semplificata, come già scrivevo a proposito di ITIL 4: il metodo è molto più ricco.

Io propongo Kanban per governare e gestire i flussi. Per governare i flussi intendo applicare le pratiche e i principi del metodo Kanban, come specificati nel Kanban Maturity Model. Nel KMM il verbo governare si riferisce alle policy, che regolano il comportamento di persone e team, mentre il flusso di lavoro si gestisce. Io uso i due verbi insieme: le policy governano, e il lavoro scorre e si gestisce dentro quei confini.

Dalle metriche alla pratica

Prendiamo per esempio i rilasci andati male. In ITIL si misura il numero e l’impatto degli errori di transizione. In Kanban ragioniamo per work item, che attraversano il flusso. Se un work item arriva al rilascio e il rilascio va male, viene conteggiato e nasce un nuovo work item, marcato come failure demand: un rifacimento di qualcosa che era già stato fatto. Così facendo sappiamo in ogni momento quanta percentuale complessiva del lavoro è costituita da rilavorazioni.

Quanto possono pesare in percentuale le rilavorazioni? In Kanban: Successful Evolutionary Change for Your Technology Business, David Anderson riporta il caso di un team che spendeva il 90% della capacità disponibile nella correzione di difetti. Un flusso così è intasato da lavoro che nasce da lavoro già fatto male, e le nuove richieste aspettano.

Nelle organizzazioni più mature le rilavorazioni contano contro il limite del lavoro in corso: se ce ne sono troppe, non entra nuovo lavoro finché i problemi di qualità non sono stati risolti. I dati su difetti e rilavorazioni si guardano poi nelle revisioni periodiche, dove si decide cosa fare per ridurli.

Passiamo alla performance rispetto agli SLA concordati. In Kanban lo SLA si costruisce partendo dai dati: si misurano i lead time dei lavori consegnati e se ne costruisce la curva di distribuzione. Dalla curva si leggono i percentili e, in base al percentile opportuno, si definisce la service level expectation (SLE): entro quanti giorni consegno e in quale percentuale di casi. L’85° percentile è il riferimento abituale, ma non è una regola: se un ritardo costa molto, conviene salire. Sulla base dello SLE definito si concorda lo SLA con il cliente in modo realistico.

Le metriche di tempo che ITIL associa alle attività, cioè design cycle time, acquire cycle time, building cycle e transition cycle, misurano ciascuna un singolo passaggio. ITIL ha poi una misura dell’intero flusso del valore, il lead time, dall’avvio alla consegna, e indica le otto attività come un buon punto di partenza per mappare i flussi. ITIL non dice però da dove parta il lead time.

Il KMM lo precisa, e parla dello stesso oggetto: quello che ITIL chiama flusso del valore, nel KMM è il workflow. Il customer lead time parte dalla richiesta accettata del cliente, il system lead time dalla presa in carico del lavoro da parte del team, ed entrambi arrivano alla consegna. Quando si applica Kanban si misurano sia le metriche end to end sia quelle dei singoli passaggi, e anche le attese, e in base a queste misure si ragiona su come ottimizzare il flusso.

Un passaggio può avere un buon tempo di ciclo e il cliente aspettare comunque a lungo, perché nel tempo di ciclo non ci sono le attese tra un passaggio e l’altro. L’esperienza dice che le attese sono la parte prevalente del lead time, e di diversi casi ho scritto anche su questo blog. Per questo si lavora sulle attese: limitando il lavoro in corso, riducendo code e buffer, gestendo meglio blocchi e dipendenze.

Lo stesso vale per la velocità di ripristino del servizio, che in ITIL compare in Support. È il lead time della gestione degli incidenti, e come ogni altra metrica di tempo si misura con la distribuzione, si legge con i percentili e si trasforma in uno SLE.

Resta la soddisfazione di stakeholder, clienti e utenti, che ITIL misura in tutte e otto le attività. Nel KMM non la si misura chiedendola in astratto. Si parte dai criteri con cui il cliente decide se richiedere il servizio, o dalle fonti della sua insoddisfazione, e da lì si ricavano gli indicatori da misurare: tempi di consegna per classe di servizio, quota di richieste consegnate senza rilavorazione, costo.

È quello che facciamo in continuazione con le aziende con cui collaboro. Partiamo dalle fonti di insoddisfazione, che mi raccontano i clienti. Quando abbiamo messo a posto il servizio, verifichiamo se quelle fonti sono state risolte. Gli indicatori non sono necessariamente solo quelli classici di Kanban: dalle fonti di insoddisfazione possono emergere altri aspetti da misurare, e li misuriamo. In questo modo la fitness for purpose diventa la sintesi di tutte le metriche, classiche e no.

L’intelligenza artificiale: dove serve e dove no

ITIL 5 dedica molto spazio all’intelligenza artificiale, e la collega alla visione olistica e all’individuazione dei colli di bottiglia. Dice anche di concentrare i miglioramenti del flusso proprio sui colli di bottiglia, e di ottimizzare il flusso prima di automatizzarlo. È un buon punto di partenza.

Una volta definito il flusso, si misura e si individua il collo di bottiglia, ed è lì che va applicata l’AI. Se la si applica a monte, il lavoro si accumula davanti al collo di bottiglia e il lead time peggiora. Se la si applica a valle, il lead time non cambia in modo apprezzabile, e può essere anche uno spreco: si accelera una stazione di lavoro che è già più scarica del collo di bottiglia. Prendiamo uno sviluppo software: se l’AI fa scrivere il codice più in fretta, ma il collo di bottiglia, a monte, è la risposta del cliente sui requisiti poco chiari, il lavoro accelerato resta in attesa. Non è cambiato nulla.

C’è poi un secondo ragionamento. Spesso il lavoro è fatto per lo più di attese, e accelerare il lavoro effettivo, come fa l’AI quando velocizza un compito, cambia poco il lead time. Ne ho scritto in un articolo recente, e lì la domanda diventa un’altra: come usare l’AI per ridurre le attese.

Conclusione

Sono partito da ITIL 5, che dice cosa misurare per ciascuna attività del ciclo di vita e rimanda ad altre fonti per il dettaglio operativo. Io propongo Kanban per governare e gestire i flussi, e le metriche sono il punto da cui si comincia. I rilasci andati male diventano failure demand, gli SLA nascono dalla distribuzione dei lead time, la soddisfazione si ricava dalle fonti di insoddisfazione di chi usa il servizio, e le metriche di tempo si leggono su tutto il flusso, non solo su un singolo passaggio.

Anche per l’intelligenza artificiale vale lo stesso ragionamento: serve dove c’è il collo di bottiglia, non dove il lavoro è già veloce. E resta necessario qualcuno che gestisca il sistema di lavoro, AI compresa.

Bibliografia

  1. ITIL® Foundation, Version 5, manuale ufficiale, e ITIL® (Versione 5) Glossario principale, v5.1, luglio 2026, PeopleCert.
  2. David J. Anderson, Teodora Bozheva, Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention, 2nd Edition, Kanban University Press, 2021.
  3. David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010.

Pubblicato il

Come funziona Kanban: dalla stima alla previsione, quando il fornitore sono io

Nell’articolo precedente ho raccontato come prendere le misure a un fornitore lento: misurare io il tempo che passa tra la mia richiesta e la sua risposta, quella che chiamo ‘metrica reciproca’, e regolarmi di conseguenza. Chiudevo con un’osservazione: il livello di servizio che dichiaro a valle deve tenere conto di quello che so del mio fornitore.

Resta però una domanda: quale livello di servizio dichiaro, io? Perché a valle il fornitore sono io. E il mio cliente, che io mi misuri o no, prima o poi la metrica reciproca la prende a me. Esattamente come io l’ho presa al mio fornitore.

Prendere le misure a me stesso

Quando un cliente chiede “per quando?”, di solito si tende a rispondere con una stima. Si guarda il lavoro, si valuta quanto è complicato, si pensa a com’è andata l’ultima volta e si ipotizza una data. È un’opinione, magari esperta, ma resta un’opinione. Una previsione funziona in un altro modo: non guarda il singolo lavoro, guarda come sono andati tutti i lavori simili. Non è un’opinione, è statistica.

Per fare questo lo strumento lo conosciamo già: è la stessa curva di distribuzione del Lead Time che ho costruito per il fornitore, solo che questa volta riguarda la parte del servizio che gestisco io. Con un’avvertenza su cosa misurare, perché è qui che ci si inganna più facilmente.

Il Kanban Maturity Model (KMM) distingue il Customer Lead Time, che parte da quando il cliente fa la richiesta, dal System Lead Time, che parte da quando io la prendo in carico. In mezzo c’è l’attesa all’ingresso: la richiesta è arrivata, ma nessuno ci sta ancora lavorando. Quell’attesa tendo a non vederla, perché per me il lavoro non è ancora cominciato. Il cliente invece la subisce per intero. Se misuro solo il System Lead Time, la mia previsione è strutturalmente ottimistica e il cliente aspetta sistematicamente più di quanto dicano i miei dati.

“I dati non li abbiamo”

Quando ne parlo nelle aziende arriva quasi sempre un’obiezione: “bello, ma i dati non li abbiamo”. In realtà ci sono quasi sempre, solo che non vengono usati. Ogni lavoro chiuso ha lasciato una traccia: una data in cui è stato chiesto e una in cui è stato consegnato, in un sistema di ticketing, in una mail, in un registro, a volte in un foglio Excel che qualcuno compila per abitudine. Non servono strumenti sofisticati per cominciare, serve la disciplina di raccogliere i dati. E, come abbiamo visto nel precedente articolo, se il sistema è stabile una trentina di misurazioni bastano per avere un primo quadro affidabile.

“Ma ogni lavoro è diverso”

La seconda obiezione che ricevo in azienda è più radicata: “il nostro lavoro non si presta, ogni cliente ha esigenze uniche, ogni progetto è un caso a sé”. È vero solo in parte. Il lavoro davvero unico esiste, ma è molto meno di quanto ci piace pensare. Il resto è fatto di attività che ripetiamo ogni settimana, solo che non le tracciamo, e quello che non vediamo ci sembra imprevedibile per definizione.

Di solito il lavoro non è tutto diverso: è di pochi tipi diversi. E i dati, curiosamente, lo mostrano da soli. Il KMM osserva che quando la distribuzione del Lead Time ha più picchi, in genere è perché dentro ci sono più tipi di lavoro mescolati. La risposta, quindi, non è rinunciare a misurare perché “tanto è tutto diverso”, ma separare i dati per tipo e costruire una curva per ciascuno. Tre o quattro tipi di lavoro diventano tre o quattro distribuzioni, e tre o quattro previsioni, ognuna sufficientemente affidabile per il suo tipo.

Dalla distribuzione allo SLE

Dalla distribuzione nasce il livello di servizio che posso dichiarare al cliente, lo SLE (Service Level Expectation): entro quanto tempo consegno, e in quale percentuale di casi. Perché sia una promessa e non un azzardo, però, servono due condizioni.

La prima è che la coda sia sottile, cioè che il rapporto tra il 98° percentile e la mediana stia sotto 5,6. Se la coda è grassa, qualunque numero dichiari è fragile: prima o poi arriva il caso che va lunghissimo e smentisce tutto. In quella situazione il primo lavoro non è promettere, è accorciare la coda statistica.

La seconda è scegliere il percentile giusto. L’85° è il riferimento comune per i servizi, sei volte su sette, ma non è una regola che vale sempre. Dipende da quanto costa al cliente un ritardo: se il ritardo costa molto, conviene salire.

Distribuzione del Lead Time dell’onboarding dopo il primo mese

Un buon esempio di quanto descritto è il caso dell’onboarding di Grow, di cui parlo nell’articolo Migliora le tue risorse umane con Kanban: Kanban in HR – Scaling Kanban in an HR department at Grow (Italy) (case study in inglese). Quando abbiamo cominciato a misurare, il Lead Time andava da 1 a 96 giorni: una coda grassa, su cui nessuna promessa poteva essere affidabile. Non abbiamo dichiarato niente. Siamo intervenuti su uno dei colli di bottiglia, la firma digitale del contratto, e in un mese la coda si è accorciata fino a diventare sottile (19 giorni), con una distribuzione dei tempi di onboarding come nell’immagine. Solo a quel punto abbiamo dichiarato ai reparti richiedenti uno SLE: 8 giorni nel 91% dei casi.

Abbiamo tenuto il percentile più alto dell’85° perché un ritardo nell’onboarding non era un semplice disagio: significava persone al lavoro senza un contratto firmato, con il rischio di sanzioni. Lo stesso servizio, con un costo del ritardo più basso, avrebbe potuto reggersi su un percentile diverso.

Cosa vuole davvero il cliente

Si pensa spesso che il cliente voglia tutto e subito, e che l’unico modo per farlo contento sia promettere tempi brevi. In realtà quello che spesso cerca è un’altra cosa: risposte oneste e previsioni affidabili, con cui fare a sua volta le sue previsioni.

È il meccanismo dell’articolo precedente, visto dall’altra parte del tavolo. Il mio SLE diventa il dato su cui il mio cliente pianifica, esattamente come lo SLE del mio fornitore era il dato su cui pianificavo io. Una data detta con sicurezza, che poi slitta, magari più volte, non gli serve a niente: lo costringe a ripianificare ogni volta. Una previsione affidabile con una probabilità dichiarata invece gli permette di regolarsi. La catena regge solo se ogni anello è onesto e affidabile, e io sono uno degli anelli.

Conclusione

Non è vero, quindi, che non posso promettere niente di affidabile. Come minimo posso misurarmi, con gli stessi strumenti con cui misuro il fornitore, e sapere cosa posso dichiarare. Posso separare i tipi di lavoro invece di nascondermi dietro il “è tutto diverso”, accorciare la coda dove serve prima di promettere, e scegliere il percentile in base a quanto costa davvero un ritardo. E posso dare al mio cliente esattamente quello che io chiedo al mio fornitore: una previsione onesta.

Al giorno d’oggi, poi, c’è una nuova tentazione, più forte che mai: usare l’AI e lasciare che sia lei a fare le previsioni al posto nostro. Ma se il lavoro non è tracciato, l’AI una risposta la dà comunque, sicura e ben presentata, solo che non ha fondamento. È una stima come quella descritta più sopra, ma quando esce da un sistema automatico con un numero e un grafico, smette di sembrare un’opinione e nessuno la mette più in discussione. Decidere cosa misurare e come resta una scelta umana, come ho spiegato nell’articolo Perché collegare l’AI ai vostri dati di flusso non basta.

Quest’ultimo tema è così importante che ho deciso di dedicargli un podcast, che prenderà il via il prossimo mese di novembre. Restate sintonizzati!

Bibliografia

  1. David J. Anderson, Teodora Bozheva, Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention – 2nd Edition, Kanban University Press, 2021

Pubblicato il

Come funziona Kanban: se il fornitore è lento, non è vero che non posso farci niente

Una frase che mi capita spesso di sentire è più o meno questa: “Noi potremmo organizzarci meglio e rendere prevedibile il nostro lavoro, ma i tempi di certe operazioni dipendono dagli altri. Non possiamo farci niente.”

Ogni volta che l’ho sentita ho pensato che avrei dovuto scrivere questo articolo. Perché non è vero che non ci si può fare niente: si può fare qualcosa, e anche di abbastanza semplice.

Chiamo fornitore chiunque debba fare qualcosa per me senza che io ne abbia il controllo. Può essere un’azienda esterna, ma anche un collega di un’altra funzione.

Prima di tutto, misurare

Se dipendo da qualcuno che ci mette tanto tempo, la prima cosa da capire è cosa vuol dire quel “tanto”. Se il fornitore non mi dà le sue metriche, le prendo io: è quella che chiamo ‘metrica reciproca’. Misuro il tempo che passa da quando faccio la richiesta a quando ricevo la risposta, e lo faccio abbastanza a lungo da costruire una curva di distribuzione del Lead Time.

Non servono migliaia di dati. Se il fenomeno è consistente, cioè se i tempi restano più o meno sempre nello stesso range, siamo in quello che Taleb chiama Mediocristan. Il Kanban Maturity Model (KMM) offre una regola pratica per verificarlo: il rapporto tra il 98° percentile e la mediana deve stare sotto 5,6. In quel caso una trentina di misurazioni bastano per avere un quadro piuttosto affidabile.

Abbastanza spesso, a misure prese, scopro una cosa banale: il fornitore non è imprevedibile, è semplicemente più lento di quanto dichiara. E lo è in modo costante.

Decidere con i dati

Il riferimento abituale è l’85° percentile: sei volte su sette la risposta arriva entro quel tempo. Il KMM definisce il Lead Time proprio così: se so quando mi serve la consegna, il Lead Time è l’anticipo con cui devo fare l’ordine per aspettarmi di riceverla in tempo.

A questo punto confronto quel valore con il tempo di cui ho bisogno. Se la risposta mi serve più in là dell’85° percentile, la richiesta va in classe di servizio standard: la mando con il giusto anticipo e so che, storicamente, arriverà in tempo. È inutile sollecitare, ed è inutile sorprendersi ogni volta dei tempi lunghi. Li conosco.

Se invece mi serve prima, il rischio di andare lunghi è più alto di quello che posso permettermi, e la richiesta va segnalata come urgente. Più il tempo è stretto, più il rischio è alto, e la distribuzione mi dice esattamente quanto. L’urgenza però deve restare un’eccezione: se tutto arriva urgente, il fornitore smette di crederci. Per questo conviene giocare d’anticipo il più possibile.

Provare a pressare e poi misurare di nuovo

“Va bene, ma allora come facciamo?” A questo punto posso fare un esperimento: pressare il fornitore e vedere cosa succede alla distribuzione. Se si comprime e l’85° percentile rientra nel tempo che mi serve, ho trovato un pattern su cui contare: il pressing diventa strutturale e lo faccio di default. Se non si comprime, ho comunque imparato che quella leva non funziona.

In ogni caso devo continuare a misurare, perché il pressing cambia il sistema. E devo tenere a mente che, se i miei tempi si accorciano, forse sto solo passando davanti agli altri clienti del fornitore: io miglioro, il suo sistema no.

Le misure servono anche a valle. Se a mia volta devo garantire dei tempi a un cliente, interno o esterno, il mio livello di servizio atteso (SLE – Service Level Expectation) deve tenere conto di quello che so del mio fornitore. È inutile promettere cose che so già di non poter mantenere a causa di qualcun altro.

Un caso reale

Con un fornitore con cui c’è una buona collaborazione dovevamo chiudere un progetto. Il fornitore dichiarava di poter finire entro fine febbraio, e per farcela avrebbe dovuto rilasciare circa nove work item a settimana. Gli abbiamo preso le misure, ricostruendole da progetti passati: ne rilasciava tre, in modo piuttosto stabile.

Non potevamo triplicare il suo Throughput, così abbiamo triplicato il tempo e pianificato la consegna per fine aprile. A lui abbiamo continuato a indicare fine febbraio. Abbiamo misurato il Throughput e non il Lead Time, ma con un sistema stabile vale la Legge di Little e il risultato non cambia: circa tre mesi.

Il progetto si è chiuso, come previsto, a fine aprile. La scadenza più stretta non ha accelerato nulla: il fornitore ha tenuto il suo ritmo. Noi però siamo arrivati puntuali, perché avevamo pianificato sui suoi numeri e non sulle sue dichiarazioni.

Successivamente ho condiviso con lui, in modo trasparente, cosa avevamo misurato e cosa avevamo fatto. E lui ha cambiato approccio.

Conclusione

Quindi no, non è vero che non posso farci niente. Come minimo posso misurare, e sapere cosa posso promettere a mia volta. Poi posso giocare d’anticipo, sperimentare il pressing e vedere se cambia qualcosa. E posso portare i dati al fornitore, perché il suo sistema può migliorarlo solo lui.

Chi ha già un sistema Kanban strutturato può fare il passo successivo con le classi di dipendenza, di cui ho scritto nell’articolo Come funziona Kanban: gestire le dipendenze esterne con le classi di dipendenza.

Bibliografia

  1. David J. Anderson, Teodora Bozheva, Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention – 2nd Edition, Kanban University Press, 2021

Pubblicato il

Perché Boyd bocciò la parola “Lean” (e cosa c’entra con la maturità di un sistema Kanban)

Prendo spunto da un articolo che ho letto su LinkedIn, scritto da Brian Rivera, che racconta un lavoro poco conosciuto: la trascrizione delle note a margine lasciate da John Boyd, il colonnello dell’aviazione americana che ha ideato gli OODA loop e che è considerato uno dei pensatori più influenti della strategia militare e organizzativa del Novecento, sui libri da lui letti, oggi conservati negli archivi di Quantico. Boyd non si limitò a sfogliare i testi sulla Toyota Production System. Li studiò a fondo. Sul suo scaffale c’erano Imai, Stalk e Hout, il libro di Aguayo su Deming, e naturalmente The Machine That Changed the World di Womack, Jones e Roos, il volume che introdusse la parola “Lean” in ogni sala riunioni del pianeta.

A margine di quel libro, di suo pugno, Boyd lasciò un giudizio netto e sprezzante, una sola parola: “Terrible!”

Se anche chi ha coniato il termine più celebrato del management moderno aveva frainteso il sistema Toyota agli occhi di Boyd, vale la pena chiedersi cosa rischiamo noi quando trattiamo Kanban come un semplice set di strumenti.

Un sintomo scambiato per il motore

La critica di Boyd non era estetica. Il problema era che “Lean” descrive un effetto collaterale, il basso livello di inventario, e non il meccanismo che lo produce. Secondo le sue note, il kanban stesso è solo una parte del sistema just-in-time, e gli autori del libro non avevano nemmeno menzionato Shigeo Shingo, l’ingegnere che con Ohno costruì l’architettura tecnica del Toyota Production System.

Il suo giudizio finale su Womack, Jones e Roos fu che non avevano colto il pensiero rovesciato di Ohno: la sua capacità di guardare fuori dal proprio sistema e ricombinare quello che osservava con il proprio modo di ragionare. È il filo che attraversa tutte le note di Boyd, qualunque sia il libro su cui scrive.

Lo stesso errore si ripete ogni volta che Kanban viene ridotto a board, limiti WIP e cadenze di revisione. Sono strumenti, non il sistema. Il Kanban Maturity Model affronta gli sprechi in un ordine preciso, prima il muri (sovraccarico), poi il mura (irregolarità), solo alla fine il muda (attività non a valore), proprio per evitare di installare pratiche senza il pensiero che le tiene insieme. Come diceva Box, tutti i modelli sono sbagliati, ma alcuni sono utili: il problema nasce quando ci si innamora del modello e si perde di vista cosa dovrebbe rappresentare.

Comando dall’alto, controllo dal basso

Nelle sue note, Boyd torna più volte su un’idea che sembrava ovvia a Toyota ma che l’Occidente continuava a mancare. Il comando, l’intento strategico, arriva dall’alto. Il controllo reale, invece, viene esercitato dall’esterno: dal cliente, dall’ambiente in cui l’organizzazione opera.

Non è uno slogan. È il meccanismo che Ohno costruì attorno al sistema kanban stesso: il processo a valle chiama il lavoro, non il contrario. Quando Imai descrisse il miglioramento come qualcosa che il management stabilisce e i lavoratori eseguono, Boyd si chiese, con la sua consueta insofferenza, come potesse il management stabilire standard su un lavoro che non conosce a fondo.

Il metodo STATIK parte esattamente da qui. Il punto di partenza non è l’organigramma né la struttura dei team, ma cosa non soddisfa il cliente del servizio. L’idoneità allo scopo, il criterio con cui un cliente sceglie o abbandona un fornitore, non viene definita da chi gestisce il sistema. Viene definita da chi sta fuori. Più un’organizzazione matura, più questo principio smette di essere un’eccezione e diventa l’impostazione di default.

Non puoi giudicare un sistema da dentro

C’è un’osservazione che Boyd scrisse nel libro su Deming e che vale più di molte pagine di teoria: il carattere di un sistema non si può determinare restando al suo interno. Per capire cosa non funziona, bisogna uscirne, osservare, e orientarsi rispetto a qualcosa di più grande delle proprie assunzioni interne.

È lo stesso principio dell’OODA loop, il ciclo osserva-orienta-decidi-agisci che Boyd sviluppò per il pensiero tattico e che oggi viene citato, spesso in versione semplificata, ben oltre il contesto militare. La parte che si perde più facilmente è l’orientamento: non basta osservare, bisogna anche essere disposti a rivedere il proprio modello della realtà.

Nel Kanban Maturity Model questo si traduce in cadenze concrete. Operations Review e Strategy Review esistono per dare all’organizzazione un punto di osservazione esterno a se stessa, un modo per vedere interazioni che dal singolo team o dal singolo silo restano invisibili. Senza questi meccanismi di feedback, un’organizzazione può ottimizzare ogni sua parte e restare comunque cieca rispetto al proprio insieme.

Il giudizio nel margine

Quel giudizio tagliente scritto a margine non era pedanteria terminologica. Era il rifiuto di ridurre un sistema vivente, capace di osservare e ricombinare continuamente se stesso, a un elenco di pratiche da installare.

Toyota lo sapeva. Boyd lo sapeva. La maggior parte delle “trasformazioni Lean” continua a non saperlo.

Bibliografia

  1. Brian Rivera, John Boyd Read Toyota’s Playbook. He Thought “Lean” Was the Wrong Word., LinkedIn, 27 luglio 2026 — https://www.linkedin.com/pulse/john-boyd-read-toyotas-playbook-he-thought-lean-wrong-brian-rivera-xcnle/
  2. David J. Anderson, Teodora Bozheva, Kanban Maturity Model, Coaches’ Edition: A Map to Organizational Agility, Resilience, and Reinvention, Kanban University Press, 2ª edizione, 2021
Pubblicato il

Dagli eroi al sistema: come il Kanban Maturity Model ha recepito le idee di Toyota

Nell’articolo precedente ho raccontato il modello del giardiniere: il modo in cui Toyota affronta gli sprechi in un ordine preciso, prima le persone, poi il flusso, poi le attività. Ne nasce una leadership che coltiva invece di installare. In questo articolo spiego come il Kanban Maturity Model abbia ripreso questi stessi principi. Li traduce in pratiche precise e verificabili, che segnano il passaggio da un livello di maturità al successivo.

Il Muri irrisolto genera l’eroe

Ai primi livelli, ML1 e ML2, il lavoro non è visualizzato in modo sistematico. Non esistono policy esplicite su cosa entra nel sistema e quando. Chi decide cosa fare oggi lo decide con il buon senso, non con una regola scritta e condivisa. Senza un limite dichiarato al lavoro in corso, tutto arriva insieme. Chi tiene in piedi il sistema è chi sa improvvisare meglio sotto pressione: l’eroe. Il Muri, il sovraccarico, nasce dal fatto che nessuno ha mai dichiarato quanto lavoro il sistema può reggere.

Il primo sollievo arriva già a ML2, con l’emergere di una figura dedicata, il Flow Manager. Il suo compito esplicito è alleviare il sovraccarico locale e stabilizzare il flusso. È un sollievo parziale: il KMM etichetta questo livello come “emergente”. Qualcuno inizia a occuparsene, ma non è ancora il sistema a farlo strutturalmente.

ML3: i processi sostituiscono gli eroi

Il salto vero è a ML3, segnato dal motto che il KMM usa esplicitamente: “no more heroes anymore”. Non è un cambio di mentalità, è un cambio di pratiche. Una board rende visibile il lavoro reale. Limiti espliciti al WIP e cadenze fisse di replenishment stabiliscono insieme cosa entra e cosa aspetta. Policy scritte e condivise sostituiscono quelle trattenute nella testa di chi ha più esperienza.

Con queste pratiche il Muri si affronta nei fatti. Il ruolo stesso cambia forma, dal Flow Manager di ML2 al Service Delivery Manager e Service Request Manager (anche chiamato Demand Manager) di ML3, e il focus si sposta dal semplice sollievo al valore del servizio. Nasce l’unità di intenti: i processi consistenti sostituiscono gli eroi. Con il carico sotto controllo, anche il Mura, l’irregolarità del flusso, si riduce, perché il lavoro entra a un ritmo dichiarato invece che a ondate imprevedibili.

Il Muda viene per ultimo

Solo a questo punto, con persone e flusso stabilizzati, ha senso occuparsi del Muda. Tipico di ML4 e ML5, significa eliminare le attività senza valore, affinare con modelli probabilistici, estendere il miglioramento oltre il singolo team.

L’errore più comune è affrontare il Muda per primo. È il più visibile, il più facile da spiegare a un dirigente: si “elimina questa attività inutile”. Affrontare Muri e Mura è scomodo, perché costringe a decidere cosa il sistema non può più permettersi di chiedere alle persone. Eliminare però attività che sembrano spreco in un sistema ancora sovraccarico e irregolare spesso significa individuare il sintomo sbagliato.

Jidoka diventa il blocco del ticket

Il telaio di Sakichi Toyoda si fermava da solo alla rottura di un filo. Nel metodo Kanban questo diventa una regola operativa precisa. Quando un elemento si blocca per un difetto, il ticket di rework si aggancia esplicitamente al suo genitore bloccato sulla board. Non è un dettaglio grafico. Significa che chiunque guardi la board vede subito dove il flusso si è rotto, invece di scoprirlo settimane dopo da un cliente insoddisfatto.

Genchi Genbutsu: la board non basta

Andare a vedere i fatti di persona ha due risvolti, nel metodo Kanban. Il primo è aprire la board invece di affidarsi a un report che riassume, e quindi semplifica troppo, la realtà. Il secondo è sedersi fisicamente accanto a chi eroga il servizio e osservare cosa fa davvero. Un report può dire che una richiesta è stata evasa in tre giorni. Solo guardando chi la evade si scopre quanto di quel tempo è lavoro reale e quanto è attesa o rilavorazione. Emergono aspetti che restano invisibili a chi guarda solo i numeri aggregati. Il KMM colloca questo passaggio, dalle intuizioni ai dati, esplicitamente a partire da ML3.

Un percorso pratico, per il settore dei servizi

Il modello del giardiniere è il sistema che Toyota ha costruito in decenni, dentro una cultura industriale specifica. Il Kanban Maturity Model prende lo stesso sistema e lo rende percorribile per chi non parte da lì. Una sequenza di pratiche verificabili, che qualsiasi organizzazione di servizi può adottare un passo alla volta: board, limiti di WIP, cadenze, policy esplicite, blocco dei ticket, osservazione diretta del servizio. Non è un’interpretazione della filosofia Toyota, è lo stesso principio reso incrementale, misurabile, portabile fuori dalla fabbrica dove è nato.

Bibliografia

  1. David J. Anderson, Teodora Bozheva, Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention – 2nd Edition, Kanban University Press, 2021
  2. Jeffrey K. Liker, Karyn Ross, The Toyota Way to Service Excellence: Lean Transformation in Service Organizations, McGraw Hill, 2017
Pubblicato il

Conquistare intero e intatto: Sun Tzu e il conflitto nelle organizzazioni

Tutti citano Sun Tzu per la sua saggezza strategica. Si prende L’arte della guerra, la si applica al business, e si finisce per parlare di “battaglie di mercato”, “nemici da sconfiggere”, “campagne” da vincere. È una lettura legittima, ma superficiale. Perché il trattato di guerra più famoso della storia, composto in Cina tre secoli prima di Cristo, ha nel suo cuore un messaggio sorprendente: la non-aggressione.

“La miglior battaglia è quella che vinciamo senza combattere.” Non è un aforisma decorativo da mettere in fondo a una slide. È la tesi centrale del libro. Sun Tzu non si limita a dare precetti per sconfiggere i nemici sul campo, ci insegna a gestire i conflitti in modo profondo e non distruttivo. E questa, a ben vedere, è la cosa più utile che possiamo portarci in azienda.

Il conflitto è dentro il sistema, non fuori

In un articolo precedente, parlando di variabilità stagionale, ho sostenuto un concetto semplice: il picco di lavoro prevedibile non è un’emergenza da affrontare a colpi di straordinari, è una condizione da conoscere. Chi tratta l’onda annuale come un nemico improvviso ha già perso, perché sta combattendo qualcosa che poteva leggere con mesi di anticipo nei propri dati.

Il conflitto organizzativo funziona allo stesso modo. La tentazione, quando in un’azienda due reparti si scontrano, quando le priorità entrano in collisione, quando un team non consegna e un altro si lamenta, è individuare il colpevole. La persona difficile. Il manager che non capisce. Il reparto che rema contro. E poi combatterlo.

Il conflitto, si legge nell’introduzione alla mia edizione di Sun Tzu, è una componente integrante della vita umana, si trova dentro di noi e intorno a noi. Non possiamo soffocarlo, ignorarlo, negargli l’esistenza. Possiamo solo imparare a gestirlo. E, aggiungo io, in un’organizzazione il conflitto tra le persone è quasi sempre il sintomo di un sistema mal disegnato: lavoro in corso senza limiti, nessuna cadenza condivisa, dipendenze invisibili, priorità che cambiano ogni settimana. Combattere le persone significa accanirsi sul sintomo. Ridisegnare il sistema significa rimuovere la causa.

Conoscere se stessi e l’altro

In Sun Tzu c’è un passaggio che torna come un ritornello. Se conosco le mie truppe ma non il nemico, le mie possibilità di vittoria sono dimezzate. Se conosco il nemico ma non le mie truppe, le mie possibilità di vittoria sono sempre dimezzate. Se conosco entrambi ma non le condizioni del terreno, le mie possibilità di vittoria sono di nuovo dimezzate. La conoscenza completa – di sé, dell’altro, del contesto – è ciò che separa la vittoria dalla sconfitta.

Mi capita spesso che mi dicano che sono stato fortunato. Fortunato a poter fare certe cose in azienda, a incontrare certi responsabili che mi hanno lasciato spazio. E rispondo sempre la stessa cosa: sì, è vero, sono stato fortunato. Ma ho anche fatto del mio meglio per conquistarli a fare cose di cui non erano necessariamente convinti, anzi, certe volte all’inizio erano contrari.

Convincere il proprio responsabile è la situazione che chiunque lavori in un’organizzazione ha vissuto mille volte. È anche il caso in cui la lezione di Sun Tzu si vede meglio, perché chi vuole convincere il proprio responsabile non ha l’autorità formale per imporre nulla. Proprio per questo deve conoscere l’altro davvero – le sue preoccupazioni, i suoi vincoli, ciò che lo muove, il momento giusto per parlargliene – invece di affidarsi a una forza che non possiede. La conoscenza dell’altro e del contesto, qui, è tutto.

Credo nelle persone, e credo che diano il meglio quando perseguono un sogno. In un altro articolo ho parlato di come il senso, lo diceva Viktor Frankl, non sia un lusso ma una necessità costitutiva dell’essere umano, e di come l’ossessione paralizzi mentre il sogno liberi. Conquistare un responsabile inizialmente contrario, per me, ha sempre voluto dire questo: costruire insieme a lui un senso abbastanza solido da rendere il sogno suo, non più solo mio. E a volte un sogno che nemmeno io credevo di avere.

Perché qui, se mi permettete, vado un po’ più in là di Sun Tzu. Nel Sun Tzu il generale conquista l’altro intero e intatto, ma resta sé stesso. Nella mia esperienza non funziona così. Conquistando le persone mi faccio conquistare anch’io. Cambio anch’io. E ciò che ne viene fuori non è la mia vittoria né la loro: è una vittoria che abbiamo costruito insieme, diversa da quella che ciascuno aveva in mente all’inizio. È ciò che al Faust di Goethe, davanti a un attimo finalmente pieno di valore, fa dire “fermati, sei bello”. Quell’attimo non si impone, e non lo possiede nessuno. Si crea insieme.

Conquistare intero e intatto

Qui sta il concetto che dà il titolo a questo articolo, ed è lo spunto più profondo che trovo in Sun Tzu: prendere il nemico “intero e intatto”, perché danneggiarlo o distruggerlo non è altrettanto buono. Significa vincere preservando sia le proprie risorse sia quelle dell’avversario. Una vittoria che lascia intatto ciò su cui si potrà costruire.

Non è una posizione altruistica. È pura efficacia. La distruzione lascia devastazione non solo per gli sconfitti, ma anche per i vincitori, che dovranno imporre a lungo la loro “pace”. Il responsabile che sbugiardi in riunione, il collega che metti in difficoltà davanti agli altri, il reparto che umili come “sconfitto” non scompaiono. Diventano nemici in attesa della rivincita. L’alleato conquistato intero resta un alleato. Il nemico sottomesso aspetta invece solo l’occasione per sabotarti. Non è un caso che il cambiamento più solido nelle organizzazioni sia quello evolutivo, che parte da ciò che già si fa: proprio perché non minaccia l’identità delle persone, non trasforma nessuno in avversario o peggio in nemico.

E c’è di più. Rifiutare in partenza la logica vittoria/sconfitta non è solo più nobile, è più intelligente. Chi entra in una discussione pensando “devo vincere io” ha già rinchiuso la propria mente. Si è reso prevedibile, ha smesso di vedere le possibilità, ha trasformato l’altro nel proprio opposto. Vedere il conflitto come “o vinco o perdo” cattura le nostre percezioni dentro un mondo ristretto e ci impedisce di accedere a una conoscenza più ampia.

Il ponte con il flusso

C’è una ragione per cui tutto questo mi parla così da vicino, ed è il lavoro che faccio ogni giorno. Un sistema Kanban ben disegnato non impone: rende visibile. Non costringe il management a limitare il lavoro in corso per decreto. Rende evidente, con i dati, il costo del troppo lavoro contemporaneo – i tempi di consegna che si allungano, le code che crescono, il flusso che si ingolfa – finché limitarlo diventa una decisione ovvia. Condivisa. Loro.

Il management che adotta un limite al WIP perché l’ha capito guardando i propri numeri è un alleato conquistato intero e intatto. Ha cambiato idea da sé, e quella decisione regge nel tempo perché è sua. Il management a cui quel limite viene imposto dall’esterno torna alle vecchie abitudini appena ci si volta. È la stessa dinamica del responsabile da convincere, del generale che preferisce la vittoria senza battaglia. Non si vince contro le persone. Si creano le condizioni perché le persone vincano con te, e tu con loro.

Lo stesso Kanban Maturity Model, per descrivere come si guida il cambiamento senza scatenare resistenza, cita Bruce Lee: “be like water”. Invece di sfondare frontalmente la roccia della resistenza – che è quasi sempre resistenza dell’identità di qualcuno, la paura di non essere più ciò che si era – conviene girarci intorno, lasciare che le pratiche nuove e più efficaci sostituiscano da sole quelle vecchie. È il “conquistare intero e intatto” tradotto in metodo: non si abbatte, si asseconda il terreno.

La saggezza della non-aggressione

Questa visione di Sun Tzu, naturalmente, è un modello. E come tutti i modelli è una rappresentazione semplificata della realtà, non la realtà stessa: guai a prenderlo come una ricetta da applicare meccanicamente a ogni situazione. Ma la saggezza che lo attraversa non è solo una tecnica militare cinese di venticinque secoli fa. È, come dice l’introduzione all’edizione che ho tra le mani, un sapere fondamentale che appartiene all’uomo: la saggezza della non-aggressione.

Non vedere l’altro – il responsabile, il collega, il reparto, persino il mercato – come un nemico da distruggere, ma come qualcuno con cui costruire qualcosa che prima non c’era, è il fondamento di ogni conflitto gestito bene. È, a sorpresa, anche il fondamento di un flusso di lavoro sano. Una saggezza che ha una radice profonda, che dal pensiero cinese di Sun Tzu arriva fino al pensiero giapponese dietro a Toyota e a Kanban. Ma questa è la storia del prossimo articolo.

Bibliografia

  1. David J. Anderson, Teodora Bozheva, Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention – 2nd Edition, Kanban University Press, 2021
  2. Sun Tzu, L’arte della guerra, a cura del Denma Translation Group, Oscar Mondadori, 2003

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.