Tag: gestione del flusso

Pubblicato il

Il motore calcola, l’AI confronta, la persona decide: l’applicazione in un caso reale

Al ritorno dal Kanban Leadership Retreat, ho scritto un articolo, “Perché collegare l’AI ai vostri dati di flusso non basta: le decisioni che qualcuno deve prendere”, su un tema che al retreat aveva occupato molto spazio: qual è la corretta architettura per introdurre l’AI in un sistema Kanban. La conclusione era che un agente AI da solo non basta, e che le cose vanno peggio se accede direttamente ai dati grezzi di flusso e li elabora in autonomia. Si ottiene una risposta plausibile ma non affidabile, che cambia quando cambia il workflow senza che nessuno se ne accorga.

Il ruolo giusto per l’AI è quello di interfaccia di un motore di flow analytics, che applica sempre le stesse definizioni di misura, con una persona (lo human in the loop) che quelle definizioni le ha decise e le mantiene. Nelle ultime settimane abbiamo applicato questa architettura a un lavoro vero: il Rolling Forecast dei progetti collegato al sistema Kanban di un’organizzazione.

Lo scenario: come funziona il Rolling Forecast

Il Rolling Forecast, del quale ho già parlato nell’articolo “Oltre il Gantt: il Rolling Forecast per introdurre Kanban e una pianificazione dinamica orientata al flusso”, permette di pianificare i progetti rispettando il limite di lavoro in corso e la capacità disponibile. Se la capacità non c’è, il progetto slitta in avanti, a volte anche all’anno successivo. Le date che ne escono vengono poi riportate sulle card della Kanban board, come inizio e scadenza.

Nel caso specifico su cui abbiamo lavorato, il Rolling Forecast è collegato a un sistema Kanban di portfolio progetti e ne recepisce le policy. Ogni progetto ha una taglia assegnata, e la durata attesa si ricava dall’85° percentile dei progetti già completati della stessa taglia. I progetti in coda si ordinano per priorità, poi per scadenza, poi per ordine di arrivo. Un progetto parte quando c’è capacità, ovvero un posto libero nei limiti al lavoro in corso, sia quello complessivo sia quelli delle singole persone assegnate. Quando un progetto finisce, il posto si libera e il successivo può partire. Il risultato è per ogni progetto una data di inizio e una di fine attese, che si ricalcolano quando cambiano i dati.

Due motori, un’AI e una persona

L’architettura nel nostro caso ha due motori. Il primo è il sistema Kanban in cui il lavoro è gestito, basato su Kanban Zone, che gestisce il flusso, raccoglie gli eventi e restituisce dati puliti: date di ingresso e uscita dalle colonne, taglie dei progetti, assegnatari. È lui il motore di flow analytics di cui parlavo nell’articolo precedente.

Il secondo motore non esisteva e l’abbiamo creato: un motore di calcolo del Rolling Forecast. Legge i dati del sistema Kanban e fa il forecast di pianificazione in funzione della capacità disponibile. Avremmo potuto chiedere il Rolling Forecast direttamente all’AI, che lo avrebbe dato per approssimazione statistica, ma non lo abbiamo fatto. Invece ci siamo fatti aiutare dall’AI a costruire un motore algoritmico, come il sistema Kanban, che faccia i calcoli corretti. Le regole che usa, cioè il percentile per ogni taglia, l’ordine in coda e i limiti per persona, sono scritte in un file di configurazione che chiunque può leggere. Non sono nascoste nella testa di chi pianifica, e non dipendono da come un’AI interpreta i dati.

Accanto a ogni regola il file indica da dove viene: dalla board, dal lavoro di pianificazione già esistente, oppure da un’ipotesi. Chi ha la responsabilità del sistema può quindi leggere una regola, discuterla, cambiarla, e il motore ricalcola applicandola sempre allo stesso modo. Sopra i due motori lavorano l’AI e la persona, con compiti diversi: li descrivo nella sezione successiva.

Chi fa cosa

I due motori calcolano, sempre allo stesso modo sugli stessi dati. Se un numero cambia, è perché sono cambiati i dati o è cambiata una regola scritta, mai perché qualcuno ha interpretato i dati in modo diverso. L’AI non calcola. Confronta i dati e gli output dei due motori, mette in evidenza le incongruenze e aiuta a riconoscere i pattern che in un elenco lungo non si vedono a occhio. La persona decide le regole e analizza l’esito del confronto.

Rispetto all’articolo precedente c’è un elemento in più, che è opportuno tenere distinto. L’AI ha scritto il codice del secondo motore, e la persona l’ha controllato e testato sulla board, verificando che l’output fosse quello previsto dalle regole.

Cosa è emerso

Il confronto fatto dall’AI sui dati dei due motori ha fatto emergere alcune domande che fino a quel momento erano rimaste implicite. Alcuni esempi danno bene l’idea di come funziona.

Il primo riguarda il momento in cui finisce il progetto. Un progetto completato, poi riaperto e chiuso di nuovo, risultava con due durate molto diverse a seconda di quale chiusura si considerava. Il motore di calcolo del Rolling Forecast ne sceglieva una per convenzione, e l’AI ha messo in evidenza l’incongruenza del dato. Cosa significhi “finito” per un lavoro che torna indietro è una policy di processo, e la scelta spetta a una persona.

Il secondo riguarda i limiti per persona. La policy della board fissa un numero massimo di progetti per ciascuna persona, ma non dice cosa fare quando un progetto è assegnato a più persone. Il motore di calcolo del Rolling Forecast ha bisogno di una regola per prevedere, e nella configurazione è stato necessario scriverne una, che per ora resta un’ipotesi: un progetto condiviso vale per ciascuno una frazione, da definire. L’AI ha messo in evidenza l’incongruenza tra ciò che la policy dice e ciò che il calcolo richiede. Completare la policy spetta a una persona.

Il terzo riguarda la durata attesa, che si ricava dal percentile dei progetti già completati della stessa taglia. Qui le incongruenze erano più d’una: i valori che avevamo ipotizzato inizialmente e quelli misurati non coincidevano per alcune taglie, il percentile si spostava molto a causa di pochi progetti lunghi, e due taglie quasi non si distinguevano per durata. Su quale base calcolare un valore su cui impegnarsi è una decisione ancora aperta che spetta a una persona.

Il confronto serve a capire

L’analisi fatta con il supporto dell’AI mette in evidenza le incongruenze, di qualunque tipo siano, e lo fa individuando dei pattern che in un insieme articolato di dati difficilmente si vedono a occhio. Ma l’AI si ferma lì: segnala delle incongruenze e può suggerire dei perché.

Ogni incongruenza può avere più cause. Può mancare una policy che il motore non conosce, perché esiste già nella pratica ma nessuno l’ha mai scritta. Può non essere aggiornata la board. Oppure può servire una policy nuova, che finora nessuno aveva avuto bisogno di definire e che il calcolo ha reso necessaria. Capire quale sia la causa, e quindi cosa fare, è il compito della persona che conosce davvero il sistema. L’analisi fatta con il supporto dell’AI le dà il punto da cui partire per evolvere il sistema, e la comprensione resta della persona.

Solo dopo aver capito arrivano le decisioni: introdurre una nuova policy, completarne una esistente, aggiornare la board. Ogni decisione di questo tipo rende il funzionamento del sistema più coerente, e le esecuzioni successive dei motori lo riflettono.

Conclusione

Il caso mostra all’opera l’architettura di cui scrivevo nell’articolo precedente: i motori calcolano su dati puliti, l’AI confronta e individua i pattern, la persona capisce e decide. Le incongruenze emerse riguardano il funzionamento del flusso e le policy del sistema: dove finisce un progetto, come si conta un limite, su quale base si stima una durata. Sono emerse perché i motori applicano sempre le stesse regole e il calcolo ne richiede di esplicite. Rieseguiti sugli stessi dati, producono gli stessi output, e le stesse incongruenze restano visibili. Usando i dati grezzi un’AI avrebbe potuto notarne qualcuna, ma senza regole stabili a ogni domanda avrebbe potuto dare una risposta diversa.

C’è poi un’aggiunta rispetto all’articolo precedente, che riguarda un possibile uso dell’AI: l’AI ha abbassato il costo di costruire un pezzo di motore che mancava, lasciando però il controllo alla persona.

Ora i due motori girano insieme. A ogni esecuzione producono dati su cui l’AI individua i pattern, e la persona li usa per capire e migliorare il sistema.

Pubblicato il

Dalla gestione delle persone alla gestione del flusso: un cambio di paradigma con effetti su scalabilità, AI, qualità e crescita manageriale

Pochi giorni fa, durante l’Officina del Kanban, una persona mi ha chiesto più volte perché dovrebbe dotarsi di metriche. Aveva costruito il suo sistema Kanban con cura e non ne sentiva il bisogno. Le ho chiesto a mia volta come fa a sapere quando il lavoro viene consegnato e la risposta è stata semplice: lei lo sa già, perché assegna il lavoro a ciascuno dei membri del team, e sono loro a comunicarle quando consegnano. Sono bravi e affidabili, quindi si fida di ciò che dicono.

Questa risposta mi ha fatto capire la reale situazione. Quella persona gestisce le persone e non il flusso, e il passaggio dall’una all’altra gestione è esattamente ciò che nel Kanban Maturity Model (KMM) separa il livello di maturità 0 dal livello 1. L’immagine che accompagna l’articolo ne mostra i due estremi.

Un sistema che regge finché le persone restano

Nella parte alta dell’immagine il lavoro da fare arriva al responsabile, che lo assegna alle persone, e ciascuna lo gestisce per conto proprio. Ognuno può avere la sua Kanban board, ma in pratica funziona come un’azienda indipendente. Una volta l’ho detto a un imprenditore che mi descriveva questo modo di lavorare: hai un’azienda di dieci persone, ma è come se avessi dieci aziende che lavorano in parallelo. Le persone non sanno cosa fanno le altre, quindi non esiste un vero lavoro di squadra, e il responsabile gestisce le persone più che il lavoro.

Finché le persone sono brave il sistema produce risultati, ed è per questo che chi lo adotta non sente la necessità di cambiare. Il suo limite è che dipende interamente dalle persone, e questo lo rende fragile. Una settimana di ferie ferma il lavoro di chi è assente, perché nessun altro lo ha in mano. Un’influenza lo rallenta e le dimissioni lo bloccano del tutto. Per lo stesso motivo il sistema scala con difficoltà: per crescere serve un altro collaboratore bravo, e finché non arriva l’organizzazione non cresce.

Torno così alla domanda sulle metriche. La fiducia nei singoli membri del team è ben riposta finché restano loro. Se uno si dimette e ne arriva un altro, quella fiducia non c’è ancora, e per costruirla occorre rilevarne le misure, che cambiano da persona a persona. Le metriche servono quindi in ogni caso, anche se in un sistema di questo tipo si fatica a percepirne il bisogno.

Gestire il flusso

Nella parte bassa dell’immagine la situazione cambia. La board è una sola, il responsabile gestisce il flusso e ciascuna persona collabora con lui per farlo avanzare. Non esistono più il lavoro mio, il lavoro tuo e quello di un altro, perché il lavoro è condiviso e ognuno ne è in parte corresponsabile. Il responsabile resta il titolare dell’accountability, ma ora il lavoro attraversa una sorta di catena di montaggio, una filiera intorno alla quale le persone si organizzano.

Nel KMM questo percorso si sviluppa in più tappe. A ML1 nasce il team, perché le persone iniziano a collaborare sugli stessi compiti. A ML2 compare il ruolo di Flow Manager, cioè di chi presidia il flusso: raccoglie le metriche, fa rispettare i limiti al lavoro in corso e facilita la risoluzione dei blocchi. Come ho descritto nell’articolo Come funziona Kanban: il Flow Manager per migliorare la gestione del flusso di lavoro, è un ruolo da svolgere più che un titolo: può assumerlo il responsabile, oppure un membro del team che si è offerto e ha le competenze adatte.

Un sistema meno fragile e più scalabile

Il sistema che ne risulta è meno fragile. Quando una persona manca, anche solo per un periodo, le altre possono prendere in carico il suo lavoro, perché in parte lo hanno già in carico. È anche più scalabile, perché chi arriva si inserisce in un sistema che procede da solo e ha una propria fisionomia, e contribuisce a gestire il lavoro senza doversi organizzare un flusso proprio.

C’è poi un’altra ragione. In un sistema così le persone più brave, che prima svolgevano il lavoro, possono evolvere e fare il jolly: non prendono lavoro in carico direttamente, ma si muovono su tutto il flusso e aiutano gli altri, in particolare i più junior, a crescere e a lavorare bene. Così chi arriva trova qualcuno che lo accompagna, e l’organizzazione può crescere senza aspettare un altro collaboratore già esperto.

Un sistema che forma nuovi manager

Si dice spesso che per crescere una persona debba diventare manager. Di frequente, però, la promozione si riduce a un nuovo titolo sul biglietto da visita, senza che nessuno le insegni il mestiere del manager.

Un sistema che evolve da ML0 a ML3 offre un’alternativa. Le persone che si vogliono far crescere imparano il mestiere lavorando con gli strumenti del flusso: leggono le metriche, gestiscono i limiti al lavoro in corso, facilitano la risoluzione dei blocchi. Quando poi diventano responsabili o assumono il ruolo di Flow Manager, quel mestiere lo conoscono già. Gestire il flusso non toglie spazio alle persone: è il modo in cui si insegna loro a diventare manager.

L’effetto sull’intelligenza artificiale

Il passaggio dalla gestione delle persone alla gestione del flusso ha una conseguenza anche sull’uso dell’intelligenza artificiale. Quando i flussi sono tanti quante sono le persone, le attività si duplicano. Se per esempio ciascuno fa la propria analisi e se la ottimizza con l’AI, lo stesso lavoro viene ripetuto molte volte. L’AI consuma token e il costo dipende proprio da quelli, per cui in un’azienda di qualche decina di persone che ripetono la stessa operazione il costo si moltiplica per il numero di persone coinvolte. Con un flusso unico l’analisi è una sola, e se serve l’AI la si applica lì.

Un flusso unico rende anche visibile il collo di bottiglia. Con tanti flussi i colli di bottiglia sono altrettanti e dipendono dalle persone, per cui non si capisce dove intervenire. Quando invece il collo di bottiglia è individuato, l’AI trova la sua collocazione corretta. Se la si mette a monte, intasa ancora di più il collo di bottiglia. Se la si mette a valle, si spreca la sua potenzialità, perché non si accelera nulla che sia già scarico.

C’è infine una possibilità in più. In un flusso unico si può provare a usare l’AI come attore del team, un agente che lavora con le persone, aiuta a orchestrare il flusso e a renderlo più efficiente. Dove il flusso non esiste però, non c’è nulla da orchestrare.

L’effetto sulla qualità

Un’ulteriore conseguenza riguarda la qualità. Dove il responsabile gestisce le persone, la qualità dipende da a chi viene assegnato il lavoro: se arriva a una persona brava il risultato è buono, se arriva a una meno brava lo è meno. Quando si passa a gestire il flusso, la qualità tende a dipendere sempre meno dalle singole persone e sempre più dal modo in cui il flusso funziona.

Avviene gradualmente man mano che il sistema evolve. A ML2 il risultato dipende ancora dall’impegno eroico dei manager. A ML3 la qualità non è più legata né agli eroismi individuali né a quelli manageriali, ma a una gestione del flusso consistente. Le persone continuano a essere più o meno brave, ma è il sistema nel suo insieme a determinare il risultato.

Perché le metriche servono sempre

Tornando alla persona dell’Officina, la sua fiducia nei singoli membri del team è giustificata finché sono loro a lavorare, ma non si trasferisce a chi arriva dopo. Le metriche servono comunque, e cambia solo il motivo. In un sistema che gestisce le persone servono per decidere se fidarsi di ciascuna, in un sistema che gestisce il flusso servono per gestirlo.

Conclusione

Il passaggio dalla gestione delle persone alla gestione del flusso è un cambio di paradigma organizzativo, non una questione di strumenti. Si parte da ML0, dove il responsabile assegna il lavoro e ciascuno se lo gestisce. A ML1 nasce il team e il responsabile smette di gestire le persone per occuparsi del flusso, a ML2 questo presidio diventa il ruolo di Flow Manager e a ML3 la qualità dipende dal flusso e non più dagli eroismi di persone o manager.

Le conseguenze sono concrete. Il sistema è meno fragile e più scalabile, perché il lavoro è condiviso e non dipende più da una sola persona. L’AI non viene duplicata da ciascuno per supportare le proprie attività ma si applica una volta sola, nel punto in cui il flusso ne ha bisogno. La qualità smette di dipendere da a chi viene assegnato il lavoro. Infine il sistema non rende le persone meno importanti: è il modo in cui si insegna loro il mestiere del manager, invece di limitarsi a promuoverle. Per migliorare non basta chiedersi quanto siano bravi i singoli: serve capire come funziona il flusso in cui lavorano e dare loro gli strumenti per poterlo gestire efficacemente.

Pubblicato il

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?

Pubblicato il

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

Pubblicato il

Il traffico cognitivo: il vero spreco del lavoro intellettuale

C’è uno spreco silenzioso che consuma ogni giorno una parte significativa del tempo dei team. Non è la riunione inutile, non è il processo ridondante. È qualcosa di più sottile: il continuo interrompere i colleghi per trovare un’informazione, il messaggio su chat inviato alle quattro del pomeriggio per sapere a che punto è una attività, la risposta attesa che blocca il lavoro proprio mentre si aspetta.

Chiamiamolo traffico cognitivo: la comunicazione non pianificata, destrutturata, generata non da reale collaborazione ma da asimmetria informativa. Tutti sanno dove si trovano le macchine in una fabbrica. Nel lavoro intellettuale (knowledge work), invece, le informazioni vivono nelle teste delle persone e trovarle richiede di interromperle.

Non si tratta di una percezione soggettiva. Lo dicono le ricerche sul communication overhead nel knowledge work, ma lo sperimentiamo tutti in prima persona e lo possiamo misurare facilmente con un piccolo esperimento: basta segnarsi su un foglio, per qualche giorno, le volte che interrompiamo o veniamo interrotti.

La lezione di Toyota: avvicinare le informazioni, non solo le persone

Toyota ha risolto un problema analogo in fabbrica con le celle di lavorazione (work cells): invece di disporre le macchine per tipo – tutte le fresatrici insieme, tutti i torni insieme – le ha raggruppate attorno al flusso di lavoro del prodotto. Il risultato è che un operatore non deve continuare a spostarsi per trovare quello che gli serve: è già vicino. Questo principio fa parte del Toyota Production System (TPS), il sistema di produzione che ha ispirato il pensiero Lean e, a cascata, buona parte dei metodi di gestione del lavoro contemporanei.

Negli uffici e nei team di knowledge work, il problema non è fisico: le persone non si spostano tra i reparti. Il problema è temporale e informativo. “Ci si sposta” con le dita sulla tastiera, mandando messaggi, cercando aggiornamenti, chiedendo conferme. La distanza da colmare non è metri, ma minuti e contesti.

Il principio sottostante alla cella Toyota, però, vale anche qui: se si rendono le informazioni accessibili senza dover chiedere, si elimina il bisogno di interrompere.

Visual management: la cella di Toyota per le informazioni

Una prima risposta per colmare la distanza informativa è il visual management, ovvero rendere lo stato del lavoro visibile a tutti i membri del team senza dover chiedere. Nelle fabbriche Toyota, ogni macchina, ogni kanban card, ogni indicatore è progettato per essere leggibile a colpo d’occhio. Nei team intellettuali, l’equivalente è la Kanban board: una rappresentazione visiva del lavoro in corso, in attesa e completato, aggiornata in tempo reale.

La pratica generale ‘Visualizza’ del metodo Kanban si articola in più di quaranta pratiche specifiche su sei livelli di maturità, che permettono la realizzazione di un solido sistema Kanban. Un sistema Kanban ben progettato riduce il bisogno di aggiornamenti via chat semplicemente perché chi vuole sapere può guardare la Kanban board.

Visual management e cadenze lavorano insieme: la board rende visibile lo stato del lavoro in ogni momento, le cadenze creano i momenti in cui quello stato viene discusso e aggiornato collettivamente.

Le cadenze: avvicinare le persone alle informazioni nel tempo

Una delle risposte più efficaci al traffico cognitivo sono le cadenze di coordinamento: riunioni brevi, sistematiche e con una frequenza precisa, progettate per condividere lo stato del lavoro in modo strutturato e prevedibile.

La pratica generale ‘Implementa cicli di feedback’ del metodo Kanban prevede un sistema articolato di otto cadenze, ciascuna con scopo e frequenza diversi: il Team Kanban Meeting quotidiano per sincronizzare il flusso; il Replenishment Meeting per decidere cosa fare entrare nel sistema; il Delivery Planning Meeting per allinearsi sulle consegne; la Service Delivery Review per valutare la qualità del servizio erogato; la Service Request Review per analizzare la domanda di servizio; l’Operations Review per ottimizzare il sistema operativo; la Strategy Review per riallineare priorità e direzione, la Risk Review per la gestione del rischio a livello sistemico. Non sono riunioni generiche: ognuna ha un perimetro informativo preciso e una lista di partecipanti coerente con quello scopo.

Il meccanismo è elegante nella sua semplicità: se so che domani mattina alle 9:15 avrò tutte le informazioni che mi servono in un Team Kanban Meeting di quindici minuti, non mando il messaggio stasera alle 17:47. La cadenza assorbe il bisogno. La chat rimane silenziosa.

Definition of Ready: avere tutte le informazioni quando servono

In un buon sistema Kanban viene anche implementata la pratica di Definition of Ready (DoR), nota anche come criteri di accettazione della richiesta.

Rappresenta una politica esplicita che stabilisce i requisiti informativi necessari affinché un elemento di lavoro possa superare il punto di impegno (commitment point). Questa pratica assicura che le richieste in entrata siano complete, chiare, coerenti e verificabili, inclusi i criteri per sapere quando il risultato è accettabile. La visualizzazione di questi criteri facilita il processo decisionale durante i Replenishment Meeting, garantendo che il team e il cliente abbiano una comprensione condivisa di ciò che è pronto per essere lavorato.

In definitiva, la DoR riduce la distanza informativa a valle, proteggendo il sistema Kanban da traffico cognitivo e incertezze, garantendo un’erogazione del servizio più fluida e prevedibile.

Perché funziona: il costo del ritardo informativo

Dietro queste logiche c’è un concetto fondamentale: il costo del ritardo (cost of delay). Ogni volta che un’informazione non è disponibile nel momento in cui serve, qualcuno la va a cercare – interrompendo se stesso e gli altri. Questo costo è quasi invisibile perché distribuito: qualche minuto qui, qualche scambio lì. Ma sommato su un team di dieci persone lungo una settimana, diventa una quantità di tempo e attenzione considerevole.

Le cadenze e la DoR non eliminano la comunicazione: la concentrano. Trasformano un flusso continuo e imprevedibile di interruzioni in momenti attesi, circoscritti e produttivi. Il parallelo con il pensiero Lean è diretto: così come il just-in-time elimina le scorte in eccesso producendo solo ciò che serve quando serve, cadenze e DoR eliminano la comunicazione in eccesso producendo il coordinamento solo quando e dove serve.

C’è anche una dimensione psicologica. La prevedibilità riduce l’ansia informativa: sapere che le informazioni arriveranno – e quando – permette di lavorare con più concentrazione nel frattempo. Le cadenze creano le condizioni strutturali perché questo sia possibile.

Cosa cambia in pratica

Introdurre cadenze di coordinamento efficaci richiede tre ingredienti. Il primo è una frequenza calibrata sul tipo di lavoro: troppo rare, non riescono ad assorbire le urgenze; troppo frequenti, diventano esse stesse un’interruzione. Il secondo è un formato chiaro: ognuno sa cosa porta e cosa si porta via, e la riunione non degenera in un aggiornamento generico. Il terzo è un sistema visivo che renda lo stato del lavoro leggibile senza dover chiedere – la Kanban board, appunto.

Nel Kanban Maturity Model (KMM), lo strumento sviluppato per misurare la maturità organizzativa nell’adozione del metodo Kanban, la capacità di progettare e mantenere cadenze efficaci è considerata un indicatore di maturità non banale: richiede che l’organizzazione abbia già sviluppato una certa trasparenza sul lavoro e una cultura di fiducia tra i team.

Quando questi elementi sono presenti, qualcosa cambia nel clima del team. Le chat si fanno più silenziose. Non perché le persone comunichino meno, ma perché comunicano meglio: nel momento giusto, con le informazioni giuste, senza interrompere il flusso di chi sta pensando.

Conclusione

Il vero spreco del knowledge work non è il tempo passato in riunione. È il tempo perso nel mezzo del lavoro a cercare informazioni che dovrebbero già essere disponibili. Toyota lo ha capito per le fabbriche disegnando le celle di lavorazione: avvicina fisicamente ciò che deve collaborare. Per i team intellettuali, la risposta ha una forma diversa – cadenze, visual management e DoR – ma una logica identica: progettare il flusso delle informazioni prima ancora di progettare il lavoro.

Le cadenze di coordinamento non sono uno strumento di controllo né un’altra riunione da calendario. Sono un sistema di riduzione del rumore – in un’epoca in cui l’attenzione è la risorsa più scarsa, ridurre il rumore è forse l’intervento organizzativo con il miglior rapporto tra semplicità e impatto.

Pubblicato il

La storia di XIT: come un team sull’orlo del caos ha ispirato il metodo Kanban

Nel celebrare il ventesimo anniversario del primo sistema Kanban in ambito IT, è fondamentale tornare alla storia che ha dato inizio a tutto. Come ha fatto un team, considerato il peggiore di Microsoft, a diventare il pioniere di una rivoluzione che avrebbe cambiato per sempre il modo di lavorare nei servizi? Questo non è un semplice caso di studio: è un racconto di trasformazione che traduce concetti astratti come “flusso” ed “efficienza” in lezioni concrete e accessibili a tutti. Al centro di questa vicenda c’è Dragoș Dumitriu, un manager che, contro il parere di chiunque, decise di prendere in carico il team con la peggiore reputazione dell’azienda, dando il via a un cambiamento tanto silenzioso quanto inarrestabile.

Il problema: un team condannato al fallimento

Per apprezzare il valore delle soluzioni adottate, bisogna prima comprendere la profondità della crisi in cui versava il team XIT. Quando Dragoș Dumitriu assunse il ruolo, la situazione era critica. Il team aveva la peggior reputazione quanto a servizio clienti all’interno di Microsoft. Il consiglio unanime dei suoi colleghi manager era di evitare quell’incarico a tutti i costi, perché “è noioso e… questo team non riesce a portare a termine le cose“. I fatti confermavano questa percezione: qualsiasi richiesta di lavoro impiegava in media 5 mesi per essere completata, un’eternità rispetto all’obiettivo aziendale di 30 giorni.

La sorpresa di Hyderabad

Il primo incontro di Dragoș con una parte del team, basato a Hyderabad, in India, rivelò una contraddizione stridente. Incontrandoli, non vide persone demotivate o incompetenti, ma un gruppo di professionisti sorridenti e capaci. Questa fu una rivelazione inaspettata e instillò in lui il dubbio che avrebbe guidato la sua indagine: “Mi chiedo cosa stia succedendo, perché vengono percepiti in modo così diverso da come li vedo io?” La reputazione disastrosa non sembrava corrispondere alle persone che aveva di fronte. Era chiaro che il problema non andava cercato negli individui. Occorreva passare dalle percezioni all’analisi oggettiva dei dati.

La nascita di una collaborazione

La collaborazione tra Dragoș e David Anderson nacque quasi per caso. In quello stesso periodo, Dragoș stava leggendo Agile Management for Software Engineering di Anderson quando vide un’email che annunciava un seminario sulla Teoria dei Vincoli tenuto da un collega di Microsoft, proprio un tale “David Anderson”. Verificato che si trattava dello stesso autore, decise di partecipare. David ricorda ancora come, al termine dell’intervento presso l’ufficio Honeywell, Dragoș lo raggiunse per presentarsi. Convinto che David potesse aiutarlo ad affrontare la sfida, gli chiese supporto. I due si accordarono così per incontrarsi nuovamente qualche giorno dopo, dando inizio a una collaborazione che avrebbe segnato la nascita del primo sistema Kanban in ambito IT.

L’indagine: i dati rivelano la vera causa del caos

Invece di cercare colpevoli, Dragoș cercò prove. Questo approccio, basato sui dati, è un principio cardine del pensiero Lean. Esaminando i dati già presenti nello strumento di tracciamento interno di Microsoft, emersero elementi che permisero di comprendere la reale natura del problema.

  • Sprechi di tempo: sviluppatori e tester passavano circa l’80% del loro tempo a inviare email. Di questo, il 50% era dedicato a sollecitare informazioni mancanti e il 30% a creare stime dettagliate per attività non ancora approvate.
  • Lavoro effettivo: di conseguenza, solo il 20% del tempo era realmente dedicato allo sviluppo e al test del software.
  • Sovraccarico cronico: ogni membro del team gestiva contemporaneamente tra i 60 e i 90 ticket aperti, creando un ingorgo continuo dove nulla riusciva a progredire.
  • Qualità delle richieste: le richieste provenienti dai clienti interni arrivavano estremamente incomplete, innescando il ciclo vizioso di email e ritardi.

Questo portò a una rivelazione inaspettata. Come ha osservato David durante il webinar del ventesimo anniversario, il team XIT era già un’organizzazione che oggi collocheremmo al livello di maturità 2 (ML2) del Kanban Maturity Model (KMM): avevano un processo definito e tutti i dati end-to-end tracciati nel loro strumento. Il problema non era la mancanza di dati: “avevano tutti i dati, ma nessuno li guardava, nessuno pensava al problema nel modo giusto“. La diagnosi finale di Dragoș fu inequivocabile: il problema non erano le persone, ma il sistema con cui il lavoro veniva gestito. La rivoluzione necessaria non era di processo, ma di prospettiva.

La soluzione: le mosse pratiche che diedero vita al metodo Kanban

La trasformazione di XIT non nacque da un manuale, ma da una serie di interventi manageriali tanto semplici quanto coraggiosi, nati direttamente dall’analisi dei dati. Queste azioni, nel loro insieme, costituirono l’essenza del primo sistema Kanban, anche se all’epoca non veniva ancora chiamato così.

Rendere visibile il lavoro e gestire le priorità

Il primo passo fu rendere visibile il caos. Dragoș creò una semplice tabella per mostrare a tutti lo stato delle attività, un precursore della moderna Kanban board. Usò un’efficace analogia: un fotografo non viene pagato per descrivere le foto che ha scattato, ma per mostrarle. Allo stesso modo, era necessario mostrare il lavoro, non solo parlarne.

Successivamente, affrontò il problema delle priorità. I cinque principali stakeholder inviavano ciascuno la propria lista di 10 priorità, generando 50 “priorità assolute” che paralizzavano il team. Quando tutto è prioritario, in realtà, niente è prioritario. Dragoș li riunì e li convinse a negoziare tra loro per produrre una sola lista consolidata di 10 priorità. Con le sue parole, decise di “dare in outsourcing il processo di prioritizzazione” agli stakeholder stessi.

Fermare il flusso di richieste incomplete

Per risolvere il problema delle richieste incomplete, che consumavano l’80% del tempo del team, fu introdotta una regola semplice ma rivoluzionaria: non si sarebbe iniziato a lavorare su nessuna attività finché tutte le informazioni necessarie non fossero state fornite dal richiedente. Questa mossa, definita sempre da Dragoș come “dare in outsourcing il lavoro di chiarimento al cliente“, liberò immediatamente una quantità enorme di tempo, permettendo al team di concentrarsi sul proprio vero lavoro.

Smettere di iniziare, iniziare a finire

La chiave di volta fu l’introduzione del principio “Stop starting, start finishing“. L’analisi aveva mostrato un numero enorme di attività iniziate ma mai concluse. Questo concetto, oggi noto come limite al Lavoro in Corso (WIP limit), fu implementato non attraverso una lavagna fisica, ma tramite nuove policy manageriali. Si creò così un “sistema Kanban virtuale”, dove il flusso veniva controllato per evitare il sovraccarico. Kanban, infatti, è prima di tutto un metodo di gestione e non solo uno strumento.

Sostituire le stime con le previsioni statistiche

Ma la vera mossa decisiva doveva ancora arrivare. Dragoș era appena atterrato da un viaggio a Hyderabad e si era diretto in ufficio per presentare i suoi progressi a un’assemblea di oltre 400 persone. Quando il suo General Manager, Dale Christian, un dirigente sei o sette livelli sopra di lui, gli chiese quale fosse l’unica cosa che avrebbe cambiato, Dragoș rispose: “Dobbiamo smettere di fare stime“. La risposta di Dale, davanti a tutti, fu un secco e sorridente: “No“.

Quella stessa sera, Dragoș si collegò con il suo team in India e disse loro l’esatto contrario. “Buone notizie, non dovete più stimare“. Si stava giocando tutto. Stava, come si diceva in Microsoft, mettendo il suo “badge sul tavolo”, pronto a essere licenziato se avesse fallito. Iniziò a usare gli oltre 200 dati storici per creare un modello di previsione. Invece di stime puntuali, offriva agli stakeholder un intervallo di probabilità. Il suo approccio fu diretto: “Quanti di voi sono soddisfatti delle previsioni del tempo?”. A chi rispondeva di sì, prometteva: “Farò la stessa cosa. Non avrò sempre ragione, ma sarò abbastanza vicino alla realtà la maggior parte delle volte“.

I risultati: una trasformazione misurabile

L’efficacia di questi interventi fu confermata dai dati. In soli nove mesi, il team, composto dalle stesse persone, raggiunse risultati significativi:

  • Produceva 5 volte più lavoro, 5 volte più velocemente.
  • I tempi di consegna crollarono da 5 mesi a un intervallo prevedibile tra 5 e 15 giorni.
  • Il backlog fu completamente azzerato. Come annunciò orgogliosamente Dragoș a David: “Abbiamo bruciato il backlog fino ad azzerarlo“.
  • L’efficienza del flusso (il tempo di lavoro effettivo rispetto al tempo totale) passò da circa l’8% a quasi il 90%. Un dato ancora più notevole se si considera, come ha sottolineato David, che un’efficienza iniziale dell’8% era in realtà abbastanza buona rispetto all’1-2% tipico in molti contesti.

Ma l’impatto più profondo fu quello umano. La trasformazione non fu solo una questione di efficienza, ma una vera e propria liberazione da un sistema insostenibile. La qualità della vita del team migliorò drasticamente, ponendo fine alla necessità di lavorare 12 o 14 ore al giorno solo per restare a galla.

La lezione di XIT e il futuro del lavoro

La storia del team XIT ha distillato principi che ancora oggi sono al centro delle moderne metodologie di gestione. Le lezioni chiave di questa trasformazione sono semplici ma potenti:

  1. Guarda al sistema, non alle persone: il problema raramente risiede nella competenza individuale, ma nel modo in cui il lavoro è organizzato.
  2. Rendi tutto visibile: la trasparenza è il primo passo per comprendere e risolvere qualsiasi problema complesso.
  3. Gestisci il flusso, non le persone: concentrati sul ridurre i ritardi e le interruzioni, non sul micro-management delle attività.
  4. Usa i dati per guidare le decisioni: le opinioni sono utili, ma i dati sono decisivi per promuovere cambiamenti significativi.

Questa storia, celebrata nel suo ventesimo anniversario, è più attuale che mai e dimostra come un approccio focalizzato sulla gestione del flusso possa trasformare anche le situazioni più disperate. Per ascoltare questo racconto direttamente dalla voce dei suoi protagonisti, David Anderson e Dragoș Dumitriu, la registrazione completa del webinar del ventesimo anniversario è disponibile su YouTube cliccando qui.

Pubblicato il

CONWIP vs. Drum-Buffer-Rope (DBR): scegliere lo strumento giusto in base alla maturità organizzativa

Durante il recente PMexpo ho riproposto il workshop Dal caos al flusso – sbloccare il potenziale del tuo team con Kanban. Gestire un laboratorio pratico sulla gestione del flusso con Kanban, con circa 40 partecipanti e un’ora e mezza di tempo a disposizione, è una sfida ma anche un’ottima opportunità per far toccare con mano a un pubblico ampio le dinamiche del flusso di lavoro. Abbiamo potuto verificare in modo empirico quanto sia immediato migliorare la produttività applicando la pratica di limitare il lavoro in corso: i partecipanti hanno osservato un incremento di produttività del 50%.

Sempre al PMexpo, in un interessante keynote speech della mattinata dal titolo molto simile – Le Regole del Flusso: dal caos alla gestione efficace negli ambienti multi-progetto – Efrat Goldratt-Ashlag e Gianluca Davico hanno mostrato come la Teoria dei Vincoli (TOC) possa essere applicata per riportare ordine, efficacia e risultati concreti negli ambienti multi-progetto.

Nel metodo Kanban si fa uso di entrambi gli approcci, e questo mi ha portato a una riflessione che voglio approfondire nel seguito dell’articolo: limitare il numero complessivo degli elementi di lavoro presenti nel sistema di flusso – ciò che più avanti definirò come CONWIP – rappresenta la soluzione per far evolvere, nelle prime fasi, le organizzazioni meno strutturate. La Teoria dei Vincoli (TOC), con il suo modello Drum-Buffer-Rope (DBR) – di cui ho già parlato in un precedente articolo – consente invece di gestire sistemi di flusso più maturi e complessi, permettendo di sfruttare in modo sempre più efficace i vincoli man mano che l’organizzazione cresce in capacità e consapevolezza.

Oltre la semplice scelta di uno strumento di pull

Sia il CONWIP (Constant Work-In-Progress) che il Drum-Buffer-Rope (DBR) sono potenti meccanismi di sistema pull (a chiamata), progettati per gestire il flusso di lavoro e migliorare le performance. Tuttavia, il loro utilizzo non è intercambiabile. Sebbene entrambi mirino a creare un flusso più stabile e prevedibile, operano a livelli di complessità e maturità organizzativa diversi. Applicare lo strumento sbagliato al contesto sbagliato può portare a frustrazione e insuccesso; al contrario, allineare la pratica al livello di maturità dell’organizzazione è un passo fondamentale verso un cambiamento evolutivo di successo. Prima di decidere quando utilizzarli, è imperativo comprendere cosa sono e per quale problema fondamentale sono stati progettati.

Definizione e concetti chiave

Per confrontare efficacemente CONWIP e DBR, è essenziale prima comprendere la loro definizione fondamentale e il loro scopo primario all’interno di un sistema di gestione del flusso di lavoro. Sebbene entrambi limitino il lavoro in corso, il loro focus e il meccanismo di controllo sono radicalmente diversi e rispondono a problemi distinti.

CONWIP: stabilire un limite a livello di sistema

Il sistema CONWIP (Constant Work-In-Progress), descritto nella pratica LW 2.1 del KMM, stabilisce un limite al numero totale di elementi di lavoro all’interno dell’intero sistema, indipendentemente dal loro stato specifico. Questo crea un sistema pull di base in cui un nuovo elemento di lavoro può entrare nel flusso solo quando un altro è stato completato e consegnato.

Il KMM lo descrive come un proto-kanban system, sottolineando che mantiene un controllo meno granulare sui singoli stati del flusso di lavoro rispetto a un sistema Kanban più maturo. Tuttavia, la sua forza risiede nella semplicità e nell’efficacia nel ridurre il sovraccarico dell’intero sistema, fornendo al team un primo, potente strumento per gestire il flusso end-to-end e alleviare la pressione generale.

DBR (Drum-Buffer-Rope): ottimizzare sfruttando un collo di bottiglia

Il Drum-Buffer-Rope (DBR), descritto nella pratica IE 5.4 del KMM, è un sistema pull molto più sofisticato, nato come meccanismo di implementazione pratica della Teoria dei Vincoli (TOC). È progettato specificamente per ottimizzare un sistema attorno al suo collo di bottiglia. Il suo meccanismo fondamentale è quello di regolare l’intero sistema in base al ritmo del suo vincolo principale.

Il meccanismo si basa su tre componenti:

  • Drum (Tamburo): il ritmo di lavoro del collo di bottiglia, che determina la velocità massima dell’intero sistema.
  • Buffer (Cuscinetto): una scorta di lavoro posizionata strategicamente subito prima del collo di bottiglia per garantirne il pieno sfruttamento e proteggerlo da interruzioni a monte.
  • Rope (Corda): il segnale che “chiama” nuovo lavoro nel sistema, permettendone l’ingresso solo al ritmo con cui il “Drum” completa il lavoro.

Lo scopo del DBR è di eseguire i passi chiave della TOC: “sfruttare” il vincolo e “subordinare” tutte le altre attività nel flusso di lavoro per proteggerne la capacità, massimizzando così il throughput complessivo.

Questi due approcci, come vedremo, trovano la loro collocazione ideale in fasi molto diverse del percorso evolutivo di un’organizzazione.

Il ruolo decisivo della maturità organizzativa

La scelta tra CONWIP e DBR non è una questione di preferenza tecnica, ma una decisione strategica dettata dal livello di evoluzione e comprensione che un’organizzazione ha dei propri processi. Il loro posizionamento distinto all’interno del Kanban Maturity Model (KMM) evidenzia come l’adozione di determinate pratiche debba essere allineata al livello di maturità raggiunto, per evitare di introdurre una complessità che l’organizzazione non è ancora pronta a gestire.

CONWIP: uno strumento per la maturità di livello 2 (ML2)

Un’organizzazione a livello di maturità 2 (ML2) è descritta nel KMM come “Customer-Driven”. In questa fase, il flusso di lavoro è emergente e, sebbene i processi siano consistenti, i risultati non lo sono ancora, portando a una situazione caratterizzata dall’espressione “mai due volte lo stesso risultato”. La sfida principale è alleviare un sovraccarico sistemico e indifferenziato, dove il vincolo principale non è ancora noto o è in continuo rapido mutamento.

In questo contesto, il CONWIP emerge come pratica di consolidamento ideale. È uno strumento appropriato perché l’organizzazione non è ancora in grado di attuare un’ottimizzazione sistematica. Come nota il KMM, a ML2 “l’organizzazione si affida a manager eroici per accelerare le richieste importanti dei clienti“. I clienti imparano a fidarsi di specifici manager, non ancora dell’organizzazione o dei suoi sistemi. Un meccanismo di controllo semplice e a livello di sistema come il CONWIP è perfetto per:

  • Introdurre un sistema pull di base senza richiedere una mappatura granulare.
  • Fornire un sollievo immediato dal sovraccarico generale.
  • Aiutare l’organizzazione a iniziare a gestire il flusso end-to-end, un passo cruciale per evolvere oltre il focus sui singoli team tipico invece di ML1.

DBR: una pratica avanzata per la maturità di livello 5 (ML5)

Un’organizzazione a livello di maturità 5 (ML5) è descritta come “Market Leader”. A questo livello, l’organizzazione è caratterizzata da una “ricerca incessante della perfezione” e da un’ottimizzazione continua dell’efficienza e delle performance economiche. Possiede un’agilità derivante da un design organizzativo orientato ai servizi ed è in grado di riconfigurarsi prontamente per offrire nuovi servizi. Ha una profonda comprensione quantitativa del proprio sistema stabile e dei propri processi.

Il DBR è una pratica di consolidamento ML5 proprio perché la sua implementazione richiede questo livello di maturità. L’organizzazione ha la capacità di identificare un vincolo unico, sufficientemente persistente e definito che limita le performance dell’intero sistema. Il DBR non è solo una soluzione a un collo di bottiglia; è uno strumento strategico utilizzato da un’organizzazione altamente adattabile per:

  • Sfruttare un vincolo identificato con precisione per massimizzare il throughput.
  • Subordinare disciplinatamente tutte le altre attività a quell’unico vincolo.
  • Allineare l’intero sistema a un obiettivo di ottimizzazione economica, consolidando la propria leadership di mercato.

La scelta, quindi, non dipende solo da quando nel percorso di maturità, ma anche dal perché, ovvero dalla natura del problema che l’organizzazione sta affrontando.

Circostanze d’uso e problemi risolti

Oltre al livello di maturità, le circostanze specifiche e il problema che si sta cercando di risolvere sono determinanti per la scelta corretta dello strumento. CONWIP e DBR sono progettati per affrontare sfide fondamentalmente diverse: la prima mira alla stabilizzazione, la seconda allo sfruttamento.

Quando usare CONWIP: stabilizzare il sistema per gestire il sovraccarico indefinito

Il CONWIP è la scelta ideale quando il problema principale è un sovraccarico generale e non differenziato del sistema, piuttosto che un singolo punto di blocco chiaramente identificato.

Scenario tipico:

  • Un’organizzazione sta passando da un focus sui team (ML1) a un focus sul servizio (ML2).
  • Il flusso di lavoro end-to-end è ancora in fase di definizione (“emergente“).
  • La sensazione prevalente è che “tutto è una priorità” e le persone sono costantemente sovraccariche, ma non è chiaro quale sia il vero vincolo.

In queste circostanze, l’obiettivo primario non è ottimizzare, ma stabilizzare. CONWIP introduce un segnale di pull a livello di sistema che costringe l’organizzazione a finire il lavoro prima di iniziarne di nuovo. Questo riduce il multitasking e permette di creare le condizioni di base per comprendere il sistema e iniziare a misurare un lead time più significativo.

Quando usare DBR: sfruttare un collo di bottiglia definito

Il DBR è appropriato quando l’organizzazione ha raggiunto una comprensione del proprio processo, al punto da aver identificato un collo di bottiglia chiaro e persistente che limita le performance dell’intero sistema.

Scenario tipico:

  • L’organizzazione ha già un flusso di lavoro stabile e prevedibile (ML3/ML4).
  • L’analisi quantitativa dei dati di flusso (es. diagrammi di flusso cumulativo) mostra un accumulo costante di lavoro in una fase specifica.
  • L’obiettivo è aumentare il throughput complessivo agendo in modo mirato su quel singolo vincolo.

In questo scenario, l’obiettivo è sfruttare il vincolo noto per massimizzare il throughput totale. Il DBR fornisce il meccanismo per garantire che il collo di bottiglia non sia mai inattivo (grazie al buffer) e che il resto del sistema non lo sovraccarichi (grazie alla corda), ottimizzando così l’intero sistema attorno al suo punto di leva più efficace. Se il vincolo si sposta, il sistema DBR viene ricalibrato per sfruttare il nuovo vincolo e mantenere il flusso nelle migliori condizioni di performance. Un sistema così equilibrato e ottimizzato può poi essere “elevato” per aumentarne la capacità produttiva.

Conclusione: maturità e contesto guidano la scelta

La scelta tra CONWIP e DBR deve essere una decisione informata, guidata da una valutazione onesta della maturità organizzativa e della natura del problema specifico che si intende risolvere. Il CONWIP è uno strumento di stabilizzazione per un’organizzazione ML2 che affronta un sovraccarico sistemico e indifferenziato. Il DBR è uno strumento di sfruttamento per un’organizzazione ML5 che ha identificato un vincolo definito e possiede la disciplina per ottimizzare l’intero sistema attorno ad esso.

Tentare di implementare il DBR in un’organizzazione a bassa maturità, senza una chiara comprensione del flusso e dei suoi vincoli, è una soluzione rischiosa. Allo stesso modo, limitarsi al CONWIP quando si è raggiunto un maggiore livello di maturità e si ha un chiaro collo di bottiglia, significa lasciare sul tavolo significative opportunità di miglioramento. L’applicazione dello strumento giusto al momento giusto non è solo un principio fondamentale del cambiamento evolutivo, ma un passo cruciale verso il raggiungimento di una maggiore agilità, resilienza e performance aziendale.

Pubblicato il

Presentazione del libro “Dal caos al flusso” al PMexpo

In occasione del PMexpo, avremo il piacere di presentare in anteprima il mio libro Dal caos al flusso: La trasformazione organizzativa con il metodo Kanban.

Ho raccolto in questo volume una selezione di articoli pubblicati nel tempo, organizzati in modo logico e per argomenti, al fine di facilitarne la lettura e la comprensione.
L’opera intende offrire un approccio pragmatico e operativo al Metodo Kanban, con particolare attenzione all’applicazione concreta dei principi nei contesti organizzativi reali. La pubblicazione è arricchita dalla presentazione di David J. Anderson, ideatore del Metodo Kanban e autore del libro bestseller Kanban: Successful Evolutionary Change for Your Technology Business.

Contenuti e obiettivi del volume

Dal caos al flusso si propone come una guida pratica alla trasformazione organizzativa, con particolare riferimento ai contesti caratterizzati da incertezza e variabilità. Tra i principali temi trattati:

  • Guidare il cambiamento evolutivo
    Il Metodo Kanban promuove un cambiamento incrementale e rispettoso dell’esistente, che parte da ciò che l’organizzazione già fa e valorizza ruoli e responsabilità, riducendo al minimo la resistenza interna.
  • Controllare il rischio operativo attraverso il flusso
    Il concetto di Flow (flusso) è al centro dell’approccio Kanban.
    Un flusso stabile e prevedibile costituisce il principale meccanismo di controllo del rischio operativo e consente una consegna di valore sostenibile nel tempo.
  • Gestire progetti, programmi e portfolio
    Il libro introduce i fondamenti del Kanban Project, Programme e Portfolio Management (KPPM), un modello che integra pensiero sistemico, gestione dei flussi e cultura collaborativa orientata allo scopo.
  • Introdurre pratiche e strumenti operativi
    Vengono inoltre presentate le modalità di applicazione dell’approccio STATIK (Systems Thinking Approach to Introducing Kanban) per la progettazione di sistemi Kanban su misura.
  • Fare leva sui ruoli emergenti
    Sono approfonditi anche i ruoli emergenti di Flow Manager e Delivery Manager, figure chiave per garantire la performance del flusso e la responsabilità operativa all’interno dell’organizzazione.

Il Project Manager ridisegnato: da “pompiere” a “risk manager”

Uno dei messaggi del libro riguarda la necessità di una profonda evoluzione del ruolo del Project Manager. Per affrontare la complessità crescente dei contesti organizzativi, il Project Manager deve trasformarsi da figura reattiva — il “pompiere” che interviene a emergenza avviata — a risk manager, in grado di agire in modo proattivo per prevenire criticità e migliorare la prevedibilità dei risultati.

L’adozione di sistemi Kanban consente di rendere le organizzazioni basate sulla conoscenza più stabili, affidabili e orientate al valore, favorendo una gestione strutturata del rischio operativo.

Invito alla lettura

Dal caos al flusso nasce dall’esperienza diretta maturata sul campo e rappresenta un invito alla riflessione e all’azione per tutte le organizzazioni che intendono intraprendere un percorso verso una maggiore agilità e prevedibilità.

Invitiamo i professionisti presenti al PMexpo a visitare lo stand di E-quality Italia per approfondire i contenuti del volume. Chi lo desidera potrà acquistare direttamente allo stand la propria copia di Dal caos al flusso a un prezzo scontato speciale.
Un’occasione per avviare un percorso concreto di trasformazione dal caos al flusso.

Pubblicato il

Pillole di Kanban applicato: inefficienze e potenziali miglioramenti nella gestione del flusso autostradale italiano

Un anno fa ho scritto un articolo su come gli svizzeri utilizzano gli stessi principi del metodo Kanban per far funzionare meglio le autostrade e ottimizzarne il flusso. In questo articolo voglio condividere invece alcune osservazioni personali sulle autostrade italiane, raccolte durante un recente viaggio. Ho voluto approfondire il modo in cui vengono gestiti i flussi di traffico e devo dire che alcuni aspetti mi hanno colpito in modo particolare.

L’altro giorno, percorrendo la tratta Bologna–Milano in un giorno feriale – con un traffico piuttosto intenso di camion – mi sono saltati all’occhio alcuni aspetti interessanti che avevo già avuto modo di osservare in altre occasioni.

La tratta a quattro corsie (Bologna-Modena): lo spreco di un quarto della capacità

Tra Bologna e Modena, l’autostrada presenta quattro corsie. Ecco cosa ho notato, e chiunque passi di lì può confermarlo:

  • I camion tendono a stare sulla prima corsia.
  • Occasionalmente, alcuni camion si spostano sulla seconda corsia per superarne un altro.
  • La terza corsia è di gran lunga la più occupata; sembra che molti automobilisti siano abituati a stare nella corsia di mezzo quando ce ne sono tre, e si spostano nella terza (quella prima della corsia di sorpasso) quando ce ne sono quattro.
  • La quarta corsia, quella di sorpasso, è semi-intasata da macchine che superano.

L’effetto più sorprendente, tuttavia, è stato che la seconda corsia era sostanzialmente vuota. C’era un certo traffico, eppure se ci si spostava dalla terza alla seconda corsia e si manteneva una velocità costante, anche di 130 km/h, si poteva procedere quasi senza ostacoli. Questo mi ha fatto riflettere su un problema enorme: una perdita di capacità di quasi un quarto. Su quattro corsie, averne una vuota significa che il 25% della capacità dell’autostrada non viene utilizzata, il che è semplicemente assurdo.

La tratta a tre corsie (dopo Modena): colli di bottiglia costanti

Dopo Modena, l’autostrada si riduce a tre corsie, e anche qui ho riscontrato problemi nella gestione dei flussi:

  • La prima corsia è dedicata ai camion.
  • La seconda è la più intasata, dove si trova la maggior parte dei veicoli.
  • La terza è per il sorpasso.

Il guaio arriva quando un camion decide di superarne un altro. Si sposta in seconda corsia, e questo crea immediatamente un collo di bottiglia. Chi si trova in seconda corsia, viaggiando tipicamente a 110-120 km/h, frena o tenta di spostarsi a sinistra per superare. Questo blocca i veicoli più veloci che arrivano sulla terza corsia e dovrebbero superare, generando un intasamento.

Ho osservato che se un camion che va a 80-90 km/h viene superato da un altro che va poco più veloce, possono volerci diversi chilometri e un tempo considerevole prima che il sorpasso si completi. Questo mantiene il collo di bottiglia attivo per un periodo prolungato, con conseguenti ingorghi.

La causa profonda: mancanza di governo del flusso

Sia nel caso delle quattro corsie con lo spreco di capacità, sia in quello delle tre corsie con i continui ingorghi, il malfunzionamento dell’autostrada è chiaramente dovuto a una mancanza di governo del flusso. Sono convinto che se il flusso fosse gestito, come fanno gli svizzeri, la capacità dell’autostrada potrebbe essere sfruttata molto meglio.

Ipotesi di soluzioni basate sul modello svizzero:

È importante premettere che alla base di qualsiasi soluzione c’è, da un lato, la volontà di gestire il traffico e, dall’altro, la disponibilità degli automobilisti ad accettare tale gestione. In ogni caso, le possibili soluzioni dovrebbero includere le seguenti opzioni:

  • Per le quattro corsie: si dovrebbe fare in modo che tutte le corsie siano occupate e che la velocità sia costante per ciascuna corsia. In questo modo, non si creerebbero ingorghi a sinistra (terza e quarta corsia) e non ci sarebbe una corsia completamente vuota. Questo significa in qualche modo “obbligare” i guidatori a occupare maggiormente la seconda corsia e a procedere in modo regolare. Questo porterebbe a una stabilizzazione del flusso, esattamente come fanno gli svizzeri.
  • Per le tre corsie: è fondamentale regolare meglio il flusso dei camion. Impedire sorpassi lunghissimi e lenti potrebbe prevenire la formazione di colli di bottiglia che durano per chilometri e minuti preziosi.

È importante sottolineare che tutte queste osservazioni sono state fatte in un giorno che non era classificato come “bollino nero” o nemmeno “bollino rosso”. L’autostrada era scorrevole, seppur con alcuni singhiozzi. Ma sarebbe bastato un minimo di traffico in più – anche senza arrivare a un giorno da “bollino rosso” – per creare il classico fenomeno delle code a tratti.

In conclusione, credo che un intervento sulla gestione e il governo del flusso sia essenziale per ottimizzare l’utilizzo delle nostre autostrade, rendendole più efficienti e meno soggette a ingorghi. In gran parte, si tratterebbe semplicemente di far rispettare le regole già esistenti, come spiega in modo molto chiaro il video della Polizia Stradale disponibile a questo link.

Pubblicato il

Pillole di Kanban applicato: Ferragosto alle terme

Quest’anno, durante le ferie, ho deciso di approfittare per fare qualche giornata di cure termali.

Quando ho chiamato per prenotare, l’operatrice mi ha chiesto subito giorni e orari precisi in cui pensavo di andare. Io ricordavo dalla volta precedente che, in realtà, potevo presentarmi liberamente. Ma lei, agenda alla mano, ha insistito: “Per prenotare bisogna fare così”.

Così ho scelto 12 date, sempre al mattino presto.
Arriva il giorno della prima inalazione: mi presento all’accettazione e chiedo se posso cambiare orario. La risposta mi sorprende:
“Può venire quando vuole. La tessera registra la sua presenza, le stampa il ticket, e lei fa l’inalazione.”

E così ho iniziato a gestire da solo il mio flusso: a volte andavo in orari diversi, altre volte in giorni non previsti. Il sistema funzionava sempre, indipendentemente dal mio arrivo. Al massimo, in giornate più affollate, aspettavo 5 minuti in coda.

Solo in quel momento ho capito: quella “prenotazione” iniziale non era un vincolo reale, ma una capacity reservation. Serviva a stimare il carico di lavoro giornaliero, per poter gestire le code e garantire un servizio fluido.

In altre parole: Kanban in azione, anche in un contesto apparentemente lontano dal lavoro e dalla produttività.

Un semplice impianto termale mi ha ricordato due lezioni importanti del Kanban:

  1. Visualizzare la capacità disponibile prima che il lavoro arrivi.
  2. Mantenere flessibilità per adattarsi alla domanda reale, senza creare colli di bottiglia

E mentre respiravo il vapore delle inalazioni, ho pensato: a volte la gestione del flusso non è solo un concetto aziendale… è una filosofia che ti segue anche in vacanza.

Buon Ferragosto!