Simulación discreta por eventos para procesos de negocio
La simulación discreta por eventos (DES) representa un proceso como una sucesión de eventos: llegada, inicio del procesamiento, fin del procesamiento, cambio de turno. El reloj avanza siempre hasta el siguiente evento programado, en lugar de avanzar en pasos de tiempo fijos. Por eso, un día de modelo cuesta tiempo de cálculo en el orden de milisegundos. Las entidades son los casos, los recursos son las capacidades de procesamiento, y surgen colas cuando ambos no encajan. Para los procesos de negocio son importantes tres decisiones: intervalos de llegada con distribución exponencial como suposición estándar, distribuciones asimétricas a la derecha para las duraciones de procesamiento, y suficientes repeticiones para que la banda de resultados se mantenga estable.
Inhaltsverzeichnis
Por qué «discreto» y por qué «orientado a eventos»
Hay dos maneras de tratar el tiempo en una simulación.
Orientado a pasos de tiempo: El reloj avanza en pasos fijos (cada minuto, cada segundo), y en cada paso se comprueba qué ha ocurrido. Fácil de programar, derrochador en ejecución: entre dos eventos en un proceso de aprobación pueden transcurrir horas en las que no pasa nada y aun así se calcula.
Orientado a eventos: El reloj salta al instante del siguiente evento programado. Entre eventos no cambia nada, así que no hace falta calcular.
Lista de eventos (ordenada por tiempo):
09:14 Llegada de trámite #418
09:22 Fin de procesamiento #402 en el paso "Revisión"
09:40 Cambio de turno Aprobación
...
El reloj salta a 09:14, procesa, programa eventos posteriores, salta de nuevo.
«Discreto» significa: el estado cambia de manera brusca en instantes concretos, no de forma continua. Esto encaja exactamente con los procesos de negocio. Una solicitud está procesada o no; no existe medio procesada.
Los cuatro componentes
| Componente | En su proceso | Qué hace |
|---|---|---|
| Entidad | Factura, solicitud, ticket, candidatura | Recorre el modelo, lleva atributos |
| Recurso | Responsable, autorizador, oficina de control | Tiene capacidad, está libre u ocupado |
| Cola | Bandeja, lista de tickets, recordatorio | Surge por sí sola cuando el recurso está ocupado |
| Evento | Llegada, inicio, fin, cambio de turno | Modifica el estado, programa eventos posteriores |
La propiedad más importante: Las colas no se modelan, surgirán. Quien introduce un tiempo de espera fijo de tres días como paso ya ha supuesto el resultado en lugar de calcularlo. Luego no podrá demostrar cómo cambia ese tiempo si varían la capacidad o la dispersión.
Las tres decisiones en las que fracasan los modelos
1. ¿Qué distribución?
Para los intervalos de llegada: exponencial. Esa es la suposición estándar cuando los trámites llegan de forma independiente, por ejemplo facturas de distintos proveedores o tickets de distintos usuarios. Genera exactamente el comportamiento que se observa en la bandeja: largos periodos tranquilos y luego tres de golpe.
No es exponencial cuando la entrada está sincronizada: una recogida a fin de mes, una entrega diaria a las 8. Entonces necesita un calendario, no una distribución.
Para las duraciones de procesamiento: sesgada a la derecha. Lognormal o Gamma. Si solo tiene estimaciones, use una triangular con mínimo, valor más probable y máximo. La razón: los tiempos de procesamiento tienen un límite duro por debajo y una larga cola a la derecha. Una distribución normal produciría duraciones negativas y subestimaría los valores atípicos que generan la cola.
Regla empírica para la práctica: Si solo sabe «5 a 15 minutos», tome una triangular con moda en 8. La decisión entre Lognormal y Gamma afecta menos al resultado que la cuestión de si permitir dispersión en absoluto.
2. Fase de calentamiento
Una simulación comienza con colas vacías. Es un estado que su proceso nunca tiene. Por eso los primeros días del modelo son sistemáticamente demasiado buenos.
Tratamiento: O bien excluye los primeros días del análisis (warm-up), o empieza con un stock inicial realista. Para procesos con utilización claramente por debajo del 85 % bastan unos pocos días; cerca del límite, el tiempo de asentamiento puede ser de semanas.
Cómo detectarlo: Si la media de la primera semana es claramente inferior a la de la segunda, la fase de calentamiento fue demasiado corta.
3. ¿Cuántas corridas?
Una sola corrida es una muestra de uno. Dice del proceso tanto como un único día de trabajo. Se repite con nuevos números aleatorios hasta que la banda de resultados se estabilice.
Criterio práctico: Duplique el número de corridas. Si P50 y P90 se mueven menos de unos pocos puntos porcentuales, el número es suficiente. Para procesos de negocio suele estar en varios cientos.
Más importante que el número exacto: Que se repita y que la salida sea una banda. Una simulación que entrega un único número ha fallado en el propósito del método.
Comparación de enfoques
| Orientado al proceso | Orientado a eventos | |
|---|---|---|
| Usted describe | la vida de una entidad | qué ocurre para cada tipo de evento |
| Ejemplo | «Llega la factura, espera, se revisa, espera, se autoriza» | «Al llegada: encolar. Si recurso libre: extraer siguiente» |
| Frecuente en | SimPy, Simul8, la mayoría de herramientas comerciales | bibliotecas más antiguas, implementaciones propias |
Para procesos de negocio la visión orientada al proceso es la más natural: escribe lo que le ocurre a un trámite, y eso corresponde exactamente a cómo el área funcional describe su flujo.
Validación: tres comprobaciones
1. Little's Law. Inventario ÷ rendimiento debe dar aproximadamente el tiempo de paso, tanto en el modelo como en la realidad. Esta comprobación vale sin hipótesis sobre distribuciones y por eso es la más fuerte.
2. Utilización frente a cálculo manual. ρ = demanda ÷ capacidad se puede calcular por paso con una calculadora. Si el modelo difiere mucho, hay una bifurcación o un calendario erróneo.
3. Prueba de valor extremo. Ponga la capacidad de un paso al doble. Si no cambia nada, ese paso nunca fue el cuello de botella. Si no lo esperaba, su modelo no coincide con su intuición. Ahí empieza la discusión interesante.
Dónde DES no es el método adecuado
- Los participantes toman decisiones propias que cambian el flujo (clientes abandonan, los operadores seleccionan casos) → simulación basada en agentes.
- Se trata de stocks y retroalimentaciones a lo largo de años (crecimiento de plantilla, dinámica de mercado) → dinámica de sistemas.
- No hay colas porque la capacidad es abundante → basta una suma.
- La pregunta es qué ocurrió realmente → Process Mining. DES calcula una hipótesis, no un registro.
Preguntas frecuentes
¿Cuál es la diferencia entre simulación discreta por eventos y simulación basada en agentes?
DES modela tareas que pasan por estaciones fijas y esperan por recursos ocupados. La lógica está en el proceso. La simulación basada en agentes modela participantes con reglas propias que interactúan entre sí. La lógica está en los agentes. Para un proceso de aprobación, DES es lo correcto; en cuanto los participantes deciden por sí mismos si y cómo continúan, ABS se vuelve interesante.
¿Qué distribución debe usar para los tiempos de procesamiento?
Una asimétrica a la derecha: lognormal o gamma si tiene datos; distribución triangular a partir de mínimo, valor más probable y máximo si estima. No la normal. Esta produce duraciones negativas y subestima los casos largos que impulsan la cola. Más importante que elegir entre los candidatos asimétricos es que exista variabilidad.
¿Cuánto debe durar la fase de calentamiento?
Lo suficiente, hasta que el inventario y el tiempo de espera dejen de acumularse sistemáticamente. Con utilizaciones claramente por debajo del 85 % son pocos días de modelo; cerca del límite de capacidad pueden ser semanas, porque la cola se estabiliza muy despacio. Una prueba sencilla: si el promedio de la primera semana está claramente por debajo del de la segunda, la fase fue demasiado corta.
¿Por qué salta el reloj en lugar de avanzar uniformemente?
Porque entre dos eventos no ocurre nada que haya que calcular. En un proceso de aprobación pueden pasar horas entre la llegada y el inicio del procesamiento sin cambio de estado. El salto de eventos hace que un año de modelo sea calculable en segundos. Es la razón por la que cientos de repeticiones son practicables.
¿Necesito un lenguaje de programación para DES?
No. Bibliotecas como SimPy requieren código; las herramientas comerciales y las herramientas con interfaz no lo exigen. La diferencia está en la responsabilidad: con una biblioteca usted decide la distribución, la fase de calentamiento y el número de réplicas; una herramienta con interfaz le quita parte de esas decisiones y calcula con menos profundidad.
Cálculelo con su propio proceso
FlowVisual convierte los números de este artículo en un modelo que se ejecuta, con sus volúmenes, sus capacidades, su margen.
Guide: seven steps to the number- Método
¿Qué es la simulación de procesos? Definición, métodos, límites
La simulación de procesos hace que un flujo se ejecute de forma artificial en lugar de describirlo. La diferencia no es académica: decide si usted tiene una opinión sobre un cambio o una cifra.
Lectura - Método
Simulación Monte Carlo para procesos: qué puede hacer y cuándo miente
Monte Carlo no es una palabra mágica, sino tirar dados con método: el mismo proceso, cientos de veces, con valores aleatorios distintos cada vez. Lo que resulta no es un único número, sino una distribución. Ese es precisamente el punto.
Lectura - Método
Calcular el cuello de botella: por qué el 85 % de utilización ya es demasiado
El cuello de botella no es el paso que más tarda, sino el que tiene la mayor utilización. Y el tiempo de espera no crece linealmente con la utilización, sino que explota justo antes del límite. El cálculo detrás cabe en una página.
Lectura