¿Cómo calcular RTO y RPO en un DRP?
Cuando una empresa habla de Continuidad de Negocio y entra en el tema de DRP (Plan de Recuperación ante Desastres), normalmente aparecen dos siglas que definen todo el presupuesto, la tecnología y el riesgo:
- RTO (Recovery Time Objective): tiempo máximo que el negocio puede estar caído.
- RPO (Recovery Point Objective): cantidad máxima de información que la empresa está dispuesta a perder (en tiempo).
Dicho simple:
- RTO = cuánto tiempo puedo estar sin operar
- RPO = cuánto tiempo de datos puedo perder
1) Antes de calcular: define qué procesos son “críticos”
No se calcula RTO/RPO “para toda la empresa” en una sola cifra. Se calcula por proceso o sistema clave, por ejemplo:
- Facturación y cartera
- ERP / inventario
- E-commerce / plataforma de pedidos
- Correo corporativo
- Atención al cliente / call center
- Nómina (por ventana de pago)
✅ Acción: lista los 5–10 procesos que más afectan ingresos, operación, cumplimiento o reputación.
📍Agenda una evaluación de continuidad
y define tus RTO/RPO con impacto real en ingresos y operación.
2) Cómo calcular RTO (en términos gerenciales)
El RTO se define con una pregunta brutalmente sencilla:
¿Cuánto tiempo puedo estar detenido antes de que el daño sea inaceptable?
Para calcularlo, estima el costo por hora de interrupción y define el punto de “dolor máximo”.
Fórmula gerencial práctica
Costo por hora de caída = (Ingresos por hora perdidos) + (Costos extra por hora) + (Penalidades por hora) + (Impacto reputacional estimado)
RTO será el tiempo máximo antes de superar un umbral que la empresa considera inaceptable.
Checklist para estimar el costo por hora
- Ventas no realizadas por hora (promedio real)
- Producción/operación detenida (costos fijos + desperdicio)
- Horas-hombre improductivas o re-procesos
- Multas o cláusulas contractuales (SLA)
- Impacto en clientes (cancelaciones / churn)
- Riesgo regulatorio (si aplica)
✅ Ejemplo rápido
Si tu empresa pierde aprox:
- 6.000.000 COP/h en ventas
- 1.500.000 COP/h en horas-hombre + operación detenida
Y además hay riesgo contractual de 10.000.000 COP si la caída supera 4 horas,
Entonces el gerente podría decir:
“Mi RTO objetivo debe ser menor a 4 horas” (porque después se dispara el impacto contractual).
👉 Resultado: RTO recomendado: 2–4 horas (dependiendo del margen de seguridad).
Descarga la plantilla de BIA + RTO/RPO
y prioriza tus procesos críticos en menos de 1 hora.
3) Cómo calcular RPO (lo que puedes perder sin quebrar el proceso)
El RPO responde a:
¿Cuál es el máximo de datos que puedo perder sin que el negocio colapse o se vuelva caótico?
Se mide en tiempo porque depende de cada cuánto cambian los datos.
Método simple para gerentes (por proceso/sistema)
- Define qué dato es crítico: pedidos, pagos, inventario, historias clínicas, tickets, etc.
- Pregunta:
- Si pierdo la información de las últimas X horas, ¿puedo reconstruirla? ¿Cuánto me cuesta?
- El RPO debe ser menor que esa X.
✅ Ejemplos muy típicos
- E-commerce / pedidos: RPO 5–15 min (perder pedidos es crítico)
- ERP / inventario: RPO 15–60 min (reconstrucción es costosa)
- Correo: RPO 1–4 h (depende del negocio)
- Nómina: RPO 4–24 h (si se maneja por lotes, puede tolerar más)
Preguntas clave para fijar RPO sin tecnicismos
- ¿Se puede reingresar manualmente lo perdido?
- ¿Cuánto tarda y cuántas personas requiere?
- ¿Existe registro alterno (pasarela de pagos, WhatsApp, formularios, logs)?
- ¿La pérdida afecta cumplimiento o auditoría?
👉 Si reconstruir 2 horas de datos implica 2 días de caos y reclamos, tu RPO no puede ser 2 horas.
4) Tabla rápida para decidir (útil en comité)
Usa esta lógica para clasificar cada sistema:
- Muy crítico (core del negocio): RTO 1–4 h | RPO 5–15 min
- Crítico (operación diaria): RTO 4–8 h | RPO 15–60 min
- Importante: RTO 8–24 h | RPO 4–12 h
- Soporte: RTO 24–72 h | RPO 12–24 h
(No es una regla universal, pero sirve para arrancar con criterio ejecutivo.)
5) El error más común: poner RTO/RPO “ideal” sin presupuesto real
RTO y RPO no son deseos. Son decisiones de negocio que implican costo:
- RTO muy bajo → requiere alta disponibilidad, redundancia, automatización
- RPO muy bajo → requiere backup continuo, replicación, arquitectura adecuada
✅ Recomendación gerencial:
Define RTO/RPO por niveles y prioriza el Top 20% de sistemas que sostienen el 80% del negocio.
Un DRP serio empieza por números, no por herramientas.
Si un gerente define RTO y RPO con base en impacto real (dinero, clientes, cumplimiento), el plan deja de ser “TI” y se vuelve estrategia de continuidad.
