Ron Ross presented in the first breakout session of the BPM track, discussing best practices for creating better (and fewer) process models by modeling business rules together with processes. I’ve talked on this subjet quite a bit, although I come at it from the process modeling side whereas Ron is from the rules side. His business partner, Gladys Lam, was also in the audience; their book Building Business Solutions: Business Analysis with Business Rules and Ron’s earlier book Business Rule Concepts covers these concepts in much more detail.
I used to joke that process modelers tend to create process models wherein the business rules are just huge networks of flow logic directly in the process, whereas rules modelers create process models with a single task that just calls a rules engine. Ron isn’t going quite that far, but definitely advocates reducing the modeling of rules directly in a process notation (as BPMN gateways, for example) to create more concise and smarter process models. Rules should be expressed in business language; rules models are fundamentally different than process models, although the decisions made in the rules models can then be used within the process model. In his example, an insurance claim process included a conditional flow path when the claim is valid, but doesn’t explicitly show what rules are applied to determine if a claim is valid – that’s a job for the rules model.
He discussed some different patterns for harvesting rules from processes – conditional flows, maximum inter-task timing, and minimum inter-task timing – and introduced their RuleSpeak guidelines for expressing the resultant business rules in concise business language. He made a distinction between behavioral rules and decision rules; the former relies on a governor to watch for the rules being met or violated (often implemented in processes as an interrupting event of some sort), while the latter is about applying a decision at a point in a process. In short, rules are the embodiment of your business policies that ensure that you get consistently achieve the right results; in the rules world, processes are just a way of connecting the rules.
The key is to externalize the rules from the processes, and (primarily) model the high-volume standardized transactions. Low-volume, specialized processes don’t need to be modeled prior to execution, but can be informed and guided by rules: this is the basis of adaptive case management. This moves the need for agility into business rules – which are typically easier to change on the fly – and both simplify and stabilize business models.
Good post by Sandy about Ron Ross’s presentation and the confluence of business rules and process models.
This is key issue or challenge with process modeling that how do you capture and document business rules (both behavioral and decision rules) along with the process diagram. We have found that having a single business process modeling tool for both helps a lot rather than doing this separately in Visio and Word or other distinct tools.
Our team has been using the AccuProcess Modeler in the recent months and have found this to be a great tool which anyone can use without a lot of formal training. It includes in a single product the process modeling, documentation and even process simulation for the as-is and to-be processes. It is available at: http://www.accuprocess.com Check it out.
There are 3 related disciplines here:
– business rules that constrain and guide processes and decisions
– business decisions that are modelled and can involve processes in making decisions and apply or embed business rules
– business processes that embed decisions including process decisions modelled as gateways
Although the 1st 2 are often combined (eg the “business rule task” in BPMN), they are different in practice. Business rule statements guide (and are applied in) both process design and decision design…
Relevant technologies are rule documentation repository, decision engine (may be a rule engine), and process engine, and relevant notations or standards are SBVR, DMN (in progress), and BPMN – for 1-3 respectively. DMN is beginning to look very interesting and will likely have good effects on the process modelling and execution community IMHO.
And after that we need event modelling 🙂