Dopo aver visto negli articoli precedenti gli elementi fondamentali di Kanban e il modo in cui si progetta e usa una Kanban board, è giunto il momento di vedere come creare una board che rappresenti il flusso di lavoro dell‘organizzazione che si deve gestire. È uno strumento che, se impostato nel modo giusto, si rivelerà davvero potente e utile.
Mappare il workflow
Abbiamo visto come è fatta una lavagna Kanban, e ancor prima avevamo introdotto i principi “filosofici” Lean su cui tale strumento si basa. Con una Kanban board ben fatta, possiamo monitorare il processo della struttura entro la quale ci muoviamo.
Ma, per svolgere questo compito, diverse sono le tecniche che si possono mettere in pratica: in questo articolo sono proposte alcune possibili soluzioni, quelle a disposizione. La maggior parte dei suggerimenti qui presentati sono il frutto di esperienza diretta sul campo, ma non vanno certo considerate come le sole possibili: possono anzi essere utilizzate in combinazione con le molte altre che si possono reperire sui numerosi libri e articoli a riguardo del tema.
La prima cosa da fare, comunque, è dare una chiara definizione del flusso del processo, del workflow, cercando di capire cosa sta dentro e cosa sta fuori.
Input, output e le altre interfacce
Mappare un processo di produzione tramite una Kanban board è un lavoro che può essere svolto iterativamente in modo incrementale, aggiungendo ad ogni passaggio un dettaglio o una nuova parte.
Il primo passaggio è quello di individuare anche in modo macroscopico il contorno del sistema che si vuole modellare. In questa fase non è importante definire i dettagli di ogni fase della lavorazione, ma ci si può limitare a disegnare il processo tramite una black box in cui siano definite le interfacce di input e di output rispetto a sistemi esterni.
Si procede quindi a identificare i contorni del sistema: il risultato finale dipende per ovvie ragioni dal livello di dettaglio con cui si vuole descrivere il processo stesso e dal focus su cui concentrare l’attenzione. Ciò che in qualche modo partecipa alla realizzazione del prodotto finito può essere considerato come parte integrante del sistema o come elemento esterno con il quale il sistema deve solamente comunicare, per esempio per completare alcune fasi della lavorazione intermedie al flusso complessivo.
In questa fase ci si può avvalere di strumenti grafici piuttosto semplici come un diagramma di flusso o un diagramma di stato UML (figura 1).
Figura 1 – Si definisce un primo modello sintetico del processo.
Value Stream Mapping
Volendo utilizzare qualcosa in grado di fornire informazioni più approfondite, si potrebbe utilizzare la tecnica del Value Stream Mapping, che permette da un lato di identificare il flusso di una determinata lavorazione, dall’altro di comprendere quali sono i punti dove si genera valore, che diverranno quelli su cui porre maggior attenzione nel processo di controllo tramite la Kanban board.
Disegnare la board
Dopo aver disegnato schematicamente il workflow, la realizzazione della Kanban board, almeno in una sua prima rappresentazione approssimativa, è piuttosto semplice: ogni passaggio può essere rappresentato da una colonna della board.
Figura 2 – Dal workflow alla board.
Il livello di dettaglio della board dipende spesso dal grado di precisione che si vuole utilizzare per monitorare lo stato di avanzamento del processo di lavorazione: si potrebbe passare da un generico ToDo, Doing, Done (dove il Doing rappresenta tutto il processo di lavorazione nel suo complesso) a qualcosa di più specifico in cui si inserisce una colonna per ogni microfase della lavorazione.
Figura 3 – Cambia il livello di dettaglio del workflow, cambia la grana della board.
Ovviamente qualcuno si starà chiedendo: “Va bene scomporre in sottofasi il grosso della lavorazione. Ma fino a che punto mi posso spingere nel suddividere il processo?”. La domanda è leggittima e la risposta è basata sul buon senso: occorre creare ulteriori passaggi nel flusso solo se questi step in più aiutano a dettagliare il processo, ma non creano confusione. Attenzione, infatti, ai flussi troppo complessi, e che finiscono per dettagliare in maniera eccessiva: questi sono pericolosi per la produttività. C’è anche una indicazione di massima a proposito, che dice di tener presente quante volte un determinato passaggio si ripete nel tempo: se è un caso isolato, che capita soltanto in poche occasioni, non è assolutamente il caso di mapparlo negli step riportati sulla Kanban board.
Mappare la realtà del processo, non una sua rappresentazione ideale
Quando si mappano gli step del processo, che si voglia realizzare una Kanban board oppure che si desideri semplicemente farsi un’idea del flusso della lavorazione, conviene sempre rifarsi allo schema reale, quello effettivo, e non quello “ideale” che viene riportato in qualche documento ufficiale e che magari viene utilizzato per una qualche presentazione ufficiale.
Sembra questa una raccomandazione superflua ma capita spesso che il processo realmente messo in atto sia differente da quello concordato sulla carta in fase di progettazione: anche il solo ammettere questa “violazione” può rappresentare un problema “politico” all’interno dell’organizzazione, specialmente nei confronti di chi aveva autorizzato la versione ufficiale e non è al corrente delle eventuali differenze; la situazione potrebbe essere ancora più delicata qualora il processo sia affetto da colli di bottiglia, rallentamenti, inefficienze.
Grazie alla sua capacità di fornire visivamente una rappresentazione statica, ma anche dinamica, dell’organizzazione, una Kanban board è estremamente efficace nel mettere in luce pregi e difetti del processo: non sempre tutte le persone possono sentirsi a proprio agio con uno strumento che evidenzi in modo così diretto eventuali inefficienze nell’organizzazione. Per questo si consiglia sempre di coinvolgere tutte le persone, di effettuare interviste, di condividere i risultati cercando di evitare che uno strumento di aiuto diventi la causa di attriti e di conflitti all’interno dell’organizzazione.
Migliorare la board: dettagliare le colonne
Dopo aver completato la definizione della prima versione della board, si può provare a fare qualche modifica per vedere di renderla più utile e realistica. Le due macroaree di intervento sono la gestione delle attività in concorrenza (WIP) e la definizione delle aree di parcheggio (i cosiddetti buffer). Di seguito sono analizzati entrambi questi aspetti.
Gestione della concorrenza: il limite WIP (Work In Progress)
La prima modifica che si può fare al fine di rendere la board più realistica è inserire i controlli sul numero di attività che potranno essere svolte in parallelo all’interno di ogni fase della lavorazione.
Sebbene si sia più volte si è sottolineato come lo svolgimento di più attività in parallelo porti a un abbassamento delle performance, prima di introdurre restrizioni in tal senso, può essere utile provare a raccogliere informazioni sullo stato attuale della lavorazione. Tramite semplici domande, rivolte a chi lavora nelle varie fasi del processo, si potrà delineare un quadro il più possibile veritiero.
Questa indagine dovrebbe essere impostata in modo analitico, cercando di non spostare la discussione su aspetti competitivi e prestazionali: “riesco a fare 3 attività in contemporanea, ma se mi impegno riesco a farne anche 4 insieme”. Poi, bisogna anche considerare le differenze tra le varie attività: un idraulico riesce normalmente a montare un rubinetto alla volta, un programmatore riesce in genere a sviluppare solo su una feature alla volta. Però il responsabile vendite può anche gestire tre o quattro clienti in una stessa fase…
Partendo dall’analisi dei dati empirici, quando si procede ad assegnare i valori al limite di lavorazione per le varie fasi del processo, si possono utilizzare valori che si reputano ragionevoli, anche senza disporre di alcun il supporto teorico.
Uno strumento per raccogliere informazioni
Un modo per condurre la raccolta delle informazioni sulle attività che il team svolge in parallelo è tramite dei lavori di gruppo, in cui si chiede di simulare il normale processo di lavorazione. Per esempio di potrebbe organizzare un workshop con varie fasi.
In una prima fase, si “ripassa” quel che è successo: si prende come esempio un compito completato da poco (in genere rappresentato da un cartellino che è finito nella colonna “Done”). Attraverso il confronto tra i vari membri del gruppo che ci hanno lavorato sopra, si cerca di ripercorrere sulla Kanban board le “tappe” che questo cartellino ha fatto per arrivare a destinazione.
La domanda da farsi a questo punto è di capire quanto tempo ci ha messo l’attività per arrivare allo stato di “completata”. Immaginiamo, per semplicità, che ci siano voluti 5 giorni completi (la teorica “settimana lavorativa”). Questi 5 giorni saranno definiti come “tempo di ciclo” del cartellino-compito.
Giunti alla terza fase, si chiederà a ciascuna persona che ha lavorato a quel cartellino di dire quanto tempo effettivo ha impiegato per lavorare su quell’attività. E qui vengono spesso fuori numeri molto più bassi del tempo di ciclo. Sommando il lavoro dei vari membri del team, magari salterà fuori che il tempo effettivo è stato solo di 8 ore. Ma allora perchè ci sono voluti 5 giorni per finire quel lavoro? Le ragioni possono essere varie, ma una delle principali è rappresentata dalle code di attesa. Magari, dopo che una prima fase di lavoro è stata completata, quel cartellino ha dovuto attendere un giorno e mezzo prima che qualcun altro lo potesse raccogliere per lavorare alla seconda fase del processo, e si è trascinato così, fino ad arrivare alla colonna Done dei lavori completati solo alla fine del quinto giorno. Non è strano, anzi è quasi “normale”, che l’80% del tempo di ciclo di un cartellino sia trascorso semplicemente in attesa. Lo scopo dei limiti WIP sui compiti che si possono svolgere in contemporanea è proprio questo: mantenere quanto più corte possibili le code di attesa, in modo tale che alla fine i cartellini si spostino più velocemente lungo la lavagna, perchè il flusso del processo scorre più veloce.
È chiaro quindi che il passo successivo deve essere per il team nel suo insieme di identificare tutte le code che sono presenti all’interno del processo con cui lavora: ci si renderà conto che le code nascono in genere nei momenti in cui si passa il lavoro da uno all’altro componente del team. Per lavorare alla riduzione delle code, sarà bene anche valutarne la portata: ci sono code minori e code di attesa che assumono dimensioni notevoli. È proprio su queste ultime che bisogna concentrarsi per prime.
La quinta fase è quella in cui finalmente si cominciano a mettere dei limiti al Work In Progress sulle colonne, in maniera da ridurre la lunghezza delle code di attesa, partendo sempre da una di quelle più grosse. Un aspetto importante da capire è che il limite WIP non va messo automaticamente sulla colonna che ha la coda più grande al suo interno, perchè potrebbe darsi invece che tale limite vada messo nella corsia precedente o anche in quella successiva… La coda in una colonna “figlia”, poi, potrebbe derivare in realtà da attività di livello più elevato in una colonna “madre” e questo va studiato con accortezza.
Oltre a porre limiti WIP sulle colonne del processo, si può pensare di adottarli in casi particolari anche per le persone: ci sono dei componenti del team che, per il loro tipo di competenze o per il ruolo che ricoprono nell’organizzazione del workflow potrebbero trovarsi sovraccarichi di cose da fare. È bene allora stabilire dei limiti WIP per derterminate persone: “Alberto avrà un limite WIP pari a 3: potranno essergli assegnate solo un massimo di tre attività da svolgere in parallelo”. Resta preferibile lavorare con i limiti WIP sulle fasi del workflow ma, nei casi di persone sempre sovraccariche, è sensato anche applicarli alle persone.
Scontrarsi con il WIP limit
Ma che succede quando arriva nella situazione in cui si rischia di sforare con il limte WIP? La cosa migliore da fare è fermare il lavoro che si aggiunge a quella coda e che costituirebbe “l’infrazione” e continuare invece a svolgere le attività precedenti che devono fluire all’interno del processo. Va bene aiutare un collega a svolgere un lavoro senza che ciò faccia superare il limite WIP; va bene svolgere alcune commissioni collaterali; ma non va bene aggiungere altre code superando i limiti WIP in questo momento.
Alla ricerca del WIP migliore: il kaizen del parallelismo
Probabilmente i valori iniziali di WIP limit potrebbero non essere quelli ottimali: solo grazie alla sperimentazione e alla valutazione degli effetti si potrà trovare una configurazione ottimale, che consenta le migliori prestazioni del processo di lavorazione. Di volta in volta, quindi, ogni variazione della configurazione in uso (per esempio imponendo un abbassamento WIP Limit naturale) dovrà essere fatta misurandone sempre gli effetti sulle performance complessive. Essenziale quindi l’adozione di metriche che permetteranno di misurare in un senso o nell’altro gli effetti del cambiamento. Parleremo di metriche in un prossimo articolo.
Qualora il team sia disponibile a supportare (e sopportare) il lavoro di messa a punto del sistema, si potrà provare a definire un percorso di miglioramento condividendo gli obiettivi ma anche gli sforzi necessari per raggiungerli. In questo caso, per esempio, si potrebbe provare a “imbrigliare” il sistema, imponendo valori leggermente più bassi di quanto misurato, in modo da evidenziare eventuali colli di bottiglia o rallentamenti e ricavare quindi i punti su cui intervenire.
Con un team poco collaborativo e poco propenso alla sperimentazione, invece, sarà certamente più difficile installare valori stringenti di WIP Limit; e questo probabilmente non fornirà indicazioni utili per imparare e migliorare…
Quando si stabiliscono dei limiti WIP per ciascuna fase del processo, questi vanno scritti sulla Kanban board, in alto sulla colonna dello step di lavorazione a cui si riferiscono: tale esplicitazione del limite WIP consente a tutti di essere consapevoli di quel limite e dovrebbe spingere le persone a non superare quel numero di attività. Per fare le cose nel migliore dei modi, il team dovrebbe anche stabilire delle regole da applicare quando qualcuno, per qualsivoglia ragione, intenda superare il limite WIP: di solito si stabilisce che, in questi casi, si farà una riunione di gruppo per valutare se in effetti ci sono ragioni sensate per “trasgredire” il limite WIP.
Introduzione delle aree di buffer
Dopo aver disegnato le colonne della board e aver introdotto il concetto di limit per ogni fase del processo, un ulteriore passo verso il miglioramento potrebbe derivare dall’introduzione delle cosiddette colonne di parcheggio (in gergo, buffer columns), dove i ticket sono in attesa di essere messi in lavorazione nella fase successiva.
Fra i benefici derivanti dall’introduzione dei buffer c’è la possibilità di gestire le dipendenze con fasi esterne del processo: per esempio quando si deve attendere il completamento della lavorazione del ticket da parte di un esecutore esterno. In questi momenti, piuttosto che bloccare tutto il processo, conviene sospendere l’attività (“parcheggiare” il ticket) e dedicarsi ad altro. Eventuali valutazioni sulla durata della permanenza, sul numero di attività parcheggiate o su altre misurazioni, possono fornire interessanti indicazioni su come intervenire per migliorare il processo.
Un’altra benefica conseguenza derivante dall’uso delle colonne di buffer è riportata nel primo articolo di questa serie, quando si faceva l’esempio della pizzeria a taglio: in quel caso, la presenza di aree fisiche dove appoggiare parti semilavorate di pizza permetteva al pizzaiolo di portare a termine le varie parti della lavorazione senza blocchi o rallentamenti complessivi.
A cosa servono i “parcheggi”
Le colonne buffer permettono di bilanciare il carico di lavoro sulle varie fasi, dato che consentono di assorbire le eventuali variazioni sul flusso di richieste e quindi di stabilizzare l’intero processo. È bene ricordare che lo sbilanciamento del carico di lavoro è considerato una delle forme di spreco più costoso, tanto indurre Taichi Ohno (l’inventore del Lean) a dedicare a questo tema una delle tre M del Lean, il Mura (che in giapponese significa appunto “sbilanciamento”).
Per quanto visto fino a questo punto, sebbene non sia affatto semplice decidere quali siano i punti nel processo dove inserire efficacemente le aree di parcheggio, ossia colonne buffer nella Kanban Board, due possono essere le ragioni sensate che aiutano a tale scopo: nei punti critici del processo e in corrispondenza delle interfacce verso sistemi esterni.
Il secondo aspetto è in genere piuttosto semplice da gestire: in questo caso infatti i punti di intervento si possono individuare in modo piuttosto semplice guardando i punti in cui la lavorazione si arresta per attendere un output esterno, se il lavoro per esempio passa ad una qualche organizzazione esterna; o dove il processo richieda una pausa per motivi strutturali.
L’esempio tipico è quello in cui si stia attendendo un’autorizzazione dalla dirigenza: in questa situazione si può fare poco per velocizzare, però si possono separare questi task e misurare il tempo che hanno trascorso in attesa, su questa colonna. Nella situazione ideale, le colonne di buffer non dovrebbero servire, ma nella realtà sono molto utili, specie se messe nelle transizioni tra aree funzionali o sottoprocessi, come quando il marketing deve inviare una richiesta di acquisto all’area finaziaria.
Uno scenario più complicato
Più complicato può essere individuare i punti in cui sia necessario introdurre un buffer per gestire sia sbalzi di domanda e offerta che per assorbire le differenti velocità delle varie fasi della produzione: nell’esempio della pizzeria potrebbe essere la lievitazione della pasta.
Una buona strategia in genere è quella di definire una configurazione di partenza e poi operare per raffinazioni successive, trovando le giuste correzioni che diano i risultati migliori. Per definire il punto di partenza si possono scegliere tre diverse soluzioni:
- se possibile, provare a individuare i probabili punti critici;
- non preoccuparsi di identificare i punti critici ma inserire i buffer in ogni fase della lavorazione;
- non preoccuparsi di identificare i punti critici e non inserire alcun buffer.
La prima ovviamente è la più semplice quando si sa come intervenire e per questo spesso non è richiesta alcuna ottimizzazione successiva, mentre le altre sono strategie da cui partire per poi cambiare successivamente in funzione dei risultati ottenuti.
Definizione delle card
Parallelamente alla progettazione e al raffinamento della board, si può lavorare per la definizione dei cartellini corrispondenti ai task in lavorazione. Ogni card dovrebbe contenere tutte le informazioni significative relative all’attività da svolgere: dovrebbe essere presente un titolo che esprima in modo chiaro scopo e tipologia della attività, dovrebbe essere presenta l’owner o comunque il responsabile, una data di scadenza e ovviamente qualcosa che ne identifichi il valore, per esempio un qualche punteggio che ne esprima la priorità. Nello specifico si potrebbero inserire tutti i campi che descriviamo di seguito.
Titolo
Un buon titolo dovrebbe essere sintetico (una o due parole) scritto in grande (in modo che sia visibile anche da lontano) e dovrebbe essere sufficientemente chiaro e parlante, affinchè possa comunicare l’obiettivo dell’attività nonchè quale beneficio possa portare al sistema o a una persona specifica. Se necessario, si possono inserire ulteriori informazioni in un sottotitolo o in una descrizione.
Date di creazione e di completamento
Sono due campi molto importanti per capire l’età del cartellino, ovvero quanto tempo si sta impiegando per completare la lavorazione. Volendo raffinare le indagini si potrà contare anche il tempo che un cartellino passa nelle colonne di buffer in modo da arrivare calcolare il lead time e il cycle time: la differenza è un indice importante di quanto si possa ottimizzare il sistema. Ne parleremo in seguito. La data di completamento ovviamente va compilata a termine della lavorazione.
Deadline
La data ultima di completamento ammissibile.
Created by / owner
Chi ha creato il cartellino o meglio chi ne è il “proprietario“.
Priorità
La priorità si esprime con un numero o un codice che indica quanto sia urgente una data attività.
Segnalazione di impedimento (impediment warning)
A volte attività importanti rimangono bloccate a causa di impedimenti di vario tipo. Se il blocco dovesse protrarsi oltre un certo limite, si può attaccare alla card un qualche elemento distintivo (per esempio un pallino adesivo colorato di rosso) in modo da evidenziare che c’è un problema che rallenta o blocca del tutto la lavorazione di un elemento critico.
Tipologia di attività
Il Task Type è riferito sia alla classe di servizio che a una specifica tipologia di attività all’interno del processo (p.e.: analisi o sviluppo o altro).
Descrizione
Una breve spiegazione del lavoro da svolgere, degli obiettivi, dei benefici e dei beneficiari.
Note
Annotazioni varie, libere.
Requisiti per definire l’attività come completata
In Kanban, i Requirements for “Complete/Finished“ non sono nulla di diverso da ciò che Scrum si chiamano Acceptance Criteria, vale a dire un elenco di criteri che permettano di stabilire quando un’attività si possa considerare davvero completata.
Storia
La history è una serie di appunti sugli eventi che hanno caratterizzato l’attività in questione. Dalla data della prima immissione nel processo, al completamento, alla revisione e successiva re-immissione in lavorazione per correzioni di vario tipo; utile anche segnare l’elenco delle persone che hanno contribuito alla lavorazione della card.
Classi di servizio
Seguendo alla lettera i passi descritti fino a questo punto, si potrebbe arrivare a progettare una board utile per gestire lo stato di avanzamento delle attività in carico per esempio a un team di sviluppo, alla quale però mancherebbe ancora un passaggio importante: la gestione differenziata delle diverse tipologie di attività.
Nella realtà, infatti, raramente le attività che sono in carico a un gruppo di lavoro sono tutte uguali fra loro; alcune sono molto urgenti tanto che ogni minuto speso per la soluzione costa all’azienda molti soldi: si pensi a un bug bloccante in produzione.
Altre attività non hanno questo grado di urgenza ma possono essere messe in lavorazione se non ci sono urgenze da completare. Infine possono esserci attività la cui lavorazione potrebbe essere a bassissima priorità e quindi potrebbero essere lavorate solo quando non ci fossero altre cose da fare.
La classificazione delle attività potrebbe essere fatta anche in funzione di altri parametri, per esempio considerando la persona a cui andrebbe in carico la lavorazione.
In Kanban si parla di Classi di Servizio, per indicare che le attività verranno trattate in modo differente in funzione delle caratteristiche specifiche della attività stessa.
Identificare le classi di servizio
Per poter inserire le classi di servizio all’interno di una Kanban board, la prima cosa da fare è identificare le varie tipologie di attività che il team dovrà gestire. Per esempio si potrebbero considerare le seguenti attività tipicamente presenti all’interno di un progetto software:
- Implementazione di nuove funzionalità.
- Bug fixing a bassa priorità.
- Bug fixing ad alta priorità.
- Documentazione.
- Attività di formazione a supporto degli utenti.
- Setup ambienti e installazione software di supporto.
- Studio per realizzazione di prototipi.
Fatto questo si può provare a definire quali sono le esigenze di queste attività, per esempio valutando il Cost of Delay o eventuali SLA contrattualizzati o altro ancora.
Fatto questo si possono creare delle macrocategorie (dette appunto Classi di Servizio) dentro le quali far ricadere le varie attività. Ogni classe dovrebbe avere una priorità associata, e dovrebbe essere esplicitato se richieda una policy particolare.
Per esempio, si potrebbero definire le tre classi descritte di seguito.
Classe 1 – bassa: bassa priorità. Costo del delay non influente. Trattamento specifico consiste nel mettere in fondo al backlog, lavorare se non c’è altro da fare. Quando la coda delle attività di questa classe supera le 5 unità, mettere in lavorazione quella più anziana.
Classe 2 – standard: media priorità. Costo del delay varia in base agli accordi contrattuali (rilasci ad ogni iterazione), è significativo ma non enorme. Trattamento specifico: lavorazione urgente ma non bloccante.
Classe 3 – alta: alta priorità. Costo del delay: ogni giorno passato in lavorazione costa 1000 €. Trattamento specifico: lavorazione urgente e bloccante; ogni altra attività deve essere interrotta. Se necessario, più persone possono mettersi a lavorare su un task di questo tipo.
Classi di servizio per armonizzare le attività
Utilizzare le classi di servizio permette di gestire in modo coerente e consono le varie attività che si presentano, per esempio razionalizzando la modalità di intervento in base alle policy specificate per una determinata classe. Normalmente lo scopo è quello di ridurre i costi di gestione o di minimizzare il disservizio online. Da notare che l’introduzione di politiche di gestione particolari, per limitare il cost of delay, porta contemporaneamente altri costi: bloccare la produzione o interrompere il lavoro di più persone per risolvere un bug in produzione ha ovviamente un costo, che però nella maggior parte dei casi non è evidente e quindi si tende a sottovalutarlo. Grazie all’osservazione delle metriche che si possono inserire in una Kanban board, è comunque possibile fare delle valutazioni in tal senso. Parleremo di questi aspetti in un prossimo articolo.
Dal punto di vista operativo, le classi di servizio possono essere introdotte tramite un codice colore particolare per i cartellini da apporre alla Kanban board, oppure tramite la creazione di corsie (swimlanes) specifiche per ogni classe.
Figura 4 – Sulla Kanban board, è possibile segnalare l’appartenenza a una determinata classe di servizio grazie a specifici codici colore (rosso, verde, giallo etc.) applicati ai cartellini, o a corsie dedicate a ciascuna classe di servizio.
Migliorare la board tramite le metriche
L’inserimento delle colonne buffer, la definizione dei WIP limit, così come la definizione delle varie colonne della board, sono decisioni che dovrebbero essere sempre soggette a valutazioni e riconsiderazioni sulla base dell’osservazione diretta del sistema e dell’efficacia della board stessa.
Spesso la configurazione migliore si verifica grazie alla naturale capacità che ha una board di fornire una rappresentazione visuale del sistema. Altre volte invece si rendono necessari ulteriori approfondimenti tramite prove e sperimentazioni, successi e fallimenti e analisi retrospettive. Il Kaizen in questo senso può essere considerato come un elemento fondamentale della metodologia Kanban: non esiste una soluzione buona a prescindere, ma si deve trovare di volta in volta la configurazione migliore.
A supporto di questo aspetto nel tempo sono state definite alcune metriche che possono offrire interessanti spunti di miglioramento: lead time e il cycle time.
Il primo, detto anche tempo di attraversamento (per esempio, di un ordine) o “tempo di risposta” è il tempo che impiega un sistema per evadere una richiesta, dal momento in cui viene presentata da un richiedente. Il cycle time invece è il tempo necessario per completare la lavorazione di una determinata richiesta.
Molto usati sono anche i Cumulative Flow Diagrams (CFD), il Defect Rate e il Blocked Items. Avremo modo di parlare di queste metriche in un prossimo articolo, quando affronteremo nello specifico questo argomento.
Conclusioni
In questo articolo si è affrontato il tema della mappatura di un processo tramite la definizione di una board. È importante ribadire una volta di più che tutte le scelte che si fanno in questa fase della progettazione dovranno sempre essere valutate in funzione della capacità da parte della board di rispondere alle necessità di monitoraggio e di miglioramento del processo. Non esiste una soluzione ottimale, ma ogni decisione dovrà poi essere valutata e misurata sul campo sulla base dei risultati ottenuti. L’introduzione delle metriche può essere in tal caso un ottimo modo per poter valutare l’efficacia dello strumento adottato. Ne parleremo.
Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.