Análisis de Impacto al Negocio (BIA)
RTO, RPO, MTTR y MTBF: identificar procesos críticos y cuantificar el impacto de una interrupción
¿Qué es el BIA?
El Business Impact Analysis (BIA) es un proceso sistemático para identificar los procesos críticos del negocio, determinar el impacto de su interrupción y establecer los tiempos máximos de recuperación aceptables. Es el punto de partida de cualquier plan de continuidad de negocio (BCP).
Sin BIA, no se sabe qué recuperar primero tras un incidente. Un BIA mal hecho puede llevar a recuperar primero el servidor de correo cuando el proceso de pagos lleva parado 4 horas y cada hora supone 50.000€ en pérdidas.
Los Métricas Clave de Continuidad
RTO — Recovery Time Objective
Tiempo máximo aceptable para restaurar un servicio/proceso tras una interrupción.
El sistema de pagos tiene un RTO de 4 horas. Si lleva 4h parado, se ha superado el objetivo.
Lo define el negocio, no TI. El área de pagos dice "necesito volver en máximo 4 horas". TI diseña la arquitectura de recuperación para cumplirlo.
RPO — Recovery Point Objective
Máxima antigüedad de los datos que se puede aceptar perder en una recuperación.
RPO de 1 hora → máximo 1 hora de transacciones perdidas. Los backups deben ser frecuentes para cumplirlo.
Dicta la frecuencia de backups. RPO = 24h → backup diario. RPO = 1h → backup o replicación horaria. RPO = 0 → replicación síncrona en tiempo real.
MTTR — Mean Time To Repair
Tiempo medio que tarda el equipo en restaurar un sistema averiado. Métrica operativa histórica.
Si el equipo ha tardado 2h, 3h, 4h y 3h en los últimos 4 incidentes, MTTR = (2+3+4+3)/4 = 3 horas.
El MTTR debe ser menor que el RTO definido. Si MTTR > RTO, hay un gap que requiere mejoras de proceso o automatización.
MTBF — Mean Time Between Failures
Tiempo medio entre fallos de un componente o sistema. Indica la fiabilidad/disponibilidad esperada.
Un servidor con MTBF de 43.800 horas (5 años) falla estadísticamente una vez cada 5 años.
Disponibilidad = MTBF / (MTBF + MTTR). Para 99.9% ("3 nines") → máximo 8.76 horas de downtime al año.
Los "Nines" de Disponibilidad
| Disponibilidad | Downtime/año | Downtime/mes | Uso típico |
|---|---|---|---|
| 99% (2 nines) | 87.6 h | 7.3 h | Sistemas internos no críticos |
| 99.9% (3 nines) | 8.76 h | 43.8 min | Aplicaciones empresariales estándar |
| 99.99% (4 nines) | 52.6 min | 4.4 min | E-commerce, banca online |
| 99.999% (5 nines) | 5.26 min | 26 seg | Telecomunicaciones, infraestructura crítica |
Cómo Realizar un BIA
1. Identificar procesos de negocio
Entrevistar a responsables de cada área. Listar todos los procesos: ventas, operaciones, soporte, RRHH, contabilidad, TI...
2. Identificar dependencias
Para cada proceso, ¿qué sistemas TI necesita? ¿qué datos? ¿qué personal clave? ¿qué proveedores?
3. Cuantificar el impacto
Para cada proceso, ¿cuánto cuesta 1h de interrupción? (ventas perdidas + coste operativo + multas regulatorias + daño reputacional)
4. Definir RTO y RPO
El área de negocio define el tiempo máximo aceptable de interrupción (RTO) y pérdida de datos (RPO) para cada proceso.
5. Priorizar
Ordenar procesos por impacto/criticidad. Los procesos con mayor coste por hora de interrupción van primero en el BCP/DRP.
6. Documentar y revisar
El BIA es un documento vivo. Revisar anualmente y tras cambios mayores de negocio o tecnología.
Buenas Prácticas
El BIA lo dirigen los responsables de negocio, no TI. TI proporciona datos técnicos.
Expresar el impacto en términos monetarios: facilita la priorización y la justificación de inversión.
Separar el MAO (Maximum Acceptable Outage) del RTO: el RTO debe ser menor o igual al MAO.
Considerar impactos no financieros: daño reputacional, sanciones regulatorias, impacto en clientes.
Validar que la arquitectura técnica puede cumplir los RTOs definidos por el negocio.
Siguiente Paso
Aprende cómo diseñar un BCP y un Plan de Recuperación ante Desastres
BCP y Plan de Recuperación (DRP) →