Some components may look slightly different in your library depending on whether you have custom configuration. 

Process simulation lets you do several things that can’t be done with a static process model:

• See the effects of variations in demand – the volume of work a process needs to handle – over daily, weekly, and monthly cycles
• See the effects of variations in supply – the resources required to perform activities – over daily and weekly cycles
• Discover and understand bottlenecks that may be causing excessive lead times or re-work costs
• Balance reduction in lead time, by adding resources at bottlenecks, against resource costs
• Compare the effect of different resourcing scenarios on existing As Is and planned To Be processes

Running a simulation

To run simulation on a process, first pick “Simulation HTML” from either the Author’s Output HTML menu, or the Change output dropdown on the ACTIONS menu of another (process) output. The simulation screen should look something like this:

• If there are multiple process diagrams in the same model, simulation will only run on the first process.

Press the RUN button at the left of the toolbar to start a simulation, and the setup dialog will appear:

You can simulate a period of one or more days, weeks or months, starting from any required date.

You can simulate up to four scenarios for comparison purposes. The As Is process is shown first, followed (unless no transformations are defined in the model) by the To Be. Any available alternative scenarios (see later section) are shown indented beneath the As Is and To Be processes.

Try your first simulation for a month, to get a feel for how long it will take to run. The time taken to run a simulation depends on the volume of instances (and parallel paths, if any) created, and on the complexity of the process. Simulating a process handling twenty instances a day for a year, will take roughly as long as one handling a thousand a day for a week.

• Scenarios that generate a large (in the thousands) backlogs will take considerably longer to run.
• If you switch to another browser tab or window while the simulation is running, after a while it will pause, and only resume when you return to the window.

Click the Run button in the dialog, and the simulation will first run a warm-up, to get the process into a steady state – without this, instances will run through the process unrealistically quickly at first, before levelling off when the load reaches normal levels.

The toolbar shows warm-up progress as a percentage.

While the simulation is running, you can monitor the build-up of work on the diagram: as the work increases (or the resources available to perform it decrease), small bars appear at the side of activities showing the current work in progress.

If you hover the mouse over a process step, a popup will appear showing basic statistics for the step:

When running multiple scenarios, you can select a different one to watch using the Scenario dropdown on the toolbar.

Process Simulation defaults

• • • • Annual volume and Max annual volume determine the overall input volume for the process. If no volumes are specified, Simulation will generate a thousand instances per year.
      • Costs are always shown as Annual figures. You can choose to break these down further either by Unit of volume or Hour of elapsed time.

• • • • “Breakdown costs by” lets you view simulated costs by unit or by hour, as well as the default annual costs.
      • The “Use role-based variable cost model” checkbox provides optional support for the cost model used by the older Transformation HTML output : this lacks support for fixed costs, and relies entirely on the estimated wait times defined for each activity. Simulation only uses estimated wait times for activities that have – or whose lanes have – no resource schedules defined: otherwise, an activity’s wait times represent the time needed for the required resources to become available.
      • The warm-up period defaults to one month, but you can modify it in Author, along with other simulation parameters, on the Simulation tray for the process

Simulation Output

Simulation Output Summary

The sidebar at the left side of the screen lets you view different aspects of the simulated process. The Summary page shows key process metrics and, if multiple scenarios are simulated, which performed best for each metric, with each scenario shown in its own color.

When the mouse hovers over any of the tiles at the top, the cursor changes to a hand pointer: click the tile, and a popup window opens to the right, showing an explanation of the metric, and how to affect it via changes in the process or resources.

The Key Metrics table provides summary data behind the comparisons:

• Annual Cost shows the cost of running the process for a year: the per unit (of process volume) or hour cost is also shown. The COSTS page provides a detailed breakdown of the individual contributory costs.
• Lead Time shows the mean, longest, shortest and median process start-to-finish times. The longest may be of interest for SLA reasons: the SCENARIOS page lets you investigate ‘long tail’ lead times in detail (down to individual events).
• Work Time shows the mean, longest, shortest and median process work time. Any notable variation in work time will reflect process, rather than resourcing, changes: the ACTIVITIES page lets you investigate these, as well as bottlenecks that may impact lead times.
• Throughput shows the projected annual throughput, along with the percentage of input volume this represents (in red if less than 85%) and the average backlog (or the peak if the backlog rises throughout the simulated period).
• Utilization shows the percentage of available FTE resource time spent doing work – if no FTE resources are defined, then no value is shown. Too low a value may indicate over-resourcing – but may be needed to cope with peaks in demand without compromising lead time. Too high a value may result in localized resource shortages, leading to longer lead times.
• Automation shows the percentage of activities in the process that are automated.

The charts immediately below the Metrics table show a line for each scenario, representing the distribution of process lead and work times between their minimum and maximum values:

The legend above the charts lets you focus on one or more scenarios: click any of the items (in this case, As Is or To Be) to remove the associated line from all the charts on the page; click it again to restore it. This is useful when comparing three or four scenarios.

The last two charts on the page show how many instances were completed for each day or week of the scenario, and what the backlog was at the end of each:

Finally, a list of the differences between the As Is and To Be states is shown:

RESOURCES

The Resources page has two charts, showing the cost and utilization for each resource.

• If no resource schedules are defined for the process, a message to that effect will be shown in place of the utilization chart – and if no costs are defined, a corresponding message will replace both charts.

The table beneath the charts shows all the resources defined in each scenario, with a row for:

• Each resource schedule provisioned for a lane: these act as shared resources for all the activities in the lane.  Any activity without resources of its own, or which is currently using all its own resources, will use a lane resource, if available.
• Each resource schedule dedicated to an activity: these are never made available to any other activity.

The columns shown for each row are:

• The lane (in bold) or activity to which the resources are allocated
• The resource Schedule name, Type (FTE, system or other) and Costs (Fixed or Variable), with the unit cost and unit type –
  • year, month or week for fixed costs
  • day, hour, unit (of process volume) or use (at activity) for variable costs

followed by columns for each scenario:

• The number of resources (for fixed costs) or days/hours/units/uses (for variable costs) to multiply the unit cost by
• The resulting Annual Cost
• The detailed unit (units or hours) cost
• The number of FTEs used (only for an FTE resource schedule)
• The Utilization percentage (of the available FTE capacity actually used)
  • If the role-based variable cost model is enabled, as described in the Setting Process Simulation Defaults sidebar on page 2, a row will be shown for each activity that has a role-based cost. The Resourcing columns will read “role-based variable costs”.

Defining a Resource pool

To define a resource pool in Author, select the lane or activity you want it to support, and click the Resource pool tool on the Components menu.

If you have standard resource pools defined in master data, you can reference those to set the resource type, cost, and schedule.

Otherwise, picking the resource type will provide the most common default schedule –

• • • • 9 to 5, with a five-day week, for FTEs
      • 24x7 for systems and other resources

 which you can adjust as required, and you can provide your own per-unit cost.

If you leave the number available blank, simulation will allocate as many resources as it needs to minimize wait times. The cost table will show a high number of resources (and a correspondingly high cost), combined with a low utilization. Where the utilization is less than 30% or 40%, try allocating half the number of resources shown: unless there are significant bottlenecks in the process, you should find you can reduce costs without major impact on lead time.

You can allocate a percentage of each resource’s time, to represent resources that also work on other activities or processes. Simulation will use the percentage to allocate cost and availability for work.

ROI

The ROI page shows the estimated return on investment due to a transformation.

The number of years shown is taken from the ROI period set Author’s process Transformation properties. You can also set a different (from the current state) mean and maximum annual volume, and an annual growth rate, applied after each successive year of the transformation.

Cost of Operations reflects the annual running costs, including any transformation Cost of change, for each scenario.

Transformation Properties

The Investments table reflects the Cost of change, spread evenly over each month of the Roll-out period, followed by any additional Technology and (if any) FTE costs added to the future state.

The Benefits table shows the resource costs removed from the process. For FTE costs, the number of FTEs removed will be shown as well as the resulting cost reduction.

Net Profit shows the difference between the Total Benefits and Investments for each year (with losses shown in red) and Return on Investment balances Investments (Total Costs) against (Total) Benefits to arrive at the Net Savings (or Loss).

Return on Investment shows the expected % ROI: in most cases this will start negative (reflecting Transformation cost), crossing over to positive at a break-even point somewhere along the line.

ACTIVITIES

The Activities page breaks the process down into its constituent activities.

The first two charts show the activities that contribute the most wait and work times to the process.

For an activity with no (dedicated or shared) resource schedules defined, wait times are based on those defined in each activity’s Metrics tray.

Otherwise, they are the result of having to wait for resources to become available. Long waits may also be due to arrivals outside working hours (possibly because of input received from activities without resource availability constraints of their own).

Work times are always based on those defined in the activity’s Process Metrics tray.

Metrics Properties

The times shown are averaged over each instance: an activity that takes an hour, but is only performed for 50% of cases, will show a contribution of 30 minutes. The next chart shows this usage: anything above 1 represents an activity is being performed multiple times (indicating rework):

The Workload chart shows the maximum work in progress at each activity. Large values may indicate a shortage of resources:

The Activity Impact table shows the data behind the charts, with a row for each activity, and a set of five columns for each scenario, each showing the corresponding chart’s data, with an additional column showing Rework percentage (some activities may have re-work even if their usage is less than 100%):

The Activity Scheduling table provides an explanation of how each activity’s wait time is derived, with a row for each activity and a pair of columns for each scenario, showing the type of resource required, and the specific resource schedule (or schedules) used:

The resource type required for an activity depends on the activity type, as defined in the process model (possibly overridden in a Transformation):

• Undefined, User, and Manual tasks require an FTE resource
• Automated, Send, Receive, Script and Business rule tasks all require a Technology resource
• Embedded sub-processes, and both Local and External process calls, require an “Other” resource – this can be used to model long-term resource allocation for the duration of a sub-process (whose component activities will have their own FTE and Technology resource requirements)
  • The process diagram reflects these: FTE-driven activities are shown in dark blue, automated activities in a lighter blue, and sub-processes (of any kind) in palest blue.

Activity Types

You can override this using dedicated activity-level resource schedules: simulation will always use the type of the (first) resource schedule available to the activity. However, you cannot override it for (shared) lane-level resources as these are applicable to multiple activities.

SCENARIOS

The Scenarios page shows information for a single scenario – as with Diagram, you can select a different scenario to view using the Scenario dropdown in the middle of the toolbar.

The cards at the top of the page echo those in the Summary page: here, they only show the values for the selected scenario, with no comparison to any other.

The Daily Demand chart shows the number (and Total Input the cumulative number) of instances initiated from each start event on each day of the simulation, to highlight weekly and monthly variations defined via input schedules.

Defining an Input Schedule

To define an input schedule in Author, select the start event you want it to affect and click the Input schedule tool on the Components menu. Specify the average and (optionally) maximum number of instances to be created during the schedule, and the times of day and days of the week that the schedule operates (the default is 9 to 5 for a 5-day week.)

You can restrict the schedule to a fixed number of days a month by checking "Input only arrives for a part of each month" and setting the start day of the month and the number of days. To set up a 2-day end of month period, set the start date to 30. Simulation will auto-adjust the start day to match the number of days in each month. To account for non-working days: in a (non-leap) February ending on a Sunday, the volume will be produced on the preceding Thursday and Friday.

Input schedules are auto-adjusted to match the specified process volume - once you have them set up, doubling (or halving) the process volume will have the effect of doubling (or halving) the volume produced by each start event, without needing to adjust each start event's volume independently.

Below the charts are a pair of tables, showing the longest process lead and work times experienced in the scenario:

Clicking on a row in either opens a third table to the right, showing the complete event log for the instance in question. This will often explain excessive lead and work times, when the cause may not otherwise be obvious.

There is an entry for each activity visited, with a group of three or more lines, each with a timestamp and either:

• The name of the step
• The shift that picked the work up, along with how much (if any) other work was active at the time
• How long the work took to complete

Sometimes – as shown with the entry at the bottom on the right – there may be additional lines showing incomplete work being suspended at the end of the shift, and then resumed by the next shift.

Unless 24x7 resources are used, waits are likely to extend over the non-working part of a day, or over an entire weekend. This is a common explanation for unexpectedly long maximum lead times, along with a shortage of resources to do the work, reflected by a large number of active resources at the time the work is picked up.

Frequently Asked Questions

How is Work Prioritized?

Work is scheduled on a strict first-come, first-served basis. When an instance reaches an activity for which a (dedicated) resource schedule is defined, or which sits in a lane for which a suitable (shared) resource schedule is defined, then simulation will book the first available resource to perform the work.

• • A ‘suitable’ shared resource is one appropriate to the activity type:
  • User, Manual and Undefined activities – shown in dark blue in the default BPMN diagram – will use the first available FTE resource
  • All automated activities (Service, Script, Rule, Send and Receive) – lighter blue in the default diagram – will use a Technology resource
  • Process calls, and embedded sub-process activities – pale blue ting in the default diagram – will use an Other resource, if defined

If no suitable resource schedules are defined, the Wait times defined in the Metrics tray will be used to schedule the work instead.

When the first available resource is found, it will be booked from the time it becomes available, making it unavailable for the duration of the work – or until the end of the shift: whichever comes first). Unless the resource is available immediately, the task will then wait until the booked start time before work is started.

Once made, bookings are never pre-empted by new instances.

If the shift ends before the work is completed, the remaining work will then be rescheduled – otherwise, when the work is completed, the instance will move on to the next step (or steps) in the process.

The ‘work in progress’ at an activity (shown by the red bars on the diagram) represents both instances currently being worked on, and instances waiting for their work to begin.

If two instances arrive at exactly the same moment, then the instance that was initiated first will take precedence and be scheduled before the other.

What are “Alternative Scenarios”?

As well as simply comparing the current and future state of a process, you can compare up to 4 alternative scenarios at a time (comparing more than four becomes confusing for the user).

Creating alternative scenarios

You can create any number of alternative scenarios, using the Author’s Scenario component tool. Once created, three new components are added to the toolbar. The Scenario lane and Scenario activity components let you define alternative resource schedules for the lanes and activities in the process, and the Scenario event component lets you define alternative input schedules and volumes for start events.

You can restrict a scenario to use with only the Current or Future state, and set a different overall volume, via its properties:

You can create any number of alternative scenarios, using the Author's Scenario component tool.  Once created, three new component are added to the toolbar.  The Scenario lane and Scenario activity components let you define alternative resource schedules for the lanes and activities in the process, and the Scenario event component lets you define alternative input schedules and volumes for start events.

You can restrict a scenario to use with only the Current or Future state, and set a different overall volume, via its properties:

To set different resourcing for a lane or activity,

• • • • • Add a Scenario lane or activity to the scenario
        • Select, from the dropdown, the process lane or activity to modify

Use the same approach to set different input schedules for a start event.

The simulation RUN dialog will now offer your additional scenarios, grouped under the standard As Is and To Be scenarios. Any scenarios restricted to either the Current or Future state will only appear in the relevant group.

You can select a maximum of four scenarios to run at any one time: once four are selected, further scenarios are disabled.

When run, the Scenario dropdown on the DIAGRAM and SCENARIOS pages lets you choose between any of the selected scenarios. The ROI page shows the difference between the As Is and the LAST selected scenario.

The remaining pages each provide a side-by-side comparison of each scenario, using a consistent color scheme, as shown in the following screenshots.

The “For scenario” selector above the first chart on each page can be very useful when comparing more than two scenarios…