A couple months ago I posted about the deficient simulation capabilities of most process modeling tools.  More recently I’ve been working with ITP Commerce – the tool provider for my upcoming BPMN training – on enhancing their simulation features to address the use cases that figure most prominently in process analysis.  It’s been a really instructive exercise, and I’m still struggling through it.  I’m interested in hearing about the experience of BPMS Watch readers who have used simulation successfully.  From my own process of thinking about the problem, here’s what I’ve come up with.

First of all, I haven’t found any books on process modeling or tutorials from modeling tool vendors that talk about how to actually use simulation analysis in a practical way.  (The tool vendors tell you how to set the parameters and click the buttons, but that’s another thing entirely.)  So I’ve had to imagine general classes of use cases based on the kind of analysis that process consultants talk about, the kind of simulation that the tool vendors seem to assume, and what users imagine they are getting from simulation.

I’ve come up with 3, and I’m building my BPMN training around the particular modeling and simulation patterns associated with each one.  Call them simulation use cases 1, 2, and 3.  I’ll post on Use Case 1 today, and follow with the others in the next day or two.

Use case 1, which I think is the most important, focuses on the general type of “process improvement” expected from scrutiny of the modeled as-is process (whether using simulation or not).  Usually the key metric is end-to-end cycle time. 

Use case 2, which maps more or less to what the modeling tool vendors are offering, assumes a production workflow scenario where bottlenecks are based on contention for resources, and are addressed by optimally configuring staffing and shift calendars at specific worksteps.  The metrics analyze the tradeoffs between cost and cycle time for various configuration scenarios.

Use case 3 represents a capability users think they are getting from simulation analysis, but almost never are: activity-based costing (ABC).  Activity-based costing is a technique of fairly assigning fixed or indirect costs to different classes of work, in order to calculate the “true” cost of each type of work.

The important BPMN features that simulation must support are different for each use case, as are the key metrics of their respective simulation reports.

Use Case 1: The problem is the current process takes too long.  The problems can usually be traced to things such as handoff delays between organizations, inefficient ping-ponging between participants, sequential activities that could be done in parallel, manual tasks that could be automated, and a preponderance of batch activities, ranging from overnight mainframe runs to interoffice mail pickup and delivery.   In books on process modeling, such as Sharp and McDermott’s Workflow Modeling, the basic difference between the as-is and the proposed to-be process is cleaning up problems like these.

Simulation issues for use case 1 include:

  1. Activity duration, active time vs total time.  In some simulation tools, activity duration is a single parameter.  But an approval that occupies 2 minutes of a manager’s time might still on average take 3 days to complete.  If you assign the Approve activity a mean duration of 3 days, is the simulation engine going to interpret that as 3 days of active time, so you would need to artificially configure lots of managers in order to avoid contention for that resource?  Or, the simulation tool might allow you to disable contention for resources for the model, avoiding that problem.  For instance, ITP Commerce Process Modeler lets you do that, but that disables the resource’s shift calendar as well.  I don’t want my simulation engine assuming the manager is Approving at 4am.  Process Modeler solves the problem by providing 2 independent duration parameters for an activity – a Wait time that does not consume resources, and an Active time (after the Wait) that does.  It preserves the shift calendar and effectively solves the problem.
  2. Handoff delays.  You can model this in three ways.  Either build it into the Wait time of the activity following the handoff, as described above, or if your tool doesn’t support Wait time, create a dummy activity with a zero-cost resource to model the delay.  Alternatively, use a timer intermediate event in the sequence flow, set to wait for a specified duration.  Of course, your simulation engine needs to support timer events.
  3. Batching delays.  For once-daily occurrences, such as batch computer runs or Fedex shipments, you can again use a timer intermediate event, but setting a specfic time rather than a duration for the timer.  If your simulation engine handles it (Process Modeler does), it’s a really handy one.  What about batching that occurs more than once a day?  Such as the interoffice mail cart, that arrives at 9am and 3pm.  For that you can use the event-based gateway with a timer event on each leg set to a specific time of day.  Again, if your simulation engine supports it (Process Modeler does), that one works great.
  4. Resource shift calendars.  Even though this use case rarely involves modeling of resource contention, the cycle time does depend on the working hours of various staff roles.  The simulation tool should specify shift calendars for each role or group, i.e. days of the week and hours of the day that the resource is available to perform tasks.  Without that, the cycle times won’t be right.
  5. The metric you’re usually looking for is the mean cycle time, plus some cycle time statistics.  Process Modeler gives me mean and maximum cycle time, and with a little custom Excel work I can get more, such as a histogram of cycle times.  I’d really like the histogram out of the box, but maybe that’s being greedy.