Archivo de la etiqueta: tecnología

Diseño de un DRP – bases a considerar

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.

foto mia 2Licenciado 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.

Continuidad de los servicios TI – clave para la sobrevivencia de las organizaciones

Sandra Camacho

Hoy en día la continuidad de nuestras organizaciones depende en gran medida de la continuidad de los servicios de tecnología de información (TI), de tal manera que una adecuada gestión de estos servicios conlleva a aumentar el éxito en el logro de los objetivos de continuidad de las organizaciones. En este artículo, se expondrán los logros y beneficios para la continuidad de negocio logrados en el Banco de la República de Colombia con la implementación de los procesos de gestión de tecnología bajo las mejores prácticas propuestas por ITIL (Information Technology Infrastructure Library), incluyendo los factores de éxito y lecciones aprendidas durante de implantación de las prácticas de ITIL.

 

Contexto de los procesos del Banco

El Banco de la República es el Banco Central de Colombia, por tal razón, tiene funciones constitucionales críticas para el sector financiero del país. Estas funciones son: administrador de las reservas internacionales, banco de bancos, banco, agente fiscal y fideicomiso del Gobierno, emisor de moneda legal, funciones cambiarias, estratega de la inflación objetivo de Colombia, prestamista de última instancia, promotor del desarrollo científico, cultural y social; y rendición de cuentas a los colombianos, siendo su principal objetivo el control de la inflación. Su misión ha sido definida como  “Contribuir al bienestar de los colombianos mediante la preservación del poder adquisitivo de la moneda y el apoyo al crecimiento económico sostenido, la generación de conocimiento y la actividad cultural del país”. El Banco de la República de Colombia tiene presencia nacional a través de 28 sucursales, una en cada ciudad capital del país, con sucursales de oficinas de tesorería en algunas de ellas y presencia cultural en todas ellas.

 

Contexto de los procesos de la dirección general de tecnología

Como es común en todas las organizaciones, para el cumplimiento de su misión, el Banco de la República cuenta con un  alto componente tecnológico con plataformas heterogéneas, diversos sistemas, proveedores y fabricantes, tecnologías “tradicionales” y “de punta”; y con proyectos transversales de modernización, que afectan servicios de misión crítica, convivencia de plataformas “nuevas” y “obsoletas”; lo que exige una gestión altamente eficiente y efectiva y de manera más sobresaliente, una gestión de continuidad. Es así como hoy en día, la continuidad de nuestra organización depende en gran medida de la continuidad de los servicios de tecnología, de tal manera que una adecuada gestión de estos servicios conlleva a aumentar el éxito en el logro de los objetivos de continuidad.

Con este contexto, la misión de la dirección de tecnología del banco es la siguiente: “Contribuimos al cumplimiento de los objetivos del Banco y a la generación de valor a sus áreas, brindando servicios y productos basados en tecnología”, de tal forma, que es necesario que esta base tecnológica tenga un altísimo grado de continuidad; puesto que en general, toda la operación es soportada por alguno de estos servicios. Por otro lado, cualquier inconveniente sobre esta plataforma o la funcionalidad de los aplicativos operativos específicos, puede generar un riesgo sobre la continuidad del negocio.

Como base de la gestión en la dirección general de tecnología del Banco, se cuenta con un  “gobierno de tecnología” fundamentado en el liderazgo, los niveles de autoridad, la  estructura organizacional y los procesos; estos últimos, basados inicialmente en las áreas funcionales y evolucionando hacia procesos transversales. Asimismo, se cuenta con indicadores de gestión que incluyen tanto indicadores estratégicos como de operación, y particularmente, la medición de puntos críticos para la continuidad y la gestión de riesgos; ésta última, dentro del contexto organizacional de la gestión de riesgo operativo y la rendición de cuentas.

Dentro de las mejores prácticas empleadas como fundamentación de esta gestión tecnológica se cuenta con: COBIT para el control gerencial, ISO 9001 para la gestión de la calidad, ISO 27001 para la gestión de seguridad, CMMI para el desarrollo de aplicaciones, PMI para la gestión de proyectos, prácticas profesionales del DRI International (Disaster Recovery Institute International) y del BRCCI para la gestión de continuidad e ITIL para la gestión de servicios.

 

Logros y beneficios del uso de ITIL para la gestión de continuidad de los servicios TI del Banco

¿Cuáles han sido los logros y beneficios de ITIL para el Banco? Básicamente estas buenas prácticas han brindado un apoyo importante en la adecuada gestión de la tecnología de la organización, facilitando la visión transversal de los procesos de TI y permitiendo la operación estandarizada y coordinada de las actividades propias de la gestión de la tecnología, la cual de acuerdo a ITIL, es clasificada en cuatro grandes macro-procesos a saber: Estrategia, Diseño, Transición y Operación.

Estrategia del servicio

Para poder explicar a detalle estos logros y beneficios, los presentaré a través de un recorrido por los cuatro macro-procesos de ITIL. Para identificar estos  beneficios, hemos encontrado que cada uno de ellos nos brinda un aporte importante, e incluso fundamental, para la continuidad de los servicios de tecnología; particularmente, en la realización de una adecuada definición estratégica a través de los procesos estratégicos de gestión financiera, gestión del portafolio y gestión de la demanda, puesto que esto ha facilitado una adecuada gobernabilidad de los servicios al estar enmarcados en la visión estratégica y táctica de la organización y así se engrana esta visión con la operatividad de la gestión de tecnología.

Estas buenas prácticas las hemos sintonizado dentro del engranaje del gobierno de TI del Banco a través de su seguimiento, mediante indicadores de gestión que son revisados mensualmente en los comités de gerencia de TI. Asimismo, están inmersos en los estándares definidos para las arquitecturas,  desarrollo y mejoramiento de nuevos productos, donde se hecho evidente la importancia de una metodología de gerencia de proyectos estructurada y basada en la gestión de la demanda. Por otro lado, han sido fundamentales los adecuados niveles de autoridad y de estructura organizacional que facilitan el acercamiento de estas buenas prácticas a todos los niveles dentro de la organización de TI.

Diseño del servicio

En cuanto a los procesos de “Diseño del  Servicio” y resaltando de manera inicial lo que para nosotros ha sido el punto de entrada, el proceso de “Gestión del Catálogo”. Este proceso nos ha llevado a conocer explícita y transversalmente, a nivel de toda la organización, cuáles servicios están en producción, sus modificaciones, y la salida de los mismos de la operación; lo cual ha permitido tener una visibilidad y control adecuada para la gestión de Continuidad de TI desde diversos frentes fundamentales, como son: las áreas operativas, las personas que operan TI y la gerencia, ya que ha  permitido un acceso ágil a los productos y servicios de TI, especialmente cuando se presenta una crisis o un requerimiento especial sobre alguno de éstos. La contextualización y la interrelación con TI han ayudando incluso a visualizar mejor el contexto y la dependencia de TI de las áreas, lo que les ha facilitado estructurar mejor sus planes de acción dentro de sus planes de continuidad de negocio (BCPs, business continuity plans), para los asuntos relacionados con TI.

Sin embargo, este proceso no tiene sentido si se maneja de manera aislada, y en particular, si el objetivo es garantizar ese adecuado entendimiento entre lo que esperan las áreas operativas y lo que TI está en capacidad de ofrecer. Por tanto, se debe ofrecer al menos, parámetros que deben estar claramente descritos a través de la “Gestión de los Acuerdos de Servicio”. Este proceso es tal vez uno de los procesos que se ha tornado más crítico para la adecuada gestión de continuidad de TI del Banco, frente a lo que se espera para la operación del negocio. En este punto es donde hemos podido especificar de manera concreta y aterrizada para la organización, las expectativas tanto en situación de normalidad como en eventos de crisis. En su primera versión nos concentramos más en la prestación del servicio en estado de normalidad, y hoy en día, hemos incluido un capítulo relacionado con la continuidad, donde hemos especificado explícitamente los tiempos estimados de los objetivos de recuperación de las operaciones (RTO, recovery time objective) y de  información (RPO, recovery point objective), para los casos en los que se presente una falla que afecte el servicio; estableciendo incluso, tiempos por tipo de falla. Este elemento ha permitido llegar a acuerdos importantes con la operación del negocio, ya que eventualmente hemos tenido que cambiar prioridades o incluso iniciar proyectos de aumento de capacidad o de cambios de arquitectura con miras a poder lograr el cumplimiento de los requerimientos del negocio en tiempos objetivo de recuperación. Por otro lado, ha permitido a las áreas operativas revisar sus análisis de riesgos y de impacto al negocio (BIA, business impact analysis), a la luz de un mayor conocimiento sobre la viabilidad de sus estimados de tiempos de recuperación, generando ajustes a sus planes de acción. Es así que cada vez trabajamos más de la mano  en el logro de un BCP realmente viable.

En este mismo sentido, los procesos de diseño relacionados con la “Gestión de Disponibilidad” y la “Gestión de Capacidad”, nos han brindado herramientas clave para poder dar cumplimiento a los “Acuerdos de Servicio”. Estos procesos nos han permitido identificar nuestra capacidad real, de tal manera que hemos podido estructurar planes de acción de TI con una clara especificación de prioridades de atención y conforme a los “acuerdos de servicio”, especialmente cuando se han conjugado una serie de eventos o de situaciones que demandan el uso de los recursos de manera simultánea. Particularmente, ha sido importante tomar en consideración no solo la capa de infraestructura y de telecomunicaciones, sino cada elemento de hardware, los centros de cómputo, de almacenamiento, etc.; siguiendo con las capas de las arquitecturas y llegando a la capa final de aplicación y presentación en lo relacionado con los servicios. Para nosotros ha sido fundamental incluir en estos procesos la capacidad y disponibilidad del recurso humano que administra, realiza el monitoreo y gestiona los servicios de tecnología, así como el concientizar a estas personas de los acuerdos que han sido establecidos con las áreas operativas y la operación del negocio, lo cual ha permitido trabajar de manera más sincronizada en los momentos donde más se ha requerido, es decir, cuando hay una crisis o emergencia.

La gestión de continuidad del negocio, y especialmente la continuidad de TI, no está completa si no se toma en cuenta a los proveedores de servicios. En este punto se tiene en ITIL el proceso de “Gestión de Proveedores”. Para el Banco, ha sido muy importante considerar los asuntos relacionados con la disponibilidad de los servicios ofrecidos, sus planes de acción en caso de falla y el seguimiento a síntomas que puedan generar posibles riesgos para la operación del Banco. Es así que ha sido fundamental la realización de análisis de riesgos de estos proveedores, lo que ha permitido considerar puntos clave de monitoreo y validación del cumplimiento por parte de éstos, ya que pueden tornarse el eslabón más débil para la operación.

En este grupo se encuentran dos procesos adicionales: la “Gestión de Continuidad de los Servicios de TI” y la “Gestión de Seguridad de la Información”, donde hemos enmarcado las mejores prácticas tanto de Continuidad como de Seguridad, como son las prácticas propuestas por DRI International e ISO 27001, respectivamente.

Transición del servicio

Podemos decir que los procesos de “transición” son los que generan más riesgos para la continuidad de TI, puesto que este en este grupo de procesos se encuentran la “Gestión de los Cambios” y  la “Gestión de Despliegue y Liberaciones”. En nuestra experiencia, hemos encontrado que las fallas de TI se han presentado cuando se lleva a cabo algún cambio sobre las arquitecturas o cuando llega un nuevo servicio a producción. Esto a pesar del cuidado en la realización de estas tareas, ya que en muchas ocasiones no se contaba con los niveles adecuados de autorización o de evaluación del impacto o del conocimiento de la dinámica del negocio, para poder así, determinar cómo y cuándo llevar a cabo estas acciones sobre las plataformas de TI, así como el realizar la adecuada notificación a las áreas del negocio involucradas, con el fin de que estas últimas a su vez, tomaran medidas de precaución o informaran de situaciones de negocio que permitieran mitigar el impacto en caso de una falla.

Estos procesos se complementan con la realización de una “Gestión de Activos y Configuración”, que nos ha facilitado el adecuado manejo de los cambios sobre la plataforma, los cuales, como fue comentado anteriormente, han sido la mayor causa-raíz de problemas de continuidad en los servicios de TI. El proceso de Gestión de Activos y Configuración nos ha permitido contar con un nivel adecuado de conocimiento  de los elementos y de la configuración sobre la cual se van a realizar los cambios, facilitando el adecuado análisis de riesgos e impactos sobre la plataforma de TI en el momento de realizar un cambio. Este proceso ha venido a jugar un papel importante para garantizar la Continuidad de los servicios de TI, mediante un control fuerte en las autorizaciones de los cambios, la evaluación de manera juiciosa en caso de llevar a cabo el cambio, el análisis de los impactos sobre las plataformas y sobre la dinámica del negocio; así como entender el cómo se llevaría a cabo el “retorno” del cambio (en caso de identificar que no operara adecuadamente), y entender el mejor momento para la realización del cambio, de acuerdo a la dinámica de los negocios afectados y del nivel de preparación respecto a las “Contingencias Operativas”, en caso de presentarse una situación grave que impida la recuperación en los tiempos estimados. La correcta “Gestión de la Configuración” así como de un adecuado conocimiento de las arquitecturas de la plataforma, permiten tomar decisiones más acertadas sobre dichos cambios.

Operación del servicio

Los procesos de “Operación”, nos han brindado un conjunto de lineamientos para llevar a cabo una gestión eficaz de los servicios una vez que están en operación, y especialmente para la continuidad de TI. La identificación pronta y oportuna de incidentes o eventos que puedan afectar la operación del negocio así como su ágil escalamiento y solución, a través de procesos de “Gestión de Incidentes” y “Gestión de Eventos”, han facilidado llevar a cabo acciones inmediatas de toma de control, evitando impactos mayores sobre la operación del negocio. Asimismo, nos ha permitido evitar la reincidencia de eventos y la corrección definitiva de fallas, a través de la realización juiciosa de análisis causa-raíz, el cual es parte del proceso de “Gestión de Problemas”.

Por otro lado, muchos de los riesgos de continuidad de TI, particularmente las negaciones de servicio o errores de personas que no operan correctamente la tecnología o los productos, son controlados a través de la “Gestión de Acceso”. Este proceso brinda al Banco un control eficiente del riesgo de acceso no autorizados de personas, que a su vez, pueden generar otros riesgos, ya sea de manera  intencional o no intencional para la continuidad de los servicios. Adicionalmente, a través de este proceso podemos identificar la dinámica de los usuarios de los servicios, lo que nos ha brindado información útil para la evaluación del impacto frente a eventuales caídas de los servicios de TI, así como para la identificación de los roles que deben ser convocados en caso de crisis y para la estructuración de un esquema de roles y responsabilidades de titulares y suplentes que permitan soportar la operación, incluso, en casos de problemas operativos que afecten la continuidad del negocio.

Finalmente, a la luz de ITIL existe un proceso para la solicitud automática de “servicios”, el cual nos ha permitido facilitar y aumentar la oportunidad de atención a las áreas operativas, evitando demoras en la petición requerida; minimizando al mismo tiempo, los tiempos que puedan afectar la continuidad de las operaciones.

Es así, como hemos encontrado muchos beneficios en cada uno de los procesos presentados por ITIL, que facilitan la labor de brindar Continuidad de los servicios de TI. Como se comentó al inicio de este artículo, en la medida que las organizaciones dependen cada vez más de la infraestructura de tecnología, de sus servicios y de la información, a nivel operativo, táctico y estratégico, la continuidad de los servicios de TI se convierten en la parte más crítica de la continuidad del negocio.

 

Factores de éxito y lecciones aprendidas

En general dentro de los obstáculos encontrados, principalmente está la visión funcional que tiene cada área de tecnología y que tradicionalmente así ha venido manejando, especialmente porque las estructuras llevan a trabajar en grupos aislados y con pocas interfaces entre sí. Sin embargo, para la superación de este obstáculo se realizó un trabajo conjunto entre los directores de las distintas áreas, encaminado hacia una misión y visión unificada como área de TI y enmarcada dentro de la hoja de ruta definida por la organización.

El cambio en los procesos no siempre ha sido fácil y la necesidad de estandarización de estos procesos viene entonces a jugar un papel importante en su viabilidad. Particularmente en lo que respecta al manejo de excepciones, ya que siempre se presentarán las urgencias, entre otras, las originadas por nuevas reglamentaciones o solicitudes especiales que exigen brindar y llevar a cabo los procesos con mayor prontitud, lo que a su vez dificulta realizar todas las actividades definidas para el proceso. En estos casos, se definieron compromisos para el cumplimiento de elementos que podrían desarrollarse posteriormente; sin embargo, es importante dar el seguimiento y llevar el control de dichos compromisos.

Un factor clave de éxito que hemos aprovechado, es involucrar activa y directamente a los directores de cada una de las áreas, tanto de tecnología como de las áreas operativas clave que participan en los procesos, quienes conscientes de la importancia de la aplicación de las buenas prácticas para la gestión, han trabajado en conjunto y con una visión global del proceso dentro del contexto de la organización.

Adicionalmente, si bien las herramientas de apoyo no es lo primero a tomar en cuenta, si han representado una pieza importante dentro del engranaje de estos procesos, ya que han brindando la trazabilidad necesaria, la base de conocimientos, la identificación y la solución temprana de situaciones que pueden poner en riesgo la continuidad del negocio. Para el caso del Banco, se cuenta con la automatización ofrecida por las herramientas de Hewlett-Packard y Altiris, con las que hemos automatizado los procesos de “Gestión de Incidentes”; “Gestión de Eventos, Alertas y Monitoreo”; “Gestión de Configuración” y “Gestión de Atención de Solicitudes”.

Una adecuada concientización en todos los niveles de la organización y de manera transversal, permitirá que se logre el mejoramiento o incluso, la estructuración de procesos de gestión. Sin esta conciencientización, será un trabajo extenuante y seguramente sin muchos frutos. Por esta razón, cualquier esfuerzo debe comenzar por esta actividad, pero no realizarla solo al inicio, sino continuar con la concientización de manera permanente y en todo nivel, mostrando con hechos concretos el mejoramiento. De esta manera, se logrará incluso que de las personas que antes eran detractoras de este esfuerzo, aporten ideas que serán valiosas para la maduración de los procesos y en nuestro caso, para la gestión del servicio de TI.

A manera de conclusión, es importante resaltar que al brindar un mejor servicio hemos podido brindar también mayor productividad y mejorar la confianza de las áreas operativas y del Banco sobre las acciones de tecnología, lo  que ha permitido minimizar la incertidumbre, incrementar la pro-actividad en la operación, y mejorar la calidad en diseño de los servicios. Esto último, nos ha llevado a minimizar el riesgo de fallas en operación, incrementar la prevención de incidentes en operación, la trazabilidad de lecciones aprendidas y la mejora en el tiempo de diagnóstico y solución, lo que al final, se traduce en niveles adecuados de continuidad de TI y por tanto de continuidad del negocio.

 

Sandra P. Camacho Bonilla tiene más de quince años de experiencia en las áreas de continuidad del negocio, gestión de riesgos y manejo de estándares y políticas de tecnología. Desde hace siete años es la directora de la unidad de soporte y continuidad de tecnología del Banco de la República de Colombia (Banco Central de Colombia). Especializa en “Business Impact Analysis” y  “Emergency Management & Safety Solutions”. Entre sus experiencias ha liderado acciones de planeación, respuesta y recuperación de  operaciones en diversos escenarios de contingencia en el sector financiero, implementación, control y seguimiento de centros de datos alternos remotos. Líder de los procesos de certificación de calidad ISO 9001 y auditor ISO 27001 para el área de tecnología del Banco de la República de Colombia. 

Es certificada en CBCP por el DRI International desde 2001 en Boston, Massachusetts, ITIL versión 3, Auditor ISO 27001 e ISO 9001 y PMP por el PMI desde el 2005. Ingeniería y Maestría en sistemas y computación de la Universidad de Los Andes. Ha sido docente académica de la Universidad de Los Andes, Universidad Javeriana y Universidad Piloto de Colombia así como conferencista en eventos de seguridad informática y continuidad.

¿Realmente mi empresa necesita un Software de Continuidad de Negocio?

Ezequiel Matias Fagetti

El software de continuidad de negocio no es nada nuevo, talvez usted ya ha tenido experiencia con estas soluciones, pero las pregunta son: ¿Es tiempo de utilizarlas? ¿Estas herramientas nos ayudan con los cambios, con nuestras necesidades y con el rol expandido de los profesionales de continuidad de negocio? Como todo lo relacionado con continuidad de negocio, la respuesta a estas preguntas no es tan simple.

 

Algunas de sus resistencias.

Desde que se comenzaron a utilizar, una de las quejas más repetidas en relación con el software de continuidad de negocio era que no son muy fáciles de utilizar, sin importar las campañas de marketing que indicaban lo contrario. Inclusive, los productos de mayor facilidad en su manejo, en comparación con el resto eran multi capa y muy complejos, especialmente para los administradores y usuarios con altos privilegios.

Pero en defensa los proveedores de este tipo de software, han puesto énfasis en facilitar su uso en estos años recientes, y actualmente su uso no es tan tedioso e  incomprensible como solía ser.

Por otro lado, hemos visto un número de paquetes de software que simplemente automatiza el problema e inclusive lo puede hacer más grande. Algunas aplicaciones están más focalizadas en la documentación en vez de los datos, otros fueron construidos sin el entendimiento de que la continuidad de negocio es parte de la gestión de riesgos.

No obstante, todavía hay gente que se pregunta ¿Por qué molestarse? ¿Por qué no continuar utilizando Word, Excel and sharepoint? ¿No sigue siendo más fácil? , en este artículo más adelante incluyo algunas reflexiones para ayudar a responder estas preguntas.

 

¿El software me soluciona todos mis problemas de continuidad?

Como usted podrá suponer, la respuesta a esta pregunta es un simple “no”, cualquier software de continuidad, aún sea de los mejores del mercado, solo nos servirá de soporte (muy importante por cierto), pero representa solo una parte de la planificación e implementación de una estrategia de continuidad.

A menudo, muchas organizaciones compran un software y construyen el programa de continuidad alrededor del software, en vez de utilizar esta software como una herramienta de apoyo; por ninguna razón, el software debería gobernar el enfoque de continuidad de negocio.

En mi experiencia, he observado frecuentemente la tendencia a iniciar un programa de continuidad de negocio que está focalizado más en el tener el propio plan en vez de focalizarse en el proceso y el beneficio de tener una estrategia clara de continuidad, inclusive, muchas veces los planes son desarrollados simplemente para cumplir con normativas externas o internas de la organización.

Evidentemente que si en la organización no creamos un plan estratégico de continuidad de negocio donde se analicen diferentes variables, como la planeación y análisis de la situación, control de daños/riesgos, recuperación y continuidad de las operaciones, mantenimiento del plan, y evidentemente el software de continuidad a ser utilizado, puede ser que se cumpla con la formalidad, pero esto no agregara valor para la organización.

 

Software desde un perspectiva más amplia que la continuidad de negocio – GRC

Creo que es momento de comenzar a ver las tradicionales soluciones de continuidad con una visión mucho más amplia, cambiando de una visión de software de planificación a una visión en favor de Gobierno, Riesgos y Cumplimiento (GRC, Governance, Risk, and Compliance). En mi opinión, existen muchas empresa de software que proveen herramientas que son realmente muy buenas y que mejoran la situación general de la continuidad. He observado que se han realizado implementaciones exitosas de estos paquetes de software que ayudan a la gente en sus esfuerzos de planificación de continuidad, sin embargo, observo también que existe un quiebre cuando los desarrolladores de estos sistemas empiezan a entender que el programa empieza necesita contar con capacidades más amplias. En este sentido las herramientas con capacidades GRC adquieren mayor importancia.

Mi opinión es que las herramientas basadas en GRC están en mejores condiciones de ayudar a los profesionales de Continuidad de Negocio y a las organizaciones a los que ellos sirven para lograr un mayor entendimiento y una mejor gestión de riesgos.  Una solución GRC es una herramienta central desde el punto de vista de cumplimiento y están relacionadas con todos los dominios (incluyendo el de continuidad, por supuesto), si su compañía es una empresa globalizada, es crítico tener un entendimiento de los requerimientos regulatorios alrededor de sus actividades, como también de las actividades de gobierno para los productos a vender o servicios a ser entregados. Las herramientas GRC típicamente están construidas con un núcleo de auditoria  y permiten calibrar los programas de continuidad de negocio.

En todos los niveles de la organización, un programa efectivo de continuidad asegurará la continuidad de las operaciones y servicios, y frecuentemente es un proceso vivo que incorpora un gran numero de diferentes elementos complementarios que trabajan en conjunto con las otras funciones de GRC

Estas oportunidades de integración entre Administración de la Continuidad del Negocio (BCM, Busines Continuity Management) y GRC proveen a la empresa un mecanismo de políticas y procedimientos mejorados, ampliando la visibilidad de los riesgos operacionales, reduciendo la duplicidad de esfuerzos, y fomentando el uso de datos compartidos. El resultado final es una mejor y más ajustada ejecución de procesos para los eventos normales y extraordinarios.

 

¿Automatizar el proceso de continuidad o no?

En mi opinión las principales ventajas de un software bien diseñado son: servir como guía en la planificación a través de procesos, estandarizar el plan en diseños y evidentemente facilitar el mantenimiento de toda la documentación involucrada en el proceso. Adicionalmente, muchos de los paquetes de software también incluyen la habilidad de generar reportes, soporte a otras tareas con comandos de incidentes y funciones de notificación, por nombrar algunas de ellas.

Como desventaja principal mencionaría principalmente el costo; y en algunos casos, las limitaciones en flexibilidad para adaptarse a necesidades específicas de las empresas.

He escuchado decir que es más simple gestionar la continuidad con documentos Word y guardarlos en diferentes carpetas. Sin embargo, desde mi punto de vista el verdadero problema con este enfoque es que al necesitar acceder a estos documentos para realizar un análisis, siempre es demasiado complicado, igualmente también el mantener los planes actualizados; lo cual implica recorrer toda la información relacionada con los diferentes planes guardados en diferentes instalaciones de la organización. Esto por supuesto, crea una mayor probabilidad de que estos planes o la información relacionada, esté desactualizada, y por lo tanto, el plan sea inefectivo en caso de una contingencia, por lo cual mi planteamiento es ¿por qué seguir este complicado proceso de gestión con documentos Word?

La respuesta depende de lo que la organizaicón quiere hacer, del volumen de datos a analizar, de la importancia que tiene la actualización de la gran cantidad de planes y de como seguir mostrando la interdependencia entre ellos. En algunos casos probablemente no se necesite una herramienta, pero con eso se va tener menos capacidad para realizar los procesos de actualización, comunicación y ejecución. Por el contrario, utilizando una herramienta será más fácil madurar el programa de continuidad de manera más rápida y efectiva, teniendo acceso a mayor cantidad de información dentro de la organización.

 

Ezequiel Matias Fagetti, MBA, CISA , CISM, CGEIT, LA 27001 – Ezequiel tiene más de 17 años de experiencia en el área de Administración de Riesgos, Gobierno Corporativo y la Gestión de Servicios, como asesor y como practicante. Ha vivido y trabajado en diferentes países como: Argentina, Reino Unido, EE.UU., España y Chile. También ha participado en grandes proyectos relacionados con las áreas de: Auditoría Interna, Auditoría TI, Cumplimiento, Servicios Financieros y SOX. Ezequiel es un miembro de ISACA y posee las certificaciones CISA, CISM y CGEIT, tiene una licenciatura en Ciencias de la Computación y obtuvo un MBA en 2001 en Barcelona. Sus especialidades son: Auditoría Interna, Gestión de la Continuidad, Asesoría Financiera, Control Interno, Administración de Riesgos, Gobierno, Gestión de Proyectos, SOX y Cumplimiento. Ezequiel puede ser contactado en efagetti@deloitte.com