Ho trovato questo articolo di Mark Rosenthal su The Lean Thinker e pensavo di proporvelo come una cosiderazione su come andare a progettare i processi produttivi quando questi non sono molto chiari (ignoti) oppure quando si vuole trasformarli per il meglio.
Vediamo cosa ha da dirci Mark e poi commento sotto con le mie osservazioni:
Sto collaborando con due squadre che lavorano per sviluppare sistemi pull nelle loro aree di lavoro rispettive.
L’approccio convenzionale (suppongo) è di fare molte presentazioni in PowerPoint sul kanban, alcuni esercizi, sviluppare una mappa dello stato futuro e infine definire un piano di implementazione.
Un approccio alternativo è di avere un piccolo gruppo di esperti che progettano il sistema.
Per la maggior parte del tempo questi approcci risultano in processi ardui e in infiniti problemi una volta che i sistemi entrano nella piena funzionalità. Se la squadra non è preparata per questo, è probabile che il sistema si spezzerà in quanto le persone lo bypasseranno per necessità di eseguire il loro lavoro.
Quello che sto osservando questa settimana invece è più organico.
Prima, abbiamo coperto alcuni fondamentali riguardanti il flusso e segnali di pull tramite una semplice dimostrazione di “assembla e spingi” vs. flusso continuo con un limitatore visuale sull’inventario WIP. Hanno visto la produttività, stabilità, visibilità incrementare mentre il lead time è diminuito di un intero ordine di grandezza. Per fare questo ci è voluta un’ora di tempo.
La squadra poi ha creato una simulazione a tavola del loro flusso attuale, e si è esercitata più volte per confermare che si trattava di una rappresentazione veritiera del come le cose effettivamente funzionano oggi. Nel farlo, hanno appreso più a fondo della situazione attuale in quanto hanno dovuto replicarla.
Poi si sono messi a ricreare un modello reale del loro lavoro in modo tale che assomigli a qualcosa che si avvicini a quello che hanno visto nella dimostrazione. Per aiutargli partire, gli sono stati dati alcuni suggerimenti di alcune cose da provare, ed alcuni semplici principi e regole.
Alcuni di questi consigli comprendevano il fatto di eseguire i cambiamenti uno alla volta, cambiando un solo fattore per volta, facendo la previsione su cosa cambierà, e poi provandolo. Se vi trovate a speculare o a discutere altre speculazioni, provate e vedrete.
Dopo due giorni, le squadre hanno costruito un kanban a multipli loop che funzionava, e stanno definendo sperimenti per imparare come il sistema risponderà alle rotture delle macchine, agli improvvisi cambiamenti nel mix degli ordini, e altre cose che solitamente incontrano nel loro lavoro.
Stanno esplorando non solo la meccanica e le regole, ma la dinamica del processo che funziona. Stanno imparando cosa significa “normale” in funzione delle possibili situazioni anormali. Stanno testando i confini della loro conoscenza e comprensione – dove e quando occorrerà un problema e che aspetto ha una condizione errata contro qualcosa che si ripristinerà facilmente da solo.
Stanno capendo come rendere il sistema più robusto, senza farlo diventare ingombrante o troppo complicato.
Stanno prendendo confidenza e una profonda conoscenza facendo delle iterazioni attraverso scenari sempre più complessi.
Le persone che lo stanno facendo sono gli stessi che in futuro lavoreranno dentro quel stesso sistema. E noi stiamo osservando chi emerge come un leader del futuro.
Quello che hanno raggiunto adesso, a metà settimana, è un’immagine chiarissima della loro condizione target, e sono fiduciosi che possono farla funzionare anche nel mondo reale. Ci sono ancora delle incognite? Certo. Quelle ci sono sempre. Tradurre questo nel mondo reale coinvolgerà molti cicli di iterazione. Solo che adesso loro sanno esattamente come fare queste iterazioni in quanto ne hanno già provate a dozzine.
Questo esercizio in realtà è molto meno riguardante il kanban e molto più l’apprendimento di come acquisire conoscenza di un qualcosa che in passato era sconosciuto.
E’ una cosa bellissima da vedere, è molto più divertente (per tutti) che la pura implementazione di un processo progettato da qualcun’altro. Anche gli scettici vengono risucchiati dentro quando le persone stanno lavorando uno accanto all’altro per cercare di far funzionare qualcosa.
E sono veramente contento che questo processo funziona in quanto mi preserva dal fatto di dover conoscere tutte le risposte…
Esattamente quello di cui ho parlato anch’io nei giorni precedenti: quando si va in un territorio sconosciuto, bisogna provare, sperimentare, capire. E lo si fa nel gemba, con processi attuali.
Questo è un processo campione da usare, preso alla lettera dal libro Toyota Kata di Mike Rother. Non si può mai conoscere tutto, ma può esserci uno stato ideale, una condizione target all’apparenza irraggiungibile che, se conosciamo esattamente dove ci troviamo in questo momento, ci può guidare a dei miglioramenti graduali per avvicinarsi ad essa. E se questa è condivisa e conosciuta da tutti, il miglioramento avviene ad una velocità più alta.
Il processo descritto ricorda moltissimo al processo 3P che ho descritto in qualche articolo in passato, e trattato più a fondo nel mio libro Progettare Costi e Valore.
Quello che conta veramente in un’azienda non è il miglioramento dei processi, quello può anche essere imposto in qualche modo, ma è il miglioramento della conoscenza (know-how) delle persone. Sono le persone che lavorano nei processi che possono contribuire alla vera prosperità nel tempo della vostra organizzazione. Bisogna solo portarle a pensare e ragionare in maniera corretta, e allinearle verso gli obiettivi comuni e condivisi…
