1. Activity duration -- active time vs. total time. In some simulation tools, activity duration is a single parameter. But an approval that occupies two minutes of a manager's time might still on average take three days to complete. If you assign the Approve activity a mean duration of three days, is the simulation engine going to interpret that as three 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 two 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), 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.
I'll post my thoughts on two other common use cases in over the next few days.
Dr. Bruce Silver is an independent analyst, consultant and author of the BPMS Watch blog. Write him at [email protected]A couple months ago I wrote 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 its simulation features to address the use cases that figure most prominently in process analysis. I've come up with three, and I'm building my BPMN training around the particular modeling and simulation patterns associated with each one.