Facilitazione | Il Project Management & l'arte della Maratona

Come funziona Kanban: il Flow Manager per migliorare la gestione del flusso di lavoro

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

Il Flow Manager è responsabile di quanto segue:

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

Un esempio concreto di applicazione del ruolo di Flow Manager è descritto nel case study di Grow (per leggerlo clicca qui). In questo caso, Alba, l’Onboarding manager, ha svolto il ruolo di Flow Manager, mentre Caterina, Direttore HR, ha assunto nel tempo il ruolo di Service Delivery 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.

Come funziona Kanban: il Delivery Manager e la responsabilità in un sistema Kanban

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

Le funzioni tipiche del Service Delivery Manager sono le seguenti:

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à.

Come funziona Kanban: il metodo Kanban per ridurre il rischio operativo e gli errori previsionali

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.

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ì.

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.

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.

Pillole di Kanban applicato: euristiche e bias cognitivi mentre si scrivono i case study su Kanban

Mentre scrivevo uno dei case study pubblicati per il portale Kanban+ della Kanban University, mi sono imbattuto in uno dei fenomeni tipici che avvengono nella nostra mente e rispetto ai quali anche il Metodo Kanban ci mette in guardia: le euristiche e i bias cognitivi.

Una parte significativa della teoria scientifica alla base del Metodo Kanban si rifà agli studi e alle scoperte dello psicologo Daniel Kahnemann, il quale insieme al collega Amos Tversky ha studiato a fondo e dimostrato con esperimenti la tendenza della mente umana a violare sistematicamente alcuni principi di razionalità. Kahnemann, riprendendo studi precedenti, ci spiega come la nostra mente sia caratterizzata da due processi di pensiero distinti: uno veloce e intuitivo (detto sistema 1) e uno più lento e ‘pigro’, ma anche più logico e riflessivo (detto sistema 2). Il primo presiede all’attività cognitiva automatica e involontaria, il secondo entra in azione quando dobbiamo svolgere compiti che richiedono concentrazione e autocontrollo. Questa organizzazione del pensiero ci consente di eseguire quotidianamente con relativa facilità operazioni complesse ma può anche essere fonte di errori, appunto le euristiche e i bias cognitivi.

Il giorno in cui avevamo impostato insieme alla mia cliente il sistema Kanban del quale ho poi raccontato nel case study, avevo utilizzato una Kanban board fisica. Si trattava di una lavagna bianca sulla quale avevo disegnato con un pennarello le colonne corrispondenti alle fasi di lavoro e sulla quale avevo man mano applicato dei post-it che rappresentavano gli elementi di lavoro. Al termine della giornata di lavoro avevo quindi fotografato con lo smartphone la lavagna, in modo tale da ‘fissare’ il lavoro svolto e archiviarne la versione così come realizzata quel giorno.

Bias di ancoraggio ed euristica affettiva

La macchina fotografica dello smartphone appone in un angolo delle foto, in sovraimpressione, una ‘marcatura temporale’ (data e ora), in modo che non si perda l’informazione di quando la foto è stata scattata. Ecco il dettaglio della foto fatta quel giorno, cosa leggete?

Il formato è ‘data inversa’, si legge da destra verso sinistra, ho scattato la foto il 18 settembre 2020 alle ore 17:41.

Soltanto che rileggendo la data distrattamente quando riguardavo il materiale per scrivere il case study, il mio Sistema 1, più abituato a leggere date scritte nel senso opposto, da sinistra verso destra, si è fatto ingannare dalla somiglianza con la data 20/9/18 (20 settembre 2018). Tipica dinamica automatica da Sistema 1 e tipico bias di ancoraggio. Il Sistema 1 ha fatto troppo affidamento sull’abitudine a leggere le date da sinistra verso destra, che ha fatto da ‘ancora’. Il mio Sistema 2 ha ritenuto plausibile l’informazione e pigramente non è intervenuto.

Inoltre la data (sbagliata) del 20/9/18 ha funzionato a sua volta da ulteriore ‘ancora’ perché sono andato avanti convinto che fosse la data giusta. Quando ho rivisto il case study insieme alla mia cliente, avevamo dei dubbi sulle date, non ci tornava che il progetto fosse iniziato due anni prima, ma ero talmente convinto della data letta sulla foto che alla fine ho convinto anche lei. “E’ stampato sulla foto, non possiamo sbagliarci” le dicevo. Sbagliando.

Deve infine avere giocato un ruolo anche l’euristica affettiva, forse abbiamo avuto tutti e due la tendenza a percepire nella nostra mente come più lunghi i tempi di un progetto che fin lì aveva dato soddisfazioni a entrambi, altra dinamica automatica da Sistema 1 e di nuovo il Sistema 2 non è intervenuto.

Arrivano i nostri, il Sistema 2

Ho trovato interessante il modo con cui un bel giorno mi sono finalmente accorto dell’errore. Dovendo preparare un incontro con la cliente e rivedendo, con il Sistema 2 ben vigile e attivo, le foto della prima versione della Kanban board, perché ero concentrato a valutare varie opzioni su come evolverla, ho finalmente prestato attenzione ai dettagli e letto bene la data, per cui il mio Sistema 2 ha decodificato che si trattava di un formato ‘data inversa’ e segnalato l’errore. Resomi conto dell’errore, ho corretto il case study.

Morale della storia: bisogna conoscere le dinamiche della nostra mente, essere consapevoli dei rischi connessi alle euristiche e ai bias cognitivi e imparare a controllarli il più possibile. In questo caso avrei fatto meglio la prima volta a non fidarmi completamente del riscontro del Sistema 1 e ‘costringere’ il Sistema 2 a fare un piccolo sforzo e una verifica di congruenza del dato fornito dal Sistema 1.

Più in generale, nei sistemi Kanban utilizziamo in modo sistematico pratiche quali metriche, visualizzazioni e cadenze proprio per costringere il Sistema 2 a fare tali verifiche di congruenza, in modo da limitare il più possibile l’impatto dei bias cognitivi sulla valutazione del nostro lavoro.

Migliora il tuo modo di lavorare con Kanban: come analizziamo in modo visuale i flussi di lavoro alla ricerca di potenziali miglioramenti

Il metodo Kanban aiuta a migliorare il modo di lavorare e negli articoli che trovate nel blog ho raccontato come questo sia stato attuato nelle aziende con cui collaboro. In questo articolo vorrei raccontare invece come funziona ‘dietro le quinte’, come insieme alle persone dei team coinvolti analizziamo in modo visuale i flussi di lavoro alla ricerca dei potenziali miglioramenti. L’esempio nel seguito si riferisce al dipartimento risorse umane del quale parlo in un caso di studio pubblicato recentemente e al suo flusso di lavoro per l’onboarding dei nuovi dipendenti.

Lavagna su Miro utilizzata insieme al dipartimento risorse umane per analizzare i flussi di lavoro

Per fare l’analisi iniziale dei flussi, di solito chiedo di incontrare il team in presenza. Il primo impatto è fondamentale per stabilire una relazione con le persone coinvolte. Creare un buon clima di collaborazione aiuta più tardi a fare emergere alcuni dettagli che altrimenti sfuggirebbero. Conoscere le persone nel loro ambiente di lavoro aiuta anche a cogliere alcuni non detti che possono essere importanti.

1. Prima mappatura dei processi e misurazione su foglio Excel

Per prima cosa quindi abbiamo mappato i flussi di lavoro su una lavagna bianca fisica, usando post-it e pennarelli. Abbiamo proceduto in modo estremamente informale, non ci siamo preoccupati della notazione utilizzata, l’importante era che il flusso di lavoro fosse chiaro e comprensibile alle persone presenti, che poi erano quelle che avrebbero dovuto leggere e usare il diagramma. Questo approccio poco formale aiuta a coinvolgere anche le persone con poca o nessuna conoscenza dei metodi di rappresentazione dei processi. Scherzando per sdrammatizzare con chi è abituato ad approcci più formali di rappresentazione, dico che scriviamo i processi con notazione BPMN che però nel nostro caso significa Brutal Process Marco’s Notation.

Per far cogliere immediatamente il senso del lavoro e anche per arrivare rapidamente a qualche risultato, una volta definito il flusso e individuate le sue fasi, con il nostro team di risorse umane abbiamo cominciato a misurare il flusso a mano, segnandoci su un foglio Excel i tempi di attraversamento delle varie fasi del flusso. Queste misure ci hanno permesso di disegnare i primi grafici di densità di distribuzione del Lead Time e cominciare a comprendere le dinamiche dei flussi di lavoro. E’ bastato questo per individuare alcuni evidenti colli di bottiglia verso i quali indirizzare le azioni di miglioramento, che hanno portato nel giro di un solo mese al dimezzamento del Lead Time medio, ma soprattutto ad avere una curva di distribuzione Thin-tailed. In pratica avevamo dimezzato e reso più certo il tempo necessario per l’onboarding dei nuovi dipendenti dell’azienda.

2. Analisi STATIK del servizio

A questo punto abbiamo svolto l’analisi STATIK del servizio di onboarding. STATIK sta per Systems Thinking Approach to Implementing Kanban ed è un approccio sistemico che permette di analizzare e mappare le fonti di insoddisfazione, la domanda, le capability del sistema, il flusso di lavoro e le classi di servizio per arrivare a definire una prima versione di un sistema Kanban. Essendosi ormai affiatato il team, anche grazie ai primi promettenti risultati, questo lavoro è stato svolto in parte da remoto. Abbiamo svolto il lavoro in ogni caso su lavagna virtuale Miro, sulla quale compilavamo un template STATIK Canvas, strumento efficacissimo per procedere rapidamente in modo visuale e ordinato.

3. Evoluzione dei processi su lavagna virtuale

Messo a punto il primo sistema Kanban, abbiamo cominciato a evolverlo progressivamente e sperimentalmente. Abbiamo rivalutato periodicamente tutti i flussi di lavoro, alla ricerca di semplificazioni e linearizzazioni. Per visualizzare questo lavoro abbiamo utilizzato di nuovo la lavagna Miro, sulla quale abbiamo mappato la seconda versione dei flussi, sempre con la solita notazione brutale. Da lì in poi abbiamo fatto periodicamente riflessioni e sperimentazioni, aggiornando i flussi sulla lavagna quando queste ultime avevano successo.

4. Kanban board elettronica con misurazione

Nel nostro percorso evolutivo il team ha cominciato con il tempo ad avvertire il bisogno di fare un uso più avanzato delle pratiche Kanban di visualizzazione e gestione del flusso di lavoro, potendo disporre anche di uno strumento di misura più agevole di quanto non fosse il foglio Excel, per cui dopo qualche mese abbiamo cominciato ad utilizzare una kanban board virtuale su Kanban Zone. Questo passaggio di ha permesso una migliore gestione dell’attività e un monitoraggio più accurato e completo delle metriche di flusso, potendo continuare il nostro percorso di evoluzione sperimentale e collaborativa con strumenti visuali.

L’evoluzione progressiva dei flussi di lavoro ha portato infine il team, nel giro di un anno, a ridurre dell’89% il tempo necessario per l’onboarding dei nuovi dipendenti. Questo percorso ha portato a rivalutare il sistema informativo aziendale dell’HR, che sta venendo costantemente aggiornato recependo i flussi aggiornati insieme a tutte le logiche e le misure del sistema Kanban. E il viaggio continua….