Eviten estos 10 errores comunes en los análisis de impacto al negocio (BIA)

Lista de verificación de los 10 errores más comunes para el análisis de impacto al negocio:

1. Considerar el impacto de las aplicaciones ininterrumpidas, no de las funciones de negocio: Lo que impulsa un análisis de impacto al negocio, es el negocio. La primera cuestión que necesita abordarse es cuál será el impacto en toda la organización si no se puede realizar una función de negocios. La segunda cuestión es de cuáles aplicaciones depende esa función.

2. Considerar las aplicaciones en forma aislada: Si bien los usuarios de negocios conocen cuáles son las aplicaciones de las que dependen, a menudo no saben en qué otras aplicaciones o infraestructura se basan aquéllas. Cuando se tenga que determinar la importancia relativa de las aplicaciones, el analista necesita comprender la totalidad del ambiente de TI: servidores, almacenamiento, red, infraestructura y el portafolio de aplicaciones en conjunto.

3. Prestar muy poca atención al impacto financiero: No debería preguntarse, “si la aplicación X no pudiera ejecutarse, ¿cuánto dinero se perdería?”. Eso plantea muchas otras preguntas, tales como: ¿Se podría recuperar las pérdidas cuando se restaure el sistema? ¿Podría la caída del sistema causar la pérdida de clientes, al igual que de ventas? ¿Cuántas pérdidas pueden atribuirse a una aplicación específica? Al realizar un BIA, la información financiera generalmente se recolecta, y luego no se utiliza al determinar los requisitos de recuperación, porque es muy complicado. Debería considerar el impacto de pérdidas y ganancias de una interrupción prolongada del sistema, así como el capital y los costos operativos que conllevaría la reconstrucción.

4. Prestar demasiada atención al impacto financiero: Hay otros impactos además de las pérdidas financieras que pueden ser mucho más importantes para la alta dirección. El efecto sobre la reputación y la retención de clientes podría pesar más en su mente. Por otra parte, muchos gerentes no entienden completamente cómo encajan sus funciones en el modelo de negocios de su compañía. Así que ellos atribuyen la totalidad del riesgo financiero a sus propias aplicaciones, en lugar de considerar todo el negocio.

5. No distinguir aplicaciones empresariales: Algunas aplicaciones son más importantes que otras, ya que sirven a la empresa en su conjunto. Pero no hay ningún gerente que pueda indicar la importancia global de esas aplicaciones. Sin embargo, una aplicación que sirve para una sola función de negocios, o que sirve a muchas funciones en diferentes formas, podría no ser notada fácilmente. Hay algunas aplicaciones, como los sistemas de planeación de recursos corporativos (ERP) o los de manejo de relaciones con los clientes (CRM), cuyo impacto es evidente. Pero hay otros (como soporte legal o manejo de documentos) que podrían pasar relativamente desapercibidos.

6. No reconocer aplicaciones de centro de datos: Algunas aplicaciones no tienen usuarios de negocios. Estas aplicaciones incluyen los sistemas operativos, los sistemas de manejo de bases de datos y las herramientas de centro de datos, que hacen posible el funcionamiento de las aplicaciones de negocios. Es fácil decir que toda la infraestructura debe ser recuperada antes que todas las aplicaciones, ¿pero un sistema operativo, en un oscuro servidor, que realiza análisis debería ser recuperado antes que los sistemas de crédito, comercio o de inventario?

7. Confundir una evaluación de riesgo con un análisis de impacto al negocio: Una evaluación de riesgo determina qué podría causar una caída del sistema; un análisis del impacto al negocio muestra los efectos que tendría esta caída si realmente ocurriera. Ha habido demasiados eventos inverosímiles en los últimos años para llegar a confundir estos términos. El problema radica en las consecuencias resultantes de las interrupciones de duración variable, independientemente de la causalidad.

8. Confundir la aceptación del riesgo con un análisis de impacto al negocio: Si un gerente de negocios está dispuesto a tomar el riesgo de que su aplicación no esté disponible, eso no significa que no es necesario determinar el impacto global. Generalmente, los gerentes no quieren perder tiempo en el proceso de BIA, así que toman el camino fácil. Sin embargo, este es un enfoque arriesgado, y muchos gerentes no se dan cuenta del gran riesgo que están tomando. Una cosa es que los gerentes acepten el riesgo de sus propias aplicaciones, y otra muy distinta arriesgar a toda la compañía.

9. Predeterminar los resultados del BIA: Algunas veces el resultado de un análisis parece obvio para los gerentes, así que automáticamente asumen la respuesta sin pasar por todo el proceso de BIA. Los supuestos pueden producir resultados correctos 80% de las veces, pero eso significa que 20% del tiempo están equivocados. En otras palabras, una de cada cinco funciones de negocios o aplicaciones está analizada de manera inexacta. El impacto podría manifestarse cuando ocurra un desastre, y para entonces será muy tarde.

10. No respaldar un resultado de BIA: Un gerente puede optar por subestimar los impactos financiero, operativo o reputacional que puede causar que sus aplicaciones no estén disponibles, debido al costo de recuperación percibido. De todos los diez errores aquí listados, este es el más insidioso, porque intencionalmente socava la exposición general de las necesidades de recuperación que un BIA pretende producir. Es entendible que los gerentes puedan estar más preocupados por el presupuesto de hoy que por un incidente que podría (o no) ocurrir en el futuro, pero están poniendo una carga de riesgo potencialmente intolerable en la empresa.

Haciendo un adecuado análisis del impacto al negocio

En general, debería realizar sus BIA con una mente abierta y seguir los hechos dondequiera que lo lleven. Los prejuicios existentes podrían quedar destrozados, pero si los prejuicios fueran confiables no habría necesidad de hacer una lista de verificación para su análisis de impacto al negocio. En demasiadas organizaciones, el llamado análisis de impacto al negocio para los sistemas de información se elabora en una rápida reunión entre unos pocos gerentes de TI.

Un plan de recuperación de desastres para TI es un subconjunto del plan de continuidad de negocios, y el carácter crítico de una aplicación depende de qué tan crítica es la función de negocios (o las funciones de negocios) que dependen de ella. Las funciones de negocios de cualquier organización son complejas e interdependientes. En las grandes compañías, podrían estar tan entrelazadas que comprender el impacto relativo de una frente otra es una labor titánica. Pero es un esfuerzo que vale la pena, no solo para que la alta gerencia pueda invertir en recuperación, sino también por el entendimiento que les da sobre las complejidades de las compañías que manejan.

Sobre el autor: Steven Ross es Director de Risk Masters Inc. y tiene una certificación como Master Business Continuity Professional (MBCP). Es un especialista en manejo de continuidad de negocios, manejo de crisis y planeación de recuperación de desastres de TI. Es editor de la serie “Seguridad en el e-Commerce”, y autor de varios libros en la serie, incluyendo “Seguridad en el Comercio Electrónico: Planeación de Continuidad de Negocios”.