Aunque muchas normas de continuidad del negocio hacen hincapié en la importancia de seguir las acciones correctivas para abordar los problemas identificados, la recientemente publicada ISO 22301 (y anteriormente BS 25999-2) también requiere la realización de un análisis de la causa raíz, es decir, que no sólo se analice un problema, sino también su causa y cómo se puede prevenir en el futuro. El análisis de la causa raíz (ACR) es un enfoque que trata de prevenir de forma proactiva la repetición del mismo acontecimiento adverso o fallo de los sistemas, rastreando las relaciones causales de un fallo hasta su origen más probable, para después poner en marcha medidas que mitiguen las causas subyacentes y, en última instancia, ayuden a prevenir la repetición del acontecimiento adverso en el futuro. Si bien es común en disciplinas que se ocupan de la precisión extrema y la protección de la vida (por ejemplo, la calidad y la salud y seguridad ambiental), no hay razón para que la disciplina de la continuidad del negocio no pueda beneficiarse de un enfoque similar, en particular para los profesionales que buscan implementar plenamente la norma ISO 22301. En este artículo se explica el análisis de la causa raíz y se identifica cómo las organizaciones pueden beneficiarse de la aplicación del concepto en el contexto de la continuidad del negocio.

El concepto de análisis de la causa raíz fue desarrollado originalmente por Sakichi Toyoda (el fundador de Toyota Motor Corporation), quien desarrolló un proceso llamado "Los cinco porqués" para entender las posibles causas de los problemas más allá de lo que era inmediatamente obvio. El análisis de la causa raíz se formalizó a medida que se integró en varios campos diferentes como impulsor del rendimiento, como la seguridad, la calidad, las operaciones y la seguridad de la información. En cada uno de estos ámbitos, no bastaba con responder a un problema de forma reactiva, sino que había que prevenir los problemas futuros, y el análisis de las causas profundas era el camino que permitía mejorar el rendimiento y mitigar los riesgos eliminando las verdaderas causas, en lugar de los meros síntomas. La incorporación del análisis de las causas profundas a las acciones correctivas relacionadas con la continuidad del negocio podría minimizar la probabilidad de futuros incidentes perjudiciales y reducir los tiempos de recuperación.

A veces, realizar el ACR es tan fácil como aplicar los cinco porqués, preguntando repetidamente "por qué" ocurrió algo hasta que parece que se ha llegado a la causa básica de cómo se produjo el fallo. La clave es una aplicación disciplinada de las preguntas de sondeo. Por ejemplo, analizar la causa raíz de por qué una organización no cumplió un objetivo de tiempo de recuperación de 24 horas para su entorno SAP durante una prueba reciente podría ser algo así:

  1. Problema: El personal de recuperación de TI no logró recuperar el sistema SAP de la organización dentro de su objetivo de tiempo de recuperación de 24 horas durante la prueba de DR de TI de la semana pasada .... ¿Por qué?
  2. El personal de recuperación de TI dijo que los LUN de la SAN no estaban mapeados correctamente, lo que retrasó drásticamente el inicio de la restauración desde el disco ... ¿Por qué?
  3. El personal del proveedor responsable de preparar el equipo no ejecutó la configuración específicamente según las expectativas documentadas... ¿Por qué?
  4. El personal del proveedor indicó que las instrucciones parecían contradictorias y no proporcionaban el nivel de detalle necesario para ejecutar los pasos, por lo que utilizaron una configuración básica por defecto... ¿Por qué?
  5. Tras el análisis, la documentación omitió varios pasos cruciales necesarios para permitir que se produzca este complejo mapeo de LUN... ¿Por qué no se encontró esto antes?
  6. Al realizar las pruebas anteriores, el personal no aprovechó plenamente la documentación del plan existente... ¿Qué ha cambiado esta vez?
  7. La persona responsable de documentar el plan y de realizar las pruebas anteriores no estaba disponible, y el personal que realizó las pruebas en esta ocasión indicó que no había recibido la formación adecuada sobre el uso de los planes, ni se le había instruido sobre cómo plantear problemas relacionados con los procesos de recuperación.

Aunque pueda parecer que se ha llegado a la raíz del problema, el simple hecho de arreglar la documentación no garantiza que la documentación futura sea precisa. Profundizando en el tema, el anterior experto en materia de TI responsable de documentar los procedimientos a menudo realiza pruebas in situ sin utilizar la documentación, ya que tiene una amplia experiencia en este campo y consideraba que podía realizar las tareas más rápidamente recuperando basándose en la experiencia en lugar de en los procedimientos documentados. El análisis de la cuestión reveló que el personal más nuevo asignado a las tareas de recuperación tenía mucha menos experiencia y no había recibido todavía un nivel adecuado de formación en materia de sensibilización. En relación con este punto, el director de TI admitió que nunca exigía a otro personal que validara la documentación, ya que las pruebas restan tiempo al soporte de producción y aprovechar a los "expertos" en cada fase disminuye el tiempo de las pruebas.

Parte de la solución a esto podría ser implementar la expectativa de que todos los procedimientos documentados sean validados al menos anualmente por otro individuo de TI dentro de un área de experiencia diferente. Una segunda parte de la solución podría ser realizar una formación adecuada por adelantado (que haga hincapié en la familiaridad con los planes y el conocimiento de los procedimientos de escalada) tanto para los individuos internos alternativos como para cualquier recurso del proveedor responsable de la ejecución del plan. En conjunto, estos esfuerzos podrían ayudar a garantizar que toda la documentación de RD de TI pueda ser utilizada eficazmente por los recursos internos y externos durante las pruebas.

Aunque es sencillo en teoría, identificar la causa raíz real y averiguar cuándo se ha ido lo suficientemente lejos puede ser complejo en la práctica. Para ayudar a entender las causas profundas primarias, hay que plantear repetidamente variantes de "por qué" (y algunas otras preguntas de sondeo), y luego buscar la respuesta que parece más probable que haya influido en el problema. Aunque el análisis de las causas profundas no sea una "ciencia exacta", cuanto más se profundice en la búsqueda de las causas, más probabilidades habrá de encontrar problemas que resolver. En la mayoría de los casos, el mayor problema al que se enfrentan las organizaciones es no explorar los problemas en primer lugar. Nuestro ejemplo demostró este problema en la recuperación de SAP. Sin embargo, es probable que este problema (los atajos) exista en otras áreas, y abordar la causa raíz podría mejorar el rendimiento y la recuperabilidad en otros lugares.

Dentro de la continuidad del negocio, hay varias áreas que comúnmente pueden ser identificadas como causas raíz de los problemas de mitigación de riesgos, respuesta y rendimiento de recuperación, aunque de nuevo, requiere rastrear los problemas más allá de lo que la mayoría de los profesionales deciden explorar. Para integrar adecuadamente el análisis de la causa raíz en las actividades de mejora continua, cada problema debe estar adecuadamente documentado, incluyendo el origen del problema, una descripción detallada, una fecha de identificación, y también debe tener un campo para capturar el análisis de la causa raíz. En lugar de que un solo individuo intente identificar la causa raíz, el personal de continuidad del negocio debe organizar y facilitar discusiones en las que participen expertos en la materia a los que se les puedan asignar los problemas o que puedan proporcionar una visión sobre un problema, y luego el grupo debe tratar de rastrear el problema hasta su origen de forma conjunta.

Dentro de la continuidad de la empresa, existen numerosas causas raíz que pueden dar lugar a diversos problemas o complicaciones. En la siguiente tabla se indican algunos ejemplos, junto con las probables causas raíz, aunque no es ni mucho menos una lista completa. Además, es importante tener en cuenta que, al igual que ocurre con las raíces que alimentan el crecimiento de un árbol, puede haber más de una causa raíz que afecte a un sistema y dé lugar a un problema, por lo que es importante rastrear todas las posibles vías de origen de un problema, en lugar de limitarse a buscar una causa directa, para identificar todos los factores que influyen.

Una vez más, el análisis de la causa raíz no se limita a resolver un caso de un problema, sino que también busca oportunidades para prevenir futuras ocurrencias de un problema. Una vez que se ha identificado el origen de un problema, es importante evaluar todas las áreas de la empresa para identificar otras áreas de riesgo y asegurarse de que se aplican las medidas de mitigación de riesgos adecuadas. Una solución en un área puede no ser necesariamente aplicable a todas las demás áreas de una organización, pero incluso si no lo es, el acto de identificar otras áreas de riesgo similares aumenta la concienciación y permite a la organización desarrollar soluciones adicionales que tienen sentido y abordar estos riesgos antes de que den lugar a futuros problemas o tiempos de inactividad.

A medida que los sistemas de gestión de la continuidad de las actividades sigan madurando, el análisis de las causas fundamentales se convertirá en una poderosa herramienta para los profesionales de la continuidad del negocio para examinar en profundidad la causa de los problemas y ofrecer la oportunidad de corregirlos antes de que se repitan.