Kanban e l'arte della Maratona

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

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

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

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

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

L’intelligenza artificiale accelera il lavoro, ma il Lead Time è fatto per lo più di attese

Quando mi chiedono che lavoro faccio, e chi me lo chiede non ha chiaro perché serva un consulente per migliorare i flussi di lavoro, parto sempre dall’efficienza di flusso.

L’efficienza di flusso è il rapporto tra il tempo in cui si lavora effettivamente a un’attività e il tempo totale che passa dall’inizio alla fine di quella stessa attività, cioè il Lead Time. Nella pratica, di solito non si usa come indicatore operativo, perché non è semplice da calcolare. Si usano le pratiche del metodo Kanban, le quali, come risultato, aumentano l’efficienza di flusso. Comprenderne la dinamica, pur senza calcolarla, permette comunque di afferrare il senso del metodo Kanban.

Quando l’efficienza di flusso è bassa, cioè sotto il 15% secondo il Kanban Maturity Model (KMM), il margine di miglioramento sta soprattutto nell’eliminare i tempi di attesa. Il che si ottiene limitando il lavoro in corso, riducendo code e buffer e gestendo meglio problemi bloccanti e dipendenze, tutte pratiche Kanban. Anderson ne ha parlato in un recente keynote, che ho sintetizzato in un articolo. Qui voglio riprendere e approfondire questo specifico aspetto.

Il lavoro effettivo è inizialmente solo una piccola parte del tempo

Il Toyota Production System, precursore del metodo Kanban, ha messo al centro proprio questo: non far andare più veloci gli addetti all’assemblaggio dei veicoli, ma eliminare le attese che stanno intorno al lavoro vero e proprio.

Nel lavoro di concetto, knowledge work in inglese, il ragionamento è identico, con una differenza. La materia prima è l’informazione. Se si parte senza averla tutta e questa arriva un po’ per volta, ci si ferma ad aspettarla, si riparte, ci si ferma di nuovo.

Prendiamo lo sviluppo software. Si comincia a sviluppare e a un certo punto manca un requisito del cliente, perché non era chiaro in fase di analisi. Si chiede al cliente, poi ci si ferma e si aspetta. Quando si ha la risposta, si riprende a lavorare fino a quando si incappa in un altro requisito poco chiaro e ci si ferma di nuovo. E così via. Alla fine il software è pronto, lo si consegna al cliente per il test e si resta in attesa del suo feedback. Se si sommano le attese, nell’esperienza mia e di molti colleghi della community Kanban, queste costituiscono la parte largamente prevalente del Lead Time.

Andare più veloci non è la leva

Per questo, all’inizio di una consulenza, una delle prime cose su cui lavoro è smontare l’idea, diffusa, che l’efficienza si ottenga facendo lavorare più in fretta le persone.

Il punto è controintuitivo. Limitare il lavoro in corso significa che le persone si occupano di meno cose contemporaneamente. Nella mia esperienza questo le porta a ricavarsi il tempo per riflettere su come tagliare i tempi morti, e dopo un po’ il processo va più veloce, senza che nessuno debba affannarsi. Nelle organizzazioni di cui parlo nei miei case study ho visto riduzioni del Lead Time fino al 90%, risultati che sono analoghi a quelli riscontrati da colleghi della community.

Cosa c’entra l’intelligenza artificiale

A più di un lettore può essere venuto a questo punto il dubbio: ma cosa c’entra questo ragionamento con l’intelligenza artificiale? Oggi, nel lavoro di concetto, l’AI viene usata soprattutto per la produttività personale. Aiuta a scrivere un testo, a fare calcoli, a preparare un’analisi, a sviluppare codice, e ognuno di questi compiti si svolge più in fretta.

Ma applicare l’AI a queste attività risponde alla stessa logica del far andare più veloci le persone. Accelera il lavoro effettivo, che è la parte più piccola del Lead Time.

Un esempio numerico: supponiamo che il lavoro effettivo sia il 10% del Lead Time, quindi due giorni su venti, e che l’AI lo dimezzi. Il lavoro passa a un giorno, il Lead Time a diciannove giorni, con un miglioramento del 5%. Il 10% è un’ipotesi esemplificativa, in linea con una situazione sotto la soglia del 15% del KMM, che è l’ordine di grandezza da cui partono i casi che seguo. Il dimezzamento del lavoro effettivo è generoso, per cui nella realtà il miglioramento è probabilmente inferiore.

A fronte di un miglioramento di questa entità, il costo dell’AI può essere anche rilevante, come riferito nel keynote da Anderson. Tornando all’esempio del software: se l’AI fa scrivere il codice più in fretta, il collo di bottiglia resta la risposta del cliente, e il problema non è risolto.

Serve un uso sistemico dell’intelligenza artificiale

La domanda giusta è come si potrebbe usare l’AI per ridurre le attese, che sono ciò che incide davvero sul Lead Time. Personalmente, un uso sistemico di questo tipo non l’ho ancora visto.

Se e quando lo troveremo, otterremo più valore dall’investimento. Anche questo ragionamento conferma però un tema che ho già sollevato in miei articoli precedenti: serve qualcuno che pensi a come gestire il sistema di lavoro e gli strumenti, l’AI compresa. Questo compito non viene eliminato dall’intelligenza artificiale, e continua a essere necessario come lo è sempre stato.

Pillole di Kanban applicato: la gestione dell’imbarco e dello sbarco in aereo

Tornando dal Kanban Leadership Retreat di Bilbao ho volato con Vueling, sulle tratte Bilbao-Barcellona e Barcellona-Milano. Due imbarchi e due sbarchi, sempre con la stessa gestione del flusso. Cito la compagnia perché è quella che ho potuto osservare, non perché sia l’unica. Qui voglio soffermarmi su cosa possiamo imparare da questo modo di gestire il flusso dei passeggeri, per applicarlo ai flussi di lavoro delle nostre organizzazioni.

Il vincolo: una sola porta

In tutti e quattro i casi l’aereo era attraccato al pontile, il cosiddetto finger. In questa situazione si usa solo la porta anteriore e quella posteriore resta chiusa. Per i passeggeri è più comodo, perché si resta sempre all’interno, non si cammina mai in pista e non ci si bagna se piove.

Imbarco e sbarco però sono normalmente più lenti, perché tutti passano da una sola porta. Se chi ha la fila 26 si trova dietro a chi ha la fila 4, deve fermarsi finché l’altro non si è seduto, perché non c’è spazio per proseguire. In termini Kanban, la porta è il collo di bottiglia del sistema.

Diventa quindi fondamentale l’ordine di imbarco. Le compagnie da sempre chiamano per numero di fila, ma i passeggeri fanno un po’ quello che vogliono. Qualcuno arriva con la fila sbagliata e viene messo da parte, ma non si sottilizza troppo, e all’imbarco si crea di solito parecchia confusione.

All’imbarco: corsie, cartelli e gruppi

Nei gate che ho usato, Vueling divide i passeggeri in tre gruppi, anteriore, centrale e posteriore. È un sistema semplice, come si fa nel metodo Kanban, senza niente di sofisticato. Il numero del gruppo, 1, 2 o 3, è stampato sulla carta d’imbarco.

Al gate le transenne a nastro, le cosiddette bindelle, creano tre corsie di coda, ciascuna con il suo cartello. Le persone si mettono quasi spontaneamente nella corsia giusta. Si imbarca il gruppo 1, poi il 2, poi il 3, e il gruppo successivo viene chiamato quando il precedente è sostanzialmente imbarcato.

Non è molto diverso da quello che si è sempre fatto, ma creando le corsie e mettendo i cartelli si gestisce davvero il flusso, e l’ingresso in aereo risulta molto più ordinato. Ritrovo la visualizzazione (corsie e cartelli), una policy esplicita (il gruppo sulla carta d’imbarco), il limite al lavoro in corso (si imbarca un gruppo alla volta) e il pull (il gruppo successivo viene chiamato quando il precedente ha finito).

Io ero nel gruppo 3, perché avevo preso la tariffa più economica. Quando sono salito, i gruppi 1 e 2, cioè circa due terzi dell’aereo, erano già seduti e il corridoio era libero. Andare in fondo e sedersi è stato molto più semplice. È successo sia a Bilbao sia a Barcellona.

Allo sbarco: un sistema simile

Ho fatto due sbarchi, a Barcellona e a Milano. Di solito, quando l’aereo arriva all’attracco, tutti i passeggeri saltano in piedi e cominciano a tirare fuori i bagagli dalle cappelliere. Qui invece parte un annuncio abbastanza perentorio: restare seduti al proprio posto fino a quando non si viene chiamati.

Poi si chiamano blocchi di file, partendo dalle più avanti, dalla 1 alla X e poi dalla X+1 alla Y. Non ricordo quante file avesse ogni blocco. Il personale tiene monitorato il deflusso e, quando il blocco è pronto a uscire, chiama il successivo. L’uscita risulta più ordinata e più rapida.

Anche qui ritrovo una policy esplicita (restare seduti), il limite al lavoro in corso (un blocco alla volta) e il pull, con il segnale che arriva da valle, cioè dal corridoio che si sta liberando. Sono due sistemi diversi ma simili e governati dalle stesse logiche di gestione del flusso: uno per l’imbarco, uno per lo sbarco.

Le misure

Sono rimasto favorevolmente impressionato, perché è un esempio semplice di come un accorgimento facile da implementare possa migliorare un flusso. La mia sensazione è che il tempo di imbarco e sbarco si sia ridotto sensibilmente. Non ho fatto misure, perché l’idea dell’articolo mi è venuta dopo il viaggio, quindi non ho né i tempi né il numero di file per gruppo di imbarco o blocco di sbarco. In ogni caso le mie misure non sarebbero state significative come statistica.

Le compagnie aeree le misure le fanno di sicuro. Hanno tempi stretti per sbarcare, imbarcare e non perdere lo slot di decollo, come detto chiaramente negli annunci che mi è capitato di sentire altre volte per sollecitare i passeggeri a sbrigarsi a prendere posto. Non so cosa misurino esattamente, ma suppongo che tra le misure ci siano il tempo tra l’apertura delle porte e lo sbarco completo, e il tempo tra l’apertura del gate e la chiusura delle porte.

Suppongo anche che il sistema sia stato ottimizzato: con una sola porta, in pochi minuti l’aereo era pronto a partire.

Cosa portarsi a casa

Per i nostri flussi di lavoro la lezione è la stessa: rendere visibile il flusso, esplicitare le regole e far entrare il lavoro a blocchi, chiamando il successivo solo quando il precedente sta defluendo. Nel vostro sistema, in base a cosa si decide quando il blocco successivo può partire?

Perché collegare l’AI ai vostri dati di flusso non basta: le decisioni che qualcuno deve prendere

Sono appena rientrato dal Kanban Leadership Retreat, la tre giorni annuale organizzata per la propria comunità da Kanban University. Tra i temi che hanno occupato più spazio quest’anno c’era l’AI: dove sta già cambiando il modo di lavorare di manager e knowledge worker e come il metodo Kanban possa aiutare le organizzazioni a orientarsi in un contesto tecnologico che si muove molto in fretta.

La risposta che sembra corretta finché non fate due volte la stessa domanda

Prendo spunto da una sessione proposta da Sonya Siderova, fondatrice di Nave, dedicata a flow metrics, analytics e AI agent. La domanda di partenza era semplice da porre ma non di facile risposta: che cosa succede quando si toglie la persona, lo human in the loop, dal ciclo di gestione del flusso di lavoro e si lascia decidere all’AI? Gli argomenti condivisi dal gruppo di lavoro sono stati sei: costo più elevato, difficoltà ad adattarsi a condizioni che cambiano, perdita di competenza di management, perdita di capacità di fare le domande giuste, perdita di capacità di guidare il cambiamento, perdita di gestione delle pratiche operative. Nel confronto tra un agente AI da solo e un agente affiancato da una persona, l’agente da solo non basta su nessuno di questi sei punti, nemmeno se lavora interfacciandosi con un motore di flow analytics già maturo.

Peggio ancora se l’agente accede direttamente ai dati grezzi di flusso e li elabora in autonomia. Il riscontro, dai test effettuati, è che si ottiene una risposta plausibile ma non affidabile. Il valore che l’AI aggiunge sta altrove: accedere attraverso il protocollo MCP ai dati prodotti in modo affidabile dal motore di flow analytics e costruirci sopra una narrazione, arrivando a generare raccomandazioni.

Successivamente a quella sessione, Siderova ha ripreso e sviluppato il ragionamento in un articolo che trovate su LinkedIn: https://www.linkedin.com/pulse/your-ai-can-talk-delivery-data-you-trust-answer-sonya-siderova-rfdfe

L’esempio che descrive è preciso. Qualcuno collega un LLM ai dati grezzi di flusso e chiede quanto dura normalmente un lavoro, cosa sta rallentando un team, quando saranno finiti quaranta work item. In pochi minuti arriva una risposta, e sembra che il problema sia risolto. Tre mesi dopo qualcuno rifà la stessa domanda. Nel frattempo il team ha cambiato workflow, due stati sono stati rinominati, i difetti seguono un percorso diverso. L’AI restituisce un numero diverso, e a quel punto nessuno sa più dire quale risposta fosse corretta.

Il prototipo non è la parte difficile

Siderova anticipa l’obiezione più ovvia, quella di chi ha collegato i propri dati grezzi di flusso a un LLM, ha sviluppato una demo e pensa di aver già risolto tutto: collegare l’API di strumenti quali Jira o Azure DevOps a un modello di AI non è al giorno d’oggi particolarmente difficile. La parte difficile comincia dopo la demo.

Prendete il cycle time. Dove parte il timer, alla creazione del ticket, all’ingresso in backlog o all’inizio effettivo del lavoro? Cosa succede se il work item torna indietro? Se salta uno stato? Se viene riaperto? Il tempo di attesa conta o no? Sono decisioni di misurazione, non domande che si rivolgono all’AI. Qualcuno deve prenderle, e poi assicurarsi che continuino a valere quando il workflow cambia il mese successivo, e quello dopo ancora. L’integrazione è un progetto, con un inizio e una fine. Il modello di misurazione è un prodotto: ha bisogno di un owner, di test, di manutenzione continua.

Da qui le sei domande che Siderova invita a porsi su ogni sistema, prima di fidarsi di un suo qualsiasi numero, che si tratti di uno strumento interno, di un foglio di calcolo o di una piattaforma commerciale: dove parte il cycle time, dove finisce, cosa succede quando il lavoro torna indietro, cosa succede quando un work item salta direttamente a “Fatto”, cosa succede quando un lavoro completato viene riaperto, il tempo di attesa viene conteggiato? E ne aggiunge una settima, decisiva quando quei numeri servono a prendere un impegno su una data di consegna: si sta guardando una media, o un percentile che permette davvero di valutare il rischio? Se il sistema non permette di rispondere con chiarezza a queste domande, quei numeri non possono essere usati per un impegno su una data di consegna. Un numero plausibile e un numero affidabile sono due cose diverse.

Interfaccia, non motore di calcolo

Interrogare ogni volta i dati grezzi e lasciare che sia l’LLM a interpretarli da zero è il modo più veloce per avere una risposta, ed è però anche quello che produce il problema descritto sopra, una risposta diversa ogni volta che qualcosa a monte cambia, senza che nessuno se ne accorga finché i numeri smettono di tornare. Interrogare un motore di flow analytics che applica sempre le stesse definizioni perché configurato opportunamente, con l’AI solo come interfaccia, fornisce invece risposte affidabili: la stessa domanda, posta oggi o tra sei mesi, produce una risposta diversa solo se sono cambiati i dati di flusso sottostanti, non perché è cambiata l’interpretazione di quei dati.

Non è un problema di modello di AI più o meno capace, è che le definizioni di misura non sono pattern che un LLM possa indovinare guardando i dati, sono decisioni che qualcuno deve avere già preso a monte.

Non è un problema di AI

Qui il discorso torna alla sostanza della gestione del flusso di lavoro. Dove parte il timer, come si trattano gli stati, cosa succede se c’è una rilavorazione: non sono un problema di ownership tecnica dello strumento. Sono esattamente ciò che rende maturo un sistema Kanban: policy esplicite, confini del workflow dichiarati, non lasciati all’intuito di chi in quel momento guarda la board. Un’organizzazione che non ha mai reso esplicite queste regole non scopre un problema di AI quando i numeri smettono di tornare. Scopre un problema di sistema che aveva sempre avuto, e che l’AI si limita a rendere visibile più in fretta, perché moltiplica il numero di domande poste a un sistema che non era pronto a rispondere con coerenza.

Ed è per questo motivo che trattare lo human in the loop come un tema separato dalla qualità della misurazione è fuorviante. Sono lo stesso tema visto da due lati diversi. La persona che possiede le definizioni di misurazione deve anche restare la persona che le mantiene quando il workflow cambia. Non è un ruolo che l’AI rende superfluo. Diventa anzi più necessario proprio perché l’AI abbassa il costo di fare domande al sistema.

Il punto di leva resta lo stesso di sempre

Visualizzare il flusso. Limitare il lavoro in corso. Rendere esplicite le policy, comprese quelle di misurazione che di solito nessuno scrive perché sembrano ovvie finché il numero torna. Solo dentro un sistema costruito così ha senso collegare un’AI e farsi rispondere sui propri dati di flusso di lavoro. Solo così quello che si ottiene è una risposta, oltre che plausibile, di cui ci si possa fidare.

Perché l’AI da sola non vi renderà agili: il concetto di “satisficing”

Quanto sta spendendo davvero la vostra azienda in intelligenza artificiale, e come fate a sapere se quella spesa sta producendo un miglioramento reale? È la domanda al centro del recente keynote speech di David Anderson tenuto a Norimberga, che è stato riproposto da Anderson stesso in un webinar e che qui riprendiamo e sintetizziamo. Non è un intervento sulla tecnologia AI in sé, ma su un problema molto più vecchio e sempre attuale: come si fa a sapere se un cambiamento produrrà un miglioramento? Da quella domanda è nato, quasi un decennio fa, il framework Fit for Purpose, sviluppato da Anderson insieme ad Alexei Zheglov.

Il problema: aziende che investono senza strategia

Anderson racconta di parlare regolarmente con aziende i cui team, un tempo dedicati all’agile coaching, oggi lavorano su iniziative di intelligenza artificiale. Lo schema che vede ripetersi è molto simile: prima si è provato l’agile in piccola scala senza risultati, poi si è scalato con qualche framework dedicato spendendo molto e rallentando ulteriormente, infine si sono licenziati scrum master e product owner, rinominando i superstiti con titoli come flow manager o transformation coach. Ora quelle stesse persone sono state messe a capo delle iniziative di AI, nella speranza che la tecnologia risolva ciò che l’agile non è riuscito a risolvere. Anderson sottolinea come questa non sia una strategia: è essenzialmente una speranza, unita a una spesa ingente.

Che cosa significa il concetto di satisficing

Il termine, coniato dall’economista e matematico Herbert Simon (premio Nobel per l’economia) a metà degli anni Cinquanta, nasce dalla fusione di “satisfactory” e “sufficient“. Simon studiava i grafi di rete e un problema ben noto nelle organizzazioni industriali: se si chiede a ogni singolo nodo di una rete, per esempio ogni reparto o linea produttiva, di ottimizzare la propria efficienza, i nodi finiscono per competere tra loro e il risultato complessivo diventa inefficiente. Un ottimo locale non produce un ottimo globale.

La soluzione individuata da Simon non era chiedere ai singoli nodi di ottimizzare, ma di raggiungere un livello, appunto, satisficing: sufficiente e soddisfacente. Se ogni nodo persegue quel livello, l’intera rete tende a un ottimo globale a partire da livelli locali di sufficienza. Applicato a un’azienda, questo significa che ogni servizio della rete organizzativa ha bisogno di metriche proprie che definiscano cosa rappresenti, per quel nodo, un livello soddisfacente e sufficiente di performance, per poi usarle in un ciclo di retroazione locale.

Il costo reale dell’AI

Anderson porta alcuni dati per dare la misura del problema. Uber avrebbe budgetato 1.800 dollari al mese per dipendente per l’AI, ma starebbe in realtà spendendo circa 5.400 dollari al mese. Un insider che lavora a un’iniziativa di AI agentica in una nota grande azienda tecnologica americana, riferisce una spesa di circa 4.000 dollari al mese per dipendente. Numeri che, calcolati in relazione a un ingegnere software con stipendio tra 150.000 e 300.000 dollari l’anno, possono sembrare sostenibili, ma che non reggono in altri mercati: a Lisbona, dove ha tenuto lo stesso keynote due mesi prima di Norimberga, una cifra del genere equivarrebbe a raddoppiare il costo del lavoro.

Una ricerca dell’Economist dello scorso giugno indica che l’1% delle aziende globali per capitalizzazione spende in media 7.500 dollari al mese per dipendente, ovvero circa 100.000 dollari l’anno. Il range che emerge da queste fonti è quindi tra 50.000 e 100.000 dollari l’anno per dipendente, a fronte di un miglioramento di produttività atteso di circa quattro volte, ma con pochissime evidenze concrete di benefici di business. Molti di questi budget vengono sottratti ad altre voci, come la formazione, di cui l’AI arriva a costare fino a dieci volte tanto per dipendente.

Agilità aziendale su due livelli

L’agilità enterprise si gioca su due dimensioni: la capacità di far girare più velocemente il business quotidiano (Run the Business), rispondendo a cambiamenti di mercato e di domanda, e la capacità di reinventarsi, di cambiare direzione quando serve (Change the Business). Storicamente gli sponsor aziendali delle iniziative agili si aspettavano velocità, e i coach che negli anni hanno sostenuto che “l’agile non è mai stato sulla velocità” hanno spesso pagato quella loro affermazione con il posto di lavoro.

Pensare per servizi, non per team

Un’organizzazione va modellata come una rete di servizi interdipendenti, non come una gerarchia. Una richiesta cliente attraversa più team per essere evasa: la Kanban board rappresenta il servizio, non la struttura organizzativa. L’unità molecolare dell’agilità aziendale non è mai stata il team, ma il servizio. Per ciascun servizio serve un proprio sistema Kanban e un proprio set di metriche di satisficing, tra cui lead time, prevedibilità, puntualità, qualità funzionale e non funzionale, conformità normativa, convenienza, adattabilità, configurabilità e sostenibilità economica.

Un punto che Anderson sottolinea con un esempio personale: l’AI non prende decisioni, genera opzioni. Con la sua stessa casella di posta come esempio, racconta di ricevere continuamente analisi con più opzioni da valutare, generate rapidamente dai suoi collaboratori grazie all’AI, che finiscono per far perdere tempo prezioso a chi deve poi decidere, lui compreso. È un caso concreto di ottimizzazione locale che crea un problema altrove nella rete, in questo caso al vertice dell’azienda.

Il problema dell’efficienza di flusso

Dati raccolti in vent’anni di lavoro con la community Kanban dicono che in molte organizzazioni solo l’1-2% del lead time complessivo di una richiesta cliente corrisponde a lavoro effettivo, il resto sono code. Se una richiesta impiega 100 giorni per essere evasa ma richiede un solo giorno di lavoro effettivo, applicare l’AI a quel giorno di lavoro, riducendolo per esempio di un fattore quattro, porta il lead time percepito dal cliente a restare sostanzialmente invariato. Il discorso cambia se il servizio ha già un’efficienza di flusso alta, per esempio del 50-60%: in quel caso l’AI può davvero dimezzare il lead time o raddoppiare la produttività. Il rischio più comune, però, è che l’AI ottimizzi localmente una fase già poco significativa nel flusso complessivo, spostando semplicemente il collo di bottiglia altrove nell’organizzazione, senza produrre alcun miglioramento globale percepibile, pur continuando a consumare budget.

Autonomia locale e doppio ciclo di retroazione

Perché il miglioramento locale funzioni, ogni nodo della rete deve poter agire con autonomia, perseguendo il proprio livello di satisficing e non un ottimo assoluto. Anderson descrive due cicli di retroazione (double-loop learning): uno interno, che chiede se il servizio sta rispettando i propri criteri di satisficing, e uno esterno, che chiede se quei criteri sono ancora quelli giusti da misurare. Quando i servizi sono collegati tra loro, ogni servizio dipendente deve conoscere cosa rappresenta un livello soddisfacente per il servizio che lo richiede, in modo che la sufficienza si propaghi lungo tutta la rete fino al cliente finale.

L’ottimizzazione globale parte dai nodi a contatto diretto con il cliente e si propaga verso l’interno dell’organizzazione attraverso pratiche di revisione periodica, documentate nel Kanban Maturity Model. Se il meccanismo funziona, i diversi nodi della rete possono scambiarsi capacità, competenze e priorità: un nodo può accettare di essere sub-ottimale per contribuire a un miglioramento globale, ma questo richiede che i sistemi di incentivo dei manager siano allineati al bene della rete e non alla sola performance locale.

Cosa fare, a prescindere dall’AI

Anderson suggerisce un percorso in tre passi, indipendente dalla tecnologia scelta:

visualizzare, dotare di strumenti di misurazione e gestire il flusso delle richieste cliente end to end, non a livello di singolo team, con il Kanban Maturity Model
definire i criteri di satisficing con il framework Fit for Purpose
implementare un ciclo di retroazione locale che porti quelle metriche al livello desiderato

Solo a queste condizioni ha senso chiedersi se un investimento in AI, applicato a un nodo specifico della rete, produrrà un miglioramento reale e misurabile, con un’analisi di ritorno sull’investimento che tenga conto sia della spesa locale sia dell’impatto globale sul business. E solo se si gestisce il flusso di lavoro per ogni servizio, si potrà sapere se l’AI ha generato dei miglioramenti oppure no.

Il confronto con Kanban su scala enterprise

Il keynote si chiude con un termine di paragone: le implementazioni Kanban su scala enterprise fatte correttamente producono tipicamente un miglioramento di produttività da 4 a 8 volte, una riduzione del 90% dei lead time e del time to market, con un costo inferiore all’1% del costo del lavoro esistente. Adam Woo, coach Kanban di Shenzhen, ha realizzato più di sei implementazioni su scala superiore alle 5.000 persone, la più grande delle quali in Huawei con 100.000 persone coinvolte. Un risultato, osserva Anderson, spesso migliore di quanto ci si aspetti dall’AI, e a una frazione del costo.

Anche nella sua organizzazione, Kanban University, Anderson riconosce all’AI un ruolo utile, per esempio nelle operazioni IT che mantengono il sito e la piattaforma Kanban+. Ma da CEO ammette di non gradire quando l’AI, usata dai suoi collaboratori, finisce per generare più lavoro di revisione per lui: spostare il collo di bottiglia al vertice dell’azienda non è mai una buona strategia.

Il keynote completo, con tutti i dati e gli esempi qui solo sintetizzati, è disponibile integralmente sul canale YouTube di Kanban University: https://youtu.be/ZWfUq8Z9soc.

Organizzare per migliorare i servizi legali: perché l’AI non basta senza flussi di lavoro strutturati

Si parla sempre più di intelligenza artificiale come soluzione definitiva per rivoluzionare i servizi legali. La promessa è seducente: efficienza immediata, risultati straordinari. Ma c’è un rischio concreto che viene sistematicamente ignorato: se l’AI viene applicata in organizzazioni non strutturate, l’efficienza che si ottiene potrebbe essere solo un’illusione.

L’ottimizzazione locale non è efficienza di sistema

L’uso prevalente degli strumenti AI oggi è focalizzato sull’individuo: si accelera la redazione di un contratto, si comprime un’analisi da due ore a venti minuti. Il risultato sembra maggiore produttività. Questo però, dal punto di vista del pensiero sistemico, può significare che si spreca lavoro più velocemente.

Se un professionista all’interno di un flusso di lavoro redige più velocemente un documento ma il collo di bottiglia è la revisione affidata a una sola persona a valle della redazione, il revisore sarà ancora più sopraffatto. Più lavoro in ingresso genera più lavoro in corso, più code, più rilavorazioni. Questo è il rischio classico dell’ottimizzazione locale: si migliora una parte del sistema ma il sistema complessivo potrebbe peggiorare.

Uscire da questa logica richiede un cambiamento di prospettiva radicale: dall’individuo al flusso.

Un percorso sistemico

Il punto di partenza è riconoscere l’identità del team e sviluppare la collaborazione, uscendo dalla mentalità individuale in cui ognuno ottimizza solo il proprio lavoro indipendentemente dagli altri. Il passo successivo è spostare l’attenzione sul flusso: il team impara a coordinare il lavoro tra i professionisti, a farlo fluire invece di accumularlo. Si arriva infine a uno stadio in cui l’organizzazione è allineata attorno a uno scopo condiviso, capace di erogare il servizio in modo coerente con le aspettative del cliente, quello che in Lean si chiama essere fit for purpose.

È qui che l’AI diventa uno strumento potente. Non prima.

L’esperienza di Studio ExLege

Lo studio ExLege – fondato dall’Avv. Germana Cardea e con la collaborazione dell’Avv. Claudia Premoli – ha scelto di percorrere questo cammino in modo consapevole, con il mio supporto.

Il punto di partenza è stato l’approccio STATIK (Systems Thinking Approach to Implementing Kanban): un’analisi delle criticità esistenti, la definizione dei flussi di lavoro reali, l’identificazione delle fonti di variabilità e di attrito. Non si è partiti da zero: la prima Kanban board è stata ricavata da un foglio di calcolo già in uso, coerentemente con il principio Kanban di “iniziare da quello che si fa oggi”.

Le pratiche Kanban introdotte – visualizzazione del lavoro, politiche esplicite, cadenze di allineamento, metriche di flusso – hanno trasformato progressivamente la gestione dello studio da un sistema basato sulla memoria individuale a un sistema strutturato, visibile, prevedibile.

I risultati sono stati concreti e percepiti con chiarezza da tutti i professionisti coinvolti. La pressione è diminuita, perché il sistema aiuta a distinguere ciò che dipende dall’organizzazione da ciò che viene dall’esterno. La visibilità è aumentata: lo studio ha collegato le capacità dei singoli in un sistema e ha iniziato a navigarlo avendo a disposizione una ‘bussola e una mappa’. Le relazioni con i clienti sono migliorate, perché conoscere lo stato esatto di ogni pratica permette di comunicare con maggiore precisione e autorevolezza. L’inserimento di nuovi professionisti è diventato più fluido, grazie a protocolli chiari che riducono l’ambiguità. Inoltre, dettaglio controintuitivo, la struttura ha prodotto flessibilità, non rigidità: avendo il controllo del sistema, lo studio ha sviluppato metriche a supporto del processo decisionale – dall’accettazione degli incarichi, alla determinazione delle tempistiche di evasione, fino alle scelte di allocazione delle risorse.

La sintesi, nelle parole dei professionisti coinvolti: “non torneremmo indietro”.

L’AI come passo successivo, non come scorciatoia

L’esperienza di ExLege non è un caso isolato: è la dimostrazione pratica di un percorso che vale per qualsiasi organizzazione di servizi professionali. Prima si costruisce il sistema, poi si introduce la tecnologia.

L’AI non crea ordine dove non c’è ma, nel bene e nel male, amplifica ciò che trova. Applicata a un’organizzazione strutturata, può sbloccare valore reale: coordinare flussi complessi, supportare decisioni strategiche, ridurre il lavoro a basso valore cognitivo. Applicata al caos, lo accelera.

Il vero investimento non è nello strumento. È nell’organizzazione che lo sa usare.

Ho pubblicato originariamente questo articolo su LinkedIn il 3 settembre 2026

Smettete di iniziare, iniziate a finire: un consiglio per salvare Milano dai cantieri infiniti

Per chi vive a Milano, è diventata un’esperienza fin troppo comune: passeggiare per la propria via e scoprire una nuova area transennata, l’ennesimo cantiere che sbuca da un giorno all’altro. La frustrazione, però, arriva dopo. Passano le settimane, poi i mesi, e dietro a quelle recinzioni non accade nulla. I lavori non procedono, il cantiere resta abbandonato, e le aree verdi sequestrate alla cittadinanza si trasformano in piccole ‘savane’ di erba incolta.

Questa paralisi diffusa genera una domanda spontanea in molti cittadini: perché accade tutto questo? Con così tanti progetti da realizzare, perché così tanti cantieri rimangono fermi?

C’è un modo migliore per gestire le opere pubbliche, un metodo che potrebbe restituire la città ai suoi abitanti in tempi più rapidi e con meno disagi.

Il problema: l’illusione della produttività

Dal punto di vista della gestione dei processi, il problema di Milano è un classico esempio di sovraccarico del sistema, dove un carico di lavoro eccessivo porta alla paralisi. Il cuore del problema risiede nella tendenza ad aprire troppi fronti contemporaneamente. L’amministrazione avvia numerosi cantieri in tutta la città, disperdendo energie, risorse e manodopera su decine di progetti diversi. Questo approccio, simile a un multitasking su larga scala, crea l’illusione di una grande operosità, ma nei fatti si rivela controproducente.

Le conseguenze negative di questa strategia sono sotto gli occhi di tutti e pesano sia sulle casse comunali che sulla vita quotidiana dei cittadini:

Progetti che non avanzano mai: le risorse frammentate impediscono di completare rapidamente anche i lavori più semplici.
Aumento dei costi per il Comune: ogni giorno in più di cantiere aperto rappresenta un costo aggiuntivo.
Significativi disagi per i cittadini: strade chiuse, rumore, aree inaccessibili e degrado urbano si protraggono per mesi.
Allungamento a dismisura dei tempi: i cronoprogrammi diventano un miraggio, con scadenze costantemente posticipate.
Crollo della produttività generale: saltare continuamente da un’attività all’altra diminuisce l’efficienza complessiva del sistema.

La causa nascosta: perché si inizia senza finire?

Ma perché si adotta una strategia così palesemente inefficace? L’ipotesi più probabile è legata a una logica burocratica e procedurale. Spesso, una volta che i fondi per un’opera pubblica vengono stanziati, esiste il rischio che vengano persi se il cantiere non viene “ufficialmente iniziato” entro una certa data.

Per non perdere il finanziamento, si procede quindi ad aprire formalmente il cantiere, magari semplicemente recintando l’area, anche senza avere le risorse o il piano operativo per portare avanti i lavori in modo continuativo. Questo meccanismo, nato per garantire l’impiego dei fondi, genera un sistema inefficiente che, dal punto di vista della buona gestione e del buon senso, non ha alcuna logica.

La soluzione controintuitiva: limitare i lavori in corso

La soluzione a questo paradosso esiste ed è sorprendentemente semplice, anche se controintuitiva. Deriva da metodologie di gestione del lavoro collaudate a livello globale, come Kanban, nate in ambito produttivo ma oggi applicate con successo in ogni settore. Il principio fondamentale è: limitare i lavori in corso (limit WIP – Work in Progress).

Invece di iniziare dieci cantieri e non portarne a termine nessuno, l’amministrazione potrebbe concentrare tutte le sue risorse sul completamento di uno o due cantieri alla volta. Solo una volta che un cantiere è finito, chiuso e l’area restituita alla città, si potrebbe procedere con l’avvio del successivo. Il principio da adottare è potente nella sua semplicità:

“Smettere di iniziare il lavoro e iniziare a finirlo.”

I benefici: più efficienza per i cittadini

Adottare un approccio focalizzato sulla conclusione dei lavori porterebbe benefici immediati e tangibili, come suggerito dall’esperienza di molte organizzazioni di cui parlo su questo blog. Concentrare le risorse non solo risolve il problema dei cantieri fantasma, ma ottimizza l’intero sistema. I vantaggi principali sarebbero:

Tempi di completamento ridotti: concentrando le risorse, ogni singolo cantiere viene terminato molto più in fretta.
Massimizzazione delle risorse pubbliche: meno cantieri aperti in parallelo significa meno costi di gestione, meno disagi prolungati e un uso più efficace dei soldi dei cittadini.
Aumento della produttività complessiva: le squadre di lavoro non sono costrette a disperdere energie, operando con maggiore efficacia su un obiettivo alla volta.

Conclusione: finire è meglio che iniziare

L’immagine di una Milano costellata di cantieri fermi non è un segno di vitalità, ma il sintomo di un sistema di gestione che ha perso di vista l’obiettivo finale: servire i cittadini. La soluzione non richiede investimenti colossali, ma un cambio di mentalità. Passare da una cultura dell’iniziare a una cultura del finire è la chiave per sbloccare la città e migliorare la qualità della vita di tutti.

La vera domanda, a questo punto, è una sola. È pronta l’amministrazione di Milano ad abbracciare un approccio dove meno significa meglio per restituire finalmente la città ai suoi cittadini?

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

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

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

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

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

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

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

Mediocristan vs. Extremistan: comprendere la natura del mondo

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

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

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

Costruire l’antifragilità: sopravvivere al caos per disaccoppiamento

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

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

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

Conclusione: il costo del non sapere

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

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

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

Pillole di Kanban applicato: Il potere rivoluzionario di due vaschette di plastica

Nella mia esperienza di consulente, mi sono imbattuto spesso in organizzazioni governate dal cosiddetto “urlometro”. La priorità non è definita dal valore strategico, ma dal volume delle grida o dall’eroismo plateale dell’ultimo minuto. In questi contesti, ruoli critici come la segreteria o il supporto operativo vivono in uno stato di assedio permanente.

Le interruzioni costanti non sono solo un fastidio. Sono una forma di spreco che distrugge la capacità cognitiva e impedisce di entrare in uno stato di flusso. Proteggere il tempo di concentrazione non è un lusso, ma una necessità operativa. Eppure, la risposta istintiva delle organizzazioni di questo tipo è spesso quella di rifugiarsi in soluzioni tecnologiche che finiscono per aggravare il problema anziché risolverlo.

Quando il digitale è troppo: il paradosso dell’eccesso tecnologico

In un caso che ho affrontato di recente, abbiamo dapprima tentato di domare il caos attraverso una bacheca elettronica. Il risultato? Un fallimento totale, dovuto a un eccesso di ottimismo: lo strumento era troppo sofisticato per un ambiente con bassa maturità digitale e alta resistenza al cambiamento. Quando il divario tra la complessità dello strumento e l’utilità percepita è troppo ampio, la tecnologia diventa un ostacolo.

In contesti di forte attrito culturale, il digitale rischia di nascondere il sovraccarico dietro schermate che nessuno apre. In questi casi, la bassa tecnologia non è un limite, ma diventa un’opportunità strategica. È necessario un sistema che renda il lavoro “fisicamente ingombrante” e impossibile da ignorare.

Il sistema delle vaschette portadocumenti: semplicità e sovraccarico visibile

Per superare l’impasse, ho fatto implementare un sistema Kanban radicalmente analogico: due vaschette di plastica e lo spazio fisico della scrivania. A differenza di un software, dove è possibile accumulare centinaia di compiti invisibili senza che nessuno se ne accorga, la fisicità del sistema rende il sovraccarico impossibile da nascondere. Se il lavoro arriva più veloce di quanto se ne riesca a smaltire, non sparisce in un backlog invisibile: si accumula nella vaschetta “Da fare”, che comincia a traboccare. Il blocco del sistema diventa evidente a chiunque passi davanti alla postazione.

Il sistema si basa su tre stati chiari, utilizzando la lingua locale per massimizzare l’adozione e ridurre il carico cognitivo:

Vaschetta “Da fare”: il punto di ingresso unico per le richieste. Rappresenta il backlog fisico.
La scrivania (“In corso”): il perimetro del WIP limit. Se un documento è sulla scrivania, è l’unico su cui si sta lavorando e su cui si può lavorare.
Vaschetta “Fatto”: il deposito del valore completato, pronto per la consegna.

Questo supporto analogico forza visivamente il limite del lavoro in corso. È un meccanismo che rende il sovraccarico tangibile e non occultabile.

La policy della vaschetta: passare dal push al pull

Il cuore del sistema non sono le vaschette, ma la policy comunicativa. È lei a trasformare il flusso da push (interruzioni imposte dall’esterno) a pull (lavoro prelevato in base alla capacità disponibile). La regola è ferrea: “Se hai qualcosa da farmi fare, lasciami un foglio nella vaschetta”.

Abbiamo posizionato una risma di fogli accanto alla vaschetta come dispositivo a prova di errore. L’atto di dover scrivere la richiesta aggiunge un attrito intenzionale che funge da filtro. Se una richiesta non vale il tempo di essere scritta, probabilmente non valeva nemmeno l’interruzione.

Come consulente, insisto sulla logica del one-piece flow, fare una sola cosa alla volta. Quando si libera la capacità si pesca dalla vaschetta ‘da fare’. Si fa una cosa per volta, nell’ordine in cui è arrivata.

Questo buffer permette all’operatore di gestire le interruzioni interne (decidere quando iniziare un nuovo compito), invece di subire le interruzioni esterne (le richieste continue dei colleghi). Protegge così la qualità e la velocità di esecuzione.

Visualizzazione contro ansia: la bacheca informativa passiva

Il micro-management è spesso alimentato dall’ansia del “a che punto siamo?” Le interruzioni per chiedere aggiornamenti sono sprechi che generano altri sprechi. Il sistema a vaschette funge da bacheca informativa passiva: fornisce uno stato dell’arte asincrono senza richiedere interazione umana.

Il responsabile o il collega non ha più bisogno di chiedere. Gli basta osservare:

Il foglio è nella vaschetta “Da fare”? La richiesta è in coda.
Il foglio è sulla scrivania? La lavorazione è in corso in questo istante.
Il foglio è nella vaschetta “Fatto”? Il compito è terminato.

Questa trasparenza agisce come un sedativo per l’ansia da controllo. Elimina il bisogno di domande continue e risparmia all’operatore l’onere emotivo di dover difendere il proprio progresso.

Il triage delle urgenze: verifica delle priorità e il costo dell’attesa

Se tutto è urgente, nulla lo è. Per gestire le eccezioni senza far collassare l’ordine di arrivo, abbiamo introdotto l’uso di post-it rossi. Tuttavia, l’applicazione di un post-it rosso non è un diritto, ma il risultato di una verifica puntuale della priorità.

La domanda strategica da porre a chiunque voglia “saltare la fila” è: “cosa costa aspettare?”. Se il richiedente non sa quantificare il costo dell’attesa, la priorità viene negata. Se il costo è reale, il post-it rosso permette al compito di diventare il prossimo elemento prelevato non appena la capacità si libera. Questo meccanismo di triage protegge l’integrità del flusso per tutto il resto del lavoro.

Conclusione: la fine degli alibi

Il sistema delle vaschette portadocumenti è uno specchio onesto dell’efficienza aziendale. Funziona perché riduce la complessità e rende visibile il valore. Tuttavia, è bene essere chiari: se chi ha l’autorità per farlo, decide deliberatamente di ignorare le policy e continuare a scavalcare i processi con l’autorità, il sistema non reggerà.

Ma c’è un risultato fondamentale che si otterrà comunque: con un sistema del genere, gli alibi finiscono. Se il responsabile scardina le regole, non può più lamentarsi della disorganizzazione o dell’inefficienza dei suoi collaboratori. La responsabilità del caos torna nelle mani di chi lo genera.

Siamo pronti a perseguire una trasparenza che non lascia più spazio a scuse?