From the above statement you can pretty much derive the types of Rules that govern a Process:
- Routing Rules - determine who (which Participant) should perform an Activity
- Flow Rules - determine which Activities should be performed and in what sequence
- Escalation Rules - determine what to do if an Activity is not completed at the right time
On a BPMN diagram the Routing Rules are somewhat indicated by Swim Lanes - Flow Rules are somewhat indicated by Gateways - Escalation Rules are somewhat indicated by attaching Timers (a form of Intermediate Event) to Activities. The challenge for those of us who implement Process Applications is to fill the gaps between the BPMN diagram that somewhat represents these Rules and the nuances of these Rules.
Using BPMN to model a Process is a fairly "Business Person Friendly" method for capturing and validating requirements. With a bit of training most Business People can "read" BPMN diagrams to validate that the diagram is an accurate representation of the Process they want implemented. Many BPM Systems translate BPMN diagrams into executable code - so what the Business Person "sees" is what the Process "does".
Unfortunately there's not a similarly wide-spread "Business Person Friendly" method for capturing and validating Routing, Flow, and Escalation Rules.
I'm intentionally being imprecise in how I use the term "Rules" - I don't want to get bogged down in a discussion about Rules Engines - I'd rather focus on the way most Business People express Rules.
- When a Business Person tells you "Have Frank do this task if the loan amount is over $500K" that's a Routing Rule.
- When a Business Person tells you "Do a Credit Check if the Applicant has no Collateral" that's a Flow Rule.
- When a Business Person tells you "If the Credit Check isn't completed in an hour notify Frank's boss" that's an Escalation Rule.
Often you'll get ambiguous or conflicting Rules from Business. It happens all the time. The Process can't (really) be implemented until the ambiguous is made clear and the conflicts are resolved - When you encounter these situations (and you will encounter these situations) you'll immediately understand why there's a lot more to implementing a Managed Business Process than BPMN.