En una charla a la que asistí hace unos meses sobre continuidad de negocio, uno de los ponentes clasificaba los métodos que existían a la hora de afrontar la materialización de un escenario de siniestro en los siguientes:
- Método israelí: atajar el problema como sea (“enemigo muerto, trabajo bien hecho”).
- Método americano: desplazar a un técnico al campo de trabajo y hacer un procedimiento. A partir de ese momento el procedimiento es sagrado.
- Método británico: el que se desplaza es un segundo del técnico (vestigios del Imperio…).
- Método español: Vamos y lo intentamos arreglar. Después, si podemos, haremos el informe, y el procedimiento….uff, eso ya veremos.
El ejemplo de los métodos muestra que podemos aprender de un incidente, más o menos grave, que en un momento dado puede afectar a un proceso de una organización. No se trata exclusivamente de aplicar el método israelí: atajar el problema y punto. Se trata de identificarlo, de ver cómo podemos afrontarlo si se vuelve a presentar, y de que podamos hacerle frente aunque no estén las personas que en su momento lo afrontaron.
La broma (seamos sinceros, a veces no tan alejada de la realidad…) me sirve para tratar un tema sobre el que hace tiempo tenía ganas de escribir: la Gestión de la Continuidad de Negocio. Y más que sobre la continuidad de negocio en sí o lo que son los RTOs, las BCAs y demás “palabros” habituales en la jerga asociada, sobre los problemas y los conceptos erróneos que detectamos cuando abordamos este tipo de proyectos en las organizaciones.
“Hacedlo, no me marees y que no sea muy caro”
Desgraciadamente Paradójicamente, el nivel de concienciación y de implicación de la Dirección en general es bajo. A los departamentos de IT les cuesta mucho convencer a los gerentes de la necesidad de invertir para prevenir. El dicho aquel de que sólo se acuerdan de Santa Bárbara cuando truena es una triste realidad; sólo cuando cae el servidor de correo y el servicio está inoperativo durante dos días, o cuando un troyano satura la red corporativa o hace caer el servidor del ERP y paraliza el proceso de facturación es cuando se pone el grito en el cielo y se plantean que a lo mejor es necesario contemplar situaciones que no tienen porqué darse, pero que el amigo Murphy se encargará de que se den.
¿Cuánto tiempo podría estar funcionando una empresa si sus principales aplicaciones corporativas dejaran de funcionar? ¿Cuál sería el volumen de pérdidas que generaría y cuánto habría costado tenerlo previsto?
¿Hasta qué punto la Dirección es consciente de la dependencia que tienen los procesos de negocio de los sistemas de información? ¿Y “sólo” dependen de los sistemas de información?
Al involucrar a la dirección y a las áreas de negocio de la organización en la fase de Análisis de Impacto en el Negocio (BIA, Business Impact Analysis) y en la de Análisis de Riesgos, se consigue su implicación y compromiso, desarrollar su concienciación sobre el tema y —aspecto fundamental— implicarles en la fase posterior de implantación del Plan de Continuidad de Negocio (Business Continuity Plan — BCP).
Un Plan de Continuidad de Negocio no es un Plan de Contingencia
Es muy habitual escuchar utilizar indistintamente términos como planes de continuidad, planes de contingencia o planes de recuperación de desastres como si todo fuera la misma cosa, cuando no lo son. Un BCP debe integrar un plan de contingencias, sí, pero es mucho más que eso. Es más, un BCP debe contemplar varios planes de contingencias: al menos de IT, de recursos humanos y de infraestructuras.
Como pasa en otro tipo de proyectos que no vienen al caso, el hecho de que se aborde el estudio de un plan de continuidad de negocio desde el punto de vista exclusivamente técnico/tecnológico hace que se piense en sistemas de alimentación redundantes, en copias entre cabinas de disco por fibra óptica o en replicación en tiempo real en un hot site. Todos estos aspectos son fundamentales, pero esta visión hace que no se contemplen por ejemplo contingencias relacionadas con el personal que utiliza los sistemas, o con un determinado servicio que presta un tercero con un SLA fundamental para el proceso de negocio. Muy habitualmente se identifica la continuidad del negocio con la continuidad del dato, lo que trae como consecuencia que no se contemplen aspectos que pueden ser tan importantes o más que el propio dato para garantizar la continuidad de un proceso que puede ser crítico para la organización.
El BCM no admite el cortar/pegar
Al igual que un SGSI, un BCP es un traje a medida para la organización, que jamás será extrapolable a otra, incluso aunque pertenezca al mismo sector de negocio. Ni la fase del BIA ni la del Análisis de Riesgos aceptan escenarios “universales”, sino que hay que estudiar todas las especificidades de la organización y de sus procesos de negocio.
La importancia de las pruebas
La Gestión de la Continuidad de Negocio (Business Continuity Management) es un sistema de gestión, y como tal está sujeto al famoso ciclo de mejora continua PDCA. Y si para cualquier sistema de gestión la “C” de Check es importante, en mi opinión en el caso de la gestión de la continuidad de negocio las pruebas de contingencia son cruciales para poder tener un nivel de confianza aceptable en el BCP definido. Es habitual encontrarse con organizaciones que en su momento definieron un BCP que acabó en la estantería de un despacho y que nunca ha sido probado: personas que ya no trabajan en la organización, aplicaciones que ya no existen, proveedores que ya no lo son, responsabilidades que han sido cambiadas, teléfonos que no son correctos, sistemas que fueron sustituidos, etc.
Como es natural, las pruebas de contingencia jamás van a ser tan duras y estresantes como una situación de contingencia real importante (e incluso van a traer complicaciones añadidas por la necesidad de testear entornos de prueba sin que los entornos de producción se vean afectados), pero sirven para valorar la robustez del BCP y revisar su grado de actualización, su eficacia y su eficiencia, el nivel de formación y concienciación del personal implicado, y como consecuencia de todo ello, pasar de la “C” de Check a la “A” de Act y modificar y actualizar aquellos aspectos que se ha comprobado durante las pruebas que es necesario modificar.
—
La resiliencia, en ingeniería, mide la capacidad de un material de recuperar su estado inicial después de ser deformado. Aunque curiosamente el término no está contemplado en el diccionario de la RAE, se utiliza muy habitualmente en ámbitos tan diferentes como la ingeniería o la psicología. En ciencias sociales, se define como la capacidad que tiene un individuo o grupo de individuos de recuperarse frente a la adversidad, para seguir proyectando el futuro.
No estoy descubriendo nada. Un BCP no es más que un sistema para garantizar en la medida de lo posible la capacidad de una organización (grupo de individuos) de recuperarse cuanto antes frente a posibles contingencias (adversidades) que puedan afectar a sus procesos de negocio (su futuro).
Una cuestión de resiliencia. No me negarán que es un área de trabajo apasionante…
