Da dove parte il Business Continuity Plan
Con l'espressione "Business Continuity Plan" si identifica un processo fortemente dinamico i cui confini tematici hanno subito negli ultimi anni un drammatico mutamento, muovendosi da un'interpretazione rivolta essenzialmente al Disaster Recovey, focalizzato univocamente su information technology and system recovery, a tutti gli aspetti del business spaziando, quindi, dai metodi di alta affidabilità dei sistemi, fino alle gestione delle risorse umane: si è maturata nel tempo la coscienza di essere di fronte ad un processo di gestione che deve essere costantemente revisionato, aggiornato e testato al fine di creare massima aderenza alle esigenze di business (in figura 1 si vede come il Disaster Recovey è una disciplina le cui tematiche sono un sottoinsieme di quelle del Business Continuity Plan.).

Figura 1 - Business Continuity Plan: un sovrainsieme del disaster recovery

Tutto ciò che è necessario per la continuità operativa, sia i processi essenziali, sia quelli di supporto, devono essere analizzati e presi in considerazione nella definizione di un piano di continuità.
Considerando che le necessità di business mutano sotto l'influenza di fattori esterni (reazione a cambiamenti del mercato) ed interni (riassetto organizzativo) il piano di continuità può essere paragonato ad una istantanea dell'azienda e pertanto valido fino a quando i suoi tratti non mutano. E' per questo che spesso si parla di Business Continuity Plan come processo aziendale.
Da quanto detto si deduce che sicuramente la definizione di un piano di continuità parte da una esigenza di affidabilità dei sistemi intesa non solo come risposta a problemi IT ma soprattutto come Disponibilità dei sistemi a supporto dei Processi di Business.

Oltre a tale necessità propriamente operativa, esistono altre esigenze che inducono alla definizione di un piano di continuità: le variabile macroambientali. Si pensi ad esempio all'accordo di Basilea II che, con l'introduzione del requisito patrimoniale per "Il rischio Operativo", ha ripercussioni anche finanziarie sulle aziende.
Una delle minacce reputata di maggior impatto dal comitato di Basilea è: "Business Distruption and System Failure".
Il Comitato sottolinea anche che le banche dovrebbero effettuare degli audit (interni o esterni) periodici ed indipendenti sulla propria business continuity e contingency planning.
Come visto la "Business Continuity" è una componente critica di ogni organizzazione. Nuove leggi, le aspettative degli azionisti, i requisiti degli investitori richiedono perciò un solido piano di continuità del servizio integrato con gli altri processi aziendali.
E' necessario adottare allora una metodologia di BCP ben strutturata e verificabile; al momento sono disponibili un elevato numero di standard: i più importanti sono stati sviluppati dal "Disaster Recovery International Institute" (DRI), dal "Business Continuity Institute" (BCI), dal "National Institute of Standards and Technology" (NIST) e dalla "Information Systems Audit and Control Association" (ISACA). Tutte queste organizzazioni concordano sulla presenza del seguente set minimo di best practices quando si disegna e realizza un piano di business continuity:

• deve essere approvato un budget per il BCP da parte del top management;
• deve essere identificato una struttura che in caso di disastro o di interruzione del servizio coordini la strategia di ripristino;
• deve essere previsto un sistema per la gestione degli incidenti o comunque un processo per controllare la situazione ed operare il ripristino;
• il piano deve essere periodicamente rivisto.

Riprendendo quanto finora detto, possiamo riassumere gli obiettivi di un Business Continuity Plan in:

• Ripristinare una situazione di normalità, entro un tempo prestabilito, in funzione dei livelli attesi di servizio e di rendere minime le perdite procurate dall'interruzione delle attività.
• Garantire continuità dei principali processi per assicurare l'erogazione dei servizi critici.

L'implementazione di Continuity Plan pur differendo a seconda dell'ambiente di riferimento, presenta alcuni punti in comune.

Livelli di servizio: un puzzle da risolvere
Qualunque sia la realtà che si vuole analizzare, esiste sempre e comunque un punto di partenza: la definizione dei processi e i relativi livelli di servizio.
Che cosa è esattamente un processo? Come posso definire un livello di servizio?
Non esiste un'unica definizione e soprattutto non esiste una regola, una "formula" che possa essere applicata per identificare un processo.
Non si può pensare di limitare l'identificazione dei processi a quelli dell'infrastruttura tecnologica: le tecnologie costituiscono solamente uno degli aspetti che influenzano il corretto funzionamento di un processo. Essenzialmente il punto di partenza è l'identificazione delle esigenze di business: quali strumenti vengono utilizzati dalle principali funzioni aziendali? Chi sono le persone chiave di tali funzioni? Esiste una procedura che deve essere seguita per svolgere tale attività?. La "concatenazione" delle risposte alle precedenti domande può dare una prima idea di processo: un processo quindi può essere definito come un'attività di business, supportata da opportuni strumenti e condotte da persone sulla base di procedure. Nel caso in cui esista un sistema informativo di supporto alle attività, come ad esempio un ERP interno all'azienda, è essenziale verificare quali siano i componenti applicativi che forniscono il sevizio; in questo caso specifico la maggior parte degli sforzi per la definizione del piano, devono essere incentrati nell'analisi dell'applicativo: poiché ci si appoggia su un sistema informativo per la totalità o comunque buona parte delle attività, è chiaro che il sistema rappresenta il fulcro del business.
Spesso la determinazione di un livello garantito è percepita semplicemente come un contratto attivabile laddove si instauri un rapporto con un fornitore esterno, ma meno ritenuto necessario/opportuno qualora ci si muova nell'ambito aziendale. In una logica di massimizzazione dell'efficienza e dell'efficacia appare auspicabile la sistematica applicazione di regole e presidi analoghi a quelli utilizzati nei rapporti con fornitori esterni. In generale, comunque, l'importanza di fissare con precisione la qualità attesa/garantita dei servizi informatici, di disporre di adeguati strumenti per la sua verifica e di un apposito flusso informativo che renda conto all'utente della qualità effettivamente erogata non sembrerebbe essere un dato acquisito in maniera generalizzata. Sul punto sarebbe forse opportuno un più elevato grado di consapevolezza, che, partendo dall'individuazione di una metodologia porti prima di tutto a specificare in maniera corretta i processi e successivamente i relativi livelli di servizio.
Nella definizione dei livelli di servizio è necessario tener conto dell'influenza di più attori coinvolti nella fruizione del servizio. Si prenda a ad esempio un sistema applicativo, le figure interessate sono:

1. Contraente: chi trae vantaggio dall'erogazione del servizio. Definisce tutti i requisiti;
2. Utente: chi utilizza il servizio;
3. Fornitore: chi gestisce il servizio.

Ciò che più importa mettere in evidenza è che a seconda della prospettiva con cui si guarda un sistema applicativo, si possono definire in modo diverso sia i servizi, sia gli utenti e i fornitori di quei servizi.
Considerando i servizi forniti da una qualunque applicazione in un ambiente pubblico (es. applicazione per la gestione dell'anagrafica di un comune), la prospettiva più ampia che possiamo abbracciare vede il servizio usato da un utente (umano- ad esempio un addetto dello sportello del comune -) e lo stesso servizio dipendere fortemente da eventuali servizi legacy o da applicazioni esterne. Il livello di servizio del processo in questo caso viene a coincidere con quello che ciascuna componente applicativa è in grado di fornire.
Generalizzando si può pensare di scomporre l'applicazione in componenti e associare a ciascuno di questi un livello di servizio. In figura 2 i pallini rossi rappresentata ognuno uno step di processo implementate da un componente applicativo differente. Come si vede processi differenti possono avere coincidenze di esecuzione: ogni processo viene suddiviso in step di processo che possono coincidere nell'implementazione.

Figura 2 - Composizione dei livelli di servizio

Il livello di servizio associato a ciascun processo si ripercuote su ciascun componente applicativo: garantire un livello di servizio per l'intero processo, significa garantire il livello di servizio di ciascun componente. Da quanto detto si deduce che per la definizione dei livelli è necessario avere delineato con chiarezza come sono mappati i processi sui componenti applicativi e quali sono le interdipendenze: se uno un componente applicativo è utilizzato da più processi questo deve avere associato un livello di servizio maggiore. Si pensi ad esempio ad un sistema di autenticazione in un'applicazione web la cui esecuzione è preposta a qualunque attività, è ovvio che questo componente debba avere un livello di servizio sicuramente maggiore rispetto a tutti gli altri (in figura 3 sono riportati gli step necessari per l'individuazione dei livelli di servizio per un'applicazione).
Possiamo sinteticamente riportare quattro passi fondamentali per la definizione dei livelli di servizio:

1. definire attributi quantitativi degli aspetti non funzionali d'uso (attributi dell'associazione utente-servizio) dettati in genere da necessità di business/organizzativ;
2. definire i vincoli derivati dall'uso di eventuali servizi esterni (attributi dell'associazione servizio-servizi esterni);
3. definire eventuali vincoli di gestione del servizio, come ad esempio vincoli sindacali, di reperibilità, ecc (attributi della associazione fornitore-servizio);
4. definire ulteriori eventuali vincoli derivati dalle scelte di architettura e progettazione del servizio (vincoli interni, mappatura dei processi su componenti applicative).

Dal punto di vista pratico, ogni livello di servizio di concretizza in un tempo di ripristino ovvero il tempo massimo che deve intercorre tra il momento in cui si verifica l'indisponibilità del sistema e il momento in cui riprende l'attività.

Figura 3 - I passi del processo di redazione

Le procedure
Una volta identificati i processi più critici e associatogli un livello di servizio, è necessario definire le procedure: come abbiamo detto all'inizio dell'articolo, il Continuity Paln si concretizza in un'insieme di procedure atte a garantire il ripristino dei servizi in caso di "rotture". Che tipo di procedure devo avere? Cosa devono contenere queste procedure?
La definizione delle procedure è differente a seconda della realtà in cui ci troviamo. Risulta pertanto più utile, per la finalità di questo articolo, identificare categorie di procedure. Possiamo innanzitutto identificare due differenti categorie:

Generiche: procedure di carattere generale che costituiscono il punto di partenza nella gestione dei problemi. Fanno parte di questo gruppo:

• Procedure di Problem escalation.
• Procedure di Problem determination.
• Procedure di gestione/manutenzione degli ambienti.

Le procedure di Problem Escalation identificano "le responsabilità" del problema e indirizzano verso l'ente di competenza: ad esempio definiscono i passi necessari per verificare, in caso di fermo di un servizio, se si tratta di un problema sistemistica oppure applicativo. In realtà complesse e dovutamente strutturate (la mancanza di organizzazione interna, è sicuramente l'ostacolo maggiore a cui si incorre nella definizione di un Continuity Plan e per tanto deve essere considerato un prerequisito) le responsabilità e quindi le conoscenze, sono sempre suddivise per enti interni a cui spetta la risoluzione dello specifico problema. Capire l'essenzialità di tali procedure è il punto di partenza per la definizione di un Continuità Plan.
Le procedure di Problem Determination definiscono, una volta affidata la risoluzione del problema ad un ente, gli step necessari per identificare con esattezza il problema. Se esempio se il problema è imputato all'ente sistemi, è suo compito identificare con esattezza la tipologia di problema. Le procedure di Problem determination devono assolvere tale compito.
Le procedure di gestione/manutenzione degli ambienti sono necessarie per il mantenimento dei sistemi e come attività preventiva nei confronti di possibili malfunzionamenti. Tali procedure regolarizzano tutte quelle attività (es. aggiornamenti dei sistemi, installazioni di patch, migrazione degli ambienti, etc.) di "quotidiana" amministrazione che se condotte in modo non "standardizzato" possono condurre a fermi dei sistemi.

La categoria Specifiche raggruppa le procedure atte alla risoluzione di ogni singolo problema. Sono di "proprietà" di ciascun ente e costituiscono l'ultimo anello della catena che, partendo dall'individuazione delle competenze, conduce alla risoluzione di un singolo problema. In figura è riportato un semplice schema dei tale processo mettendo in evidenza anche le responsabilità.

Figura 4 - le responsabilità delle procedure

Conclusioni
Un Continuity Plan essendo uno "strumento" essenziale per garantire piena disponibilità dei servizi, necessita di un po' di tempo e di risorse per poter essere definito; Tutta l'azienda è direttamente coinvolta per lo sviluppo e l'effettivo successo del piano e una cultura di responsabilizzazione della completa struttura aziendale è necessaria come requisito primario.