I finished the day listening to Michael zur Muehlen discuss business processes and rules, a topic that I spoke about a few weeks ago at the Business Rules Forum. Michael, who I know from the BPM Think Tanks, is responsible for BPM courses at Stevens Institute of Technology. You can see his presentation slides online here.
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 modelling tools: they’re not friendly to business types. Became of that, we 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 5000 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 BPMS. 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 modelling that’s done by the business analysts: how much do they need to know about rules, and what does their modelling 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.
He talked about the links between process management, business rules and compliance: whereas 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 symbols are actually used, and found that there’s 6 or 7 symbols that are used in most of the diagrams — the rest are strictly long-tail usage. See page 39 of the slide deck that I link to above for the chart.
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, company-wide and less predictable.
My flight home leaves tomorrow mid-day, so this is likely the end of my IIR/Shared Insights BPM conference coverage. Next year, maybe they’ll spring for more than 2 nights of hotel…