Cuánto cuesta una caída: modelo simple para estimar impacto y priorizar resiliencia (TI + negocio)

La pregunta “¿cuánto nos cuesta una caída?” no es técnica. Es una decisión de dirección porque afecta a ingresos, operación, atención al cliente, cumplimiento de compromisos y capacidad de recuperación.

En muchas organizaciones, la resiliencia se prioriza por intuición: lo más visible, lo que más ruido hace o lo último que falló. El problema es que ese enfoque suele mezclar síntomas con impacto real. Un servicio con muchos tickets no siempre es el más crítico, y un sistema aparentemente secundario puede detener una operación entera si bloquea facturación, pedidos, producción o soporte.

Por eso conviene cambiar el marco de conversación:

• de “infraestructura” a servicios,
• de “criticidad percibida” a impacto estimado,
• de “queremos máxima disponibilidad para todo” a tolerancia al riesgo explícita,
• y de “proyectos sueltos” a decisiones priorizadas.

La resiliencia no consiste en blindarlo todo por igual. Consiste en decidir dónde una hora de caída es aceptable, dónde no lo es y qué inversión tiene sentido para reducir ese riesgo.

Acciones recomendadas

1. Identificar entre 5 y 10 servicios críticos y asignar un responsable de negocio único por cada uno.
2. Definir escenarios de caída comparables: indisponibilidad total, degradación severa, pérdida de datos o fraude operativo.
3. Hacer un taller de 60–90 minutos con negocio, operaciones, TI y finanzas para estimar impacto en rangos.
4. Traducir el impacto a objetivos de recuperación: RTO, RPO y prioridades de restauración.
5. Revisar dependencias y SLAs de terceros en los servicios con mayor impacto.
6. Crear un backlog de resiliencia con medidas concretas, coste estimado y reducción esperada del riesgo.
7. Realizar al menos un simulacro anual de mesa para validar supuestos y descubrir dependencias no documentadas.

Definir “caída” en términos útiles

Antes de poner números, conviene acordar qué significa exactamente una caída. No todo fallo produce el mismo daño y no todo impacto viene de una indisponibilidad total.

Una definición útil debería distinguir al menos cuatro situaciones:

1. Indisponibilidad total

El servicio no puede usarse. Ejemplos típicos: plataforma de venta no operativa, ERP inaccesible, sistema de atención caído.

2. Degradación significativa

El servicio sigue disponible, pero con lentitud, errores parciales o capacidad reducida. A veces el negocio sigue operando, pero con menor rendimiento o con más intervención manual.

3. Pérdida o corrupción de datos

El servicio puede volver, pero el problema real está en la calidad o integridad de la información. Esto afecta directamente al RPO y puede disparar tareas manuales de reconciliación.

4. Fraude operativo o transacción incorrecta

No siempre hay “caída” visible. Un error de cambio, una automatización defectuosa o un incidente de seguridad pueden generar operaciones erróneas, pagos duplicados, pedidos mal procesados o accesos indebidos.

Esta distinción importa porque cada escenario tiene costes distintos y exige respuestas diferentes. Un servicio puede tolerar una hora de indisponibilidad, pero no tolerar pérdida de datos. Otro puede aceptar degradación temporal, pero no errores en transacciones.

El modelo simple en 5 componentes

La recomendación clave es trabajar con rangos: mínimo razonable, caso probable y máximo razonable. Es más honesto que fijar una cifra con apariencia de exactitud pero sin base.

1. Ingresos no realizados

Aplica cuando la caída impide vender, facturar o procesar operaciones que generan ingreso.

Preguntas útiles:

• ¿Qué volumen de transacciones se deja de procesar por hora o por día?
• ¿La venta se pierde o solo se retrasa?
• ¿Existe canal alternativo o recuperación posterior?
• ¿Hay estacionalidad o franjas horarias críticas?

Fórmula orientativa: ingresos afectados por periodo × porcentaje no recuperable

Puntos a tener en cuenta:

• No todo ingreso interrumpido es ingreso perdido.
• Si la demanda se recupera después, el impacto real puede ser parcial.
• Si la caída ocurre en una ventana crítica —cierre mensual, campaña, pico comercial— el rango cambia.

2. Coste de productividad o parada operativa

Aquí se estima el coste de personas y equipos que no pueden trabajar, o que pasan a hacerlo de forma muy ineficiente.

Fórmula orientativa: número de personas afectadas × horas impactadas × coste horario aproximado

También puede incluir:

• menor rendimiento de operaciones,
• trabajo manual adicional,
• retrasos en cadena,
• replanificación o turnos extra.

La clave es evitar una visión demasiado estrecha. No solo cuenta el equipo que “usa” el sistema, sino también los procesos dependientes: atención al cliente, almacén, finanzas, compras o producción.

3. Coste de respuesta y recuperación

Toda caída consume recursos para contener, investigar, restaurar y validar.

Incluye, según el caso:

• tiempo interno de TI, seguridad, operaciones y negocio,
• soporte extraordinario,
• proveedores externos,
• consultoría especializada,
• horas extra,
• comunicaciones a clientes o usuarios,
• validación posterior y cierre de incidencia.

Fórmula orientativa: horas internas + coste externo + esfuerzo de remediación post-incidente

Este bloque suele infravalorarse porque muchas empresas no registran el tiempo real invertido en recuperar un servicio y “absorbe” el esfuerzo dentro del equipo.

4. Costes contractuales o compensaciones

No conviene inventarlos. Deben tratarse como “según contrato”, tanto si la empresa paga a clientes como si sufre el incumplimiento de un proveedor.

Posibles casos:

• compensaciones por niveles de servicio,
• penalizaciones contractuales,
• descuentos o créditos de servicio,
• costes asociados a incumplimiento de compromisos comerciales.

Si no hay cláusula clara, mejor no cuantificarla como certeza. Puede reflejarse como riesgo condicionado: “podría existir coste contractual si aplica la cláusula X del acuerdo Y”.

5. Coste de oportunidad y reputación

Es el componente más difícil de cuantificar y, por eso, conviene tratarlo con disciplina.

Puede incluir:

• pérdida de confianza de clientes,
• incremento de cancelaciones o abandono,
• retraso en operaciones comerciales,
• impacto en marca interna o externa,
• desvío de proyectos por priorizar la recuperación.

Si se cuantifica, debe explicarse el método. Por ejemplo:

• incremento observado de bajas tras una incidencia relevante,
• coste comercial estimado de una campaña perdida,
• tiempo de dirección y áreas clave desviado de otras iniciativas.

Si no hay base suficiente, es preferible dejarlo como impacto cualitativo alto/medio/bajo en lugar de asignar una cifra arbitraria.

Una forma práctica de calcularlo

Un modelo simple puede construirse para cada servicio con tres escenarios temporales:

• 1 hora
• 4 horas
• 1 día

Y para cada escenario estimar un rango por componente:

La suma no pretende dar “la cifra exacta” del daño. Pretende responder mejor a estas preguntas:

• ¿Qué servicios generan mayor impacto económico si fallan?
• ¿Qué ventana de recuperación es aceptable para cada uno?
• ¿Dónde merece la pena invertir primero?
• ¿Qué riesgos conviene transferir, mitigar o aceptar?

Cómo aterrizarlo en 60–90 minutos

No hace falta lanzar un programa complejo para empezar. Un taller bien preparado puede dar una primera base de decisión.

Participantes mínimos

• responsable de negocio del servicio,
• responsable de operaciones o proceso,
• TI o arquitectura,
• seguridad si aplica,
• finanzas o controlling,
• compras o gestión de proveedores si el servicio depende de terceros.

Preguntas de la sesión

1. ¿Qué servicio evaluamos?

Debe describirse en términos de negocio, no de tecnología.

1. ¿Qué proceso de negocio soporta?

Venta, facturación, atención, logística, producción, cierre financiero, etc.

1. ¿Qué tipo de caída nos preocupa?

Total, degradación, datos, fraude operativo.

1. ¿Qué pasa si cae 1 hora, 4 horas o 1 día?

Qué se detiene, qué se retrasa, qué se hace manualmente.

1. ¿Quién queda afectado?

Equipos internos, clientes, partners, canales.

1. ¿Se pierde ingreso o solo se pospone?

Y en qué proporción.

1. ¿Qué costes de respuesta se activan?

Personal interno, proveedor, soporte, horas extra.

1. ¿Hay compromisos contractuales?

Solo si están documentados.

1. ¿Qué dependencias existen?

Red, identidad, integraciones, proveedor de nube, operador logístico, pasarela de pago, etc.

1. ¿Qué tiempo máximo tolerable tiene sentido?

De ahí saldrá la conversación sobre RTO y RPO.

Resultado esperado

Al final del taller debería existir una ficha por servicio con:

• impacto estimado por escenario,
• responsable de negocio,
• dependencias críticas,
• supuestos usados,
• RTO objetivo,
• RPO objetivo,
• acciones prioritarias.

De impacto a decisiones: RTO, RPO, proveedores y backlog

El valor del modelo aparece cuando se usa para decidir, no cuando se guarda en una presentación.

1. Mapear impacto a RTO

El RTO es el tiempo objetivo para restaurar un servicio. No debe definirse por costumbre ni copiarse entre sistemas.

Regla práctica:

• si el impacto de 1 hora ya es alto, el RTO tendrá que ser muy exigente;
• si el impacto crece sobre todo a partir de 4 horas, quizá el esfuerzo de diseño debe centrarse ahí;
• si 1 día es tolerable con trabajo manual, puede no tener sentido sobredimensionar.

2. Mapear impacto a RPO

El RPO define cuánta pérdida de datos es aceptable. Hay servicios que soportan cierto retraso de replicación y otros que no toleran perder ni una transacción.

Preguntas clave:

• ¿Qué pasa si se pierden 15 minutos de datos?
• ¿Puede reconstruirse la información?
• ¿Quién valida la reconciliación?
• ¿Cuánto cuesta corregir manualmente?

3. Ajustar SLAs y exigencias a proveedores

Si un servicio es crítico pero depende de un tercero, la resiliencia no termina en casa.

Conviene revisar:

• SLA reales frente a necesidades de negocio,
• ventanas de mantenimiento,
• soporte fuera de horario,
• responsabilidades de recuperación,
• acceso a evidencias y tiempos de escalado,
• planes de continuidad del proveedor.

El objetivo no es pedir “máximo SLA” para todo, sino asegurar que el servicio contratado está alineado con el impacto que la empresa ha estimado.

4. Priorizar el backlog de resiliencia

Una vez estimado el impacto, es más fácil ordenar inversiones como:

• redundancia de componentes,
• mejora de backup y restauración,
• automatización de failover,
• documentación de recuperación,
• monitorización de dependencias,
• refuerzo de controles de cambio,
• ejercicios de recuperación,
• alternativas manuales temporales,
• mejora contractual con terceros,
• segmentación o aislamiento de servicios críticos.

Una buena práctica es valorar cada acción por:

• coste aproximado,
• reducción esperada del riesgo,
• tiempo de implantación,
• dependencia de terceros.

Antipatrones comunes

Inventar números para “cerrar” el ejercicio

Si no hay dato interno, es mejor trabajar con rango y supuestos explícitos. Un número exacto sin fundamento empeora la decisión.

Usar un único escenario

No es lo mismo una caída de 20 minutos que una de 8 horas. El impacto no siempre crece linealmente.

Confundir sistema con servicio

El negocio no compra “bases de datos” ni “servidores”. Depende de servicios completos con personas, procesos, integraciones y proveedores.

Ignorar dependencias de terceros

Un servicio puede parecer resiliente sobre el papel y fallar en la práctica por identidad, conectividad, mensajería, pagos o soporte externo.

Medir solo pérdida de ventas

En muchos casos, el mayor coste está en productividad, recuperación, retrabajo y disrupción operativa.

No asignar un responsable de negocio

Si nadie del negocio asume la criticidad y los criterios de recuperación, la conversación se queda en TI y pierde legitimidad presupuestaria.

No revisar supuestos

Los procesos cambian. Un servicio que era secundario puede convertirse en crítico tras una integración, una adquisición o una nueva dependencia comercial.

Plantilla copiable: tabla de servicios críticos

Plantilla copiable: preguntas de estimación rápida

Un criterio simple para priorizar primero

Si la empresa quiere empezar sin complicarse, puede ordenar servicios por tres variables:

1. Impacto económico estimado por hora o por jornada
2. Tiempo máximo tolerable de interrupción
3. Madurez actual de recuperación

Con eso ya puede clasificar:

• Prioridad 1: alto impacto, baja tolerancia, recuperación débil.
• Prioridad 2: alto impacto, tolerancia media, controles parciales.
• Prioridad 3: impacto moderado o posibilidad real de operación manual temporal.

Este enfoque ayuda a evitar una lista interminable de “todo es crítico”.

Cierre

Estimar el coste de una caída no exige una fórmula perfecta. Exige un marco compartido para decidir mejor.

Si la empresa consigue describir sus servicios críticos, asignarles un responsable, estimar impacto en rangos y traducirlo a RTO, RPO y acciones concretas, ya habrá dado un paso importante: pasar de la intuición a la gobernanza.

La resiliencia madura no se basa en prometer disponibilidad absoluta. Se basa en saber qué duele de verdad cuando algo falla, cuánto estamos dispuestos a asumir y dónde conviene actuar primero.