Aunque muchas normas de continuidad de negocio hacen hincapié en la importancia de realizar un seguimiento de las acciones correctivas para abordar los problemas identificados, la recientemente publicada ISO 22301 (y anteriormente BS 25999-2) también exige realizar un análisis de la causa raíz, es decir, examinar no sólo un problema, sino su causa y cómo puede evitarse en el futuro. El análisis de la causa raíz (ACR) es un enfoque que trata de evitar de forma proactiva que se repita el mismo acontecimiento adverso o fallo de los sistemas, rastreando las relaciones causales de un fallo hasta su origen de impacto más probable y, a continuación, poniendo en marcha medidas para mitigar las causas subyacentes para, en última instancia, ayudar a evitar que se repita el acontecimiento adverso en el futuro. Aunque es habitual 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 medioambientales), no hay motivo para que la disciplina de la continuidad de negocio no pueda beneficiarse de un enfoque similar, sobre todo para los profesionales que pretenden implantar plenamente la ISO 22301. Este artículo explica el análisis de causa raíz e identifica cómo pueden beneficiarse las organizaciones de la aplicación del concepto en un contexto de continuidad de negocio.
El concepto de análisis de la causa raíz fue desarrollado originalmente por Sakichi Toyoda (fundador de Toyota Motor Corporation), que desarrolló un proceso denominado «Los cinco porqués» para comprender las causas potenciales de los problemas más allá de lo que era inmediatamente obvio. El análisis de la causa raíz se fue formalizando a medida que se integraba en distintos campos como impulsor del rendimiento, como la seguridad, la calidad, las operaciones y la seguridad de la información. En cada una de estas áreas, no bastaba con responder de forma reactiva a un problema: había que prevenir futuros problemas, y el análisis de la causa raíz era el camino que permitía mejorar el rendimiento y mitigar los riesgos eliminando las verdaderas causas, en lugar de sólo los síntomas. Incorporar el análisis de las causas profundas a las acciones correctivas relacionadas con la continuidad de la empresa podría muy bien minimizar la probabilidad de futuros incidentes perjudiciales y reducir los tiempos de recuperación.
A veces, realizar un ACR es tan fácil como aplicar los cinco porqués, preguntando repetidamente «por qué» ocurrió algo hasta que parezca que has llegado a la causa básica de cómo se produjo el fallo. La clave es la aplicación disciplinada de 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 parecido a esto:
- Problema: El personal de recuperación de TI no consiguió recuperar el sistema SAP de la organización dentro de su objetivo de tiempo de recuperación de 24 horas durante la prueba de RD de TI de la semana pasada …. ¿Por qué?
- El personal informático de recuperación dijo que los LUN de la SAN no se mapeaban correctamente, lo que retrasaba drásticamente el inicio de la restauración desde el disco… ¿Por qué?
- El personal del proveedor responsable de preparar el equipo no ejecutó la preparación específicamente según las expectativas documentadas … ¿Por qué?
- 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é?
- Tras analizarla, la documentación omitió varios pasos cruciales necesarios para permitir que se produjera esta compleja asignación de LUN… ¿Por qué no se descubrió esto antes?
- Al realizar pruebas anteriores, el personal no aprovechó plenamente la documentación existente del plan … ¿Qué ha cambiado esta vez?
- La persona responsable de documentar el plan y de realizar las pruebas anteriores no estaba disponible, y el personal que realizó las pruebas esta vez indicó que no se le había formado adecuadamente sobre el uso de los planes, ni se le había instruido sobre cómo escalar los problemas relativos a los procesos de recuperación.
Aunque pueda parecer que se ha llegado a la causa raíz, arreglar simplemente la documentación no garantiza que la documentación futura sea precisa. Profundizando en el tema, el anterior experto en TI responsable de documentar los procedimientos suele realizar 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 de recuperación más rápidamente basándose en la experiencia, en lugar de en los procedimientos documentados. Explorando la cuestión más a fondo se descubrió que el personal más nuevo asignado a las tareas de recuperación tenía mucha menos experiencia y aún no había recibido un nivel adecuado de formación de concienciació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 consistir en implantar la expectativa de que todos los procedimientos documentados sean validados al menos una vez al año por otra persona de TI dentro de un área de especialización diferente. Una segunda parte de la solución podría consistir en impartir una formación adecuada por adelantado (que haga hincapié en la familiaridad con los planes y el conocimiento de los procedimientos de escalado) tanto a las personas internas suplentes como a los recursos de los proveedores responsables de la ejecución del plan. Juntos, 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 sencillo en teoría, identificar la causa raíz real y averiguar cuándo has ido lo suficientemente lejos puede ser complejo en la práctica. Para ayudar a comprender las causas profundas primarias, debes formular repetidamente variantes del «por qué» (y algunas otras preguntas de sondeo), y luego buscar la respuesta que parezca 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 profundamente busques las causas, más probabilidades tendrás 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 de negocio, hay varias áreas que pueden identificarse habitualmente 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 atrás 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 documentarse adecuadamente, 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 una sola persona intente identificar la causa raíz, el personal de continuidad de negocio debe organizar y facilitar debates en los que participen expertos en la materia a los que se puedan asignar los problemas o que puedan aportar su visión sobre un problema, y luego el grupo debe intentar rastrear el problema hasta su origen de forma conjunta.
Dentro de la continuidad empresarial, hay numerosas causas raíz que pueden dar lugar a diversos problemas o complicaciones. En la tabla siguiente se señalan algunos ejemplos, junto con las causas raíz probables, aunque dista mucho de ser 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 perseguir sólo una causa directa, para identificar todos los factores que influyen.
De nuevo, el análisis de la causa raíz no consiste sólo en resolver un caso de un problema, sino también en buscar oportunidades para evitar que se produzca en el futuro. Una vez 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 adecuadas para mitigarlo. 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 tengan sentido y aborden 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 del negocio sigan madurando, el análisis de la causa raíz se convertirá en una poderosa herramienta para que los profesionales de la continuidad del negocio examinen en profundidad la causa de los problemas y ofrezcan la oportunidad de corregirlos antes de que vuelvan a ocurrir.
