ITIL4 | Il Project Management & l'arte della Maratona

Dalla formazione ITIL4 alla pratica quotidiana: il valore di un percorso di coaching Kanban

Nel mio lavoro di formatore per E-quality Italia, mi capita spesso di tenere corsi di ITIL 4, soprattutto a livello Foundation, che continuano a suscitare grande interesse da parte delle aziende italiane. Una delle domande che più frequentemente emergono durante questi incontri è tanto semplice quanto essenziale: “Come possiamo applicare concretamente nella nostra realtà aziendale quello che stiamo imparando?”

Questa domanda, pur nella sua apparente semplicità, tocca il cuore del valore formativo: trasformare concetti e framework teorici in strumenti utili per affrontare il lavoro quotidiano. In questa prospettiva, una delle risposte più efficaci – a mio avviso – è l’applicazione del metodo Kanban come leva operativa per dare concretezza ai concetti di ITIL.

Il punto di vista di ITIL 4 sul metodo Kanban

ITIL 4 nasce con l’intento di fornire un quadro di riferimento strutturato per la gestione dei servizi IT, con un’attenzione particolare alla co-creazione di valore tra chi eroga e chi utilizza i servizi. Per realizzare tale obiettivo, le organizzazioni devono imparare a migliorare continuamente i propri processi e i flussi di lavoro. È proprio qui che il metodo Kanban si rivela uno strumento operativo essenziale.

Nel materiale didattico ufficiale di ITIL 4, Kanban viene menzionato come possibile approccio per supportare la filosofia Lean. In particolare, Kanban viene descritto come un adattamento del pensiero Lean alle attività di knowledge work, cioè al lavoro concettuale e basato sulla conoscenza, tipico dell’ambiente IT. Il framework ITIL 4 identifica Kanban come utile laddove vi sia difficoltà a gestire e a dare priorità al lavoro, oppure a visualizzare con chiarezza le fasi di un processo.

Dove ITIL beneficia maggiormente di Kanban

In questo contesto, Kanban viene proposto come soluzione semplice e a basso rischio, che può aiutare le organizzazioni a migliorare l’efficienza, visualizzare i processi in corso, limitare il lavoro simultaneo (WIP – Work In Progress), gestire il flusso delle attività e rilevare eventuali blocchi o colli di bottiglia. Tutti elementi che contribuiscono a rendere più fluido e prevedibile il funzionamento dei team. È una proposta che si allinea al principio guida di ITIL “Keep it simple and practical” (Mantenere semplicità e praticità).

Secondo ITIL, il valore per il cliente è generato attraverso i cosiddetti value stream, i flussi di valore che attraversano le varie attività e componenti del sistema dei servizi. In questo senso, Kanban rappresenta uno strumento concreto per rendere visibili tali flussi, individuare inefficienze, ridurre gli sprechi e migliorare la capacità di risposta del sistema. Per questo motivo, Kanban può contribuire efficacemente a tutte le attività della service value chain, come la pianificazione, la progettazione e transizione, la realizzazione e la messa in esercizio dei servizi, il supporto e, naturalmente, il miglioramento continuo.

Una visione condivisa: ITIL e Kanban parlano una lingua simile

Sebbene la rappresentazione che ITIL offre di Kanban sia piuttosto semplificata – il metodo Kanban è in realtà molto più ricco e articolato – l’integrazione tra i due non è solo possibile, ma del tutto coerente e naturale. Entrambi si ispirano ai principi del pensiero Lean e al Toyota Production System. Ne condividono le radici teoriche, i valori e l’approccio sistemico al lavoro.

Il metodo Kanban si basa su alcune pratiche generali che risultano coerenti con i principi ITIL: visualizzare il lavoro, limitare il lavoro in corso, gestire attivamente il flusso, rendere esplicite le regole di gestione, introdurre cicli di feedback e promuovere il miglioramento continuo attraverso la sperimentazione e la collaborazione.

Il vero potere del metodo Kanban risiede nell’adozione sistemica di queste pratiche, nella gestione attiva dei flussi di lavoro e nella capacità di adattarsi dinamicamente alle esigenze del sistema. È in questa prospettiva che Kanban diventa uno strumento strategico, non solo operativo, per applicare ITIL.

Come usare concretamente Kanban per applicare ITIL

Arrivati a questo punto, sorge però spontanea un’altra domanda: “Ma quindi, in pratica, come si fa?”. La risposta passa da un confronto tra l’approccio strutturato di ITIL e la natura evolutiva di Kanban.

Mentre ITIL propone un modello organico, con ruoli definiti e processi strutturati, difficili da introdurre in un’organizzazione, Kanban suggerisce un’evoluzione graduale, senza imporre cambiamenti drastici iniziali. Non richiede di cambiare i ruoli esistenti, ma lavora con ciò che c’è, facilitando l’evoluzione naturale delle pratiche organizzative.

Dalla mia esperienza, la chiave è quindi partire dal basso: individuare un team reale, osservare il suo modo di lavorare e iniziare ad applicare i principi e le pratiche di Kanban ai suoi flussi attuali. In questo modo, ITIL rimane lo sfondo di riferimento, un benchmark con cui confrontarsi, mentre Kanban diventa il vero strumento quotidiano per far evolvere l’organizzazione di servizi.

Per questo motivo, nel mio lavoro accompagno le organizzazioni a partire da ciò che già fanno, utilizzando ITIL e altri framework non come prescrizioni rigide, ma come linee guida per aiutare a individuare i work item, a definire delle policy di servizio, stabilire cadenze operative e strutturare cicli di feedback, facendo leva sul metodo Kanban.

In sostanza, ITIL fornisce la cornice concettuale, ma è attraverso l’approccio pragmatico ed evolutivo di Kanban che possiamo muoverci, passo dopo passo, verso un’implementazione efficace e sostenibile di servizi migliori.

Conclusione

L’adozione combinata di ITIL e Kanban offre una risposta concreta a chi si chiede come portare nella pratica i concetti appresi nei corsi ITIL. Utilizzando Kanban come strumento per gestire il lavoro, organizzare i flussi, visualizzare i problemi e strutturare i cicli di feedback, diventa possibile calare ITIL nella realtà quotidiana delle organizzazioni, trasformando un framework complesso in una linea guida pratica al miglioramento.

In definitiva, ITIL ci suggerisce dove andare. Kanban ci permette di arrivarci, un passo alla volta.

Bibliografia

ITIL

ITIL® Foundation – ITIL4 Edition, The Stationery Office, 2020
ITIL®4: Create, Deliver and Support, The Stationery Office, 2020
ITIL®4: Direct, Plan and Improve, The Stationery Office, 2020
ITIL®4: Drive Stakeholder Value, The Stationery Office, 2020
ITIL®4: High-velocity IT, The Stationery Office, 2020
ITIL®4: Digital and IT Strategy, The Stationery Office, 2020

Kanban

David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010
David J. Anderson, Teodora Bozheva, Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention – 2nd Edition, Kanban University Press, 2021

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.

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.