Skip to main content

Resumen

La simulación en ProDex es simulación de eventos discretos, y es un conjunto de artefactos conectados en lugar de una sola función. Construyes un modelo de tu proceso en el lienzo del Modelador, opcionalmente lo impulsas con una programación de eventos de producción reales, y lo ejecutas como una ejecución. Una ejecución produce datos que interpretas mediante KPIs y gráficos. Para comparar escenarios, ejecutas cada variante como su propia ejecución y comparas las ejecuciones. Para cuantificar la variabilidad dentro de un mismo escenario, lo ejecutas varias veces con distintas semillas aleatorias. Esta página es el mapa. Cada artefacto tiene su propia página con los detalles, y Tu primera simulación recorre todo el ciclo una vez, de forma práctica.

Los bloques de construcción

Modelos

El modelo es el artefacto central: el grafo del proceso más los datos de soporte que referencia. Vive en el lienzo del Modelador, donde arrastras fuentes, procesos, búferes, combinadores, separadores, transformadores, enrutadores y sumideros, y conectas el flujo entre ellos. Las estaciones no son nodos de flujo: son un mecanismo de agrupación que envuelve procesos, combinadores, separadores, transformadores y enrutadores dentro de un espacio físico. Adjuntas al modelo están las entidades que se mueven a través de él, los recursos (trabajadores, máquinas, herramientas) que consume, y las constantes y tablas de búsqueda que lo parametrizan, además de cualquier submodelo anidado (Nodos de modelo). Las distribuciones de las que se nutre su lógica estocástica viven en línea dentro de los campos de cada componente en lugar de existir como un artefacto separado. Un modelo es un objeto vivo: lo editas en el momento, lo revalidas y lo vuelves a ejecutar a medida que evoluciona tu comprensión del proceso. La validación detecta problemas estructurales antes de ejecutar.

Programaciones

Una programación es la capa operativa sobre un modelo. Donde el modelo describe cómo funciona el proceso, una programación describe cuándo ocurren cosas específicas, ancladas al tiempo de calendario real: las liberaciones de material inyectan entidades específicas en momentos específicos, y las acciones programadas disparan asignaciones de variables o eventos en momentos específicos. Un modelo puede tener muchas programaciones — una semana base, un escenario de alta demanda, una ventana de mantenimiento — y eliges la activa en el selector de programación en la parte superior del Modelador. Cambiar la programación cambia el escenario operativo sin tocar el modelo en sí.
En una Fuente, las liberaciones de material coexisten con la lógica de llegada propia de la Fuente: ambas se disparan, y las liberaciones programadas se disparan incluso cuando la Fuente está pausada. Si quieres llegadas exclusivamente por programación, usa una Fuente de solo evento sin lógica de llegada. Consulta Programaciones.

Ejecuciones

Una ejecución es una ejecución de un modelo contra una programación (o contra la duración simple del modelo cuando no hay programación activa). Produce un registro completo de lo que sucedió — ciclos de vida de entidades, actividad de procesos, actividad de recursos — que la vista de Resultados lee. Las ejecuciones se almacenan bajo su modelo padre, y cada una remite a la configuración que ejecutó. Después de que la simulación en sí termina, ProDex calcula los KPIs y gráficos de la ejecución en un segundo paso: una ejecución se muestra como pendiente mientras ese paso está trabajando, y lista una vez que sus números están poblados.

KPIs y gráficos

Los KPIs son números únicos: rendimiento, WIP promedio, utilización. Los gráficos son visualizaciones: rendimiento a lo largo del tiempo, utilización por recurso, un histograma de longitud de cola. Ambos se crean sobre el modelo — describes lo que quieres y Dexter escribe la consulta subyacente — de modo que cada ejecución posterior los calcula automáticamente. Son la capa de interpretación que convierte los datos crudos de una ejecución en una respuesta. Consulta Resultados y análisis.

Comparar escenarios

Un escenario es simplemente una ejecución. Para comparar una línea base contra un cambio — capacidad extra, una programación alterna — ejecuta cada variante: edita el modelo y vuelve a ejecutarlo, cambia la programación activa, o pídele a Dexter que copie el modelo y cambie la copia para que la línea base quede intacta. Luego pídele a Dexter que compare las ejecuciones, y dispone sus KPIs lado a lado para que puedas ver qué opción gana y por cuánto. Consulta Comparar ejecuciones.

Réplicas

Las réplicas responden una pregunta diferente: no qué opción es mejor, sino ¿cuánto varía el resultado de esta opción solo por el azar? Pídele a Dexter que ejecute una configuración con varias semillas aleatorias, y las lanza como un solo lote de ejecuciones y compara la dispersión de cada KPI entre ellas. La configuración necesita contenido estocástico genuino: un modelo completamente determinista produce réplicas idénticas sin dispersión que medir.
Las variantes varían el escenario; las semillas varían el azar. Compara variantes para elegir entre opciones, y replica cada una para saber cuánto confiar en la diferencia.

Cómo encajan las piezas

El arco típico:
  1. Construye el modelo en el lienzo: conecta el flujo, define entidades, establece las distribuciones de las que se nutre tu lógica de tiempos y enrutamiento, agrega constantes, deja la validación en verde.
  2. Adjunta una programación si el escenario necesita tiempos operativos reales; de lo contrario, el campo de duración del modelo es suficiente.
  3. Ejecútalo. La simulación se ejecuta, y luego el paso de resultados calcula tus KPIs y gráficos.
  4. Analiza en Resultados: lee los KPIs, inspecciona los gráficos y el registro de eventos, itera sobre el modelo, ejecuta de nuevo.
  5. Compara escenarios. Ejecuta cada configuración candidata y pídele a Dexter que compare las ejecuciones.
  6. Cuantifica la variabilidad con réplicas antes de confiar un escenario a una decisión real.
No tienes que manejar nada de esto a mano. Dexter puede construir modelos, copiarlos en variantes, disparar ejecuciones y réplicas, crear KPIs y gráficos, y comparar ejecuciones desde el chat — y un estudio de mejora completo puede ejecutarse a lo largo de varias sesiones. Consulta Estudios de simulación.

Límites y advertencias

  • Editar un modelo no conserva su versión anterior. Las ejecuciones pasadas siguen registrando lo que ejecutaron, pero para volver a ejecutar la línea base más tarde, pídele a Dexter que copie el modelo antes de cambiarlo. Una copia comparte sus submodelos, entidades, constantes y tablas de búsqueda con el original, así que cambiarlos afecta a ambos; para conservar una línea base exacta, exporta la fábrica primero.
  • Los resultados llegan en dos etapas. Una ejecución cuyos KPIs aún no se han poblado está pendiente, no rota — la simulación terminó y el paso de resultados sigue calculando. Si el paso de resultados falla, se puede reintentar sin volver a simular.
  • La interfaz sigue una sola selección activa. Los Resultados, la creación de gráficos y el selector de ejecución leen el modelo, la ejecución y la programación actualmente activos, así que confirma que estás viendo la ejecución que crees antes de comparar números.

Hacia dónde ir después