Pillole di Kanban applicato: conversazione tra un padre (Kanban Coach) e il figlio adolescente

“Un problema ben esposto è un problema per metà risolto.”
Charles F. Kettering

“Oggi mi hanno chiamato da scuola e mi hanno detto che sei sempre in ritardo….”.
“Io?! Ma che…. cioè, non SEMPRE… di tanto in tanto forse sì, ma non sempre, anzi molto spesso sono puntuale!”
“Va bene figlio mio, facciamo qualcosa!”

Qualche mese dopo, mostrando un grafico con la distribuzione statistica dei ritardi.

distribuzione statistica dei ritardi

“Figlio mio, questa è la metrica di quanto spesso sei puntuale o in ritardo, nel complesso”.
“Chi? Io? Stai scherzando!”.
“No, non sto scherzando, questa è la tua situazione negli ultimi mesi, come puoi vedere arrivi puntuale il 68% delle volte, mentre arrivi entro 15 minuti di ritardo il 93% delle volte e il 99% delle volte sei lì entro mezz’ora di ritardo, ecco tutto”.
“Papà sei un dannato nerd!”.
“Sì lo so figlio mio, ma questi sono fatti, quello che gli psicologi chiamerebbero un esame di realtà. Qual è il numero di ritardi che la scuola è pronta ad accettare?”.
“Non ne ho idea, papà”.
“Va bene, allora controlla con loro, anche se sospetto che abbiano un’aspettativa molto più bassa rispetto al tuo attuale numero di ritardi; tra l’altro la buona notizia è che la distribuzione statistica è ragionevolmente una curva cosiddetta ‘thin tailed’, il che significa che sei costantemente prevedibile…”.
“Cos’è questa roba statistica, papaaaa?! Dimmelo in un modo che anche il gatto possa capire!”.
“Intendo dire che fai le cose più o meno sempre allo stesso modo, quindi probabilmente basta che tu anticipi di mezz’ora la tua sveglia al mattino e sarai sempre puntuale, se lo vorrai….”
“Dai papà, perché dovrei svegliarmi mezz’ora prima…. posso invece correre ed essere puntuale!”.
“È una tua decisione figlio mio, sei tu il padrone del tuo destino, sei tu il capitano della tua anima….”
“Anche la cavolo di poesia ora, smettila papà, ho capito….”

Questa conversazione e i personaggi in essa rappresentati sono puramente fittizi con lo scopo di spiegare ai lettori il Metodo Kanban

traduzione in italiano del post originale pubblicato su LinkedIn https://www.linkedin.com/feed/update/urn:li:linkedInArticle:7164921766983725056/

Pillole di Kanban applicato: la gestione delle congestioni autostradali in Svizzera

Per recarmi in Svizzera a svolgere alcuni corsi di formazione devo percorrere una delle tratte autostradali credo più congestionate al mondo, tra la frontiera italiana di Como e Lugano Nord. La tratta complessiva che devo percorrere da casa al centro di formazione è lunga 85 km e richiede approssimativamente due ore per essere percorsa, sia all’andata al mattino che al ritorno alla sera. L’andamento del traffico non è costante, anche se si tratta di un fenomeno che può essere studiato e che è statisticamente prevedibile perché segue una distribuzione gaussiana. Si tratta di una tipica situazione che si può gestire con un sistema Kanban per garantire la puntualità del trainer in aula e infatti finora non ho mai iniziato un corso in ritardo. Grazie anche agli svizzeri che gestiscono le congestioni autostradali utilizzando gli stessi concetti che stanno alla base di Kanban.

La tratta autostradale svizzera, che si snoda in un fondo valle tra le montagne, risulta la parte più problematica e congestionata. Ho notato però che gli svizzeri gestiscono il traffico autostradale di quella tratta super congestionata utilizzando un sistema basato sulla teoria dei vincoli, quindi applicando gli stessi principi che hanno ispirato Anderson nella messa a punto del metodo Kanban. Vediamo come.

Il vincolo sta nel collo di bottiglia

Alla base del ragionamento c’è la constatazione che un sistema di flusso, come è anche un’autostrada, è vincolato dal suo collo di bottiglia. Se in autostrada ci sono delle strozzature o dei punti particolarmente congestionati, la quantità di mezzi oraria che può percorrere l’autostrada (che in Kanban chiamiamo Throughput) sarà limitata dal più lento di tali strozzature e punti congestionati. Se noi riusciamo in qualche modo a far fluire il traffico alla stessa velocità del collo di bottiglia, il flusso si stabilizza e poi possiamo provare ad accelerarlo, aumentando il throughput e diminuendo il tempo di percorrenza di ciascun mezzo. Concetto intuitivo in teoria, un po’ meno in pratica perché si tratta di andare piano per essere più veloci.

La legge di Little

L’altro concetto che ci aiuta è la Legge di Little, che si può applicare solo in presenza di sistemi con distribuzione statistica gaussiana (e il traffico in autostrada lo è), per cui si possono fare i calcoli utilizzando i valori medi come valori di riferimento. La Legge di Little è una funzione lineare che lega la quantità di elementi medi presenti in un sistema alla velocità di attraversamento media del sistema stesso.
La relazione è L = λ x W, dove L è il numero dei elementi mediamente presenti nel sistema (nel nostro caso i mezzi), λ è il tasso di arrivo medio, che si suppone costante (nel nostro caso quanti mezzi entrano in autostrada al minuto), e W è il tempo medio di attraversamento del sistema (nel nostro caso il tempo per percorrere la tratta autostradale). Facendo qualche semplice simulazione con la Legge di Little si può verificare facilmente come in un sistema si possa minimizzare la velocità di percorrenza (e di conseguenza massimizzare il throughput) se non lo si carica oltre il 65%-70% della sua capacità di carico massima teorica. In Kanban applichiamo questo mettendo dei limiti al WIP – Work In progress (lavoro in corso, nel nostro caso il numero di mezzi presenti sulla tratta autostradale). Concetto questo invece del tutto controintuitivo.

La soluzione del problema dell’autostrada

Mettere insieme questi due concetti per la gestione dell’autostrada significa fare come fanno gli svizzeri:

  • utilizzare un semaforo per frenare il flusso a monte (tipicamente all’ingresso di una galleria prima del tratto congestionato)
  • regolare tramite il semaforo l’accesso al sistema, evitando di caricare il sistema oltre il limite che tende a bloccarlo, limite che è determinato dal collo di bottiglia
  • fare rispettare rigidamente il limite di velocità di 80 km/h per mantenere il flusso stabile

Così facendo il sistema si stabilizza e il risultato è sorprendente, perché dopo l’attesa per accedere al sistema (che mediamente non supera mai i 15′) si riesce comodamente a percorrere la tratta a 80km/h in circa mezz’ora, che sono abbastanza sicuro essere un tempo ottimizzato.

Di ritorno alla sera, terminata la tratta in territorio svizzero, si passa la frontiera e i flussi non sono più regolati, per cui si può osservare e anche provare a misurare la differenza. Per quanto riguarda la tratta italiana, soprattutto all’andata, il metodo Kanban lo ho applicato io in modo tale da assicurarmi di avere tempi di percorrenza prevedibili e affidabili, ma di questo parlerò in un altro articolo.

Migliora il tuo IT Service Management con Kanban: FARA IT Operations – Applying the Kanban Method in the IT Operations Team (case study in inglese)

Applicando il Metodo Kanban, in cinque mesi a partire dall’ottobre 2021, FARA ha migliorato in modo significativo le proprie IT Operations e ha risolto la maggior parte delle ragioni di insoddisfazione che aveva individuato inizialmente e migliorato il suo Service Management. Ha raggiunto tali risultati facendo leva sulle tipiche pratiche Kanban: visualizzazione, limitazione del WIP (Work In Progress, ovvero il lavoro in corso), gestione del flusso di lavoro, esplicitazione delle policy, attuazione dei feedback loop (incontri periodici in cui team a vari livelli discute di come gestire e migliorare il sistema) e infine miglioramento collaborativo ed evoluzione sperimentale del sistema.

FARA è un’azienda tecnologica norvegese leader nei sistemi di mobilità intelligente nei paesi nordici. Da oltre 20 anni fornisce soluzioni di mobilità innovative (come l’Account-Based Ticketing, informazioni in tempo reale e gestione della flotta) per migliorare il flusso di informazioni, l’esperienza dei passeggeri e le infrastrutture di trasporto. E’ parte del Gruppo Ticketer, fornitore del sistema di biglietteria più diffuso nel Regno Unito.

Il Case Study, scritto da Anna Radzikowska, analizza i seguenti elementi che hanno migliorato le IT Operations di FARA:

  • Come la valutazione del livello di maturità ha aiutato a guidare i miglioramenti
  • Come il team ha identificato le cause principali dell’insoddisfazione
  • Cosa è importante per identificare le fonti di domanda
  • Come le modifiche per rendere esplicite le policy e la visualizzazione hanno aiutato ad affrontare i problemi
  • Come il team è riuscito a superare le resistenze legate alla sensazione che avere un nuovo processo fosse un’ulteriore costo che faceva perdere tempo
  • Come il team ha creato nuove abitudini
  • Quali automazioni ha impostato il team per diminuire il numero di interventi manuali
  • Come la ripartizione del lead time ha aiutato il team a identificare le aree di miglioramento

Leggi il case study sul sito Kanban+ della Kanban University

IT Service Management is better with Kanban – Cos’è un servizio?

L'immagine rappresenta un team di specialisti IT che lavora in modo mirato con il metodo Kanban.

Secondo ITIL® 4 un servizio è “Un mezzo per abilitare la co-creazione del valore favorendo il conseguimento dei risultati che i clienti desiderano ottenere senza dover gestire costi e rischi specifici”. Il metodo Kanban è più chiaro e diretto; un servizio è tutto quello che accade tra una richiesta di un cliente e il soddisfacimento della richiesta stessa.

Secondo ITIL® 4 un’organizzazione eroga servizi; secondo il metodo Kanban un’organizzazione è un insieme di servizi.

In Kanban la dimensione di un servizio può essere qualsiasi; dall’esecuzione di un semplice compito allo sviluppo di un prodotto, di un progetto o di un’iniziativa.

In Kanban ogni organizzazione è una rete di servizi; ad esempio un team di sviluppatori riceve e soddisfa richieste da parte delle altre componenti dell’organizzazione.

Il comportamento della rete è stabilito da un insieme di policy, più o meno esplicite. L’efficacia della rete dipende spesso dalla qualità delle policy della stessa. La Definition of Done di un servizio è un esempio di policy.

Il metodo Kanban suggerisce l’applicazione di tre principi ai servizi:

  1. Comprendere le necessità e le aspettative del cliente, e rimanere focalizzati su queste (abbiamo capito a cosa si è ispirato ITIL®…)
  2. Gestite il lavoro, e lasciate che i lavoratori si auto-organizzino intorno al lavoro
  3. Revisionate regolarmente la rete e le sue policy per migliorare i risultati.

Il metodo Kanban è un metodo bottom up; per prima cosa ogni team della rete applica il metodo a sé stesso. Il metodo “kanbanizza” tutta l’azienda un metodo alla volta.

ITIL®, a differenza di Kanban, prevede un approccio top down; ITIL® 4 si applica a interi value stream, coinvolgendo in un’unica attività di progettazione tutte le pratiche e attività che costituiscono il flusso del valore.

Migliora il tuo IT Service Management con Kanban: identificare e misurare i flussi per ottenere livelli di servizio affidabili

Recentemente mi è capitato di essere interpellato per una consulenza Kanban da un collega che si sta occupando di supportare l’IT di una nota grande azienda di servizi. I servizi offerti dall’azienda in questione dipendono in modo significativo da una complessa rete di servizi informativi che spostano ingenti quantità di dati e gestiscono decine di migliaia di transazioni al giorno, per cui l’IT dell’azienda si ritrova a svolgere un ruolo critico per il business. Il CIO dell’azienda ha contattato il collega perché si trovava in difficoltà a comprendere le dinamiche del sistema e a mantenerlo sotto controllo.

Quello a cui si è trovato davanti il collega, è un caso tipico: i sistemi informativi delle grandi aziende sono spesso modellati a partire dalle best practice ITSM di riferimento del mercato, quali ITILv3 o più recentemente ITIL4. Tali framework sono sicuramente utili per comprendere il contesto dei servizi IT e definire principi e processi delle organizzazioni anche se poi manca la parte pragmatica che permetta di plasmare l’ecosistema organizzativo in modo tale che ciò che è stato pensato e implementato possa essere successivamente controllato e migliorato. Manca quasi sempre quello che definirei il ‘motore’ per il miglioramento continuo. Per cui ci si trova a distanza di anni a non comprendere più le vere dinamiche di funzionamento del sistema organizzativo.

carichi di lavoro del sistema misurati per orario della giornata

La prima cosa fatta è stata quindi cercare di ricostruire i flussi informativi di scambio tra i sistemi, a partire dai più critici. E’ stato utilizzato un approccio molto pragmatico, individuando insieme al CIO alcuni nodi che facevano sicuramente parte dei flussi e collocando in questi nodi delle sonde che rilevassero le metriche fondamentali di flusso tra i nodi stessi: throughput, tempi di attraversamento, carichi di lavoro distribuiti per orario della giornata e numero di transazioni che vanno in errore. Tali metriche sono poi state messe in un cruscotto a disposizione del CIO. Questo primo passo ha portato dei primi benefici in termini di visibilità e misura del sistema coerentemente con le pratiche Kanban di visualizzazione e gestione del flusso.

tempi di risposta del sistema misurati per orario della giornata

Dopo questa fase iniziale sono stati progressivamente individuati ulteriori nodi e aggiunte altre sonde in modo tale da andare a ricostruire e a misurare i processi reali all’interno dell’organizzazione. L’approccio pragmatico e sperimentale è stato apprezzato perché tende a ovviare uno dei problemi tipici dell’analisi dei processi in aziende di grandi dimensioni, dove la complessità è tale che ricostruire i flussi di lavoro con il metodo tradizionale di andare ad analizzare la documentazione e a intervistare le persone rischia di risultare fuorviante oltre che costoso.

Kanban offre una guida pragmatica su come utilizzare al meglio le metriche raccolte per ottenere un effettivo miglioramento dei flussi di lavoro e dei servizi e fare in modo che il CIO possa offrire al business livelli di servizio prevedibili e affidabili.

Aperta la finestra di visibilità sui flussi di lavoro, il prossimo passo sarà quindi quello di far leva su alcune pratiche Kanban che permettano di sviluppare il sistema in modo evolutivo;
a cominciare dall’introduzione di cicli di feedback a vari livelli dell’organizzazione per far riflettere le persone e fare emergere idee di miglioramento dei servizi; e proseguendo con l’arricchimento dei ruoli aziendali già esistenti con competenze e responsabilità di gestione dei flussi.

L’obiettivo finale è quello di arrivare a dotare l’organizzazione nel suo complesso di uno strumento di controllo efficace dei livelli di servizio, non più solo a disposizione dell’IT ma anche del business.


IT service management is better with Kanban

L'immagine rappresenta un team di specialisti IT che lavora in modo mirato con il metodo Kanban.

Negli ultimi cinque anni #ITIL4 è cresciuto di dimensioni fino a raggiungere proporzioni monumentali; sei libri e 34 pratiche, per un totale stimato di oltre 2.000 pagine. Leggere tutto il materiale disponibile richiederebbe troppo tempo, per non parlare del costo dell’operazione.

Questo è il motivo per cui la grande maggioranza delle persone si ferma al livello Foundation, ma il livello Foundation non ci fornisce le conoscenze che servirebbero per iniziare davvero a migliorare i nostri servizi. Negli ultimi due anni mi sono reso conto che esiste una strada diversa, il metodo Kanban.

Per Kanban ogni organizzazione è una rete di servizi interdipendenti tra loro; il comportamento della rete è definito da un insieme di policy. A differenza di quanto avviene negli altri metodi, #ITIL4 incluso, Kanban non fornisce soluzioni preconfezionate ai problemi delle organizzazioni, ma fornisce un metodo per evidenziare i problemi esistenti e provare a risolverli. In questo modo si evita la resistenza che le persone oppongono naturalmente a qualsiasi tentativo di cambiare il loro modo di lavorare.

Cosa c’è dentro Kanban?

Tre principi di Service Management:

  1. Comprendere e concentrarsi sulle necessità e le aspettative dei clienti
  2. Gestire il lavoro (non le persone), lasciando che le persone si auto-organizzino intorno al lavoro
  3. Rivedere regolarmente la rete e le sue policy per migliorare i risultati

Tre principi di Change Management:

  1. Partire da quello che si sta già facendo; comprendere i processi attuali, come sono applicati in pratica, e rispettando i ruoli, le responsabilità e i job title.
  2. Impegnarsi a perseguire il miglioramento grazie a miglioramenti evolutivi
  3. Garantire atti di leadership a tutti i livello

Tre principi di scaling:

  1. Scalare in modo orientato ai servizi un servizio alla volta
  2. B Non progettare una grande soluzione su scala aziendale, come suggerisce #ITIL4
  3. Usare le Cadenze Kanban come sistema di gestione che consente di ottenere equilibrio, il che porta a una migliore erogazione dei servizi aziendali.

Sei pratiche:

  1. Visualizzare
  2. Limitare il work in progress
  3. Gestire il flusso del lavoro
  4. Rendere esplicite le policy esistenti
  5. Mettere in atto cicli di feedback
  6. Migliorare in modo collaborativo ed evolvere in modo sperimentale utilizzando i modelli e il metodo scientifico

S.T.A.T.I.K, un approccio all’implementazione:

Identificare i servizi. Per ogni servizio:

  1. Capire cosa rende il servizio adatto allo scopo.
  2. Comprendere le fonti di insoddisfazione dell’attuale sistema di erogazione.
  3. Analizzare le fonti e la natura della domanda.
  4. Analizzare l’attuale capacità di erogazione.
  5. Modellare il flusso di lavoro per l’erogazione del servizio.
  6. Identificare e definire le classi di servizio.

… e se poi doveste sentire comunque il bisogno di confrontarvi con le pratiche più diffuse ci sono i processi free e open source descritti da FitSM

Vi sembra interessante? Tutta la conoscenza kanban è disponibile sul portale kanban.plus (12€ / mese, 254,70€ / anno), e tutta la formazione e il coaching kanban sono disponibili sul sito della Kanban University, oltre che – ovviamente – qui su kanban.help.

 Non ci sono esami per ottenere le certificazioni Kanban, perché i corsi sono essenzialmente pratici, e chi li porta a termine impara tutto quello serve per iniziare a usare il metodo in azienda. 

Migliora il tuo IT Service Management con Kanban: misurare ed equilibrare i carichi di lavoro di una funzione IT

Sto collaborando come consulente e coach da qualche anno con la funzione IT di un’azienda della quale non farò il nome per ragioni di riservatezza, la chiamerò Grow, un nome di fantasia.

Quando ho iniziato a collaborare con Grow, l’azienda in forte crescita ma con una storia di piccola realtà locale, non aveva mai avuto la presenza di un vero IT Manager di ruolo e la funzione IT era operata in modo sostanzialmente poco strutturato da altre funzioni.

Dopo un periodo iniziale in cui, in staff alla presidenza, ho svolto personalmente ad interim la funzione di IT Manager, cominciando a organizzare quella che sarebbe diventata la funzione IT, si è deciso di assumere una IT Manager di ruolo e insieme a lei siamo andati a strutturare la funzione mediante l’introduzione di processi e ruoli basati sul framework ITILv3, che allora costituiva lo stato dell’arte nel settore dei servizi IT. Per la parte di gestione dei progetti abbiamo invece sviluppato, sempre insieme all’IT Manager di Grow, un metodo interno basato su un ibrido tra i framework PRINCE2 e AgilePM che successivamente è stato adottato da tutta l’azienda Grow anche per i progetti non IT.

Nel corso degli anni si è quindi sviluppata in Grow una IT moderna, in staff alla direzione aziendale e basata sul concetto di System Integration and Management, che oggi conta un team di tre persone, oltre alla IT Manager, e che coordina e integra un network di fornitori esterni per erogare un numero sempre crescente di servizi IT alle direzioni tecniche di Grow, che nel frattempo ha raggiunto i tremila dipendenti.

Il volume di lavoro e le dimensioni sempre maggiori hanno posto l’IT di Grow di fronte a sfide nuove e complessità sempre crescenti e i modelli basati sui soli framework di ITSM e Project Management non erano più sufficienti.

Per questa ragione abbiamo cominciato ad applicare il metodo Kanban con l’obiettivo di comprendere più a fondo il funzionamento dei vari servizi gestiti dall’IT per poterli gestire meglio.

distribuzione statistica dei tempi di risposta del Service Desk

Il Service Desk e i processi di Incident Management e Request Fulfillment sono stati la parte relativamente più semplice: dopo anni di lavoro per strutturarli con l’ausilio di uno strumento ITSM, sono ottimizzati – si stima che il tempo medio di evasione di un ticket si sia ridotto in cinque anni di un fattore dieci. Introducendo la tipica metrica Kanban di distribuzione statistica dei tempi di risposta come in figura, ci siamo resi conto che in effetti l’attività di Service Desk stava sovra-performando, il 96% dei ticket erano evasi entro 4 ore a fronte di uno SLA concordato con il business di 8 ore per i ticket a bassa priorità che sono la stragrande maggioranza (99%).

distribuzione statistica dei tempi di risposta degli altri servizi IT

Più difficile inizialmente la misura degli altri servizi IT per i quali non si disponeva di strumenti di gestione equipaggiati con metriche Kanban. È stata quindi introdotta una Kanban board dotata di strumenti di misura che nel giro di qualche mese ha permesso di disporre di un grafico di confronto dal quale è risultato che il 96% dei task relativi ad altri servizi erano evasi entro 8 settimane a fronte di un livello di servizio non ancora definito ma che sarebbe stato ragionevole fissare a 4 settimane o meno.

Potendo disporre di tali metriche e di una sostanziale prevedibilità complessiva dei propri servizi il team IT di Grow ha ridistribuito i carichi di lavoro e riallocato la propria capacità produttiva, lavorando su un’agenda settimanale condivisa degli impegni del team per riequilibrare le performance dei servizi e ottimizzare i livelli di servizio verso il business.