What is Process Simulation?

Process simulation allows a process model to be tested for performance characteristics without actually deploying the process. Each simulation run is a hypothetical (what-if) test varies parameters such as work volume, worker availability, etc. to provide a performance summary of the process design under those conditions. Some parameters are set to fixed values by the process analyst performing the simulation test. Other parameters are allowed to change within a range of possible values just as they would in real life. In effect, the simulation run shrinks the scale of real time (weeks, months, years etc.) to just a few seconds, minutes or hours to predict long term process behavior without the time and cost of actual deployment and observation.

Who Simulates Processes?

Process simulation is most commonly used by process analysts familiar with the production behavior patterns of processes. Among these analysts, there are two logical roles, usually filled by the same person. First, the Simulation Designer sets the parameters of a simulation scenario based upon their knowledge of the process under test. Their knowledge combines;a theoretical understanding of how various simulation parameters can affect outcomes as well as practical aspects of this particular process such as which statistical deviations best represent the actual work environment, etc.

The second role, the Process Analyst, uses established simulation settings but varies aspects of the process design to carry out what-if analysis on the design such as increasing the number of people applied to an activity, changing the Calendar, splitting work across activities, etc. Infinity Process Platform offers other possible modes of simulation beyond this description, but these roles are still generally involved.

Why Would I Simulate A Process?

Business Process Management emphasizes the continual improvement of processes and informed decision making related to these improvements. As an organization becomes more aware of its processes, and manages them explicitly, the need arises to predict the behavior of process changes, before they are actually implemented. Management and other process specialists will increasingly require data to drive their decisions. Some of this information can be gathered from process reports on deployed processes used in production. But reports typically only provide insight into the existing process or possibly a range of minor variations. That is, reports only show what has or is occurring and may inform some simple changes. If the process will change substantially in any dimension (flow of process, number of workers applied at various activities, business calendar changes, etc.) then simulation is more appropriate for predicting the impact of the change. Combining management and process design discipline with simulation, and other facilities such as reporting, the process-aware organization can manage every phase and interaction of their process improvement. This approach is applicable irrespective of the broader process framework being applied (e.g. Six Sigma, CMMI, ISO 9000, etc.).

When Should I Simulate A Process?

Infinity Process Platform offers a range of process related features for each phase of process improvement program. For the purposes of understanding simulation within Infinity Process Platform, it is first useful to distinguish between As-Is and To-Be processes. We will follow the convention that the As-Is process is any process currently in place (for current purposes assume this is a Infinity Process Platform managed process), and the To-Be process is a process design still being developed prior to deployment.  

There are three times when a process is typically simulated

  1. When the To-Be process needs to be validated, or improved prior to first deployment
  2. When an As-Is process needs to be analyzed or improved
  3. When reports need to be tested but there is no suitable Infinity Process Platform data yet available

We will consider these three cases separately from a high level view of the Infinity Process Platform Development Process.

To-Be Processes

  1. Design the To-Be process using the Infinity Process Platform designer
  2. Test/correct the To-Be process for logical consistency using the debugger or interactive Workflow Execution Perspective (or both)
  3. Test/correct the To-Be process for operational performance potential using simulation
  4. Deploy the To-Be process to production (or another environment outside development)

In To-Be processes, there is no run time operational data available, so the only baseline for process performance is the one configured by the Simulation Designer. That is, the baseline for evaluating performance is hypothetical, not real since the operating parameters are assumed by the Simulation Designer. This does not mean the simulation outcomes are not useful. They are more useful than no outcomes or testing whatsoever, and by testing a few variations, a reasonable degree of confidence can be reached prior to deployment.  

Once the To-Be process is being used, it transitions to As-Is status.

As-Is Processes

Now simulation is used in somewhat different manner.

  1. Select an As-Is process that needs operational performance improvements, or other analysis.
  2. Configure simulation to baseline its assumptions using the Infinity Process Platform operational data of the selected As-Is process
  3. Test/correct the As-Is process for operational improvement potential using simulation
  4. Deploy the revised As-Is process to production (or another environment outside development)

In the As-Is process, there is run time operational data available and it serves as the baseline for process performance. No assumptions about process behavior are necessary since there is a history to draw upon. Of course, it is possible for the Simulation Designer to mix both real and hypothetical simulation parameters and this might be called for if the process design changes substantially (there may be other good reasons as well).

Finally, the As-Is process could be simulated using only hypothetical assumptions just like a To-Be process; this approach ignores the historical data available about As-Is process. This might be appropriate if it is known the operational data was collected under circumstances (operating conditions) that will be significantly different before the next version is deployed. This approach is explained in more detail in the Retrieve from Audit Trail section.