Tecnología informa que la plataforma está disponible. Operaciones confirma que su proceso fue recuperado. El proveedor comunica que el servicio funciona normalmente y Continuidad verifica que el RTO fue cumplido.

Sin embargo, el cliente todavía no puede completar su operación ¿Cómo puede ocurrir?

Cada componente puede haberse recuperado individualmente y, aun así, el servicio continua interrumpido. Esta situación la hemos visto numerosas veces y expone uno de los cambios más importantes que plantea la resiliencia operativa: dejar de observar exclusivamente la continuidad de procesos, sistemas y áreas, para entender cómo todos ellos se combinan para entregar un servicio clave del negocio.

El cliente no consume procesos

Durante años hemos construido modelos de continuidad alrededor de procesos.

Realizamos el BIA. Identificamos procesos críticos. Definimos e identificamos el RTO y RPO. Asignamos estrategias de recuperación. Desarrollamos planes y probamos.

Todo esto continúa siendo necesario, pero existe una diferencia importante entre recuperar un proceso y mantener un servicio.

Un cliente que intenta realizar una transferencia no sabe cuántos procesos internos participan. Tampoco sabe qué aplicación, proveedor, base de datos, API o equipo operativo interviene. Simplemente espera que la transferencia funcione, por eso, desde la perspectiva de resiliencia operativa, la pregunta evoluciona de:

De ¿Recuperamos el proceso? a ¿Podemos continuar entregando el servicio dentro de una disrupción tolerable?

Un servicio crítico es una cadena

Por ejemplo, pensemos en pagos digitales. Para que el servicio funcione pueden intervenir:

• canales digitales;
• autenticación;
• procesamiento transaccional;
• bases de datos;
• infraestructura;
• telecomunicaciones;
• APIs;
• prevención de fraude;
• personas;
• proveedores;
• liquidación;
• atención al cliente.

La fortaleza individual de cada componente importa, pero la resiliencia depende de la cadena completa. Podemos tener una infraestructura redundante, extraordinariamente resiliente y fallar porque un proveedor externo no responde. Podemos tener dos centros de datos y descubrir que ambos dependen de la misma tecnología. Podemos recuperar la aplicación y encontrar que las operaciones necesitan una conciliación que todavía no está disponible.

La resiliencia del servicio está determinada por sus dependencias, no solamente por sus componentes individuales principales.

El mapa organizacional no siempre representa el riesgo

Las organizaciones suelen gestionarse verticalmente, pero cada área tiene responsables, indicadores y controles, pero los servicios funcionan horizontalmente.

Cuando ocurre una disrupción, el organigrama deja de ser una buena representación de cómo se propaga el impacto, por eso necesitamos mapear servicios de extremo a extremo.

Mapear resiliencia no significa hacer otro inventario

El objetivo no debería ser documentarlo absolutamente todo de nuevo, deberíamos comenzar por aquello cuya interrupción podría generar un impacto intolerable.

Para cada servicio considerado crítico necesitamos comprender:

Servicio → procesos → personas → tecnología → información → instalaciones → terceros → dependencias.

Y después formular una pregunta mucho más interesante: ¿Dónde puede romperse esta cadena?

Las interdependencias no identificadas suelen ser las más peligrosas

Muchas vulnerabilidades no aparecen durante la aplicación del BIA.

Por ejemplo, una aplicación tiene alta disponibilidad, pero depende de una API sin alternativa. Existe personal de respaldo, pero ambos especialistas trabajan desde la misma ubicación. Tenemos dos proveedores, pero ambos utilizan el mismo proveedor cloud. Existe un proceso manual, pero solamente soporta el 15 % del volumen habitual. Tenemos sitio alterno, pero la autenticación depende de un servicio central que también está afectado.

Individualmente, los componentes parecen resilientes pero cuando observamos sus interdependencias aparece otra realidad.

De RTO a tolerancia a la disrupción

El RTO continúa siendo importante, pero la resiliencia operativa introduce una perspectiva adicional: ¿Cuánto deterioro del servicio puede tolerar realmente la organización? No siempre necesitamos recuperar el 100 % inmediatamente.

Quizás durante una crisis podamos operar al 70 % de capacidad, con determinadas funcionalidades restringidas, priorizando clientes críticos, aplicando procedimientos manuales o suspendiendo temporalmente procedimientos secundarios. Eso requiere definir previamente qué significa operar en modo degradado.

La resiliencia no consiste únicamente en caer y recuperarse. También consiste en continuar operando de forma controlada mientras la recuperación ocurre, a un nivel mínimo pero que garantice la funcionalidad del servicio.

La capacidad degradada debería probarse

Muchas estrategias dicen, “En contingencia el proceso será manual”. Suena bien pero ¿con qué volumen o capacidad se aplicará? Si normalmente procesamos 20.000 operaciones diarias y manualmente podemos realizar 700, tenemos una estrategia de contingencia, pero también una brecha de capacidad. Esa diferencia debería conocerse antes de decidir la estrategia para responder al incidente.

Podríamos comenzar a medir:

Capacidad normal: 100 %
Capacidad mínima tolerable: 60 %
Capacidad demostrada en contingencia: 35 %

Ahora tenemos una conversación de resiliencia mucho más útil.

El Comité de Continuidad debería mirar servicios críticos más que procesos

Un dashboard de resiliencia podría mostrar:

• Estado de los servicios críticos;
• Nivel de tolerancia máxima a la disrupción;
• Capacidad mínima requerida;
• Capacidad operativa demostrada;
• Dependencias críticas de terceros;
• Puntos únicos de falla;
• Terceros sin alternativa;
• Escenarios probados;
• Brechas abiertas;
• Tiempo estimado para recuperar capacidad completa.

Entonces el Comité de Continuidad puede dejar de preguntar “¿Cuántos procesos tienen BCP?”

y comenzar a preguntar “¿Qué servicios podrían superar hoy nuestra tolerancia a la disrupción?”

La diferencia es enorme. Esto es lograr resiliencia operativa.

Reflexión final

La continuidad tradicional nos enseñó a recuperar procesos. La resiliencia operativa nos obliga a mirar algo más amplio, la capacidad de continuar entregando servicios importantes cuando varios componentes fallan simultáneamente.

No importa que Tecnología haya recuperado las bases de datos. No importa que Operaciones esté disponible. No importa que el proveedor cumpla individualmente su SLA.

Lo único que debe importar es que el cliente ya pueda operar, es decir que el servicio se ha restablecido.

Por eso, el siguiente paso de madurez no consiste necesariamente en crear más planes. Consiste en conectar los que ya tenemos alrededor de aquello que realmente importa.

La organización puede recuperarse por procesos o áreas y seguir fallando como servicio. La resiliencia comienza cuando dejamos de proteger silos y empezamos a proteger cadenas completas de valor.