Ricardo G. Otero Buen día estimados colegas! Antes que nada les agradecemos la deferencia en interesarse en este artículo, el cual esperamos sea de vuestro agrado y utilidad. Ya hace tiempo, como equipo de trabajo, nos encontramos en la tarea de instalar el proceso de Gerenciamiento de la Continuidad del Negocio, en varias instituciones de nuestro país (Argentina), algunas de éstas financieras (con importantes regulaciones de índole tecnológica) y no financieras. Hemos notado que en muchas de ellas, esto implica una importante maduración en sus actividades del día a día. Atención: NO en términos estrictos de Continuidad de Negocio, sino de Gestión operativa de la institución. Esta situación enfocada en lo que hace a:  “Gobernabilidad de Infraestructura Tecnológica” a, “Infraestructura Edilicia”,  “Organización y Procesos y a, “Gestión de Riesgos”, nos ha mostrado que muchos de los problemas que tenemos para la implementación del BCM, obedece a fuertes debilidades en esas cuatro áreas, más que a requerimientos propios del BCM. Permítannos ir a varios ejemplos para ayudarnos en nuestra explicación: Focalizándonos en actividades de TI, encontramos las principales divisiones funcionales tales como: Desarrollo de Software, Infraestructura Tecnológica, Telecomunicaciones, Mesa de Ayuda y, Seguridad Informática. Una vez que nos ubicamos en cada una de estas funciones, comenzamos a detectar fuertes debilidades en actividades tales como: resguardos (problemas en los momentos de toma de los mismos, formatos de testeos, convenciones de nombres y herramientas para su rápida localización, identificaciones automáticas en los Jobs que los utilizan, ubicación off-site de los mismos…). Recordemos que la cadena se corta en su eslabón más delgado. En nuestro ejemplo: si no practicamos el testeo regular de los resguardos, es muy probable que al momento en que acudamos a estos puedan no estar disponibles como esperamos (tiempos que se necesitan para su restauración, contenidos). Vayamos a más actividades y sus posibles debilidades. Puestas en producción de Software de base la cual debería ser planificada y testeada previamente asegurándose que si hay diferencias entre nuestro Data Center Alternativo, los componentes operativos de sus equipos no sean en algún momento incompatibles con los avances en las aplicaciones que los utilizan y, no nos demos cuenta. Es por esto que quizás una aplicación que funcione correctamente en el Data Center Primario, NO lo haga en el secundario. Control de capacidad de almacenamiento, procesamiento y transmisión de datos de nuestro Data Center Alternativo. Esto en relación a los controles habituales que deberían hacerse a dicho lugar como parte de nuestra gestión tecnológica. Obviamente con el objetivo de asegurarnos que las respuestas en aquel lugar, serán las esperadas por el negocio y muy cercanas a las utilizadas habitualmente por el mismo. Facilidades en las aplicaciones utilitarias como “Antivirus”, “Correo” asegurándonos que los correos puedan accederse desde cualquier lugar aceptado para la contención, temas de certificados digitales y ubicación de los pst históricos. Bitácoras de operación de los sistemas (para operadores), con Jobs que salteen actividades que NO son críticas para el negocio. Habitualmente analizamos qué procesos manuales pueden dejar de hacerse en situación de crisis, pero…dejamos de lado los automáticos dado que Desarrollo de Sistemas, no ha marcado los lugares en los Jobs que, similarmente a lo manual, deberían dejarse de lado. Si avanzamos sobre el área de Desarrollo, la inexistencia de estándares de programación así como de documentación de sistemas incluyendo un mapa de aplicaciones, nos puede complicar a la hora de decidir qué aplicaciones mantener en el Data Center Alternativo. Aquí proponemos considerar que NO SOLO LAS APLICACIONES CRITICAS deben mantenerse “con vida” durante la contención. Suele suceder que aplicaciones NO criticas contienen piezas de software que son utilizadas por las que SI son críticas y, éstas últimas al no encontrarlas en el DCA, cancelan, obligándonos a efectuar búsquedas e instalaciones de emergencia. Software considerados como “descartables” al momento de una crisis (tradicionalmente “DataWarehouse”), al no considerar que dado los tiempos que requieren su ejecución, si dejamos de ejecutarlos por varios días, nunca más podremos tener sus bases actualizadas y con el consiguiente riesgo de pérdida de una rica historia de información. Interfases que no esperan ser ejecutadas en forma contínua y “pisan” sus entregas a otros sistemas sin siquiera preguntar si ha sido o no tomada el despacho anterior de información. Puntos de retoma no indicados en los Jobs, ausencias de arquitectos de datos, software o hardware que hace que encontremos un “enjambre” de cosas en la granja de servidores, distribuidos antojadizamente o sin criterio nos encarecen el montaje de nuestro DCA. Resguardos de fuentes, versionadores, control de software de proveedores, contenidos de los entornos de testeos, análisis de riesgos en las puestas en producción diarias, definiciones “unilaterales” de momentos de resguardos, generando RPOs desconocidos para el negocio y por lo tanto, con grandes riesgos de que no sepan (o puedan) reconstruir su situación ante una crisis “inoportuna”… Si recorremos Seguridad Informática, generalmente encontramos que NO se han hecho el tiempo de analizar posibles degradaciones de la seguridad en las comunicaciones,  accesos a las bases de datos, controles de actividades del oficial de seguridad en el DCA, ubicación de certificados de seguridad, controles de capacidad de VPNs para teletrabajos…etc. En el área de Mesa de Ayuda, la inexistencia de estándares en la formación de puestos de trabajo, encarece la formación de puestos alternativos por el alto costo de la gestión diaria en el mantenimiento de las posiciones alternativas; considerar que software de gestión de incidentes no son necesarios durante una contención, dejando de lado pensar cómo vamos a gestionar los mismos durante el start up en una cisis. Por último miremos un instante el área de Organización y Procesos. La ausencia de un mapa integral de procesos (mas o menos maduro y actualizado), nos impedirá asegurarle a la alta Gerencia, que nuestra contención abarca desde el principio a fin toda la cadena productiva del negocio que sostiene un producto o servicio importantísimo para la supervivencia de la empresa. Son muchas las actividades en el día a día que deberían madurar para “abaratarnos” los costos de implementación del BCM. Gracias por vuestra atención y quedamos a sus órdenes para eventuales consultas adicionales. Licenciado en Administración con más de 25 años de experiencia en los rubros de Desarrollo de Sistemas, Líder de Proyectos,  Auditor Líder de Tecnología junto con Auditorías de Riesgo Operacional, Asesor del mercado financiero para la Implementación de proceso de Gerenciamiento de Continuidad del Negocio (BCM), Diseño y construcción de Planes de continuidad del Negocio y Continuidad de Procesamiento de Datos. Certificado como Business Continuity Professional por el DRII.