Model Strategy & Simulation

Most BPM systems offer some form of simulation capability. Simulation capabilities range from the very simple ability to walk through a process, to very sophisticated case-arrival/activity performance models, and even to goal-seeking optimization capabilities.  In this post I explore the relationship between simulation and Model PReserving/Transforming Strategy. 

In an earlier post, I introduced the concept of a “Model Preserving Strategy” versus a “Model Transforming Strategy” and defined them as two approaches that a BPMS can take in the lifecycle of a business process.

The usefulness of simulation is often debated, but let me categorize people into two camps: simulation optimists and simulation pessimists.

The simulation optimist probably expects a little too much detailed insight into how future cases will flow through the process. The optimist expects precise quantitative measures of what everyone in the process will be doing. Simulation can provide this information, but in order to do so, the simulator must be provided with precise quantitative measures on the cases that will be coming, the amount of time it takes to handle ever activity, and precise models of the workers who will be doing their jobs. This works passably only in cases where you have extremely large numbers of essentially identical cases and for job where the individual differences of the skill, knowledge, or background of the workers makes no difference at all. Even in these cases, tracking down accurate information on activity time and case distributions can take more effort than the value of the result of simulation. While the optimist has inflated expectations, there is no denying that simulation can give you good information on relatively straightforward scenarios, like “What if my case load increases 20%, where will I have to increase resources” or “if I can eliminate one step for 90% of least-risk cases, how do the time savings compare to expected cost of the low probability problem?”

The pessimists don’t expect any rabbit to come out of a hat that was not put there before, but even a pessimist can see that running a simulation provides an ability to see the dynamics inherent in the model, as an aid to understanding the process as it is modeled. Formal graphical models are things that are not entirely natural to most people, and we can all use help understanding the model. This is a kind of “debug” capability that allows the business analyst to find basic problems before they get into the next step of development.

The Model Transforming Strategy

For the pessimist, simulation is very important because it allows the business person to work the problems of the model out at the business level, before it is transformed into a model for the system domain. Since mistakes at one level are magnified after transformation, it is important to use whatever techniques are available in order to debug before going to the next level.

For the optimist, the problem is that simulation of the business domain model may, or may not, have any relevance in the system domain or in the enactment domain. Spending a tremendous amount of time building a precise model of the workers and the caseload may be for nothing if the model is transformed for actual execution. Finding that a particular resource level produces optimum flow through the business model may turn out to not be the optimum solution once the model is transformed. Simulating in the system or enactment domain will give you a better optimum, but these models don’t have meaning for the business analysts, and it may not be obvious how to translate the optimum situation back into the business domain. Simulation optimist are finding that simulations are significantly complicated when the model is transformed.

The Model Preserving Strategy

Clearly the optimists are are on better ground when the model designed by the business analysts is represented in a one-for-one way with the process that is executed in the enactment engine. An optimum setting is more likely to represent reality.

For the pessimist, the situation is about the same between the two strategies. Simulation can help with understanding the dynamics of the situation, and that will be the case whether the model is transformed later or not. Although one might point out that since the model is never transformed, there is no urgency to complete the simulation before progressing to the next stage. If the model keeps the same form through the lifecycle, the business analyst and the system integrator can cooperate on running simulation models with increasing precision.

Discussion

In summary, the pessimist sees a basic benefit of simulation regardless of whether the model is transformed or not, but the optimist who is really trying to get quantitative results from the simulation will see much better results in a system that preserves the model’s form through the BPM lifecycle.