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.
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 business calendar, splitting work across activities, etc. Stardust offers other possible modes of simulation beyond this description, but these roles are still generally involved.
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.).
Stardust offers a range of process related features for each phase of process
improvement program. For the purposes of understanding simulation within Stardust,
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 Stardust 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
We will consider these three cases separately from a high level view of the Stardust Development Process.
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.
Now simulation is used in somewhat different manner.
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.