¿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)

  1. Define qué dato es crítico: pedidos, pagos, inventario, historias clínicas, tickets, etc.
  2. Pregunta:
    1. Si pierdo la información de las últimas X horas, ¿puedo reconstruirla? ¿Cuánto me cuesta?
  3. 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.