L’analyse d’impact sur les entreprises (BIA), comment faire?

Comment créer une analyse d’impact sur les entreprises (BIA) ? Je suppose que l’organisation est suffisamment mûre pour savoir pourquoi le BCM est nécessaire et donc pourquoi un BIA est nécessaire dans le processus de BCM. Il s’agit d’un mode de mise en œuvre possible du BIA. Le principe est que l’organisation gère déjà les risques et dispose d’une analyse des risques qui est également utile pour les processus de l’organisation. Bien que cela ne soit pas toujours nécessaire. Nombreux sont ceux qui jugent opportun de procéder d’abord à l’analyse de l’impact sur l’environnement parce qu’ils peuvent ainsi soumettre les processus les plus importants à une analyse de risque complète. Nous commençons donc par une analyse de l’impact sur les entreprises.

Dans cette contribution, j’écris ma propre opinion, et non celle d’une quelconque organisation. Cette contribution s’inspire des travaux suivants :   Planification de la continuité des activités : un non-sens pour les planificateurs de la continuité occupés ; Charley Newnham   Le manuel définitif de gestion de la continuité des activités 3° édition ; Andrew Hiles

La BIA classique fait de grands progrès :

Comprendre l’organisation et ses processus

Identifier les ressources nécessaires

Estimer les menaces et les risques.

Comprendre l’organisation et ses processus

Identifier tous les processus de l’organisation

Identifier les processus critiques (CP), les processus essentiels (EP), les processus nécessaires (NP) et les processus utilisables (PU).

Identifier les parties prenantes et les parties intéressées.

Estimer l’impact dans le temps de chaque processus en cas d’abandon ou d’interruption.

Déterminer l’objectif de temps de reprise (RTO) et l’objectif de point de reprise (RPO) pour chaque processus.

Identifier les dépendances internes et externes.

• Entre autres, également des calendriers d’autres plans
• Également des mesures déjà prises et à prendre
• À partir de manuels et de documents
• …

Trier la liste en fonction du RTO

Choisissez maintenant les processus top-x pour lesquels vous souhaitez élaborer le PCA ultérieurement (il s’agit des processus dont le délai est critique).

Identifier les ressources nécessaires

Humain : définir les rôles pour exécuter les processus,

• Combien d’ETP sont nécessaires ?
• Quels sont les clients nécessaires ?
• Quelle est l’assistance technique nécessaire ?
• Quels sont les fournisseurs nécessaires ?
• Avons-nous besoin de personnel d’autres entités ?

Machines : accès aux données ; capacités de télétravail ;…

Données requises

Postes de travail requis

• Bureaux
• Chaises
• Ordinateurs
• Chauffage
• Café
• Espace de réunion
• Salle technique
• Préférence géographique

Estimer les menaces et les risques.

• Utiliser les résultats de l’analyse de risque déjà effectuée pour les processus.
• Dans un premier temps, limitez-vous aux processus critiques en termes de temps.

Ainsi, une BIA possible présente les tableaux et la disposition suivants :

Étape 1 : liste des processus
séquence	Processus/activité	Description de l’impact	impact 1-5	RTO	Priorité RTO	RPO	Dépendances	CP/ NP/ EP/ PU

Étape 2 : ressources nécessaires pour les processus critiques
Processus de suivi	Rôles requis, nombre	Outils et systèmes requis	Matériel requis	Espace de travail nécessaire / Nombre de personnes	Autres départements/unités organisationnelles/fournisseurs/services	contacts et fonctions et informations de contact

Étape 3 : évaluation des menaces/risques.
Processus de suivi	Déclaration de menace/risque	Opportunité/ raison	Probabilité Élevée/ … / Faible	Impact/ Description	Impact élevé/ … / Faible	Risque élevé/ … / Faible	Accepter/ Déplacer/ Réduire/ Supprimer / Ce qui est déjà en place à titre préventif ?

Propriétaire de la BIA : xxx xxxxx

Senior Customer BIA : xxx xxxxx

Date de la version : aaaammjj

Version : NN.nn

Au secours, j’ai un BIA !

Vous savez donc que la vie du BIA est un processus qui a un but. L’objectif est de soutenir un PCA réaliste. Et pour cette raison, c’est un exercice qui porte ses fruits en cas de catastrophe.

Si vous devez créer un nouveau (premier) PCA :

• Ensuite, vous partagez l’AIB avec les personnes qui ont besoin de la comprendre. Vous leur demandez également leur avis et leur retour d’expérience.
• Ensuite, vous vous assurez que la planification n’inclut que les CP (processus critiques) qui sont importants dans la fenêtre temporelle couverte par votre plan.
• Faites ensuite signer l’AIP par le superviseur et assurez-vous qu’il est d’accord avec le contenu de l’AIP.

Si vous avez déjà un PCA que vous devez mettre à jour,

• Assurez-vous ensuite que les processus critiques de l’AIB et les priorités du plan correspondent.
• Il faut ensuite s’assurer que le PCA est aligné sur les RTO dans le BIA.
• Il faut ensuite s’assurer que les accords de niveau de service sont alignés sur les délais d’exécution dans le BIA.
• Ensuite, vous partagez l’AIB avec ceux qui ont besoin de la comprendre. Vous leur demandez également leur avis et leur retour d’expérience.
• Ensuite, vous vous assurez que la planification n’inclut que les CP (processus critiques) qui sont importants dans la fenêtre temporelle couverte par votre plan.
• Faites ensuite signer l’AIP par le superviseur et assurez-vous qu’il est d’accord avec le contenu de l’AIP.

Révision de la BIA.

Le BIA est le fondement du PCA (BCP). Elle permet de comprendre pourquoi ce qui est inclus dans le PCA et ce qui ne l’est pas. La mise à jour d’un PCA est donc plus rapide, mais il faut également veiller à ce que le BIA soit exact. Faites ceci

• Une fois par an
• Lors de tout changement important dans l’organisation (nouveaux processus, fin des anciens processus, nouveau bâtiment, changement de personnes telles que le personnel, le personnel,…, les fournisseurs, les citoyens, changement de l’environnement, changement des accords de niveau de service, …), l’organisation doit être en mesure d’offrir des services de qualité.

Vous vérifiez donc, lors d’une révision, si quelque chose a changé depuis la version précédente.

Description et utilité des thèmes du BIA.

Informations sur le processus pour la BIA	Description et utilité
Nommez un processus critique en termes de temps et/ou de mission	Description : Identification du processus qui est : critique en termes de temps : un processus qui doit être redémarré dans les 48 heures suivant un incident ; et/ou critique en termes de mission : un processus qui contribue à la réalisation de la mission d’une entité. Utilité : Liste des processus sensibles dont dépend notamment la survie de l’organisation.
Processus de description	Description : Brève explication de ce qu’implique le processus critique en termes de temps/mission, quand il commence et quand il se termine. Utilité : Tant qu’il n’existe pas de noms génériques pour les processus, la description est nécessaire pour clarifier le contenu du processus prévu.
Outil de processus	Description : Les personnes et les ressources nécessaires à l’exécution d’un processus critique en termes de temps et/ou de mission. Chaque ressource de travail détermine la ou les périodes pendant lesquelles elle est urgente, le nombre d’unités nécessaires et l’alternative qui peut être proposée. Les ressources de travail du processus peuvent comprendre – Personnel (nombre et fonction) – Postes de travail – Téléphones / Fax / téléphones portables – Postes de travail – Ordinateurs portables – Services d’impression et de copie – Accès au courrier électronique – Accès à l’internet – …   Utilité : En période de crise, un processus peut être relancé plus rapidement si l’on sait quelles sont les ressources de travail nécessaires pour le faire.
Période du processus	Description : Heure(s) à laquelle le processus critique en termes de temps ou de mission est exécuté. Utilité : Cet indicateur de temps indique la période de l’année au cours de laquelle un processus présente le degré d’urgence sélectionné. Il peut être différent pour les processus saisonniers, par exemple. Cela permet d’établir des rapports flexibles afin de mettre en place une réparation qui soit la plus pertinente possible au moment où la crise se produit.
Impact en cas de défaillance du processus	Description : Décrit l’étendue des dommages subis. Ces impacts peuvent inclure des dommages à la réputation, des dommages financiers, des dommages humains, des retards de travail, des dommages matériels, … L’utilité : L’impact est souvent considéré comme le degré d’urgence pour déterminer « l’urgence d’un processus ». Il s’agit donc d’un indicateur de l’ampleur des pertes de toutes sortes qui pourraient résulter de l’échec d’un processus.
RTO : Objectif de temps de récupération	Description : Le délai accordé par la direction entre un incident perturbateur et le redémarrage provisoire des opérations, souvent à un niveau de capacité prédéterminé. Utilité : Cette quantité est un indicateur plus fin de l’urgence du redémarrage des processus et donne aux techniciens une indication de l’ordre de priorité dans lequel ils devraient pouvoir redémarrer les processus au profit de l’organisation ou des organisations. Cet indicateur est notamment essentiel pour planifier le redémarrage des systèmes informatiques.
RPO : Recovery Point Objective (objectif de point de récupération)	Description : Période de temps autorisée entre deux moments de stockage sécurisé des données. C’est-à-dire la quantité maximale de données/transactions qui peuvent être perdues entre le dernier stockage de données sécurisé et l’incident perturbateur. Utilité : Cet indicateur est, pour les processus liés aux TIC, un indicateur lié au système de sauvegarde. Il donne une idée de l’ampleur du retard à rattraper et de la quantité de travail des derniers jours qui a pu être perdue.
Propriétaire de processus	Description : La personne responsable du litige. Utilité : Lorsqu’un processus particulier est impliqué dans un incident, la personne responsable peut facilement être notifiée.
Dépendances des processus	Description : Ces dépendances indiquent quels processus dépendent les uns des autres (dans les deux sens : « dépend de » et « est nécessaire pour »). L’utilité : Grâce à ces informations, on a une meilleure vision du problème et on peut prévenir l’évolution d’une cascade de crises.
Dépendance à l’égard du matériel	Description : La dépendance à l’égard du matériel, tel que les ordinateurs portables, les notebooks, les iPads, les iPhones, les serveurs, … Cette information devrait être claire (en partie : serveurs, …) dans le fichier d’exploitation. Utilité : Cela permet à l’informatique de fournir à la direction une estimation des dépenses en matériel, et de savoir quel matériel est nécessaire pour mettre en place un nouveau système sur lequel les processus seront exécutés.
Dépendance logicielle	Description : La dépendance à l’égard de logiciels, tels que les navigateurs, le système documentaire, le centre de gravité, le bureau,… Cette information doit être claire (en partie : serveurs,…) dans le fichier d’exploitation. Utilité : Cela permet à l’informatique de fournir à la direction une estimation des dépenses en logiciels et de savoir quels logiciels sont nécessaires pour mettre en place un nouveau système sur lequel les processus seront exécutés.
Dépendance financière	Description : dépenses liées au processus, au bâtiment, etc. Utilité : Cette dépendance permet de comprendre certains des coûts liés au redémarrage des processus. Cela permet de préparer/demander des budgets et des postes de coûts.
Dépendance à l’égard des installations	Description : Les dépendances des éléments tels que les sandwichs, le café, les tables, la bureautique, les chaises, l’électricité, les toilettes, l’eau, la lumière, l’air conditionné,… Utilité : Cela permet au directeur financier d’estimer les dépenses liées aux installations et de savoir quelles sont les installations nécessaires pour faire travailler les gens.
Dépendance des parties prenantes	Description : Il s’agit des données contenues dans les listes de contacts, telles que les fournisseurs, les clients, les employés… Utilité : Donne à la direction une vue d’ensemble de toutes les parties impliquées, avec lesquelles elle doit se mettre en rapport afin de rendre les processus à nouveau opérationnels par leur intermédiaire / pour leur compte.