Kanban, dall’idea alla pratica

Pizza al taglio, ossia Kanban nel negozio all’angolo

Nella pizzeria a taglio che ha aperto da poco in paese c’è un pizzaiolo esperto che, dopo molti anni di lavoro alle dipendenze di altri principali, ha deciso di mettersi in proprio. Useremo un nome di fantasia per questo simpatico ristoratore e nella migliore tradizione della pizza napoletana, lo chiameremo Antonio, per gli amici “Totò”.

Antonio, nel piccolo negozio ha messo un banco con una vetrina dove gli avventori possono ammirare le pizze appena sfornate già tagliate in fette o spicchi. Accanto alla vetrina c’è il bancone per le consegne e una piccola cassa.

Normalmente Antonio tiene in questa vetrina quattro o cinque tipi di pizza, scelte fra quelle più richieste dalla clientela. Il pomeriggio all’uscita della scuola vicina molti bambini si fermano coi genitori per fare merenda e per questo motivo una delle pizze più richieste è una specie di focaccia dolce farcita di cioccolata. La sera invece gli adolescenti preferiscono pizze dai sapori più forti, piccanti o magari qualche ricetta più dietetica.

Dietro il bancone Antonio ha installato una macchina spianatrice — con la quale, partendo da palle di pasta preparata manualmente, si formano le basi di pasta cruda — e un paio di forni elettrici per la cottura.

Antonio, da esperto pizzaiolo qual è, è in grado di sfornare sempre la giusta quantità di pizze per ogni tipologia, tanto che normalmente l’attesa media dei clienti è sempre molto ridotta.

Dalla “quattro stagioni” al Kanban

Il modo con cui Antonio gestisce la sua pizzeria è molto efficiente e vi si possono trovare applicati, magari in modo inconsapevole, alcuni principi della filosofia Lean nonché della metodologia Kanban. Innanzitutto, Antonio punta ad avere poche pizze pronte nella sua vetrina in modo che la clientela possa sempre degustare pizze calde appena sfornate, che si possano limitare gli sprechi a fine giornata e che sia possibile pianificare meglio la preparazione, anche se in questo modo deve continuamente controllare il flusso delle richieste della sua clientela.

In termini Lean potremmo dire che Antonio tende a ridurre al minimo le giacenze di magazzino, preferendo una produzione just-in-time per offrire sempre un prodotto di qualità.

“Tirare” la produzione: approccio pull

Il nostro pizzaiolo riesce a ottimizzare questo processo di lavorazione tramite quello che in Lean si chiama approccio pull alla produzione: non esegue alcuna pianificazione preventiva del quantitativo di pizze da fare né del loro tipo, ma valuta il livello del magazzino (il bancone) e in base a quello si mette a preparare o meno altre pizze. Nei momenti in cui non c’è molto da fare, quando per esempio il bancone è pieno e c’è poca clientela nel negozio, allora si mette a svolgere quelle attività non urgenti, che potremmo chiamare task a bassa priorità, come per esempio preparare le palle di pasta che poi andranno in frigorifero, oppure pulire il forno, oppure riposarsi.

Il suo obiettivo è fare in modo che sul bancone ci siano sempre tre o quattro pizze pronte: conoscendo il tempo necessario per far sì che una pizza sia pronta per essere messa in vendita, il cosiddetto lead time di processo, appena vede che le scorte scendono sotto un certo quantitativo, si mette a preparare una nuova pizza.

È quindi il flusso dei clienti che comprano le pizze ossia il ritmo di svuotamento del magazzino, che determina il processo di lavorazione: in gergo si dice che il processo viene tirato (“pull” in inglese) dal fondo.

“Spingere” la produzione: approccio push

Se Antonio applicasse un processo opposto (push), si concentrerebbe sulla produzione delle pizze cercando prima di tutto di immaginare quante ne riuscirebbe a vendere: in questo caso la sua unica preoccupazione sarebbe quella di “spingere” la produzione dal forno verso il bancone e quindi verso la bocca dei clienti, in modo da non accumulare troppe pizze pronte per essere infornate. Per perseguire questo approccio, dovrebbe fare molta attenzione alla pianificazione e controllare accuratamente l’organizzazione del suo processo di lavorazione, valutando in particolar modo i vari “colli di bottiglia” della produzione: il forno, la preparazione delle palle di pasta, il bancone…).

Antonio sa che questo lavoro di controllo e pianificazione è indubbiamente più complicato, sicuramente meno efficiente dell’altro (pull); inoltre a fine giornata qualche spreco lo si avrebbe sempre.

Prioritarizzare le attività: task lenti, task bloccanti, task poco importanti

Antonio nella sua piccola bottega mette in atto anche altri principi tipici della produzione snella. Egli infatti lavora da solo, anche se in quel negozio ci sono un paio di forni e una sola pressa che spiana le palle di pasta per la pizza.

Questa configurazione non è casuale. La macchina pressatrice infatti svolge un compito molto semplice e piuttosto rapido che dura solo pochi secondi. Il forno invece è probabilmente la fase della lavorazione più lunga dato che per cuocere una pizza sono necessari circa 8 minuti a seconda del tipo di pizza. Per questo motivo, nella stanza una pressatrice è più che sufficiente mentre un solo forno avrebbe creato code in attesa. In realtà dopo qualche tempo Antonio si è potuto permettere un forno più grande, in grado di cuocere fino a dieci pizze contemporaneamente, cosa che, di fatto, permette non solo di velocizzare il tempo di preparazione di una singola pizza, ma di eliminare ingolfamenti in entrata al forno. In questo modo Antonio può smettere di preoccuparsi della gestione delle varie fasi intermedie e concentrarsi sull’unico punto veramente importante: il numero di pizze pronte ed esposte nella vetrina.

Priorità e lotti di lavorazione

Una cosa che però continua a gestire con la massima attenzione è la fase più delicata della lavorazione, la cottura: essendo la fase più lunga dell’intero processo, è molto importante non sottovalutarla. Per questo motivo egli spesso sacrifica altre fasi della lavorazione: sia che stia guarnendo una base di pasta, sia che stia servendo un cliente, spesso si interrompe per infornare o per togliere una pizza pronta (task lento ad alta priorità perché bloccante sugli altri).

In realtà Antonio gestisce quest’alternanza, per esempio fra il servire un cliente o interrompersi per infornare una pizza, in modo estremamente attento; come ogni commesso che lavora al pubblico, conosce bene il valore di ogni singola fase del suo lavoro: per esempio interrompere il condimento di una pizza ha un impatto diretto solo sul processo di lavorazione. Sospendere momentaneamente il servizio di un cliente è invece una cosa che potrebbe costare un prezzo maggiore in termini di immagine o di soddisfazione della clientela.

Dato che sa intrattenere con simpatia i propri clienti, può permettersi di interrompere il servizio al bancone per cuocere una pizza; Antonio sa che però può farlo solo per pochi istanti e per dedicarsi quindi ad attività di breve durata. Se per esempio decidesse di seguire la lavorazione di cinque pizze per volta, tutte le fasi sarebbero più impegnative in termini di tempo e quindi anche le interruzioni al servizio al bancone diventerebbero intollerabili per la clientela. Antonio sa quindi che il trucco è gestire lotti di lavorazione piccoli, per esempio una pizza per volta.

Buffer

Ricapitoliamo velocemente la maggior parte delle scelte fatte da Antonio nel gestire il suo negozio: approccio pull, piccoli lotti in produzione, fasi di lavorazione a durata differente, brevi momenti di interrruzione per infornare pizze crude e successivamente per sfornare pizze cotte, e così via. Tutte queste attività sono possibili anche grazie a una soluzione importante: la vetrina delle pizze pronte, che in termini Lean potrebbe essere definita come una specie di buffer in grado di assorbire gli sbalzi del processo di lavorazione o di domanda, se per esempio entrano più persone del previsto nel negozio a comprare le pizze.

La dimensione di tale buffer — il numero di pizze cotte esposte nel bancone — è molto importante: un buffer troppo piccolo (poche pizze pronte per la vendita) rischia di non lasciare tempo per mettersi alla preparazione di nuove pizze; se il buffer invece è troppo grande il pericolo è quello di preparare troppe pizze rispetto alla reale domanda della clientela.

L’esperienza e la maestria di Antonio, permettono di utilizzare un dimensionamento variabile di questo “tampone”: la catena è estremamente ridotta per cui un solo buffer in fondo alla linea di lavorazione è in grado di stabilizzare tutta la catena. Come si avrà modo di vedere, quasi tutti i processi di produzione si avvalgono di uno o più stazioni di parcheggio, o buffer, in modo da stabilizzare e quindi ottimizzare il flusso di lavorazione.

Limitare il numero di attività svolte in parallelo

Oltre al dimensionamento della vetrina da esposizione (il buffer), fra le varie cose che Antonio ha imparato a pianificare con l’esperienza, è il numero delle cose che il suo negozio riesce a fare in parallelo.

In passato si è avvalso della collaborazione di alcuni aiutanti che aveva chiamato per aumentare la produzione in concomitanza di determinati picchi di produzione. Sebbene questo abbia permesso aumentare il numero di pizze in lavorazione, ha anche messo in luce alcuni limiti strutturali del laboratorio di Antonio. Spesso si creavano “ingorghi” durante la lavorazione delle pizze, per esempio in entrata del forno o peggio ancora sul bancone della vetrina, oppure non si riusciva a produrre il giusto quantitativo di pizze per minimizzare gli avanzi (pizze fredde non più vendibili).

A rotazione, ai vari addetti alla lavorazione capitava di rimanere in attesa che un collega finisse un altro lavoro: spesso tale attesa era dovuta alle troppe cose che i colleghi dovevano fare. L’idea che iniziò a farsi strada nel laboratorio è che più cose ognuno faceva in parallelo, più alta era la probabilità di bloccare i colleghi: se fossero stati in tanti nel piccolo laboratorio, avrebbero rallentato più persone in un colpo solo.

Una frase che spesso viene utilizzata per spiegare la filosofia lean e le metodologie basate su kanban è proprio questa: “Your multitasking is my bottleneck”, vale a dire che fare tante cose tutte insieme non è affatto un vantaggio, ma anzi va a creare degli intoppi, dei “colli di bottiglia”

Colli di bottiglia

Col tempo Antonio si è reso conto quindi che, sebbene fosse possibile aumentare nominalmente la produzione, la presenza di colli di bottiglia nel processo portava a un complessivo abbassamento delle prestazioni tanto da vanificare gli sforzi fatti per aumentare la produzione, aumentando invece i costi e gli sprechi.

WIP limit e kanban card: alcune storie di esempio

Abbiamo utilizzato l’esempio del “pizza a taglio” di Totò per illustrare alcuni concetti tipici della produzione snella nell’ambito di un contesto semplice e comprensibile a tutti: chi non è stato in una pizzeria del genere?

Eppure tutti quei semplici concetti sono l’esatta dimostrazione di alcuni dei principi base della produzione snella e di Kanban in particolare: flusso di produzione, approccio pull, task bloccanti, diversificazione della durata delle attività, interruzioni, priorità, colli di bottiglia, limite di attività svolte in parallelo (WIP limit, vale a dire limite sui Works In Progress contemporaneamente) e così via. Prima di passare ad analizzare quindi la teoria alla base di Kanban, conviene vedere un altro paio di esempi dal mondo reale che vanno oltre la pizzeria di Antonio.

Parcheggiare l’automobile

C’è uno scenario completamente diverso, ma molto esplicativo, che quasi tutti avranno vissuto in prima persona: lasciare l’auto in un parcheggio a pagamento in cui entrata e uscita siano regolati da sbarre automatiche, sistemi di pagamento e, soprattutto, posti limitati e numerati.

Se il numero di automobilisti che desiderano parcheggiare è ben al di sotto della capienza del parcheggio, in genere nessuno si accorge del meccanismo che regola il parcheggio stesso: si arriva, si preleva un biglietto alla macchinetta, la sbarra si alza e si procede verso un posto libero.

Se invece il parcheggio ha raggiunto la capacità massima, normalmente all’entrata si formano delle code di auto in attesa di poter entrare nel parcheggio. In questo caso, essendo il numero di posti disponibili limitati dalla capienza massima del parcheggio, per ogni automobilista che lascia il parcheggio si libera un posto per la vettura di un altro che vuole entrare.

Questa organizzazione è possibile perché un semplice contatore tiene traccia delle auto che entrano e di quelle che escono e blocca il rilascio di nuovi biglietti quando si arriva a un certo limite.

Visitare il giardino del Palazzo Imperiale

Tale sistema si basa su un meccanismo inventato molti anni fa presso il parco del Palazzo Imperiale giapponese: in primavera infatti moltissime persone accorrono per poter assistere al bellissimo spettacolo della fioritura dei ciliegi; per garantire l’armonia e la bellezza del parco è necessario limitare il numero di visitatori contemporaneamente presenti nel giardino, cosa che fin dai tempi antichi viene ottenuta con un meccanismo estremamente semplice ma altrettanto efficace.

Pur essendo l’ingresso al parco gratuito, all’entrata ogni visitatore deve prelevare da un contenitore un “gettone”, una tessera visuale: questo è il significato del termine giapponese kanban (scritto con la “k” minuscola) che vuol dire appunto, “cartellino”, “tessera” \[4\]. In inglese si parla di kanban cards che, in casi come quelli del giardino, possono essere oggetti realizzati con cura dagli artigiani di un tempo.

Il visitatore deve tenere con sé questa tessera per tutto il tempo in cui rimane dentro il parco. Quando esce, dovrà riporre la sua kanban nel contenitore apposito. Quando non ci sono tessere kanban nel contenitore, nessun visitatore può più entrare nel parco: avere la tessera in mano è la condizione per poter entrare. Non appena qualcuno esce, depone il suo “gettone” kanban e un altro visitatore può riceverlo ed entrare a sua volta. Semplice. Lineare. Ripetibile.

Questo aneddoto, raccontato fra gli altri da D.J. Anderson nel suo famoso libro su Kanban \[2\], è probabilmente la dimostrazione più semplice di molta parte della pratica di Kanban (con la “K” maiuscola), intesa come particolare metodologia Lean per la gestione dello sviluppo del software, che ben si integra le pratiche Agile in genere. Avremo modo di ritornare su questi concetti.

Le code in autostrada

Un’altra esperienza che in qualche modo si poggia sugli stessi concetti teorici di Kanban e che ogni lettore vive più o meno regolarmente è quella di percorrere in automobile un tratto di una autostrada o di una superstrada. Un fenomeno piuttosto ovvio che si può sperimentare in questo caso è che maggiore è il numero di auto che percorrono quel tratto, minore sarà la velocità con la quale si potrà percorrere quel tratto, ovvero maggiore è la probabilità che si formino dei rallentamenti.

Un fatto forse meno intuitivo, ma strettamente collegato al precedente, è che aumentando la velocità consentita su quel tratto di strada, maggiore sarà la probabilità che si formino rallentamenti o ingorghi nei vari tratti di strada. Detto in altro modo, in corrispondenza di elevati volumi di traffico, abbassare la velocità di percorrenza — per esempio imponendo un limite di velocità più basso — permette di percorrere un determinato tratto di strada a una velocità costante senza rallentamenti o intoppi e quindi di raggiungere la propria destinazione in tempi minori.

Nella maggior parte dei sistemi di lavorazione, quella che empiricamente si potrebbe definire come la capacità di processo è funzione di una serie di fattori fra cui si trova la capacità massima di canale (per esempio il numero massimo di auto che possono transitare per un tratto di strada), il grado di variabilità all’interno del processo stesso (ossia se c’è molta differenza fra le varie fasi di lavorazione in termini di tempo di lavorazione), la definizione ottimale di “aree di parcheggio” all’interno del processo (vedi l’esempio del banco-vetrina della pizzeria) e altro ancora.

In un processo pull, “spingere” non è la soluzione

Un errore tipico che si commette quando si desidera aumentare le prestazioni del sistema è quello di “spingere” su tutte queste variabili con la speranza che le performance complessive migliorino. Purtroppo, come avremo modo di vedere, oltre un certo limite, la risposta del sistema va nella direzione opposta.

Di questi aspetti si era accorto anche Deming il quale, come già accennato nella serie di articoli “Verso Agile” (vedi \[3\] e articoli successivi), nei suoi studi affermava che la migliore performance di un sistema complesso non si ottiene spingendo al massimo ogni componente del sistema, ma trovando una corretta configurazione fatta anche di parti che lavorano ben al disotto della potenza nominale massima.

Avremo modo di formalizzare meglio questi temi quando parleremo di teoria delle code, del teorema di Little e dell’effetto Forrester. In questo primo articolo iniziamo con l’introdurre i concetti di base di Kanban rimandando alle puntate successive gli approfondimenti sulle tecniche e sull’utilizzo nella pratica di progetto.

Breve storia di Kanban

Verso l’inizio degli anni Quaranta del secolo scorso, gli ingegneri di Toyota stavano lavorando all’ottimizzazione dei propri processi di produzione. Taiichi Ohno, anche prendendo spunto dal lavoro di Deming, lavorava duramente per introdurre nuovi principi di quella che sarebbe diventata poi la produzione snella \[1\] \[3\].

Una delle fonti che dette maggior ispirazione a Ohno arrivò da un settore inaspettato, quello della grande distribuzione alimentare. In quel periodo stavano nascendo i primi supermercati dentro i quali i commessi e gli addetti al rifornimento del magazzino dovevano trovare soluzioni ottimali proprio per gestire merci con un così alto tasso di degradazione: un cesto di insalata impiega meno tempo per perdere di “freschezza” rispetto a quello necessario a un modello di automobile per diventare obsoleto…

In quel caso, il flusso di approvvigionamento era guidato dal livello di approvvigionamento a scaffale: solo quando l’ultimo elemento di un certo prodotto era prossimo alla vendita si procedeva al riordino, non prima. Furono quelli i primi esempi di gestione just-in-time, che ispirò i manager giapponesi della Toyota nel mettere a punto un nuovo processo di approvvigionamento. Tramite la gestione in tempo reale dei flussi di entrata e di uscita dei prodotti, riuscirono a migliorare le prestazioni complessive del sistema: stava nascendo un metodo basato su kanban.

kanban: un segnale visivo

Il principio che animò questo processo di trasformazione è descrivibile con un semplice slogan: “migliorare la comunicazione tramite una gestione visuale del processo”.

La parola kanban infatti deriva dalla composizione delle parole kan (“visivo”, “visuale”) e ban (“segnale”) e infatti buona parte della metodologia quando fu creata, faceva uso di cartellini visuali e di lavagne dove questi cartellini erano attaccati per monitorare gli stati di avanzamento della produzione, l’approvvigionamento, l’acquisto o la movimentazione dei materiali.

Il sistema infatti in modo estremamente naturale stimolava il confronto e il dialogo all’interno del team, velocizzando lo scambio delle informazioni e agevolando quindi il processo decisionale sul cosa e come organizzare il lavoro. Fra gli obiettivi che Ohno e il suo staff si dettero durante il lavoro di messa a punto di Kanban, vi era quello di evitare la sovrapproduzione delle merci in entrata o dei prodotti finiti in uscita che, in ottica Lean, erano considerate fra le forme di spreco più impattanti sulle performance di un sistema produttivo.

Kanban come metodologia di gestione e controllo.

A partire dal 2007 Kanban (con la “K” maiuscola per distinguerlo dal cartellino) è stato introdotto come metodologia di gestione e controllo dello sviluppo del software grazie al lavoro di David J. Anderson, il quale si è ispirato ai principi del Lean e del Toyota Production System messo a punto da Ohno in oltre venti anni di lavoro \[3\]. Anderson ha formalizzato le sue idee in un libro \[2\] pubblicato nel 2010.

Caratteristiche di Kanban

Nel suo lavoro, Anderson analizza i principi della produzione snella e, sulla base di esperienze personali e di confronti con metodologie di gestione sperimentate, ha messo a punto la sua visione di come certi principi Lean si possano adattare alla gestione dello sviluppo software, integrandosi nel più ampio quadro delle metodologie agili.

I cinque aspetti fondamentali

Nel libro, Anderson ha sintetizzato in cinque punti gli aspetti più importanti di Kanban:

• visualizzare il flusso di lavoro: dare una rappresentazione visiva del processo di lavorazione, ponendo in risalto, per ogni step del processo complessivo, il valore prodotto;

• limitare il Work-in-Progress (WIP): porre dei limiti espliciti sul lavoro complessivo eseguibile all’interno di ogni fase della lavorazione;

• misurare e gestire il flusso: misurare e gestire il flusso per avere sempre informazioni attendibili e poter quindi prendere decisioni coerenti col sistema; per ogni azione intrapresa, visualizzare sempre le conseguenze;

• rendere esplicite le politiche di processo: definire e condividere con tutti gli interessati le regole a cui processo e stakeholder devono attenersi è il modo più semplice ed efficace per garantire il miglioramento delle prestazioni, la riduzione degli sprechi, l’ottenimento degli obiettivi;

• identificare le possibili opportunità di miglioramento: creare nell’organizzazione una cultura in cui il continuo miglioramento del sistema, del processo e delle performance siano obbiettivi condivisi in tutti i membri della comunità; in giapponese, tale cultura del miglioramento continuo è nota con il nome di kaizen.

Tre regole importanti

Questi cinque punti possono essere considerati i cinque obiettivi fondamentali che dovrebbero essere perseguiti tramite tre regole importanti, che sono alla base di Kanban:

• usare gli strumenti di cui si è già in possesso: partire da quello che si sa fare senza aspettare di avere imparato cose nuove;

• condividere un percorso di cambiamento che abbia come obiettivo la crescita e l’evoluzione dell’organizzazione;

• rispettare l’organizzazione attuale: il processo di cambiamento ed evoluzione non deve imporre stravolgimenti drastici nel processo, modifiche traumatiche nei ruoli e nelle persone, ma introdurre le novità in modo graduale e compatibile con le necessità e gli obiettivi; per questo sono così importanti la visualizzazione del processo, la misurazione, la definizione esplicita delle policy.

Molte delle indicazioni fin qui viste sono prese per la maggior parte dai principi del Lean che Kanban sposa in pieno: si potrebbe quasi dire che l’obiettivo principale di Kanban è quello di funzionare come attivatore dei principi Lean all’interno dei sistemi di produzione del software.

Come abbiamo già accennato, occorre sempre essere consapevoli della differenza tra Kanban con l’iniziale maiuscola (la metodologia sviluppata da D.J. Anderson) e kanban con l’iniziale minuscola (il cartellino segnalatore utilizzato inizialmente nel Toyota Production System). In tal senso le parole di D.J. Anderson sono particolarmente esaustive: “…Kanban (con la ‘K’ maiuscola) è il metodo di cambiamento evolutivo che utilizza un sistema pull basato su kanban (con la ‘k’ minuscola), sulla visualizzazione dei flussi e su altri strumenti per catalizzare l’introduzione di idee Lean all’interno del mondo dello sviluppo tecnologico e delle attività IT”.

Conclusioni

Attraverso un certo numero di esempi relativi ad attività quotidiane e facilmente comprensibili, abbiamo introdotto un’analisi dei principali aspetti affrontati dai sistemi di gestione delle attività basate su principi Lean.

Abbiamo poi raccontato brevemente la storia dei cartellini kanban introdotti inizialmente nel Toyota Production System e di come molti dei principi Lean utilizzati nella produzione industriale siano stati introdotti e adattati al mondo della gestione dello sviluppo del software, grazie al metodo Kanban, messo a punto da D.J. Anderson a partire dalla fine del decennio passato.

Nei prossimi articoli affronteremo la metodologia Kanban sul piano pratico, illustrandone pratiche e strumenti.

Riferimenti

• \
• [1\] Womack J.P. - Jones D.T. - Roos D., "The Machine That Changed the World: The Story of Lean Production", Harper Business, 1991 (trad. it. "La macchina che ha cambiato il mondo", Rizzoli 1999)

• \
• [2\] David J. Anderson, "Kanban: Successful Evolutionary Change for Your Technology Business", Blue Hole Press, 2010

• \
• [3\] Giovanni Puliti, “Verso l'Agile - I parte: L’importanza dell’apprendimento”, MokaByte 188, ottobre 2013

http://www2.mokabyte.it/cms/article.run?permalink=mb188_VersoAgile-1

• \
• [4\] Francesco Saliola, “Kanban: agile o no? - Qualche riflessione su una questione dibattuta”, MokaByte 190, dicembre 2013