Tag: ITIL

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.

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 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

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 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

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

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.