Ai recenti Stati Generali delle Ingegnerie Digitali, tenutisi a Milano gli scorsi 18 e 19 Aprile, ho fatto un intervento dal titolo ‘Utilizzare lean e kanban per il miglioramento dei servizi: l’Enterprise Services Planning (ESP)‘ che ho voluto concludere con una provocazione: Proviamo ad applicarlo… per esempio per risolvere il problema dei tempi di attesa dei passaporti? Perché sono convinto che si potrebbe affrontare il problema dei tempi di attesa dei passaporti con Kanban. L’applicazione di concetti e pratiche del metodo Kanban potrebbe infatti dare una grossa mano a snellire tutti quei i servizi al cittadino che si trovano a essere ‘ingolfati’, non solo il rilascio dei passaporti. Migliorando i livelli di servizio offerti ai cittadini e al contempo riducendo la pressione e il conseguente stress lavorativo che grava sugli uffici preposti.
Tempi di attesa troppo lunghi
Non conosco in dettaglio il flusso di lavoro per il rilascio dei passaporti, osservo il problema della lunghezza dei tempi di attesa dalla prospettiva del semplice cittadino. Sono però ben noti al pubblico due fenomeni ai quali si sente imputare la forte crescita di richieste di passaporti: la brexit, che obbliga chi si reca nel Regno Unito a dotarsi di passaporto (prima bastava la carta di identità) e la pandemia, che ha fortemente limitato i viaggi per un paio d’anni, facendo rinviare a molti il rinnovo del passaporto. Ora che nel dopo-pandemia c’è la frenesia di tornare a viaggiare, i due fattori menzionati hanno generato un carico superiore a quello che le strutture preposte sono evidentemente in grado di evadere in tempi rapidi. La situazione non è omogenea, ma in alcune zone di Italia (per esempio a Milano) occorre attendere diversi mesi per ottenere il passaporto. Come sempre accade il servizio in sofferenza ha ingenerato meccanismi distorti, c’è chi acquista biglietti aerei low cost per ottenere un appuntamento prioritario e pare che a un certo punto ci fosse anche chi faceva incetta di appuntamenti per rivenderli a caro prezzo. Questi espedienti non possono essere ovviamente la soluzione, invece il sovraccarico di un servizio al cittadino è una tipica circostanza che può trarre un grande beneficio dall’applicazione del metodo Kanban.
In effetti alcune pratiche suggerite dal metodo Kanban già stanno venendo applicate. Recentemente la Polizia di Stato ha introdotto l’Agenda Prioritaria degli appuntamenti, per gestire in modo codificato le situazioni in cui il cittadino non può attendere i mesi necessari per il rilascio standard. Tale pratica in Kanban la si definirebbe come l’introduzione di classi di servizio, ovvero il modo in cui qualcosa viene trattato una volta inserito nel sistema. In un sistema Kanban si attribuisce la classe di servizio a una determinata lavorazione in base a quanto costa ritardare detta lavorazione. Più elevato è il costo di rimandare la lavorazione, prima si dovrà effettuare la lavorazione. Nel caso dei passaporti, i cittadini che lo richiedono non sono tutti nella stessa situazione, qualcuno può aspettare il tempo di evasione standard mentre qualcun altro ha necessità di viaggiare in tempi brevi e non può aspettare. Nel sistema di prenotazione dei passaporti possiamo quindi identificare due classi di servizio: una che potremmo definire come ‘standard‘, il passaporto viene rilasciato nei tempi tipici previsti dal sistema (qualche mese) e un’altra classe di servizio che potremmo definire come ‘accelerata‘ (‘expedite‘ nell’originale in inglese), che permette il rilascio del passaporto in base all’Agenda Prioritaria (qualche giorno).
Introdurre le policy per il servizio
Le classi di servizio però da sole non sono sufficienti per stabilizzare il servizio, occorre anche definire delle regole per l’assegnazione di una determinata classe di servizio a una lavorazione. Lasciando libero l’utente di attribuire alla propria lavorazione una classe di servizio, ci si troverebbe solo con lavorazioni di classe ‘accelerata’ e sappiamo che se tutto diventa urgente, allora nulla è più urgente perché chi si trova a dover effettuare la lavorazione non riesce più a indentificare le vere urgenze. E infatti se andiamo a vedere nel sistema di prenotazione dei passaporti la pagina dell’Agenda Prioritaria, un avviso in testa alla pagina indica chiaramente le regole per ottenere un appuntamento: “Gli appuntamenti disponibili valgono solamente per i residenti nella provincia. Rientrano tra le condizioni di priorità i viaggi da intraprendere nei prossimi 30 giorni per le seguenti motivazioni: studio, lavoro, salute, turismo. All’atto dell’appuntamento verrà richiesta la documentazione comprovante l’effettiva priorità e la data del viaggio.” Tale pratica in Kanban sarebbe definita come l’introduzione di policy di servizio, appunto le regole da applicare per garantire un corretto funzionamento del servizio. Quindi regole non solo per l’assegnazione della classe di servizio, ma regole in generale che permettano al servizio di funzionare in modo stabile e affidabile. E infatti se andiamo a leggere il vademecum sul sito della Questura di Milano, si può notare che si applicano anche alcune ulteriori regole, ovvero che nell’Agenda Ordinaria si possono “prendere fino ad un massimo di n.4 appuntamenti complessivi” mentre nell’Agenda Prioritaria si possono “prendere fino ad un massimo di n.2 appuntamenti non modificabili”. Questo a ulteriore garanzia del corretto utilizzo del sistema di prenotazione e per evitare almeno il più possibile i funzionamenti distorti.
Accelerare il collo di bottiglia
Osservata con la lente del metodo Kanban, la direzione intrapresa per la gestione del sistema di rilascio dei passaporti è corretta, innanzitutto è necessario stabilizzare il sistema. Una volta che il sistema è stabile, analizzando e misurando le fasi del flusso di lavoro, è possibile individuare il collo di bottiglia e, come ho già illustrato in un precedente articolo a proposito dei flussi autostradali, vincolare tutto il sistema alla velocità del proprio collo di bottiglia. Al flusso che procede alla stessa velocità del collo di bottiglia è possibile quindi applicare i concetti propri della teoria dei vincoli e della teoria delle code, provando ad accelerarlo, per diminuire il tempo medio di lavorazione, nel nostro caso il tempo medio di rilascio dei passaporti, e per aumentare per converso il numero di passaporti rilasciati per unità di tempo (o come si chiama in Kanban, ‘throughput‘ o ‘delivery rate‘). C’è da augurarsi che le autorità preposte vogliano portare fino in fondo il percorso intrapreso per la gestione dei passaporti, applicando questi concetti per migliorare questo e altri servizi ai cittadini.
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.
Questa è la storia di come è nato il metodo Kanban. Dopo aver introdotto con successo il primo programma Kanban di Microsoft, il team di Sustaining Engineering, che gestisce le Change Request interne di Microsoft, è passato dall’avere le peggiori performance dell’azienda ad avere le migliori, nonostante la dislocazione geografica sfavorevole, dimostrando l’adattabilità e l’efficacia dei principi di Kanban. Questo caso sfata anche in modo eclatante alcune credenze diffuse sul metodo Kanban: che il metodo Kanban funzioni solo con team piccoli e co-locati e che Kanban sia sinonimo di strumenti visuali e in particolare della Kanban board.
Ho già ricordato in un precedente articolo come David J Anderson abbia creato il metodo Kanban perché non riusciva ad applicare in modo soddisfacente i metodi agili su larga scala e ho evidenziato commentando il case study su BBVA come Kanban possa aiutare invece a migliorare l’efficacia e la scalabilità di Scrum.
Lo scenario
Per comprendere le sfide affrontate dal team di Sustaining Engineering prima dell’utilizzo di Kanban, è utile comprendere la complessità dell’organizzazione IT di Microsoft. All’epoca, Microsoft operava come sette unità aziendali distinte, ciascuna con una propria funzione IT, oltre a un’unità della sede centrale che gestiva i servizi condivisi aziendali. XIT si occupava dei servizi condivisi, concentrandosi sul supporto IT e su applicazioni quali il sistema di anagrafica dei dipendenti per le risorse umane e il sistema di gestione delle buste paga gestito dall’unità finanziaria di Microsoft.
Sustaining Engineering, con sede a Hyderabad, in India, era un piccolo team incaricato di mantenere e migliorare queste applicazioni IT al di fuori delle release principali e degli aggiornamenti delle applicazioni. Tuttavia, il team era afflitto da problemi, tra cui tempi lunghi, scarsa affidabilità e promesse non mantenute. La situazione era ulteriormente aggravata da una differenza di fuso orario di 13 ore tra la sede centrale di Microsoft a Seattle e Hyderabad.
(continua dopo l’immagine)
Le sfide
Una delle principali sfide affrontate dal team di Sustaining Engineering era la mancanza di visibilità sugli obiettivi o sulle iniziative aziendali di alto livello della multinazionale americana. Le richieste di modifiche e correzioni di bug arrivavano spesso in modo isolato, rendendo difficile comprenderne l’importanza strategica. Il team era essenzialmente un servizio che prendeva ordini e spesso non era chiaro il contesto di business in cui queste richieste erano inserite.
Inoltre, il team soffriva di un lavoro arretrato eccessivo, con un tempo medio di cinque mesi per le richieste di modifica. Questo, unito all’abitudine di fare promesse di consegna che non si potevano mantenere, aveva eroso la fiducia dei clienti. Inoltre, il team era vincolato da determinati requisiti, tra cui l’obbligo di utilizzare processi di sviluppo software strutturati che non sempre funzionavano bene in un ambiente virtuale.
Anche la necessità di stimare l’effort e il costo delle singole Change Request contribuiva in modo significativo ai problemi di Sustaining Engineering. Il team doveva calcolare il potenziale ritorno sull’investimento (ROI) di ogni richiesta prima di decidere se procedere, il che richiedeva tempo e sforzi considerevoli. Il lavoro sulle stime doveva essere fatto prima di affrontare qualunque lavoro pianificato e contribuiva a ritardare ulteriormente le consegne.
La soluzione
Come primo passo, il team ha smesso di elaborare stime e le ha sostituite con accordi sui livelli di servizio, sperando che il cambio migliorasse i tempi di consegna e la soddisfazione dei clienti. Il responsabile del team ha anche deciso di introdurre Kanban come soluzione, utilizzando una strategia che prevedeva diversi cambiamenti chiave nel processo:
Limitare il lavoro in corso (WIP): l’imposizione di limiti al WIP nello sviluppo e nei test ha permesso al team di concentrarsi su un numero gestibile di attività alla volta.
Sostituzione della pianificazione mensile: le riunioni di pianificazione mensili sono state sostituite da riunioni di ‘replenishment’ settimanali per adattarsi più efficacemente ai cambiamenti di priorità.
Gestione del flusso: il team si è dato l’obiettivo di dare visibilità della quantità massima di lavoro che poteva essere consegnato tra una riunione settimanale e la successiva, e anche di rendere esplicite le policy che avrebbero fatto funzionare meglio il processo nel suo insieme.
Semplificazione della comunicazione: invece di farsi inviare le nuove richieste di lavoro a Hyderabad per la stima, il team ha comunicato più frequentemente e direttamente con le parti interessate.
Prima di fare partire questo nuovo modo di lavorare, il responsabile del team si è impegnato in una azione ‘diplomatica’. Ha incontrato i singoli stakeholder per spiegare i cambiamenti proposti e chiarire che il loro ruolo nell’organizzazione non veniva messo in discussione o minacciato in alcun modo. L’iniziativa si è rivelata vincente e le parti interessate hanno accettato di impegnarsi nei cambiamenti prima del vero e proprio kickoff.
I risultati
I risultati sono stati eccellenti, tanto che da questa esperienza è stato sviluppato il metodo Kanban che si poi è diffuso in tutto il mondo:
sistema virtuale a chiamata “pull”, senza nessuna lavagna visuale
230% di aumento di produttività
91% di riduzione del lead time (tempo di attraversamento del sistema) medio
puntualità delle consegne dallo 0% al 98%
il tutto in 15 mesi e a un costo sostanzialmente nullo, con un team distribuito tra Redmond negli Stati Uniti e Hyderabad in India
Il case study completo è disponibile sui siti 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.
BBVA è una delle maggiori banche internazionali e un pioniere nell’introduzione dei metodi Agile nel settore bancario globale, che ha concretamente migliorato la propria applicazione di Scrum grazie a Kanban. La gestione di servizi e progetti che richiedono un elevato livello di lavoro di conoscenza e devono rispettare scadenze rigorose, richiede un processo decisionale rapido e una gestione flessibile, per cui nel 2014 la banca ha avviato, a partire dai sistemi informativi gestionali del settore finanza, l’adozione di metodi di lavoro Agile e in particolare Scrum per soddisfare meglio le aspettative dei propri clienti.
Le sfide
Tuttavia, i responsabili dei programmi si sono scontrati con difficoltà e sfide legate alla trasformazione delle aree della banca nel loro complesso. I progetti rappresentavano una piccola parte di tutto il lavoro svolto e non era chiaro come il ‘business-as-usual’, il lavoro corrente, dovesse essere gestito in parallelo ai progetti, soprattutto quando c’erano forti dipendenze da persone con determinate competenze. Era inoltre necessario collegare tutti i team che fornivano prodotti e servizi in un’entità che lavorasse in modo sincronizzato per soddisfare le aspettative dei clienti in modo prevedibile e sostenibile. Pertanto, la percezione generale era che, sebbene Scrum fosse appropriato per i team di progetto, per diventare una vera organizzazione Agile sarebbe stato necessario evolvere oltre e introdurre altre pratiche.
E’ a questo punto che Teodora Bozheva, autrice del Case Study, si era unita ai team di coach che facilitavano la trasformazione Agile in BBVA. La prima analisi condotta con l’ausilio del modello di maturità Kanban aveva evidenziato i seguenti problemi:
Scarsa visualizzazione, limitando così la comprensione condivisa del carico di lavoro effettivo.
Mancanza di limiti al lavoro in corso (WIP – Work in Progress). I flussi di lavoro gestiti dai team erano congestionati, con poca o nessuna attenzione all’organizzazione del lavoro e a limitare il WIP per agevolare la stabilizzazione dei flussi di lavoro stessi.
Cattiva gestione di flussi di lavoro, che causava frequenti interruzioni e cambi di priorità, gestione ad hoc delle situazioni bloccanti e mancanza di comprensione qualitativa della domanda e delle capacità dei team.
Mancanza di processi definiti, che costringevano le persone a gestire i compiti da svolgere piuttosto che a concentrarsi sui risultati.
Mancanza di indicatori chiave di performance, che facevano concentrare i manager sull’ottimizzazione delle risorse piuttosto che sul miglioramento dell’erogazione del servizio.
(continua dopo l’immagine)
La soluzione
L’introduzione delle pratiche Kanban per supportare e migliorare l’applicazione di Scrum, insieme all’adozione di una gestione orientata al servizio hanno portato cambiamenti positivi, tra cui una maggiore flessibilità nella gestione dei progetti e nella contemporanea erogazione dei servizi ‘business-as-usual’, un migliore coordinamento delle dipendenze e una migliore collaborazione e comunicazione tra i team. L’adozione di un orientamento al servizio e di un pensiero in termini di flusso è stato essenziale per aumentare l’agilità e raggiungere obiettivi come un più rapido time-to-market, l’adattabilità alle mutevoli esigenze del mercato, la trasparenza, la collaborazione e il miglioramento continuo. L’uso del metodo Kanban e del modello di maturità Kanban ha fornito una preziosa guida e ha aiutato l’area Finance di BBVA a evolversi in un’entità più agile e orientata al cliente. E’ stato quindi possibile nel tempo estendere la modalità di lavoro Agile in modo coordinato e sincronizzato a più di 30.000 dipendenti gestendo in modo efficace le interdipendenze tra i vari team.
Nel maggio del 2020, il team Core Data, che era stato il pioniere dell’introduzione del metodo Kanban in BBVA, riportava i seguenti dati relativi ai miglioramenti effettuati nel solo 2019:
riduzione del 28% dei costi di gestione (tempo dedicato alle cerimonie di Scrum)
riduzione del 25% del tempo di risposta alle richieste di informazioni
17% di riduzione dei tempi di risoluzione degli incidenti
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.
Kanban è molto di più che la semplice ‘kanban board’. Il Metodo Kanban codifica oltre 150 pratiche in relazione a 7 livelli di maturità organizzativa. In un keynote speech del maggio 2017, David J Anderson, creatore del metodo Kanban, ha proposto il Metodo Kanban come un vero e proprio percorso alternativo all’agilità aziendale.
Anderson cita un sondaggio condotto intervistando 300 CIO britannici, dal quale è emerso che “più della metà dei CIO ritiene che la metodologia agile sia ormai screditata, mentre tre quarti non sono più disposti a difenderla come metodo di svolgimento dei progetti. Inoltre, la metà dei CIO ritiene che i processi agili siano solo una moda dell’IT.” Anderson sottolinea quindi come il metodo Kanban sia nato (in Microsoft a partire dal 2004) perché personalmente non era riuscito ad applicare i metodi agili su larga scala nelle grandi aziende per le quali aveva lavorato in precedenza (Sprint, Motorola) e questo prima ancora che i metodi agili si chiamassero così (il Manifesto per lo Sviluppo Agile di Software è del 2001).
Just say #no______ Un percorso alternativo all’agilità aziendale
Il Metodo Kanban si pone quindi come percorso alternativo, come l’approccio meno dirompente all’agilità aziendale e l’alternativa più radicale ad Agile (con la ‘A’ maiuscola) perché si basa sui seguenti elementi:
#noRevolutionaryChange Applicare Kanban significa partire da dove si è, non significa rivoluzionare l’azienda. Con Kanban il cambiamento è evolutivo, per piccoli passi.
#noEstimates Le stime sono costose e inutili. Meglio analizzare i trend storici e la distribuzione statistica dei lead time (tempo di attraversamento del sistema).
#noIterations Lavorare con gli sprint costringe a frammentare gli elementi di lavoro più grandi e si creano delle inutili interdipendenze tra uno sprint e l’altro. Meglio gestire un flusso continuo di lavoro con limiti al Work In Progress (lavoro in corso).
#noPlanning La pianificazione del lavoro è costosa e inutile. Meglio pianificare l’ecosistema in cui avviene il lavoro (servizi, workflow, valutazione dei rischi, policy, classi di servizio, criteri decisionali), cominciando a ottimizzare i singoli servizi dell’organizzazione e poi collegandoli.
#noPrioritization La prioritizzazione è costosa e inutile. Meglio rendere trasparenti gli elementi concreti di rischio e di costo del ritardo e selezionare dinamicamente il prossimo elemento di lavoro in base a quello.
#noBacklogGrooming Che è costoso e inutile. Meglio lasciare il backlog così com’è e usare i filtri decisionali basati sul rischio e sul costo del ritardo per selezionare il prossimo elemento di lavoro.
#noDependencyManagement Mappare le dipendenze è inutile e costoso. Meglio gestire solo le dipendenze con un elevato costo del ritardo e gestire un sistema di prenotazione della capacità produttiva dei servizi a valle che possono causare criticità ai servizi a monte.
#noCrossFunctionalTeams Riorganizzare i team e renderli co-locati è inutile e costoso. Meglio lasciare i team così come sono e dove sono, facendo invece in modo che le persone siano allineate verso il raggiungimento di obiettivi comuni, anche se appartengono a organizzazioni diverse in posizioni geografiche diverse.
e infine
#noPrescriptiveProcessDefinition Kanban non è una metodologia, non è anti-Agile, non vi impone un framework, dei processi o altro e non stravolge quello che state facendo. Vi aiuta però a renderlo migliore e a costruire il vostro percorso verso l’agilità aziendale.
Approfondiremo prossimamente ciascuno di questi temi, qui su Kanban Help.
Cosa ha ottenuto chi ha applicato Kanban
La prima applicazione di Kanban in Microsoft nel 2005 ha portato ai seguenti risultati:
sistema virtuale a chiamata “pull”, senza nessuna lavagna visuale
230% di aumento di produttività
91% di riduzione del lead time (tempo di attraversamento del sistema) medio
puntualità delle consegne dallo 0% al 98%
il tutto in 15 mesi e a un costo sostanzialmente nullo, con un team distribuito tra Redmond negli Stati Uniti e Hyderabad in India
La seconda applicazione in Hewlett-Packard nel 2006 ha portato ai seguenti risultati:
sistema virtuale a chiamata “pull”, senza nessuna lavagna visuale
700% di aumento di produttività
lead time medio di realizzazione del firmware per le stampanti laser di nuova generazione ridotto da 21 mesi a 3 mesi e mezzo
settimana lavorativa di 4 giorni e mezzo
il tutto in meno di un anno e a un costo sostanzialmente nullo
A queste sono seguite numerose applicazioni in tutto il mondo con risultati analoghi, anche in Italia, anche per noi di Kanban Help.
State lavorando con Scrum o altri framework agili e faticate a ottenere dei risultati soddisfacenti? Kanban vi può aiutare a far funzionare meglio quello che fate già!
Qui sotto trovate il link per ascoltare il keynote speech originale su YouTube.
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.
"... mi sono reso conto che la maratona poteva darmi innumerevoli spunti per mettere alla prova e sperimentare concretamente i metodi di project management e anche essere una potente metafora per farli comprendere agli altri ..."
Questo blog utilizza cookie necessari al funzionamento ed utili alle finalità illustrate nella privacy policy.
Cliccando sul tasto "OK", scorrendo questa pagina, cliccando su un link o proseguendo la navigazione in altra maniera, si acconsente all'uso di tutti i cookie.OKPer saperne di più o negare il consenso a tutti o ad alcuni cookie clicca qui
consulenza operativa
formazione certificata
profilo LinkedIn
video
@pmmaratona
Pillole di Kanban applicato: affrontare il problema dei tempi di attesa dei passaporti con Kanban
Ai recenti Stati Generali delle Ingegnerie Digitali, tenutisi a Milano gli scorsi 18 e 19 Aprile, ho fatto un intervento dal titolo ‘Utilizzare lean e kanban per il miglioramento dei servizi: l’Enterprise Services Planning (ESP)‘ che ho voluto concludere con una provocazione: Proviamo ad applicarlo… per esempio per risolvere il problema dei tempi di attesa dei passaporti?
Perché sono convinto che si potrebbe affrontare il problema dei tempi di attesa dei passaporti con Kanban. L’applicazione di concetti e pratiche del metodo Kanban potrebbe infatti dare una grossa mano a snellire tutti quei i servizi al cittadino che si trovano a essere ‘ingolfati’, non solo il rilascio dei passaporti. Migliorando i livelli di servizio offerti ai cittadini e al contempo riducendo la pressione e il conseguente stress lavorativo che grava sugli uffici preposti.
Tempi di attesa troppo lunghi
Non conosco in dettaglio il flusso di lavoro per il rilascio dei passaporti, osservo il problema della lunghezza dei tempi di attesa dalla prospettiva del semplice cittadino. Sono però ben noti al pubblico due fenomeni ai quali si sente imputare la forte crescita di richieste di passaporti: la brexit, che obbliga chi si reca nel Regno Unito a dotarsi di passaporto (prima bastava la carta di identità) e la pandemia, che ha fortemente limitato i viaggi per un paio d’anni, facendo rinviare a molti il rinnovo del passaporto. Ora che nel dopo-pandemia c’è la frenesia di tornare a viaggiare, i due fattori menzionati hanno generato un carico superiore a quello che le strutture preposte sono evidentemente in grado di evadere in tempi rapidi.
La situazione non è omogenea, ma in alcune zone di Italia (per esempio a Milano) occorre attendere diversi mesi per ottenere il passaporto. Come sempre accade il servizio in sofferenza ha ingenerato meccanismi distorti, c’è chi acquista biglietti aerei low cost per ottenere un appuntamento prioritario e pare che a un certo punto ci fosse anche chi faceva incetta di appuntamenti per rivenderli a caro prezzo. Questi espedienti non possono essere ovviamente la soluzione, invece il sovraccarico di un servizio al cittadino è una tipica circostanza che può trarre un grande beneficio dall’applicazione del metodo Kanban.
Immagine fonte Wikipedia licenza Creative Commons CC BY 3.0
Introdurre le classi di servizio
In effetti alcune pratiche suggerite dal metodo Kanban già stanno venendo applicate. Recentemente la Polizia di Stato ha introdotto l’Agenda Prioritaria degli appuntamenti, per gestire in modo codificato le situazioni in cui il cittadino non può attendere i mesi necessari per il rilascio standard.
Tale pratica in Kanban la si definirebbe come l’introduzione di classi di servizio, ovvero il modo in cui qualcosa viene trattato una volta inserito nel sistema. In un sistema Kanban si attribuisce la classe di servizio a una determinata lavorazione in base a quanto costa ritardare detta lavorazione. Più elevato è il costo di rimandare la lavorazione, prima si dovrà effettuare la lavorazione.
Nel caso dei passaporti, i cittadini che lo richiedono non sono tutti nella stessa situazione, qualcuno può aspettare il tempo di evasione standard mentre qualcun altro ha necessità di viaggiare in tempi brevi e non può aspettare. Nel sistema di prenotazione dei passaporti possiamo quindi identificare due classi di servizio: una che potremmo definire come ‘standard‘, il passaporto viene rilasciato nei tempi tipici previsti dal sistema (qualche mese) e un’altra classe di servizio che potremmo definire come ‘accelerata‘ (‘expedite‘ nell’originale in inglese), che permette il rilascio del passaporto in base all’Agenda Prioritaria (qualche giorno).
Introdurre le policy per il servizio
Le classi di servizio però da sole non sono sufficienti per stabilizzare il servizio, occorre anche definire delle regole per l’assegnazione di una determinata classe di servizio a una lavorazione. Lasciando libero l’utente di attribuire alla propria lavorazione una classe di servizio, ci si troverebbe solo con lavorazioni di classe ‘accelerata’ e sappiamo che se tutto diventa urgente, allora nulla è più urgente perché chi si trova a dover effettuare la lavorazione non riesce più a indentificare le vere urgenze. E infatti se andiamo a vedere nel sistema di prenotazione dei passaporti la pagina dell’Agenda Prioritaria, un avviso in testa alla pagina indica chiaramente le regole per ottenere un appuntamento:
“Gli appuntamenti disponibili valgono solamente per i residenti nella provincia.
Rientrano tra le condizioni di priorità i viaggi da intraprendere nei prossimi 30 giorni per le seguenti motivazioni: studio, lavoro, salute, turismo.
All’atto dell’appuntamento verrà richiesta la documentazione comprovante l’effettiva priorità e la data del viaggio.”
Tale pratica in Kanban sarebbe definita come l’introduzione di policy di servizio, appunto le regole da applicare per garantire un corretto funzionamento del servizio. Quindi regole non solo per l’assegnazione della classe di servizio, ma regole in generale che permettano al servizio di funzionare in modo stabile e affidabile. E infatti se andiamo a leggere il vademecum sul sito della Questura di Milano, si può notare che si applicano anche alcune ulteriori regole, ovvero che nell’Agenda Ordinaria si possono “prendere fino ad un massimo di n.4 appuntamenti complessivi” mentre nell’Agenda Prioritaria si possono “prendere fino ad un massimo di n.2 appuntamenti non modificabili”. Questo a ulteriore garanzia del corretto utilizzo del sistema di prenotazione e per evitare almeno il più possibile i funzionamenti distorti.
Accelerare il collo di bottiglia
Osservata con la lente del metodo Kanban, la direzione intrapresa per la gestione del sistema di rilascio dei passaporti è corretta, innanzitutto è necessario stabilizzare il sistema. Una volta che il sistema è stabile, analizzando e misurando le fasi del flusso di lavoro, è possibile individuare il collo di bottiglia e, come ho già illustrato in un precedente articolo a proposito dei flussi autostradali, vincolare tutto il sistema alla velocità del proprio collo di bottiglia.
Al flusso che procede alla stessa velocità del collo di bottiglia è possibile quindi applicare i concetti propri della teoria dei vincoli e della teoria delle code, provando ad accelerarlo, per diminuire il tempo medio di lavorazione, nel nostro caso il tempo medio di rilascio dei passaporti, e per aumentare per converso il numero di passaporti rilasciati per unità di tempo (o come si chiama in Kanban, ‘throughput‘ o ‘delivery rate‘).
C’è da augurarsi che le autorità preposte vogliano portare fino in fondo il percorso intrapreso per la gestione dei passaporti, applicando questi concetti per migliorare questo e altri servizi ai cittadini.
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.