En las últimas semanas vimos fallas que afectaron la vida cotidiana de millones de personas.
Pagos que no acreditan. Energía que desaparece. Plataformas críticas que quedan intermitentes.
No en una empresa. En varias. Al mismo tiempo. En múltiples países, incluso en regiones
Y cada vez que pasa, aparece la misma frase tranquilizadora:
“El plan de continuidad estaba en regla.”
Ese es el problema.
La continuidad no está fallando donde creemos
Hoy, en muchas organizaciones, el BCP y el DRP funcionan exactamente como fueron diseñados.
El inconveniente es que parecería que fueron diseñados para auditoría, no para operación real bajo estrés. Porque digo esto?
Porque se prueba el restore técnico.
Se cumplen RTO y RPO.
Se documenta el ejercicio.
Pero no se prueba lo esencial
El problema que casi nadie admite:
las pruebas están guionadas
En la mayoría de las organizaciones, los ejercicios de continuidad se hacen así:
- fecha avisada con semanas de anticipación
- todos los equipos sentados, alertas, “en modo simulacro”
- proveedores informados
- backlogs limpios
- presión cero
Eso no es una prueba. Es un ensayo teatral.
Se prueba el restore técnico.
Se cumplen RTO y RPO.
Se documenta el ejercicio.
Pero no se prueba lo esencial:
- si el cliente puede completar un journey crítico
- si los canales comunican algo coherente
- si atención al cliente puede responder
- si la conciliación posterior es viable
- si el negocio puede seguir operando, aunque sea degradado
En la vida real, nada de eso ocurre con gente preparada y tiempo para acomodarse.
Lo que una prueba real debería incomodar
Una prueba de continuidad válida debería generar, al menos, estas fricciones:
- decisiones con información incompleta
- equipos que no estaban “de guardia”
- dependencias externas que no responden
- clientes operando mientras algo falla
- tensión entre seguir vendiendo o frenar
Si no incomoda, no sirve.
El error de fondo
El error no es técnico.
Es cultural.
Se diseñan pruebas para:
- no exponer debilidades
- no generar ruido
- no incomodar a negocio
- no dejar evidencia incómoda
Y así se pierde el único valor del ejercicio: aprender antes del incidente real.
La diferencia entre cumplir y estar preparado
Cumplir es:
“Hicimos el test y pasó”
Estar preparado es:
“El test mostró cosas que nos obligaron a cambiar decisiones”
Si una prueba no deja hallazgos accionables, no fue una prueba, fue una certificación encubierta.
“Las organizaciones no fallan porque no prueban. Fallan porque prueban escenarios que nunca van a vivir.”
La brecha silenciosa que nadie quiere mirar
En casi todas las organizaciones que analizo veo el mismo patrón:
- El BIA declara procesos críticos que ya no reflejan cómo hoy se presta el servicio.
- El riesgo operacional y tecnológico identifica amenazas reales, pero las analiza en silos.
- El DRP prioriza sistemas, no servicios ni experiencias de cliente.
Cada pieza, por separado, es defendible.
Juntas, no conversan.
El BIA dice qué es crítico.
El riesgo dice qué puede fallar.
El DRP dice qué se levanta primero.
Pero nadie responde la pregunta incómoda:
“Si esto falla mañana a las 11 de la mañana, ¿qué vive el cliente y cómo seguimos operando?” Como impacta en tu reputación? El evento de caída del servicio en disponibilidad tiene un costo diferente si se cae 1 hora a si se cae 5 hs, lo midieron?… tengo mas de 50 preguntas aquí para hacerte
No tomes a la ligera esto que te estoy comentando, la brecha es bestial, crítica, dolorosa e ingobernable en el momento que se dé la contingencia. Te lo aseguro, mis canas tienes miles de ejemplos de historias que no deberían repetirse y te cuento que se repiten uno a uno.
A ver, solo uno te tiro. Supongamos que tu estrategia de contingencia está basada en una red MPLS donde conectas a todas las sucursales y centro de datos, que son de terceros, tus audítorías (no les hago doble click, pero automaticamente lo harás tu) dan ok. Que pasa si el corte supera las 4 hs?, todos los puntos de conexión de la contingencia de tu proveedor tienen los equipos electrogenos funcionales?. Uff si te contara…
Cuando cumplir no alcanza
He visto organizaciones donde:
- el DRP se ejecutó “con éxito”
- los sistemas estaban arriba
- pero los pagos quedaban pendientes
- los clientes no sabían qué estaba pasando
- el call center improvisaba
- la deuda operativa explotaba días después
Desde el cliente, eso es una caída total.
Desde el regulador, un riesgo operativo.
Desde el negocio, un daño reputacional innecesario.
Y sin embargo, en el comité se escucha:
“Pero el plan funcionó.”
No. Funcionó el papel. Falló la continuidad.
El error de diseño de fondo
La mayoría de los planes siguen respondiendo a una lógica vieja:
“Cómo recupero IT”
Cuando el mundo actual exige otra:
“Cómo sigo prestando servicio en condiciones anormales”
Eso implica aceptar algo que cuesta mucho:
- que no todo puede seguir funcionando
- que hay que decidir qué priorizar
- que operar degradado es mejor que no operar
- que la continuidad es una decisión de negocio, no solo de tecnología
Y eso requiere criterio senior. No checklist.
Lo que casi nadie está haciendo
Las organizaciones más maduras no tienen mejores documentos.
Tienen mejor integración.
- BIA construido sobre journeys reales, no procesos históricos.
- Riesgos mapeados por impacto en servicio, no solo por control.
- DRP diseñado por servicio crítico, con dependencias internas y externas explícitas.
- Modos degradados definidos antes del incidente, no durante.
- Comunicación, atención y conciliación sentadas en la misma mesa que IT.
No es más complejo.
Es más honesto.
Mi preocupación real
Mi preocupación no es técnica. Es estructural.
Estamos apoyando actividades críticas de la vida diaria en arquitecturas frágiles desde el punto de vista operativo, pero confortables desde el punto de vista documental.
Y eso genera una falsa sensación de control que se rompe siempre en el peor momento.
En industrias de alto impacto cotidiano, esto ya no es una debilidad metodológica.
Es riesgo sistémico.
Una reflexión final
La continuidad no se cae cuando falla un sistema.
Se cae cuando nadie está gobernando el servicio extremo a extremo.
Se cae cuando el BIA describe procesos que ya no representan la realidad del cliente.
Cuando el riesgo se analiza, pero no se traduce en decisiones operativas.
Cuando el DRP sabe levantar tecnología, pero no sabe sostener negocio bajo presión.
Ahí es donde hoy se juega la diferencia real:
entre organizaciones que resisten incidentes porque tomaron decisiones incómodas a tiempo,
y organizaciones que quedan expuestas aunque “hayan cumplido”.
Mi trabajo, cuando me convocan, no es escribir mejores planes.
Es conectar impacto en cliente, riesgo materializado y decisiones de operación real.
Sentar en la misma mesa a negocio, tecnología, riesgo y comunicación.
Y ayudar a definir, antes de la crisis, qué se prioriza, qué se degrada y quién decide.
Porque la continuidad no se audita.
Se gobierna.