John Reynolds wrote a post recently about Interdependent tasks, and the resulting complexity. John takes a simple example, the vacation approval process, and then points out what makes the difference between a cute model and a real implementation:
Sam can't really (in good conscience) make a Decision about any Vacation Request in isolation.? Only one Employee can be absent at any one time, so every Decision that Sam makes potentially effects all of the Pending Requests.? To be fair to everyone, Sam needs to take into account all of the Pending Vacation Requests before rendering a Decision on any of them.
Examples like these are what makes implementing "real world" processes hard.? Processes seldom execute in a vacuum, and work done within one instance often influences other instances.? Participants often have to consider multiple Tasks together, rather than performing each task in isolation.
He's right, of course.? This is why a demonstration of a BPM solution can look easy, but the actual implementation actually takes real work and thought.
John purposely held back from suggesting a clever BPMN modeling solution or other trick of the trade to give us something to think about. I'll give you my thoughts on how to approach the problem. ? But in a general sense, this falls back into a general process pattern:
- a process model that does a decent job of representing one process "instance".
- another process that manages the set of all processes
- yet another process that is the maintenance and improvement of the process definition and the management of process instances collectively.
What John is describing is a variation on the second level of process.? It already goes without saying that we need to manage a set of vacation requests collectively.? The extra wrinkle is that at a step in the approval process, the process should present context to the user, that likely includes:
- All pending and approved vacation requests for other team members
- Possibly other pending and approved vacation requests for people on other teams
- Remaining vacation days for this person
- Remaining days in the year in which to use those days
- Time since last vacation
All of this information gives the Approver context in which to make the decision.? The individual process' execution flow hasn't gotten more complicated. But the implementation details of that Approve step got more interesting.? Luckily, the information above will be pretty easy to provide if your BPMS had reasonable tracking and introspection capabilities.? So if we simply invest some trust in our user, and supply them with the information they need to make a decision, we'll get really good outcomes with minimum implementation headaches.
Sometimes the really interesting bits in a process implementation aren't in the BPMN.? As John points out, we shouldn't assume that every detail should be captured in a BPMN model.