Come garantire l’operatività aziendale anche se l’ufficio è inagibile per un incendio?

Immagini la scena. Sono le tre del mattino e il suo telefono squilla. È la vigilanza: un corto circuito ha causato un incendio nel suo ufficio principale. Nessun ferito, per fortuna, ma la sede è inagibile per giorni, forse settimane. I server sono offline, i documenti irraggiungibili, le linee telefoniche mute. La prima reazione è il panico. La seconda è rivolta all’IT: “Abbiamo il backup, vero?”. Questa è la domanda che quasi tutti si pongono, credendo che un piano di Disaster Recovery tecnico sia la soluzione.

La realtà, però, è molto più complessa. Molti consulenti le parleranno di soluzioni cloud, di ridondanza dei dati e di software. Si concentreranno sul “cosa”, sulla tecnologia. Ma da Direttore Generale, la sua preoccupazione va oltre: come assicuro ai clienti che il servizio non si fermerà? Come coordino le persone? Come gestisco la catena di fornitura se il mio ERP è inaccessibile? La risposta non risiede in un documento statico chiuso in un cassetto, ma nella costruzione di un vero e proprio muscolo organizzativo. La resilienza non è un’assicurazione che si compra, ma una cultura che si costruisce e si allena, guardando oltre l’IT per focalizzarsi su persone e processi.

E se la vera chiave non fosse “avere un piano”, ma “essere un’organizzazione preparata”? Questo articolo non è una checklist tecnica. È una guida strategica per lei, Direttore Generale, per smettere di delegare la continuità operativa all’IT e iniziare a governarla. Esploreremo come identificare ciò che conta davvero, come testare le nostre debolezze prima che lo faccia una crisi e come trasformare un obbligo normativo in un vantaggio competitivo tangibile, assicurando che la promessa fatta ai clienti venga sempre mantenuta.

Per affrontare questo percorso in modo strutturato, analizzeremo gli elementi fondamentali che trasformano un’azienda da fragile a resiliente. Questo sommario delinea le tappe chiave del nostro ragionamento strategico.

Business Impact Analysis (BIA): come capire quali uffici devono ripartire entro 4 ore

Di fronte a un disastro, l’istinto è quello di voler ripristinare tutto e subito. È un errore strategico che disperde energie e risorse. La prima domanda da porsi non è “cosa è rotto?”, ma “cosa serve ai nostri clienti ORA?”. La Business Impact Analysis (BIA) è lo strumento che risponde a questa domanda. Non è un’analisi tecnica, ma un’indagine strategica che mappa i processi aziendali e li classifica in base al loro impatto sul business nel tempo. L’obiettivo è separare ciò che è urgente da ciò che è semplicemente importante.

Il processo, come delineato dalla norma ISO 22317, non si limita a dire “il reparto vendite è critico”. Scende nel dettaglio: quali attività specifiche del reparto vendite? L’inserimento di un nuovo ordine per un cliente chiave ha priorità diversa rispetto all’aggiornamento del CRM. Per molte PMI italiane, la BIA rivela che le attività più critiche sono quelle legate a specifici SLA contrattuali o a catene di fornitura just-in-time. L’impatto non è solo economico, ma anche reputazionale, legale e operativo. Stabilire che il processo X deve ripartire entro 4 ore e il processo Y può aspettare 48 ore è una decisione di business, non tecnologica, che guida l’intera strategia di continuità.

Questa mappatura strategica dei processi permette di vedere l’azienda come un organismo vivente, con organi vitali e altri meno essenziali per la sopravvivenza a breve termine. L’illustrazione seguente mostra metaforicamente come i processi aziendali siano interconnessi, con alcuni ingranaggi (quelli critici) che devono continuare a girare per non bloccare l’intero meccanismo.

Come evidenziato dallo schema, comprendere le dipendenze è cruciale. Magari il reparto legale non sembra una priorità, ma se è l’unico a poter firmare digitalmente un documento per sbloccare una spedizione urgente, la sua indisponibilità diventa un blocco critico. Stimare il costo del fermo macchina è un esercizio fondamentale in questa fase. Se, secondo le stime di N-Tech, il costo del downtime per le PMI varia tra 137 e 427 dollari al minuto, la BIA non è più un esercizio teorico, ma il calcolo del rischio finanziario reale che sta correndo.

Senza una BIA, si rischia di investire migliaia di euro per proteggere sistemi che potrebbero restare fermi per una settimana senza danni reali, lasciando scoperti processi la cui interruzione di poche ore può compromettere un cliente strategico.

RTO e RPO: qual è il tempo massimo che la tua azienda può restare ferma prima di fallire?

Una volta che la BIA ha stabilito le priorità, è necessario tradurre queste esigenze di business in parametri misurabili per l’IT. Qui entrano in gioco due acronimi fondamentali che ogni Direttore Generale dovrebbe padroneggiare: RTO e RPO. Non sono dettagli tecnici, ma la formalizzazione degli obiettivi di resilienza. L’RTO (Recovery Time Objective) è il tempo massimo che può intercorrere tra l’incidente e il ripristino del servizio. È la risposta alla domanda: “Quanto tempo possiamo permetterci di restare fermi?”. Un RTO di 1 ora per un e-commerce è radicalmente diverso da un RTO di 24 ore per l’ufficio contabilità.

L’RPO (Recovery Point Objective), invece, definisce la quantità massima di dati che l’azienda può permettersi di perdere. Risponde alla domanda: “A quale momento nel passato dobbiamo essere in grado di tornare?”. Un RPO di 5 minuti significa che, nel peggiore dei casi, si perderanno gli ultimi 5 minuti di lavoro. Un RPO di 24 ore implica che si potrebbe perdere l’intera giornata lavorativa precedente. È evidente che un RPO basso richiede tecnologie di backup più frequenti e costose. Il problema è che, troppo spesso, questi valori sono decisi dall’IT in base a budget o prassi, non alle reali necessità del business. Questo scollamento è pericoloso: secondo Digital World Italia, il 45% delle aziende italiane non ha un accesso continuo e garantito ai propri dati, sintomo di una sottovalutazione sistemica di RTO e RPO.

Definire RTO e RPO per ogni servizio critico è un atto di governance. È l’unico modo per avere un dialogo costruttivo con il reparto IT e i fornitori, fornendo loro obiettivi chiari e misurabili su cui costruire le soluzioni tecniche. Il tavolo seguente illustra come questi parametri cambino drasticamente in base alla funzione aziendale, evidenziando che una soluzione unica per tutti è quasi sempre quella sbagliata.

Ignorare RTO e RPO significa navigare a vista, sperando che le soluzioni tecniche adottate siano “abbastanza buone”. Ma la speranza non è una strategia. Definire questi obiettivi è il primo passo per trasformare la spesa IT da un costo a un investimento misurabile nella sopravvivenza dell’azienda.

Chi chiama chi: l’errore di non avere una lista contatti cartacea d’emergenza

Nell’era digitale, l’idea di una lista di contatti cartacea sembra un anacronismo. Eppure, in uno scenario di crisi reale come un incendio o un attacco ransomware che rende inaccessibile la rete aziendale, la rubrica sul server o sul CRM diventa inutile. Chi ha il numero di cellulare personale del responsabile della produzione? Del consulente del lavoro per le comunicazioni urgenti ai dipendenti? Del perito assicurativo? La tecnologia può fallire, ma la catena umana della fiducia non deve spezzarsi. La prima reazione a un disastro non è tecnica, è umana: è una telefonata.

Il “Chi chiama chi” non può essere improvvisato. Deve esistere un protocollo di comunicazione chiaro, a cascata, che definisca ruoli e responsabilità. Questo protocollo, però, è efficace solo se i contatti sono accessibili. L’errore fatale è conservare questa lista solo in formato digitale sui sistemi aziendali. La soluzione è tanto semplice quanto vitale: una “War Room” di contatti strategici, stampata e conservata in luoghi sicuri e diversificati (a casa del Direttore Generale, in auto, presso una sede secondaria). Questa lista non deve contenere solo i numeri del team interno di crisi, ma anche quelli di tutti i partner esterni che diventano vitali in un’emergenza.

La comunicazione in emergenza richiede canali diversificati. L’email è inaffidabile e lenta. Gli SMS sono ottimi per un’allerta iniziale di massa per la loro alta affidabilità anche con poca rete. App come WhatsApp o Telegram sono eccellenti per il coordinamento in tempo reale di gruppi di lavoro specifici. Le telefonate dirette restano insostituibili per le comunicazioni critiche uno-a-uno. Avere un piano che specifichi quale canale usare per quale scopo evita il caos e la perdita di tempo prezioso. La seguente checklist fornisce una base concreta per costruire una lista di contatti a prova di disastro, pensata per il contesto italiano.

Sottovalutare questo aspetto “low-tech” della continuità operativa è uno degli errori più comuni e gravi. Quando tutto è offline, l’unica infrastruttura che resta è la rete di persone che ha costruito. Assicurarsi che possano comunicare è il suo primo dovere.

Smart Working come piano di continuità: perché non basta dire “lavorate da casa” se non è testato

Dopo la pandemia, lo smart working è diventato per molti sinonimo di continuità operativa. “Se l’ufficio è inagibile, lavoriamo da casa”. Sulla carta, sembra una soluzione semplice e ovvia. In pratica, è una trappola se non viene pianificata e testata come una vera operazione militare. Dire “lavorate da casa” senza un piano è come dare a un esercito delle armi senza aver mai fatto un’esercitazione di tiro. I punti di rottura sono numerosi e spesso sottovalutati.

Il primo ostacolo è tecnologico. La VPN aziendale è dimensionata per supportare il 10%, il 20% dei dipendenti? Cosa succede se il 100% tenta di connettersi simultaneamente? Le performance degli applicativi gestionali, testate sulla veloce rete aziendale, come si comportano con le connessioni domestiche medie italiane, spesso caratterizzate da una bassa velocità di upload? Un conto è scaricare un file, un altro è lavorare attivamente su un database remoto. Senza test di carico realistici, il rischio è di avere un’intera forza lavoro connessa ma incapace di operare, trasformando lo smart working in un “not working”.

Oltre alla tecnologia, c’è il processo. Quali attività dipendono ancora da documenti cartacei presenti in ufficio? La firma di un contratto, l’approvazione di un ordine, la consultazione di un archivio fisico. Ogni processo che richiede una presenza fisica è un punto di rottura. Infine, c’è l’aspetto legale e umano, cruciale in Italia. Lo smart working emergenziale deve comunque rispettare le normative su salute e sicurezza sul lavoro (informative INAIL) e il diritto alla disconnessione. Avere pronti i template per gli accordi individuali semplificati è un passo fondamentale che non può essere improvvisato nel mezzo di una crisi.

Lo smart working non è un piano B, è un’operatività di tipo B. Deve essere progettato, documentato, testato e mantenuto con lo stesso rigore dell’operatività in ufficio. Altrimenti, è solo un’illusione di resilienza.

Perché implementare un ERP senza aver disegnato i flussi è un suicidio economico?

L’ERP (Enterprise Resource Planning) è il sistema nervoso centrale dell’azienda. Gestisce ordini, produzione, contabilità, logistica. In un piano di continuità, il suo ripristino è quasi sempre una priorità assoluta. Tuttavia, c’è un rischio ancora più profondo del suo downtime: un ERP che non rispecchia la realtà operativa dell’azienda. Implementare un sistema gestionale standard senza prima aver mappato, analizzato e messo in discussione i flussi di lavoro reali è un investimento destinato al fallimento, un vero e proprio suicidio economico.

Il problema risiede nel “debito di processo“: quell’insieme di eccezioni, scorciatoie e procedure informali che gli operatori adottano per far funzionare le cose “all’italiana”. Sono le deroghe commerciali concesse al cliente storico, le modifiche all’ordine gestite via post-it, i flussi di approvazione basati su una stretta di mano. Un ERP standard non conosce queste eccezioni. Forza l’azienda in un modello rigido che, scontrandosi con la realtà, genera inefficienza, frustrazione e, infine, il rigetto. I dipendenti, per poter lavorare, iniziano a creare sistemi paralleli (i famigerati fogli Excel), vanificando l’investimento e la promessa di un dato unico e centralizzato.

Un ERP che non funziona correttamente in tempi normali diventerà il singolo punto di rottura più grande durante una crisi. Se i dati sono inaffidabili, se i processi sono bloccati, ripristinare il sistema non servirà a nulla. L’azienda sarà operativa tecnicamente, ma paralizzata funzionalmente. La mappatura dei flussi (AS-IS) e la progettazione di quelli futuri (TO-BE), coinvolgendo gli utenti chiave che conoscono le eccezioni, non è un costo aggiuntivo del progetto ERP, ma la sua più importante polizza assicurativa.

Prima di investire in un software per la resilienza, investa tempo per capire come la sua azienda lavora davvero. La tecnologia deve adattarsi al processo, non il contrario. Soprattutto in un’emergenza.

Quando il fornitore IT fallisce: come avere un piano di uscita rapido

La sua strategia di continuità operativa dipende in larga parte da fornitori esterni: il provider del data center, la software house che ha sviluppato il gestionale, l’agenzia che gestisce il cloud. Ma cosa succede se a fallire non è la sua azienda, ma uno di questi partner critici? Un fallimento, un’acquisizione ostile, un grave problema di liquidità o un disservizio prolungato del suo fornitore IT possono avere lo stesso impatto di un incendio in ufficio. Affidarsi a un unico fornitore per un servizio critico senza un piano di uscita (exit strategy) è come navigare con una sola ancora.

L’errore comune è credere che il contratto legale sia una protezione sufficiente. In una crisi, le clausole contrattuali servono a poco se l’operatività è bloccata. La vera protezione è un piano tecnico e organizzativo per migrare rapidamente a un’alternativa. Questo piano deve includere tre elementi non negoziabili. Primo: la proprietà e l’accesso ai dati. I suoi dati devono essere sempre esportabili in un formato standard e lei deve possedere le credenziali di amministrazione (root) per accedervi, anche se il servizio è gestito esternamente. Secondo: la documentazione. L’intera architettura, le configurazioni e le procedure devono essere documentate e conservate internamente, non lasciate nella testa o sui server del fornitore.

Terzo, e più strategico, è il concetto di “fornitore dormiente“. Si tratta di identificare e negoziare un contratto quadro con un provider alternativo prima che si verifichi una crisi. Questo fornitore “dormiente” conosce già la sua infrastruttura, ha le competenze per intervenire e ha dei termini contrattuali pre-approvati. L’attivazione può così essere quasi immediata, trasformando un processo di migrazione che richiederebbe mesi in un’operazione di pochi giorni.

Non dia per scontata la solidità dei suoi partner. Pianifichi la loro uscita di scena con la stessa cura con cui ha pianificato il loro ingresso. La sua continuità dipende anche dalla loro.

Perché il tuo backup è inutile se non hai mai provato il ripristino (Crash Test)

Il backup è il pilastro di ogni strategia di Disaster Recovery. Avere copie dei dati è fondamentale. Tuttavia, un backup non testato è solo un’ipotesi, non una certezza. È come avere un estintore che non si sa se funziona. L’unico modo per trasformare l’ipotesi in una garanzia è eseguire periodicamente un “Crash Test Operativo“: una simulazione completa di ripristino dei dati e dei sistemi. Solo provando a ripristinare si scoprono i problemi nascosti: backup corrotti, procedure di recupero non documentate, dipendenze software dimenticate, tempi di ripristino molto più lunghi del previsto.

Come disse un esperto del settore, “un piano non testato è solo teoria”. Il crash test non è solo una verifica tecnica, ma un allenamento per il team e una validazione del processo. Coinvolgere gli utenti finali nel test è cruciale. Sono loro, non l’IT, a poter confermare se i dati ripristinati sono integri e se le applicazioni funzionano come dovrebbero. Un ripristino tecnicamente riuscito ma funzionalmente inutile non serve a nulla.

Un piano non testato è solo teoria.

– CDLan, Business continuity e disaster recovery: guida alla strategia integrata

Inoltre, nel contesto normativo attuale, documentare i test di ripristino è diventata una prova fondamentale. Per il GDPR, dimostrare di testare regolarmente l’efficacia delle misure tecniche e organizzative è un requisito chiave del principio di “accountability”. In caso di ispezione da parte del Garante della Privacy o della Guardia di Finanza, un registro dei test di ripristino riusciti vale più di mille pagine di policy sulla sicurezza.

La fotografia seguente cattura l’essenza di questo processo: non è un’automazione fredda, ma richiede concentrazione, competenza e validazione umana. Il successo del ripristino dipende dalla persona che lo governa e lo verifica.

Uno studio legale milanese, ad esempio, utilizza i test di ripristino trimestrali come prova tangibile. Questi test includono scenari reali, come il recupero granulare di singole email richieste dalle autorità o la simulazione del ripristino dell’intero database su un’infrastruttura cloud diversa da quella di origine. Questa documentazione proattiva li ha protetti da sanzioni, dimostrando la loro diligenza.

Programmi un “Crash Test Operativo” nel suo calendario aziendale con la stessa importanza di un consiglio di amministrazione. È l’unico modo per sapere con certezza se la sua polizza assicurativa sui dati è valida.

Perché il piano di continuità di 3 anni fa è carta straccia oggi?

Molte aziende creano un piano di continuità operativa, lo archiviano e lo considerano un compito “fatto”. Questo è uno degli errori più pericolosi. Un piano di continuità non è un monumento da ammirare, ma un organismo vivente che deve adattarsi a un ambiente in costante cambiamento. Un piano scritto tre anni fa, o anche solo un anno fa, è molto probabilmente obsoleto e inadeguato oggi. Le ragioni sono molteplici: tecnologiche, organizzative e, soprattutto, normative.

L’azienda si evolve: vengono introdotti nuovi software, i processi vengono modificati, le persone cambiano ruolo, nuovi fornitori critici entrano nella catena del valore. Ogni cambiamento, se non riportato nel piano, crea un nuovo potenziale punto di rottura. Il responsabile della logistica di tre anni fa potrebbe aver lasciato l’azienda, e il suo sostituto potrebbe non essere nemmeno a conoscenza del suo ruolo nel team di crisi. Il nuovo software di CRM basato su cloud, non presente nel vecchio piano, potrebbe essere diventato il cuore pulsante delle vendite.

Ma il fattore che rende i vecchi piani più rapidamente obsoleti è l’evoluzione del contesto normativo e legale, particolarmente dinamico in Italia e in Europa. Un piano che non tiene conto di questi cambiamenti non solo è inefficace, ma espone l’azienda a gravi rischi di non conformità. Come dimostra la tabella seguente, gli ultimi anni hanno visto un’accelerazione delle normative che impattano direttamente la gestione della continuità e della resilienza.

Questa evoluzione legislativa, come illustrato in una recente analisi comparativa delle normative, trasforma la continuità operativa da una best practice a un obbligo di legge per un numero crescente di settori.

La continuità operativa deve diventare parte del ciclo di vita della gestione aziendale. Preveda revisioni periodiche, almeno annuali, e dopo ogni cambiamento significativo nell’organizzazione. Tratti il suo piano di continuità non come un documento finito, ma come la versione corrente di una strategia in continua evoluzione per garantire la promessa fatta ai suoi clienti.