De la estimación a la simulación: cómo mejorar la evaluación de riesgos en proyectos tecnológicos

En una migración tecnológica crítica, se estimó una probabilidad de éxito del 75%.

El resultado fue un fallo operativo.

Y no… no fue un problema de ejecución.

Fue un problema de cómo se evaluó el riesgo.

---

El caso: cuando todo parecía estar bajo control

La lógica detrás de esa estimación era aparentemente sólida:

• No se realizaban cambios en aplicaciones ni en base de datos
• Se mantenían las mismas direcciones IP
• Existía un antecedente de estabilización mediante un workaround

Además, el cambio estaba planificado con bastante precisión:

• Duración total de la ventana: 6 horas
• Corte controlado: 10 minutos
• Estabilización estimada: 2 horas de intermitencia
• Rollback previsto: 1 hora
• Tiempo de recuperación: 1 hora

Desde el diseño, todo parecía controlado.

Pero falló.

---

Dónde estuvo el error

El problema no fue técnico en sí.

Fue conceptual.

👉 Se asumió que un workaround previo era evidencia de solución.

Cuando en realidad, solo había demostrado que el sistema podía recuperarse temporalmente… no que el problema estuviera resuelto.

---

El límite de la matriz de riesgo

La evaluación se apoyó en una matriz tradicional de probabilidad e impacto.

Útil, sí.

Suficiente, no.

Porque:

• Clasifica riesgos, pero no modela su comportamiento
• Usa escalas discretas
• Depende del juicio del equipo
• No refleja cómo interactúan los factores en el sistema real

Así se llegó a un “75% de éxito” que no representaba la realidad operativa.

---

Reenfocando el análisis: una sola rama del RBS

En lugar de analizar todo el proyecto, basta con enfocarse en una sola dimensión:

👉 Riesgos tecnológicos

Factores clave:

• Posible causa raíz no resuelta
• Dependencias funcionales no visibles
• Workaround interpretado como solución
• Comportamiento del sistema durante estabilización

---

De riesgos a variables

Para entender mejor el escenario, estos riesgos se convierten en variables:

Factor de riesgo	Representación
Causa raíz no resuelta	Probabilidad (%)
Workaround no sostenible	Probabilidad (%)
Impacto en sistemas periféricos	Probabilidad (%)
Tiempo de diagnóstico	Rango de horas
Tiempo de recuperación	Rango de horas

👉 Aquí ocurre el cambio importante:
pasamos de opiniones a escenarios posibles.

---

Mini-simulaciones: entendiendo el comportamiento real

Para ilustrar este comportamiento, se evaluaron diferentes combinaciones plausibles de estos factores.

Este enfoque —inspirado en una simulación tipo Monte Carlo— permite observar cómo pequeñas variaciones cambian completamente el resultado.

Supuestos operativos:

• Ventana total: 6 horas
• Tiempo base del cambio: 2 horas
• Estabilización esperada: 2 horas
• Capacidad de recuperación: limitada dentro de la misma ventana

 

 

---

Escenarios evaluados

Escenario	1	2	3
Causa raíz	Sí	No	Sí
Workaround	Falla	—	Parcial
Impacto periférico	No	No	Sí
Diagnóstico (h)	2	0.5	2
Recuperación (h)	2	1	3
Resultado	❌ Falla (inestabilidad prolongada)	✅ Éxito	❌ Falla (impacto en estabilización)

 

---

Resultado estimado

Al considerar múltiples combinaciones de estos factores:

Resultado estimado	Valor
Probabilidad de completar sin inestabilidad relevante	25%
Probabilidad de fallo operativo	75%
Principal factor	Causa raíz no resuelta
Segundo factor	Comportamiento en estabilización

 

Estos valores no provienen de una medición exacta, sino de un ejercicio de simulación simplificada basado en múltiples escenarios plausibles.

Al evaluar distintas combinaciones de factores —como la presencia de una causa raíz no resuelta, la sostenibilidad del workaround y el comportamiento del sistema en estabilización— se observa que la mayoría de los escenarios conduce a una condición de falla operativa.

En este contexto, la probabilidad de éxito se reduce significativamente, ubicándose en torno al 20%–30%, mientras que la probabilidad de fallo se aproxima al 70%–80%.

 

👉 Lo que evidencia una diferencia significativa respecto a la estimación inicial..

---

Dónde estaba realmente el riesgo

El riesgo no estaba en el corte.

El rollback estaba bien definido.

👉 El riesgo estaba en la estabilización del sistema bajo condiciones reales.

---

¿Dónde entra la inteligencia artificial?

Hoy, herramientas de inteligencia artificial permiten acelerar este tipo de análisis:

• Identificar factores de riesgo relevantes
• Proponer variables medibles
• Evaluar múltiples escenarios
• Estimar probabilidades de resultado

Sin necesidad de construir modelos complejos desde cero.

Como se observa en enfoques modernos de gestión de riesgos, la IA no reemplaza al Project Manager, pero sí permite pasar de decisiones basadas en percepción a decisiones basadas en evidencia.

---

Lecciones clave

1. Un workaround no es una solución
   Puede estabilizar, pero no elimina la causa raíz.
2. La matriz de riesgo no es suficiente en entornos complejos
   Se requiere modelar escenarios.
3. Las dependencias indirectas importan
   Aunque no se modifiquen aplicaciones o bases de datos, el comportamiento del sistema puede cambiar.
4. El riesgo es sistémico
   No se evalúa por partes aisladas.

---

Conclusión

El problema no fue la migración.

Fue la forma en que se evaluó el riesgo.

El verdadero valor del Project Manager en entornos complejos está en tener el criterio para cuestionar supuestos, interpretar señales y dar visibilidad real del comportamiento del sistema.

Solo así es posible tomar decisiones que realmente protejan la continuidad del negocio.

Porque al final, la pregunta no es:

👉 “¿Creemos que va a funcionar?”

sino:

👉 “¿Cuál es la probabilidad real de que falle?”