Un guasto informatico, l’assenza improvvisa di una persona chiave o il blocco di un fornitore possono rallentare un’azienda in poche ore. Un piano di contingenza serve a decidere in anticipo chi fa cosa, con quali risorse e entro quali tempi, così da ridurre improvvisazione e perdite. Qui propongo un esempio concreto, alcuni scenari frequenti e un metodo pratico per costruire, testare e aggiornare il proprio piano.
Un piano efficace trasforma l’imprevisto in una sequenza di azioni gestibili
- Obiettivo: mantenere operative le attività essenziali durante una crisi.
- Struttura: rischio, segnali di attivazione, responsabili, procedure e tempi di recupero.
- Esempio pratico: gestione di un attacco informatico con blocco dei sistemi aziendali.
- Risorse umane: ruoli sostitutivi, contatti aggiornati e comunicazioni interne chiare.
- Verifica: simulazioni almeno ogni 6-12 mesi e revisione dopo ogni incidente significativo.
Che cos’è un contingency plan aziendale e a cosa serve
Un contingency plan è un piano alternativo che indica come reagire quando un evento interrompe, o rischia di interrompere, una parte importante dell’attività. Non coincide con un semplice elenco di rischi: deve tradurre ogni scenario in decisioni operative, responsabilità e priorità.
Io lo considero una sorta di copione per i momenti in cui nessuno dovrebbe perdere tempo a chiedersi da dove cominciare. Il piano non elimina l’imprevisto, ma riduce il tempo tra l’allarme e la prima azione utile, proteggendo clienti, dipendenti, dati e ricavi.
È utile distinguerlo da altri strumenti. Il business continuity plan riguarda la continuità complessiva dell’organizzazione, mentre il disaster recovery plan si concentra soprattutto sul ripristino di sistemi, infrastrutture e dati. Il piano di contingenza può collegare entrambi, ma spesso è più mirato e dedicato a un singolo rischio.
Quando è davvero necessario
Non serve creare un documento di cinquanta pagine per ogni possibile inconveniente. Ha senso partire dagli eventi che combinano alta probabilità e forte impatto, oppure da quelli meno probabili ma capaci di fermare completamente un processo essenziale.
- interruzione dei sistemi informatici o attacco ransomware;
- assenza di una persona con competenze difficili da sostituire;
- blocco di un fornitore o di una piattaforma digitale;
- inagibilità della sede o impossibilità di raggiungerla;
- perdita, divulgazione o indisponibilità di dati importanti;
- crisi reputazionale o comunicazione errata verso clienti e dipendenti.
Un esempio completo di piano per un attacco informatico
Immaginiamo una media impresa con 45 dipendenti. Il gestionale, il CRM e i file condivisi diventano improvvisamente inaccessibili. Il piano deve chiarire non solo come recuperare i dati, ma anche come continuare a lavorare nel frattempo.
| Elemento | Esempio operativo |
|---|---|
| Rischio | Blocco dei server o possibile attacco ransomware. |
| Segnale di attivazione | Accesso ai sistemi impossibile per oltre 15 minuti o rilevamento di attività sospette. |
| Responsabile iniziale | Responsabile IT, oppure referente esterno indicato nell’elenco delle emergenze. |
| Prime azioni | Isolare i dispositivi colpiti, sospendere gli accessi remoti e conservare i log dell’incidente. |
| Continuità minima | Usare moduli offline, contatti telefonici e una cartella cloud separata già predisposta. |
| Comunicazione interna | Inviare un messaggio ufficiale entro 30 minuti, indicando cosa è bloccato e cosa resta operativo. |
| Obiettivo di ripristino | Ripristinare le funzioni essenziali entro 4 ore, se il danno lo consente. |
| Fine dell’emergenza | Riapertura controllata dei sistemi dopo verifica tecnica e autorizzazione del responsabile. |
I tempi indicati sono **esemplificativi**, non valori validi per ogni azienda. Il tempo massimo entro cui un processo dovrebbe tornare disponibile è chiamato RTO, mentre l’RPO indica quanta quantità di dati l’organizzazione può permettersi di perdere rispetto all’ultimo salvataggio.
Il ruolo delle persone nel piano
Un documento IT fallisce se il personale non sa come comportarsi. Per questo inserirei una tabella con almeno tre ruoli: chi prende la decisione, chi esegue le azioni tecniche e chi comunica con dipendenti, clienti e fornitori.
Prevederei anche un sostituto per ogni ruolo critico. Se l’unico amministratore di sistema è assente, il piano deve indicare una persona interna o un fornitore esterno autorizzato, con recapiti aggiornati e accessi gestiti in modo sicuro.
Come costruire un piano di contingenza in modo pratico
Il metodo più utile, secondo la mia esperienza, è procedere per priorità e non per quantità di documenti. Un piano breve, leggibile e provato sul campo vale più di una procedura completa che nessuno riesce a consultare durante una crisi.
- Individua i processi essenziali. Elenca ciò che deve continuare anche in emergenza, come fatturazione, assistenza clienti, paghe, produzione o consegne.
- Valuta i rischi. Per ogni processo considera probabilità, impatto economico, conseguenze sulle persone e tempo massimo di interruzione accettabile.
- Definisci i trigger. Un trigger è il segnale che fa scattare il piano. Può essere un’ora di indisponibilità, una soglia di assenze o la conferma di un incidente.
- Assegna responsabilità precise. Ogni attività deve avere un titolare e un sostituto. Evita formule vaghe come “se ne occupa l’ufficio competente”.
- Prepara alternative realistiche. Inserisci fornitori secondari, sedi di riserva, strumenti offline, procedure manuali e canali di comunicazione alternativi.
- Stabilisci tempi e criteri di rientro. Indica quando iniziare il ripristino, chi lo autorizza e quali controlli devono essere completati prima di tornare alla normalità.
Per documentare il lavoro può essere utile una Business Impact Analysis, cioè un’analisi che misura quanto l’interruzione di ogni attività incida sull’azienda. Non la trasformerei in un esercizio burocratico: bastano una matrice di priorità, alcuni responsabili e una stima concreta dei danni.
Tre scenari aziendali da trasformare in esempi
Assenza improvvisa di una persona chiave
In una piccola azienda commerciale, il responsabile ordini conosce procedure, clienti e condizioni speciali senza averle documentate. Il piano dovrebbe prevedere un sostituto formato, una lista dei clienti prioritari, credenziali gestite correttamente e una procedura essenziale per approvare gli ordini.
Questo scenario mostra un errore frequente: confondere la riservatezza con la dipendenza da una sola persona. La soluzione non è distribuire indiscriminatamente tutte le informazioni, ma creare accessi controllati e una documentazione minima che permetta di lavorare anche durante un’assenza prolungata.
Blocco di un fornitore strategico
Un’azienda manifatturiera può dipendere da un solo fornitore per un componente con tempi di consegna di 20 giorni. Un piano sensato indica una seconda fonte qualificata, una scorta minima, i criteri per attivarla e la persona autorizzata a sostenere il costo aggiuntivo.
Non sempre il fornitore alternativo è economicamente conveniente. Il compromesso può consistere nel mantenere una quantità ridotta di scorte o nel firmare un accordo quadro senza acquistare subito grandi volumi. L’obiettivo è comprare resilienza senza immobilizzare risorse inutilmente.
Leggi anche: One page business plan - guida pratica per la tua impresa
Inagibilità della sede
Se l’ufficio non è accessibile per un incendio, un guasto o un problema strutturale, il piano deve stabilire dove lavorare e con quali strumenti. Le alternative possono includere lavoro da remoto, coworking temporaneo o una sede secondaria, ma vanno verificate prima dell’emergenza.
Qui entrano in gioco anche le risorse umane. Bisogna sapere quali attività possono essere svolte da casa, quali dipendono da apparecchiature presenti in sede e come comunicare eventuali cambiamenti di orario o turnazione senza creare confusione.
Come testare il piano e correggere gli errori
Un piano non testato è soltanto un’ipotesi. Io inizierei con una simulazione di 60-90 minuti, coinvolgendo le persone che dovrebbero davvero intervenire e osservando dove si bloccano le decisioni.
Durante l’esercitazione controllerei almeno questi aspetti:
- il personale sa riconoscere il segnale di attivazione?
- i numeri di telefono e gli indirizzi email sono aggiornati?
- chi può dichiarare l’emergenza?
- le procedure funzionano anche senza rete o gestionale?
- i backup sono accessibili e realmente ripristinabili?
- i tempi di recupero sono compatibili con le esigenze dei clienti?
Dopo il test, raccoglierei gli errori in un registro con tre colonne semplici: problema, responsabile della correzione e data prevista. È una pratica poco spettacolare, ma fa emergere rapidamente ciò che sulla carta sembrava funzionare e nella realtà no.
La revisione dovrebbe avvenire almeno una volta all’anno e ogni volta che cambiano sede, software, organigramma, fornitori o modalità di lavoro. Un piano vecchio può essere più pericoloso di un piano assente, perché crea una falsa sensazione di preparazione.
Il valore nascosto di un piano pensato anche per le persone
La parte tecnica attira più attenzione, ma durante una crisi la qualità delle comunicazioni interne può fare la differenza. Un messaggio breve, firmato da un responsabile e con istruzioni precise riduce voci, duplicazioni e decisioni contraddittorie.
Consiglio di preparare in anticipo almeno tre modelli di comunicazione: uno per il personale, uno per i clienti e uno per i fornitori. Non devono contenere dettagli riservati, ma indicare cosa è successo, quali servizi restano disponibili e quando arriverà il prossimo aggiornamento.
Il miglior esempio di contingency plan, alla fine, non è quello più lungo. È un documento aggiornato, accessibile alle persone giuste, costruito su rischi concreti e verificato con una simulazione. Se ogni collaboratore sa qual è il proprio primo passo, l’azienda ha già trasformato una parte dell’incertezza in capacità di reazione.
