Archivo de la categoría: Prácticas de Gestión
La Clasificación de la Información.
Muchos incidentes de seguridad de la información pasan porque no se tiene idea de lo sensitivo que la información es para la empresa. La Gestión de TI tiene que ser proactiva en definir niveles de sensibilidad de la información y clasificar toda la información que administra. Esta tarea, permite definir riesgos reales, como lo ve la Alta Dirección, a la vez que proporciona el valor real de la información y la justificación para las inversiones en tecnología.
La Gestión de TI debe tener claro en primer lugar que su razón de ser es el negocio. Todos los frameworks y metodologías de gestión de TI, hacen énfasis en que en primer lugar, los procesos de negocios tienen que ser evaluados, para identificar los requerimientos de TI del negocio. Inmediatamente después pasan a centrarse en el modelo de información que soportará las operaciones de negocio. Luego, un elemento importante del modelo de información, es la clasificación de la información. Esta tarea, consiste en identificar cada pieza de información que se administra en la empresa y discutir con el negocio el nivel de acceso, en términos de poder verla, poder modificarla o eliminarla y las áreas internas y externas de la organización que usarán este acceso. Cuando vemos en los organismos de inteligencia de las grandes naciones que utilizan términos como “secreto” o “top secret”, no asumimos ese nivel de confidencialidad en nuestra información, por no poner en riesgo ventajas estratégicas en términos de planes de competitividad entre naciones, que incluso algunas veces son de carácter bélico. Sin embargo, la Gestión de TI tiene que interiorizar que el término “confidencialidad” aplica a todas las organizaciones. Hay que considerar varios aspectos. La Gestión de TI debe estar clara que en el ámbito comercial, prácticamente se libra una guerra todo el tiempo, en la cual, se trata de ganar a nuestra competencia con los mejores precios, los mejores servicios, las mejores ventajas, etc. Por ejemplo, la planificación de una estrategia de mercado, que incluye publicidad, preparación del producto o servicio y toda una actividad de divulgación interna, para asegurarse de que todos los empleados entienden que se le ofrece al cliente, se puede arruinar, si es conocida previamente por la competencia. Esto se puede dar si alguna presentación de entrenamiento o de discusión de la estrategia es sacada del ámbito de la empresa y compartida con alguien externo, ya sea intencionalmente o no. Esto implica, que la Gestión de TI debe de considerar la información, no sólo las bases de datos. Esto es, identificar claramente la información a clasificar, en todas sus posibles formas de uso y crear instrucciones específicas hacia el personal de la organización sobre la clasificación de la información existente y que tiene que ser observada sobre la información en todas sus presentaciones. Algo que aporta mayor relevancia a esta actividad es cuando la empresa administra información de otros, por ejemplo, los clientes, cuya información no debería de ser divulgada por nosotros. Información sensitiva que podría existir en nuestras bases de datos incluye datos personales de identificación de clientes y datos de tarjetas de crédito, que incluso poseen normativa especial para su manipulación (PCI DSS – Payment Card Industry Data Security Standard), con el fin de asegurar que no existan brechas de seguridad que lleven a divulgar esta información. Hay que notar, que si existen estándares, la Gerencia de TI podría exhibir negligencia en no aplicarlos, si son pertinentes para la organización.
Controles Sobre Los Datos.
Aunque los datos de una organización residan en Bases de Datos de última tecnología, con altas prestaciones en cuanto a características de seguridad, siempre se tiene que planificar e implementar controles para mitigar el riesgo de que nuestros datos pierdan integridad, confidencialidad o disponibilidad. Muchos gerentes o presidentes de empresas, mantienen la duda sobre la confiabilidad del manejo que las Gerencias de TI realizan. Si la organización es grande, muchas veces las tareas del manejo de datos son asignadas a más de una persona, por lo que la duda recae sobre la organización, procedimientos, estrategias de segregación de tareas y controles definidos para darle seguimiento al mantenimiento saludable de los datos. Las Gerencias de TI tienen que realizar no solo la tarea operativa de coordinar el manejo de los datos, sino también la proactiva demostración hacia la Alta Dirección de la efectividad y transparencia con la que se están administrando los datos. Es muy mala señal, cuando un Auditor de Sistemas pregunta por las políticas y procedimientos de administración de bases de datos y estos no existen. El primer mensaje que se proyecta con este hallazgo es que no se han configurado controles de una manera consciente. Posiblemente existirán controles, porque los técnicos de TI, en cada nivel, a partir de su conocimiento y las características del software que implementen, seguramente activaran algunos controles, llevando la administración de datos a un estado que podría denominarse inicial y de ser muy consistente y seguro, repetible, pero no documentado. Los Gerentes de TI deben de tener presente una premisa. Sin importar el tipo de organización que se trate, la confianza inicial en el manejo de datos ha sido asignada a ellos, a partir de que es un experto en la gestión de Tecnologías de la Información, pero es su responsabilidad el mantener e incrementar esa confianza a través del establecimiento de políticas y procedimientos que demuestren claramente como se garantiza la efectiva Administración de Datos. Internamente, la Dirección de TI también debe de organizar el proceso de Administración de Datos, de manera que se garantice que técnicamente se están aprovechando las funcionalidades del software administrador de bases de datos, que se han asignado las responsabilidades, que se han documentado todas los diseños relacionados con los datos (diagramas entidad – relación, reglas de transformación de datos, migraciones de datos y similares). Es importante también que las Gerencias de TI propicien el compartimiento de responsabilidades en cuanto a la seguridad de los datos. No hay nada más sospechoso que una Dirección de TI que administra de manera secreta los datos. Secreta para su Junta Directiva, para su Oficial de Seguridad, para su departamento de Auditoría o para cualquier otro mecanismo de control establecido por la Alta Dirección. En realidad, este tipo de organismo debe de formar parte operativa del proceso de Administración de Datos, realizando un rol de verificador de puntos críticos que permitan demostrar la transparencia en el manejo de datos. En organizaciones maduras en el manejo de datos, los Oficiales de Seguridad son los responsables de asignar y monitorear los permisos de acceso a los datos. Esto garantiza que cada función tiene los privilegios que necesita, que usuarios privilegiados no abusan de sus privilegios. De igual manera, se involucran ya sea a un Oficial de Seguridad o a un Oficial de Riesgos en el monitoreo de las bitácoras de auditoría de la bases de datos. Esta segregación de funciones sobre los datos, permite percibir un ambiente de alto control sobre los datos, especialmente cuando al descubrir hallazgos, se ven todos como parte de un mismo equipo que trabaja precisamente para identificar comportamientos anómalos en la gestión de datos.
El Método de Gestión de las Tecnologías de la Información.
Muchas veces veo en las organizaciones al personal de Tecnologías de la Información realizando un tareismo infructuoso, que no deja valor para la organización, ni satisfacción para el profesional de TI que desempeña las tareas. Siempre existen cosas urgentes que hacer, tareas que eran para ayer y no se han concluido, próximos proyectos que se prevé no se terminarán a tiempo, muchas dudas en el significado de cada tarea para todo el conjunto de servicios de TI. También veo a Gerentes de TI que se aferran a la idea de que las cosas mejorarán cuando se realice un próximo proyecto de implementación de ITIL o COBIT o cualquier estándar similar, para lo cual se ha solicitado presupuesto y tiempo, desgraciadamente medido en meses y a veces hasta años. Es impresionante el ver como las soluciones de Gestión de TI se plantean como proyectos, cuando la Gestión de TI es un proceso continuo, sujeto a mejora continua, que debe de visualizarse como una práctica común en las operaciones diarias de TI. Me parecería que a la Gestión de TI le está pasando lo mismo que le pasaba a la Gestión de la Calidad en las décadas de los 60 a los 90. Después de la revolución industrial, cuando la producción en masa se hizo común, salieron muchas teorías sobre como administrar la producción. Una de ellas fue la del Control Estadístico de la Calidad. Bajo este enfoque, la Gestión de la Producción dedicaba esfuerzos a capturar datos estadísticos de los errores, o productos fabricados con desperfectos, para ponerse como meta crear procesos de producción que redujeran el porcentaje de error anterior. Este enfoque originaba en primer lugar, ciclos infructuosos de reducción en el porcentaje de errores, para luego volver a los valores iniciales y a veces hasta sobrepasarlos. En todo caso, sea un porcentaje mayor o menor de producción con errores, era producción perdida, trabajo perdido y recursos no recuperables. A partir de los años 90, la cultura japonesa nos heredo los círculos de calidad. Bajo esta filosofía, el mismo trabajador es responsable de decir porque no se trabaja con calidad y de definir las recomendaciones para evitar los problemas que originan el producir con errores. Comparto una frase que me impacto bastante: “Es mejor medir dos veces y cortar una”. Pequeño detalle. Pero una gran realidad de los ambientes de producción, en el que gran parte del desperdicio se debe a fallos en la tarea de medición.
Pues bien, mi opinión es que al igual que los procesos de calidad modernos, la Gestión de TI debe de practicarse desde el día uno. Identificando las causas que están originando que no se avance en el objetivo de tener una coordinación adecuada entre las Tecnologías de la Información y el negocio. Creando pequeñas tareas que tengan problemas únicos a resolver y no permitiendo que los errores se cometan dos veces. Revisando el resultado de las decisiones tomadas y estando listos a resolver el siguiente problema. Este método de gestión de las TI seguramente hará funcionar mejor el soporte que las Tecnologías de la Información proporcionan al negocio, de tal manera que en el mediano plazo se perciban los beneficios y se ordene la Gestión de TI.
El uso de Open Source como fuente de reducción de la inversión de TI.
Revisando el tema de costos de TI, uno llega a pensar en Open Source como una opción al incremento de costos. Bueno, lo es. Este movimiento, que comenzó ya hace muchos años, resulta que ha madurado muchísimo, ha soportado estándares en muchas áreas del desarrollo de la computación y lo mejor de todo ha creado productos que se convierten en excelentes soluciones a un costo muy bajo para resolver problemas que de otra forma requerirían de una inversión considerable. Tomemos como ejemplo, la computación de escritorio. Anoche, mientras preparaba una solución GIS, con software open Source, por supuesto, me encontré que la aplicación utilizaba datos en el formato dbf. Eso tradicionalmente no ha sido un problema para Excel. Pero en la versión de 2010, esta funcionalidad ha sido removida del Excel. Por supuesto, si uno es un Power User y tiene la versión profesional de Microsoft Office, puede lograr su objetivo de crear datos en formato dbf a través de crear una tabla de Access importando el archivo de Excel y luego importarlo en formato dbase. Punto resuelto. Pero si no tengo esta versión y sobre todo, si los datos van a ser manipulados por personal que no necesita una versión profesional de Microsoft Office, la opción de utilizar Apache Open Office resuelve este problema a un costo cercano a cero. Es así porque siempre hay costos adicionales a los de la adquisición del software cuando implementamos un producto. La curva de aprendizaje del usuario, el soporte, la donación que aportamos por utilizar este software tan útil sin el problema de pagar una factura para instalarlo. En serio, cada vez es más la gente que realiza aportaciones a estas fundaciones como un medio de apoyar y de retribuir el buen trabajo que desarrollan, ayudando a crear un mercado más competitivo y con más opciones. Si lo vemos desde el punto de vista empresarial y tenemos que proporcionar un software de oficina a un costo promedio de $200 por usuario, si tengo 50 usuarios, la factura total a pagar asciende a $10,000.00. Eso hace difícil la decisión entre el usar Open Source o no. Adicionalmente, Open Source es más seguro que la opción utilizada por muchos de utilizar copias pirateadas, que incluso pueden llegar a dañar los “activos de información” contenidos en las máquinas en las que se instalan. Esto representaría un costo que bien puede medirse más que en valor económico, en el impacto de perder y rehacer información valiosa. Este pequeño ejercicio nos deja un análisis económico básico. Lo sorprendente es que en muchas más áreas, el Open Source ha creado productos de software que proporcionan un nivel satisfactorio de desempeño, que bien vale la pena evaluar las opciones disponibles antes de realizar una implementación de software. Con esto, la Gerencia de TI podrá proveer servicios mientras realiza ahorros evaluados en miles de dólares, lo cual no debe de ser despreciable para ninguna organización.
Los Procesos de Gestión de TI y la Gestión del Personal.
Personalmente opino que el éxito de los Gerentes de TI radica en la selección adecuada y oportuna de los procesos de gestión de TI que debe de implementar. Aunque la realidad de nuestras empresas salvadoreñas y de la región centroamericana lleva muchas veces a asumir las Gerencias de TI con una gran cantidad de “puntos pendientes” que tienen que ser superados, la selección de procesos obliga a los Gerentes de TI a ganar la capacidad de superar la demanda de cosas urgentes que la organización le requiere, a través de la identificación de procesos que deben de ser creados o mejorados para resolver definitivamente los problemas de TI.
Si hablamos de comunes denominadores en la Gestión de TI en la empresa salvadoreña, uno es que no ha existido mayor organización a través de un enfoque de procesos en la praxis de la industria. Esto tiene que deberse a la forma en la que la Educación Universitaria ha llegado a los profesionales de TI. Los profesionales de TI aprenden a desarrollar software, a realizar análisis de sistemas, a administrar redes y una gran variedad de temas que rondan el área técnica de TI. El verdadero problema es que no importa cuantos sistemas e infraestructura tecnológica tenga una empresa, ni el nivel de inversión realizado, si no implementamos procesos de gestión de TI, la función de TI se desarrollará de una forma muy lenta, con ciclos que obliguen a rehacer cosas, con muestras claras de no ser eficientes ni eficaces. Esto nos plantea dos problemas: por un lado, la formación de profesionales de TI ha sido deficiente en cuanto a enseñar a gestionar la TI; por otro, los modelos de Gestión de TI evolucionan rápido, igual que la tecnología, obligando a una renovación constante de conocimientos por parte de los profesionales de TI que tienen bajo su responsabilidad gerenciar el soporte de las Tecnologías de la Información en una organización.
Similar a la discusión presentada sobre la aplicación de estándares, existen marcos de referencia (frameworks) que les proporcionan un horizonte de planeación a los Gerentes de TI. Si tomamos el ejemplo de COBIT, en su versión 5, proporciona un listado de 32 procesos de Gestión de TI, que pueden implementarse para realizar una gestión óptima de la función de TI. Si le hemos seguido la pista al desarrollo de COBIT, sabremos que en la versión 4.1 eran 34 procesos. La disminución se debe a que COBIT 5, en su versión 5, ya toma en cuenta el Gobierno de TI, que no es responsabilidad exclusiva de los Gerentes de TI, sino que obliga a la Alta Dirección a ser una parte activa de la función de TI, incorporando 5 procesos adicionales de Gobierno de TI. Pero si hablamos a nivel de Gerencia, existen 32 procesos de los cuales se tiene que priorizar su implementación con el fin de mejorar la gestión de TI de una manera programada. Los procesos están organizados a través de dominios, de alguna forma llevan un orden lógico de desarrollo a través de fases de planeación, implementación, ejecución y evaluación de la función de TI.
El verdadero arte de la implementación de los procesos de TI es el hacerlo en el 90% de los casos, con el personal existente. Debido a las limitaciones de conocimiento expresadas anteriormente, los profesionales de TI de todos los niveles, tienden a visualizar como difícil la implementación de procesos de trabajo más estructurados, que los obliguen a llevar controles que son comunes en otras áreas. Esto lleva a la excusa de que se necesita un responsable de los procesos de gestión de TI, cuando esta responsabilidad es del Gerente de TI, que tiene que modificar los manuales de puestos de todos los miembros del departamento de TI para acomodar las funciones a los procesos que se implementen. Esto puede llevar a temas de carga de trabajo y la percepción de que se están otorgando más funciones al personal. Sin embargo, cuando el departamento de TI no realiza su trabajo a satisfacción de la organización todo el personal puede tener consecuencias, por lo cual, un proceso de implementación de procesos de gestión de TI debe de promocionarse como la forma de trabajo más organizada y el camino a seguir para mejorar el ambiente laboral del personal de TI, haciéndolo más profesional, asimilando y poniendo en práctica conocimientos que han surgido en los últimos años sobre la Gestión de TI. La implementación de procesos es en definitiva una forma de crecimiento profesional para el personal de TI. Es importante conocer que en las organizaciones que han implementado frameworks como COBIT, el personal de TI pasa a tener un mejor desempeño, logrando una mejor imagen, menores niveles de stress laboral y hasta el logro de bonos.
Aplicación de Estándares de TI
Es común, más de lo que la gente quiere admitir, que profesionales de TI tengan problemas a la hora de buscar una ruta práctica para implementar estándares. Una raíz de este problema se basa en la incomprensión completa del término, confusión con otros términos como políticas y procedimientos y la decisión o el conocimiento de qué poner en cada tipo de documento. En esta ocasión nos enfocaremos en los estándares. Para poner un punto de referencia válido de comparación, se anexa el significado de la palabra “estándar”, de acuerdo a la Real Academia Española. Mi experiencia como Ingeniero Industrial, me dejo saber hace mucho tiempo que los estándares en buen español son “normas” que se deben cumplir en orden a seguir un acuerdo común logrado sobre una forma de resolver un problema a través del trabajo de organizaciones que se dedican a la identificación, construcción, discusión y divulgación de estos acuerdos o normas. Esta es una labor importante para todas las áreas del conocimiento, no solo para las tecnologías de la información. Los estándares son los que permiten que al construir o hacer productos, estos tengan una referencia común que permita garantizar que tienen las características requeridas y que podrán operar con otros productos. Por ejemplo, la gasolina tiene que cumplir con un estándar de producción para garantizar que puede operar con cualquier marca de vehículo. Este es un ejemplo de interoperabilidad, que permite visualizar fácilmente la importancia de un estándar y como funciona, dado que sin importar quién fabricó la gasolina, el seguimiento del estándar de fabricación y de las características del producto final, las gasolinas de diferentes productores cumplen su función con un nivel de variabilidad muy pequeño. Esto es, hay un margen de tolerancia, aún en la industria, para la aplicación de estándares.
Definición de «estandar». Fuente: Sitio web de la Real Academia de la Lengua Española.
Cuando se aplican estándares a servicios o productos intangibles, como el software, el tono ha sido el buscar la unificación de diferentes teorías de conocimiento, a efectos de cerrar una discusión que sería muy extensa, dado que cada fabricante puede proporcionar su versión de “la mejor práctica a seguir”, haciendo imposible para los tomadores de decisiones tener una garantía mínima de que en la organización se está siguiendo una práctica adecuada. Los estándares en el área de las Tecnologías de la Información proporcionan los requisitos mínimos que se deben de cumplir para garantizar que se realiza una determinada función o se presta un servicio con una variabilidad muy pequeña respecto de las mejores prácticas. Esto garantiza a la Alta Dirección, que la función de TI se desempeña de una manera aceptable, conforme al conocimiento actual.
Existen estándares para todas las áreas de las Tecnologías de la Información, tanto en hardware, como en software, como en los procesos de gestión. En nuestro medio, deberíamos de estar conscientes de los estándares relacionados con la gestión de TI, para que al momento de resolver un problema, la solución siga un patrón común, que consiste en aprender qué dice el estándar que hay que considerar, evaluar su adopción completa o parcial, de acuerdo a las condiciones específicas de la organización, su tamaño, objetivos, apetito de riesgo, etc. Definir los elementos del estándar que se implementarán y proceder a su aplicación. Esto último es necesario porque en los temas de gestión de TI no todas las organizaciones necesitan aplicar un estándar completo para resolver un problema. Hay que entender que la definición de un estándar de TI, visto desde un entorno nacional, y a veces mundial, debe de considerar elementos que son necesarios en grandes corporaciones. La práctica sana es acotar el estándar aplicado en una organización para enfocar los esfuerzos en esas partes del estándar que garantizan la obtención de los beneficios esperados. Esto permite resolver el problema con el mínimo de esfuerzo y dejar un camino establecido para la mejora continua, a partir de la implementación de más partes del estándar.
Como conclusión, un Gerente de TI debería de acostumbrarse a decir ante la Alta Dirección cosas como “Se ha realizado un Plan de Seguridad, basado en la norma ISO/IEC 27001”. Este tipo de declaraciones le proporciona mayor validez a su trabajo y seguramente mejores resultados.
¡Terremoto en Costa Rica! Ayer se probaron los Planes de Contingencia Tecnológica.
No cabe duda que los fenómenos naturales que causan desastres suceden tarde o temprano. Me parece que esa parte de la realidad es conocida y en las organizaciones se espera que suceda lo más tarde posible, lo suficiente como para estar preparados para afrontar la contingencia. Por supuesto, ante un desastre natural del tipo que aconteció ayer en Costa Rica, lo primero es salvaguardar las vidas humanas, la seguridad de la integridad física de las personas. Pero posteriormente al evento, en momentos en los que aún se está sufriendo la experiencia de pasar por el evento, hay que asegurar que los activos de la organización serán protegidos. Leía la noticia sobre como algunas agencias bancarias cerraban “por precaución” y me preguntaba si esa era una medida ya calculada, “paso uno del plan de contingencia tecnológica en caso de terremoto”. Otras noticias decían que las comunicaciones habían tenido problemas en la primera hora posterior al evento. Esto es un impacto en las comunicaciones, que bien podría haber dejado partes de la red de datos de una organización sin acceso. “Paso número 2”, definir el estado de funcionalidad después del evento catastrófico. La verdad es que en esos momentos las decisiones tienen que ser bien medidas. El Gerente del Proceso de Contingencia o el Líder de Contingencia tiene primero que buscar la información y si la obtiene, tomar la mejor decisión a partir de lo que sabe. Si no la obtiene, aún tendrá que tomar la decisión de qué hacer, pero con un margen de error más grande.
Cuando se diseñan los Planes de Contingencia, siempre es bien difícil hacer entender al personal de una organización que hay que pensar en los escenarios de un evento que obligue a la activación del Plan de Contingencia. Por ejemplo, después de un terremoto, podría ser que se cuenten con los empleados claves. En ese escenario, ellos realizarán las actividades claves de recuperación ejecutando los roles que normalmente desempeñan. Escenario 2, no está disponible un empleado clave por las mismas causas del evento. Este escenario obliga a pensar de antemano en la persona, o personas en una cadena de sucesión, que retomarían sus funciones. Este escenario obliga a crear también relaciones de comunicación entre los funcionarios claves y sus sucesores en caso de contingencia. Obliga a establecer capacitaciones para los sucesores. Obliga a revisar que la documentación de los procesos este clara y actualizada, así como obliga a la lectura por parte de los sucesores, quienes podrían incluso hacer observaciones que mejoren la documentación existente. Esos escenarios y muchos más, son los que se tiene que pensar de antemano cuando se está creando un Plan de Contingencia Tecnológica. Escenarios con sus consecuencias en términos de personas involucradas, conocimiento identificado como crítico, capacitaciones y mejor documentación.
Quizá el principal problema del personal en las organizaciones es la falta de imaginación. Siempre la usamos para imaginar lo mejor, por lo que imaginar que sucede algo malo, de carácter catastrófico, nos hace dudar de cuales serían los escenarios de un evento catastrófico. La recomendación es: ¿Tiene su organización un Plan de Contingencia para afrontar estos escenarios? Si la respuesta es no, tienen trabajo y ojalá el tiempo para hacerlo sea menor que lo que falta para el siguiente evento catastrófico.
Planificar la Continuidad de los Negocios.
El término Continuidad de Negocios pasa a tener un significado inmenso cuando las condiciones existentes no permiten hacer negocios de manera normal. Cuando no podemos llegar a los clientes, o los clientes no pueden llegar a nosotros. En momentos de crisis, por situaciones totalmente ajenas a la organización, que obliga a parar operaciones, es recomendable tener un Plan de Continuidad de Negocios, que permita manejar la situación sin improvisar, a partir de medidas bien pensadas que garanticen la imagen, la atención al cliente y lo más importante, la constante generación de ingresos.
La generación de ingresos parece ser el factor de mayor peso a la hora de decidir implementar un programa de Continuidad de Negocios. Por esta razón, las normativas de riesgos operativos para el sector financiero siempre incluyen artículos relacionados con el mandato de realizar la planificación de la Continuidad de Negocios. En El Salvador, la Norma para la Gestión del Riesgo Operacional de las Entidades Financieras, menciona este tema desde varios puntos de vista. Uno es como una responsabilidad de los entes de Gobierno Corporativo: la junta directiva, el comité de riesgo, la alta gerencia y la unidad de riesgos. Luego, en el artículo 16 consigna el mandato de implementar un “Sistema de Gestión de la Continuidad”, explicando incluso las fases que debe de incluirse en el cumplimiento de este artículo. Las fases son típicas de lo que explican las normas relacionadas, como la BS25999, que prácticamente hacen de la Continuidad del Negocio un proceso más de la Gestión Empresarial, recomendando que exista una estructura formal de responsabilidad, tiempos específicos para revisar las necesidades de continuidad de negocios, la definición específica de planes de contingencia, la divulgación a toda la organización y muy importante, la prueba de los planes de contingencia.
Las empresas al momento de considerar la inclusión del Proceso de Gestión de Continuidad del Negocio en su dinámica de gestión empresarial, deben de considerar la importancia que tiene para su salud financiera la continuidad en la generación de ingresos. Este es el factor que decide si se hace o no una iniciativa de este tipo. Un primer paso debería de ser realizar una evaluación del impacto que tiene el cese de operaciones en todas las áreas de la organización. Este simple ejercicio proporcionaría los datos para definir el tipo de Gestión de la Continuidad que se necesita. El análisis de impacto establece el costo de dejar de operar por lapsos de tiempo considerados en función del tipo de empresa, pudiendo estos ser de horas, días o semanas. Este costo siempre estará reflejado como un costo de oportunidad por el ingreso no generado, las pérdidas incurridas por faltar al cumplimiento de un servicio y los costos de retornar a las operaciones. Factores secundarios a considerar incluyen el mantenimiento de la competitividad, respecto de empresas similares que hayan implementado ya esta función, así como la imagen de la empresa ante los ojos del cliente.
Como efecto secundario de la Planificación de la Continuidad de Negocios, las operaciones diarias se verían beneficiadas de mejoras que prevean la no interrupción de procesos, dado que al analizar las operaciones, surgen normalmente propuestas de mejora que permiten crear procesos más confiables, más robustos, que se adelantan a los eventos de falla y tienen ya implementados los caminos alternos para evitar el cese de operaciones.
Gestión y Auditoría de TI 