Tag: cycle time

ITIL5 e le metriche del ciclo di vita: dove entra Kanban e dove serve l’intelligenza artificiale

Ho appena terminato di tenere un corso ITIL 5 Foundation. Mentre raccontavo le otto attività del nuovo ciclo di vita dei prodotti e dei servizi, a ciascuna era associato un elenco di metriche di successo, e continuavo a vedere passare metriche che conosco molto bene: sono quelle tipiche dei sistemi Kanban. Avrei voluto fermarmi a raccontare cosa dice il Kanban Maturity Model (KMM) su quelle misure. Chi segue un corso come questo spesso vorrebbe anche capire come si fa nella pratica, ma un corso ITIL deve attenersi al contenuto dell’esame e non è il luogo per approfondire la parte pratica. Allora provo a farlo in questo articolo, almeno per dare qualche spunto.

Un secondo punto mi ha fatto riflettere durante il corso. ITIL 5 collega l’intelligenza artificiale alla visione olistica, quella che in Kanban chiamiamo visione sistemica (Systems Thinking), e all’individuazione dei colli di bottiglia, e dice che i miglioramenti del flusso vanno concentrati proprio lì. È un buon punto di partenza. Io ci aggiungo dove applicarla concretamente: a monte del collo di bottiglia intasa ancora di più, a valle accelera qualcosa che non ne ha bisogno. In aula ho fatto un breve accenno al concetto, qui vorrei provare a spiegarlo meglio.

Cosa introduce ITIL 5

ITIL 5 introduce un modello di ciclo di vita di prodotti e servizi digitali con otto attività: Discover, Design, Acquire, Build, Transition, Operate, Deliver, Support. ITIL precisa che non vanno eseguite come un ciclo: dal punto di vista dell’organizzazione formano la catena del valore, cioè l’insieme delle attività che abilitano il valore. Ogni organizzazione ne include alcune o tutte e le combina, secondo il proprio contesto, nei flussi del valore (value stream).

La novità rispetto a ITIL 4 è che a ciascuna attività è associato un elenco di metriche chiave di successo. In ITIL 4 le metriche stavano nelle pratiche. Cycle time, wait time e lead time c’erano già, ma a livello di flusso e di pratiche, non di attività.

Guardando l’insieme delle metriche, alcune saltano all’occhio. La soddisfazione compare in tutte e otto le attività: quella degli stakeholder in sette, quella di clienti e utenti in Deliver e in Support. L’aderenza alla roadmap o alla strategia in sette. Un tempo esplicito compare in quattro: Design, Acquire, Build e Transition, a cui si aggiunge la velocità di ripristino in Support. Discover, Operate e Deliver non hanno nessuna metrica di tempo.

Le metriche e il Kanban Maturity Model

Le corrispondenze con il KMM sono molte.

Per la transizione ITIL misura il numero e l’impatto degli errori di transizione, cioè dei rilasci andati male. Un rilascio andato male genera rilavorazioni, e il lavoro che ne nasce nel KMM si chiama failure demand: la domanda che arriva perché la qualità iniziale non bastava.

Per la qualità ITIL misura specifiche, risorse e soluzioni. Nel KMM la qualità si misura sul risultato finale: la quota di richieste consegnate senza rilavorazione. Quando si registra una rilavorazione, occorre risalire a quali specifiche, risorse o soluzioni l’hanno generata.

Per Deliver e Support ITIL misura la performance rispetto agli SLA concordati. Nel KMM corrispondono la puntualità di consegna e gli impegni di servizio basati sui percentili di lead time.

Per la soddisfazione di stakeholder, clienti e utenti ITIL ha una misura in ogni attività. Nel KMM corrispondono gli indicatori di fitness for purpose, ricavati dai criteri con cui il cliente sceglie il servizio.

Poi in ITIL troviamo le metriche di tempo: design cycle time, acquire cycle time, building cycle, transition cycle e velocità di ripristino. Nel KMM le grandezze corrispondenti sono lead time e cycle time, che si leggono come percentili sulle rispettive curve di distribuzione.

Cosa ITIL 5 dice sul livello operativo

ITIL 5 fornisce la cornice concettuale, il modello di ciclo di vita e i principi guida per orientare le decisioni, e lascia il dettaglio delle procedure operative ad altre fonti: le ITIL Practice Guide ufficiali, DevOps, PRINCE2 per il project management. Lo stesso ITIL dichiara che nessun framework da solo basta. Tratta anche il flusso, con la mappatura dei flussi del valore, e usa le metriche di tempo per individuare colli di bottiglia e ritardi.

Su Kanban dice due cose. Lo definisce come un metodo per visualizzare il lavoro, individuare blocchi e conflitti di risorse e gestire il lavoro in corso. E cita le Kanban board tra gli strumenti per dare visibilità agli stakeholder. Non compaiono né il funzionamento pull né i limiti al lavoro in corso. A mio avviso la rappresentazione che ITIL offre di Kanban è semplificata, come già scrivevo a proposito di ITIL 4: il metodo è molto più ricco.

Io propongo Kanban per governare e gestire i flussi. Per governare i flussi intendo applicare le pratiche e i principi del metodo Kanban, come specificati nel Kanban Maturity Model. Nel KMM il verbo governare si riferisce alle policy, che regolano il comportamento di persone e team, mentre il flusso di lavoro si gestisce. Io uso i due verbi insieme: le policy governano, e il lavoro scorre e si gestisce dentro quei confini.

Dalle metriche alla pratica

Prendiamo per esempio i rilasci andati male. In ITIL si misura il numero e l’impatto degli errori di transizione. In Kanban ragioniamo per work item, che attraversano il flusso. Se un work item arriva al rilascio e il rilascio va male, viene conteggiato e nasce un nuovo work item, marcato come failure demand: un rifacimento di qualcosa che era già stato fatto. Così facendo sappiamo in ogni momento quanta percentuale complessiva del lavoro è costituita da rilavorazioni.

Quanto possono pesare in percentuale le rilavorazioni? In Kanban: Successful Evolutionary Change for Your Technology Business, David Anderson riporta il caso di un team che spendeva il 90% della capacità disponibile nella correzione di difetti. Un flusso così è intasato da lavoro che nasce da lavoro già fatto male, e le nuove richieste aspettano.

Nelle organizzazioni più mature le rilavorazioni contano contro il limite del lavoro in corso: se ce ne sono troppe, non entra nuovo lavoro finché i problemi di qualità non sono stati risolti. I dati su difetti e rilavorazioni si guardano poi nelle revisioni periodiche, dove si decide cosa fare per ridurli.

Passiamo alla performance rispetto agli SLA concordati. In Kanban lo SLA si costruisce partendo dai dati: si misurano i lead time dei lavori consegnati e se ne costruisce la curva di distribuzione. Dalla curva si leggono i percentili e, in base al percentile opportuno, si definisce la service level expectation (SLE): entro quanti giorni consegno e in quale percentuale di casi. L’85° percentile è il riferimento abituale, ma non è una regola: se un ritardo costa molto, conviene salire. Sulla base dello SLE definito si concorda lo SLA con il cliente in modo realistico.

Le metriche di tempo che ITIL associa alle attività, cioè design cycle time, acquire cycle time, building cycle e transition cycle, misurano ciascuna un singolo passaggio. ITIL ha poi una misura dell’intero flusso del valore, il lead time, dall’avvio alla consegna, e indica le otto attività come un buon punto di partenza per mappare i flussi. ITIL non dice però da dove parta il lead time.

Il KMM lo precisa, e parla dello stesso oggetto: quello che ITIL chiama flusso del valore, nel KMM è il workflow. Il customer lead time parte dalla richiesta accettata del cliente, il system lead time dalla presa in carico del lavoro da parte del team, ed entrambi arrivano alla consegna. Quando si applica Kanban si misurano sia le metriche end to end sia quelle dei singoli passaggi, e anche le attese, e in base a queste misure si ragiona su come ottimizzare il flusso.

Un passaggio può avere un buon tempo di ciclo e il cliente aspettare comunque a lungo, perché nel tempo di ciclo non ci sono le attese tra un passaggio e l’altro. L’esperienza dice che le attese sono la parte prevalente del lead time, e di diversi casi ho scritto anche su questo blog. Per questo si lavora sulle attese: limitando il lavoro in corso, riducendo code e buffer, gestendo meglio blocchi e dipendenze.

Lo stesso vale per la velocità di ripristino del servizio, che in ITIL compare in Support. È il lead time della gestione degli incidenti, e come ogni altra metrica di tempo si misura con la distribuzione, si legge con i percentili e si trasforma in uno SLE.

Resta la soddisfazione di stakeholder, clienti e utenti, che ITIL misura in tutte e otto le attività. Nel KMM non la si misura chiedendola in astratto. Si parte dai criteri con cui il cliente decide se richiedere il servizio, o dalle fonti della sua insoddisfazione, e da lì si ricavano gli indicatori da misurare: tempi di consegna per classe di servizio, quota di richieste consegnate senza rilavorazione, costo.

È quello che facciamo in continuazione con le aziende con cui collaboro. Partiamo dalle fonti di insoddisfazione, che mi raccontano i clienti. Quando abbiamo messo a posto il servizio, verifichiamo se quelle fonti sono state risolte. Gli indicatori non sono necessariamente solo quelli classici di Kanban: dalle fonti di insoddisfazione possono emergere altri aspetti da misurare, e li misuriamo. In questo modo la fitness for purpose diventa la sintesi di tutte le metriche, classiche e no.

L’intelligenza artificiale: dove serve e dove no

ITIL 5 dedica molto spazio all’intelligenza artificiale, e la collega alla visione olistica e all’individuazione dei colli di bottiglia. Dice anche di concentrare i miglioramenti del flusso proprio sui colli di bottiglia, e di ottimizzare il flusso prima di automatizzarlo. È un buon punto di partenza.

Una volta definito il flusso, si misura e si individua il collo di bottiglia, ed è lì che va applicata l’AI. Se la si applica a monte, il lavoro si accumula davanti al collo di bottiglia e il lead time peggiora. Se la si applica a valle, il lead time non cambia in modo apprezzabile, e può essere anche uno spreco: si accelera una stazione di lavoro che è già più scarica del collo di bottiglia. Prendiamo uno sviluppo software: se l’AI fa scrivere il codice più in fretta, ma il collo di bottiglia, a monte, è la risposta del cliente sui requisiti poco chiari, il lavoro accelerato resta in attesa. Non è cambiato nulla.

C’è poi un secondo ragionamento. Spesso il lavoro è fatto per lo più di attese, e accelerare il lavoro effettivo, come fa l’AI quando velocizza un compito, cambia poco il lead time. Ne ho scritto in un articolo recente, e lì la domanda diventa un’altra: come usare l’AI per ridurre le attese.

Conclusione

Sono partito da ITIL 5, che dice cosa misurare per ciascuna attività del ciclo di vita e rimanda ad altre fonti per il dettaglio operativo. Io propongo Kanban per governare e gestire i flussi, e le metriche sono il punto da cui si comincia. I rilasci andati male diventano failure demand, gli SLA nascono dalla distribuzione dei lead time, la soddisfazione si ricava dalle fonti di insoddisfazione di chi usa il servizio, e le metriche di tempo si leggono su tutto il flusso, non solo su un singolo passaggio.

Anche per l’intelligenza artificiale vale lo stesso ragionamento: serve dove c’è il collo di bottiglia, non dove il lavoro è già veloce. E resta necessario qualcuno che gestisca il sistema di lavoro, AI compresa.

Bibliografia

  1. ITIL® Foundation, Version 5, manuale ufficiale, e ITIL® (Versione 5) Glossario principale, v5.1, luglio 2026, PeopleCert.
  2. David J. Anderson, Teodora Bozheva, Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention, 2nd Edition, Kanban University Press, 2021.
  3. David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010.

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.

Perché collegare l’AI ai vostri dati di flusso non basta: le decisioni che qualcuno deve prendere

Sono appena rientrato dal Kanban Leadership Retreat, la tre giorni annuale organizzata per la propria comunità da Kanban University. Tra i temi che hanno occupato più spazio quest’anno c’era l’AI: dove sta già cambiando il modo di lavorare di manager e knowledge worker e come il metodo Kanban possa aiutare le organizzazioni a orientarsi in un contesto tecnologico che si muove molto in fretta.

La risposta che sembra corretta finché non fate due volte la stessa domanda

Prendo spunto da una sessione proposta da Sonya Siderova, fondatrice di Nave, dedicata a flow metrics, analytics e AI agent. La domanda di partenza era semplice da porre ma non di facile risposta: che cosa succede quando si toglie la persona, lo human in the loop, dal ciclo di gestione del flusso di lavoro e si lascia decidere all’AI? Gli argomenti condivisi dal gruppo di lavoro sono stati sei: costo più elevato, difficoltà ad adattarsi a condizioni che cambiano, perdita di competenza di management, perdita di capacità di fare le domande giuste, perdita di capacità di guidare il cambiamento, perdita di gestione delle pratiche operative. Nel confronto tra un agente AI da solo e un agente affiancato da una persona, l’agente da solo non basta su nessuno di questi sei punti, nemmeno se lavora interfacciandosi con un motore di flow analytics già maturo.

Peggio ancora se l’agente accede direttamente ai dati grezzi di flusso e li elabora in autonomia. Il riscontro, dai test effettuati, è che si ottiene una risposta plausibile ma non affidabile. Il valore che l’AI aggiunge sta altrove: accedere attraverso il protocollo MCP ai dati prodotti in modo affidabile dal motore di flow analytics e costruirci sopra una narrazione, arrivando a generare raccomandazioni.

Successivamente a quella sessione, Siderova ha ripreso e sviluppato il ragionamento in un articolo che trovate su LinkedIn: https://www.linkedin.com/pulse/your-ai-can-talk-delivery-data-you-trust-answer-sonya-siderova-rfdfe

L’esempio che descrive è preciso. Qualcuno collega un LLM ai dati grezzi di flusso e chiede quanto dura normalmente un lavoro, cosa sta rallentando un team, quando saranno finiti quaranta work item. In pochi minuti arriva una risposta, e sembra che il problema sia risolto. Tre mesi dopo qualcuno rifà la stessa domanda. Nel frattempo il team ha cambiato workflow, due stati sono stati rinominati, i difetti seguono un percorso diverso. L’AI restituisce un numero diverso, e a quel punto nessuno sa più dire quale risposta fosse corretta.

Il prototipo non è la parte difficile

Siderova anticipa l’obiezione più ovvia, quella di chi ha collegato i propri dati grezzi di flusso a un LLM, ha sviluppato una demo e pensa di aver già risolto tutto: collegare l’API di strumenti quali Jira o Azure DevOps a un modello di AI non è al giorno d’oggi particolarmente difficile. La parte difficile comincia dopo la demo.

Prendete il cycle time. Dove parte il timer, alla creazione del ticket, all’ingresso in backlog o all’inizio effettivo del lavoro? Cosa succede se il work item torna indietro? Se salta uno stato? Se viene riaperto? Il tempo di attesa conta o no? Sono decisioni di misurazione, non domande che si rivolgono all’AI. Qualcuno deve prenderle, e poi assicurarsi che continuino a valere quando il workflow cambia il mese successivo, e quello dopo ancora. L’integrazione è un progetto, con un inizio e una fine. Il modello di misurazione è un prodotto: ha bisogno di un owner, di test, di manutenzione continua.

Da qui le sei domande che Siderova invita a porsi su ogni sistema, prima di fidarsi di un suo qualsiasi numero, che si tratti di uno strumento interno, di un foglio di calcolo o di una piattaforma commerciale: dove parte il cycle time, dove finisce, cosa succede quando il lavoro torna indietro, cosa succede quando un work item salta direttamente a “Fatto”, cosa succede quando un lavoro completato viene riaperto, il tempo di attesa viene conteggiato? E ne aggiunge una settima, decisiva quando quei numeri servono a prendere un impegno su una data di consegna: si sta guardando una media, o un percentile che permette davvero di valutare il rischio? Se il sistema non permette di rispondere con chiarezza a queste domande, quei numeri non possono essere usati per un impegno su una data di consegna. Un numero plausibile e un numero affidabile sono due cose diverse.

Interfaccia, non motore di calcolo

Interrogare ogni volta i dati grezzi e lasciare che sia l’LLM a interpretarli da zero è il modo più veloce per avere una risposta, ed è però anche quello che produce il problema descritto sopra, una risposta diversa ogni volta che qualcosa a monte cambia, senza che nessuno se ne accorga finché i numeri smettono di tornare. Interrogare un motore di flow analytics che applica sempre le stesse definizioni perché configurato opportunamente, con l’AI solo come interfaccia, fornisce invece risposte affidabili: la stessa domanda, posta oggi o tra sei mesi, produce una risposta diversa solo se sono cambiati i dati di flusso sottostanti, non perché è cambiata l’interpretazione di quei dati.

Non è un problema di modello di AI più o meno capace, è che le definizioni di misura non sono pattern che un LLM possa indovinare guardando i dati, sono decisioni che qualcuno deve avere già preso a monte.

Non è un problema di AI

Qui il discorso torna alla sostanza della gestione del flusso di lavoro. Dove parte il timer, come si trattano gli stati, cosa succede se c’è una rilavorazione: non sono un problema di ownership tecnica dello strumento. Sono esattamente ciò che rende maturo un sistema Kanban: policy esplicite, confini del workflow dichiarati, non lasciati all’intuito di chi in quel momento guarda la board. Un’organizzazione che non ha mai reso esplicite queste regole non scopre un problema di AI quando i numeri smettono di tornare. Scopre un problema di sistema che aveva sempre avuto, e che l’AI si limita a rendere visibile più in fretta, perché moltiplica il numero di domande poste a un sistema che non era pronto a rispondere con coerenza.

Ed è per questo motivo che trattare lo human in the loop come un tema separato dalla qualità della misurazione è fuorviante. Sono lo stesso tema visto da due lati diversi. La persona che possiede le definizioni di misurazione deve anche restare la persona che le mantiene quando il workflow cambia. Non è un ruolo che l’AI rende superfluo. Diventa anzi più necessario proprio perché l’AI abbassa il costo di fare domande al sistema.

Il punto di leva resta lo stesso di sempre

Visualizzare il flusso. Limitare il lavoro in corso. Rendere esplicite le policy, comprese quelle di misurazione che di solito nessuno scrive perché sembrano ovvie finché il numero torna. Solo dentro un sistema costruito così ha senso collegare un’AI e farsi rispondere sui propri dati di flusso di lavoro. Solo così quello che si ottiene è una risposta, oltre che plausibile, di cui ci si possa fidare.

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.