Guide d'analyse d'impact sur l'entreprise

Tout le monde ne sait pas où et quand commencer à mettre en œuvre des plans de continuité des activités. Je dis généralement ceci: lorsque les pertes possibles sont supérieures aux coûts de la lutte contre la menace, il est temps de prendre des mesures, les coûts seront adéquats. Et vice versa. Si le coût de la contre-action est plus ou moins clair, l'estimation des pertes est une tâche non triviale. Je vous invite dans les coulisses d'un projet d'évaluation d'impact commercial (Business Impact Analysis - BIA) et développez une stratégie de continuité informatique en prenant comme exemple un grand détaillant. Alors allons-y.

Commencer

Nous avons participé au projet de X5 Retail Group - le plus grand détaillant en Russie. L'entreprise gère les réseaux de Pyaterochka, Carousel et Crossroads.

Elle avait déjà sa propre politique de gestion des risques d'interruption, qui comprenait:

1. assurance contre les risques;
2. formation de la gestion de crise;
3. minimisation des risques pour la vie et la santé des personnes;
4. maîtrise des risques de gestion d'entreprise;
5. Préparation de plans de reprise d'urgence pour les systèmes informatiques.

Conformément à cette politique, l'infrastructure informatique centralisée a nécessité l'élaboration de plans de continuité des services informatiques et de reprise après sinistre. La solution idéale serait de construire un centre de données de sauvegarde, de configurer la réplication synchrone, de configurer l'automatisation des transferts d'urgence et de regarder «H» à une heure sur l'écran comment les systèmes informatiques se déplacent vers le centre de données de sauvegarde et les voyants verts s'allument, signalant qu'il n'y a aucun danger pour les entreprises.

Mais en tenant compte de l'économie du processus, la société a suggéré que réserver uniquement les systèmes informatiques les plus critiques, sans lesquels les magasins ne pourraient pas fonctionner et les pertes financières importantes, serait une mesure adéquate en cas d'urgence. Une question importante se pose - quels systèmes et pour combien de temps faut-il restaurer?
Le service informatique du client a déterminé la classification des systèmes informatiques et le temps de récupération acceptable pour chaque système. Cependant, plus tard, il a été décidé de procéder à une évaluation complète de l'impact des urgences sur les activités de l'entreprise (BIA) conformément à la norme ISO 22301 et aux meilleures pratiques.

Volume et limites

Le théâtre commence par un cintre, et le BIA commence par la définition de l'étendue du travail. Pour ce faire, vous devez examiner les processus commerciaux de l'entreprise, ses services, ses états financiers, ses relations avec ses partenaires, ses clients et ses sous-traitants. Ensuite, identifiez et coordonnez les processus et services commerciaux clés qui entreront dans les limites du projet. La durée et le coût de la BIA dépendent du volume. De plus, notre expérience suggère que vous ne devez pas étirer le projet pendant plus de 9 mois.

Dans notre cas, le client a déjà déterminé les limites en choisissant les processus commerciaux les plus importants pour les activités de trading.

L'entretien

Une fois que les limites et le cadre de la LFI sont fixés, une liste des intervenants des entreprises et des autres services avec lesquels vous souhaitez mener une entrevue est déterminée. Il est très important de collecter des informations auprès de différents services afin d'avoir une image objective des processus dans l'entreprise, de comprendre comment ils fonctionnent, d'avoir une évaluation de «ce qui se passera si ...». À ce stade, nous obtenons des informations sur la façon dont les processus métier dépendent exactement de l'informatique et construisons une matrice de ces dépendances. En outre, les représentants des entreprises et les parties intéressées par le processus opérationnel évaluent les conséquences, les dommages possibles et les scénarios possibles. Pour cela, nous avons développé un questionnaire spécial et interviewé environ 50 répondants (présenté 50 présentations sur le projet lui-même, mené, reçu et traité tous les questionnaires remplis).

Processus d'affaires

Parallèlement aux entretiens, nous avons décrit les processus métier, en tenant compte du temps nécessaire pour achever les opérations individuelles et de la profondeur d'élaboration, suffisante pour une analyse plus approfondie. Le partitionnement d'un processus en composants plus petits et des opérations spécifiques est nécessaire afin de comprendre comment un système informatique affecte un processus particulier à différents moments de la journée et à différents moments de l'année. À ce stade, il est important de comprendre que nous ne décrivons pas les processus commerciaux selon GOST ou une autre méthodologie. Nous n'optimisons pas les processus commerciaux et ne donnons généralement pas de recommandations pour l'amélioration des processus commerciaux, du moins au sein de la BIA. Nous décrivons les processus métier de manière si détaillée qui nous permet de justifier la méthodologie de calcul des pertes et d'évaluer les pertes selon plusieurs critères. Pour une description graphique, la notation EPC, ARIS et MS Visio ont été utilisées comme outils.

Seuils

Afin de déterminer le temps objectif de récupération cible, il est nécessaire à terre de se mettre d'accord sur les critères selon lesquels nous évaluerons les dégâts, et sur leurs valeurs seuils. Si ces seuils sont dépassés, nous considérerons que les dommages sont critiques et l'intervalle de temps auquel la valeur seuil est atteinte deviendra le temps de récupération cible. Deux options ont été suggérées:

• déterminer l'OTR selon un critère - les pertes financières;
• déterminer l'OTR en fonction de trois critères - perte financière, perte de réputation, perte de contrôlabilité des processus opérationnels.

La première option avec un critère semble préférable, car toute perte peut être conditionnellement convertie en argent - l'essentiel est de s'entendre sur une formule de recalcul. Mais, comme le montre la pratique, personne ne raconte spécifiquement les pertes de réputation en pertes financières, et l'approbation d'une telle formule peut prendre un temps indéfini. Il a été décidé de prendre en compte le temps de récupération pour les deux options, et au stade de la présentation des résultats, le client déterminera lui-même celle qui reflète la réalité de manière plus objective.



Pour l'avenir, je dirai qu'en utilisant la première option avec un critère, il s'est avéré que l'OTR dans le processus de «tarification», par exemple, peut atteindre 10 jours. Lors du calcul de la deuxième option, le RTO n'a pas dépassé 24 heures. En tout état de cause, la décision de gestion - quelles pertes prendre en considération et lesquelles ne pas - revient au client.

Les risques

Avec le client, nous avons déterminé la liste des risques opérationnels. Autrement dit, ceux qui affectent l'informatique, et ceux qui affectent à leur tour les processus métier qui ... eh bien, vous comprenez. Cette étape est importante car une urgence n'est pas considérée comme un cheval sphérique dans le vide, ils disent ce qui arrivera à la Patrie et à nous si nous la perdons. Les risques ont été répartis entre global et local. Pour chacun d'eux, un scénario de développement et un impact sur les processus de l'entreprise ont été déterminés en tenant compte des résultats de l'entretien. Évidemment, le même système informatique en cas de défaillance peut affecter plusieurs processus métier, mais nous étions terriblement inquiets à propos de seulement deux processus dans le projet. Ensuite, nous avons évalué les réclamations conformément aux paramètres suivants:

• propagation de la menace;
• la capacité d'alerter;
• durée d'exposition;
• probabilité d'occurrence;
• dommages estimés.

En conséquence, ils ont dessiné une carte thermique où chaque application a reçu une évaluation de la chaleur de l'entreprise pourrait être brûlée pendant son temps d'arrêt. Par exemple, en 4 heures d'indisponibilité pour les modules SAP individuels, l'entreprise ne reçoit toujours pas de problèmes graves, mais même les premières heures d'indisponibilité du logiciel de caisse enregistreuse sur la carte thermique sont marquées en rouge vif.

Il est nécessaire de préciser que l'évaluation des risques et le classement ultérieur sont formés avec l'aide d'un groupe d'experts et sont nécessaires pour déterminer les situations les plus critiques pour le client.

Risque éventuel et scénario. Incendie dans le centre de données: la salle des serveurs est complètement grillée, le module SAP impliqué dans le processus de «Réapprovisionnement» n'est pas disponible. Cela signifie que chaque jour, jusqu'à la restauration du module SAP brûlé, la gamme de produits est réduite. Tout d'abord, cela concerne les produits périssables, deuxièmement, les produits qui sont en forte demande (par exemple, les céréales et le pain), et troisièmement, les produits chimiques ménagers. Évidemment, cette situation entraînera une baisse des revenus des magasins. Mais ce n'est pas tout à fait évident: l'acheteur qui est venu chercher de la bière et des cigarettes, en l'absence d'une des marchandises, ne peut probablement rien acheter. De même pour le processus de tarification. Si un client conditionnel qui a découvert les remises le mercredi à 12 h 00 arrive au magasin dans l'après-midi et que le processus de «tarification» ne fonctionne pas (c'est-à-dire les prix sans remises), alors il:

A) n'achète rien (= perte financière);
B) accusera le magasin de fraude (= perte de réputation)
B) se plaint au régulateur (= pénalité pour publicité déloyale).

Technique d'estimation des pertes

Comme vous l'avez probablement compris à partir de ce qui précède, afin de calculer même les pertes financières, il est nécessaire de développer une méthodologie et des formules pour les calculer, qui prennent en compte les remises, les promotions, l'heure de la journée, la haute saison (par exemple, l'excitation à la fin de décembre). La méthodologie devrait contenir une partie descriptive (d'où elle vient et pourquoi elle est multipliée par les poids), ainsi que des tableaux et des graphiques pour la clarté de la perception.

La technique décrit également:

• Comment le temps de récupération est déterminé pour un processus métier
• Comment le temps de récupération d'un processus métier se traduit par RTO / RPO pour les systèmes informatiques
• classes de criticité et classes de récupération - pourquoi est-ce nécessaire.

Nous allons plus loin.

Calcul RTO

Une fois que tous les entretiens ont été menés, les processus opérationnels sont décrits, les risques sont évalués, une méthodologie est définie et approuvée et les pertes sont calculées. Étant donné que les activités de Pyaterochka, Carousel et Crossroads diffèrent au moins en termes d'échelle - pour chaque réseau, nous avons développé nos propres tableaux, nos propres calendriers et calculs de pertes.

Pour l'ensemble du processus métier, le temps de récupération est déterminé (voir la méthodologie), lorsque les pertes dépassent la valeur seuil (voir les seuils). Ce temps de récupération est attribué aux systèmes informatiques impliqués dans le processus métier (voir matrice d'interview et de dépendance). Il semblerait que les paramètres de continuité soient définis - le projet est achevé (voir limites et cadre). Mais il ne suffit pas de dire "le processus doit être restauré en 12 heures". Il est important de déterminer comment cela fonctionne maintenant. Combien d'heures un système informatique peut-il être réanimé aujourd'hui? Et si le temps de récupération actuel est plus long ou significativement plus long que l'objectif? Pour ceux qui gardent toujours raison et concentration, bienvenue au GAP!

Analyse des BPA et plan d'action

À la suite des étapes précédentes, nous avons déterminé l'état des processus et des systèmes TO TO, c'est-à-dire qu'il devrait être idéalement. Au stade actuel, nous déterminons l'état de «TEL QUEL». Dans le même temps, nous touchons dans une moindre mesure les processus métier et nous nous concentrons sur la composante informatique. Pour le client, nous avons évalué ses solutions actuelles en termes de récupération après une urgence. De plus, dans ce cas, il n'était pas nécessaire d'effectuer une véritable récupération avec une minuterie. Il suffisait d'entrer dans les détails et de tester le bureau pour comprendre que le RTO cible était inaccessible.

Après cela, nous avons développé un certain nombre de recommandations, à la fois d'ordre général (pour assurer la continuité informatique), et directement liées aux systèmes informatiques et à leur architecture. Ce sont des esquisses de solutions techniques et une estimation approximative du coût de leur mise en œuvre. En fait, il y a maintenant une base pour une décision. D'un côté de l'échelle - les pertes et de l'autre - le coût des mesures.
Si certains systèmes informatiques ne subissent pas d'analyse GAP, ou plutôt, leur temps de récupération est plus long que l'objectif, nous créons un programme de projets pour atteindre l'état cible ou, si vous le souhaitez, une feuille de route avec justification de la séquence des projets et une évaluation intermédiaire de l'amélioration de la durabilité de l'organisation.

De plus, pour le client, nous avons développé du matériel et des modèles méthodologiques pour la formation de plans de continuité et de plans de reprise après sinistre.

La stratégie

Attends, attends, j'ai presque fini.

Sur la base des résultats du BIA, nous avons développé une stratégie de continuité informatique. La stratégie de continuité décrit deux points clés.

1. Quels risques informatiques affectant les activités de l'entreprise sont pris en compte, et lesquels ne le sont pas (c'est-à-dire ce dont nous avons peur et déciderons dans le cadre de la continuité, et ce dont nous n'avons pas peur, et pour cela nous avons la gestion des incidents).
2. Quelles solutions organisationnelles, architecturales, infrastructurelles et autres défendrons-nous contre les menaces?

Par stratégie, nous tuons deux oiseaux avec une pierre. Premièrement, tout le monde dans l'entreprise comprend comment et contre quoi nous nous protégerons. Deuxièmement, pour les non-spécialistes de l'informatique (par exemple, les financiers), le processus de budgétisation des solutions de reprise après sinistre informatique semble plus transparent. Et aussi pathétique que cela puisse paraître, la stratégie aide à prendre les bonnes décisions managériales (il y a toujours la possibilité de ne pas dépenser d'argent pour la DR, et maintenant nous savons exactement comment cela affectera l'entreprise en cas d'accident).

Et ensuite? Poursuite de la mise en œuvre de la stratégie de continuité et de l'analyse de l'impact commercial pour d'autres processus métier et systèmes informatiques. Développement de plans de continuité, tests périodiques de ces plans, mais c'est une tout autre histoire.

Igor Tyukachev, consultant, Jet Infosystems Design Center