Doctor Strange, 14.000.605 futures e il tramonto (parziale) del PDCA
Quando pianificare un solo scenario non basta più a salvare l'universo - o l'azienda
C'è una domanda che periodicamente riemerge tra chi si occupa di sistemi di gestione: il PDCA funziona ancora, o lo teniamo in vita per abitudine? Ne ho discusso di recente, e la conversazione è finita per smontare quarant'anni di certezze operative in pochi scambi.
La risposta breve è: il PDCA non è morto. Ma da solo, in un contesto complesso, non basta più. E se vuoi capire perché, ti conviene osservare come si comporta Stephen Strange quando la situazione supera ogni piano possibile, compreso il migliore che tu possa scrivere.
Non è un esercizio di stile. Chi lavora ogni giorno con sistemi di gestione conosce bene la sensazione: il ciclo è scritto correttamente, la procedura è impeccabile, l'audit va bene, e nonostante questo l'organizzazione arriva sempre un passo dopo rispetto a quello che sta succedendo davvero. Il sospetto, a quel punto, non è che il PDCA sia stato applicato male. È che sia stato applicato al problema sbagliato.
Kamar-Taj: il regno ordinato del PDCA
Prima di Thanos, il mondo di Strange è Kamar-Taj: rituali precisi, sigilli ripetibili, un percorso di addestramento incrementale dove ogni gesto sbagliato viene corretto subito e ogni progresso si costruisce sul precedente. È, in sostanza, un ambiente Plan-Do-Check-Act perfetto: pianifichi l'esercizio, lo esegui, verifichi il risultato, correggi la postura della mano. Il ciclo funziona perché il contesto è stabile e le variabili sono poche.
Le quattro fasi, applicate a un contesto stabile, hanno una logica quasi banale: pianifichi l'obiettivo e il metodo (Plan), lo metti in pratica (Do), verifichi lo scostamento tra risultato atteso e risultato ottenuto (Check), correggi ciò che non ha funzionato prima di ripartire (Act). Funziona perché tra una fase e l'altra il mondo intorno resta, più o meno, lo stesso. È la premessa silenziosa che rende tutto il modello coerente - e che nessuno, quasi mai, si prende la briga di verificare prima di applicarlo.
A Kamar-Taj, prima dell'arrivo di Thanos, quella premessa regge benissimo.
Vale la pena ricordare un dettaglio che pochi citano: lo stesso Deming non amava particolarmente la sigla PDCA. Il ciclo nasce dagli studi di Walter Shewhart negli anni Trenta e Deming, portandolo in Giappone negli anni Cinquanta, preferiva parlare di PDSA, Plan, Do, Study, Act, perché "Check" gli sembrava suggerire una semplice ispezione, mentre "Study" implicava un'analisi più profonda. Il mercato ha preferito la sigla più corta. Succede spesso, anche nei sistemi di gestione: la versione semplificata vince su quella corretta.
Su processi ripetitivi, stabili, a bassa variabilità, una linea produttiva, una procedura amministrativa, un programma di audit interni, il PDCA resta uno strumento solido. Il problema comincia quando arriva qualcosa che non rispetta le regole di Kamar-Taj.
Poi arriva Thanos: benvenuti nella complessità
I sistemi in cui oggi lavoriamo assomigliano sempre meno a Kamar-Taj prima dell'invasione e sempre più a Kamar-Taj durante: volatilità dei mercati, sistemi digitali interconnessi, intelligenza artificiale che cambia le regole del gioco più velocemente di quanto tu riesca a scrivere una procedura, supply chain globali, normative che cambiano in corsa, rischio cyber, stakeholder con aspettative che si spostano di mese in mese.
Il PDCA presuppone implicitamente che tu possa prima pianificare, poi eseguire, poi controllare, poi correggere, in questo ordine, con il tempo di completare ogni fase prima che il contesto cambi sotto di te. È un ciclo lineare applicato a un mondo che, sempre più spesso, non aspetta che tu finisca la fase "Check" prima di modificare le regole.
Non è un caso che anche le norme ISO più recenti (9001, 14001, 45001, 37001) abbiano affiancato al PDCA elementi che da soli, dentro un cerchio a quattro fasi, non ci stanno comodamente: risk-based thinking, gestione del contesto, leadership, gestione della conoscenza, resilienza. Sono tutti elementi trasversali, non sequenziali. Il cerchio, da solo, è diventato troppo piccolo per contenerli.
Un esempio banale, ma reale: un'organizzazione pianifica il proprio sistema di gestione del rischio informatico su base annuale, con revisione a marzo dell'anno successivo. Nel frattempo cambia il fornitore cloud, cambia una normativa sulla protezione dei dati, e viene scoperta una vulnerabilità critica in un componente usato da mezzo mercato. Il ciclo "Plan" di marzo era corretto quando è stato scritto. A giugno, di quel piano, è rimasto poco.
I 14.000.605 futures: l'OODA Loop secondo lo Stregone Supremo
Davanti a Thanos, Strange non si affida a un singolo piano ben scritto. Esplora un numero enorme di sviluppi possibili, 14.000.605, per la precisione, prima di individuare quale sequenza di eventi porta alla vittoria. Non pianifica: osserva, si orienta, decide, agisce. E ricomincia.
Questo è, quasi letteralmente, un ciclo OODA - Observe, Orient, Decide, Act - teorizzato da John Boyd, colonnello e pilota da caccia dell'aeronautica statunitense, famoso per la capacità di prevalere in combattimento simulato contro qualsiasi avversario in meno di quaranta secondi. Boyd non stava scrivendo un manuale di project management: stava cercando di sopravvivere in un ambiente dove la situazione cambiava più in fretta di qualsiasi piano scritto a terra.
Il ciclo OODA è oggi citato spesso in ambito risk management e cybersecurity, non a caso i due domini dove il tempo di reazione conta quanto la qualità della decisione. Non sostituisce il PDCA: lo affianca, o lo sostituisce, nei contesti dove il tempo tra pianificazione e verifica è un lusso che non ti puoi permettere.
Un team che gestisce un incidente di sicurezza informatica non scrive un piano annuale e poi lo esegue: osserva i log in tempo reale, si orienta rispetto a ciò che sa di attacchi simili, decide la contromisura, agisce, e osserva di nuovo l'effetto della propria azione, in un ciclo che può durare minuti, non trimestri. È lo stesso principio che muove Strange davanti a Thanos: la velocità del ciclo decisionale conta quanto la sua correttezza.
Il Multiverso ha bisogno del Cynefin, non di un piano quinquennale
C'è un dettaglio che nel confronto tra Strange e il PDCA passa spesso inosservato: prima di agire, lo Stregone Supremo non si limita a osservare i futuri possibili, li esplora attivamente, valuta le conseguenze, e solo allora sceglie la linea temporale su cui muoversi. Non pianifica l'esito, lo scopre sperimentando in sicurezza.
È esattamente la logica del framework Cynefin, sviluppato da Dave Snowden alla fine degli anni Novanta, che distingue quattro domini decisionali. Nei contesti semplici basta riconoscere il pattern e applicare la prassi consolidata (Sense - Categorize - Respond). Nei contesti complicati serve un esperto che analizzi la situazione prima di agire (Sense - Analyze - Respond). Nei contesti complessi, causa ed effetto si vedono solo a posteriori: non puoi pianificare, devi sperimentare in piccolo, osservare cosa emerge, e solo allora rispondere (Probe - Sense - Respond). Nei contesti caotici, infine, devi agire subito per stabilizzare la situazione, e capire dopo (Act - Sense - Respond).
Il punto debole del PDCA applicato ai contesti complessi non è la sua logica interna, che resta valida: è l'assunzione implicita che tu sappia già, in fase di "Plan", cosa funzionerà. In un contesto complesso, semplicemente, non lo sai. Lo scopri facendo esperimenti a basso rischio e osservando le conseguenze - non scrivendo un piano perfetto a tavolino.
Nella pratica, questo significa lanciare piccoli esperimenti reversibili - un progetto pilota su un solo reparto, una modifica testata su un singolo processo prima di estenderla - invece di progettare a tavolino la soluzione definitiva per l'intera organizzazione. Se l'esperimento fallisce, il danno è contenuto e il fallimento stesso diventa informazione utile. È probe-sense-respond applicato fuori dai libri di testo, ed è molto più vicino a come lavora davvero chi gestisce un'emergenza reale rispetto a chi compila un piano annuale.
L'apprendimento continuo: quando anche le regole vanno riscritte
Nei sistemi basati su intelligenza artificiale e machine learning il modello si allena continuamente sui dati che riceve: non c'è una fase "Check" separata dal resto, il controllo è incorporato nel funzionamento stesso. È il Continuous Learning Loop, e da solo basterebbe a spiegare perché pensare per fasi sequenziali, oggi, è spesso un esercizio di retrospettiva più che di gestione reale.
C'è però una distinzione più sottile, e più utile, introdotta da Chris Argyris e Donald Schön nel 1978: quella tra apprendimento a ciclo singolo e apprendimento a ciclo doppio. Il ciclo singolo corregge l'azione mantenendo intatte le assunzioni di partenza, riduco i tempi di consegna perché l'indicatore dice che sono troppo lunghi. Il ciclo doppio mette in discussione l'assunzione stessa: sto ancora misurando la cosa giusta? Quell'indicatore ha ancora senso nel contesto in cui opero oggi?
Guardato con questa lente, il percorso di Strange nei vari film non è solo un susseguirsi di battaglie vinte correggendo la tecnica. È un personaggio che, progressivamente, rimette in discussione le proprie convinzioni di fondo, il bisogno di controllo assoluto, l'idea che esista sempre un'unica soluzione giusta da imporre. Non impara solo a lanciare meglio gli incantesimi: impara a cambiare il modo in cui decide quale incantesimo lanciare. È double loop learning applicato a un personaggio, e la maggior parte dei sistemi di gestione che ho visto in vent'anni non arriva mai a questo livello: si ferma a correggere l'azione, senza mai interrogare l'assunzione.
Un esempio concreto: un'azienda misura da anni il tasso di non conformità in produzione e lo riduce progressivamente, azione dopo azione, correzione dopo correzione. Il ciclo singolo funziona, l'indicatore migliora. Nessuno, però, si chiede se quell'indicatore stia ancora misurando ciò che conta davvero, ora che gran parte del valore si è spostato dal prodotto fisico al servizio post-vendita. Correggere l'azione senza rivedere l'assunzione produce, con il tempo, organizzazioni bravissime a ottimizzare la cosa sbagliata.
Adaptive Management: la lezione arriva dagli ecosistemi, non dai project manager
Un ultimo paradigma merita una menzione, perché arriva da un campo lontano dal management classico: la gestione ambientale. L'Adaptive Management, formalizzato da C.S. Holling alla fine degli anni Settanta per governare ecosistemi complessi sotto incertezza, si basa su sperimentazione continua, feedback costante, revisione delle decisioni e apprendimento organizzativo incorporato nel funzionamento quotidiano - non collocato in una fase separata a valle.
Messi in fila, questi paradigmi disegnano un pattern comune: Sense, Analyze, Decide, Execute, Learn, Adapt, non più un cerchio a quattro fasi che si chiude e ricomincia, ma un flusso continuo dove controllo e apprendimento non sono tappe separate, sono parte integrante di ogni fase.
Cosa resta in piedi del PDCA
Detto tutto questo, buttare il PDCA sarebbe un errore uguale e contrario a quello di applicarlo ovunque. Resta lo strumento giusto per i processi stabili, ripetitivi, a bassa variabilità: una linea produttiva, una procedura amministrativa consolidata, un programma di audit pianificato con largo anticipo. In quei contesti, il ciclo Plan-Do-Check-Act funziona ancora perché le condizioni che lo rendono efficace - stabilità, prevedibilità, tempo sufficiente per completare ogni fase - sono ancora presenti.
Il problema non è mai stato il PDCA in sé. È l'abitudine di applicarlo come se fosse l'unico strumento disponibile, indipendentemente dal dominio in cui ti trovi. La competenza reale, quella che fa la differenza tra un sistema di gestione che funziona e uno che produce solo documentazione, non consiste nello scegliere un modello e applicarlo sempre. Consiste nel riconoscere in quale dominio ti trovi - stabile o complesso, prevedibile o caotico - e scegliere il ciclo adatto a quel dominio. Il Cynefin, in fondo, insegna esattamente questo.
Doctor Strange non ha vinto studiando un solo piano fino alla perfezione. Ha vinto esplorando milioni di scenari e riconoscendo l'unico che funzionava, poi ricominciando a osservare non appena le condizioni sono cambiate. Se il tuo sistema di gestione si ostina a pianificare un solo futuro possibile e a controllarlo trimestralmente, forse non ha bisogno di un audit in più. Ha bisogno di un Occhio di Agamotto.
© Diritti e citazioni - I personaggi e le opere citati in questo articolo appartengono ai rispettivi autori e titolari dei diritti. Il loro utilizzo ha finalità esclusivamente divulgativa e di commento critico, ai sensi dell'art. 70 L. 633/1941. Nessuna affiliazione o sponsorizzazione è implicita o sottintesa.
© mauriziomicucci.it - La riproduzione è consentita con citazione della fonte
Commenti
Posta un commento