Cuando una empresa habla de continuidad operacional, muchas veces se traba en el mismo error:
“Todo es crítico.”
Y si todo es crítico, al final no priorizas nada.
Y cuando llega un incidente real (caída de sistemas, corte de luz, ausentismo, proveedor), la empresa improvisa y decide en pánico.
La continuidad operacional se construye al revés:
- primero defines qué no puede parar
- luego defines cuánto tiempo puedes aguantar
- y recién después armas estrategias y checklists
Eso se llama BIA (Business Impact Analysis, Análisis de Impacto al Negocio).
Aquí lo haremos en versión simplificada, ideal para pymes y equipos que quieren hacerlo bien sin volverse técnicos.
El error típico: creer que todo es crítico (y por qué te mata)
“Todo es importante” = sin prioridad en crisis
En una crisis, no hay tiempo para debatir 2 horas.
Si no existe una lista clara de procesos críticos:
- el equipo se divide (“lo mío es más urgente”)
- el comité de crisis se paraliza
- se pierde tiempo en lo secundario
- se dejan caer funciones vitales (caja, despacho, atención, etc.)
Enfoque correcto: priorizar por impacto y tiempo
La clave no es “qué me gusta más”, es:
- impacto real (plata, clientes, cumplimiento, seguridad)
- y tiempo (en cuántas horas se vuelve grave)
Qué es un BIA (sin tecnicismos)
Un BIA responde 3 preguntas:
- ¿Qué procesos no pueden parar?
- ¿Qué pasa si paran? (impacto)
- ¿Cuánto tiempo puedes aguantar antes de perder demasiado? (umbral)
Impacto por hora/día (lo que sí importa)
No necesitas una fórmula perfecta. Solo necesitas clasificar impactos típicos:
- Ventas/caja: ¿dejas de vender? ¿se corta la facturación?
- Clientes: ¿se atrasan entregas? ¿suben reclamos?
- Cumplimiento: ¿incumples contratos, normas, obligaciones?
- Seguridad: ¿se expone gente, activos, información?
- Operación: ¿se acumula trabajo imposible de recuperar?
Umbrales simples (2h / 8h / 24h / 72h)
Esta escala funciona muy bien en pymes porque es concreta:
- 2 horas: se pone feo al tiro (ventas/operación)
- 8 horas: aguantas un turno, pero al final del día duele
- 24 horas: aguantas un día, pero al segundo día explota
- 72 horas: aguantas, pero afecta reputación y backlog
La pregunta no es “¿puede parar?”.
Es “¿cuánto aguanta antes de que el daño sea irreparable o muy caro?”.
RTO y RPO en simple (cómo definirlos sin volverte TI)
Estos conceptos se usan mucho en continuidad y suenan técnicos, pero son simples.
RTO: tiempo máximo para recuperar
RTO (Recovery Time Objective) = “máximo tiempo aceptable para volver a operar”.
Ejemplo:
- Proceso: despacho
- RTO: 8 horas (si no despachamos en el día, queda la escoba)
RPO: pérdida máxima de datos tolerable (si aplica)
RPO (Recovery Point Objective) = “cuánta información puedo perder sin morir”.
Ejemplo:
- ventas registradas
- RPO: 1 hora (no puedo perder más de 1 hora de ventas)
Si tu empresa no depende mucho de datos, el RPO puede ser “manual” o “casi no aplica”.
Pero si vendes online, facturas o manejas inventario digital, el RPO importa.
Plantilla práctica para mapear procesos críticos (lista + 5 preguntas)
Aquí va la plantilla base. Te recomiendo hacerla en una planilla.
Paso 1: lista procesos (sin complicarte)
Ejemplos comunes:
- ventas/pedidos
- pagos/facturación
- despacho/entrega
- atención al cliente
- compras/abastecimiento
- producción (si aplica)
- sueldos (mensual, pero crítico por fecha)
- TI básico (internet, sistema, acceso)
Paso 2: responde 5 preguntas por proceso
Para cada proceso:
- ¿Qué entrego? (output)
- ¿Qué pasa si se detiene? (impacto)
- ¿Cuánto aguanta? (2h/8h/24h/72h)
- ¿De qué depende? (persona, TI, proveedor, infraestructura)
- ¿Cuál es el mínimo viable? (plan B)
Ejemplo real (simple):
- Proceso: facturación
- Impacto: no entra caja / atraso contable
- Aguanta: 24h (pero en 48h duele)
- Depende: sistema + persona clave
- Mínimo viable: facturar manual 1 día + planilla + respaldo
Paso 3: mapa de dependencias (para detectar puntos únicos de falla)
Marca dependencias por color:
- Persona clave
- TI / sistema
- Proveedor
- Infraestructura
Si un proceso crítico depende de una sola persona o proveedor, tienes un punto único de falla.
Cómo decidir “qué es crítico” (sin discusión eterna)
Usa una regla simple:
Un proceso es crítico si cumple 2 de estos 3:
- Impacto alto (plata/clientes/cumplimiento/seguridad)
- Aguanta poco (2h u 8h)
- No hay plan B real
Con eso ya puedes priorizar con criterio.
De diagnóstico a acción: qué priorizar primero (quick wins de continuidad)
Una vez que tienes tu lista de críticos, no te vayas a escribir un plan gigante. Parte por quick wins:
Quick win 1: reducir puntos únicos de falla
- segunda persona entrenada
- manual corto de 1 página
- checklist
- claves/credenciales compartidas con control (no en la cabeza de uno)
Quick win 2: plan B operativo para 2–8 horas
- ventas manual temporal
- despacho con guía física
- atención por canal alternativo
- respaldo de datos básico
Quick win 3: comunicación y roles
- quién decide
- quién comunica
- quién registra en bitácora
Eso ya te sube continuidad sin burocracia.
Si quieres llevar este diagnóstico a un plan de continuidad completo (BCP base) con plantillas, roles, checklists, pruebas e indicadores, este curso te lo deja paso a paso sin improvisar:
Errores comunes (los que hacen que el BIA no sirva)
- Declarar “todo crítico”
- No poner umbrales de tiempo
- No mapear dependencias
- No definir mínimo viable (plan B)
- Hacerlo solo TI (cuando la continuidad es operación)
- No validar con quienes ejecutan
- Quedarse en diagnóstico sin acciones
Checklist (para hacer tu BIA simplificado hoy)
- Listé procesos principales
- Respondí las 5 preguntas por proceso
- Clasifiqué umbral 2h/8h/24h/72h
- Definí RTO (y RPO si aplica) para críticos
- Mapeé dependencias y puntos únicos de falla
- Elegí 3 quick wins para esta semana
Paso a paso (7 pasos) para definir procesos críticos
- Lista procesos
- Define impacto por proceso
- Define umbral de tiempo (2h/8h/24h/72h)
- Define RTO y RPO (si aplica)
- Mapea dependencias
- Selecciona procesos críticos (regla 2 de 3)
- Define mínimo viable + quick wins
FAQs
¿Esto sirve para empresas chicas?
Sí, especialmente. Mientras más chica la empresa, más puntos únicos de falla.
¿Qué hago si no tengo datos exactos?
Haz estimaciones por consenso con quienes operan. Mejor una estimación útil que ninguna.
¿RTO/RPO es solo para TI?
Se usa mucho en TI, pero el concepto aplica a cualquier proceso: cuánto puedes esperar para recuperar.
¿Cada cuánto se revisa el BIA?
Mínimo una vez al año o cuando cambie un proceso clave, proveedor crítico o sistema.
Cierre
La continuidad no parte con un documento, parte con una pregunta: ¿qué no puede parar?
Con un BIA simplificado puedes priorizar en serio y tomar decisiones con calma cuando llegue un incidente.
Si quieres construir el BCP base completo con plantillas, checklists, roles, pruebas e indicadores (sin prueba y error), revisa el curso aquí: