Come funziona il motore di simulazione
Comprendere il motore di simulazione
ProcessMind utilizza un motore di simulazione a eventi discreti (DES) per modellare i processi. Comprenderne il funzionamento Le consentirà di configurare le simulazioni in modo più efficace e interpretarne correttamente i risultati.
Che cos’è la simulazione a eventi discreti?
Nella simulazione a eventi discreti, lo stato del sistema cambia solo in corrispondenza di specifici eventi: l’orologio passa da un evento all’altro e, tra un evento e il successivo, non accade nulla. Questo approccio è ideale per i processi aziendali perché:
- Le attività hanno orari di inizio e fine distinti
- Le risorse vengono assegnate e rilasciate in momenti specifici
- I casi arrivano e si concludono in momenti definiti
Perché gli eventi discreti?
A differenza della simulazione continua, utilizzata in fisica o nella fluidodinamica, i processi aziendali non richiedono una modellazione istante per istante. Una richiesta di prestito non passa gradualmente dallo stato «inviata» a quello «approvata»: cambia stato in corrispondenza di eventi specifici.
Il ciclo principale degli eventi
Il motore di simulazione segue un ciclo semplice:
1. Initialize: Set up starting conditions
2. Get Next Event: Find the earliest scheduled event from the priority queue
3. Advance Time: Move simulation clock to that event's time
4. Process Event: Handle the event (start activity, complete activity, etc.)
5. Schedule New Events: Based on what happened, add new events
6. Repeat: Continue until end time or max events reached (5,000,000)
7. Output: Generate the complete event logTipi di eventi
La simulazione genera ed elabora diversi tipi di eventi:
| Tipo di evento | Descrizione |
|---|---|
| Arrivo del caso | Un nuovo caso entra nel processo tramite un evento di inizio |
| Inizio dell’attività | Un caso avvia un’attività (le risorse vengono assegnate) |
| Completamento dell’attività | Un caso conclude un’attività (le risorse vengono rilasciate) |
| Valutazione del gateway | Un punto decisionale determina il percorso o i percorsi da seguire |
| Completamento del caso | Un caso raggiunge un evento finale |
Generazione e arrivo dei casi
I casi entrano nella simulazione attraverso gli eventi di inizio del modello BPMN. Il modello degli arrivi è determinato dalla distribuzione di generazione dei casi.
Modello di arrivo predefinito
Per impostazione predefinita, i casi arrivano secondo una distribuzione di Poisson, con una frequenza di un caso all’ora. Si ottengono così intervalli tra gli arrivi casuali e realistici, tipici di molti processi aziendali.
Personalizzare gli arrivi
È possibile configurare diversi modelli di arrivo utilizzando le distribuzioni descritte nella documentazione sulle distribuzioni.
Flusso dei casi nel processo
Sequence Flows
Quando un caso completa un elemento, segue immediatamente il Sequence Flow in uscita. Se è disponibile un solo percorso in uscita, il caso lo segue automaticamente.
Comportamento dei gateway
I gateway determinano come i casi si diramano e si ricongiungono:
| Tipo di gateway | Comportamento |
|---|---|
| XOR (esclusivo) | Viene selezionato un solo percorso in uscita, con una scelta casuale ponderata in base alle probabilità. Le probabilità sono considerate pesi relativi e normalizzate automaticamente. |
| AND (parallelo) | Tutti i percorsi in uscita vengono seguiti contemporaneamente. Il caso si divide in token paralleli. |
| OR (inclusivo) | Selezione casuale dei percorsi, con la garanzia che ne venga seguito almeno uno. |
| Basato su eventi | Selezione casuale tra gli eventi disponibili. |
Impostare le probabilità
Per i gateway XOR, si assegnano probabilità a ciascun flusso in uscita. Si tratta di pesi relativi:
- Se si impostano i flussi su 70, 20 e 10, vengono normalizzati rispettivamente al 70%, 20% e 10%
- Impostando i flussi su 7, 2 e 1 si ottiene lo stesso risultato
- Ai flussi senza un valore assegnato viene attribuita la percentuale rimanente
Esecuzione delle attività
Quando un caso raggiunge un task (attività), il motore segue questa sequenza:
1. Verificare la disponibilità delle risorse
La risorsa necessaria ha capacità disponibile?
2. Inserire il caso in coda, se necessario
Se le risorse non sono disponibili, il caso entra nella coda di attesa. Per impostazione predefinita, ProcessMind utilizza l’ordine FIFO (First In, First Out): i casi vengono elaborati nell’ordine di arrivo.
3. Assegnare le risorse
Quando diventano disponibili, le unità di risorsa necessarie vengono riservate per il caso.
4. Determinare il tempo di elaborazione
Il motore estrae un valore dalla distribuzione configurata per il tempo di elaborazione, che determina la durata dell’attività.
5. Pianificare l’evento di completamento
Nella coda degli eventi viene aggiunto un evento di completamento all’istante current_time + processing_time.
6. Rilasciare le risorse
Quando si verifica l’evento di completamento, le risorse vengono restituite al gruppo e rese disponibili per gli altri casi.
Tempo di elaborazione minimo
Per garantire timestamp univoci e un comportamento realistico, tutte le attività hanno una durata minima di 1 secondo. Anche con una distribuzione di durata pari a zero, le attività durano almeno un secondo.
Probabilità di salto
È possibile configurare per le attività una probabilità di salto (0-100%). Quando un’attività viene saltata:
- Il caso passa immediatamente all’elemento successivo
- Non vengono utilizzate risorse
- Non trascorre tempo (a eccezione del secondo minimo)
- L’attività compare nel log con una durata minima
Questo consente di modellare situazioni reali in cui alcuni passaggi vengono talvolta saltati.
Gestione del tempo
L’orologio della simulazione
La simulazione utilizza un orologio virtuale che avanza a intervalli discreti, da un evento all’altro. Se l’evento successivo è alle 10:35 e l’ora corrente è 10:30, l’orologio passa direttamente alle 10:35.
Unità di tempo
Internamente, tutti gli orari vengono convertiti in unità coerenti. È possibile specificare le durate in:
- Secondi
- Minuti
- Ore
- Giorni
Le frequenze di arrivo si impostano separatamente, per ora, giorno, settimana, mese o anno.
Periodicità e fasce orarie
I parametri possono variare in base all’ora della simulazione. Per esempio:
- Frequenze di arrivo diverse nei giorni feriali e nel fine settimana
- Tempi di elaborazione diversi nei turni del mattino e del pomeriggio
- Capacità delle risorse diversa nelle ore di punta
Per i dettagli di configurazione, consulti la documentazione sulla periodicità.
Gestione delle risorse
Gruppi di risorse
Ogni risorsa ha una capacità definita, ovvero il numero di casi che può gestire contemporaneamente.
Gestione delle code
Quando la domanda supera la capacità, i casi attendono in coda. Per impostazione predefinita, ProcessMind utilizza l’ordine FIFO (First In, First Out), così i casi vengono elaborati nell’ordine di arrivo.
Generazione dell’Event Log
Durante la simulazione, ogni esecuzione di un’attività viene registrata nell’Event Log generato:
| Campo | Descrizione |
|---|---|
| ID del caso | Identificativo univoco di ciascun caso (generato in sequenza) |
| Attività | Nome dell’elemento BPMN |
| Timestamp di inizio | Momento in cui è iniziata l’attività |
| Timestamp di completamento | Momento in cui è terminata l’attività |
| Risorsa | Risorsa che ha eseguito l’attività |
| Attributi | Eventuali attributi del caso in quel momento |
Questo log segue i formati standard degli Event Log e può essere analizzato con tutti gli strumenti di ProcessMind.
Limiti della simulazione
| Limite | Valore | Scopo |
|---|---|---|
| Numero massimo di eventi | 5.000.000 | Evita che la simulazione prosegua senza controllo |
| Durata minima | 1 secondo | Garantisce timestamp univoci |
Inizi in piccolo, poi estenda la simulazione
Quando configura una nuova simulazione, inizi con un periodo breve (alcuni giorni o settimane) per convalidare la configurazione. Dopo aver verificato che il modello si comporta correttamente, estenda la simulazione a periodi più lunghi.