I sat in on a presentation by Michael zur Muehlen on business processes and rules at the recent IIR/Shared Insights BPM conference. Michael is responsible for Business Process Management courses at Stevens Institute of Technology. He started out with the bottom line on why you want to integrate process and rules:

• Simpler processes • Higher agility • Better risk management

Who wouldn't want this? However, he points out that users don't like processes, since they find them abstract (or possibly requiring a more analytic view of the organization) and restrictive (that is, not able to capture all the actual business cases). He also points out the obvious problem with Eclipse-based process modeling tools: they're not friendly to business types, so you end up with technical people maintaining business processes, which usually results in a lot of code and the next generation of legacy systems.He went though an example of an insurance company with 12 process steps and 5,000 business rules, and it became obvious why rules change faster than processes. He highlighted three places where rules and processes come together: control flow, work assignment and cross-process policy enforcement. I still think that the key issue is the boundary: when is something done as a decision tree in a rules system, and when it is done as control flow directly in the BPM system? Michael suggests that you might want to first model the rules in the BPMS, then extract the rules, although I don't think that the rules experts would consider that a best practice. The challenge, then, comes with the modeling that's done by the business analysts: how much do they need to know about rules, and what does the modeling environment need to look like in order to support that?

He had some good suggestions about mining rule criteria from previously executed processes, determining what the automated rules should be based on prior manual processes. From an insurance standpoint, this can result in auto-underwriting on standard cases.

Michael talked about the links between process management, business rules and compliance: whereas a BPMS can enforce process compliance, rules are used to enforce contextual compliance for all the things around the business processes that aren't really part of process compliance.

Michael and a colleague did a fascinating study of which BPMN (business process modeling notation) symbols are actually used, and found that there are six or seven symbols that are used in most of the diagrams (see page 39 of this slide deck). The rest are strictly long-tail usage.

He had some practical advice on how business rules and business processes interact:

• Business objectives (rules) govern and prioritize business activities (processes) • Process objectives (rules) govern and define core processes (processes) • Process objectives break down to business rules and core processes break down to business processes, where business rules govern the business processes, and bsiness processes use the business rules. • This can be taken to a further level of granularity with operational rules.

He also had a chart for classifying change, and showing where it made more sense to use business rules or business process for a particular decision/activity; for example, use rules if it's rapidly changing, companywide and less predictable.

Sandy Kemsley is an independent systems architect specializing in business process management, Enterprise 2.0, enterprise architecture and business intelligence. She is also the author of the Column2 blog on BPM, Enterprise 2.0 and technology trends in business. Write to her at Sandy [at] Column2.com.Michael zur Muehlen of the Stevens Institute of Technology spoke about business processes and rules at the recent IIR/Shared Insights BPM conference. He started out with the bottom line on why you want to integrate process and rules: 1. simpler processes 2. higher agility 3. better risk management. Who wouldn't want this? Well, it turns out users don't like processes...