Bien que de nombreuses normes de continuité des opérations soulignent l'importance du suivi des actions correctives pour résoudre les problèmes identifiés, la norme ISO 22301 (et précédemment BS 25999-2), récemment publiée, exige également la réalisation d'une analyse des causes profondes, c'est-à-dire l'examen non seulement d'un problème, mais aussi de sa cause et de la manière dont il peut être évité à l'avenir. L'analyse des causes profondes (RCA) est une approche qui vise à prévenir de manière proactive la répétition d'un même événement indésirable ou d'une même défaillance des systèmes en remontant les relations de cause à effet d'une défaillance jusqu'à son origine la plus probable, puis en mettant en place des mesures pour atténuer les causes sous-jacentes afin d'éviter que l'événement indésirable ne se reproduise à l'avenir. Bien qu'elle soit courante dans les disciplines qui traitent de la précision extrême et de la protection de la vie (par exemple, la qualité et la santé et la sécurité environnementales), il n'y a aucune raison pour que la discipline de la continuité des affaires ne puisse pas bénéficier d'une approche similaire, en particulier pour les praticiens qui cherchent à mettre pleinement en œuvre l'ISO 22301. Cet article explique l'analyse des causes profondes et identifie comment les organisations peuvent bénéficier de la mise en œuvre de ce concept dans un contexte de continuité des opérations.

Le concept d'analyse des causes profondes a été développé à l'origine par Sakichi Toyoda (le fondateur de Toyota Motor Corporation), qui a mis au point un processus appelé "Five Whys" pour comprendre les causes potentielles des problèmes au-delà de ce qui était immédiatement évident. L'analyse des causes profondes est devenue plus formelle lorsqu'elle a été intégrée dans plusieurs domaines différents en tant que moteur de performance, tels que la sécurité, la qualité, les opérations et la sécurité de l'information. Dans chacun de ces domaines, il ne suffisait pas de réagir à un problème - il fallait prévenir les problèmes futurs, et l'analyse des causes profondes était la voie à suivre pour améliorer les performances et atténuer les risques en éliminant les véritables causes, plutôt que les simples symptômes. L'intégration de l'analyse des causes profondes dans les mesures correctives liées à la continuité des activités pourrait très bien minimiser la probabilité de futurs incidents perturbateurs et réduire les délais de récupération.

Parfois, effectuer une ACR est aussi simple que de mettre en œuvre les cinq pourquoi, en demandant de manière répétée "pourquoi" quelque chose s'est produit jusqu'à ce qu'il semble que vous ayez atteint la cause fondamentale de l'échec. La clé est une application disciplinée des questions d'approfondissement. Par exemple, l'analyse de la cause fondamentale pour laquelle une organisation n'a pas réussi à atteindre l'objectif de temps de récupération de 24 heures pour son environnement SAP lors d'un récent test pourrait ressembler à ceci :

  1. Problème : Le personnel chargé de la récupération informatique n'a pas réussi à récupérer le système SAP de l'entreprise dans le délai de récupération fixé à 24 heures lors du test de récupération informatique de la semaine dernière ..... Pourquoi ?
  2. Le personnel chargé de la récupération informatique a déclaré que les LUN du SAN n'étaient pas mappés correctement, ce qui retardait considérablement le début de la restauration à partir du disque ... Pourquoi ?
  3. Le personnel du fournisseur responsable de la préparation de l'équipement n'a pas exécuté l'installation conformément aux attentes documentées... Pourquoi ?
  4. Le personnel du fournisseur a indiqué que les instructions semblaient contradictoires et ne fournissaient pas le niveau de détail nécessaire pour exécuter les étapes, de sorte qu'il a utilisé une configuration de base par défaut ... Pourquoi ?
  5. Après analyse, la documentation a omis plusieurs étapes cruciales nécessaires pour permettre ce mappage complexe de LUN ... Pourquoi cela n'a-t-il pas été découvert plus tôt ?
  6. Lors des tests précédents, le personnel n'a pas pleinement exploité la documentation du plan existant ... Qu'est-ce qui a changé cette fois-ci ?
  7. La personne chargée de documenter le plan et d'effectuer les tests antérieurs n'était pas disponible, et le personnel qui a effectué les tests cette fois-ci a indiqué qu'il n'avait pas été correctement formé à l'utilisation des plans, et qu'il n'avait pas non plus reçu d'instructions sur la manière de transmettre les problèmes concernant les processus de récupération.

Bien qu'il puisse sembler que la cause première ait été atteinte, le simple fait de corriger la documentation ne garantit pas que la documentation future sera exacte. En approfondissant la question, l'ancien expert en informatique responsable de la documentation des procédures effectue souvent des tests sur site sans utiliser de documentation, car il a une grande expérience dans ce domaine et a estimé qu'il pouvait effectuer des tâches plus rapidement en récupérant en se basant sur son expérience plutôt que sur des procédures documentées. Une étude plus approfondie de la question a révélé que le personnel plus récent affecté aux tâches de récupération était beaucoup moins expérimenté et n'avait pas encore reçu un niveau approprié de formation de sensibilisation. À ce sujet, le directeur informatique a admis qu'il ne demandait jamais à d'autres membres du personnel de valider la documentation, car les tests prennent du temps sur le support de production et le fait de faire appel à des "experts" dans chaque phase réduit le temps de test.

Une partie de la solution pourrait consister à exiger que toutes les procédures documentées soient validées au moins une fois par an par un autre informaticien dans un domaine d'expertise différent. Une deuxième partie de la solution pourrait consister à dispenser une formation appropriée dès le départ (qui met l'accent sur la familiarisation avec les plans et la connaissance des procédures d'escalade) à la fois aux personnes internes suppléantes et aux ressources du fournisseur responsables de l'exécution du plan. Ensemble, ces efforts pourraient contribuer à garantir que toute la documentation relative au plan de secours informatique peut être utilisée efficacement par les ressources internes et externes pendant les tests.

Bien que simple en théorie, l'identification de la cause première réelle et la détermination du moment où vous êtes allé suffisamment loin peuvent être complexes en pratique. Pour mieux comprendre les causes premières, vous devez poser des variantes de "pourquoi" (et quelques autres questions d'approfondissement), puis rechercher la réponse qui semble la plus susceptible d'avoir influencé le problème. Bien que l'analyse des causes profondes ne soit pas une "science exacte", plus vous cherchez les causes, plus vous avez de chances de trouver des problèmes à résoudre. Dans la plupart des cas, le plus gros problème auquel sont confrontées les organisations est de ne pas explorer les problèmes en premier lieu ! Notre exemple a démontré ce problème dans la récupération de SAP. Cependant, il est probable que ce problème (les raccourcis) existe dans d'autres domaines, et que le fait de s'attaquer à la cause première pourrait améliorer les performances et la capacité de récupération ailleurs.

Dans le cadre de la continuité des opérations, plusieurs domaines peuvent être identifiés comme des causes profondes des problèmes de performance en matière d'atténuation des risques, de réponse et de récupération, même si, là encore, il faut remonter plus loin que ce que la plupart des professionnels choisissent d'explorer. Pour intégrer correctement l'analyse des causes profondes dans les activités d'amélioration continue, chaque problème doit être correctement documenté, y compris la source du problème, une description détaillée, une date d'identification, et il doit également y avoir un champ pour saisir l'analyse des causes profondes. Plutôt que de laisser une seule personne tenter d'identifier la cause profonde, le personnel chargé de la continuité des opérations devrait organiser et animer des discussions auxquelles participent des experts en la matière à qui les problèmes peuvent être attribués ou qui peuvent apporter un éclairage sur un problème, puis le groupe devrait chercher à remonter ensemble à l'origine du problème.

Dans le cadre de la continuité des activités, il existe de nombreuses causes profondes qui peuvent conduire à divers problèmes ou complications. Le tableau suivant en donne quelques exemples, ainsi que les causes profondes probables, bien que cette liste soit loin d'être exhaustive. Il est également important de noter que, tout comme les racines d'un arbre qui alimentent sa croissance, il peut y avoir plus d'une cause première qui affecte un système et entraîne un problème. Il est donc important de remonter toutes les voies potentielles de l'origine d'un problème, plutôt que de rechercher une seule cause directe, afin d'identifier tous les facteurs d'influence.

Encore une fois, l'analyse des causes profondes ne consiste pas seulement à résoudre un problème ponctuel, mais aussi à rechercher les possibilités de prévenir les occurrences futures d'un problème. Une fois l'origine d'un problème identifiée, il est important d'évaluer tous les secteurs de l'entreprise afin d'identifier les autres secteurs à risque et de s'assurer que des mesures d'atténuation des risques appropriées sont mises en place. Une solution dans un domaine n'est pas nécessairement applicable à tous les autres domaines de l'organisation, mais même si ce n'est pas le cas, le fait d'identifier d'autres domaines à risque similaires sensibilise et permet à l'organisation de développer des solutions supplémentaires qui ont du sens et traitent ces risques avant qu'ils n'entraînent de futurs problèmes ou temps d'arrêt.

Alors que les systèmes de gestion de la continuité des activités continuent de mûrir, l'analyse des causes profondes deviendra un outil puissant pour les professionnels de la continuité des affaires d'examiner en profondeur la cause des problèmes et de donner l'occasion de les corriger avant qu'ils ne se reproduisent.