Ken il Guerriero come consulente BCP involontario: lezioni di sopravvivenza organizzativa dall'apocalisse nucleare
Business Continuity · ISO 22301 · ISO 31000
C'è un personaggio della cultura pop che ha operato in condizioni di crisi estrema per tutta la sua vita professionale, senza mai una procedura documentata, senza un piano di recupero, senza un registro dei rischi. Eppure sopravvive. Anzi, vince quasi sempre. Si chiama Kenshiro, erede del Hokuto Shinken, protagonista di Ken il Guerriero (北斗の拳, Hokuto no Ken). E senza saperlo, incarna — nel modo più brutale possibile — i principi fondamentali della Business Continuity.
L'ambientazione è il 2199 d.C., vent'anni dopo una guerra nucleare che ha distrutto la civiltà. Non ci sono infrastrutture, non ci sono istituzioni, non ci sono supply chain. Ogni giorno è un esercizio pratico di gestione della continuità operativa in condizioni di Maximum Disruption. Ogni villaggio che Kenshiro incontra è un'organizzazione che ha subito un evento distruttivo senza alcun BCP attivo. E lo vediamo: muoiono quasi tutti.
«Omae wa mou shindeiru.»— Kenshiro, a qualsiasi antagonistaChe in italiano suona: "Sei già morto." Esattamente quello che dice un auditor dopo aver visto un'azienda senza piano di continuità operativa.
Oggi parliamo di ISO 22301:2019 — lo standard internazionale per i Sistemi di Gestione della Business Continuity — e di ISO 31000:2018 — framework per la gestione del rischio. Li leggiamo attraverso gli occhi di un guerriero del post-apocalisse che, a modo suo, li applica ogni singolo giorno. Inconsapevolmente. Brillantemente. Con molta più forza fisica del necessario.
1. Il mondo di Ken è la tua azienda senza BCP
Facciamo un esperimento mentale. Immagina la tua organizzazione domani mattina: il server principale è offline, il responsabile IT è irreperibile, il fornitore critico ha chiuso, l'ufficio è inaccessibile per un'alluvione e metà del personale chiave è in malattia. Nessuna procedura di backup attivabile. Nessun contatto di emergenza aggiornato. Nessun piano.
Benvenuto nel Ken il Guerriero dell'imprenditoria italiana. La savana post-nucleare non è così diversa: risorse scarse, minacce improvvise, strutture inagibili, personale decimato. La differenza è che Kenshiro sa esattamente cosa fare perché ha interiorizzato — nel suo corpo, letteralmente — una risposta a qualsiasi scenario di crisi. La tua organizzazione, invece, improvvisa.
Secondo diversi studi internazionali sulla resilienza organizzativa, una percentuale significativa di aziende colpite da un evento disruptivo grave — incendio, cyber attack, perdita di dati critici, interruzione della supply chain — non riprende mai pienamente la propria operatività entro due anni. Non perché il danno fosse irreparabile. Ma perché non sapevano cosa fare nei primi 72 ore.
Il BCP non salva dall'evento. Salva dal dopo l'evento.
2. Hokuto Shinken come Risk Assessment: colpisci i punti vitali
Il Hokuto Shinken è un'arte marziale basata sulla conoscenza dei 708 punti di pressione vitali del corpo umano — i Tsubo — ciascuno dei quali, se colpito nella sequenza corretta, produce un effetto specifico e prevedibile. Kenshiro non attacca alla cieca: identifica il punto critico, valuta l'impatto, agisce con precisione chirurgica.
Questo è esattamente ciò che richiede ISO 31000:2018 nella sua fase di risk assessment: identificare i punti di pressione dell'organizzazione — le vulnerabilità che, se colpite, producono effetti a cascata sull'operatività — e mappa la relazione tra causa, evento e conseguenza.
Risk identification: l'organizzazione deve identificare le fonti di rischio, le aree di impatto, gli eventi e le loro cause e conseguenze potenziali.
Risk analysis: comprende la stima della probabilità degli eventi e della magnitudine delle loro conseguenze, tenendo conto dei controlli esistenti.
Risk evaluation: confrontare i risultati dell'analisi con i criteri di rischio per determinare se il rischio è accettabile o richiede trattamento.
In sintesi: identificare i Tsubo prima che li trovi qualcun altro.
Nella pratica aziendale, i Tsubo dell'organizzazione sono quei nodi critici la cui interruzione genera conseguenze sproporzionate: il singolo dipendente che detiene conoscenze non documentate, il fornitore unico senza alternativa qualificata, il sistema IT senza ridondanza, il processo manuale non presidiato. Colpisci uno di questi punti — con un attacco informatico, una dimissione improvvisa, un'alluvione — e l'organizzazione, esattamente come gli avversari di Ken, esplode dall'interno.
| Tsubo Aziendale | Rischio Corrispondente | Risposta BCP |
|---|---|---|
| Dipendente chiave unico | Perdita di know-how critico non documentato | Knowledge management, job shadowing, mansionari dettagliati |
| Fornitore monopolista | Interruzione supply chain senza alternativa | Dual sourcing, contratti con SLA di continuità |
| Sistema IT senza backup | Perdita dati / blocco operativo totale | Recovery Point Objective (RPO) e Recovery Time Objective (RTO) definiti |
| Sede unica senza alternativa | Inaccessibilità struttura (incendio, alluvione, black-out) | Work from anywhere policy, sede alternativa identificata |
| Processo non documentato | Operatività dipendente dalla memoria individuale | Procedure scritte, istruzioni operative, workflow digitalizzati |
3. Il Business Impact Analysis: o lo fai tu, o lo fa l'apocalisse
Ogni villaggio che Kenshiro incontra nella savana ha già subito il suo Business Impact Analysis — nel senso che le conseguenze della mancanza di difese sono già visibili, dolorose e irreversibili. I sopravvissuti sono quelli che avevano costruito qualcosa: un pozzo, delle mura, una comunità organizzata. Gli altri sono già morti, o quasi.
Il BIA — Business Impact Analysis richiesto da ISO 22301:2019 (cl. 8.2.2) è lo strumento con cui l'organizzazione, prima che arrivi Shin con i suoi scagnozzi, risponde a tre domande fondamentali:
L'organizzazione deve identificare e valutare l'impatto di una interruzione delle attività critiche, determinando in particolare:
— le attività prioritarie e il livello minimo accettabile di erogazione del servizio (MBCO — Minimum Business Continuity Objective);
— il Maximum Tolerable Period of Disruption (MTPD): per quanto tempo l'organizzazione può sopportare l'interruzione prima di subire danni irreversibili;
— il Recovery Time Objective (RTO): entro quanto tempo il processo deve essere ripristinato;
— il Recovery Point Objective (RPO): quanta perdita di dati è tollerabile (rilevante per i processi informativi).
Traduzione in linguaggio Hokuto: devi sapere esattamente in quale sequenza intervenire e su quali punti. Colpire a caso non è una strategia. È solo violenza.
4. Le strategie di continuità: il metodo Ken non scala, ma ispira
Kenshiro affronta ogni crisi con una combinazione di tre approcci: resilienza personale estrema (non si abbatte mai), adattamento tattico (cambia approccio in base all'avversario) e protezione delle risorse critiche (protegge Yuria, Bat, Lin — le sue risorse non sostituibili). In termini di Business Continuity, corrisponde esattamente alle tre macro-strategie previste da ISO 22301.
- Prevent & Reduce — Agire prima che l'evento accada: ridurre la probabilità o la magnitudine dell'impatto. Corrisponde al lavoro preventivo di Ken che riconosce l'avversario, ne valuta la tecnica e prepara la contromossa prima di subire il colpo.
- Respond & Recover — Gestire l'interruzione quando accade: attivare le procedure di risposta, ripristinare le funzioni critiche nell'ordine corretto e nel tempo previsto. Ken non si ferma dopo il primo colpo ricevuto. Sa già cosa fare.
- Restore & Improve — Ripristinare le condizioni normali e migliorare: aggiornare il piano sulla base di quanto appreso. Ogni battaglia lascia a Kenshiro una conoscenza nuova che applicherà nel prossimo scontro. Il sistema impara. Il BCP anche — ma solo se c'è qualcuno che lo aggiorna.
5. Il peggior errore: confondere la sopravvivenza con la continuità
Attenzione. Qui sta la trappola concettuale in cui cade il 90% delle organizzazioni che pensano di avere già un BCP.
Sopravvivere non è continuare. Kenshiro sopravvive sempre. Ma quante delle organizzazioni che incontra nella savana sono ancora in piedi alla fine? Quasi nessuna. Perché sopravvivenza ed operatività sono due cose diverse. Puoi superare la crisi — blocco del server, perdita del cliente principale, interruzione della supply chain — e tuttavia non essere più in grado di erogare il tuo servizio al livello atteso. Sei vivo. Ma per i tuoi clienti, sei già morto.
L'organizzazione deve stabilire obiettivi di business continuity coerenti con la politica, misurabili, comunicati e aggiornati. Devono includere il MBCO (Minimum Business Continuity Objective): il livello minimo di servizio che l'organizzazione deve mantenere durante un'interruzione per soddisfare i propri obblighi.
Non «sopravvivere alla crisi». Ma «restare operativi al livello X entro Y ore». La differenza è sostanziale. Una è una speranza. L'altra è un obiettivo misurabile.
6. Il test del BCP: la lezione di Raoul
Uno dei personaggi più istruttivi del manga — per ragioni opposte a Ken — è Raoul, il fratello adottivo che sembrava invincibile, ben addestrato, sicuro di sé. Aveva tutte le competenze. Aveva il fisico. Aveva l'esperienza. Ma non aveva mai testato realmente il suo piano contro un avversario all'altezza. Quando arriva Kenshiro, la teoria si scontra con la realtà. E la realtà vince.
Le aziende che non testano il proprio BCP sono esattamente Raoul. Hanno il documento. L'hanno scritto bene. È bello da vedere. Ma non l'hanno mai esercitato.
- Tabletop exercise: simulazione teorica con i responsabili — "cosa faremmo se...". Basso costo, alto valore. Da fare almeno annualmente.
- Drill test: attivazione reale di una procedura specifica (es. ripristino backup, attivazione sede alternativa, comunicazione di crisi). Testa la singola componente.
- Full-scale exercise: simulazione completa di uno scenario di crisi, con attivazione dell'intero Crisis Management Team. Rivela le lacune che gli altri test non trovano.
- Lesson learned: ogni esercitazione deve produrre un documento di miglioramento. Il BCP che non si aggiorna dopo un test è un documento morto.
Un BCP non testato è come Raoul che si allena solo con gli scagnozzi. Funziona finché non incontra Ken.
7. La vera forza di Ken: sa cosa proteggere prima di tutto
In tutto il manga, Kenshiro non combatte per combattere. Combatte per proteggere qualcosa di specifico: Yuria, i bambini, i deboli del villaggio. Sa esattamente qual è la sua asset critica e orienta ogni decisione tattica in funzione di essa. Questo è il cuore del Business Continuity Planning.
Non si tratta di proteggere tutto. È impossibile e controproducente. Si tratta di identificare con precisione — attraverso il BIA — le funzioni critiche, i processi prioritari e le risorse non sostituibili che devono essere operative anche durante e immediatamente dopo un evento disruptivo. Il resto può aspettare. Il resto richiede tempi di ripristino più lunghi. Ma quelle cose lì — devono funzionare.
Il Business Continuity Plan più sofisticato del mondo non serve a nulla se non è noto, accessibile e attivabile durante la crisi. Un BCP salvato solo sul server principale — che è offline durante il disastro — è una delle non-conformità più frequenti e più tragicomiche che si incontra durante gli audit ISO 22301.
Il piano di continuità deve essere disponibile offline, in formato stampato o su sistema ridondato, e deve includere i contatti di emergenza aggiornati. Perché durante la crisi non si ha tempo di cercarlo. E l'internet potrebbe non funzionare.
Kenshiro porta il suo piano nel corpo. È l'unico supporto veramente resiliente che esista.
8. Dalla savana all'ufficio: cosa fare davvero
Trasliamo tutto in una roadmap concreta. Non serve partire da uno standard completo se non si è mai fatto nulla. Si parte dai fondamentali.
- Step 1 — Contesto e scopo: definire perimetro, stakeholder e obiettivi del BCMS. Chi siamo, cosa proteggiamo, per chi lo facciamo. (ISO 22301, cl. 4)
- Step 2 — Business Impact Analysis: identificare le attività critiche, i loro tempi di ripristino accettabili (RTO/RPO), le dipendenze interne ed esterne. (cl. 8.2.2)
- Step 3 — Risk Assessment: applicare ISO 31000 per identificare minacce, vulnerabilità e livello di rischio per ciascuna attività critica. (cl. 8.2.3)
- Step 4 — Strategia di continuità: definire le risposte per ciascuno scenario critico (ridondanza, outsourcing, workaround manuali, sede alternativa). (cl. 8.3)
- Step 5 — Business Continuity Plan: documentare le procedure operative di risposta, i ruoli nel Crisis Management Team, i flussi di comunicazione interna ed esterna. (cl. 8.4)
- Step 6 — Test e simulazione: pianificare ed eseguire esercitazioni, documentare i risultati, aggiornare il piano. (cl. 8.5 e 10.1)
- Step 7 — Revisione continua: il BCP non è un documento statico. Va rivisto a ogni cambiamento organizzativo rilevante e almeno una volta l'anno. (cl. 9.3)
ISO 22301:2019 è certificabile — ovvero un'organizzazione può ottenere la certificazione di terza parte del proprio BCMS — ma anche senza certificazione, la struttura logica dello standard è uno strumento pratico e applicabile in qualsiasi contesto organizzativo, indipendentemente dalla dimensione. Startup o multinazionale: la continuità operativa non è un lusso. È una condizione di sopravvivenza nel mercato.
Conclusione: il vero avversario non è l'apocalisse
Kenshiro vive in un mondo già distrutto. Non può prevenire l'apocalisse perché è già avvenuta. Ma può scegliere come rispondere, chi proteggere, in quale ordine agire. E quella scelta — preparata, interiorizzata, testata — è la differenza tra lui e tutti gli altri sopravvissuti che muoiono nei primi dieci minuti di ogni episodio.
Le organizzazioni non vivono nell'apocalisse nucleare. Ma vivono in un contesto in cui le interruzioni operative sono inevitabili: cyber attack, eventi climatici estremi, interruzioni della supply chain, pandemie, incendi, crisi reputazionali, perdita di personale chiave. La domanda non è se arriverà un evento disruptivo. La domanda è: quando arriva, sai già cosa fare?
Se la risposta è «dipende», «ci pensiamo», o «speriamo non succeda», allora hai già sentito cosa ti dice Ken.
E lo sai anche tu.
Commenti
Posta un commento