Simulazione a eventi discreti per processi aziendali
La simulazione discreta basata su eventi (DES) rappresenta un processo come una sequenza di eventi: arrivo, inizio lavorazione, fine lavorazione, cambio turno. L'orologio salta sempre al prossimo evento pianificato, invece di avanzare a intervalli temporali fissi. Per questo motivo un giorno di modello richiede tempo di calcolo nell'ordine dei millisecondi. Le entità sono le pratiche, le risorse le capacità di lavorazione, si formano code quando i due non coincidono. Per i processi aziendali sono importanti tre decisioni: intervalli di arrivo distribuiti esponenzialmente come ipotesi predefinita, distribuzioni asimmetriche verso destra per le durate di lavorazione, e ripetizioni sufficienti affinché la banda dei risultati resti stabile.
Inhaltsverzeichnis
Perché «discreto» e perché «orientato agli eventi»
Esistono due modi per trattare il tempo in una simulazione.
A passi di tempo: L’orologio avanza a intervalli fissi (ogni minuto, ogni secondo) e a ogni passo si verifica cosa è successo. Facile da programmare, dispendioso in esecuzione: tra due eventi in un processo di approvazione possono passare ore in cui non succede nulla e comunque si calcola.
Orientato agli eventi: L’orologio salta al momento del prossimo evento pianificato. Tra gli eventi lo stato non cambia, quindi non c’è bisogno di calcoli.
Lista eventi (ordinata per tempo):
09:14 Arrivo processo #418
09:22 Fine lavorazione #402 al passo "Verifica"
09:40 Cambio turno Approvazione
...
L’orologio salta alle 09:14, elabora, pianifica eventi successivi, salta ancora.
«Discreto» significa: lo stato cambia a salti in momenti specifici, non in modo continuo. Questo corrisponde esattamente ai processi aziendali. Una richiesta è elaborata o non lo è; non esiste mezzo-elaborata.
I quattro mattoni
| Mattone | Nel Suo processo | Cosa fa |
|---|---|---|
| Entità | Fattura, richiesta, ticket, candidatura | Percorre il modello, porta attributi |
| Risorsa | Addetta, autorizzante, reparto verifica | Ha capacità, è libera o occupata |
| Coda | Casella, lista ticket, promemoria | Si forma automaticamente quando la risorsa è occupata |
| Evento | Arrivo, inizio, fine, cambio turno | Modifica lo stato, programma eventi successivi |
La proprietà più importante: le code non vengono modellate, si formano. Chi inserisce un tempo di giacenza di tre giorni come passo fisso ha presunto il risultato invece di calcolarlo. Non potrà poi mostrare come quel tempo cambi se variano capacità o dispersione.
Le tre decisioni su cui i modelli falliscono
1. Quale distribuzione?
Per gli intervalli di arrivo: esponenziale. Questa è l’assunzione standard quando gli arrivi sono indipendenti, per esempio fatture da fornitori diversi o ticket da utenti diversi. Produce esattamente il comportamento osservato nella casella: lunghi periodi tranquilli, poi tre insieme.
Non è esponenziale quando l’ingresso è cadenzato: un batch a fine mese, un passaggio giornaliero alle 8. Allora serve un calendario, non una distribuzione.
Per le durate di lavorazione: asimmetrico a destra. Lognormale o Gamma. Se ha solo stime, triangolare con minimo, valore più probabile e massimo. Il motivo: le durate hanno un limite inferiore rigido e una lunga coda a destra. Una distribuzione normale genera durate negative e sottostima gli outlier che causano le code.
Regola pratica: se sa solo «5 a 15 minuti», usi una distribuzione triangolare con moda a 8. La scelta tra lognormale e Gamma influenza meno del decidere se includere la dispersione.
2. Fase di riscaldamento
Una simulazione inizia con code vuote. È uno stato che il Suo processo non ha mai. I primi giorni del modello sono quindi sistematicamente troppo favorevoli.
Trattamento: escludere i primi giorni dall’analisi (warm-up), oppure partire con uno stock iniziale realistico. Per processi con utilizzo ben sotto l’85 % bastano pochi giorni; vicino al limite il tempo di assestamento può durare settimane.
Come lo nota: se la media della prima settimana è chiaramente sotto quella della seconda, il warm-up è stato troppo corto.
3. Quante esecuzioni?
Un’unica esecuzione è un campione di uno. Dice del processo quanto un singolo giorno di lavoro. Si ripete con nuovi numeri casuali finché la fascia di risultati si stabilizza.
Criterio pratico: raddoppi la quantità di esecuzioni. Se P50 e P90 cambiano di meno di qualche percento, il numero è sufficiente. Per processi aziendali tipicamente servono alcune centinaia.
Più importante del numero esatto: ripetere e ottenere una fascia di risultati. Una simulazione che restituisce un singolo numero non ha centrato lo scopo del metodo.
Il confronto delle prospettive
| Orientato al processo | Orientato agli eventi | |
|---|---|---|
| Descrive Lei | il ciclo di vita di un’entità | cosa succede per ogni tipo di evento |
| Esempio | «La fattura arriva, aspetta, viene verificata, aspetta, viene approvata» | «All’arrivo: mettersi in coda. Se la risorsa è libera: prendere il prossimo» |
| Diffuso in | SimPy, Simul8, la maggior parte degli strumenti commerciali | librerie più vecchie, implementazioni proprie |
Per i processi aziendali la visione orientata al processo è la più naturale: si scrive cosa succede a un’istanza e questo corrisponde al modo in cui un reparto descrive il proprio flusso.
Validazione: tre verifiche
1. Little's Law. Inventario ÷ Throughput deve approssimare il tempo di attraversamento, sia nel modello sia nella realtà. Questa verifica vale senza ipotesi sulle distribuzioni ed è quindi la più forte.
2. Utilizzo contro calcolo manuale. ρ = Domanda ÷ Capacità si può ricalcolare per ogni passo con una calcolatrice. Se il modello diverge molto, c’è una diramazione o un calendario errato.
3. Test di valore estremo. Raddoppi la capacità di un passo. Se non cambia nulla, quel passo non era mai il collo di bottiglia. Se non lo prevedeva, il modello non corrisponde alla Sua idea. È proprio lì che inizia la discussione interessante.
Dove DES non è il metodo giusto
- I partecipanti prendono decisioni autonome che cambiano il flusso (i clienti abbandonano, gli operatori scelgono i casi) → simulazione agent‑based.
- Si tratta di stock e retroazioni su anni (crescita del personale, dinamiche di mercato) → System Dynamics.
- Non ci sono code perché la capacità è abbondante → basta un’addizione.
- La domanda è cosa è effettivamente accaduto → Process Mining. DES calcola un’ipotesi, non è un registro.
Domande frequenti
Qual è la differenza tra simulazione a eventi discreti e simulazione basata su agenti?
La DES rappresenta istanze che attraversano stazioni fisse e attendono risorse occupate. La logica è nel processo. La simulazione basata su agenti rappresenta partecipanti con regole proprie che interagiscono tra loro. La logica è negli agenti. Per un processo di approvazione DES è corretta; non appena i partecipanti decidono autonomamente se e come proseguire, l'ABS diventa interessante.
Quale distribuzione dovrei usare per i tempi di lavorazione?
Una asimmetrica a destra: lognormale o gamma, se ha dati, distribuzione triangolare da minimo, valore più probabile e massimo, se stima. Non una normale. Questa genera durate negative e sottostima i casi lunghi che alimentano la coda. Più importante della scelta tra i candidati asimmetrici a destra è che ci sia effettivamente variabilità.
Quanto deve durare la fase di riscaldamento?
Quanto basta perché scorte e tempi di attesa non si accumulino più sistematicamente. Con tassi di utilizzo ben sotto l'85% si parla di pochi giorni di modello; vicino al limite di capacità possono essere settimane, perché la coda si stabilizza molto lentamente. Un test semplice: se la media della prima settimana è nettamente inferiore a quella della seconda, la fase è stata troppo breve.
Perché l'orologio salta invece di scorrere uniforme?
Perché tra due eventi non succede nulla che debba essere calcolato. In un processo di approvazione tra arrivo e inizio della lavorazione spesso passano ore senza cambiamento di stato. Il salto per eventi rende computabile un anno di modello in pochi secondi. È il motivo per cui centinaia di ripetizioni sono praticabili.
Ho bisogno di un linguaggio di programmazione per la DES?
No. Librerie come SimPy richiedono codice, strumenti commerciali e strumenti leggeri con interfaccia no. La differenza sta nella responsabilità: con una libreria Lei decide distribuzioni, fase di riscaldamento e numero di repliche; uno strumento con interfaccia Le toglie in parte queste decisioni e calcola però in modo più superficiale.
Lo calcoli sul Suo processo
FlowVisual trasforma i numeri di questo articolo in un modello funzionante, con i Suoi volumi, le Sue capacità, il Suo margine.
Guide: seven steps to the number- Metodo
Che cos'è la simulazione di processo? Definizione, metodi, limiti
La simulazione di processo fa eseguire artificialmente un flusso invece di descriverlo. La differenza non è accademica: determina se Lei ha un'opinione su una modifica o un numero.
Lettura - Metodo
Simulazione Monte Carlo per i processi: cosa può fare e quando inganna
Monte Carlo non è una parola magica, ma tirare i dadi con metodo: lo stesso processo, centinaia di volte, ciascuna con valori casuali diversi. Ciò che ne risulta non è un numero, ma una distribuzione. Proprio questo è il punto.
Lettura - Metodo
Calcolare il collo di bottiglia: perché l'85 % di utilizzo è già troppo
Il collo di bottiglia non è il passo con la durata più lunga, ma quello con l'utilizzo più alto. E il tempo di attesa non cresce linearmente con l'utilizzo, ma esplode poco prima del limite. Il calcolo dietro sta su una pagina.
Lettura