Il Project Management e l'arte della Maratona

L’Arsenale di Venezia: un sistema Kanban ante litteram

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.

Fonti sull’organizzazione del lavoro nell’Arsenale di Venezia:
Giovanni Caniato – L’Arsenale: maestranze e organizzazione del lavoro – Treccani
Carlo Gatti – L’Arsenale di Venezia – Mare Nostrum

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.

Pillole di Kanban applicato: le classi di servizio permettono ai fornitori di gestire al meglio le aspettative dei clienti

Quando un cliente richiede un intervento a un fornitore, il suo obiettivo principale è ottenere una soluzione rapida ed efficace alla propria richiesta. Non è interessato alle eventuali difficoltà interne del fornitore, come un carico di lavoro elevato o altre sfide organizzative. Questa realtà pone una pressione significativa sui fornitori, ma offre anche un’opportunità per migliorare l’organizzazione utilizzando strumenti come le Classi di Servizio definite dal metodo Kanban.

Gestione di tre classi di servizio al gate di un aeroporto

Il cliente e le aspettative di risposta

La settimana scorsa, erano i primi giorni del nuovo anno dopo le festività natalizie, ho chiesto un intervento a un fornitore e ho ricevuto questa risposta:

“Buongiorno, oggi pomeriggio verrete contattati da Mario (nome di fantasia) e verrà fornito un preventivo per gli interventi da svolgere.
Ci scusiamo per l’attesa, ma abbiamo un carico di lavoro abbastanza elevato in questi giorni e stiamo cercando di evadere tutte le richieste in maniera più celere possibile.
Grazie”

Ho preso questa come esempio, ma risposte dello stesso tenore sono abbastanza comuni nei servizi. Alle volte sono anche verbose e forniscono giustificazioni articolate, tipicamente imputando la responsabilità a fattori esterni. Tuttavia al cliente non interessa quale carico di lavoro abbia il fornitore né il perché. Mi chiedo sempre perché chi scrive tali risposte non rifletta mai sul fatto che, quando si trova a sua volta a essere cliente di qualcuno, non è affatto interessato ai problemi di chi sta dall’altra parte.

Per un’organizzazione che vuole migliorare il proprio livello di maturità, è fondamentale smettere di dedicare tempo alle giustificazioni e investire invece lo stesso tempo nello sviluppo di un sistema organizzativo. Il metodo Kanban ci può aiutare e nello specifico ci possono aiutare le Classi di Servizio.

Perché il cliente non è interessato ai problemi del fornitore?

Il cliente si trova al centro della propria esperienza e il suo problema è la sua priorità. Ecco alcuni motivi per cui il cliente non considera rilevanti le difficoltà interne del fornitore:

Aspettative elevate: I clienti si aspettano risposte rapide e soluzioni efficaci, soprattutto quando hanno già atteso un certo periodo di tempo.
Concorrenza sul mercato: Se un fornitore non è in grado di rispondere tempestivamente, il cliente può rivolgersi a un concorrente.
Percezione del valore: Il cliente valuta il servizio in base al risultato finale e alla qualità dell’interazione, non agli ostacoli incontrati dal fornitore lungo il percorso.

Questa disconnessione di prospettive sottolinea l’importanza di un’organizzazione interna che permetta di gestire al meglio le richieste, anche in periodi di alta domanda.

Il metodo Kanban e le Classi di Servizio

Le Classi di Servizio nel metodo Kanban aiutano gestire il lavoro in base al costo del ritardo, ovvero quanto costa al cliente aspettare che il lavoro venga fatto. Le Classi di Servizio sono la base per la costruzione di una solida disciplina di triage, che è la vera risposta ai clienti per fornire loro buoni livelli di servizio.

Vediamo quali sono le tipiche Classi di Servizio che possono essere utilizzate per garantire i livelli di servizio, anche a fronte di un carico di lavoro elevato.

1. Classe Urgente (Expedite)

Questa classe è dedicata alle richieste che richiedono attenzione immediata e non possono aspettare. Nel contesto del servizio clienti, potrebbe includere:

Problemi critici che bloccano le operazioni del cliente.
Emergenze che richiedono un intervento immediato.

Le richieste in questa classe devono essere gestite con la massima priorità, interrompendo temporaneamente il lavoro su altre attività. Perciò il numero di richieste di Classe Urgente gestibili deve essere limitato, definendo bene le policy per l’assegnazione di questa classe alle richieste.

2. Classe a Data Fissa (Fixed Date)

Alcune richieste hanno una scadenza specifica, ma non richiedono attenzione immediata. Ad esempio:

Interventi programmati.
Attività legate a eventi o scadenze legali.

Queste richieste devono essere pianificate per garantire che siano completate entro la data richiesta. Per pianificarle correttamente è necessario conoscere il tempo di attraversamento (Lead Time) per sapere quando metterle in lavorazione. Ho scritto un articolo al proposito che potete leggere qui.

3. Classe Standard

La maggior parte delle richieste rientra normalmente in questa classe. Sono importanti, ma non urgenti e non hanno una scadenza specifica. Il loro costo del ritardo cresce linearmente e devono essere gestite entro un ‘periodo ragionevole’. Nei sistemi organizzativi maturi il fornitore è in grado di definire tale ‘periodo ragionevole’ e offrire al cliente un livello di servizio standard basato sulla misura del Lead Time. Il fornitore è anche in grado di calcolare un livello di rischio operativo rispetto al livello di servizio offerto. Ho scritto un articolo al proposito che potete leggere qui.

4. Classe Intangibile

Questa classe è riservata a lavori che migliorano i processi interni o riducono i rischi futuri, ma che non hanno un impatto immediato sul cliente. Il costo del ritardo è appunto ‘intangibile’. Ad esempio:

Ottimizzazione dei sistemi.
Formazione del personale.

Queste richieste svolgono un ruolo importante nei periodi di bassa domanda da parte dei clienti, perché costituiscono una riserva di lavoro che consente di mantenere costante il carico di lavoro del sistema.

Differenziazione dei prezzi in base alle Classi di Servizio

Un aspetto interessante delle Classi di Servizio è la possibilità di applicare prezzi differenziati, come avviene in settori come quello ferroviario o aereo. Ad esempio:

Classe Urgente: Può comportare un costo più elevato per garantire un trattamento prioritario e la disponibilità immediata delle risorse.
Classe a Data Fissa: Un prezzo intermedio, che riflette la necessità di una pianificazione specifica ma senza l’urgenza.
Classe Standard: Un prezzo adeguato al livello di servizio standard offerto.
Classe Intangibile: In molti casi, questa classe potrebbe non essere addebitata direttamente al cliente ma rappresentare un investimento interno.

Definire una struttura tariffaria in funzione delle Classi di Servizio non solo permette di allocare meglio le risorse, ma può anche aiutare i clienti a scegliere il livello di servizio più adatto alle loro esigenze, aumentando la loro soddisfazione complessiva.

Come implementare le Classi di Servizio nella gestione delle richieste

Un approccio di base alla disciplina del triage prevede un lavoro continuativo rispetto ai seguenti punti:

Identificazione delle richieste: Classificare ogni richiesta in base al costo del suo ritardo utilizzando le Classi di Servizio.
Comunicazione con il cliente: Informare il cliente su quando e come la sua richiesta verrà gestita, migliorando la trasparenza.
Allocazione delle risorse: Assegnare le risorse in base alle classi, evitando il sovraccarico di un singolo team o operatore.
Monitoraggio e miglioramento continuo: Utilizzare metriche come il Lead Time e il tempo di ciclo (Cycle Time) per monitorare le prestazioni e apportare miglioramenti.

Conclusione

Un carico di lavoro elevato non deve diventare un ostacolo alla soddisfazione del cliente. Implementando le Classi di Servizio del metodo Kanban ed eventualmente introducendo una differenziazione dei prezzi, i fornitori possono migliorare la gestione delle richieste, garantire tempi di risposta adeguati e mantenere alta la soddisfazione del cliente. In questo modo, è possibile trasformare una sfida organizzativa in un’opportunità per ottimizzare i processi e fidelizzare i clienti.

Pillole di Kanban applicato: quando un approccio pragmatico ed evolutivo evita di complicare inutilmente le cose

Quando si implementa un sistema Kanban è importante evitare di complicare inutilmente le cose. In particolare un aspetto con cui mi confronto spesso è come riuscire a ricavare, appunto senza complicazioni inutili, le prime metriche di flusso su cui lavorare.

Iniziare da quello che si sta facendo ora

Kanban ci insegna a iniziare da quello che si sta facendo ora e tipicamente i team dispongono già di sistemi informativi, quali che siano. Un approccio relativamente semplice per ottenere dati sui Lead Time è quindi quello di estrarre dai sistemi esistenti le marche temporali (timestamp) relative alle varie attività e lavorare su quelle in un foglio di calcolo, per ricavare le metriche. Così ho fatto anche recentemente, salvo che mi sono trovato davanti a una situazione che mi ha fatto riflettere. Voglio raccontarvi l’episodio perché è rappresentativo di un approccio che si incontra spesso e che però è dannoso.

Una soluzione inutilmente complicata

Il flusso di lavoro in questione (per la gestione dell’iscrizione a un servizio e la firma di un contratto) consta di 5 step. Ho chiesto al fornitore del sistema informativo già esistente di poter estrarre una tabella con le marche temporali dei passaggi di stato tra i cinque step. Semplicissimo, il resto lo avrei fatto io sul mio foglio di calcolo. Ho ottenuto la seguente risposta (la ho modificata e decontestualizzata per ovvie ragioni di riservatezza, ma ne ho conservato il senso):

“Per rispondere alla richiesta basterebbe aggiungere 5 campi alla form di iscrizione, che verrebbero valorizzati ad ogni passaggio di stato. (T0 – Creazione, T1 – Risposta, T2 – Verifica, T3 – Firma, T4 – Completata)

Però, durante i primi utilizzi del sistema è emersa la necessità di “forzare lo stato” dell’iscrizione per riportarlo indietro e dunque si potrebbe verificare che un determinato T registrato nel sistema possa essere sovrascritto (es. “T3 – Firma” se ripercorro uno step precedente verrebbe sovrascritto).

A tal proposito quanto sopra proposto non sarebbe più valido e la nostra soluzione diventa quella di disabilitare il campo di stato dell’iscrizione e implementare un’azione “Cambia Stato” dove si dovrà selezionare il nuovo stato che si vuole assegnare all’iscrizione, oltre all’inserimento di una motivazione.

I campi sopra proposti non sarebbero più necessari e addirittura fuorvianti e dunque la form sopra descritta alimenterebbe un elenco di “Audit”, in cui ogni singola riga rappresenta un singolo cambio di stato della singola iscrizione. (Autore, Ora e Motivazione).

Saranno messi a disposizione i seguenti elenchi:
…”

Il messaggio terminava con la lista degli elenchi messi a disposizione e una quotazione della soluzione proposta.

La soluzione semplice

Le prime tre righe in realtà avevano già risposto alla mia richiesta, sarebbe bastato fare una quotazione di quello (che però non è stata fatta). Invece chi ha risposto ha preso spunto da alcune eccezioni che si erano verificate nel flusso e si è impegnato nell’immaginare una gestione di tali eccezioni. Che peraltro nessuno aveva richiesto. Tanto però è bastato per convincere i miei colleghi a rimandare la richiesta.

Ho dovuto discutere, prima con i miei colleghi, poi con il fornitore, per farli recedere dalla ‘gestione delle eccezioni’ e convincerli ad adottare la semplice soluzione che anche il fornitore aveva perfettamente delineato nelle prime tre righe della risposta. Una volta convinti, e a qualche settimana di distanza dall’implementazione (per raccogliere i primi dati), la nostra Flow Review si è arricchita di una utilissima metrica di distribuzione dei Lead Time. E le eccezioni? Le ho semplicemente tolte dai dati e trattate a parte, per il momento.

Morale della storia

Che lezione possiamo trarre da questa storia?

Il metodo Kanban incoraggia la semplicità e l’efficienza, iniziando con i processi esistenti, migliorandoli in modo incrementale e concentrandosi sul flusso di valore. Nel caso descritto è stata sufficiente la semplice estrazione dei dati per analizzare le prime metriche e valutare insieme al team le successive azioni di miglioramento del servizio da sperimentare. Senza inutili complicazioni.

Pillole di Kanban applicato: lo spillone porta comande in pizzeria

Una delle caratteristiche principali del metodo Kanban è la semplicità e l’efficacia nel visualizzare il flusso di lavoro. Un esempio sorprendentemente chiaro di Kanban in azione si può trovare in una pizzeria tradizionale e in quello che reputo uno degli strumenti più antichi del mondo: lo spillone porta comande.

Lo spillone porta comande come sistema Kanban

Come è ancora facile osservare in molte pizzerie e ristoranti, le comande vengono tradizionalmente appuntate su foglietti di carta e infilate in uno spillone vicino alla cucina. Questo semplice strumento è un esempio intuitivo di sistema Kanban. Riflettiamo su come funziona:

1. Visualizzazione del lavoro

Ogni foglietto rappresenta un ordine da preparare. Lo stato del lavoro è visibile in tempo reale:

I foglietti infilati sullo spillone sono gli ordini ricevuti e ancora da iniziare.
Quelli che vengono tolti dallo spillone e messi sul bancone del pizzaiolo o in cucina sono in corso di lavorazione.
Gli ordini completati vengono rimossi dal sistema.

2. Limitazione del lavoro in corso

Il numero massimo di foglietti che lo staff può gestire contemporaneamente è limitato dalla capacità operativa della cucina. Se la pila dei foglietti cresce troppo, il sistema segnala un sovraccarico e suggerisce la necessità di gestire meglio la capacità o rallentare l’accettazione di nuovi ordini.

3. Gestione del flusso

I foglietti si spostano lungo un percorso implicito:

Ingresso: L’ordine viene preso dal cameriere e aggiunto allo spillone.
Elaborazione: Il pizzaiolo o la cucina preparano i piatti in ordine di arrivo.
Uscita: Una volta completato, l’ordine viene servito e il foglietto viene eliminato.

4. Feedback immediato

Lo spillone offre feedback istantaneo sullo stato del lavoro:

Se il numero di foglietti aumenta rapidamente, è chiaro che c’è un collo di bottiglia.
Se la pila si riduce o si svuota, il flusso sta funzionando in modo ottimale.

Vantaggi del sistema

Semplicità: Non richiede tecnologia avanzata o competenze tecniche.
Trasparenza: Tutti i membri dello staff possono vedere lo stato degli ordini.
Adattabilità: Si adatta automaticamente alla capacità della cucina.
Miglioramento continuo: I dati visivi sul flusso di lavoro aiutano a identificare e risolvere i problemi.

Conclusione

Uno spillone porta comande in una pizzeria è un esempio tangibile di come i principi del Kanban possano essere applicati in qualunque contesto di servizi. Questa semplicità dimostra che i metodi di gestione visuale del lavoro possono migliorare l’efficienza e la trasparenza ovunque ci sia un flusso di lavoro, dalla cucina di una pizzeria a un team di sviluppo software. Una lezione preziosa per chiunque desideri ottimizzare i propri processi!

Pillole di Kanban applicato: non servono eroi, servono risk manager

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.

Applicare il metodo Kanban è anche questo: accettare di essere antieroi, non a caso la leadership a livelli alti del Kanban Maturity Model prevede il valore essenziale dell’umiltà.

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.

immagine Wikimedia, clicca qui per i crediti

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

Come funziona Kanban: la gestione proattiva dei rischi

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.

Come funziona Kanban: gestire le dipendenze esterne con le classi di dipendenza

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

E’ bene ricordare che quando nei sistemi Kanban si parla di ‘priorità’ si intende ‘classe di servizio’, concetto correlato con il ‘costo del ritardo’, ovvero quanto costa all’organizzazione posticipare la lavorazione di quell’elemento di lavoro, nel nostro caso il ticket.

La priorità aumenta con il passare del tempo

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.

Poster riassuntivo della gestione delle dipendenze, disponibile sul sito Kanban+ della Kanban University

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.

Una trattazione più articolata e dettagliata delle classi di dipendenza la potete trovare sul portale Kanban+ della Kanban University, cliccando qui.

Come funziona Kanban: l’agilità aziendale vera è posticipare le decisioni, ma non troppo

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.

Il primo passo è limitare il Work in Progress (WIP), per ridurre la variabilità e migliorare la prevedibilità del flusso di lavoro, rendendo la pianificazione più realistica e gestibile. Una volta che il sistema è stato reso stabile e prevedibile, la metrica del Lead Time osservato in passato per i tipi di lavorazione simili permette di decidere quanto prima è necessario iniziare un determinato lavoro per consegnarlo in tempo. Il Lead Time non è un numero, ma una distribuzione di probabilità, per cui si ragiona in termini di confidenza statistica e di rischio di coda, concetti per i quali rimando a un precedente articolo che trovate qui.

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.

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.

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