Son las tres de la mañana, medio entorno está caído y en la llamada de emergencia hay seis personas. Cada una dice lo mismo con distintas palabras: lo mío va primero. Sin un criterio previo, gana quien grita más fuerte o quien tiene el puesto más alto —que casi nunca es lo mismo que lo que el negocio necesita de vuelta antes. El Análisis de Impacto al Negocio, o BIA por sus siglas en inglés, existe justo para que esa decisión ya esté tomada, en frío, mucho antes del desastre.
Qué es (y qué no es) un BIA
Un BIA es el ejercicio de medir qué le pasa al negocio, con el tiempo, cuando cada proceso deja de funcionar. No es un inventario de servidores ni una lista de "sistemas importantes" —porque si preguntas cuáles son importantes, la respuesta siempre es "todos". El BIA cambia la pregunta: no "¿qué tan importante es esto?" sino "¿cuánto nos duele, y cada hora que pasa cuánto más nos duele?". Esa segunda pregunta sí ordena, porque no todos los procesos duelen al mismo ritmo.
Los números que produce
Un BIA bien hecho entrega tres cosas, y las tres alimentan directo al plan de recuperación:
- Impacto en el tiempo: cuánto cuesta cada hora (o cada día) de caída de un proceso, en dinero, en cumplimiento, en reputación. Aquí es donde el ejercicio se vuelve concreto y a veces incómodo —y donde ayuda tener claro cuánto cuesta de verdad una hora sin sistemas.
- El MTD (máximo tiempo tolerable de caída): el punto a partir del cual el daño deja de ser recuperable —clientes que no vuelven, multas, contratos perdidos. De ese techo se derivan hacia abajo el RTO y el RPO de cada sistema, no al revés.
- El mapa de dependencias: qué necesita cada proceso para funcionar. El ERP no sirve sin su base de datos; la base de datos no arranca sin el directorio activo y el DNS; nada funciona sin red y energía.
Las dependencias mandan en el orden
Aquí está el detalle que la intuición ignora: el orden de recuperación no es la lista de procesos ordenada por importancia, es esa lista reordenada por dependencias. De nada sirve que "facturación" sea tu proceso número uno si facturación necesita la base de datos, que necesita el directorio activo, que necesita la red. Recuperas de abajo hacia arriba: primero los cimientos invisibles (red, DNS, identidad, almacenamiento), luego los sistemas que se apoyan en ellos. El BIA es lo que hace visible esa cadena antes de que la descubras a tropezones a las tres de la mañana.
Cómo se hace sin adivinar
Un BIA no se llena solo en una hoja de cálculo desde TI. Se construye hablando con quien vive cada proceso: ¿cuánto aguantan sin este sistema antes de que sea un problema serio?, ¿hay una forma manual de operar mientras tanto y por cuánto tiempo?, ¿qué otros procesos se caen si este se cae? TI aporta el mapa técnico de dependencias; el negocio aporta el costo real de estar detenido. El cruce de ambos es el BIA. Hacerlo desde un solo lado produce, otra vez, cifras inventadas —RTO y RPO que suenan razonables pero que nadie puede defender.
La pregunta que conviene hacerse
No es "¿qué sistemas tenemos que proteger?" —esa lista es infinita y no ayuda a decidir. Es: si mañana solo pudiéramos recuperar tres cosas en la primera hora, ¿cuáles serían, y por qué esas y no otras? Si el equipo no tiene una respuesta acordada y con números detrás, ese es exactamente el trabajo del BIA. Y es el trabajo que hay que hacer antes de comprar tecnología de recuperación: sin él, un DR site o un DRaaS se dimensionan a ciegas. Ayudar a levantar ese análisis —y a traducirlo en un DRP que se pueda ejecutar— es donde empieza un plan que sirve.