En este artículo se hacen algunas reflexiones sobre la fase de estrategia dentro del ciclo de vida de la continuidad de negocio.
Es más que habitual que los clientes, y no pocos consultores, a la hora de mejorar la resiliencia de las organizaciones, propongan un “Plan de Continuidad de Negocio”. En realidad, se debería hablar de implantar una “Gestión de la Continuidad de Negocio”, ya que de lo que se trata es de poner en marcha una serie de procesos, actividades y capacidades interrelacionadas. De aquí en adelante usaremos las siglas BCM para referirnos a dicha Gestión.
Sí, hay que reconocer que uno de los posibles resultados del BCM puede ser la elaboración de uno o varios planes que definan cómo actuar ante un evento inesperado y recuperar una funcionalidad de negocio o una capacidad TIC. No obstante, dichos planes no son, por supuesto, los únicos “outputs” del BCM, aunque sí es cierto que son los más visibles y, por desgracia, los auditores suelen limitarse a verificar la existencia de los mismos cuando evalúan las capacidades de recuperación de la organización (el clásico de poner la marca de “cumple” en la casilla de verificación).
Como se muestra en el diagrama anterior (inspirado en las normas ISO 22301/22313 y sus padrastros las BS25999-1/2), antes de llegar a la fase “Implantación”, que es donde se escriben los planes, hay que realizar las tareas asociadas con “Comprender la organización” y “Definir la Estrategia”.
La primera de estas fases es relativamente conocida, e incluye tareas como los BIA (Business Impact Analysis, o análisis de impacto en los negocios), análisis de riesgos, o determinar los parámetros RTO/RPO. Otra cosa es que se hagan apropiadamente, aunque en este mismo blog se pueden encontrar artículos sobre la forma adecuada de medir los impactos.
En cualquier caso, supongamos que disponemos de unos BIA correctamente ejecutados, que nos dicen qué le ocurre a lo largo del tiempo a mi organización en caso de que las distintas actividades relevantes estén paralizadas. En base a ello se ha fijado un objetivo de tiempo de recuperación (RTO) para cada una y se ha determinado qué niveles de servicio degradado se puede seguir prestando y qué se necesitaría en términos de TIC, personas, proveedores o instalaciones para prestar dicho servicio mínimo.
La tentación, llegados a este punto, es empezar sin demora a escribir planes, los cuales deberían ser concisos, prácticos, con toda la información relevante para gestionar un incidente y sin ningún dato superfluo, orientados a la acción, etc.
No obstante, habría que pararse a cuestionarse cuál debería ser el contenido de dichos planes y cómo enlazaría con la información proveniente de los BIA.
Pongamos un caso sencillo: tengo una empresa con sedes en Madrid y Barcelona, y he identificado, entre otros, un proceso de negocio que habitualmente requiere de la participación de 60 personas de la oficina de Madrid. El RTO de dicho proceso es 24 horas y el nivel mínimo de servicio requiere la participación de 15 de dichas 60 personas atendiendo al teléfono para responder a las llamadas más importantes. Por otra parte, mi BIA también me ha identificado cuáles de los servicios TIC son esenciales para mantener el funcionamiento de dicho proceso. Por último, también sé que el proceso puede estar en modo degradado (con 15 personas, en vez de las 60 habituales) durante un máximo de 5 jornadas laborables.
¿Cómo se supone que voy a escribir un plan para recuperar ese proceso de negocio? ¿Sé acaso desde dónde o cómo van a trabajar esas 15 personas? ¿Y las aplicaciones?, ¿van a estar restauradas en 24h, si ahora mismo no cuento con un sistema de respaldo? Si se ha destruido el edificio, o no puedo acceder a él durante un periodo superior a 5 días, ¿qué solución voy a plasmar en el plan?
Llegados a este punto, parece claro que falta un paso entre el BIA y el Plan, y este paso consiste en definir CÓMO pienso recuperar el proceso.
Un plan puede reflejar aquellos pasos que se deben seguir para empezar a utilizar mis métodos alternativos, pero está claro que antes habrá que haber decidido cuáles son esos métodos alternativos y eso no está en ninguna parte del BIA.
Como se indica en la Guía de Buenas Prácticas del BCI, la fase de estrategia “identifica y selecciona tácticas y estrategias adecuadas para determinar cómo conseguir la continuidad y la recuperación a partir de una disrupción”. Dicho en lenguaje claro: ¿cómo consigo seguir trabajando en modo de contingencia? y ¿cómo podría volver a la normalidad (recuperación o restauración)?
Una primera duda a la hora de definir estrategias suele surgir de los más novatos en este campo, y suele expresarse con afirmaciones-quejas del tipo: ¡Es que no puedo prever todas las posibles situaciones! Mi respuesta ante dicha afirmación es decirles que tienen toda la razón: es imposible tener una estrategia para cada posible amenaza (fuego, hacking, huelga, malware, gripe aviar, volcán islandés paralizando el tráfico aéreo, sabotaje, apocalipsis zombi o guerra termonuclear global). La lista de amenazas o causas de interrupción es infinita y, aunque contemple todas las que se me ocurran, la ley de Murphy dicta que la que finalmente acontezca será una en la que nadie había pensado antes.
Entonces, ¿cómo puedo en realidad formular estrategias, si las causas de interrupción pueden ser innumerables? Aparentemente, estamos bloqueados.
¡No desesperemos!, hace algún tiempo leí un párrafo en un librito sobre la antigua BS25999 (The route map to BCM), que debería estar impreso en mármol en cualquier academia sobre continuidad de negocio, y que reza más o menos como sigue: Se recomienda que se consideren cuatro escenarios a la hora de definir estrategias. La causa que subyace al escenario no debería tenerse en cuenta. En cambio, se debe considerar el efecto que tendrían.
¿Y qué cuatro escenarios indica esa publicación?, pues los siguientes efectos o impactos:
- Imposibilidad de acceso a instalaciones
- Falta de personal
- Fallo de la tecnología
- Fallo de un proveedor clave
Si lo pensamos bien, pase lo que nos pase las consecuencias de la materialización de cualquier amenaza se traducirá en uno o varios de los escenarios anteriores. Por lo tanto, hemos conseguido reducir nuestro problema inabarcable a otro ya manejable.
Volviendo a nuestro ejemplo, ¿qué estrategia seguiría en caso de que mi oficina en Madrid no estuviera disponible, cuando resulta que tengo que restaurar el proceso en 24h?
Eso es lo que veremos en la segunda parte de esta serie, en unos días.
