← Casos de estudio
Simulación operativa / Apoyo a decisiones
OpsTwin
Prueba un cambio de plantilla o de flujo antes de aplicarlo en una operación de servicio real.
OpsTwin es un prototipo de simulación operativa y apoyo a decisiones para equipos de servicio. Su ejemplo canónico compara añadir un agente de soporte general con acelerar un 25% la revisión y asignación inicial de tickets.
Prototipo público de producto
Resumen del caso
El brief estratégico
El problema, la respuesta del sistema, la prueba disponible, el valor estratégico y el límite intencional.
- 01Problema
- Los dashboards operativos explican qué ocurrió, pero no cómo podrían responder las colas, la presión de plantilla y los niveles de servicio ante un cambio propuesto.
- 02Sistema
- Un espacio de apoyo a la decisión que compara una línea base con intervenciones acotadas mediante simulaciones discretas repetidas y emparejadas.
- 03Prueba
- Despliegue activo, repositorio público, contratos versionados, validación de integridad y registros históricos de verificación. En el último punto registrado, pasaron 247 tests de backend y 172 de frontend.
- 04Valor
- Crea evidencia comparativa antes de comprometerse con un cambio de plantilla, rediseño de proceso o piloto operativo.
- 05Límite
- Un modelo acotado de operaciones de soporte: no prueba causalidad, no predice resultados en producción ni recomienda una acción de forma autónoma.
01 / Problema
Los dashboards operativos muestran lo que pasó. No prueban un cambio propuesto.
Los equipos de servicio pueden ver volumen de tickets, tiempo de resolución y carga de trabajo después de que ocurran. La pregunta difícil es contrafactual: qué podría cambiar si se añade capacidad o se acelera la primera revisión.
Estos cambios mueven la presión por todo el flujo. Una mejora local puede desplazar colas o carga a otro punto, por eso OpsTwin compara cada cambio bajo las mismas condiciones simuladas.
Construir un análisis a medida para cada pregunta.
Probar el cambio en la operación real.
02 / Producto
Primero una comparación guiada. El espacio completo cuando hace falta.
Empezar por la operación
Revisar el flujo de soporte ficticio, sus supuestos y la medida que se compara.
Comparar dos cambios acotados
Añadir un agente de soporte general o hacer un 25% más rápida la revisión y asignación.
Leer la evidencia
Inspeccionar el cambio medio observado, la consistencia entre pruebas, la incertidumbre, el proceso y la carga de los equipos.
03 / Comparación demostrada
El resultado explica la evidencia. No elige una acción.
El flujo guiado público compara la operación actual con dos cambios propuestos. La captura siguiente es un resultado actual del escenario de soporte ficticio, no evidencia de una empresa real.
Cambio medio observado
La diferencia en la medida elegida a través de ejecuciones de simulación emparejadas.
Consistencia entre pruebas
Con qué frecuencia un cambio propuesto funciona mejor que la operación actual.
Rango plausible
Un rango alrededor del cambio medio estimado que puede incluir mejora, ausencia de mejora o un resultado peor.
Límite de decisión
Un ranking puede no ser concluyente. La evidencia comparativa no es una recomendación.
04 / Prueba de interfaz
El producto mantiene el resultado conectado con la operación que lo produce.
La vista de Proceso muestra dónde entra un cambio propuesto en el flujo. La carga de los equipos mantiene visibles la capacidad y la espera junto a la comparación principal.
05 / Método
La simulación emparejada hace más justa la comparación.
OpsTwin usa números aleatorios comunes. La ejecución 1 de la operación actual y la ejecución 1 de cada cambio propuesto comparten las mismas condiciones simuladas. El emparejamiento se mantiene en las ejecuciones repetidas.
Esto reduce la posibilidad de que una diferencia proceda solo de una demanda simulada distinta. No convierte el modelo en una previsión de producción ni en una prueba causal.
La frecuencia de mejora no es una probabilidad de éxito en producción.
Un rango plausible no es un rango de resultado garantizado.
Un ranking comparativo no es una recomendación operativa.
La evidencia de simulación no es una prueba causal.
06 / Ingeniería y fiabilidad
La interfaz muestra evidencia solo después de que el modelo la comprueba.
La interfaz pública envía una solicitud versionada a un servicio de simulación en FastAPI. SimPy ejecuta el modelo de eventos discretos y las semillas hijas deterministas preservan el calendario emparejado entre la línea base y los escenarios.
Un fallo de despliegue también aclaró un límite de propiedad. La web dependía de un fixture fuera de su paquete desplegado, por lo que el activo de ejecución se movió al servicio que lo necesitaba y quedó protegido frente a divergencias.
Interfaz Next.jsContrato de solicitud versionadoServicio de simulación FastAPIMotor SimPyComprobaciones de integridadEvidencia y exportación
07 / Resultado
Un prototipo desplegado con evidencia inspeccionable y límites claros.
El producto en vivo, el repositorio público y las capturas actuales permiten inspeccionar la implementación. No se afirma ningún resultado operativo de una empresa real.
En el último punto de verificación registrado, pasaron 247 tests de backend y 172 de frontend. Son registros históricos, no una afirmación sobre la suite completa actual.
08 / Límites
Un modelo de soporte acotado, no una plataforma de optimización para producción.
- El escenario canónico representa un flujo de soporte ficticio, no una operación arbitraria.
- No se han procesado datos de empresas ni de usuarios reales.
- El prototipo no tiene base de datos, autenticación, persistencia ni estado multiusuario.
- La salida de la simulación no es una prueba causal ni una garantía de resultado en producción.
- El producto no recomienda una acción de forma autónoma ni garantiza una configuración óptima.
- No se afirma un resultado de negocio medido ni un estudio con participantes terminado.
El uso en producción requeriría calibración del modelo, integración de datos, seguridad, observabilidad y validación con definiciones operativas propias de la organización.
09 / Aprendizaje
El límite útil está donde el modelo deja de hablar por quien opera.
Un modelo matemáticamente válido puede fallar como producto si las personas no entienden la decisión que respalda ni la incertidumbre que contiene.
OpsTwin trata el resultado como evidencia comparativa. La persona operadora conserva la decisión, los supuestos y el siguiente paso.
OpsTwin
Explora la comparación y revisa el modelo que la sostiene.
Abre el producto guiado o revisa el repositorio y los detalles de implementación.
