Lo Strangler Pattern che sconfigge una burocrazia

Strangler Pattern: quello usato per uccidere i mainframe

Attacchiamo un problema estremamente grande con piccoli successi che ci permettano di affrontarlo per parti di dimensioni abbastanza piccole da essere gestibili, spesso senza che la burocrazia nemmeno si renda conto di dover allestire una difesa. È lo Strangler Pattern.

Harry Potter: “Quindi se tutti i suoi Horcrux venissero distrutti, Voldemort potrebbe essere ucciso?”
Albus Silente: “Sì, credo di sì. Senza i suoi Horcrux, Voldemort sarà un uomo mortale con un’anima mutilata e ridotta”.

Le grandi organizzazioni hanno problemi grandi e cercano di risolverli sempre nello stesso modo: cercando di mangiare l’elefante in un solo boccone. Creano piani pluriennali di modernizzazione e trasformazione e mettono in attesa ogni altra cosa, a favore di queste iniziative che interessano tutto. Questi piani cercano di tener conto di ogni minimo dettaglio e di ogni caso limite, con l’intento sincero di sviluppare una soluzione perfetta, e consumano il tempo e l’attenzione dei migliori talenti dell’organizzazione. È probabile che la nostra organizzazione abbia in corso uno o più di questi piani proprio in questo momento.

Eppure, questi piani falliscono.

Dire che questo approccio probabilmente fallirà non convince mai nessuno a smettere di provarci. (Chi scrive ha tentato di convincere. Molte volte). Né gettarsi di fronte al treno in corsa servirà a fermare o far cambiare il piano. La pianificazione pluriennale è lo stato naturale di una burocrazia. Se cerchiamo di attaccare direttamente una tipica iniziativa di questo genere, verranno attivati tutti gli anticorpi e tutti i meccanismi di difesa.

Invece, possiamo aggirare completamente questo processo utilizzando lo Strangler Pattern (letteralmente, schema dello strangolatore): ritagliamoci un pezzetto ben definito dello spazio del problema, poi in silenzio e rapidamente progettiamo, testiamo e implementiamo un sostituto. Ogni pezzetto sostituito ci porta un passo più vicino alla realizzazione della nostra stella polare, ma, a differenza del piano decennale, lo Strangler Pattern funziona davvero.

Che cos’è lo Strangler Pattern

Formalmente, lo Strangler Pattern è una teoria della modernizzazione dei computer mainframe: si toglie un pezzo di funzionalità legacy alla volta e la si sostituisce con una nuova, moderna. Ripetendo lo stesso procedimento, il mainframe gigante diventa sempre più piccolo, finché non è abbastanza piccolo da poter sostituire tutto quello che resta in un colpo solo. Il meccanismo funziona, non importa se il problema sia letteralmente un mainframe tradizionale, oppure qualche altro grattacapo gigantesco all’interno della nostra organizzazione.

Il modo migliore che abbiamo trovato per descrivere lo Strangler Pattern è una analogia con il mondo di Harry Potter. (Attenzione: spoiler!) Chi non conosce la serie di libri, sappia che il mondo della magia ha un problema grave: il malvagio Voldemort. Inizialmente, i personaggi principali (Harry Potter, Silente, il Ministero della Magia) cercano di risolvere il problema come farebbe qualsiasi normale burocrazia: formulando grandi piani per affrontare direttamente Voldemort e tutti i suoi accoliti. Con il procedere della storia, questo approccio provoca la morte di quasi tutte le persone care a Harry, per non dire dei miliardi di sterline di danni alle proprietà dei babbani. Nonostante i piani più raffinati preparati dai migliori talenti della magia, alla fine Voldemort è più potente che mai.

Leggi anche: La burocrazia va affrontata con risposte adeguate

Poi Harry viene a sapere degli Horcrux e senza volerlo adotta lo Strangler Pattern. Invece di combattere direttamente Voldemort, si mette a girare il mondo distruggendo senza tanto clamore le fonti del potere di Voldemort, una dopo l’altra: un medaglione qui, un diadema là. I singoli Horcrux non sono esattamente facili da distruggere, ma una o due persone sono in grado di eliminarli, uno alla volta, Quando Voldemort si rende conto di quello che sta facendo Harry, il suo potere un tempo irresistibile è diventato così debole che basta un unico, timido adolescente (Neville) per distruggerlo completamente.

Strangolare un arretrato di domande di disoccupazione

Nell’estate del 2020, al culmine della pandemia da Covid-19, centinaia di migliaia di californiani erano nel panico. Alcuni hanno perso ogni speranza e sono arrivati a togliersi la vita. I cittadini della California facevano domanda a frotte per ottenere i benefici della disoccupazione, ma passavano le settimane e poi i mesi senza che ricevessero né denaro né risposte. Quando cercavano di telefonare per avere aiuto, nessuno rispondeva alle loro chiamate; l’ufficio per la disoccupazione faceva fatica addirittura ad aprire la posta, figuriamoci a gestirla.

Che cosa era successo? L’ufficio statale per la disoccupazione aveva rimandato per molti anni ogni minimo cambiamento ai propri processi e ai propri mainframe, in attesa dei risultati di uno sforzo di modernizzazione del sistema dei benefici pianificato meticolosamente e in atto da decenni. In teoria, il nuovo sistema avrebbe usato tecnologia moderna che avrebbe reso più facile modificare e migliorare l’esperienza di chi faceva richiesta; in pratica, quel progetto di modernizzazione aveva richiesto quasi un decennio di pianificazione e sarebbero stati necessari ancora anni prima che potesse fornire qualcosa di utile. Peggio ancora, tutti i migliori talenti tecnici e di evasione delle richieste erano assegnati a quel progetto, così che a gestire lo tsunami di domande in arrivo era rimasto un manipolo ancora più sparuto di persone.

Per tutta risposta, il governatore Newsom ha annunciato la costituzione di una squadra di pronto intervento che avrebbe cambiato le cose. Nel tentativo disperato di trovare una soluzione a breve, ha detto al team (di cui faceva parte Layer Aleph, la società di consulenza di crisi di Marina) che aveva solo quarantacinque giorni per trovare il modo di evadere oltre un milione di domande arretrate. Marina e i suoi colleghi si trovavano lanciati in una corsa ad altissima velocità (con un mainframe vecchio di decenni e un numero di collaboratori quadruplicato dalla sera alla mattina) per erogare i benefici di disoccupazione ai cittadini della California. Ogni minuto contava.

La squadra di pronto intervento ha adottato lo Strangler Pattern, suddividendo il puzzle in molti piccoli tasselli fondamentali, per riprogettarli in rapida successione.

• Un tracciatore dello stato delle domande. Un’analisi delle telefonate indicava che oltre il 98 percento delle persone chiamava per conoscere lo stato di avanzamento delle proprie pratiche, un’informazione che gli operatori del call center non potevano in effetti fornire. Un servizio dettagliato di stato delle pratiche faceva parte dello sforzo di modernizzazione pianificato, ma non era stato ancora nemmeno iniziato. Marina e il suo team, invece, hanno parlato sia con persone che avevano inoltrato domanda, sia con operatori che gestivano le pratiche, per tradurre gli avvisi di stato del sistema esistente (prevalentemente codici a tre cifre) in frasi comprensibili, in linguaggio comune. Poi hanno esportato un report esistente di questi codici di stato, una volta ogni sera, su un sito web esterno, ospitato in un ambiente cloud sicuro, che poteva gestire livelli di traffico elevati, impossibili per il mainframe. In meno di due settimane, dieci milioni di californiani sono passati dal rimanere in attesa al telefono tutto il giorno al poter usare un sito web self-service, dove potevano verificare istantaneamente lo stato delle loro pratiche e che cosa dovevano fare.
• Identificazione delle domande arretrate. L’ufficio per la disoccupazione aveva bisogno di un modo semplice per distinguere fra le pratiche che richiedevano un intervento del personale da quelle che non lo richiedevano. Senza quello, gli specialisti, che già erano al limite, perdevano tempo a lavorare su milioni di pratiche che non richiedevano in realtà il loro intervento, invece di concentrarsi sui problemi che impedivano ai richiedenti di ricevere il beneficio. Per costruire una semplice dashboard, il team ha sviluppato un elenco di ogni possibile avviso di sistema e ha affiancato gli addetti all’evasione delle pratiche per stabilire quali avvisi contassero davvero. Questa dashboard è stata costruita con Microsoft Excel, poi rielaborata con Tableau, un diffuso software di visualizzazione.
• Uno strumento di gestione del carico di lavoro. Sembra un capriccio, ma Marina e il suo team hanno costruito anche questo interamente in Microsoft Excel. L’acquisto di un sistema raffinato per pianificare e gestire i carichi di lavoro era un’altra parte del futuro progetto di modernizzazione. Per risolvere il problema nell’immediato, Marina ha parlato con ogni linea di business per ricavare delle stime sul tempo richiesto da ogni passo, sul numero delle persone assegnate a ogni passo, e sul numero delle pratiche in attesa a ogni passo. Rapidamente sono venute alla luce grandi possibilità di miglioramento. Un esempio: l’obiettivo era evadere ogni pratica in meno di 21 giorni, ma molte domande attendevano al primo passo del processo un numero di giorni già superiore a quello. Spostando più persone nella prima fase dell’elaborazione, l’ufficio per la disoccupazione ha fatto in modo che nessuna domanda rimanesse più di un giorno al livello del primo passo, il che ha aumentato il numero totale di pratiche che potevano essere evase in meno di 21 giorni.

Queste soluzioni da Strangler Pattern adottate nello Stato della California hanno richiesto poco tempo e poco denaro e si sarebbero potute implementare ancora più facilmente anni prima. Certo, è utile avere lo stimolo dell’urgenza, ma non è necessario aspettare che si verifichi una crisi nella nostra organizzazione per apportare questi tipi di miglioramenti.

Quali sono i buoni candidati per lo Strangler Pattern

Se guardo la massa, non agirò mai. Se guardo il singolo, agirò.
– Madre Teresa

Come si risolve il cambiamento climatico? Come si ottengono la pace mondiale, la salute mentale, gli obiettivi di vendita del prossimo anno? Quando il nostro cervello affronta problemi enormi, sembra chiudersi, schiacciato, incerto anche solo su dove iniziare. In questo modo è difficile fare passi avanti.

possiamo realizzare un grande cambiamento nella nostra burocrazia, o addirittura nel mondo, se possiamo mostrare agli altri come mangiare il loro elefante: un pezzetto alla volta.

Gli esempi della California funzionavano bene come candidati per lo Strangler Pattern perché:

• non esistevano già come programmi o sistemi;
• permettevano di usare report di dati già esistenti;
• avevano una portata ridotta (per esempio, solo stato delle pratiche);
• non richiedevano nuovi sistemi o nuovo personale;
• potevano dimostrare rapidamente la propria utilità;
• potevano essere implementati nel contesto delle norme e dei regolamenti esistenti (per esempio, lo strumento per la gestione del carico di lavoro era solo un foglio di calcolo che non aveva bisogno dell’approvazione dell’IT, di formazione da parte delle HR o di cambiamenti nei processi di business).

Come possiamo trovare dove applicare nella nostra organizzazione lo Strangler Pattern? Alcuni ambiti della nostra organizzazione che potrebbero essere adatti per questo approccio sono i seguenti.

• Sostituire un processo che viene svolto totalmente su carta con una versione digitale. Possiamo migliorare l’efficacia dei moduli uscendo dall’ufficio, andando a parlare con gli utenti in carne e ossa e guardando negli interstizi fra i compartimenti stagni.
• Individuare metriche di tracciamento che al momento non sono misurate, per creare un cambiamento che volete. In questo caso, tutto quello che serve può essere un foglio di calcolo giornaliero o settimanale. Per esempio, se alla fine volete passare a un sistema multicanale per migliorare il customer service, ma nessuno misura l’efficacia del customer service oggi, trovare come prima cosa modi per condurre indagini sulla soddisfazione o misurare il tasso di risoluzione al primo contatto può preparare la scena per la nostra presentazione.
• Processi che vengono svolti in modo diverso a seconda dell’area (per esempio, in cui possiamo sperimentare e misurare i cambiamenti nella nostra area di responsabilità per prima).
• Individuare punti dolenti o requisiti che l’organizzazione prima o poi dovrà affrontare, ma che sono sotto il radar o sono abbastanza noiosi da non attrarre molta attenzione, come gli aggiornamenti legislativi di routine.

Non è necessario avere un’idea di come mangiare tutto l’elefante e neanche la maggior parte dell’elefante quando iniziamo: dobbiamo solo avere qualche primo passo concreto che ci aiuti a prendere sempre più slancio. Questi passi devono essere abbastanza specifici da risultare trattabili e realizzabili per il nostro pubblico.

Marina ha quella che chiama la matematica manipolativa di Marina, quando deve tenere una presentazione su come identificare e definire il raggio d’azione dei progetti basati sullo Strangler Pattern. Pone una serie di domande.

• Abbiamo in questo momento tutto quello che vi serve per iniziare?
• possiamo parlarne pubblicamente come di un risultato positivo?
• Migliorerà il morale dei collaboratori?
• Che cosa vi farà guadagnare (capitale politico, risparmi finanziari)?
• Chi è contrario?
• È un prerequisito per altri cambiamenti che volete introdurre in seguito?
• Quanto tempo richiederà?
• Quali risorse (tempo, persone) richiederà?

Dalla teoria alla pratica dello Strangler Pattern

• Iniziamo con la tecnologia esistente. Se dovessimo trovarci a lavorare con un vecchio database legacy, una cosa che sa fare bene è produrre un foglio di calcolo di dati a intervalli regolari (per esempio, ogni sera). Anziché aspettare anni (o decenni) che venga sostituito, usiamolo a nostro vantaggio. Se possiamo mettere le mani su un report serale già esistente, possiamo usarlo per alimentare un numero straordinario di strumenti esterni al mainframe stesso, come tracciatori di stato o dashboard di avanzamento. Qualcosa che i database legacy non fanno bene è scalare per abilitare molte connessioni simultanee (per esempio, un milione di persone che si collegano direttamente al database per verificare lo stato delle proprie pratiche ed effettuano compulsivamente un refresh). Questo è un motivo citato spesso per cui cose come gli strumenti self-service non sono più frequenti: l’organizzazione di solito desidererebbe moltissimo questa funzionalità, ma aspetta soltanto di sostituire completamente il mainframe con un database moderno che possa gestire quel carico. Strangoliamo questo atteggiamento con un approccio che richieda la connessione al database solo una o due volte al giorno e combini l’esportazione di un foglio di calcolo da parte del mainframe con uno strumento moderno abbastanza scalabile da gestire il pubblico.
• Non abbiamo l’ossessione delle informazioni in tempo reale. Dati giornalieri sono perfettamente soddisfacenti per la maggior parte delle interazioni di business. Certo, qualche indicatore di stato cambierà un minuto dopo l’esportazione del report, ma la maggior parte no. Possiamo sempre usare il successo di tutto quello che sviluppate con i dati giornalieri per giustificare in seguito l’investimento per la capacità di generare dati in tempo reale.
• Troviamo il vostro cavallo di Troia. Prendiamo in considerazione tutti i nostri punti di ingresso per affrontare un problema, non solo il primo in ordine cronologico, o quello più vicino al vostro ruolo. Se ci sentiamo bloccati in attesa che si concluda (o inizi) un progetto enorme, guardiamoci intorno per trovare un’opportunità che non sia stata ancora sfruttata, magari che non è nel raggio d’azione, o al momento è solo su carta, o nel campo di un diverso ufficio.
• Guardiamo oltre la tecnologia. Lo Strangler Pattern può avere avuto origine nell’IT, ma possiamo applicarlo anche a problemi non tecnici. Qualsiasi piano o iniziativa pluriennale offre opportunità di uno strangolamento di breve termine (cioè di lavorare su problemi collaterali, più ridotti).

Questo articolo richiama contenuti dal capitolo 32 di Rompere la burocrazia.

Immagine di apertura di Mihály Köles su Unsplash.