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.
Per recarmi in Svizzera a svolgere alcuni corsi di formazione devo percorrere una delle tratte autostradali credo più congestionate al mondo, tra la frontiera italiana di Como e Lugano Nord. La tratta complessiva che devo percorrere da casa al centro di formazione è lunga 85 km e richiede approssimativamente due ore per essere percorsa, sia all’andata al mattino che al ritorno alla sera. L’andamento del traffico non è costante, anche se si tratta di un fenomeno che può essere studiato e che è statisticamente prevedibile perché segue una distribuzione gaussiana. Si tratta di una tipica situazione che si può gestire con un sistema Kanban per garantire la puntualità del trainer in aula e infatti finora non ho mai iniziato un corso in ritardo. Grazie anche agli svizzeri che gestiscono le congestioni autostradali utilizzando gli stessi concetti che stanno alla base di Kanban.
La tratta autostradale svizzera, che si snoda in un fondo valle tra le montagne, risulta la parte più problematica e congestionata. Ho notato però che gli svizzeri gestiscono il traffico autostradale di quella tratta super congestionata utilizzando un sistema basato sulla teoria dei vincoli, quindi applicando gli stessi principi che hanno ispirato Anderson nella messa a punto del metodo Kanban. Vediamo come.
il semaforo in autostrada
Il vincolo sta nel collo di bottiglia
Alla base del ragionamento c’è la constatazione che un sistema di flusso, come è anche un’autostrada, è vincolato dal suo collo di bottiglia. Se in autostrada ci sono delle strozzature o dei punti particolarmente congestionati, la quantità di mezzi oraria che può percorrere l’autostrada (che in Kanban chiamiamo Throughput) sarà limitata dal più lento di tali strozzature e punti congestionati. Se noi riusciamo in qualche modo a far fluire il traffico alla stessa velocità del collo di bottiglia, il flusso si stabilizza e poi possiamo provare ad accelerarlo, aumentando il throughput e diminuendo il tempo di percorrenza di ciascun mezzo. Concetto intuitivo in teoria, un po’ meno in pratica perché si tratta di andare piano per essere più veloci.
La legge di Little
L’altro concetto che ci aiuta è la Legge di Little, che si può applicare solo in presenza di sistemi con distribuzione statistica gaussiana (e il traffico in autostrada lo è), per cui si possono fare i calcoli utilizzando i valori medi come valori di riferimento. La Legge di Little è una funzione lineare che lega la quantità di elementi medi presenti in un sistema alla velocità di attraversamento media del sistema stesso. La relazione è L = λ x W, dove L è il numero dei elementi mediamente presenti nel sistema (nel nostro caso i mezzi), λ è il tasso di arrivo medio, che si suppone costante (nel nostro caso quanti mezzi entrano in autostrada al minuto), e W è il tempo medio di attraversamento del sistema (nel nostro caso il tempo per percorrere la tratta autostradale). Facendo qualche semplice simulazione con la Legge di Little si può verificare facilmente come in un sistema si possa minimizzare la velocità di percorrenza (e di conseguenza massimizzare il throughput) se non lo si carica oltre il 65%-70% della sua capacità di carico massima teorica. In Kanban applichiamo questo mettendo dei limiti al WIP – Work In progress (lavoro in corso, nel nostro caso il numero di mezzi presenti sulla tratta autostradale). Concetto questo invece del tutto controintuitivo.
La soluzione del problema dell’autostrada
Mettere insieme questi due concetti per la gestione dell’autostrada significa fare come fanno gli svizzeri:
utilizzare un semaforo per frenare il flusso a monte (tipicamente all’ingresso di una galleria prima del tratto congestionato)
regolare tramite il semaforo l’accesso al sistema, evitando di caricare il sistema oltre il limite che tende a bloccarlo, limite che è determinato dal collo di bottiglia
fare rispettare rigidamente il limite di velocità di 80 km/h per mantenere il flusso stabile
Così facendo il sistema si stabilizza e il risultato è sorprendente, perché dopo l’attesa per accedere al sistema (che mediamente non supera mai i 15′) si riesce comodamente a percorrere la tratta a 80km/h in circa mezz’ora, che sono abbastanza sicuro essere un tempo ottimizzato.
Di ritorno alla sera, terminata la tratta in territorio svizzero, si passa la frontiera e i flussi non sono più regolati, per cui si può osservare e anche provare a misurare la differenza. Per quanto riguarda la tratta italiana, soprattutto all’andata, il metodo Kanban lo ho applicato io in modo tale da assicurarmi di avere tempi di percorrenza prevedibili e affidabili, ma di questo parlerò in un altro articolo.
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.
In questo webinar del gennaio 2021, David J Anderson, autore del metodo Kanban, sottolinea come un mito della comunità Agile sia stato clamorosamente sfatato dalla pandemia: non è vero che rendere i team stabili e co-locati fa automaticamente aumentare la collaborazione e la produttività. Nei fatti, abbiamo sperimentato tutti come lavorando in smart-working dal tavolo della cucina di casa siamo più produttivi e la collaborazione con i colleghi non ha subito cambiamenti nella maggior parte dei casi semplicemente perché non c’era nemmeno in ufficio.
La collaborazione si costruisce dandosi scopo e obiettivi comuni e perseguendoli con costanza, a prescindere dalla stabilità del team e dalla collocazione geografica.
Anderson suggerisce quindi un modello per il futuro: la capacità delle singole persone di pensarsi come una piccola organizzazione orientata ai servizi che lavora per la più ampia organizzazione aziendale; allo stesso tempo la capacità delle aziende di sviluppare quella che viene definita ‘produttività relazionale’, ovvero imparare a collaborare davvero nel lavoro reale per dare risultati di valore ai propri clienti.
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.
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.
Qui sopra potete ascoltare l’intervista. Auguro veramente a tutti di potersi dedicare ad attività che valorizzino la nostra umanità per fare cose straordinarie assieme.
Una delle domande che ci stiamo facendo tutti è come ripartire quando sarà allentato il lockdown che si è reso necessario a causa dell’emergenza COVID. C’è molto fermento a livello politico, sociale e aziendale su ‘cosa fare’, anche se ritengo che sia molto più importante chiedersi prima ‘cosa ha senso fare’ e ‘che modello operativo ha senso applicare’ per procedere e per decidere, perché il rischio che corriamo è quello di interpretare la situazione a seconda di come siamo fatti noi e quindi applicare istintivamente i modelli che ci sono più congeniali o riproporre in modo più o meno consapevole i modelli che siamo abituati ad applicare a un contesto che però è radicalmente cambiato. Per comprendere quale modello operativo/decisionale abbia senso applicare si può utilizzare Cynefin (si pronuncia: /ˈkʌnɨvɪn/), un framework di interpretazione della realtà e di scelta delle strategie per affrontare le diverse situazioni del quale avevo già parlato in un precedente post di qualche anno fa e che nel frattempo ha acquisito popolarità.
Cynefin individua
cinque domini rappresentativi della realtà in cui ci troviamo e l’esercizio
consiste nel comprendere in quale dominio si trovi ogni situazione da gestire:
il dominio Ovvio (Obvious domain) è quello in cui le relazioni causa/effetto dei fenomeni sono appunto ovvie e comprensibili da tutti; in questo tipo di dominio ha senso agire seguendo delle cosiddette Best Practice, secondo schemi noti per cui le decisioni saranno prese secondo un modello del tipo Percepire – Categorizzare – Rispondere (Sense – Categorise – Respond); per esempio le convenzioni dell’andare per strada sono ovvie e note a tutti e le decisioni saranno prese categorizzando le situazioni che si presentano secondo quello che dice la Best Practice che è il codice della strada; in questo dominio ha senso avere dei vincoli rigidi e gestire le attività stesse seguendo dei processi
il dominio Complicato (Complicated domain) è simile a quello Ovvio, anche se le relazioni causa/effetto dei fenomeni non sono ovvie e comprensibili da tutti ma solo da degli esperti; in questo tipo di dominio ha senso agire seguendo delle Good Practice, soggette a valutazione e interpretazione da un esperto, le decisioni saranno prese secondo un modello del tipo Percepire – Analizzare – Rispondere (Sense – Analyse – Respond); per esempio una malattia nota richiede una conoscenza medica e la conoscenza di un protocollo terapeutico, occorrerà la valutazione di un medico; in questo dominio ha senso avere dei vincoli di governo, nel nostro esempio le prescrizioni generali del protocollo terapeutico, che però dovranno poi essere interpretate e applicate dal medico, che è l’esperto
il dominio Complesso (Complex domain) è quello in cui le relazioni causa/effetto dei fenomeni possono essere comprese solo a posteriori, ma non in anticipo; in questo tipo di dominio si seguono e si plasmano delle Emergent Practice, che sono delle pratiche innovative basate sulla sperimentazione, o delle cosiddette Exaptive Practice, che sono l’adattamento di capacità e abilità già a presenti a nuove esigenze; in entrambi i casi le decisioni saranno prese secondo un modello Esplorare – Percepire – Rispondere (Probe – Sense – Respond); per esempio una malattia nuova richiede necessariamente della sperimentazione e l’adattamento di capacità, abilità e tecniche mediche già note a un nuovo contesto terapeutico e il protocollo terapeutico viene creato, modificato in modo dinamico e continuamente migliorato; in questo dominio ha senso avere solo dei vincoli abilitanti, ovvero delle regole che aiutano il sistema a procedere più spedito, come lo sono per esempio le regole di una metodologia di lavoro agile quale Scrum
il dominio Caotico (Chaotic domain) è quello in cui non ci sono relazioni causa/effetto e se ci sono non possono essere comprese; in questo dominio ci sono solo delle Novel Practice, nelle quali le decisioni saranno prese secondo un modello Agire – Percepire – Rispondere (Act – Sense – Respond); queste sono le tipiche situazioni di emergenza, dove si tende ad agire e fare immediatamente qualcosa senza porre limiti o vincoli, salvo poi provare a capire se quello che si è fatto può essere replicabile e cercare di spostarsi verso un dominio diverso, di solito quello Complesso
Il quinto dominio, quello del Disordine (Disorder domain) è quello in cui non è chiaro quale sia il modello interpretativo da applicare, è quello in cui ci troviamo la maggior parte del tempo ed è quello più insidioso; in questo dominio infatti la tendenza è a interpretarlo secondo la propria zona di confort o secondo la propria esperienza con il rischio di prendere decisioni secondo un modello errato; se sono una persona metodica e mi trovo a mio agio a gestire processi avrò la tendenza a considerare tutto ovvio e ad applicare processi anche dove i processi non funzionano e non possono funzionare
La tensione del genere umano è da sempre quella spostare quante più situazioni progressivamente dal dominio Caotico verso quello Complesso, poi verso quello Complicato e infine a quello Ovvio. Bisogna però stare attenti a interpretare le situazioni e collocarle nel dominio corretto, vediamo alcuni esempi.
La
ipersemplificazione di ciò che semplice non è, per esempio prendere decisioni
di tipo medico secondo il modello del dominio Ovvio, può far perdere il
controllo della situazione e farci precipitare nel dominio Caotico, in figura
rappresentato dal ‘dirupo’ tra il dominio Ovvio e quello Caotico.
Anche mettere troppi vincoli a qualcosa che appartiene correttamente al dominio Ovvio ci potrebbe far precipitare nel dominio Caotico: un limite di velocità troppo basso in autostrada fa precipitare l’autostrada nel caos.
È abbastanza evidente che la sottovalutazione iniziale dell’emergenza COVID che stiamo affrontando, la narrazione del COVID come se fosse una normale influenza, quindi gestendolo nel migliore dei casi secondo lo schema del dominio Complicato, nel peggiore secondo lo schema del dominio Ovvio e non più correttamente secondo lo schema del dominio Complesso come avrebbe dovuto essere, ci ha precipitato verso il dominio Caotico. A quel punto le reazioni sono state quelle corrette, i protocolli terapeutici e le misure di contenimento si sono sviluppati secondo lo schema Agire – Percepire – Rispondere tipiche del dominio Caotico. Progressivamente, man mano che le Novel Practice hanno cominciato a essere individuate, abbiamo quindi cominciato a spostare i protocolli terapeutici e le azioni nel dominio Complesso: i protocolli terapeutici che si stanno consolidando per via sperimentale sono delle Emergent Practice e si sono visti anche esempi di Exaptive Practice, il più mediatico dei quali è sicuramente stato l’adattamento delle maschere da snorkeling per l’ossigenazione dei pazienti in terapia sub-intensiva. Con l’andare del tempo e il consolidamento dell’esperienza e dei protocolli terapeutici ci sposteremo auspicabilmente verso il dominio al quale vogliamo che la medicina appartenga che è il dominio Complicato, anche se come sappiamo c’è sempre una deriva latente verso la medicina fai da te, quindi verso il dominio Ovvio, che però è pericoloso, come anche l’esperienza del COVID ci ha insegnato.
Lascio al lettore l’esercizio di andare più nello specifico ad analizzare alla luce di questo modello di interpretazione i singoli comportamenti che si sono visti nei mesi in cui è esplosa l’emergenza, sia da parte dei cittadini che delle istituzioni ai vari livelli. Non è difficile e il fatto sorprendente è che Cynefin aiuta a mettere in luce in maniera piuttosto lampante le letture corrette o errate che sono state fatte dai vari attori nelle varie situazioni.
Abbiamo parlato fin qui dell’aspetto medico-sanitario, ma avvicinandosi il momento della fine del lockdown e della ripartenza, ci sarà da rileggere tutto il contesto socio-economico-organizzativo e il modello interpretativo di Cynefin può essere di aiuto per non sbagliare l’approccio decisionale ed evitare di precipitare nel dominio Caotico. Alcuni modelli organizzativi apparterranno ai medesimi domini di prima dell’emergenza COVID, altri invece richiederanno un profondo ripensamento. La convivenza con il virus negli ambienti di lavoro richiederà che molte attività che prima erano gestite secondo le logiche tipiche del dominio Ovvio dovranno cominciare a essere gestite secondo logiche più tipiche del dominio Complesso, quindi in modo euristico, sperimentale e agile oppure secondo le logiche del dominio Complicato, quindi con l’aiuto di esperti.
Chi ha familiarità con le modalità di lavoro agile e i suoi vari framework di riferimento, dovrebbe aver sentito parlare del concetto di Velocity, che è la principale metrica di riferimento che viene utilizzata per misurare quanto lavoro un team di sviluppo può completare con successo nel corso di un intervallo di tempo fisso detto Sprint. Ma sappiamo cosa significa davvero misurare la Velocity di un team?
Il termine, per assonanza, tende a essere sempre tradotto con “velocità” per cui la metrica nella percezione comune diventa la “velocità del team“ e la sensazione è che il team debba ricercare la propria efficienza, che però per il modo di pensare agile è un controsenso.
In un contesto di lavoro agile infatti, quale per esempio Scrum, quello che importa non è tanto l’efficienza del team quanto la sua capacità di permettere al proprio cliente, in Scrum rappresentato dal ruolo del Product Onwer, di ottenere i risultati che creano valore per il cliente stesso.
Questi risultati che creano valore in inglese sono detti Outcome e infatti si dice che le metriche per misurare un team agile devono essere Outcome based.
Per fare un esempio semplice ma efficace del concetto appena espresso, in un contesto agile a nessuno importa quanto un team sia efficiente a piantare chiodi o ad avvitare viti, quello che importa è la capacità di appendere quadri nel modo desiderato dal proprio Product Owner entro un tempo ragionevole previsto dal team e utile al Product Owner.
Siamo allora sicuri che “velocità” sia la traduzione corretta per il termine Velocity? Anche perché chiunque conosca un inglese anche elementare sa che normalmente “velocità” si traduce con “speed”. E quindi?
La spiegazione sta in un’altra delle mie passioni sportive, la barca a vela. Perché la parola Velocity in realtà è un termine nautico con un significato ben preciso e tutto mi fa pensare che chi ha adottato questo termine per i team agili abbia voluto utilizzare una metafora sportiva e in particolare velica, che però è risultata talmente sottile che quasi nessuno la ha colta.
La velocità di una barca a vela si misura con due grandezze: la velocità propria della barca nell’acqua (Speed Through Water – STW) che è quella che si percepisce navigando e la velocità effettiva sulla superficie terrestre (Speed Over Ground – SOG) che è quella che ci dice quanto la barca di sta effettivamente spostando. Senza qui addentrarsi in spiegazioni tecniche, le due velocità sono correlate ma non sono quasi mai uguali per via delle dinamiche dell’acqua. Sempre per fare un esempio semplice, si pensi a una barca che naviga contro corrente in un fiume dove c’è una corrente pari alla velocità della barca stessa; la STW sarà positiva, la barca rispetto all’acqua si muove, la SOG sarà nulla, rispetto alla superficie terrestre la barca è ferma.
La STW ci dice quanto rapidamente la barca si muove sull’acqua, quindi ci da un’indicazione di quanto è efficiente il moto della barca, la SOG ci dice quanto rapidamente la barca si muove sulla superfice terrestre, quindi ci da un’indicazione di quanto è efficace il moto della barca. Da notare che entrambe in inglese sono Speed, nessuna delle due è Velocity, che è un concetto ancora diverso. Cosa è la Velocity allora?
Nel disegno ho
riportato una spiegazione un po’ semplificata del concetto velico di Velocity.
Una barca non può muoversi contro vento, al massimo può tenere un angolo di circa 45° rispetto alla direzione del vento. Se si vuole quindi raggiungere un obiettivo che sta controvento, occorre bordeggiare, ovvero ‘zigzagare’ come in figura con angoli di 45° rispetto alla direzione del vento e così facendo ci si avvicinerà al punto obiettivo. Quello che ci interessa non è né la STW, né la SOG ma la velocità con cui la barca si avvicina al punto obiettivo, che in inglese viene chiamata appunto Velocity Made good on Course (VMC), che è la componente della SOG che ci sta avvicinando al punto obiettivo.
Quindi il sottinteso di chi ha scelto il termine Velocity è che il team deve misurare la propria capacità relativa di avvicinarsi al punto obiettivo (che fuori di metafora è il risultato che crea valore per il Product Owner) e non tanto la propria efficienza di azione intrinseca (Speed Through Water – STW) ma nemmeno la propria efficacia assoluta (Speed Over Ground – SOG), perché per raggiungere l’obiettivo del Product Owner il team deve saper combinare la propria efficienza ed efficacia con una strategia che permetta di impiegare al meglio gli elementi propulsivi disponibili (il vento) per riuscire a raggiungere l’obiettivo nel tempo più breve possibile, ma senza compromettere il risultato. E chi ha esperienza di navigazione a vela sa bene che questa strategia di impiego degli elementi propulsivi disponibili è l’elemento che fa la differenza tra un buon velista e un principiante ed è più decisiva e importante rispetto a efficienza ed efficacia del mezzo, perché se si sbaglia il percorso o non si capisce come gira il vento e si finisce controvento, la barca si ferma.
Fuori dalla metafora velica, si usa quindi il termine Velocity perché non importa quanto il team agile sia efficiente e nemmeno quanto sia efficace, ma quanto sia complessivamente abile nel progredire il più rapidamente possibile verso gli obiettivi che creano valore per il cliente.
“Tutto andrebbe semplificato il più possibile, ma non di più” (Albert Einstein)
L’affermazione nel titolo sembra di un’ovvietà disarmante. Lo è in teoria anche se in pratica le cose stanno diversamente perché è proprio la difficoltà delle persone ad organizzarsi a livello personale che spesso fa fallire i sistemi organizzativi aziendali, sopratutto se tale difficoltà è incontrata dalle figure di vertice, che tra l’altro sono quelle maggiormente oberate di impegni e che più necessitano di una buona organizzazione personale.
Insieme ai colleghi condividiamo spesso riflessioni sui progetti organizzativi che ciascuno di noi ha portato avanti negli anni in varie aziende e ci rinforziamo sempre più nella seguente convinzione: l’organizzazione aziendale discende dall’organizzazione personale degli individui, senza quest’ultima anche le migliori pratiche organizzative faticano ad avere successo. Tale convinzione ci porta continuamente a ricercare e adottare metodiche di organizzazione personale che possano rinforzare la capacità di operare nostra e dei nostri team.
In effetti ripercorrendo i miei interventi in azienda, come anche descritto in altri articoli su questo blog, ho sempre cercato di perseguire uno sviluppo armonico in parallelo dell’organizzazione aziendale da un lato e di quella personale dei membri del team di lavoro dall’altro, anche se non sempre ho avuto a disposizione gli strumenti adatti.
Nell’ultimo anno ho quindi approfondito l’applicazione del Natural Planning Model® ideato da David Allen nell’ambito di GTD® – Getting Things Done®.
GTD® e il Natural Planning Model® offrono qualcosa in più, perché favoriscono la creazione di un vero e proprio sistema personale per la gestione di tutte le proprie attività e progetti, rigoroso e allo stesso flessibile. Il metodo, grazie alla sua struttura adattabile e scalabile, si integra perfettamente con qualunque contesto organizzativo, quale che sia la metodologia applicata.
L’aspetto che apprezzo particolarmente di questo sistema di gestione personale rispetto ad altri metodi è che il Natural Planning Model® non impone la calendarizzazione di tutte le proprie attività, ma propone una disciplinata gestione del backlog delle proprie attività, con modalità molto simili a quanto avviene per le varie metodiche agili quali Scrum, Kanban o Agile Project Management, che spesso applico nei progetti aziendali. Questo significa che il Natural Planning Model® può diventare il ‘terminale personale’ di un sistema organizzativo completo per l’azienda.
Sto personalmente applicando il Natural Planning Model®, con risultati molto soddisfacenti, per la gestione della mia vita nel suo complesso (come in effetti deve essere per massimizzarne l’efficacia) e all’interno di essa anche per la gestione di un contesto poco strutturato all’interno di una organizzazione con cui collaboro e che è in rapida evoluzione. Grazie a esso riesco a cavalcare l’onda delle varie attività che spesso fanno la loro comparsa in maniera piuttosto estemporanea e imprevista e a convogliarle in un flusso controllato e organizzato, evitando al tempo stesso il classico fenomeno del “foglio che cade tra due scrivanie” ovvero delle attività che si perdono e nessuno prende in carico. Non che prima non facessi questo, ma mi rendo conto che grazie all’applicazione di un metodo ottimizzato mi ritrovo ad operare in modo molto più efficiente ed efficace.
Il prossimo passo sarà sviluppare la nuova struttura operativa, i processi e gli schemi di flusso di gestione dei progetti per l’organizzazione in questione ma le fondamenta, a livello personale, sono già poste e sono solide. In effetti l’organizzazione già funziona, perché sono organizzati gli individui al suo interno.
“Buscar el levante por el poniente” Cristoforo Colombo
Mi è capitato, a fronte della mia proposta di applicazione di metodologie strutturate di project management, di sentirmi obiettare che per la riuscita dei progetti, più che di metodologie, occorre competenza nel merito e alle volte anche un’idea geniale e creativa.
E’ vero che le competenze di merito e le idee creative sono importanti, ma questo non è in contraddizione con l’applicazione di un metodo per la gestione strutturata dei progetti. Anzi, è vero il contrario.
Prince2, come anche altre metodologie quali PMBoK o Praxis Framework, invita alla gestione strutturata dei rischi, siano essi a impatto negativo (minacce) o che siano invece a impatto positivo (opportunità). E’ proprio questa ultima categoria che spesso viene trascurata e che deve invece essere compresa meglio.
Una gestione opportuna (identificazione, valutazione, pianificazione e implementazione di azioni di risposta) permette di classificare secondo logiche di valore i vari rischi-opportunità che si presentano – magari anche identificati tramite intuizioni geniali di qualche partecipante al progetto! – e di definire adeguate strategie e azioni di risposta per condividere, aumentare o sfruttare le opportunità che si sono presentate.
Un metodo rigoroso permette di catturare meglio e prima le intuizioni, di non disperderle e di stimolare il pensiero di tutti alla continua elaborazione di idee che possano essere funzionali alla riuscita del progetto. La classificazione per logiche di valore permette quindi di focalizzarsi sulle migliori opportunità, concentrando su di esse gli sforzi e le risorse a disposizione.
Anche l’opera di Cristoforo Colombo di “buscar el levante por el poniente” può essere annoverata tra i casi illustri di gestione virtuosa dei rischi-opportunità. Isabella di Castiglia ha saputo cogliere il valore potenziale dell’intuizione di Colombo, ma soprattutto ha saputo lavorare in modo strutturato per sfruttare al meglio il rischio-opportunità che le si era presentato.
"... 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
Mi è capitato, a fronte della mia proposta di applicazione di metodologie strutturate di project management, di sentirmi obiettare che per la riuscita dei progetti, più che di metodologie, occorre competenza nel merito e alle volte anche un’idea geniale e creativa.
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.