ITIL | Il Project Management & l'arte della Maratona

Come funziona Kanban: ottimizzare i processi aziendali con la Teoria dei Vincoli (TOC) in Kanban

In questo articolo vi parlo di come funziona Kanban, approfondendo come sia possibile ottimizzare i processi aziendali con la Teoria dei Vincoli (TOC) in Kanban. La Teoria dei Vincoli (TOC), introdotta da Eliyahu M. Goldratt negli anni ’80 del secolo scorso, è un approccio che mira a migliorare le prestazioni delle organizzazioni concentrandosi su quei pochi fattori che limitano la produttività. TOC si basa su un concetto fondamentale: ogni sistema ha un vincolo che ne determina la capacità massima. Pertanto, il miglioramento complessivo dipende dall’individuazione e dalla gestione del vincolo più critico.

Cosa sono i Vincoli?

Un vincolo, nella Teoria dei Vincoli, è qualsiasi elemento che impedisce a un sistema di raggiungere i suoi obiettivi perché costituisce un collo di bottiglia. Questo elemento può essere una risorsa scarsa, una politica aziendale, una fase produttiva, o addirittura la domanda di mercato. Come Goldratt descrisse, i vincoli sono come l’anello debole di una catena: è inutile rinforzare gli altri anelli se non si rafforza quello che effettivamente limita la resistenza dell’intero sistema.

I cinque passaggi della Teoria dei Vincoli

Per applicare la TOC, Goldratt ha proposto cinque passaggi che aiutano a identificare e gestire i vincoli in maniera sistematica:

Individuare il vincolo: Il primo passo è capire quale parte del sistema limita il rendimento complessivo. Ad esempio, può essere un macchinario lento in una linea di produzione o una fase burocratica in un processo amministrativo.
Sfruttare il vincolo: Una volta identificato il vincolo, è necessario massimizzare il suo rendimento. Bisogna ottimizzarne l’uso, assicurandosi che non ci siano interruzioni e che funzioni al massimo della sua capacità.
Subordinare tutto al vincolo: In questo passaggio, si adattano tutte le altre fasi del processo alla capacità produttiva del vincolo. Ciò significa che le altre risorse non dovrebbero produrre oltre la capacità del vincolo, per evitare l’accumulo di work in progress o ritardi in altre parti del sistema.
Elevare il vincolo: Se il vincolo continua a limitare la produttività, bisogna prendere misure per aumentare la sua capacità. Questo può includere l’acquisto di nuove attrezzature, l’assunzione di personale aggiuntivo o il cambiamento di politiche che causano inefficienze.
Ricominciare il ciclo: Una volta che il vincolo è stato elevato o eliminato, è possibile che emerga un nuovo vincolo. Il processo ricomincia, garantendo un miglioramento continuo.

Drum, Buffer e Rope

Un concetto chiave all’interno della TOC è il modello Drum, Buffer, Rope (DBR), che aiuta a sincronizzare i processi produttivi attorno al vincolo.

Drum (Tamburo): Il tamburo rappresenta il ritmo del sistema, imposto dal vincolo. Questo ritmo determina la cadenza a cui tutto il sistema deve operare, come un tamburo che scandisce il passo.
Buffer (Cuscinetto): Il cuscinetto è una riserva di lavoro che viene posta prima del vincolo, garantendo che esso non resti mai inattivo. Il buffer serve per assorbire le eventuali fluttuazioni o inefficienze in altre parti del sistema, proteggendo il vincolo da ritardi.

Rope (Corda): La corda è il meccanismo di comunicazione che collega i processi a monte del vincolo. Serve a controllare il flusso di lavoro verso il vincolo, evitando sovrapproduzione. La corda sincronizza il ritmo dell’intero sistema con quello del vincolo.

Applicazione della TOC con il Metodo Kanban

Il metodo Kanban integra perfettamente la TOC per la gestione dei vincoli nei flussi di lavoro, vediamo come:

Individuare il vincolo: Attraverso l’uso di una Kanban board e delle metriche Kanban, è facile individuare il vincolo osservando dove si accumula il lavoro e misurando i tempi di attraversamento di ciascuna fase di lavoro. Le aree dove il lavoro si accumula indicano i colli di bottiglia. Questo rende visibile il vincolo, consentendo all’organizzazione di intervenire su di esso.
Sfruttare il vincolo con Kanban: Una volta identificato il vincolo, la TOC consiglia di massimizzare il suo utilizzo. Kanban, grazie al suo meccanismo di “pull” (tirare il lavoro in base alla domanda), consente di gestire il flusso di lavoro in modo che il vincolo operi al massimo della sua capacità senza essere sovraccaricato.
Subordinare tutto al vincolo: Kanban è eccellente nel subordinare le altre risorse al ritmo del vincolo. Con i limiti di WIP (Work In Progress), il metodo Kanban controlla che le risorse a monte non producano troppo, evitando che il vincolo venga sopraffatto dal carico di lavoro.
Elevare il vincolo: Quando il vincolo raggiunge la sua capacità massima, l’organizzazione può decidere di investire per aumentarne la capacità. Ad esempio, potrebbe voler migliorare una fase del processo o aumentare le risorse a disposizione del vincolo. Anche in questo caso Kanban può evidenziare i miglioramenti implementati e facilitare la gestione del cambiamento.
Iterare con Kanban e TOC: La combinazione di TOC e delle altre pratiche Kanban offre un ciclo continuo di miglioramento. Man mano che un vincolo viene risolto, Kanban permette di monitorare visivamente e misurare se emerge un nuovo vincolo e dove intervenire.

Un esempio pratico: l’Onboarding dei dipendenti

Utilizzando Kanban e la TOC un dipartimento di risorse umane ha migliorato drasticamente le proprie prestazioni, come ho già raccontato in un case study precedentemente pubblicato e approfondito in un webinar. Il dipartimento di risorse umane stava cercando di migliorare il processo di Onboarding dei nuovi dipendenti. Applicando Kanban, il team di lavoro ha visualizzato l’intero processo, dalla presa in carico fino all’integrazione dei nuovi arrivati nell’organizzazione, e ha cominciato a misurare i tempi di percorrenza delle varie fasi. Nel corso del tempo, si è osservato che una fase particolarmente lenta era quella legata alla firma del contratto, dove i nuovi assunti restavano disorientati dalla procedura di firma digitale, con l’effetto che questa fase del processo si protraeva per giorni, se non per settimane.

Seguendo la TOC, si è identificato questo come il vincolo. Si è stabilito che la fase di firma del contratto dovesse determinare il ritmo e la velocità di tutto il flusso di lavoro (drum). Si poi è creato un piccolo buffer di candidati pronti per firmare il contratto, in modo da non fare mai mancare lavoro alla fase che limita la velocità di tutto il processo. Infine, il flusso di lavoro è stato controllato tramite la ‘corda’ (rope), rappresentata dai limiti di WIP all’ingresso e lungo il flusso, in modo da non aggiungere troppi nuovi candidati nel processo fino a quando la fase di firma del contratto non fosse in grado di gestirli.

Il risultato immediato è stato quello di riuscire a stabilizzare il flusso di lavoro e renderlo prevedibile. Successivamente il vincolo è stato elevato, ovvero la fase di firma del contratto è stata ottimizzata, per accelerarla e di conseguenza accelerare tutto il processo. Questo ha permesso il dimezzamento del tempo di processo totale nel giro di circa un mese. Iterando poi il ciclo di miglioramento, nell’arco di un anno si è ottenuta una riduzione pari a quasi il 90% del tempo di processo totale.

Conclusione

La Teoria dei Vincoli all’interno del metodo Kanban è uno strumento estremamente potente per ottimizzare i processi aziendali. Mentre la TOC individua e affronta i vincoli che limitano le prestazioni, altre pratiche Kanban permettono di gestire in modo sistemico e flessibile il flusso di lavoro. La combinazione di questi approcci offre un ciclo continuo di miglioramento, rendendo l’organizzazione più efficiente, adattabile e pronta a rispondere ai cambiamenti.

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.

Migliora il tuo project management con Kanban: Churchill ci insegna a scrivere le policy

Una delle pratiche generali del metodo Kanban è ‘Esplicita le Policy’ (Make Policies Explicit), che da un punto di vista pratico significa definire, scrivere e rendere chiare a tutti le regole di funzionamento del proprio sistema Kanban. Nella mia esperienza di coach osservo che questo è un aspetto spesso poco considerato, mentre invece è di un’importanza cruciale.

In questo articolo vi riporto e commento un famoso dispaccio declassificato di Winston Churchill, primo ministro britannico durante la seconda guerra mondiale, che ci insegna come si scrivono le policy. E ci insegna anche a cosa servono le policy.

A cosa servono le policy

Le policy definiscono come si svolge il lavoro in ogni fase del processo, come viene visualizzato il lavoro, come vengono prese le decisioni e quali sono gli interlocutori con cui relazionarsi, sia all’interno dell’organizzazione di servizi che con i clienti. Rendere esplicite le policy è essenziale per rendere il flusso di lavoro stabile e affidabile.

Il dispaccio di Churchill definisce una policy che spiega in modo chiaro e per punti le modalità secondo cui devono essere scritti i report perché siano efficaci. Lo stesso vale per le policy dei sistemi Kanban, sono istruzioni operative che devono descrivere cosa fare perché il flusso di lavoro funzioni efficacemente.

Peraltro chi si occupa di progetti e project management non può non notare il richiamo del dispaccio ad evitare di produrre carta e burocrazia inutile e limitarsi all’essenziale. Anche questo è un insegnamento che ritroviamo nel metodo Kanban. Per esempio la pianificazione dei progetti con Kanban permette di elaborare una previsione affidabile dei tempi e costi di progetto in modo rapido, economico ed efficace, senza inutili appesantimenti.

Come si scrivono le policy

Le policy devono quindi essere scritte in linguaggio semplice e comprensibile a tutti, sono istruzioni operative, non devono impressionare qualcuno ma essere applicate sistematicamente in modo tale da aiutare la stabilizzazione del flusso di lavoro.

Il dispaccio di Churchill è scritto nelle stesse modalità che descrive, in modo tale da essere esso stesso un esempio di come si scrivono i report. Per questo mi pare che sia un ottimo esempio di guida pragmatica, attuabile e basata su evidenze, come ci insegna a fare anche il metodo Kanban.

Spesso riscontro invece nelle aziende una preoccupazione per la forma con cui vengono scritte le policy. In una certa misura è comprensibile, ma non deve portare a perdere di vista la sostanza, come invece succede troppo spesso. La prerogativa dei sistemi Kanban non è quella di essere formalmente ineccepibili, quanto quella di funzionare in modo affidabile ed evolvere nel tempo.

A chi servono le policy

Le policy servono a chi opera sul flusso di lavoro per sapere come deve comportarsi nelle varie situazioni. Il team è chiamato a definire le policy che permetteranno di lavorare meglio e poi a rispettarle o a modificarle se non sono funzionali. In questo senso più che la scrittura delle policy è importante la loro applicazione. Se sapremo portare i flussi di lavoro ad essere stabili, sapremo poi anche evolverli, altrimenti no. Troppe volte vedo policy, anche pensate bene, che poi restano all’atto pratico lettera morta.

Di nuovo ci è di ispirazione il dispaccio di Churchill, che nell’ultimo paragrafo riassume il senso profondo del metodo Kanban: “la disciplina di esporre i punti concreti in modo conciso si rivelerà un aiuto per una maggiore chiarezza di pensiero”. E conseguentemente di azione.

Migliora il tuo Project Management con Kanban: gestire ed evolvere un’organizzazione che eroga servizi

Il metodo Kanban è uno strumento efficace per stabilizzare e poi evolvere in modo efficace ogni organizzazione che eroga servizi. Ho già raccontato in un precedente articolo come sia possibile utilizzare Kanban per misurare ed equilibrare i carichi di lavoro tra flussi di lavoro diversi. Questo è reso possibile dal fatto che i flussi vengono analizzati come se fossero indipendenti uno dall’altro, ciascuno di loro viene gestito e stabilizzato fino a farlo diventare affidabile e robusto a prescindere da ciò che accade nel resto del sistema. Infine si cerca di equilibrare in modo empirico e sperimentale la rete dei flussi collegati insieme, sempre però evitando la centralizzazione del controllo, che porterebbe il sistema complessivo a essere fragile. Al contrario una rete di sistemi Kanban è resiliente perché l’eventuale degradarsi di una parte ha sempre un impatto limitato sul resto del sistema.

L’applicazione di Kanban ai servizi

La funzione IT di Grow, l’azienda citata nel precedente articolo, che ricordo utilizza processi e ruoli basati sul framework ITILv3, ha la possibilità di equilibrare i carichi perché nell’arco di qualche anno ha fatto evolvere costantemente la propria struttura basandosi sulla logica sopra descritta. Nell’immagine si può vedere come il nucleo del sistema si basi oggi su tre sistemi Kanban, interconnessi ma indipendenti. Il primo è l’IT Portfolio, il flusso di lavoro che permette in modo trasparente di orchestrare tutti gli altri servizi e di destinare le risorse dove necessario. Il secondo è il Service Desk, flusso che gestisce il supporto agli utenti (richieste di servizio e incidenti). Il terzo è l’IT Workflow, flusso che elabora tutti gli elementi di lavoro relativi ai processi ITIL necessari far funzionare i servizi IT erogati dal sistema complessivo.

Le altre funzioni aziendali di Grow, che sono i ‘clienti’ della funzione IT, e che a loro volta sono in parte gestite con sistemi Kanban – come per esempio l’HR – interagiscono con il Service Desk per quanto riguarda l’operatività corrente e con l’IT Portfolio per richiedere tutti i miglioramenti ai servizi utilizzati. L’IT Portfolio indirizza i miglioramenti di piccola entità (Change Request – CR) all’IT Workflow, che li processa. Invece i miglioramenti di maggiore entità (Progetti) vengono indirizzati a un sistema Kanban specifico per la gestione dei progetti.

L’applicazione di Kanban ai progetti

La funzione IT di Grow ha un sistema di project management che si basa su PRINCE2 e AgilePM e anche nel caso dei progetti ha fatto evolvere il proprio project management grazie ai sistemi Kanban sviluppati al proprio interno. Il sistema Kanban del Progetto orchestra in modo trasparente il progetto stesso e indirizza lo sviluppo dei componenti ai vari team, che nel caso della nostra funzione IT sono per lo più dei fornitori esterni.

I fornitori esterni nella quasi totalità dei casi non utilizzano un sistema Kanban, ma come detto la loro eventuale instabilità impatta in modo limitato i sistemi Kanban interni che mantengono autonomamente la propria stabilità. Dai fornitori esterni possono anche ritornare delle richieste all’IT Workflow, per esempio per i test dei sistemi informatici che sono sviluppati dal progetto, oppure per i cambi di configurazione dei servizi modificati dal progetto.

Il sistema Kanban di Progetto, infine, non vede l’IT Portfolio solo come ‘committente’, ma interagisce anche con esso per richiedere eventuali CR fuori dal proprio ambito.

Mantenere il sistema bilanciato

E’ necessario sottolineare di nuovo l’importanza che hanno avuto e che hanno nel sistema dell’IT di Grow lo sviluppo, la gestione e la stabilizzazione di ciascuno dei flussi e dei sistemi Kanban in modo indipendente ma interconnesso. In questo modo l’IT di Grow riesce mantenere affidabili e robusti i flussi a prescindere dal funzionamento del resto del sistema e allo stesso tempo disporre di un sistema complessivo sostanzialmente prevedibile e resiliente.

Il metodo Kanban mette a disposizione numerosi strumenti e un metodo di sviluppo evolutivo consolidato per arrivare a questo risultato, senza sostituire i metodi di service management e project management già in uso, ma semplicemente aiutando ad utilizzarli meglio e a potenziarli, come avvenuto in Grow.

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

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.

carichi di lavoro del sistema misurati per orario della giornata

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.

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

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, 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, sostanzialmente 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.

Un altro aiuto per un mondo di code: shift-left

Un altro approccio suggerito da ITIL4 che ci può aiutare nel nostro nuovo mondo fatto di ‘social distancing’ e lunghe code per tutto è quello che va sotto il nome di Shift-left. Di che cosa si tratta?

Shift-left (letteralmente “sposta a sinistra”) si riferisce a un qualunque processo, che di solito è rappresentato in uno schema che procede da sinistra verso destra, e significa spostare un’attività e la relativa responsabilità verso la stazione di processo che è immediatamente a monte nel processo, quindi nello schema l’attività si sposta appunto a sinistra. Questo si rende necessario perché tipicamente la stazione a valle è più lenta, spesso è un collo di bottiglia e si cerca con lo shift-left di rendere più spedito tutto il processo, riducendo quindi i tempi di attesa in coda.

Prendiamo un esempio semplice, che possiamo sperimentare tutti, quello di una coda alla cassa di un supermercato. Una tipica operazione di shift-left è quella di mettere dei lettori di codice a barre a disposizione degli utenti del supermercato e far fare a questi ultimi, mentre sono in coda alla cassa, la lettura dei codici dei prodotti nel carrello, in modo che quando viene il loro turno le operazioni in cassa siano più rapide. L’operatore di cassa deve svolgere solo un controllo visivo sommario sul carrello e gestire il pagamento, con notevole risparmio di tempo alla cassa e conseguente risparmio sui tempi di attesa in coda.

Un altro esempio tipico è quello di far precompilare online agli utenti di un servizio un form con i propri dati, in modo che una volta arrivati allo sportello fisico l’operatore abbia già tutti i dati inseriti e debba solo controllarli, con risparmio di tempi e di code.

Esiste anche un concetto, meno comune, di Shift-right (“sposta a destra”) che significa, questa volta, spostare una attività e la relativa responsabilità verso la stazione di processo che è immediatamente a valle nel processo, quindi nello schema l’attività si sposta a destra.

Tutte le volte che ci viene messa a disposizione un’applicazione per il PC o per lo smartphone che non è stata completamente testata dagli sviluppatori, i quali si affidano ai feedback degli utenti per la messa a punto dell’applicazione, siamo in presenza di un approccio di Shift-right. L’attività di test è stata di fatto delegata agli utenti, che nel processo di sviluppo dell’applicazione stanno a valle.

Anche nel caso dei concetti di Shift-left e Shift-right, come per Swarming si tratta di approcci che si sono sempre utilizzati, ad ITIL4 il merito di averli suggeriti e sistematizzati.

Swarming ovvero un aiuto per un mondo di code

Il mondo in cui ci siamo venuti a trovare a causa del COVID-19 è caratterizzato dalle code. Con la necessità del ‘social distancing’, di mantenere la ‘distanza sociale di sicurezza’, si sono create code lunghissime ovunque. Code fisiche, come le code che si formavano fuori dai supermercati i primi giorni dell’emergenza, o code virtuali, ora che progressivamente si sta riaprendo e ci si sta organizzando per gestirle con sistemi di ticketing via app. Ma ormai viviamo di code e sono sempre code lunghe. Quali metodi ci possono aiutare a gestire meglio le code e i servizi che si rinnovano in un mondo che è cambiato?

Prendendo spunto da ITIL4, edizione più recente del framework più noto per la gestione dei servizi non solo IT, mi viene in mente Swarming (letteralmente lo ‘sciame delle api’), un approccio che viene suggerito per aiutare a migliorare la gestione delle code. Di che cosa si tratta?

Swarming è definito come ‘un metodo per gestire il lavoro in cui un gruppo di risorse specialistiche o di stakeholder lavorano su un’attività inizialmente tutti assieme fino a quando non diventa chiaro chi è nella posizione migliore per continuare a svolgere il lavoro e a quel punto gli altri sono lasciati liberi di dedicarsi ad altri compiti’. Proviamo a capire meglio cosa significa in pratica.

L’idea fondamentale di Swarming parte da alcune osservazioni sui limiti di efficacia dei sistemi classici di gestione delle code:

i ticket tipicamente vengono assegnati alle differenti code da parte del primo livello (chi prende in carico la richiesta) e il primo livello spesso non ha le competenze per valutare ne la priorità del ticket né a quale gruppo inoltrare il ticket stesso. Quello che spesso succede è che il ticket viene instradato in maniera non corretta e quindi deve essere riassegnato successivamente a una coda diversa allungando i tempi di evasione della richiesta perché il ticket resta in giro per molto più tempo prima di venire assegnato al gruppo di lavoro che è in grado di risolverlo e di gestirlo correttamente
la scarsa comprensione della richiesta porta spesso a fare escalation verso team di specialisti per dei ticket per i quali in realtà non sarebbe necessario, causando così un sovraccarico sulle risorse più specializzate alle quali viene assegnato il ticket e così facendo rallentando il processo e allungando i tempi di evasione della richiesta

Cosa fa quindi Swarming? In realtà fa la cosa più vecchia del mondo, quella che abbiamo sempre visto fare a tutti i ristoratori capaci di gestire l’affollamento dentro e fuori dal proprio locale: qualcuno, di solito il titolare nel locale, non si prende alcun compito preciso ma dedica il suo tempo a verificare se tutte le situazioni nelle quali viene gestita una coda stanno funzionando correttamente e se non stanno funzionando correttamente interviene a supporto. Gli interventi del titolare tipicamente riguardano:

la coda all’esterno del locale, dalla quale vengono fatti passare avanti gruppi piccoli , tipicamente di due persone, perché magari all’interno si sono liberati dei tavoli da due
Il monitoraggio delle richieste in cucina, per verificare che non ci siano intoppi all’evasione in tempi accettabili
il monitoraggio dei tavoli per accertarsi che non ci sia nessun ospite che sta aspettando un tempo eccessivo per ricevere il servizio al tavolo

Questo esempio, che abbiamo tutti sotto gli occhi, ci aiuta a capire quelli che nella sostanza sono i tre tipi di Swarming che vengono suggeriti:

Dispatch Swarms: esperti vanno a pescare dalla coda in ingresso al sistema non necessariamente l’attività che si trova in prima posizione e mandano invece avanti quelle attività per le quali vedono la possibilità di essere evase in maniera efficace rapidamente; nel nostro esempio è il titolare del locale (il nostro ‘esperto’) che esce e verifica se ci sono gruppi corrispondenti ai tavoli che si sono liberati all’interno e li manda avanti
Backlog Swarms: esperti vanno regolarmente a verificare le attività presenti nelle varie code all’interno del sistema e le evadono o le riassegnano ad altre code senza generare inutili attese; nel nostro esempio è sempre il titolare del locale che verifica regolarmente la coda delle richieste alla cucina o al forno della pizza e riorganizza il lavoro in modo da far procedere più spedita l’evasione delle richieste, eventualmente svolgendo lui stesso il lavoro
Drop-in Swarms: esperti monitorano regolarmente il lavoro di altri operatori e intervengono a supporto quando lo ritengono opportuno per accelerare il lavoro; nel nostro esempio è di nuovo il titolare del locale che monitora il lavoro dei camerieri ai tavoli e interviene a loro supporto qualora ritenga che possa essere utile per accelerare e migliorare il servizio

Come si vede bene è un’idea antica, che se applicata in modo sistematico può migliorare di molto la gestione del servizio anche in presenza di lunghe code. L’obiezione principale che viene fatta all’adozione dello Swarming è il fatto che l’impiego di esperti in un ruolo di supporto e quindi in definitiva senza nessun ruolo proprio assegnato, è visto come un uso inefficiente delle risorse aziendali.

L’esempio che ho fatto del nostro ristoratore penso tolga qualunque dubbio: abbiamo sperimentato tutti come i locali in cui il titolare svolge le azioni appena descritte siano nel complesso più efficienti.

Peraltro tali locali sono anche più gradevoli perché il titolare di solito non si limita a fare Swarming ma coinvolge gli avventori in una esperienza umana che poi è la vera ragion d’essere del suo lavoro e del suo servizio. E in questo momento abbiamo bisogno soprattutto di quello, di una migliore esperienza di servizio, nonostante la mascherina sul viso.

Lavoro Meglio mi ha intervistato su Cynefin

Ascolta “#126 Puntata speciale [Intervista] Cynefin” su Spreaker.

Ringrazio l’amica e collega Leonarda Vanicelli, podcaster di Lavoro Meglio, che mi ha voluto invitare a fare una chiacchierata su Cynefin, il tema del mio ultimo articolo.

Qui sopra potete ascoltare l’intervista. Auguro veramente a tutti di potersi dedicare ad attività che valorizzino la nostra umanità per fare cose straordinarie assieme.

Capire quale modello applicare per ripartire con il COVID

Una delle domande che ci stiamo facendo tutti è come ripartire quando sarà allentato il lockdown che si è reso necessario a causa dell’emergenza COVID. C’è molto fermento a livello politico, sociale e aziendale su ‘cosa fare’, anche se ritengo che sia molto più importante chiedersi prima ‘cosa ha senso fare’ e ‘che modello operativo ha senso applicare’ per procedere e per decidere, perché il rischio che corriamo è quello di interpretare la situazione a seconda di come siamo fatti noi e quindi applicare istintivamente i modelli che ci sono più congeniali o riproporre in modo più o meno consapevole i modelli che siamo abituati ad applicare a un contesto che però è radicalmente cambiato. Per comprendere quale modello operativo/decisionale abbia senso applicare si può utilizzare Cynefin (si pronuncia: /ˈkʌnɨvɪn/), un framework di interpretazione della realtà e di scelta delle strategie per affrontare le diverse situazioni del quale avevo già parlato in un precedente post di qualche anno fa e che nel frattempo ha acquisito popolarità.

Cynefin individua cinque domini rappresentativi della realtà in cui ci troviamo e l’esercizio consiste nel comprendere in quale dominio si trovi ogni situazione da gestire:

il dominio Ovvio (Obvious domain) è quello in cui le relazioni causa/effetto dei fenomeni sono appunto ovvie e comprensibili da tutti; in questo tipo di dominio ha senso agire seguendo delle cosiddette Best Practice, secondo schemi noti per cui le decisioni saranno prese secondo un modello del tipo Percepire – Categorizzare – Rispondere (Sense – Categorise – Respond); per esempio le convenzioni dell’andare per strada sono ovvie e note a tutti e le decisioni saranno prese categorizzando le situazioni che si presentano secondo quello che dice la Best Practice che è il codice della strada; in questo dominio ha senso avere dei vincoli rigidi e gestire le attività stesse seguendo dei processi
il dominio Complicato (Complicated domain) è simile a quello Ovvio, anche se le relazioni causa/effetto dei fenomeni non sono ovvie e comprensibili da tutti ma solo da degli esperti; in questo tipo di dominio ha senso agire seguendo delle Good Practice, soggette a valutazione e interpretazione da un esperto, le decisioni saranno prese secondo un modello del tipo Percepire – Analizzare – Rispondere (Sense – Analyse – Respond); per esempio una malattia nota richiede una conoscenza medica e la conoscenza di un protocollo terapeutico, occorrerà la valutazione di un medico; in questo dominio ha senso avere dei vincoli di governo, nel nostro esempio le prescrizioni generali del protocollo terapeutico, che però dovranno poi essere interpretate e applicate dal medico, che è l’esperto
il dominio Complesso (Complex domain) è quello in cui le relazioni causa/effetto dei fenomeni possono essere comprese solo a posteriori, ma non in anticipo; in questo tipo di dominio si seguono e si plasmano delle Emergent Practice, che sono delle pratiche innovative basate sulla sperimentazione, o delle cosiddette Exaptive Practice, che sono l’adattamento di capacità e abilità già a presenti a nuove esigenze; in entrambi i casi le decisioni saranno prese secondo un modello Esplorare – Percepire – Rispondere (Probe – Sense – Respond); per esempio una malattia nuova richiede necessariamente della sperimentazione e l’adattamento di capacità, abilità e tecniche mediche già note a un nuovo contesto terapeutico e il protocollo terapeutico viene creato, modificato in modo dinamico e continuamente migliorato; in questo dominio ha senso avere solo dei vincoli abilitanti, ovvero delle regole che aiutano il sistema a procedere più spedito, come lo sono per esempio le regole di una metodologia di lavoro agile quale Scrum
il dominio Caotico (Chaotic domain) è quello in cui non ci sono relazioni causa/effetto e se ci sono non possono essere comprese; in questo dominio ci sono solo delle Novel Practice, nelle quali le decisioni saranno prese secondo un modello Agire – Percepire – Rispondere (Act – Sense – Respond); queste sono le tipiche situazioni di emergenza, dove si tende ad agire e fare immediatamente qualcosa senza porre limiti o vincoli, salvo poi provare a capire se quello che si è fatto può essere replicabile e cercare di spostarsi verso un dominio diverso, di solito quello Complesso
Il quinto dominio, quello del Disordine (Disorder domain) è quello in cui non è chiaro quale sia il modello interpretativo da applicare, è quello in cui ci troviamo la maggior parte del tempo ed è quello più insidioso; in questo dominio infatti la tendenza è a interpretarlo secondo la propria zona di confort o secondo la propria esperienza con il rischio di prendere decisioni secondo un modello errato; se sono una persona metodica e mi trovo a mio agio a gestire processi avrò la tendenza a considerare tutto ovvio e ad applicare processi anche dove i processi non funzionano e non possono funzionare

La tensione del genere umano è da sempre quella spostare quante più situazioni progressivamente dal dominio Caotico verso quello Complesso, poi verso quello Complicato e infine a quello Ovvio. Bisogna però stare attenti a interpretare le situazioni e collocarle nel dominio corretto, vediamo alcuni esempi.

La ipersemplificazione di ciò che semplice non è, per esempio prendere decisioni di tipo medico secondo il modello del dominio Ovvio, può far perdere il controllo della situazione e farci precipitare nel dominio Caotico, in figura rappresentato dal ‘dirupo’ tra il dominio Ovvio e quello Caotico.

Anche mettere troppi vincoli a qualcosa che appartiene correttamente al dominio Ovvio ci potrebbe far precipitare nel dominio Caotico: un limite di velocità troppo basso in autostrada fa precipitare l’autostrada nel caos.

È abbastanza evidente che la sottovalutazione iniziale dell’emergenza COVID che stiamo affrontando, la narrazione del COVID come se fosse una normale influenza, quindi gestendolo nel migliore dei casi secondo lo schema del dominio Complicato, nel peggiore secondo lo schema del dominio Ovvio e non più correttamente secondo lo schema del dominio Complesso come avrebbe dovuto essere, ci ha precipitato verso il dominio Caotico. A quel punto le reazioni sono state quelle corrette, i protocolli terapeutici e le misure di contenimento si sono sviluppati secondo lo schema Agire – Percepire – Rispondere tipiche del dominio Caotico. Progressivamente, man mano che le Novel Practice hanno cominciato a essere individuate, abbiamo quindi cominciato a spostare i protocolli terapeutici e le azioni nel dominio Complesso: i protocolli terapeutici che si stanno consolidando per via sperimentale sono delle Emergent Practice e si sono visti anche esempi di Exaptive Practice, il più mediatico dei quali è sicuramente stato l’adattamento delle maschere da snorkeling per l’ossigenazione dei pazienti in terapia sub-intensiva. Con l’andare del tempo e il consolidamento dell’esperienza e dei protocolli terapeutici ci sposteremo auspicabilmente verso il dominio al quale vogliamo che la medicina appartenga che è il dominio Complicato, anche se come sappiamo c’è sempre una deriva latente verso la medicina fai da te, quindi verso il dominio Ovvio, che però è pericoloso, come anche l’esperienza del COVID ci ha insegnato.

Lascio al lettore l’esercizio di andare più nello specifico ad analizzare alla luce di questo modello di interpretazione i singoli comportamenti che si sono visti nei mesi in cui è esplosa l’emergenza, sia da parte dei cittadini che delle istituzioni ai vari livelli. Non è difficile e il fatto sorprendente è che Cynefin aiuta a mettere in luce in maniera piuttosto lampante le letture corrette o errate che sono state fatte dai vari attori nelle varie situazioni.

Abbiamo parlato fin qui dell’aspetto medico-sanitario, ma avvicinandosi il momento della fine del lockdown e della ripartenza, ci sarà da rileggere tutto il contesto socio-economico-organizzativo e il modello interpretativo di Cynefin può essere di aiuto per non sbagliare l’approccio decisionale ed evitare di precipitare nel dominio Caotico. Alcuni modelli organizzativi apparterranno ai medesimi domini di prima dell’emergenza COVID, altri invece richiederanno un profondo ripensamento. La convivenza con il virus negli ambienti di lavoro richiederà che molte attività che prima erano gestite secondo le logiche tipiche del dominio Ovvio dovranno cominciare a essere gestite secondo logiche più tipiche del dominio Complesso, quindi in modo euristico, sperimentale e agile oppure secondo le logiche del dominio Complicato, quindi con l’aiuto di esperti.