Talking with SAP today I made the comment that the best place to use business rules was often in stable, core business processes because those processes don’t change, only the decision rules within them. This clearly struck a chord with @GregChase and it made me think I should write a slightly longer version of what I meant before I retweeted it (I’m @jamet123 for those not yet following me on twitter).
It seems to me that business processes can be divided into those at the edge of a business and those at the core. I realize this is grossly simplistic and only one of the many ways to divide processes but bear with me. Processes at the edge are less stable and evolve more rapidly. No-one is 100% sure what the process should be and so it gets changed a lot based on experience. Some of these edge processes never really stabilize at all. In these processes decisioning is going to be dynamic, hard to formalize and largely manual.
Core processes, however, are much more stable. Everyone knows the paths that work through the process, the activities involved are well defined. Changes to these processes are a big deal, disruptive to the company regardless of how they are implemented. In these processes what changes are the decisions and the business rules behind those decisions – what makes a customer eligible for this level in the loyalty program, what price is this policy for this customer, what’s the best retention offer to make. These decision changes can be mistaken for a process change if the decision has not been broken out but they are not process changes – the activities, their sequence and their purpose all remain the same. The decision-making behavior of a specific activity is what changes.
Most companies have both kinds of processes and most therefore will need to manage decisions as well as processes. If they focus initially on core processes, like underwriting in Insurance say, they will likely adopt rules and focus on decisions first. If they focus initially on edge processes, they are less likely to see the value of rules and decisions in the short term and will focus purely on process. But their core processes will require decisioning.
Comments on this entry are closed.
Very interesting article! I first encountered the separation of business rules from a BPM in a Sandra Kemsley presentation and was struck by the simple but powerful benefits of doing so. I have argued (I am a business ‘expert’ not a BPM expert) to keep the rules out of some process modelling recently done for my organisation. The modellers, using Websphere, had not encountered this and gradually understood and fully appreciated the idea. I am collecting the rules using the Ron Ross Business Rules Approach and when they have stable ID’s I intend to add them into the BP model using their references as determined in the rule repository.
I agree with the stable and edge processes distinction; we go further and have “exceptions” set out in separate text format for the really “one-off” processes that might occur – they might be very stable and have their own “one-off” business rules but tend to over-complicate the BP model.
Another approach I am hoping to follow, as a guide to putting rules into the model, is to directly align the Party, Data, Process elements of the BP model with rules that have that Party, Data or Process as subject (I am using rule statement templates c/- Graham Witt and the majority are organised into this simple taxonomy of rules). Sounds neat in theory, probably it will be a bit messy in practice, but it is very interesting to explore these ideas.
Brilliant. When you read something that is so clearly right, there’s a tendency to think “Oh, yeah, I knew that” but the reality is that you probably didn’t. So it is with James’ post on business rules in stable core processes. I fancy myself a bit of an expert on how companies approach business processes, but the last paragraph really got me thinking. The point – a company’s view and approach to business processes will be affected by whether they start with “edge processes” or “core processes.”
I’d be remiss if I didn’t note that “core” means very different things to different people. E.g., what Geoffrey Moore means by “core” is probably somewhat different that what James means by core.
Whatever your terms and definitions, this was an excellent, thought-provoking post.
Thanks, James
Interesting discussion, possibly as I have quite the opposite opinion; the most fertile business processes for rules automation are usually the most exception rich and changeable.
First off, let me mention that I agree that stable, well understood processes can benefit from rule technology for precisely the reasons you mention. If the processes, and it’s constituent activities are well understood, then we often find that most of the change in the process is limited to the business rules within it. Therefore some sort of rules automation and management solution will provide a productivity benefit.
Must more interesting is the exception rich processes which we can’t nail down. We spend our time mapping our decision trees and analysing business processes to try and find a way to stabilise and optimise the business process. We might even apply the bag of tricks we’ve learn’t from Six Sigma and LEAN.
It’s the wrong solution to the right problem. Our highly valued tools for process optimisation work by minimising and managing the variation in business processes. Reducing variation enables us to increase velocity, automate via BPM, and thereby minimise cost. But it is this processes variation, the business exceptions, which can have a disproportionate effect on creating value. In a world where we’re all good, it’s the ability to be original that enables you to stand out.
An alternative approach is to embrace this variation. Simplify the processes until it is stable, reducing it to its essential core. Treat exceptions as alternate scenarios, compiling the set of commonplaces required to support the vast majority of exceptions. We can then use a backwards chaining rule to bind process instances to the appropriate commonplace in a variation of Jim Sinur‘s “simple processes, complex rules” approach.
This approach reduces the complexity of an ever changing process by transforming change into the evolution of an appropriate suite of commonplaces, and the goal-directed rules used to bind them to process instances.
Unfortunately, most vendors don’t provide backwards chaining out of the box (I think RuleBurst, who bought Haley before being swallowed by Oracle, are the sole exception), so it’s seen as something of an unnecessary black art.
r.
PEG
In response to Peter:
I think we are in agreement here – the variation in some of the processes you describe is not really process variation in my mind but decision variation and the use of decisioning and a rules engine to manage that variation would be the right approach. The idea of simplifying a process and then using decisioning to add variations is a great one and is certainly something I think about (though you expressed it more eloquently than I usually manage).
As an aside FICO Blaze Advisor supports some backward chaining as does JBoss Drools.
JT
There’s a conversation tying these ideas to BPM and in-memory databases over at the SAP community network.