Uno degli aspetti che trovo più affascinanti e rivoluzionari di Kanban è l’abolizione della pianificazione nel senso tradizionale del termine. Un’affermazione che, in ambito aziendale, spesso suscita sguardi perplessi e il sospetto che si tratti di una mera provocazione. Eppure, il punto è proprio questo: Kanban elimina la pianificazione perché essa, semplicemente, non funziona. Il motivo? L’impossibilità di prevedere ogni variabile in modo deterministico.
Al suo posto, Kanban introduce un approccio diverso, basato sull’analisi del rischio e dell’incertezza. Più che pianificare, si adotta un approccio di forecasting che è sorprendentemente vicino a quello della “navigazione stimata” nella barca a vela. Proprio come un’imbarcazione che si muove sulla superficie al confine tra due fluidi e adatta la sua rotta alle condizioni del vento e del mare, un sistema Kanban si muove in un contesto dinamico e complesso, dove la realtà non segue schemi prestabiliti. E forse è proprio questa la sua forza: accettare l’incertezza, invece di combatterla con previsioni che spesso si rivelano illusorie, e imparare a navigarla con agilità.
La navigazione stimata
La navigazione stimata in barca a vela è un metodo per determinare la propria posizione e tracciare la rotta basandosi su calcoli e osservazioni di punti di riferimento, venti, correnti e condizioni meteorologiche. Si parte da un punto noto e, tenendo conto della velocità dell’imbarcazione, della direzione del vento, della corrente e del tempo trascorso, si stima dove ci si trova in un dato momento. Questo approccio non è statico, ma dinamico: man mano che si procede, si raccolgono nuove informazioni – ad esempio, cambiamenti nelle condizioni meteo o nella direzione e intensità del vento – e si adatta la rotta e la previsione di viaggio di conseguenza. Proprio come in un sistema Kanban, la chiave della navigazione stimata non è pianificare rigidamente, ma correggere il percorso in base alla realtà del momento, accettando l’incertezza come parte integrante del viaggio.
Parallelismi tra la navigazione stimata e Kanban
Dipendenza dalle condizioni attuali
Sia in mare che nei progetti, le condizioni iniziali sono solo un punto di partenza. Un navigatore si basa su venti, correnti e posizione attuale per prendere decisioni consapevoli e adattare continuamente la rotta. Allo stesso modo, un team Kanban osserva il flusso di lavoro, identifica i colli di bottiglia, e modifica le modalità di gestione del flusso di lavoro in base a ciò che emerge. L’attenzione si concentra su ciò che è “in corso”, limitando il carico di lavoro per garantire che ogni attività sia completata prima di iniziarne un’altra.
Previsioni e non certezze
Un navigatore può prevedere la durata del viaggio, ma sa che condizioni non del tutto previste possono influenzare il percorso e utilizza in modo costante le previsioni meteomarine, che sono basate su analisi di tipo probabilistico. Similmente, in Kanban si utilizzano misure basate su dati storici per prevedere la durata delle attività, tenendo però sempre conto della loro variabilità statistica per fare un’analisi di probabilità.
Adattamento continuo alle condizioni
Il viaggio di una barca a vela non è mai lineare. I navigatori correggono costantemente la rotta, sfruttando le nuove informazioni e reagendo agli imprevisti. Anche in Kanban, la gestione del flusso è un processo iterativo, dove si acquisiscono informazioni e si incontrano ostacoli imprevisti lungo il percorso e si adatta il modo di lavorare di conseguenza.
Monitoraggio continuo
Il navigatore utilizza gli strumenti di bordo e i rilevamenti per verificare la posizione e confrontarla con il percorso pianificato. In Kanban le metriche come il lead time e il throughput aiutano a capire se il sistema sta funzionando correttamente e dove sono necessari interventi.
Importanza della comunicazione
Una buona comunicazione è vitale sia a bordo di una barca a vela che in un team Kanban. I membri dell’equipaggio devono condividere informazioni sulle condizioni del mare e sulle manovre necessarie. Analogamente, la trasparenza e la collaborazione sono essenziali in Kanban per garantire che tutti i membri del team siano allineati e informati.
Flessibilità e feedback
La navigazione stimata privilegia l’adattamento alle circostanze rispetto a un piano rigido, un navigatore pone costante attenzione ai segnali ambientali e sviluppa la capacità di anticipare i cambiamenti. In Kanban allo stesso modo, i cicli di feedback costanti e la flessibilità sono fondamentali per reagire tempestivamente ai cambiamenti e garantire il successo dei progetti e dei servizi.
Gestione delle dipendenze
Come un navigatore deve considerare le maree e le correnti, un team Kanban deve gestire le dipendenze tra le attività. Questo richiede accorgimenti e meccanismi opportuni per garantire che il flusso di lavoro non venga interrotto.
Orientamento al flusso
In barca a vela, uno degli obiettivi fondamentali è mantenere l’imbarcazione in movimento, adattandosi continuamente alle condizioni del vento e del mare. Il navigatore controlla costantemente il movimento della barca, regolando le vele per mantenere la rotta. Se la barca si ferma o perde troppo slancio, ripartire diventa difficile e inefficiente. Lo stesso principio si applica al concetto di flusso in Kanban, l’obiettivo è mantenere il flusso costante, garantendo che il lavoro proceda senza intoppi, riducendo blocchi e interruzioni.
Non conta partire, conta arrivare
In barca a vela, ciò che conta davvero non è la velocità assoluta dell’imbarcazione, ma la Velocity Made Good (VMG) on course, ovvero la velocità effettiva con cui ci si sta avvicinando alla destinazione. Una barca può muoversi rapidamente, ma se la direzione non è quella giusta, il progresso reale sarà minimo. Lo stesso principio si applica a Kanban, non è importante quanto velocemente si lavora in un dato momento, ma quanto lavoro viene effettivamente consegnato. L’obiettivo non è essere sempre impegnati o lavorare al massimo della velocità, ma completare il lavoro nel modo più efficiente possibile, riducendo sprechi e rallentamenti. Come in navigazione, l’essenziale non è l’illusione del movimento, ma il progresso reale verso la meta.
Conclusione
Kanban e la navigazione stimata in barca a vela condividono un principio fondamentale: il successo non dipende da piani rigidi, ma dalla capacità di osservare, misurare, adattarsi e rispondere ai cambiamenti. In entrambi i casi, l’obiettivo non è fissare una rotta immutabile, ma ottimizzare il flusso per avanzare in modo efficiente e consapevole. Così come un velista parte con una direzione generale, sfrutta previsioni e stime per tracciare il percorso, ma è sempre pronto a correggere la rotta in base alle condizioni reali, allo stesso modo Kanban permette di gestire il lavoro in modo dinamico, adattandosi alle sfide man mano che emergono. Questa flessibilità non è solo una necessità, ma la chiave per navigare con successo la complessità, trasformando ogni progetto o servizio in un viaggio in cui conta non solo la meta, ma anche il modo in cui la si raggiunge.
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.
L’analisi STATIK (Systems Thinking Approach to Introducing Kanban) è un metodo strutturato per introdurre Kanban in un’organizzazione, garantendo un flusso di lavoro efficiente e ottimizzato. Il suo valore risiede nella capacità di analizzare il sistema esistente, comprendere la domanda di lavoro, identificare i colli di bottiglia e progettare un sistema ‘pull’ su misura per le esigenze del team. Attraverso un approccio basato sul pensiero sistemico, STATIK aiuta le aziende a migliorare la gestione del lavoro, aumentare la trasparenza e favorire un’evoluzione sostenibile dei processi operativi.
Per aiutarvi a comprenderne meglio le dinamiche, ho tradotto un’interessante guida scritta da due colleghi brasiliani – Cleiton “Caco” Mafra e Lucas Guimarães – i quali hanno anche creato uno strumento visuale che utilizzo tantissimo, lo STATIK Canvas.
STATIK Canvas – La migliore guida pratica per iniziare a lavorare con Kanban
Sebbene molte persone abbiano già avuto contatti con STATIK nei corsi di formazione, ci rendiamo conto che la maggior parte di loro ha dubbi su come applicare questo approccio nella pratica.
Questa difficoltà è diventata più evidente nel dicembre 2020, quando Lucas Guimarães ha creato lo STATIK Canvas e lo ha pubblicato sul suo profilo Linkedin con l’obiettivo di aiutare la comunità a introdurre il metodo Kanban in modo più visivo e pratico. Ci sono stati molti commenti con domande, diversi messaggi ed è allora che a noi (Lucas e Caco) è venuta l’idea di scrivere un post per spiegare il metodo passo dopo passo in modo dettagliato e con consigli pratici, in modo che possiate usarlo come guida pratica e definitiva a STATIK.
Lucas e io abbiamo deciso di pubblicare STATIK Canvas Playbook – La guida per avviare il miglioramento continuo con Kanban. Il playbook è un modo semplificato e diretto di applicare STATIK, utilizzando lo STATIK Canvas per comprendere e diagnosticare la situazione attuale della vostra azienda, area, prodotto o servizio che volete migliorare.
Questi sono consigli pratici per aiutarvi a ottenere il massimo da STATIK Canvas.
Continuate a leggere e scoprite come applicarlo: tutto è spiegato passo dopo passo.
Che cos’è STATIK?
STATIK è l’acronimo di “System Thinking Approach To Introduce Kanban”.
STATIK è un approccio esplorativo per iniziare a introdurre Kanban nella vostra organizzazione.
È un metodo che fornisce le basi per esaminare il prodotto/servizio in modo sistemico e individuare i primi passi da compiere con il metodo Kanban per iniziare a dare una risposta ai fattori di insoddisfazione esistenti.
Sebbene il metodo preveda 8 fasi raccomandate, STATIK non è un modello prescrittivo e la sua serie di fasi non è sequenziale. Il metodo può essere applicato in vari modi e in organizzazioni di qualsiasi tipo e dimensione.
Queste sono le 8 fasi suggerite per l’analisi di ogni prodotto/servizio:
Fase 1: capire cosa rende ogni servizio adatto allo scopo del cliente
Fase 2: capire la fonte di insoddisfazione del processo attuale
Fase 3: analizzare la domanda
Fase 4: analizzare la capacità
Fase 5: modellare il flusso di lavoro
Passo 6: individuare le classi di servizio
Fase 7: progettare il sistema Kanban
Fase 8: socializzare (condividere) il sistema e negoziarne l’implementazione
Nell’ottica di semplificare l’approccio STATIK, il Canvas si propone di fornire maggiore chiarezza su cosa trattare in ogni fase e di rendere il percorso più semplice, soprattutto per coloro che iniziano a lavorare con Kanban per la prima volta. Questo è un articolo pratico da utilizzare come fonte di riferimento e, in quest’ottica, divideremo l’articolo in 2 argomenti principali:
4 errori comuni e come evitarli – 4 consigli pratici
STATIK Canvas – Consigli dettagliati su come applicare l’approccio nella pratica
4 errori comuni e come evitarli
Poiché lo scopo principale di questo articolo è quello di darvi consigli pratici sui primi passi da compiere con il metodo e di mostrarvi alcune scorciatoie per evitare di bloccarvi o di commettere errori comuni fin dall’inizio, iniziamo con 4 consigli pratici che vi aiuteranno a partire con il piede giusto.
Pensare che STATIK sia necessariamente da fare in un workshop.
Considerare STATIK come una checklist.
Cercare di essere quello che ne sa più degli altri.
Perdersi nei dettagli invece di cercare di identificare gli schemi di funzionamento generali.
1 – Pensare che STATIK sia necessariamente da fare in un workshop
Il primo consiglio pratico su STATIK è forse la domanda che ci sentiamo rivolgere più spesso: “Devo fare un workshop per utilizzare STATIK?”. La nostra risposta a questa domanda è decisamente NO.
In realtà, non esiste una prescrizione per l’esecuzione di STATIK. Il metodo fornisce in generale un approccio per comprendere alcuni aspetti del vostro prodotto/servizio, simile a una diagnosi, ma il modo in cui lo fate dipende da voi. Cercate di fare ciò che è più sensato in quel momento.
A livello più pratico, forse in alcuni scenari, per motivi di programmazione o di disponibilità, è improbabile che si riesca a mobilitare le persone per partecipare a un workshop, oppure semplicemente non si vuole creare resistenza a ciò che si sta facendo in quel momento e si preferisce comprendere lo scenario agendo in modo più discreto.
In questo caso, non c’è bisogno di forzare un workshop o una lunga riunione per far funzionare STATIK. Un approccio è quello di parlare semplicemente con le persone in modo informale, cercare di capire alcuni aspetti del loro prodotto/servizio e prendere nota degli aspetti più importanti.
Forse invece vi trovate in uno scenario in cui le persone non sono allineate tra loro rispetto alle fonti di insoddisfazione, allo scopo del prodotto/servizio, al flusso della domanda e ad altri aspetti trattati in STATIK, oppure volete coinvolgere le persone nel processo di cambiamento e utilizzare questo momento come punto di partenza. In questi casi, potrebbe essere una strategia migliore programmare una riunione o un workshop con tutte le persone coinvolte per promuovere l’allineamento e una comprensione comune dello scenario.
In sostanza, se fare STATIK sotto forma di workshop o in modo più discreto coinvolgendo le persone individualmente, dipende da voi. Non c’è nessuna prescrizione che dica che dovete farlo in un modo o nell’altro.
Suggerimento pratico:
Concentratevi sul risultato che volete ottenere con il processo. Assicuratevi che, indipendentemente dal formato, il risultato finale di STATIK sia una visione sistemica del vostro prodotto/servizio e un punto di partenza per un cambiamento evolutivo.
2 – Considerare STATIK come una checklist
Un errore comune tra coloro che lo utilizzano per la prima volta è quello di legger alcuni dei contenuti di STATIK, annotare gli 8 passi e volerli seguire alla lettera. Spesso si vuole fare tutti i passi in una volta sola – e ci si sente addirittura frustrati se non si riesce a fare tutto subito – per cui si fanno le cose in modo forzato, semplicemente per soddisfare tutti i passi dell”elenco’.
Come abbiamo detto all’inizio di questo articolo, STATIK è un approccio che aiuta a comprendere meglio lo scenario attuale.
Sebbene contenga 8 fasi esplicite, STATIK non è una ricetta per l’implementazione di Kanban e non richiede di utilizzare tutte le fasi nella vostra applicazione, né di eseguirle in una sequenza specifica.
La vera necessità di comprendere lo scenario prima di iniziare qualsiasi cambiamento è quella di poter iniziare il cambiamento in modo più assertivo e generare la minor resistenza possibile. Quindi iniziate in modo semplice.
Spesso il fatto che si cerchi di forzare la comprensione di molte cose che non sono ancora chiare nemmeno alle persone coinvolte può generare una resistenza iniziale.
In alcuni casi, la sola comprensione di 4 o 5 aspetti del vostro prodotto/servizio è sufficiente a darvi una visione d’insieme della vostra situazione e una base per iniziare a evolvere, senza che dobbiate seguire con precisione tutte le 8 fasi.
Suggerimento pratico:
Prendete le cose con calma e uscite dalla modalità automatica. Nulla in Kanban è una passeggiata; prima di qualsiasi applicazione pratica è necessario considerare il suo contesto.
3 – Cercare di essere quello che ne sa più degli altri
Un errore comune di chi inizia a lavorare con STATIK è quello di non volersi limitare a comprendere il processo, le insoddisfazioni e altri aspetti del prodotto/servizio, ma di cercare di correggere ciascuno di questi aspetti.
Come abbiamo detto più volte nel corso di questo articolo, STATIK è un approccio per generare COMPRENSIONE.
Se iniziate a correggere il processo e a cercare di implementare i cambiamenti fin dall’inizio, inizierete ad affrontare la resistenza delle persone fin dall’inizio.
“Ah, ma perché dovrei mai generare resistenza nelle persone se sto cercando di aiutare?”.
Mettiamoci quindi nei panni di queste persone. Immaginate di avere un vostro processo e un modo di fare le cose al lavoro, e all’improvviso arriva un estraneo e vi dice che vuole capire il vostro processo per aiutarvi a migliorare, ma prima di capire come funzionano le cose, inizia a fare varie correzioni, a mettere in discussione e a dare giudizi su tutto quello che sta succedendo. Come vi sentireste?
Prima che, proprio nella fase di comprensione, cerchiate di correggere il processo, dicendo che le persone stanno sbagliando tutto e che voi avete le risposte su come dovrebbero essere fatte le cose, ricordate che, se lo fate, da quel momento in poi tutti vi vedranno come l’ennesimo ‘fenomeno’ che, invece di aiutare le persone a evolvere rispetto ai problemi che hanno oggi, si preoccupa unicamente di realizzare il processo che ha in mente.
Le cose sono come sono oggi per un motivo, cercate di capire prima di giudicare.
Suggerimento pratico:
Non progettate il processo. Limitatevi a capire lo scenario. Lasciate le modifiche per un secondo momento ed evitate di creare attriti fin dall’inizio.
4 – Perdersi nei dettagli invece di cercare di identificare gli schemi di funzionamento generali.
L’ultimo consiglio pratico di questo articolo, ma non meno importante. Alla fine dell’intero processo STATIK, una volta ottenute alcune informazioni sull’erogazione e sulla struttura del servizio, è necessario comprendere le dinamiche di tutto ciò che è stato raccolto.
Poiché in questa fase cominciano ad essere evidenti alcune carenze nel processo, cercate di mettere in relazione le cose.
Verificate quanto un fattore interferisca con l’altro, cercate di mettere in relazione l’insoddisfazione con le differenze tra capacità e domanda, o con il flusso di lavoro esistente, con il profilo delle richieste, ecc.
L’osservazione d’insieme del servizio e della relazione tra i diversi aspetti può portare a conclusioni preziose per quanto riguarda i primi passi da compiere per un eventuale cambiamento.
Suggerimento pratico:
Concentratevi sui modelli e sulle relazioni tra i diversi aspetti del vostro servizio, non limitatevi a osservare i dettagli in modo isolato. Questo vi consentirà di essere più confidenti quando introdurrete nuove pratiche o modifiche ai processi.
STATIK Canvas
Si tratta di uno strumento che facilita il processo STATIK, aiutandovi a introdurre il metodo Kanban in modo più visivo e pratico.
Il Canvas permette la conservazione di tutte le informazioni in un unico posto, facilitando il processo di visualizzazione delle informazioni in modo sistematico, dove è possibile effettuare correlazioni tra i risultati di ciascun argomento trattato nel processo STATIK.
Per semplificare gli 8 passi originali di STATIK, li abbiamo adattati ai seguenti punti:
Prodotto/servizio o team
Scopo del prodotto/servizio
Fonti di insoddisfazione
Analisi della domanda
Analisi della capacità
Classi di servizio
Flusso di lavoro
Cadenze
Progettare il sistema Kanban e metterlo in pratica
Qual è il prodotto/servizio o il team analizzato in questo processo?
Il primo passo è identificare il prodotto/servizio che verrà analizzato. Vogliamo sottolineare che STATIK si applica anche ai prodotti, perché nella letteratura Kanban si trova solo il termine “servizi”, quindi molti hanno dei dubbi. In parole povere, un prodotto/servizio è qualcosa che la vostra azienda consegna o vende al cliente.
Se avete più di un prodotto/servizio, eseguite questo processo per ciascuno di essi. L’ideale è capire e analizzare il prodotto/servizio, dal momento in cui si riceve la richiesta e si comprende il problema, fino a quando lo si consegna al cliente.
Sebbene sia ideale concentrarsi sul prodotto/servizio nel suo complesso, è anche comune iniziare a comprendere come lavora un singolo team. Se vi trovate in questo scenario, non preoccupatevi: nelle fasi successive vi daremo dei suggerimenti per non perdere la visione sistemica del servizio fino alla consegna al cliente. In questo modo, STATIK vi aiuterà a capire dove si posiziona il vostro team nel flusso complessivo e garantirà l’allineamento globale con il prodotto/servizio per guardare all’insoddisfazione da una prospettiva più ampia.
Scopo del prodotto/servizio
Qual è lo scopo del prodotto/servizio? Che cosa lo rende adatto alle finalità dei clienti? Qual è la definizione di successo del prodotto/servizio?
È molto comune che le persone abbiano difficoltà a identificare lo scopo del prodotto/servizio, spesso perché non conoscono il concetto o perché si riferisce a qualcosa di intangibile.
Il nostro consiglio è di cambiare un po’ il vocabolario e di usare alcune domande:
Chi è il nostro cliente? È utile concentrarsi sul cliente finale.
Chi è coinvolto nella fornitura di questo prodotto/servizio al cliente finale? Questo aiuta a fare un po’ di chiarezza su chi è coinvolto.
Perché esistono queste persone? Cosa accadrebbe al nostro cliente se il nostro prodotto/servizio non esistesse? Questo aiuta a rendere tangibile l’impatto. Se la risposta è ancora un po’ generica, si può reiterare la domanda “Perché?” fino a ottenere qualcosa di più tangibile.
Se ci sono ancora delle lacune, vale la pena di andare avanti e durante le fasi successive si può poi tornare indietro e integrare.
Questa fase è molto importante per comprendere l’impatto del vostro prodotto/servizio e collegarlo alle altre fasi.
Fonti di insoddisfazione
Il grande segreto è garantire un’ampia comprensione dell’intero flusso da diversi punti di vista, ciò che chiamiamo visione sistemica. Cercate di coinvolgere tutti coloro che prendono parte diretta o indiretta nella fornitura del prodotto/servizio, in modo da comprendere entrambe le parti, interna ed esterna, ed evitare il pregiudizio di concentrarsi su una sola parte.
Un allineamento parziale in questa fase può portare a un cambiamento inadeguato, con pratiche che potrebbero non risolvere le reali insoddisfazioni alla base di quel prodotto/servizio, poiché non sono state mappate diverse insoddisfazioni e non sono state ascoltate diverse persone importanti all’interno del flusso di fornitura.
Insoddisfazione interna
Dal punto di vista di coloro che sono coinvolti nella realizzazione e nell’erogazione del prodotto/servizio.
Team di lavoro
Sviluppatori
Persone che si occupano di prodotti e design
Dirigenti e/o stakeholder interni
Altri team coinvolti nel processo
Appaltatori coinvolti nella realizzazione
Fornitori coinvolti nella realizzazione
Insoddisfazione esterna
Dal punto di vista di coloro che ricevono il prodotto e sono influenzati dal risultato del prodotto/servizio.
Cliente che paga il prodotto/servizio
Utenti finali del prodotto/servizio
Persone che si occupano di assistenza e supporto al cliente (aiutano a portare la visione del cliente)
Soggetti interessati esterni
Il consiglio principale è quello di evitare di addentrarsi troppo nell’analisi fin dall’inizio e di trasformarla in un fiume di lamentele. Se si individuano tra 3 e 5 insoddisfazioni interne principali e tra 3 e 5 insoddisfazioni esterne principali, questo è sufficiente per andare avanti. Se ritenete che le fonti di insoddisfazione mappate contengano troppe informazioni, prendetevi il tempo di ascoltare e poi cercate di stabilire un ordine di priorità tra quelle più rilevanti.
Un altro punto importante in questa fase è assicurarsi che si stiano davvero esaminando le insoddisfazioni esterne. È molto comune avere diverse insoddisfazioni interne e solo poche esterne, soprattutto in scenari di bassa maturità. In questo caso, se una parte è molto più preponderante dell’altra, cercate di assicurarvi di coinvolgere altre persone che possano portare una visione più ampia. Se non avete accesso diretto al cliente, potete rivolgervi alle persone che ne sono in contatto per avere una visione approssimativa.
Alcune domande che possono aiutarvi a iniziare a mappare l’insoddisfazione:
Cosa vi preoccupa oggi quando guardiamo questo prodotto/servizio?
Cosa ti manca?
Che cosa vi viene richiesto che non potete soddisfare?
Ci sono dipendenze che ne rendono difficile l’esecuzione?
Se vi rendete conto che c’è ancora qualcosa di non emerso, una possibilità è quella di andare avanti e tenere d’occhio le insoddisfazioni da cogliere durante le fasi successive. È molto comune che le insoddisfazioni emergano dopo, soprattutto quando si parla di richieste e di flusso. Sentitevi liberi di tornare e di inserire altre fonti di insoddisfazione man mano che le individuate nelle fasi successive.
Dopo aver analizzato il flusso di prodotti e servizi in diverse realtà, abbiamo individuato alcune insoddisfazioni tipiche che si manifestano in modo ricorrente e che vogliamo condividere con voi per aiutarvi a individuarle, soprattutto in scenari non ancora ben esplorati.
Fonti comuni di insoddisfazione:
Disallineamento delle informazioni per cui un’area “dà la colpa” a un’altra, in questo caso durante la comprensione del flusso diventerà più chiara la dinamica e si potrà approfondire.
Consegna ritardata
Mancanza di collaborazione tra i team e priorità poco chiare
Problema di qualità o troppa rilavorazione
La consegna è sempre in ritardo o non avviene affatto
Siamo lenti e non abbiamo la velocità che speravamo di avere
Disallineamento tra l’azienda e il cliente in merito alle aspettative sui tempi di consegna
Spesso non si rispettano le scadenze o gli accordi sul livello di servizio
Ma ricordate, questo non è un “menu” di insoddisfazioni o una guida, è solo un riferimento per aiutare chi si approccia per la prima volta a identificare ed esplorare, perché spesso vengono fuori parole singole, come “Disallineamento” o “Velocità”, e si può esplorare meglio usando alcune di quelle che io chiamo domande jolly:
Che aspetto ha questo problema, come e dove si verifica?
Perché dobbiamo risolvere questo problema?
Come lo si risolve oggi?
Analisi della domanda
Quali richieste ci sono nel processo? Chi fa le richieste? Con quale frequenza? Qual è il volume?
Non lasciatevi trascinare dalla voglia di conoscere esattamente tutti i dettagli delle richieste; il più delle volte un’informazione approssimativa con qualche variazione è molto meglio di nessuna informazione.
In assenza di informazioni molto dettagliate, parlate con le persone che lavorano su quel flusso, con i manager e con coloro che generano la domanda per quel prodotto/servizio. Concentratevi inizialmente sulla ricerca di tutto ciò che è già in corso, di tutto ciò che è già stato pianificato e che le persone si sono già impegnate a fare e di ciò che è stato consegnato la settimana precedente, in modo da poter uscire dalla soggettività e concentrarvi su ciò che è già un dato di fatto.
Il primo passo è identificare i “Tipi di domanda”, che non è altro che identificare i tipi di lavoro che passano attraverso il flusso. Come negli esempi che seguono:
Progetti
Richieste legate alla roadmap del prodotto
Richieste di adeguamento normativo
Errori/bug
Incidenti
Debito tecnico
Esperimenti
Richieste dei clienti
Se sono difficili da identificare, iniziate a guardare l’ultima settimana, poi gli ultimi 15 giorni e se riuscite ad arrivare agli ultimi 30 giorni, è un ottimo punto di partenza.
Di seguito sono riportate alcune domande che possono aiutare a sbloccare la conversazione e a esplorare i tipi di richieste che vengono fatte:
Quali sono le “cose” su cui avete lavorato la scorsa settimana?
C’è un periodo del mese o dell’anno in cui dovete agire su qualcosa che arriva solo in quel periodo?
Ci sono task o richieste che arrivano con urgenza o senza alcuna pianificazione?
Avete delle richieste o delle cose urgenti e dovete interrompere tutto per occuparvene?
Le richieste provengono tutte da un unico punto o da diverse fonti/richiedenti?
Una volta identificati i principali tipi di domanda, si può cercare di raggrupparli – se sono troppi, si possono raggruppare e riunire in 6 tipi principali di domanda.
Esplorate quindi questi aspetti per ogni tipo di domanda:
Da dove viene?
Identificare la fonte della domanda, se interna o esterna, da quale area.
Chi la prende in carico?
Identificare chi la riceve e cosa fa con la domanda per valutarne le aspettative.
Frequenza di ricezione
Quante volte riceviamo questo tipo di domanda alla settimana o al mese? Identificare il volume, per settimana o per mese, ricordando che può essere un dato approssimativo, se è difficile guardare per mese allora guardate alle ultime settimane. In genere, le richieste con il volume più elevato meritano un’attenzione particolare per avere a disposizione maggiori informazioni.
Natura della domanda
Pianificata
Non pianificata
Stagionale – Arriva in un periodo specifico del mese o dell’anno. Spesso il flusso è già sovraccarico e quando arrivano queste richieste non c’è preparazione per affrontarle.
Casuale
SLA / Aspettative di consegna
Qual è il tempo di consegna previsto? Identificare le aspettative di consegna e vedere se c’è qualcosa che potrebbe integrare le fonti di insoddisfazione.
Un formato utile per registrare queste informazioni è quello di creare una tabella/foglio di calcolo per organizzare i dati e raggruppare i tipi di domanda.
Analisi della capacità
Quanto tempo impiega una richiesta per essere consegnata? Ci sono colli di bottiglia? Dove si blocca il flusso? Quanto viene consegnato per periodo (mese, settimana o sprint)?
È molto comune che le persone subiscano la mancanza di informazioni relative all’analisi della capacità, spesso rinunciando perché ritengono di non avere abbastanza informazioni, soprattutto quando si entra a far parte di un’organizzazione che ha ancora pochi dati quantitativi sulle consegne.
Non è necessario un sistema di metriche altamente raffinato per ottenere una prima comprensione della capacità. Se lo fate, è fantastico, ma se non lo fate, non sentitevi frustrati. Non preoccupatevi, cercheremo di demistificare questa fase, in modo che possiate raccogliere informazioni preziose, anche quando sembra che non ce ne siano. Vi assicuriamo che le informazioni ci sono sempre e che facendo le domande giuste riuscirete a trovarle.
L’obiettivo principale è capire in che modo l’organizzazione è in grado di soddisfare la domanda attuale e identificare se c’è un sovraccarico e da dove proviene. A tal fine, è meglio esaminare lo storico delle ultime settimane e riportare tutto ciò che è stato consegnato, di solito considerando un minimo di 2 settimane e idealmente 1 o 2 mesi di consegne.
Elementi da raccogliere per ogni tipo di domanda che viene consegnata:
Identificare i tipi di domanda.
Identificare il tempo di consegna di ciascun tipo di domanda.
Individuare se si è verificato un blocco e quale ne è la causa.
Identificare se c’è stato un sovraccarico di lavoro.
Identificare come sono state gestite le esigenze stagionali e se il personale è stato sovraccaricato o ha fatto gli straordinari.
Non preoccupatevi troppo dell’accuratezza delle informazioni, a volte non ci sono dati esatti. Le informazioni approssimative sono utili.
A questo punto è possibile capire il volume delle consegne evase dal team e fare un controllo incrociato con il volume delle richieste in entrata. Il suggerimento è di vedere se le richieste che arrivano più frequentemente sono in equilibrio con quelle che escono più frequentemente, perché potrebbero esserci opportunità di esplorare e definire meglio le priorità.
Un esempio: se il servizio consegna tra i 5 e i 10 elementi di un tipo di domanda a settimana, ma ogni settimana ne arrivano tra i 15 e i 20, si può già capire che c’è un problema. È chiaro che c’è un sovraccarico e si può correlare questo dato con l’analisi della domanda per capire la fonte del sovraccarico.
Seguendo il modello di Pareto, l’obiettivo è quello di evidenziare il 20% delle richieste che rappresentano l’80% dei problemi.
Classi di servizio
Quali richieste hanno un rischio diverso da altre? Ci sono richieste urgenti? Ci sono richieste con una scadenza?
L’obiettivo principale è quello di comprendere le classi di servizio già esistenti, per cui il suggerimento di scoprire cosa arriva con urgenza rispetto al resto è, nella maggior parte dei casi, sufficiente per iniziare e permette alle persone di semplificare la comprensione.
Tuttavia, in questa fase in cui si parla di classi di servizio, spesso vediamo la persona che facilita lo STATIK iniziare a introdurre i concetti di classe di servizio e cercare di implementare questi concetti per ogni categoria di domanda, spesso riempiendo di contenuti teorici le altre persone coinvolte in questo processo – facendo cadere il gruppo di lavoro esattamente nel terzo errore comune, ovvero cercare di essere quello che ne sa più degli altri – e di essere visto come il “professore” che insegnerà a tutti cos’è la classe di servizio e come segmentare le richieste utilizzando ciascuno dei suoi concetti.
La conseguenza di questo tipo di atteggiamento è che probabilmente inizierete ad affrontare la resistenza delle persone già in STATIK, perché vi siete messi a progettare un processo.
Evitate la trappola di voler usare STATIK per insegnare le classi di servizio ed evitate di usare il momento per implementare le classi di servizio, concentratevi invece sulla comprensione delle cose come sono oggi e non sull’introduzione di cose nuove.
Per evitare di cadere in questa trappola, basta scoprire il profilo di rischio delle richieste esistenti. Verificate se ci sono richieste con scadenze, se ci sono richieste urgenti, se ci sono richieste con priorità diverse. Classificate queste richieste utilizzando una nomenclatura che tutti conoscono ed evitate di introdurre termini che potrebbero essere troppo complicati per le persone in quel momento.
Come riferimento, le classi di servizio determinano il modo in cui la domanda deve essere gestita dal flusso di lavoro.
Gli elementi urgenti sono quelli che devono essere consegnati il prima possibile o che avrebbero dovuto essere già consegnati. Di solito sono legati a problemi, incidenti o guasti gravi, perché prima vengono consegnati, maggiore è la percezione del valore.
Gli elementi con una data hanno una scadenza rispetto alla quale il valore/risultato possa essere realizzato. A volte, anticipare non aumenta la percezione del valore.
Gli elementi normali sono quelli di cui il team si occupa quotidianamente, messi in sequenza ed eseguiti.
Esistono anche elementi dei quali la percezione del valore nel tempo è intangibile, che non hanno un’aspettativa legata alla consegna o un risultato chiaro. Inizialmente, consiglio di trattarli insieme alle voci normali per semplificare il processo STATIK.
Un consiglio è anche quello di esplorare alcuni esempi pratici con il gruppo, mettendoli in relazione con le richieste discusse nelle fasi precedenti per comprendere i volumi.
Un esempio pratico che è capitato a un team di Marketing è stato quando abbiamo utilizzato STATIK e abbiamo identificato che il problema principale era rappresentato dalle richieste che arrivavano con urgenza dalle Risorse Umane, che le portavano sempre con poco preavviso. STATIK ha contribuito a fare emergere questa consapevolezza e il primo passo è stato quello di organizzare il flusso per rendere visibile questo problema e quindi organizzare meglio la presa in carico di questo tipo di richieste.
Flusso di lavoro
Come funziona il flusso delle richieste? Progettare il flusso di lavoro. Iniziate in modo semplice. Concentratevi sulla mappatura del flusso attuale piuttosto che sulla sua correzione.
L’obiettivo principale è comprendere le fasi già in atto per il completamento del lavoro.
Non cercate di aggiustare il flusso – ancora una volta, non cadete nella trappola di essere quello che ne sa più degli altri – l’obiettivo è modellare il flusso così com’è oggi.
C’è un istinto naturale a guardare alcuni problemi e a volerli correggere nella mappatura, o a giudicare che sono sbagliati. Questo finisce per generare una sensazione negativa nelle persone, facendo sembrare che tutto sia sbagliato, e spesso si finisce per perdere i dettagli dello scenario perché le persone possono avere paura del giudizio degli altri.
Potrebbe anche esserci una certa pressione a riordinare il flusso utilizzando qualcosa di già noto e voi, in qualità di facilitatori STATIK, dovreste sottolineare che il primo passo verso il cambiamento è quello di generare una comprensione comune dello scenario da diversi punti di vista.
Quando durante la mappatura ci si imbatte in un miglioramento del flusso, assicurarsi che l’insoddisfazione per quel punto sia mappata; questo aiuterà a garantire che non venga dimenticata, poiché potrebbero esserci più modi per risolvere l’insoddisfazione.
La discussione su un punto di miglioramento del flusso può anche essere sviluppata nell’arco di qualche giorno osservando il flusso in azione. Di solito entro una settimana i principali problemi e insoddisfazioni diventano molto evidenti.
Suggerimenti importanti:
Non giudicare il flusso e la realtà
In questo momento, è sufficiente tracciare una mappa di come si presenta il flusso nella realtà
Se avete molte particolarità, concentratevi su quelle più importanti.
I diversi tipi di domanda possono avere flussi diversi
Iniziate con una semplice rappresentazione della realtà, che vi aiuterà a mettere in luce i principali problemi e le attuali insoddisfazioni.
Prima di tutto disegnate uno schema condiviso, è importante disegnare e rendere visibile la mappatura in modo che tutti abbiano la stessa comprensione della realtà.
Non è un problema iniziare a mappare il flusso a livello di team, ma tenete presente che STATIK si basa sul pensiero sistemico, quindi se utilizzate questo approccio cercate di capire come si colloca questo team rispetto al sistema d’insieme e come influisce sul risultato del cliente. Questo vi fornirà un allineamento globale rispetto al prodotto/servizio e vi farà guardare all’insoddisfazione da una prospettiva più ampia.
Questo approccio aiuta a identificare i principali colli di bottiglia, a far emergere i conflitti di comunicazione tra le diverse aree o i team che lavorano al flusso e a individuare il punto di partenza migliore.
Cadenze
Quali cadenze e cicli di feedback esistono oggi?
Affinché il vostro processo funzioni in modo minimamente efficiente, è necessario che ci siano determinate cadenze, riunioni o momenti di riflessione. Che si tratti del flusso di lavoro, delle consegne o di decidere cosa consegnare o come consegnare qualcosa.
Queste riunioni possono non essere formali o svolgersi a intervalli fissi, ma sono cadenze in cui le persone valutano problemi, processi, richieste e prendono decisioni. Vale la pena di prendere nota di queste cadenze e di capire lo scopo di ciascuna di esse.
È comune che le organizzazioni che iniziano a utilizzare il metodo Kanban abbiano una routine di pianificazione e follow-up.
Il consiglio è di sviluppare in qualche modo il contenuto di queste 3 routine principali:
Semplice riunione di pianificazione e allineamento settimanale (Replenishment Meeting)
Riunione giornaliera per la verifica del lavoro sulla Kanban board (Kanban Meeting)
Retrospettiva alla fine della settimana per valutare con il team ciò che è stato consegnato, i risultati e i punti da migliorare nel flusso (Service Delivery Review)
Non cambiate e non create resistenze: iniziate con le routine esistenti, con gli stessi nomi e poi, se necessario, evolvete con il passare dei giorni. Se una routine non è presente nella vostra organizzazione, va bene restare così come si è. Con il passare dei giorni, la mancanza di questa cadenza può diventare evidente e potete introdurla, se necessario.
Progettare il sistema Kanban e metterlo in pratica
Kanban ha i 3 principi di gestione del cambiamento che ci guidano e orientano, e quando iniziamo a introdurre le pratiche sono ancora più importanti:
1. Iniziate da ciò che fate oggi.
Rispettare l’attuale processo, i ruoli, i titoli e le responsabilità.
2. Accettate di perseguire il miglioramento attraverso il cambiamento evolutivo.
3. Incoraggiate la leadership a tutti i livelli.
Nel corso di questo articolo abbiamo sottolineato l’importanza di prendere atto della realtà piuttosto che esprimere giudizi, quindi quando si tratta di mettere in pratica questi principi, non dimenticateli.
Generalmente ci troviamo di fronte a due scenari:
Scenario 1 – Un’organizzazione che non ha un modo strutturato di gestire il lavoro, dove tutto viene fatto utilizzando fogli di calcolo, e-mail o persino liste di compiti individuali.
Scenario 2 – Organizzazione che ha un modo per gestire il lavoro, di solito con software come Trello, Jira, Microsoft TFS, VersionOne o altri strumenti di gestione dei progetti.
Indipendentemente dallo scenario, la raccomandazione è di concentrarsi sul flusso di lavoro discusso nello STATIK Canvas. Se trovate difficile rappresentare il flusso nella sua interezza, va bene iniziare con un approccio parziale, purché vi assicuriate che le insoddisfazioni siano evidenti e senza perdere di vista l’intero flusso (visione sistemica), poiché la maggior parte dei problemi nasce nelle iterazioni tra le parti.
Tenete presente che questo è il primo passo verso il cambiamento, fate attenzione che la cosa più importante a questo punto è portare il lavoro verso una sua gestione visuale e osservare. Ricordate il principio “Iniziate da ciò che fate oggi”.
In situazioni di lavoro in presenza, il consiglio è di iniziare con una lavagna fisica che genera meno resistenza, ma sappiamo che oggi la realtà è il lavoro a distanza, quindi uno degli strumenti digitali più semplici con cui iniziare è Trello. Per le organizzazioni che già dispongono di uno strumento, il consiglio è di evitare attriti e di utilizzare lo strumento esistente.
Una volta progettato il flusso, è sufficiente portare tutte le richieste in corso all’interno del flusso stesso, utilizzando contrassegni o etichette per rappresentare i tipi di richieste e le classi di servizio. La corretta classificazione delle informazioni vi aiuterà a raccogliere le informazioni in modo corretto.
Rafforzate le cadenze e le routine che sono state individuate, ricordatevi l’obiettivo e concordate le date e gli orari per ogni momento.
Con il passare dei giorni, l’insoddisfazione diventerà evidente, così come il volume delle richieste in corso e i colli di bottiglia. Le cadenze aiuteranno le persone a riflettere su queste insoddisfazioni e potrete apportare miglioramenti che affrontino le insoddisfazioni, facendo un primo passo verso il miglioramento continuo.
È abbastanza comune fare molti progressi entro due mesi e allora si può iniziare a esaminare le altre pratiche del metodo Kanban e continuare a far evolvere il proprio sistema di lavoro. Ma non abbiate fretta, ogni cosa accade a suo tempo.
Non dimenticate di evidenziare i miglioramenti e i risultati ottenuti: in questo modo contribuirete a guardare oltre i problemi, a generare l’impegno a continuare a evolvere e a farvi lavorare in modo più pragmatico e basato sull’evidenza.
Ricordate:
Non modellare un sistema più complicato del necessario.
A volte il solo fatto di avere una visione di insieme è già un risultato sufficiente per il momento.
All’inizio, i principali vantaggi derivano dalla gestione visiva, rendendo esplicita l’insoddisfazione.
“Un sistema non è mai la somma delle sue parti. È il prodotto dell’interazione tra le parti”
Russell Ackoff
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.
L’Arsenale di Venezia, un tempo il più grande complesso industriale d’Europa, e il metodo Kanban potrebbero sembrare non avere alcuna correlazione. Tuttavia, un’analisi più attenta e approfondita rivela sorprendenti somiglianze e interessanti spunti di riflessione. L’esempio che sto per raccontarvi ci condurrà alla scoperta di una straordinaria storia che affonda le sue radici nel passato.
Un modello pionieristico di produzione industriale
L’Arsenale di Venezia, fondato nel XII secolo, rappresenta uno dei primi e più avanzati esempi di complesso industriale integrato nella storia. Si trattava di un cantiere navale gestito dalla Repubblica di Venezia, specializzato nella costruzione e nella manutenzione delle navi da guerra e mercantili della Serenissima. Per secoli, è stato il cuore pulsante della potenza marittima veneziana, grazie a una straordinaria organizzazione del lavoro che anticipava molti dei principi della produzione industriale moderna.
Con una forza lavoro che raggiungeva le 16.000 unità, l’Arsenale era in grado di costruire e allestire una galea al giorno, grazie a un’organizzazione del lavoro altamente specializzata e a una divisione delle fasi produttive. Questa struttura permetteva una produzione efficiente e standardizzata delle navi.
L’entrata dell’Arsenale dipinta da Canaletto, 1732
L’organizzazione della produzione nell’Arsenale di Venezia
L’Arsenale funzionava come una gigantesca macchina produttiva, organizzata secondo un modello che garantiva velocità, efficienza e qualità nella costruzione delle navi. La produzione era suddivisa in una serie di fasi altamente specializzate, ciascuna affidata a operai esperti detti “arsenalotti”. Questi artigiani erano suddivisi in corporazioni a seconda del loro ruolo nel processo produttivo.
La gestione del flusso di lavoro
La costruzione di una nave all’interno dell’Arsenale seguiva un percorso ben definito, che prevedeva le seguenti fasi principali:
Preparazione del legname: Il legno proveniva dalle foreste del Cadore e di altri territori sotto il controllo della Serenissima. Dopo essere stato selezionato e stagionato, veniva trasportato all’Arsenale per essere lavorato.
Assemblaggio dello scafo: Gli operai specializzati nelle strutture in legno lavoravano con una precisione quasi standardizzata. L’impiego di modelli e tecniche di produzione ripetitive permetteva di costruire scafi in tempi rapidi.
Placcatura e rinforzi: Dopo la realizzazione dello scheletro della nave, si procedeva alla placcatura esterna con tavole di legno, fissate con chiodi e resine impermeabilizzanti. Le navi veneziane erano rinomate per la loro robustezza e leggerezza.
Installazione delle sovrastrutture e dell’attrezzatura di bordo: In questa fase venivano installati gli alberi, le vele, i remi e le decorazioni, oltre alle cabine per l’equipaggio e i capitani.
Armamento e rifinitura: Le navi da guerra erano dotate di cannoni e altre attrezzature belliche prima di essere varate e messe in servizio.
Questa suddivisione del lavoro consentiva di realizzare una galea in tempi straordinariamente brevi per l’epoca, arrivando, nei momenti di massima efficienza, a costruire una nave al giorno.
Un sistema Kanban ante litteram
Uno degli aspetti più innovativi dell’Arsenale di Venezia era la sua capacità di funzionare in maniera simile a un moderno sistema di produzione Kanban. Il processo di costruzione delle navi era altamente standardizzato e suddiviso in reparti specializzati, con un flusso di materiali e manodopera ottimizzato per garantire la massima produttività.
Gli arsenalotti utilizzavano un sistema di prefabbricazione in cui le diverse sezioni della nave, come ordinate, paratie e fasciame, venivano prodotte separatamente e contrassegnate con numeri o segni distintivi. Queste parti venivano poi trasportate nei punti di assemblaggio finale, dove venivano montate in sequenza, riducendo significativamente i tempi di costruzione. La numerazione delle parti facilitava il lavoro degli operai specializzati, assicurando che ogni componente fosse posizionato correttamente senza margine di errore.
A differenza di altri cantieri navali dell’epoca, dove la costruzione avveniva in modo artigianale e disperso, nell’Arsenale veneziano la produzione era centralizzata e organizzata in una sequenza precisa. Questa innovazione permetteva di ottenere navi di qualità uniforme e di ridurre i tempi di realizzazione, garantendo a Venezia una flotta costantemente rinnovata e aggiornata.
La gestione delle risorse e il controllo della qualità
La Repubblica di Venezia esercitava un controllo rigoroso sulle risorse necessarie alla produzione navale. Le materie prime, come il legno, il ferro e la pece, erano gestite direttamente dallo Stato, che ne garantiva la disponibilità e la qualità. Anche la manodopera era regolata da un sistema preciso: gli arsenalotti godevano di salari stabili e privilegi che li incentivavano a trasmettere le loro competenze alle nuove generazioni.
Inoltre, ogni fase della costruzione era soggetta a controlli rigorosi per garantire la massima qualità delle imbarcazioni. La Serenissima aveva compreso l’importanza della standardizzazione e della manutenzione preventiva per mantenere la propria supremazia marittima.
Valori del metodo Kanban riconoscibili nel sistema dell’Arsenale di Venezia
Il metodo Kanban si basa su valori e pratiche che possiamo sorprendentemente ritrovare nell’organizzazione dell’Arsenale di Venezia. Di seguito analizziamo le principali corrispondenze.
1. Trasparenza
Kanban enfatizza la trasparenza dei processi di lavoro attraverso strumenti visivi, come le Kanban board. Allo stesso modo, nell’Arsenale di Venezia, l’organizzazione della produzione era chiara e strutturata:
Le diverse fasi della costruzione navale erano visibilmente organizzate nei vari reparti dell’Arsenale.
Ogni lavoratore sapeva esattamente quale fosse la sua mansione e il contributo alla fase produttiva.
2. Collaborazione
Il metodo Kanban incoraggia la collaborazione tra team per migliorare il flusso di lavoro. L’Arsenale era un esempio di lavoro collettivo su larga scala:
Le diverse corporazioni di mestieri (falegnami, calafati, fabbri, velai) collaboravano strettamente per completare ogni nave nel minor tempo possibile.
Il processo produttivo era suddiviso in team specializzati che operavano in modo interdipendente, simile ai team Kanban moderni.
3. Equilibrio
Kanban aiuta a bilanciare la domanda e la capacità produttiva. L’Arsenale manteneva un equilibrio attraverso:
Produzione su richiesta, evitando scorte eccessive. Le navi venivano costruite in base alle esigenze della Repubblica di Venezia, evitando surplus inutili.
Una gestione delle risorse centralizzata, assicurando che ogni reparto ricevesse materiali in modo coordinato.
4. Focalizzazione sul cliente
Il metodo Kanban incoraggia a lavorare su ciò che porta valore al cliente finale. L’Arsenale aveva una forte attenzione al bisogno della Serenissima:
La produzione di navi era ottimizzata per garantire potenza navale e velocità di risposta alle esigenze militari e commerciali di Venezia.
La capacità di costruire una galea al giorno era una risposta diretta alle necessità strategiche di difesa e commercio.
5. Leadership a tutti i livelli
Kanban valorizza il ruolo di ogni membro del team nel miglioramento continuo. Anche nell’Arsenale:
Gli arsenalotti non erano semplici operai, ma specialisti altamente qualificati, il cui sapere era tramandato di generazione in generazione.
L’organizzazione del lavoro lasciava spazio all’iniziativa individuale, permettendo ai maestri d’arte di migliorare continuamente le tecniche costruttive.
Pratiche del metodo Kanban riconoscibili nel sistema dell’Arsenale di Venezia
1. Visualizzare il lavoro
Nel metodo Kanban, i flussi di lavoro vengono visualizzati su una board. Nell’Arsenale:
Il layout fisico dell’Arsenale permetteva una visualizzazione naturale, dove ogni fase di costruzione aveva una posizione ben definita.
Le navi in costruzione erano assemblate lungo un canale e le attività assegnate a ogni squadra erano chiaramente visibili.
2. Limitare il lavoro in corso (WIP – Work In Progress)
Il metodo Kanban limita il numero di attività in corso per evitare sovraccarico e sprechi. Nell’Arsenale:
La costruzione era organizzata per fasi specifiche e sequenziali, evitando congestioni di lavoro.
Il numero di navi in produzione era attentamente regolato per non sovraccaricare le risorse e ottimizzare i tempi.
3. Gestire il flusso di lavoro
Kanban aiuta a identificare colli di bottiglia e ottimizzare il flusso. Nell’Arsenale:
La suddivisione del lavoro in reparti specializzati assicurava un flusso regolare e prevedibile della produzione.
Ogni squadra di operai riceveva i materiali e i componenti nel momento giusto, garantendo un processo continuo, l’Arsenale era sostanzialmente un sistema ‘pull’.
4. Rendere le regole di processo esplicite
Kanban suggerisce di rendere le regole operative chiare per tutti. Nell’Arsenale:
Il lavoro era rigidamente regolato da norme statali e procedure definite.
I mestieri erano organizzati in corporazioni con ruoli e compiti ben definiti, simili alle policy documentate nei sistemi Kanban.
5. Implementare feedback loop
Nel metodo Kanban, i feedback sono la vera e propria catena di trazione del miglioramento continuo. Nell’Arsenale:
La produzione era monitorata costantemente, per correggere errori e ottimizzare i processi.
Venezia investiva nella formazione continua degli arsenalotti, trasmettendo le conoscenze per migliorare le tecniche produttive.
6. Migliorare collaborando ed evolvere sperimentando
Il metodo Kanban incoraggia cambiamenti incrementali per ottimizzare il sistema. Nell’Arsenale:
I metodi di costruzione delle navi si evolvevano continuamente, adattandosi alle nuove esigenze belliche e commerciali.
L’innovazione tecnologica era costante, con l’introduzione di miglioramenti nei materiali e nelle tecniche di assemblaggio.
Conclusione
L’Arsenale di Venezia rappresentava un modello industriale e di organizzazione del lavoro sorprendentemente vicino ai principi di Lean e del metodo Kanban. La suddivisione delle fasi produttive, la gestione del flusso, il controllo delle risorse e della qualità hanno reso questo straordinario cantiere navale uno dei più avanzati della storia.
Il modello produttivo veneziano non solo garantì alla Serenissima una flotta potente ed efficiente, che dominò i mari per quasi un millennio, ma gettò anche le basi per quelli che sono stati i successivi sviluppi nel campo della produzione industriale. Sebbene sviluppato in un contesto preindustriale, il metodo veneziano dimostra come l’efficienza nella gestione del lavoro sia un principio senza tempo.
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.
Un breve articolo che ho letto in questi giorni mi ha ricordato una grande verità: nessuno si ricorderà o renderà merito agli eroi silenziosi che giorno per giorno, con piccoli costanti cambiamenti, permettono alle organizzazioni di prosperare prevenendo i problemi ed evitando i rischi.
Così come tutti si ricordano i pompieri che hanno spento un incendio e salvato vite ma nessuno si ricorda di chi altrove, con un lavoro nascosto e costante di prevenzione, ne ha evitati magari a decine con un impatto reale molto maggiore.
Ne avevo già parlato a proposito del ruolo di project manager in un precedente post che potete rileggere qui, ma vale per qualunque ruolo aziendale. Non servono eroi, servono risk manager.
Riporto l’articolo originale di Dimitar Bakardzhiev (la traduzione è mia):
“Avete mai notato che gli ingranaggi organizzativi di solito girano senza alcun plauso per le menti che li guidano?
Ciò evidenzia la realtà del management: gli stessi individui o le iniziative che guidano la trasformazione sono spesso trascurati o sottovalutati.
Questi eroi non celebrati – manager che risolvono silenziosamente i conflitti, implementano sistemi che prevengono il caos o motivano i team a superare le aspettative – raramente fanno notizia.
Eppure, sono le ancore che tengono a galla e fanno prosperare le organizzazioni. Il loro contributo, anche se impercettibile, è la spina dorsale del progresso.
Forse è giunto il momento di fermarsi e chiedersi: stiamo davvero riconoscendo i catalizzatori nelle nostre organizzazioni o lasciamo che il successo metta in ombra i suoi architetti silenziosi?
Iniziamo a celebrare non solo i risultati, ma anche le menti umili che li rendono possibili.”
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.
Per far funzionare bene un sistema organizzativo e i suoi flussi di lavoro è fondamentale una gestione proattiva dei rischi, che infatti è un filo conduttore chiave del metodo Kanban. In tre degli ultimi cinque articoli ho già trattato il tema del rischio e di come viene affrontato per migliorare le previsioni e rendere i flussi di lavoro più stabili e affidabili. In questo articolo voglio risalire alla fonte e spiegare quali sono i razionali di base di tale approccio.
Le radici concettuali: il pensiero di Taleb, Shewhart e Deming
Nassim Nicholas Taleb, nel suo pensiero sul rischio, esplora il concetto di incertezza e imprevedibilità, evidenziando come molti eventi significativi (i cosiddetti ‘Cigni Neri’) siano estremamente improbabili, ma hanno un impatto enorme e sono spesso razionalizzati solo a posteriori. Taleb critica la dipendenza da modelli statistici tradizionali che sottovalutano le dinamiche dell’incertezza e del caos. Introduce inoltre il concetto di antifragilità, ovvero la capacità di un sistema di non solo resistere agli shock, ma di trarne beneficio e crescere. Taleb incoraggia un approccio prudente e resiliente al rischio, valorizzando la robustezza e il fattore umano rispetto alla fiducia cieca nella previsione e nel controllo.
Mediocristan ed Extremistan
Una delle idee chiave di Taleb, che ha influenzato ed è stata ripresa dal metodo Kanban, è la distinzione tra Mediocristan ed Extremistan per descrivere due tipi di domini statistici che influenzano la nostra comprensione del rischio e dell’incertezza.
Mediocristan:
Caratteristiche: Si riferisce a un mondo in cui le variabili seguono una distribuzione normale o gaussiana. Gli eventi estremi (outlier) sono rari e hanno un impatto minimo sull’insieme. La maggior parte delle variazioni è contenuta entro limiti prevedibili.
Esempi: Peso o altezza di un gruppo di persone. Aggiungere una persona di altezza straordinaria o peso anomalo non cambia significativamente la media complessiva.
Principio: Le dinamiche sono dominabili e i fenomeni sono relativamente stabili.
Extremistan:
Caratteristiche: Si riferisce a un mondo dominato da distribuzioni a coda grassa o lunga (fat-tail), dove eventi estremi sono frequenti e possono avere un impatto sproporzionato. I valori eccezionali contano molto di più rispetto alla media.
Esempi: Ricchezza, successo editoriale, popolarità di un video online. Un singolo miliardario o bestseller può influenzare enormemente la media.
Principio: Le dinamiche sono altamente imprevedibili e dominano le eccezioni.
Mediocristan è il dominio della stabilità, dove gli eventi rari non contano molto, mentre Extremistan è il regno dell’incertezza e degli eventi straordinari, che possono alterare radicalmente la realtà. Secondo Taleb, il mondo reale, soprattutto in ambiti come l’economia o l’innovazione, è spesso più vicino all’Extremistan, rendendo fondamentale considerare i rischi di eventi eccezionali (i ‘Cigni Neri’).
Rischi di variazione per causa comune e rischi di variazione per causa speciale
I rischi nei sistemi Kanban vengono classificati come rischi di variazione per causa comune (chance cause variation) e rischi di variazione per causa speciale (assignable cause variation). Questi concetti derivano dal lavoro pionieristico di Walter Shewhart negli anni ’20 del secolo scorso e sono stati ulteriormente sviluppati da William Edwards Deming, influenzando profondamente il Toyota Production System da cui il metodo Kanban deriva direttamente. La differenza tra questi rischi è un concetto fondamentale per la gestione del flusso di lavoro in un sistema Kanban.
Variazioni per causa comune:
Sono intrinseche al sistema e derivano dalla normale variabilità dei processi di lavoro.
Sono sempre presenti e contribuiscono alla fluttuazione “naturale” delle prestazioni.
Esempi: lievi differenze nei tempi di completamento delle attività, piccole variazioni nella qualità del lavoro, fluttuazioni nella domanda di lavoro.
Gestione: si affrontano migliorando il sistema nel suo complesso, ottimizzando i processi e riducendo la variabilità intrinseca.
Variazioni per causa speciale:
Sono esterne al sistema e derivano da eventi specifici e identificabili.
Sono imprevedibili e causano deviazioni significative dalle prestazioni normali.
Esempi: guasti imprevisti alle apparecchiature, richieste urgenti non pianificate, assenze improvvise del personale, ritardi da parte di fornitori esterni.
Gestione: si affrontano identificando la causa specifica, intervenendo per risolvere il problema immediato e implementando misure preventive per evitare che si ripeta in futuro.
I concetti di Extremistan e Mediocristan, introdotti da Taleb, sono strettamente correlati ai concetti di rischi di variazione per causa comune e rischi di variazione per causa speciale:
I rischi di variazione per causa comune sono tipici del Mediocristan. Sono variazioni intrinseche al sistema, con un impatto limitato e prevedibile. Possono essere gestiti migliorando il sistema nel suo complesso e riducendo la variabilità intrinseca.
I rischi di variazione per causa speciale sono tipici dell’Extremistan. Sono variazioni imprevedibili, spesso causate da eventi esterni al sistema, che possono avere un impatto significativo sulle prestazioni. Richiedono un’azione immediata per identificare e risolvere la causa specifica, oltre a misure preventive per evitare che si ripetano in futuro.
Il ruolo del Lead Time
L’analisi dei tempi di consegna (Lead Time) in un sistema Kanban può rivelare se ci troviamo di fronte a un Mediocristan o a un Extremistan:
Tempi di consegna con una distribuzione ‘a coda sottile’ (thin-tailed) indicano un Mediocristan: la maggior parte dei lead time si concentra attorno alla media, con pochi outlier. Possiamo utilizzare i valori di Lead Time per fare delle previsioni e pianificare.
Tempi di consegna con una distribuzione ‘a coda grassa o lunga’ (fat-tailed) indicano un Extremistan: la media è influenzata da outlier estremi, rendendola un indicatore poco affidabile. Dobbiamo analizzare gli outlier e anticipare i loro effetti con contromisure specifiche (in gergo si parla di “tagliare la coda”).
La pratica Kanban di limitare il WIP (Work in Progress) ha lo scopo di ottenere una distribuzione dei lead time a coda sottile, tipica del Mediocristan. Limitando il lavoro in corso, si riduce la variabilità del sistema, rendendolo più prevedibile e meno soggetto a eventi estremi.
Un percorso evolutivo per imparare a gestire i rischi
Il Kanban Maturity Model (KMM) sottolinea l’importanza di imparare a distinguere tra rischi di variazione per causa comune e rischi di variazione per causa speciale, per una gestione del rischio efficace. Nei livelli di maturità più bassi, le organizzazioni tendono a reagire a tutte le variazioni come se fossero speciali, con un approccio reattivo e spesso inefficace.
Man mano che l’organizzazione matura, sviluppa la capacità di:
Riconoscere le variazioni per causa comune e concentrarsi sul miglioramento continuo del sistema.
Identificare rapidamente le variazioni per causa speciale, intervenire per risolvere i problemi e implementare misure preventive.
Questa capacità di discernimento è cruciale per migliorare il flusso di lavoro, ridurre i rischi e aumentare la prevedibilità delle prestazioni.
Superare la mentalità vittimistica
Un ostacolo al discernimento dei rischi è che in molti ambienti aziendali la presunta complessità del contesto (cioè considerare tutte le variazioni come se fossero per causa speciale, mentre in realtà sono per causa comune) viene usata come scusa per giustificare le proprie prestazioni inadeguate. Le difficoltà esterne sono addotte come unica ragione delle scarse prestazioni, attribuendo i propri insuccessi a fattori esterni anziché a carenze personali o di metodo, di conseguenza evitando di assumersi la responsabilità di migliorare il sistema di lavoro.
Tale mentalità è particolarmente diffusa in ambienti di lavoro con bassa maturità. Si parla di ‘abdicazione’ in relazione alla leadership. Un leader che abdica alle proprie responsabilità, evitando di prendere decisioni e di affrontare i problemi, contribuisce a creare un ambiente in cui si diffonde una mentalità vittimistica. I membri del team, non sentendosi guidati e supportati, tenderanno a scaricare la colpa altrove e a lamentarsi invece di cercare soluzioni.
Al contrario un ambiente di lavoro positivo e collaborativo, con una leadership forte e supportiva, può contribuire a contrastare la mentalità vittimistica. Quando le persone si sentono valorizzate, responsabilizzate e parte di un team, sono più propense ad affrontare le sfide con un atteggiamento positivo e proattivo.
Evolvere la propria gestione del rischio insieme alla maturità organizzativa
La gestione del rischio nel Kanban Maturity Model (KMM) evolve significativamente attraverso i diversi livelli di maturità. Man mano che un’organizzazione matura, la sua capacità di identificare, analizzare e mitigare i rischi diventa più sofisticata e integrata nella sua cultura e nei suoi processi.
Ecco una panoramica di come il rischio viene gestito ai diversi livelli di maturità:
Livello 0 – Oblivious: A questo livello, il rischio non viene gestito in modo consapevole. L’organizzazione non ha processi definiti per l’identificazione o la mitigazione dei rischi, e le decisioni vengono prese in modo reattivo, spesso solo dopo che i problemi si sono già verificati.
Livello 1 – Team Focused: I team iniziano a riconoscere l’esistenza dei rischi, ma la gestione è ancora informale e limitata al livello di singolo team. I rischi vengono discussi durante le riunioni del team e si cerca di trovare soluzioni pragmatiche per mitigarli.
Livello 2 – Customer Driven: L’organizzazione inizia a comprendere l’importanza della gestione del rischio per la soddisfazione del cliente. Si introducono metriche per monitorare i rischi e si inizia a sviluppare una comprensione più olistica del flusso di lavoro, identificando potenziali punti deboli e colli di bottiglia.
Livello 3 – Fit for Purpose: La gestione del rischio diventa un processo più formale e integrato nel sistema Kanban. Si utilizzano le classi di servizio per dare priorità al lavoro in base al rischio e al valore per il cliente. Si implementano meccanismi di feedback per apprendere dagli errori e migliorare continuamente la gestione del rischio.
Livello 4 – Risk Hedged: L’organizzazione sviluppa una solida capacità di gestione del rischio. Si implementano processi di governance del rischio e si utilizzano metriche avanzate per monitorare le prestazioni e identificare le aree di miglioramento.
Livello 5 – Market Leader: La gestione del rischio diventa parte integrante della cultura organizzativa. L’organizzazione è in grado di anticipare i rischi e di adattarsi rapidamente ai cambiamenti del mercato. Si adotta un approccio proattivo alla gestione del rischio, investendo in innovazione e sperimentazione per mitigare i rischi futuri.
Livello 6 – Built for Survival: L’organizzazione è in grado di gestire eventi imprevisti e di alta criticità. Si sviluppano piani di emergenza e si mettono in atto strategie per garantire la resilienza e la continuità operativa, anche in scenari di crisi. Un’organizzazione a questo livello di maturità è antifragile, sa trarre beneficio dagli shock estremi (i ‘Cigni neri’) e sfruttarli a proprio favore per crescere.
In sintesi, la gestione del rischio nel KMM evolve da un approccio reattivo e informale a un processo proattivo, integrato e strategico. La maturità della leadership gioca un ruolo fondamentale in questo processo, guidando l’organizzazione verso una maggiore consapevolezza e una gestione più efficace del rischio.
Conclusione
La comprensione dei concetti di Extremistan e Mediocristan, la loro relazione con i rischi di variazione, l’evoluzione della maturità organizzativa sono fattori cruciali per una gestione del rischio efficace in un sistema Kanban. Analizzando la distribuzione dei Lead Time e implementando opportune strategie di gestione e controllo del flusso di lavoro, è possibile mitigare i rischi e migliorare la prevedibilità delle prestazioni dei servizi, anche in contesti complessi e incerti.
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.
Qualche giorno fa, un team IT con cui collaboro da tempo, e che ha già sviluppato un sistema Kanban abbastanza sofisticato, stava facendo un’analisi più puntuale del flusso di lavorazione dei ticket del proprio service desk e delle performance rispetto agli SLA (accordi sul livello di servizio).
Analizzando le metriche il team ha notato che a volte il servizio viene erogato (dalla prima risposta alla risoluzione) in tempi superiori a quelli previsti dagli SLA e si è accorto che questo succede in un caso specifico.
Viene aperto un ticket al quale viene assegnata priorità bassa o media. Il fornitore ci mette molto a rispondere e con il passare del tempo la priorità si alza. A un certo punto il ticket diventa a priorità alta, quando però è troppo tardi per risolverlo nel rispetto dei tempi previsti dagli SLA per la priorità alta (più stringenti rispetto a quelli per i ticket a priorità più bassa).
L’esempio che mi è stato fatto è quello di un incidente su un software di gestione ordini. Era stato aperto con priorità media. Dopo due settimane l’utente doveva procedere con gli ordini altrimenti l’azienda sarebbe restata senza materiali e la priorità era stata cambiata in alta. Assegnando una priorità più alta al ticket (con uno SLA più stringente), il team si è ritrovato immediatamente fuori SLA.
Questa è la tipica situazione in cui il team, nel proprio percorso di maturazione, si rende conto di avere bisogno di qualcosa di nuovo per gestire sempre meglio il proprio flusso di lavoro. E lo chiede al Kanban coach.
Da una gestione reattiva a una gestione proattiva delle dipendenze e del rischio correlato
Ho fatto riflettere il team sul fatto che la gestione delle dipendenze (dai fornitori, ma non solo) fatta fin lì era stata reattiva, mentre era arrivato il momento di introdurre le cosiddette ‘classi di dipendenza’ (Classes of Dependency Management), ovvero fare il triage anche a valle sui fornitori e, in funzione di quello, agire in modo proattivo, anticipando i problemi.
Dobbiamo considerare il flusso di lavoro su cui stiamo lavorando, nel nostro esempio il nostro service desk, come un servizio che chiama un altro servizio, nel nostro esempio il servizio di assistenza del fornitore.
In un sistema Kanban possiamo disporre di metriche di flusso, tra cui una curva di distribuzione dei Lead Time relativa allo step del flusso di lavoro in cui siamo in attesa del fornitore. La stessa curva rappresenta una buona approssimazione del Lead Time del nostro fornitore e possiamo utilizzarla per calcolare il livello di rischio che abbiamo rispetto al fatto che il fornitore ritardi la risoluzione del ticket. Disporre della metrica relativa al fornitore significa che possiamo valutare quanto questo sia affidabile e capire cosa aspettarci, in modo da poterci regolare di conseguenza.
Gestire le priorità in funzione delle classi di dipendenza
Possiamo quindi, in funzione del rischio calcolato sul tempo di risposta del fornitore, assegnare la classe di dipendenza e agire come segue:
aprire il ticket al fornitore con una priorità più alta rispetto a quella che esponiamo a monte all’utente del nostro servizio
eventualmente alzare da subito la priorità anche del nostro servizio
in funzione della classe di dipendenza attribuita e se esiste un buon livello di collaborazione, si può chiedere proattivamente al fornitore di riservare della capacità produttiva, in modo puntuale e dinamico
eventualmente si può riservare della capacità produttiva anche nel nostro servizio, per accelerare le nostre operazioni quando finalmente il fornitore risponde
Da un punto di vista pratico e in termini di visualizzazione, si contrassegna il ticket con un’etichetta che corrisponde alla classe di dipendenza. Si stabilisce quindi una policy correlata alla classe di dipendenza in base alla quale l’elemento di lavoro viene trattato opportunamente.
Conclusione
Sostanzialmente il rischio correlato alla dipendenza dal fornitore viene gestito giocando d’anticipo, in modo proattivo, sistematico e standardizzato. In questo modo non viene più cambiata la priorità in corso di lavorazione ai ticket perché, a fronte di un rischio, la policy che regola la gestione della classe di dipendenza prevede già una priorità più alta e le opportune contromisure. E anche a fronte di un fornitore poco affidabile, il nostro flusso di lavoro risulta maggiormente prevedibile e affidabile, aumentando la soddisfazione degli utilizzatori del nostro servizio.
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.
C’è molta confusione in circolazione sul concetto di “agilità”, in questo articolo voglio spiegare come la vera agilità aziendale e organizzativa sia la scienza di posticipare le decisioni, ma non troppo. Una scienza, non un’arte, perché alla base c’è il metodo scientifico.
Cos’è l’agilità aziendale e qual è il suo impatto operativo
L’agilità aziendale è la capacità di un’organizzazione di rispondere rapidamente ai cambiamenti, lasciando al proprio cliente la possibilità di cambiare in corso d’opera i requisiti del lavoro richiesto, in qualunque momento. Questo per ottenere un risultato finale che sia il più aderente possibile ai desiderata del cliente stesso.
Da un punto di vista operativo, di chi deve fare il lavoro, l’agilità si riflette nella convenienza di aspettare il più possibile a decidere e a impegnarsi a fare il lavoro. Questo approccio aumenta le opzioni disponibili e la possibilità di cambiare i requisiti del lavoro da fare, senza però essersi ancora impegnati a farlo e quindi senza sostenere eventuali costi di rilavorazione.
Sapere quanto aspettare prima di iniziare il lavoro
L’attesa d’altro canto aumenta anche la probabilità di consegnare il lavoro in ritardo. E quindi diventa cruciale sapere quanto si può aspettare prima di iniziare il lavoro e diventa fondamentale il ruolo delle metriche di flusso. E per poter disporre di metriche di flusso affidabili occorre un sistema stabile e prevedibile, che possiamo ottenere attraverso l’implementazione di un sistema Kanban.
Considerando per i servizi, come in figura, il tipico valore dell’ottantacinquesimo percentile (ma può variare in funzione della criticità del servizio stesso), si dovrà iniziare il lavoro con un anticipo rispetto alla data di consegna prevista che dia una confidenza statistica almeno dell’85% o, se preferiamo, un rischio massimo del 15% di ritardare rispetto alla data promessa, circa una volta su sette.
Pianificare utilizzando il Lead Time
La pianificazione e il successivo controllo di qualunque attività aziendale, sia delle attività correnti che delle attività relative ai progetti, viene fatta di conseguenza basandosi sui valori di Lead Time e diventa più accurata e affidabile, oltre che meno costosa da gestire. Invece di concentrarsi sulla stima dell’effort e l’aggiunta di fattori di rischio, Kanban si basa sui dati empirici del flusso di lavoro per prevedere in modo probabilistico le date di consegna.
Il metodo Kanban offre quindi un approccio alla pianificazione significativamente più vantaggioso rispetto ai metodi tradizionali. In definitiva, l’approccio di pianificazione basato sul Lead Time di Kanban promuove l’agilità aziendale, la consegna puntuale e la soddisfazione del cliente. A costi più bassi.
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.
Quando un’organizzazione introduce i principi e le pratiche Kanban, sviluppa la consapevolezza del servizio che offre al cliente e una comprensione iniziale dell’importanza della gestione del flusso di lavoro. L’attenzione si sposta quindi sul flusso di lavoro piuttosto che sul semplice completamento di singoli compiti. Tuttavia l’identificazione e la definizione del ‘flusso di lavoro’ possono risultare ancora ambigue. Ciò crea la necessità di una supervisione del flusso stesso e si osserva l’emergere del ruolo di Flow Manager .
Si noti che quello di Flow Manager è un ruolo da svolgere e non necessariamente un titolo di lavoro o una nuova posizione nell’organizzazione. Un approccio tipico all’implementazione di questo ruolo consiste nell’assegnarlo a un membro del team che si è offerto volontariamente e che possiede le conoscenze e le competenze adeguate per svolgere tale ruolo.
Le modalità di implementazione del ruolo tipicamente vengono poi adattate alla cultura organizzativa. Questo ruolo tende ad avere un focus interno, gestendo attivamente il flusso e concentrandosi sull’efficienza operativa e sul miglioramento continuo, promuovendo una gestione sostenibile delle attività del team. Con l’aumento del livello di maturità dell’organizzazione questo ruolo si può evolvere in quello di Service Delivery Manager.
Le responsabilità del Flow Manager in un sistema Kanban
Creare nel team la consapevolezza che si sta fornendo un servizio ai clienti.
Garantire la raccolta delle metriche di flusso.
Facilitare il Workflow Kanban Meeting.
Facilitare la comprensione delle richieste dei clienti.
Facilitare la risoluzione dei blocchi, l’eliminazione delle rilavorazioni e dei problemi legati all’invecchiamento del WIP (Work In Progress) che vengono segnalati dal team .
Più nello specifico il Flow Manager assicura che il flusso di lavoro rimanga fluido e privo di interruzioni. A tal fine, monitora costantemente il sistema Kanban per individuare colli di bottiglia — punti in cui il lavoro si accumula — e interviene per risolverli. Basa il suo lavoro sull’utilizzo di strumenti come la Kanban board e le metriche visive, ad esempio il Cumulative Flow Diagram (CFD), per mantenere il flusso stabile e prevedibile.
Il Flow Manager e il monitoraggio del flusso di lavoro
Il Flow Manager è anche responsabile dell’applicazione e del monitoraggio delle WIP Limit (Work in Progress Limit), uno dei pilastri del metodo Kanban. Questi limiti impediscono il sovraccarico del team, favorendo la focalizzazione sulle attività in corso. Il Flow Manager regola queste limitazioni quando necessario, adattandole ai cambiamenti del volume di lavoro o alle necessità operative.
Un altro aspetto fondamentale del ruolo è l’analisi delle metriche chiave per il flusso di lavoro. Tra queste troviamo il Lead Time (tempo totale per completare un’attività), il Cycle Time (tempo impiegato da un’attività per attraversare una fase specifica) e il Throughput (numero di attività completate in un determinato periodo). Questi dati consentono al Flow Manager di identificare inefficienze, misurare l’impatto delle modifiche e prevedere tempi di consegna più accurati.
Il Flow Manager come facilitatore per il team
Il Flow Manager non agisce solo come analista ma anche come facilitatore per il team. Aiuta i membri a superare ostacoli, supportandoli nell’organizzazione e nella priorità delle attività. Promuove inoltre una cultura di trasparenza, assicurandosi che tutte le informazioni rilevanti siano visibili sulla Kanban board. Questo approccio garantisce che tutti i membri del team abbiano una comprensione condivisa dello stato del lavoro.
La figura del Flow Manager è strettamente connessa al miglioramento continuo. Attraverso l’analisi costante e riunioni regolari (come le Flow Review), introduce modifiche incrementali al processo per ottimizzare le prestazioni.
Un aspetto distintivo del Flow Manager è la capacità di adattarsi ai cambiamenti. Grazie alla flessibilità del metodo Kanban, questa figura guida il team nell’affrontare nuove priorità o condizioni impreviste, mantenendo il focus sull’obiettivo finale. Inoltre, promuove una mentalità agile, incoraggiando il team a sperimentare, apprendere dagli errori e migliorare progressivamente.
In un sistema evoluto tipico di un organizzazione di maggiore maturità, il ruolo del Flow Manager può coesistere con il ruolo di Service Delivery Manager per supportare quest’ultimo nel presidio di specifici flussi e parti del sistema complessivo. In collaborazione con il Service Delivery Manager, il Flow Manager può garantire che il lavoro soddisfi le aspettative dei clienti, bilanciando al contempo qualità, efficienza e sostenibilità.
Un esempio di applicazione del ruolo di Flow Manager
La Kanban board del flusso di Onboarding su Kanban Zone fornisce automaticamente ad Alba le metriche di Lead Time.
Alba, nel ruolo di Flow Manager, ha supportato il Caterina nel seguente modo:
Mappatura e analisi del flusso di lavoro: Alba ha collaborato con il team per mappare il flusso di lavoro di Onboarding, identificando i colli di bottiglia e le inefficienze. Questo ha permesso a Caterina, insieme ad Alba, di avere una visione chiara del processo e di individuare le aree di miglioramento.
Misurazione e monitoraggio del Lead Time: Alba ha raccolto dati sul Lead Time di ogni fase del processo, consentendo al team di analizzare le prestazioni e di identificare le opportunità di miglioramento.
Implementazione di policy e pratiche Kanban: Alba ha lavorato con il team per implementare limiti al WIP, le classi di servizio e altre policy Kanban, contribuendo a stabilizzare il flusso di lavoro e a renderlo più prevedibile.
Gestione dei colli di bottiglia: Alba ha affrontato direttamente i colli di bottiglia, come il processo di firma digitale dei contratti, implementando soluzioni per semplificare e velocizzare le attività.
Comunicazione e collaborazione: Alba ha mantenuto una comunicazione costante con il team e con i dipartimenti tecnici, garantendo la trasparenza e la collaborazione tra le diverse parti coinvolte nel processo di Onboarding.
Il supporto di Alba, come Flow Manager, ha permesso al Direttore HR di:
Concentrarsi sulla strategia e sugli obiettivi di alto livello: Caterina ha potuto delegare la gestione del flusso di lavoro ad Alba, concentrandosi sulla definizione degli obiettivi strategici e sulla supervisione generale del processo.
Prendere decisioni informate: Grazie ai dati raccolti e alle analisi fornite da Alba, Caterina ha potuto prendere decisioni informate sulle politiche e le strategie di Onboarding.
Migliorare la comunicazione con i dipartimenti tecnici: Le iniziative di Alba per migliorare la comunicazione e la collaborazione hanno contribuito a rafforzare i rapporti tra HR e i dipartimenti tecnici.
Presentare risultati concreti al comitato di direzione: Caterina ha potuto presentare al comitato di direzione i risultati tangibili del lavoro svolto da Alba e dal team, dimostrando il valore del suo ruolo di leadership e l’efficacia del sistema Kanban implementato.
Conclusione
In sintesi, il ruolo di Flow Manager è un elemento strategico per il successo del metodo Kanban. Supporta il team nel mantenere un flusso di lavoro bilanciato, risolvendo problemi e promuovendo la collaborazione. Grazie a un approccio data-driven, garantisce un miglioramento continuo, ottimizzando le prestazioni operative e soddisfacendo le esigenze dei clienti.
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.
Nel metodo Kanban non sono indicati specificamente dei ruoli, con tre eccezioni: una di queste è il ruolo di Service Delivery Manager (SDM). Come mai un metodo che non prevede ruoli, ne indica alcuni? Non è questa una contraddizione? In realtà no, perché tali ruoli sono dei cosiddetti ‘ruoli emergenti’, si possono empiricamente osservare nelle aziende che applicano il metodo.
Inoltre il contenuto che viene dato a tali ruoli è coerente con la filosofia del metodo. Ovvero gestire un flusso di lavoro, o meglio ancora un sistema di lavoro. E lasciare che le persone si organizzino intorno ad esso. Il ruolo di Service Delivery Manager emerge perché sviluppando ed evolvendo un sistema Kanban viene a delinearsi l’esigenza di una ‘accountability’ sul flusso di lavoro.
L’esigenza di una accountability
Va ricordato che il termine ‘accountability’ in inglese ha un significato più forte rispetto alla semplice ‘responsibility’, termini entrambi normalmente tradotti in italiano con ‘responsabilità’. In italiano il termine ‘accountability’ non ha un vero corrispondente perché ha un significato più stringente. Esprime la responsabilità personale ultima, necessariamente in capo a un singolo, che ha il dovere di giustificare le proprie azioni e decisioni e rispondere del proprio operato. Contiene anche con un’implicita valenza di “responsabilità morale a operare bene” e in caso contrario a “pagare di persona” (account = conto, rendiconto).
Se un’organizzazione implementa un sistema Kanban è necessario che ci sia un presidio chiaro che si curi di farlo funzionare in modo adeguato e coerente. E allora emerge l’esigenza di assegnare un’accountability chiara a un Service Delivery Manager.
Ho già parlato in un case study di una mia esperienza di alcuni anni fa. In quell’occasione, grazie alla felice intuizione del CEO, mio diretto responsabile, mi sono ritrovato nel ruolo di Delivery Manager. Da lì ho avuto la possibilità, ma anche la responsabilità, di implementare un sistema Kanban. In quel caso l’emergere del ruolo ha facilitato l’emergere del sistema e viceversa.
Il focus di tale ruolo deve restare comunque sulla gestione del flusso di lavoro e del sistema e non sulla gestione delle persone. Quali sono quindi le responsabilità, o meglio le accountability, del Service Delivery Manager?
L’immagine (fonte Kanban University) mostra il focus del Service Delivery Manager sulla gestione del flusso di lavoro
Le responsabilità del Service Delivery Manager in un sistema Kanban
Gestire il flusso di lavoro, cioè l’evasione delle richieste di lavoro dei clienti.
Facilitare il Delivery Planning Meeting.
Gestire la Service Delivery Review.
Guidare l’identificazione, l’analisi e la risoluzione degli impedimenti nel flusso di lavoro, come ad esempio blocchi, rilavorazioni e elementi di lavoro da troppo tempo in lavorazione.
Supervisionare la gestione delle dipendenze e le cause assegnabili per i ritardi nell’erogazione dei servizi che non hanno soddisfatto le aspettative del cliente o gli SLA.
Più nello specifico il Service Delivery Manager deve assicurarsi che il sistema Kanban funzioni correttamente. Cioè deve assicurarsi che le seguenti tipiche attività di gestione del flusso siano svolte da tutto il team per mantenere il flusso di lavoro stabile e prevedibile:
Visualizzare il lavoro: utilizzare uno strumento, fisico o digitale, per rappresentare visivamente il flusso di lavoro, per mantenere sotto controllo lo stato di ogni elemento di lavoro, darne visibilità a tutta l’azienda.
Definire le policy di lavoro e in particolare limitare il lavoro in corso (WIP): per gestire il flusso in modo efficace, è importante limitare il numero degli elementi di lavoro che possono essere “in corso” contemporaneamente. Questo impedisce al team di disperdere le energie su troppi fronti e di generare inefficienze. Fare in modo che le policy siano concordate e visibili a tutte le persone coinvolte.
Monitorare i tempi di ciclo (Lead Time e Cycle Time): il Lead Time indica il tempo totale che intercorre dall’inizio alla fine di un’attività (il tempo visto dal cliente), mentre il Cycle Time misura il tempo che impiega il team per completare il lavoro da quando si impegna a svolgerlo. Monitorare questi parametri è essenziale per mettere a punto livelli servizio e pianificazione realistici e individuare le aree in cui il flusso è rallentato e dove si può intervenire per migliorare.
Individuare i colli di bottiglia e le cause di blocco del flusso: analizzando costantemente i dati sul flusso, si potranno identificare i colli di bottiglia, cioè i punti del processo dove il lavoro si accumula e rallenta. Potrebbe trattarsi di una fase specifica del processo o di una risorsa che non è disponibile al momento giusto.
Intervenire per migliorare: una volta identificati i problemi, il team deve agire per risolverli. Ad esempio, se il collo di bottiglia è in fase di revisione del lavoro, potrebbe essere necessario assegnare più risorse o rivedere le modalità di gestione delle revisioni stesse.
Implementare incontri di feedback con una cadenza appropriata: incoraggiare la collaborazione, l’apprendimento e i miglioramenti. Analizzare i dati e lasciarsi guidare dai dati.
Conclusione
In conclusione il Service Delivery Manager nel metodo Kanban può svolgere una funzione cruciale nel garantire il corretto flusso di lavoro, supportando il miglioramento continuo, aiutando il team a ottimizzare i processi e a rispettare gli SLA. Inoltre, può contribuire a massimizzare il valore del servizio erogato al cliente, assicurando un’erogazione puntuale e di qualità.
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.
Uno degli aspetti che comunemente non sono così noti e chiari è il fatto che il metodo Kanban aiuta a ridurre il rischio operativo e gli errori previsionali. La difficoltà iniziale delle persone alle quali ne parlo parte proprio dalla comprensione del concetto di rischio operativo. “Quale rischio operativo?” mi chiedono. “Il rischio legato al fatto che a causa di diversi eventi, interni o esterni all’organizzazione, potremmo metterci più di quanto previsto per fare il lavoro” rispondo. “In che senso?” insistono. Allora comincio a porre loro alcune domande.
Il concetto di Lead Time
Chiedo di farmi un esempio di qualche tipica richiesta di lavoro che ricevono. “Quanto tempo ci mettete per evadere questa richiesta di lavoro?” chiedo. La risposta tipicamente è un numero. “Siamo sicuri?” chiedo. “Come varia questo valore a seconda delle circostanze, lo sapete?”. Normalmente la risposta è vaga.
Allora comincio a disegnare su un foglio o su una lavagna una rappresentazione di una semplice Kanban board come in Figura 1. Spiego che chiameremo Lead Time il tempo che ogni richiesta di lavoro (che chiameremo Work Item) ci mette per essere evasa e spiego che il Lead Time non è un unico valore ma una distribuzione di valori. Poi ripeto la domanda: “Quanto tempo ci mettete per evadere questa richiesta di lavoro?” e quindi, senza aspettare la risposta, spiego che il tempo rilevato di evasione della richiesta può variare e comincio ad annotare i valori su un grafico come in Figura 1.
Figura 1
La distribuzione dei Lead Time
Proseguendo ad aggiungere valori chiedo: “succede che i valori di Lead Time si ripetano, giusto?” e così facendo vado ad aggiungere al grafico i valori che si ripetono impilandoli ai precedenti, fino a raggiungere una rappresentazione come in Figura 2. A questo punto verifico con i miei interlocutori se si ritrovano nel grafico disegnato, normalmente rispondono di sì.
Figura 2
Quale valore utilizzare per fare previsioni
Siamo pronti allora per il passo successivo che consiste nell’invitare i miei interlocutori a rispondere alla domanda: “quale dei valori misurati secondo voi ha senso utilizzare per fare previsioni future?” e qui inizia la vera riflessione, come in Figura 3.
Figura 3
Qualcuno risponde “la media” e allora faccio riflettere sul fatto che solitamente si dice ‘media’ riferendosi a quel valore per cui una volta su due ci si mette di più, mentre una volta su due ci si mette di meno del valore stesso. Questo in termini statistici però non è il concetto di media, ma più propriamente è quello di mediana, anche nota come cinquantesimo percentile. Quindi faccio notare come prendendo a riferimento la mediana saremo in ritardo una volta su due, ossia avremo il 50% di probabilità di non essere puntuali, che è un rischio piuttosto elevato, probabilmente non accettabile.
Qualcuno allora mi risponde “il valore più frequente”. Faccio notare che il valore più frequente, in termini statistici detto moda, nel grafico è tipicamente più a sinistra della mediana, il che significa che ho ancora più probabilità di essere in ritardo rispetto ad utilizzare la mediana, corro un rischio ancora più elevato, superiore al 50%.
Parliamo di rischio operativo
Arrivati a questo punto cambio prospettiva alla riflessione e chiedo “guardiamola dal punto di vista del rischio, quale probabilità di arrivare in ritardo siete disposti ad accettare? O meglio, quale probabilità di arrivare in ritardo sono disposti ad accettare i clienti del vostro servizio?” Qui le risposte sono ovviamente molto diverse a seconda dei servizi e dei casi, ma di base propongo loro di ragionare intorno all’ottantacinquesimo percentile, ovvero il valore previsionale in base al quale ci si prende un rischio del 15% di arrivare in ritardo, che normalmente per i servizi è accettato e che si usa in Kanban.
Per concludere faccio infine notare come fare previsioni sul completamento di una richiesta di lavoro senza misurare i Lead Time e senza effettuare un’analisi statistica sia fuorviante perché essendo noi tutti soggetti ai bias cognitivi e in particolare all’euristica della disponibilità, tenderemo automaticamente ad adottare il valore più frequente, prendendoci dei rischi inaccettabili senza nemmeno rendercene conto.
Conclusione
Chiaramente questo è solo l’inizio e ci sono altri passaggi da fare per introdurre efficacemente gli strumenti statistici, a cominciare dalla comprensione del tipo di curva di distribuzione presente e dalla validazione del modello che emerge dalla rilevazione dei dati. Normalmente però queste riflessioni avviano un percorso evolutivo che porta progressivamente nel tempo a un miglioramento sostanziale dei modelli previsionali, alla stabilizzazione dei flussi di lavoro e quindi a una migliore gestione del servizio.
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.
