"Plan de continuidad operacional" suena a algo que solo necesitan los bancos y las grandes corporaciones. En la práctica, es la respuesta a una pregunta muy simple: si hoy tu servidor principal falla, si un proveedor crítico se cae, si hay un corte de luz que dura dos días, ¿cuánto tarda tu empresa en volver a operar con normalidad?
El 70% de las pymes chilenas no tiene una respuesta clara a esa pregunta. No porque sea un proceso imposible ni caro: es que nadie les explicó por dónde empezar. Eso es lo que resuelve este artículo.
Qué es (y qué no es) un plan de continuidad
Un plan de continuidad operacional no es un documento de 200 páginas en PDF que nadie lee. Es un conjunto de procedimientos documentados que permiten a tu empresa seguir operando —o recuperar la operación rápidamente— cuando algo sale mal.
En el contexto TI específicamente, el plan responde tres preguntas:
- ¿Qué sistemas son críticos para operar? (Identificación de activos críticos)
- ¿Qué pasa si cada uno de esos sistemas falla? (Análisis de impacto)
- ¿Cómo los recuperamos y en cuánto tiempo? (Procedimientos de recuperación)
Los dos indicadores que toda empresa debería conocer
Antes de armar cualquier plan, hay que definir dos umbrales clave:
RTO (Recovery Time Objective): cuánto tiempo máximo puede estar un sistema caído antes de que el impacto sea inaceptable para el negocio. Para una tienda online puede ser 2 horas. Para una empresa de manufactura con pedidos automatizados puede ser 30 minutos. Para una oficina de arquitectura puede ser un día completo.
RPO (Recovery Point Objective): cuántos datos puedes permitirte perder. Si haces respaldo cada noche a medianoche y el servidor cae a las 5 PM del día siguiente, pierdes 17 horas de trabajo. ¿Es aceptable eso? Si no lo es, el respaldo debe ser más frecuente.
No hay valores "correctos" de RTO y RPO en abstracto: dependen de tu negocio. Una empresa con contratos de servicio con SLA tiene umbrales muy distintos a una empresa de servicios profesionales. Definirlos es el primer paso real del plan.
Paso a paso para armar el plan sin perderse
Paso 1: Inventario de sistemas críticos
Haz una lista de todos los sistemas y plataformas que usa tu empresa para operar: servidor de archivos, ERP o sistema contable, correo electrónico, CRM, plataforma de facturación electrónica, accesos remotos, herramientas de comunicación interna. Para cada uno, anota quién lo usa, qué pasa si no está disponible y cuánto tiempo máximo aguantarías sin él.
Paso 2: Clasificación por criticidad
No todos los sistemas son igual de urgentes. El sistema de facturación electrónica y el servidor de archivos compartidos probablemente son críticos. El servidor de impresión probablemente no lo es tanto. Clasifica en tres niveles: crítico (no puede estar caído más de X horas), importante (afecta la operación pero hay alternativas temporales) y secundario (puede esperar).
Paso 3: Procedimientos de recuperación documentados
Para cada sistema crítico, documenta: qué hacer exactamente si falla, quién es el responsable de ejecutarlo, cómo se valida que la recuperación fue exitosa y a quién se le comunica internamente. Que lo pueda ejecutar alguien que no sea el administrador de sistemas habitual, por si ese día él no está disponible.
Paso 4: Respaldos verificados con política 3-2-1
3 copias, 2 soportes distintos, 1 fuera de la ubicación principal (o en la nube). Y prueba de restauración al menos cada trimestre. Un respaldo que nunca se probó es un respaldo del que no sabes si funciona cuando lo necesitas.
Paso 5: Plan de comunicación interna
¿A quién se llama primero si cae el servidor a las 11 PM de un viernes? ¿Cómo se comunica al equipo que no habrá sistema hasta el lunes? ¿Hay un canal alternativo de comunicación si el correo corporativo está caído? Define esto antes de que pase.
Paso 6: Simulacro al menos una vez al año
Un plan que nunca se prueba es solo un documento. Los simulacros no tienen que ser drásticos: basta con declarar "ejercicio" y hacer la simulación de recuperar el servidor de archivos desde el respaldo mientras el equipo técnico sigue el procedimiento documentado. Vas a encontrar cosas que mejorar, y es mucho mejor encontrarlas en un ejercicio que en un incidente real.
El principal beneficio del plan de continuidad no es técnico: es saber que cuando algo falle —y algo siempre falla— el equipo sabe qué hacer y cuánto va a tardar. Eso vale mucho en términos de gestión de la presión bajo incidente.
¿Cuánto cuesta realmente?
El plan en sí no tiene costo de infraestructura: es trabajo de análisis y documentación. La inversión está en el tiempo del equipo TI para levantarlo y en eventuales mejoras a la infraestructura de respaldo que el análisis revele (muchas veces, el problema no es la tecnología sino que el respaldo no estaba configurado bien).
Lo que sí tiene costo es no tener el plan. Las empresas con planes de continuidad operacional sólidos se recuperan de incidentes en promedio tres veces más rápido. Eso es tiempo de operación, contratos cumplidos y reputación protegida.