Cosa introduce ITIL 5<\/h2>\n\n\n\n
ITIL 5 introduce un modello di ciclo di vita di prodotti e servizi digitali con otto attivit\u00e0: Discover, Design, Acquire, Build, Transition, Operate, Deliver, Support. ITIL precisa che non vanno eseguite come un ciclo: dal punto di vista dell\u2019organizzazione formano la catena del valore, cio\u00e8 l\u2019insieme delle attivit\u00e0 che abilitano il valore. Ogni organizzazione ne include alcune o tutte e le combina, secondo il proprio contesto, nei flussi del valore<\/em> (value stream<\/em>).<\/p>\n\n\n\n La novit\u00e0 rispetto a ITIL 4 \u00e8 che a ciascuna attivit\u00e0 \u00e8 associato un elenco di metriche chiave di successo. In ITIL 4 le metriche stavano nelle pratiche. Cycle time, wait time e lead time c\u2019erano gi\u00e0, ma a livello di flusso e di pratiche, non di attivit\u00e0.<\/p>\n\n\n\n Guardando l\u2019insieme delle metriche, alcune saltano all\u2019occhio. La soddisfazione <\/em>compare in tutte e otto le attivit\u00e0: quella degli stakeholder in sette, quella di clienti e utenti in Deliver e in Support. L\u2019aderenza alla roadmap <\/em>o alla strategia<\/em> in sette. Un tempo <\/em>esplicito compare in quattro: Design, Acquire, Build e Transition, a cui si aggiunge la velocit\u00e0 di ripristino<\/em> in Support. Discover, Operate e Deliver non hanno nessuna metrica di tempo.<\/p>\n\n\n\n Le corrispondenze con il KMM sono molte.<\/p>\n\n\n\n Per la transizione ITIL misura il numero <\/em>e l\u2019impatto degli errori di transizione<\/em>, cio\u00e8 dei rilasci andati male. Un rilascio andato male genera rilavorazioni, e il lavoro che ne nasce nel KMM si chiama failure demand<\/em>: la domanda che arriva perch\u00e9 la qualit\u00e0 iniziale non bastava.<\/p>\n\n\n\n Per la qualit\u00e0 ITIL misura specifiche, risorse<\/em> e soluzioni<\/em>. Nel KMM la qualit\u00e0 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\u2019hanno generata.<\/p>\n\n\n\n Per Deliver e Support ITIL misura la performance rispetto agli SLA concordati<\/em>. Nel KMM corrispondono la puntualit\u00e0 di consegna e gli impegni di servizio basati sui percentili di lead time.<\/p>\n\n\n\n Per la soddisfazione di stakeholder, clienti e utenti ITIL ha una misura in ogni attivit\u00e0. Nel KMM corrispondono gli indicatori di fitness for purpose<\/em>, ricavati dai criteri con cui il cliente sceglie il servizio.<\/p>\n\n\n\n Poi in ITIL troviamo le metriche di tempo: design cycle time<\/em>, acquire cycle time<\/em>, building cycle<\/em>, transition cycle<\/em> e velocit\u00e0 di ripristino<\/em>. Nel KMM le grandezze corrispondenti sono lead time<\/em> e cycle time<\/em>, che si leggono come percentili sulle rispettive curve di distribuzione.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u00e0 agli stakeholder. Non compaiono n\u00e9 il funzionamento pull <\/em>n\u00e9 i limiti al lavoro in corso<\/em>. A mio avviso la rappresentazione che ITIL offre di Kanban \u00e8 semplificata, come gi\u00e0 scrivevo a proposito di ITIL 4: il metodo \u00e8 molto pi\u00f9 ricco.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Prendiamo per esempio i rilasci andati male. In ITIL si misura il numero e l\u2019impatto 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<\/em>: un rifacimento di qualcosa che era gi\u00e0 stato fatto. Cos\u00ec facendo sappiamo in ogni momento quanta percentuale complessiva del lavoro \u00e8 costituita da rilavorazioni.<\/p>\n\n\n\n Quanto possono pesare in percentuale le rilavorazioni? In Kanban: Successful Evolutionary Change for Your Technology Business<\/em>, David Anderson riporta il caso di un team che spendeva il 90% della capacit\u00e0 disponibile nella correzione di difetti. Un flusso cos\u00ec \u00e8 intasato da lavoro che nasce da lavoro gi\u00e0 fatto male, e le nuove richieste aspettano.<\/p>\n\n\n\n Nelle organizzazioni pi\u00f9 mature le rilavorazioni contano contro il limite del lavoro in corso: se ce ne sono troppe, non entra nuovo lavoro finch\u00e9 i problemi di qualit\u00e0 non sono stati risolti. I dati su difetti e rilavorazioni si guardano poi nelle revisioni periodiche, dove si decide cosa fare per ridurli.<\/p>\n\n\n\n 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\u201985\u00b0 percentile \u00e8 il riferimento abituale, ma non \u00e8 una regola: se un ritardo costa molto, conviene salire. Sulla base dello SLE definito si concorda lo SLA con il cliente in modo realistico.<\/p>\n\n\n\n Le metriche di tempo che ITIL associa alle attivit\u00e0, cio\u00e8 design cycle time, acquire cycle time, building cycle e transition cycle, misurano ciascuna un singolo passaggio. ITIL ha poi una misura dell\u2019intero flusso del valore, il lead time, dall\u2019avvio alla consegna, e indica le otto attivit\u00e0 come un buon punto di partenza per mappare i flussi. ITIL non dice per\u00f2 da dove parta il lead time.<\/p>\n\n\n\n Il KMM lo precisa, e parla dello stesso oggetto: quello che ITIL chiama flusso del valore, nel KMM \u00e8 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.<\/p>\n\n\n\n Un passaggio pu\u00f2 avere un buon tempo di ciclo e il cliente aspettare comunque a lungo, perch\u00e9 nel tempo di ciclo non ci sono le attese tra un passaggio e l\u2019altro. L\u2019esperienza 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.<\/p>\n\n\n\n Lo stesso vale per la velocit\u00e0 di ripristino del servizio, che in ITIL compare in Support. \u00c8 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.<\/p>\n\n\n\n Resta la soddisfazione di stakeholder, clienti e utenti, che ITIL misura in tutte e otto le attivit\u00e0. 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\u00ec si ricavano gli indicatori da misurare: tempi di consegna per classe di servizio, quota di richieste consegnate senza rilavorazione, costo.<\/p>\n\n\n\n \u00c8 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<\/em> diventa la sintesi di tutte le metriche, classiche e no.<\/p>\n\n\n\n ITIL 5 dedica molto spazio all\u2019intelligenza artificiale, e la collega alla visione olistica e all\u2019individuazione 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. \u00c8 un buon punto di partenza.<\/p>\n\n\n\n Una volta definito il flusso, si misura e si individua il collo di bottiglia, ed \u00e8 l\u00ec che va applicata l\u2019AI. 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\u00f2 essere anche uno spreco: si accelera una stazione di lavoro che \u00e8 gi\u00e0 pi\u00f9 scarica del collo di bottiglia. Prendiamo uno sviluppo software: se l\u2019AI fa scrivere il codice pi\u00f9 in fretta, ma il collo di bottiglia, a monte, \u00e8 la risposta del cliente sui requisiti poco chiari, il lavoro accelerato resta in attesa. Non \u00e8 cambiato nulla.<\/p>\n\n\n\n C\u2019\u00e8 poi un secondo ragionamento. Spesso il lavoro \u00e8 fatto per lo pi\u00f9 di attese, e accelerare il lavoro effettivo, come fa l\u2019AI quando velocizza un compito, cambia poco il lead time. Ne ho scritto in un articolo recente<\/a>, e l\u00ec la domanda diventa un\u2019altra: come usare l\u2019AI per ridurre le attese.<\/p>\n\n\n\n Sono partito da ITIL 5, che dice cosa misurare per ciascuna attivit\u00e0 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.<\/p>\n\n\n\n Anche per l\u2019intelligenza artificiale vale lo stesso ragionamento: serve dove c\u2019\u00e8 il collo di bottiglia, non dove il lavoro \u00e8 gi\u00e0 veloce. E resta necessario qualcuno che gestisca il sistema di lavoro, AI compresa.<\/p>\n\n\n\n Ho pubblicato originariamente questo articolo per il portale Kanban Help<\/a>, al quale collaboro insieme al collega Luca Gambetti. Ho appena terminato di tenere un corso ITIL 5 Foundation. Mentre raccontavo le otto attivit\u00e0 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 … Continua a leggere ITIL5 e le metriche del ciclo di vita: dove entra Kanban e dove serve l’intelligenza artificiale<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[618,8,105,130],"tags":[373,635,397,619,636,374,634,99,217,179,183,507,631],"class_list":["post-2786","post","type-post","status-publish","format-standard","hentry","category-ai-intelligenza-artificiale","category-idee","category-itil","category-kanban","tag-ai","tag-ciclo-di-vita","tag-collo-di-bottiglia","tag-cycle-time","tag-failure-demand","tag-intelligenza-artificiale","tag-itil5","tag-kanban","tag-kanban-maturity-model","tag-lead-time","tag-metriche","tag-sla","tag-sle"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\tLe metriche e il Kanban Maturity Model<\/h2>\n\n\n\n
Cosa ITIL 5 dice sul livello operativo<\/h2>\n\n\n\n
Dalle metriche alla pratica<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.kanban.systems\/blog\/wp-content\/uploads\/2026\/10\/flusso-valore-percentile-1024x313.png\")
<\/figure>\n\n\n\nL\u2019intelligenza artificiale: dove serve e dove no<\/h2>\n\n\n\n
Conclusione<\/h2>\n\n\n\n
Bibliografia<\/h2>\n\n\n\n
\n
Visita Kanban Help – www.kanban.help<\/a> – per conoscere gli strumenti formativi e di coaching che ti possono aiutare a introdurre il metodo Kanban nella tua azienda.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"