more information about these options, please refer to examples for each level.

For each simulation level follow these steps:

Collect process data for the simulation.
Add the data to the relevant shapes in the diagram.
Interpret and present the outcomes.

1. To simulate your process model, click the Simulation View button on the ribbon. Doing so will
display your process in read-only simulation mode.

2. The shapes that require information will be highlighted according to the simulation level in scope.
Note Bizagi will retain the level you are currently running once you save the model returning to the
Process Model view.

Copyright © 2013 - Bizagi 245

 3. Select each highlighted shape in turn and enter the information.

4. Once all the data has been added, click Run to launch the Process Simulation window.

246 Copyright © 2013 - Bizagi

5. Click Start to run the simulation. When you run a simulation, it will show an animated view of the
process in execution and the the flow of tokens between the activities.

You may click the Stop button at any time to end the simulation.

Copyright © 2013 - Bizagi 247

 6. Once the simulation has run, the outcomes will display.
Click Results to view the outcomes.

7. Click the Export to Excel button, located at the bottom left, to transfer the Results chart to Excel.

8. Process to the next level of simulation and repeat step 2-8.

248 Copyright © 2013 - Bizagi

 9. To return to the Process Model view, click Close Simulation View.
Save your model for Bizagi to retain the current simulation level, returning to the Process Model view.

For information about how to manage scenarios, please refer to Scenarios

Note: The simulation engine does not support the pattern modeled in Transactional Process, Change
Management and Ad Hoc, from our Process Central.

7.2.1 Simulation levels

Bizagi Simulation comprises of four levels. Each subsequent level incorporates additional information
exhibiting more complexity than the preceding one, thereby providing a detailed analysis of your
processes. Levels are not interdependent, , you may start at any level if you hold the required process
data .

Level 1 - Process Validation: The first and most basic simulation level to evaluate the
structure of the process diagram.

Copyright © 2013 - Bizagi 249

 Data: It requires estimated percentage splits of sequence flows to provide a basis for routing. It also
needs the value of the trigger counter contained in the Start Event shape.

Results: The outcomes show all paths activated during the execution and whether all tokens actually
finished. Additionally, it evaluates how many tokens passed through each Sequence Flow, Activity and
End Event.

Level 2 – Time Analysis: Second level of simulation to measure the end-to-end process
time.

Data: Apart from the data entered in Process Validation, estimated timings (service times) of each
activity and the interval time between token generation is required. This data can either be constant or
samples from statistical distributions 1.

Results: The results show process throughput times for tokens, presented as minimum, maximum,
mean and sum (total of all processing times). Similar results can be presented for individual key
activities.

Level 3 – Resource Analysis: Predicts how the process will perform with different
levels of resources. This level of detail provides a reliable estimate of how the process will perform in
operation.

Data: In addition to the data entered in Time Analysis, this level includes the definition of resources
(and/or roles): how many are available and where they are used. Due to the inclusion of resources, the
activity times should be adjusted to represent the actual work time; delay due to unavailability of staff
will be explicitly indicated.

Results: The structure of the results is similar to Time Analysis. Also, the time spent, the time spent
busy or idle for each type of resource is presented.
This level assume an unlimited number of resources.

Level 4 – Calendar Analysis: Includes calendar information that reflects the process
performance over dynamic periods of time, such as shifts, days schedules or weeks.
By default Bizagi includes a chosen calendar that works 24/7. If no calendars are defined, Bizagi will
assume that the defined Resources will always be available.

Data: Apart from the data entered in Resource Analysis, it includes the definition of resource
calendars.

250 Copyright © 2013 - Bizagi

Results: The structure of the results is similar to Resource Analysis.

EXAMPLE
To better illustrate each of the simulation levels let us consider an Emergency attendance process. In
this process a call center receives a report of an emergency. Upon receiving the call, a call center agent
enters details on the person affected, the symptoms and the physical address where the emergency
occurred.

On receipt of the report, a qualified nurse classifies the emergency according to its severity.
Green: Low severity. The patient can be easily stabilized.
Yellow: Medium severity. The patient requires special attention but can be stabilized at the place of
emergency.
Red: High severity. The patient must be collected and taken to the nearest hospital.

According to the priority assigned, the Emergency attendance department presents a different level of
response.

Green: This triage is assisted by a quick response vehicle (i.e. a motorcycle) carrying two people: a
paramedic and a doctor.
Yellow: This triage is assisted by a basic ambulance having a doctor, nurse and a paramedic on
board.
Red: This triage is assisted by a fully equipped ambulance holding two doctors, a nurse and a
paramedic.

If the emergency is green or yellow, the process finishes once the response team arrives at the at the
place of emergency.
If the emergency is red, the fully equipped ambulance transfers the patient to the nearest hospital.
During the transfer a nurse carries out the necessary paperwork to ensure quick admittance.

When the patient arrives at the hospital with the necessary paperwork, the receptionist will be able to
admit the patient quickly and provide medical assistance immediately.

Copyright © 2013 - Bizagi 251

 This process must be carefully analyzed in order to reduce the time between receiving the request and
providing medical assistance (at the place of emergency or the hospital). Here, time is life. Bizagi
Simulation will help us to make clear decisions to best design the business process and reduce the
emergency wait time.

1. Refer to BPSim specification to review statistical distributions supported and their explanation.

7.2.1.1 Level 1 - Process Validation

Overview
The first level of the simulation validates the Process Model, making sure the process passes through
all the sequence flows, and behaves as expected.
Resources, processing times and costs are not included in this level. Such parameters will be included
later in subsequent levels.

When validating a Process Model the simulation results will show if:
Gateways are synchronized.
Messages are synchronized.
Decisions probabilities are correctly assigned.
Routing behaves as expected.
All tokens have ended.

Bizagi offers real-time animation of simulations to easily identify problems. The Results report will show
the behavior during execution

252 Copyright © 2013 - Bizagi

Defining the input data required for this level
In the Process Validation level you will note that only Start Events and Gateways are enabled for
editing. For this level you need to define:

Max.arrival count: Define the number of token instances the process will generate (or trigger).
We recommend defining a large enough number (at least 1000) to allow the execution to stabilize and
present reliable outcomes.
Select the Start Event of the process and click the Gear icon on the pie menu. Enter the Max.arrival
count in the pop-up window.

Note:
The simulation will finish when one of these options happens first: sceario's duration is reached, max
arrival count is reached.
When you define a scenario duration, (in the scenario´s configuration) the simulation will finish once
this duration is reached, disregarding the Max arrival count.
The same applies the other way around: once the max arrival count is reached the simulation will
finish disregarding the scenario's duration.

Gateways routing: Inclusive and exclusive Gateways have activation probabilities. Probabilities are
values between 0 and 100%.

Copyright © 2013 - Bizagi 253

 Select the Gateway and click the scroll arrow icons ( ) to set the probabilities.

If you do not define probabilities for the paths, they will be equally distributed.

Running the simulation

Once the required data for this level have been defined, click the Run button to execute the simulation.

254 Copyright © 2013 - Bizagi

In the new window, click Start to run the simulation.

When running a simulation, the following analysis data will display:

Copyright © 2013 - Bizagi 255

 Number of completed tokens.
Number of token instances created.
Number of instances that activate each shape.
Number of finished instances.

Results
When the simulation is finished, view the results by selecting the Results option.

For this first level, the results of the simulated outcome will contain the following information:

256 Copyright © 2013 - Bizagi

 Name: Identifies the specific BPM shape for which the results are displayed.
Type: Identifies the element type of the BPM shape.
Tokens completed: Indicates how many tokens were processed (instances) during the execution of
the simulation.

You can transfer the results report to Excel by clicking the Export to Excel button.

Example: Validating the Emergency attendance process

We wish to validate the process flow of the Emergency attendance process:

Copyright © 2013 - Bizagi 257

 Define the required input data for this level, namely the max.arrival count and the probabilities for all
decision Gateways

1. In this example we will generate 1000 token instances. Click the Start Event and then the Gear icon.
Set the control's value to a 1000.

258 Copyright © 2013 - Bizagi

2. Define the probabilities for all outgoing paths of the Gateway. Suppose the emergency department
has estimated, based on historical data, that the probabilities for the different sequence flows are:
Green: 20%
Yellow: 30%
Red: 50%
Define each probability for the Gateway named Triage type.

Copyright © 2013 - Bizagi 259

 3. Parallel Gateways always activate all outgoing sequence flows; therefore, it is not necessary to
define probabilities for this Gateway.

4. Click the Run button.

Now, click Start to run the simulation. Note how the number of completed events are displayed in
execution.

When the simulation is complete, select Results.

260 Copyright © 2013 - Bizagi

Analyzing the results
The results obtained are:

Analyzing the results we conclude that something is wrong. The number of tokens (1000) created at the
Start Event of the process differs to the sum of tokens completed at the End Events (1006+311+186).

Copyright © 2013 - Bizagi 261

 Can you identify what is wrong in the flow?

If you watch the diagram carefully, you will see there is no point of convergence, that is, no shape has
been defined to synchronize the paths that exit the Parallel Gateway.

It is necessary to merge the outgoing flows into a single flow before the token continues to the next
activity. To do this, include a Parallel Gateway (as a convergence element) to synchronize them.

Once the change is done, Run the simulation again. Looking at the new results we can see that all is
working as expected: The number of tokens created (1000) is equal to the sum of tokens completed
(483+315+202). In addition, each token is passed correctly to the triage based on the probabilities
defined.

262 Copyright © 2013 - Bizagi

7.2.1.2 Level 2 - Throughput time analysis

Overview
The second level of the simulation is useful in measuring end-to-end process time.
Here, resources are not included; Bizagi assumes an infinite capacity to avoid delays in the process
flow. This is the best case scenario under the given flow and processing times.

Defining the input data required for this level

In addition to the information specified in the previous level, the following must be defined in the
throughput Time Analysis:

Arrival interval time: Defines the time interval between token instances generation. Instances
will be created until the max.arrival count is reached. This applies to Start Events, Activities that start
processes or Timer Events.
Select the Start Event of the process and click the Gear icon on the pie menu. Set the value for the
control.

Copyright © 2013 - Bizagi 263

 One option is to define the arrival interval time as a constant by entering a value. The time units for
this value are defined in the scenario´s configuration.
In the following image tokens instances are generated every 5 minutes.

Alternatively, define a statistical distribution. Click the advanced icon alongside the field to view and
select a distribution.

264 Copyright © 2013 - Bizagi

Once selected, you will be able to set the parameters of the distribution.
In the following image the time between generation of tokens instances is exponentially distributed with
mean equals to 5 minutes. Tokens will be generated until 100 are reached.

Processing times: Defines the amount of time an Activity or Event needs to process a token. That
is, it defines a service time period from the moment a token arrives at an Activity or Event until it is

Copyright © 2013 - Bizagi 265

 executed.
Click the Activity or Event. Select the Clock on the pie menu, and enter a processing period in the Time
Control.

You have the option of defining the processing time as a constant by entering values in the
corresponding units.

Alternatively, define a statistical distribution. Click the advanced icon alongside the field to view and
select a distribution.

266 Copyright © 2013 - Bizagi

Once selected, you will be able to set the parameters of the distribution.
In the following image the processing time of a token in a specific activity is normally distributed with
mean 5 minutes and standard deviation of 3 minutes.

Running the simulation

Once the required data for this level have been defined, click the Run button to execute the simulation.

Copyright © 2013 - Bizagi 267

 In the new window, click Start to run the simulation.

When running a simulation, the following analysis data will display.

Number of tokens completed.

268 Copyright © 2013 - Bizagi

 Average time per activity.
Total processing time per activity

Results
When the simulation is complete, select Results to view the outcome.

For the Time Analysis level, the results of the simulated outcome will contain the following information:

Name: Identifies the specific BPM shape for which the results are displayed.
Type: Identifies the element type of the BPM shape.
Tokens completed: Indicates how many tokens were processed (instances).
Tokens started: Indicates how many tokens arrived at the shape.
Minimum time: Indicates the minimum processing time of the shape.

Copyright © 2013 - Bizagi 269

 Maximum time: Indicates the maximum processing time of the shape.
Average time: Indicates the average processing time of the shape.
Total time: Indicates the total time employed to process the shape.

You can transfer the results report to Excel by clicking the Export to Excel button.

Example: Performing a time analysis for the Emergency

attendance process
In order to provide a general insight into processing times, the emergency response department has
decided to perform a time analysis.

For this analysis the following assumptions have been made:

Necessary resources to perform activities have infinite capacity.
The expected time between reports is 5 minutes.
The simulation will evaluate a period of 1 week.
The estimated processing times for each of the activities are fixed as shown in the next table:

Activity Processing time (min)

Receive emergency report 4

Classify Triage 5

Manage patient entry 11

Pick up patient 20

Arrive at patient place QAV 7

270 Copyright © 2013 - Bizagi

 Arrive at patient place BA 10

Authorize entry 4

1. Define trigger times. To do so, click the Start Event and then the Gear icon on the pie menu.
For this example, the expected time between reports is 5 minutes, so set the time to this value. Note
the value entered is in minutes.
For more information about units please refer to Scenarios.

2. Define the Activities' processing times.

Click the Activity, select Clock on the pie menu and set a value for the Time control.
In the following image the processing time for the first activity is set to 4 minutes.

Copyright © 2013 - Bizagi 271

 3. Once all the processing times have been defined, run the simulation. Click the Run button.
Note the simulation shows analysis findings for each shape in real time as it executes, such as average
time, total processing time and the number of completed tokens.

4. When the simulation is finished, select Results to view the outcome.

272 Copyright © 2013 - Bizagi

Analyzing the results
As we mentioned before, the results on this level give us a general insight into the cycle time of the
process. For this specific case we are able to identify the expected time a person has to wait from the
moment the emergency is reported until medical attention is received.

Copyright © 2013 - Bizagi 273

 Based on the results, we can conclude:

A patient waits at least 16 minutes before receiving medical attention.

A patient waits no more than 33 minutes for medical attention.
The expected time a patient waits to receive medical attention is 25,06 minutes.

7.2.1.3 Level 3 - Resource analysis

Overview
This analysis shows the potential effect of resource constrains on process performance. Remember
that a Resource is defined as a person, equipment, or space necessary for the execution of a specific
task.

In the previous level, Time Analysis, we assumed infinite resource capacity, that is, activities are able to
process infinite quantity of tokens at the same time. However this assumption is not practical at all. In
real terms there are always resources constraints.

The most common issue arising from introducing resources constraints is that tokens need to wait to
be processed at a given moment. This results in bottlenecks and increase in cycle time, thereby
reducing the capacity of the process.

Money is another resource directly or indirectly involved in a process. Consequently, this level also
allows you to analyze your business operation in terms of costs.

The purpose of this analysis is to identify and minimize the impact of these constraints in terms of cycle
time and costs.

The resource analysis results will allow you to evaluate the following performance measures:

Sub- or over-utilization of resources.

Total resources costs.
Total activity costs.
Delays (time an activity waits for a resource).
A more accurate expected cycle time.

Defining the input Data required for this level

By default the Performers defined in the process documentation are defined as resources. In the
Resources Analysis level you need to define the following parameters:

Resources: Remember that a resource is a person, equipment or space necessary for the execution
of a specific task.

To define a Resource click the Resources option found in the ribbon.

274 Copyright © 2013 - Bizagi

A new window will display the available resources.
To add a new resource, click Add resource.

Select Add performer.

Copyright © 2013 - Bizagi 275

 Enter the name, description and type of the new resource. Click OK.

Availability and costs of resources:

To define availability and costs of resources, select the Resources option found in the Ribbon. The
availability of Resources determines how many resources of a given type you have as a whole (not for
a particular activity).

276 Copyright © 2013 - Bizagi

A new window will display the available resources. In the Availability tab, enter the value for each
Resources available.

To define the costs of Resources, proceed to the Costs tab.

You can define the fixed and per hour costs for each Resource. The cost units are defined in the
scenario's configuration.

Copyright © 2013 - Bizagi 277

 Resources requirements: Tasks require resources to be performed. Once you have defined the
process' resources, you have to define how many are required in order to perform a task.

To define the Resources requirements for a task, click the task and select the Resource icon in the pie
menu.

278 Copyright © 2013 - Bizagi

Select the desired resources from the list available in the Resource window.
You can select one or more resources. The AND/OR selection mode is available in order to define if all
the selected resources are required by the task at the same time or only one at a time.

For each resource selected you must define how many of them are used in the task.

Activity costs: The cost of performing an activity, that is, how much an activity costs once executed.

To define the cost of performing an activity, select the Activity and click Cost on the pie menu.

Copyright © 2013 - Bizagi 279

 Set a fixed cost amount. The cost units are defined in the scenario's configuration..

Running the simulation

Once the required data has been entered, click the Run button to execute the simulation.

280 Copyright © 2013 - Bizagi

In the new window, click Start to run the simulation.

Copyright © 2013 - Bizagi 281

 When running a simulation, the following analysis data will display.
Resource usage status.
Number of tokens completed.
Average time per activity.
Total processing time per activity
Average waiting time per activity.

282 Copyright © 2013 - Bizagi

Results
When the simulation is complete, select Results to view the outcome.

For the Resource Analysis level, the results of the simulated outcome will contain the following
information for Process and Resources:

For Process and activities

Copyright © 2013 - Bizagi 283

 Name: Identifies the specific BPM shape for which the results are displayed.
Type: Identifies the element type of the BPM shape.
Tokens completed: Indicates how many tokens were processed for each specific BPM shape.
Tokens started: Indicates how many tokens arrived at the shape.
Minimum time: Indicates the minimum processing time at the shape.
Maximum time: Indicates the maximum processing time at the shape.
Average time: Indicates the average processing time at the shape.
Minimum time waiting resource: Indicates the minimum time a task had to wait for a resource.
Maximum time waiting resource: Indicates the maximum time a task had to wait for a resource.
Average time waiting resource: Indicates the average time a task had to wait for a resource.
Standard deviation: Indicates the standard deviation of the average time a task had to wait for a
resource.
Total fixed cost: Indicates the total cost of performing a task during execution of the simulation.

For Resources

284 Copyright © 2013 - Bizagi

 Usage: Indicates the percentage of time the resource was busy.
Total fixed cost: Indicates the fixed component cost of using the resource.
Total unit cost: Indicates the variable component cost of using the resource.

Example: Performing a resource analysis for the Emergency

attendance process
In order to analyze the impact of resources constraints in the Emergency attendance process, the
emergency department has decided to perform a resource analysis.

For this analysis the following assumptions have been made:

The expected time between reports is 5 minutes.
The simulation will evaluate a period of 1 week.
Resources can be shared between activities.

The following tables respectively show:

The resources involved in this process, the current available quantity and the related costs.

Resource Quantity Fixed Cost (US) Unit Cost (US)

Call center agent 2 3 0

Nurse 2 5 0

Fully equipped 4 30 0,4

ambulance

Copyright © 2013 - Bizagi 285

 Basic ambulance 2 25 0,3

Quick attention vehicle 2 18 0,22

Receptionist 2 3 0

The necessary quantity of resources for each activity.

Activity Resource Quantity

Receive emergency report Call center agent 1

Classify Triage Nurse 1

Manage patient entry Nurse 1

Pick up patient Fully equipped ambulance 1

Arrive at patient place QAV Basic ambulance 1

Arrive at patient place BA Quick attention vehicle 1

Authorize entry Receptionist 1

The cost associated with the performance of each activity.

Activity Cost (US dollars)

Receive emergency report 2

Classify Triage 1

Manage patient entry 1

Pick up patient 0

Arrive at patient place QAV 0

Arrive at patient place BA 0

Authorize entry 1

The estimated processing times for each of the activities

Activity Processing time (min)

Receive emergency report 4

Classify Triage 5

286 Copyright © 2013 - Bizagi

 Manage patient entry 11

Pick up patient 20

Arrive at patient place QAV 7

Arrive at patient place BA 10

Authorize entry 4

Define the required input data for this level: Resources, requirements and costs.

1. Define the resources involved in the process. Create the necessary resources from the Resources
option.

2. For each resource define the available quantity, fixed cost and unit cost.

Copyright © 2013 - Bizagi 287

 3. Define the resources requirements for each activity. Click the activities and then the Resources icon.
Set the resource and number of instances to perform the activity.
For example, here we are defining that the second activity requires a nurse in order to be performed.

4. Finally, define the cost of performing each activity. Click the activity, select Cost and enter the
corresponding cost.
Here we are defining the the cost of performing the Manage patient entry activity is 1 dollar. This cost
is related to paperwork and calls.

288 Copyright © 2013 - Bizagi

5. Click Run, then select Start in the new window to execute the simulation. Note the number of
completed Events are displayed. When the simulation is finished, select Results to view the outcome.

Copyright © 2013 - Bizagi 289

 Analyzing the results
As we mentioned before, the results of a resource analysis give us a general insight into the cycle time
of the process. Consequently, we can identify how the cycle time is affected.

First we analyze the process results.

290 Copyright © 2013 - Bizagi

Compared with the best case scenario achieved in the previous level, the inclusion of resources
constraints has significantly increased the cycle times.
The minimum time remains at 16 minutes but the maximum increased to 657 minutes and now the
average is 204,91 minutes. The previous results only had an average waiting time of 25,06 minutes.
As is evident, the processing times for each activity have changed. Now, they reflects delays. The
highest average processing times are recorded at Classify triage and Manage patient. The average
waiting times confirm there is a problem in those activities. Possibly, resources used in them are not
enough.

Now lets analyze the resources results.

The usage of the resources indicates some sub and over-utilization.

For this case we confirm our hypothesis about a possible problem of resources capacity.
The nurse who performs the Classify triage and Manage patient reception has a usage of 99,91%.
This means she is utilized at full capacity and tokens have to wait until she becomes available. The
emergency department should consider increasing the number of triage nurses to reduce service
and waiting times, and thereby reducing the cycle time.

We'll see if the situation gets better including a new nurse in the available resources. Now we would
have three nurses.
Click Run to simulate the new scenario.

Analyze the new results:

Copyright © 2013 - Bizagi 291

 Introducing another resource brings us closer to the best case scenario with no process delays. The
minimum time remains at 16 minutes, the maximum now becomes 35 minutes and the average 25,26
The results also show waiting times close to 0 in the activities where they exist. The current resources
are sufficient to avoid critical delays.

The above can be confirmed from the resources results.

Usages are acceptable. Nurses now have a utilization of 69,88%.

From the resources cost perspective, there was a total cost of 84.163 US. The new cost of 86.986 US
includes the additional nurse. The increase of 2.823 US offsets the benefit in reducing the average
waiting time to 179,5 minutes.
There may be other ways to reduce the cost even further and to improve resource utilization, but for
now we can accept the state of affairs.

292 Copyright © 2013 - Bizagi

7.2.1.4 Level 4 - Calendar analysis

Overview
In addition to the resources constrains discussed in the previous level, we should also consider the
effect of resources availability over time to obtain a better understanding of true process performance.

In real scenarios, processes are subjected to ever changing conditions in the availability of resources.
Holidays, weekends, shifts and breaks restrict and define the true performance of a process.

This level predicts how a process will perform during dynamic periods of time, such as shifts, days
schedules or weeks.
At the end of this level you will obtain more accurate information on:

Sub- or over-utilization of resources.

Total resources costs.
Total activity costs.
Delays (time an activity waits for a resource).
Expected cycle time.

Defining the input data required for this level

Additional to the information required in the previous level, the following must be defined in the
Calendar Analysis:

Calendars: A Calendar defines resource capacity over certain periods of times. They define the
schedules, shifts, holidays and other time constraints to reflect the process in real life.

To create a Calendar click the Calendars option. Click Add calendar.

Copyright © 2013 - Bizagi 293

 Defining a Calendar is done in the same way as Outlook. Thus, you can configure time shifts or longer
periods of time.
In the Calendar configuration you find the following options:

294 Copyright © 2013 - Bizagi

 Name: Defines the name of the calendar. It should be short and clear in order to allow identifing the
period of time it represents. For example night shift, cooffe break, lunch hour etc.
Start Time: Defines the starting time of the calendar.
Duration: Defines the total duration of the calendar.
Recurrence Pattern: Defines the frequency with which a Calendar will be repeated. It can be daily,
weekly, monthly or yearly.
Range of recurrence: Defines the period of time for which the calendar applies.
Start of recurrence: Defines start date of the period of time for which the calendar applies.
End of recurrence Defines the end date of the period of time in which the calendar applies. It can
also be defined in terms of number of recurrences.

Click OK to save the changes.

Calendars assignment:
Additionally in this level, you have to define the availability of resources for each defined calendar.

To define the calendars assignment click the Resources option

For each Resource (row) you must define the availability for each calendar (column).
Keep in mind that if you leave a Calendar blank, Bizagi will assume the availability value of a resource is
the one defined in the Default Calendar.
This calendar includes the same resources availability defined in Level 3 (Resources Analysis).

Copyright © 2013 - Bizagi 295

 Running the simulation
Once the required data for this level have been defined, click the Run button to execute the simulation.

In the new window, click Start to run the simulation.

296 Copyright © 2013 - Bizagi

When running a simulation, the following analysis data will display.
Status of resource usage
Number of tokens completed
Average time per activity
Total processing time for each activity
Average waiting time for each activity

Results
When the simulation is complete, select Results to view the outcome. For a calendar analysis , the
results of the simulated outcome will contain the following information:

Resources (All resources)

Tab for each Resource

Name: Identifies the specific BPM shape for which the results are displayed.
Type: Identifies the element type of the BPM shape.
Tokens completed: Indicates how many tokens were processed (instances).
Tokens started: Indicates how many tokens arrived at the shape.
Minimum time: Indicates the minimum processing time of the shape.
Maximum time: Indicates the maximum processing time of the shape.
Average time: Indicates the average processing time of the shape.

Copyright © 2013 - Bizagi 297

 Total time: Indicates the total time employed to process the shape.
Min. time waiting: Indicates the minimum waiting time for the shape.
Max. time waiting: Indicates the maximum waiting time for the shape.
Avg. time waiting: Indicates the average waiting time for the shape.
Standard deviation waiting: Indicates the standard deviation of the waiting time for the shape.
Total time waiting: Indicates the total waiting time for the shape.
Total fixed cost: Indicates the total fixed cost for the shape.

Example: Performing a calendar analysis for the Emergency

attendance process
In order to analyze the impact of calendars in the Emergency attendance process, the Emergency
department has decided to perform a Calendar analysis.

The shifts for the process will be as follow:

Resource Morning shift (6:00 am - 2:00 pm) Day shift (2:00 Night shift
pm - 10:00 pm) (10:00 pm - 6:00
am)

Call center agent 2 2 1

Nurse 3 3 3

Fully equipped ambulance 4 4 4

Basic ambulance 2 1 2

Quick attention vehicle 1 2 1

Receptionist 2 1 1

1. Create the three calendars (working shifts).

Click the Calendars and add a new Calendar.
We are going to create the Night shift. In the Calendar configuration options enter the following
information:

Name: Type Night Shift

Start Time: This calendar starts at 10:00 pm (see table above) so this is the start time
Duration: This calendar starts at 10:00 pm and finishes at 6:00 am so the calendar duration is 8
hours.
Recurrence Pattern: This calendar is repeated everyday so select Daily and type 1 in the alongside
field.
Start of recurrence: This calendar applies always so the start date is the same start date of the
simulation.
End of recurrence This calendar applies always so it has no end date.

298 Copyright © 2013 - Bizagi

Repeat the procedure for the morning and day shift calendars.

2. Through the Resources option, set the availability of resource for each calendar created previously.

3. Click the Run button. When the simulation is finished, select Results to view the outcome.

Copyright © 2013 - Bizagi 299

 Analyzing the results
Recall that incorporating ever changing conditions in the resource availability gives us a better
understanding of true process performance.
The results of the calender analysis will reflect this change. Let us analyze them.

First we examine the process results:

The average time a patient waits for assistance suffered a little increase from 25,06 minutes to 25,48
minutes. This is not significant.
The increase from 35 to 39 minutes in the maximum time can be explained by the existing waiting

300 Copyright © 2013 - Bizagi

 times in some of the activities of the process that were not present in the previous level.
The Arrive at patient place BA task has a maximum waiting time of 20 min. It could be critical for a
patient, however the average waiting time is 0,74 min. It is clear that high waiting times in this task
are rare.
Despite the presence of waiting times, they are not regarded critical.

The resources usage results will highlight any critical capacity problems.

The highest usage is for the Nurse. Remember that this resource performs two activities in the
process: Classify triage and Manage patient entry.
From the Process results we can conclude that the usage of nurses is not at full capacity since the
waiting times of the associated activities are not significant.
Assigning shifts and resources did not overtly affect the process in general; therefore, we can
conclude that the allocation is adequate for our purpose.

7.2.2 Scenarios
Bizagi Simulation allows you to create multiple scenarios for your process model, to analyze different
combinations of data input and observe many possible outcomes. Scenarios are completely
independent from one another, from the definition of the scenario itself to the data included in each
shape of the model.

When you are in Simulation View, the model will display a default scenario created by Bizagi. All
information entered belongs to that specific scenario. The name of the process scenario being
simulated is displayed above the model:

Copyright © 2013 - Bizagi 301

 Click the Properties button in the ribbon to manage the scenario.

302 Copyright © 2013 - Bizagi

For each scenario provide the following information:

Name: The name of the scenario. It should be clear and descriptive to easily identify the simulation
conditions.
Description: A detailed description of the new assumptions and changes made to the process.
Author: The person or group that created the scenario.
Version: The version number of the scenario.
Start: Date on which the simulation starts.
Duration: Period of time during which the process will be simulated.
Base Time units: The units in which time metrics and results will be displayed.
Base currency unit: The units in which cost metrics and results will be displayed.
Replication: Number of simulations for the given scenario.
Seed: Value of the seed used to generate random numbers.

Note:

We recommend using 30 replications to make sure the simulation reaches a stable state.
For the replications to take place, keep in mind that you should run the What-If analysis which
provides direct results (instead of using the graphical simulation with Real-time display at the Run
option). Notice that you may select only 1 scenario, to run the 30 replications.

Note:

The simulation will execute according to the duration defined disregarding the max arrival count.
If the max arrival count is reached and the duration is not, the resources will remain idle and the
results may not reflect the reality.
If no duration is defined, the default duration is 30 days.

Create scenarios
To create a new what-if scenario, select the What if option (found in the Simulation group on the
ribbon) and select Manage scenarios.

Click New. Two actions are available:

Duplicate selected scenario: Creates a copy of the current scenario with the same parameters
configurations (number of resources, processing time, calendars etc).
Blank scenario: Creates a scenario with blank simulation parameters.

Copyright © 2013 - Bizagi 303

 Edit the new scenario to add specific information to your activities.

7.3 What If analysis

What if analysis is a powerful tool for improvement that evaluates how strategic, tactical or operational
changes may impact the business . Through different scenarios you will be able to perform a true-to-
life analysis of your processes without putting your business operation at risk.

304 Copyright © 2013 - Bizagi

Bizagi allows you to easily carry out what-if analyses on your processes to evaluate, understand and
predict the effects of your decisions over given performance measures. You will be able to perform
What if analysis in any of the simulation levels.

You will be able to answer questions like:

How would the processing time of a case decrease if the number of available resources is doubled?
What would be the cost/benefit rate of reducing the process time in a specified activity?
What would be the effect of altering the working shift configuration in the operational cost and
service level?

The reports generated in What if analysis will display the results of all scenarios to be easily
compared.

Note:

We recommend using 30 replications to make sure the simulation reaches a stable state.
For the replications to take place, keep in mind that you should run the What-If analysis which
provides direct results (instead of using the graphical simulation with Real-time display at the Run
option). Notice that you may select only 1 scenario, and in this example we used 100 replications.

Using What if analysis

To perform a what-if analysis, first create the desired scenarios and then run the simulation, selecting
the scenarios for comparison.

Compare scenarios
When each scenario with its relevant data has been created, click What if and mark the scenarios you
wish to compare. Thereafter, run the simulation to generate the reports.

Copyright © 2013 - Bizagi 305

 The Report will compare the scenarios, including all information for the selected analysis level. For
readability, disparities are highlighted in color.
We recommend comparing two scenarios at a time; with many scenarios the results evaluation may
become too complex.

7.3.1 What if analysis example

Based on the calender analysis example, we will reduce the number of resources for all shifts and see if
the processing times are affected.
To do this, we will create an additional scenario by duplicating the original one:

306 Copyright © 2013 - Bizagi

In Scenario 1 the resources availability is:

Resource Morning shift (6:00 am - 2:00 pm) Day shift (2:00 Night shift
pm - 10:00 pm) (10:00 pm - 6:00
am)

Call center agent 2 2 1

Nurse 3 3 3

Fully equipped ambulance 4 4 4

Basic ambulance 2 1 2

Quick attention vehicle 1 2 1

Receptionist 2 1 1

In Scenario 2 the resources availability will be altered as follows:

We reduced Nurse, Fully equipped ambulance and Receptionist. We increased basic ambulance and

Copyright © 2013 - Bizagi 307

 quick attention vehicle.

Resource Morning shift (6:00 am - 2:00 pm) Day shift (2:00 Night shift
pm - 10:00 pm) (10:00 pm - 6:00
am)

Call center agent 2 2 1

Nurse 2 2 2

Fully equipped ambulance 2 2 2

Basic ambulance 2 2 2

Quick attention vehicle 2 2 2

Receptionist 1 1 1

We run the what-if analysis including both scenarios.

Mark the scenarios and click Start.

308 Copyright © 2013 - Bizagi

As soon as the analysis is complete, the Results will display.
Color is used to emphasis differences between scenarios. Values that differ are highlighted in red.

The resources results show that the usage of resources increased, especially for the Nurse, now at full
capacity. This gives us an idea that there will be delays and patients will be held waiting. The positive
result is that costs are reduced.

Copyright © 2013 - Bizagi 309

 Analyzing the outcomes we note that:
The completed tokens have been reduced. This means we are tending to less patients with this new
resources distribution.

Waiting time has increased in several activities:

310 Copyright © 2013 - Bizagi

In the whole, this new scenario is not beneficial. The hospital cannot afford such high waiting times
since it offers a health care service.
We recommend reverting the resources availability for Nurse and Ambulance to their original values,
and changing the availability of other activities. Run the simulation again and examine the results.

Copyright © 2013 - Bizagi 311