An interesting discussion started on twitter this week with @BigBlueMilky saying “Decision Management is so much more that just using business rules” – something I strongly agree with. @JeffreyGoodReq followed up by adding “But you must start with business rules” and, when I disagreed and said you must start with Decisions added “rules = context needed for decision framework, no?” Much as I enjoy tweeting 140 characters is not really enough to have this discussion.
First, why is Decision Management more than just using business rules? First, Decision Management involves using both business rules and predictive analytics (and sometimes optimization). Not all decision-making is best described only in terms of business rules and many decisions cannot be completely described using only rules derived from policy, regulation and know-how – there is a need to apply analytic insight to the decision as well. While you can represent a lot of predictive analytic models as executable business rules, this is not the same as treating them the same as the rest of your rules. They need to be discovered, managed and updated analytically. Decisions also need to be managed over time – data is collected about the decisions made and how well they worked so that decision-making can be analyzed, improved and evolved systematically (this is why we talk about Decision Management Systems not Decision Automation Systems).
But why not start by collecting business rules? Well Decision Management involves the discovery, automation and ongoing improvement of decisions (see these three webinars on Decision Discovery, Decision Services and Decision Analysis in our recent How to Build Decision Management Systems series). Successful Decision Management efforts begin by identifying the key objectives of a business area and then identifying, modeling and describing the business decisions that impact those objectives (this is described in more detail in Chapter 5 of my new book). As part of defining these decisions you identify the regulations, policies, know-how and analytic insight needed to make these decisions. Then, and only then, do you collect business rules.
This works better as the decision definitions provide a context and a framework for your rules. The decisions have a place in your processes and use cases (so it is clear where they will be used) and are tied to business objectives (so you know how to define good and bad decisions as well as the value of improvements in decision-making). It is clearer when you have collected all the rules you need (you have defined the decisions you were focused on) and it avoids what I call the “big bucket of rules” problem where companies end up with lots of correct business rules but no easy way to tie them to day to day operations.
Now, once you are done, the rules do indeed provide the framework for how each decision is made – they define the approach being used to make decisions. But starting with the decision, beginning with the decision in mind as I like to say, is critical to effective Decision Management.
Comments on this entry are closed.
It’s obvious I need to buy YAB [yet another book] because I come to decision management from a different place. Thus, using lowercase to describe it.
I am going agree every organization should avoid the “big bucket of rules” and rules should be tied directly into operations. Identifying rules as an academic exercise can be fun, but it’s not worth the effort if you don’t tie them to better business processes and operations.
But it seems decision management is another view of the stack. While the entire stack (operations) is effectively reaching a business goal, there are many ways to view the stack. One is via the operational processes being used (BPM), another is via the business rules, and yet another is decision management.
Certainly, predictive modeling and analytics can help a company be more effective in reaching their goals, but my experience tells me trying to get better without understanding the multiple views of the stack leads to lots of wasted time and effort.
I also don’t know of any company willing to undertake looking at all the views simultaneously. You have to prioritize where to focus your resources.
My own background leads me to prefer looking at processes first, rules second, and decision management third. But maybe I’m just hanging out in my comfort zone. Presuming we all want the same thing, why should I focus of decisions before processes and rules?
The challenge I find with fitting business rules into “the stack” is that they get everywhere: You can have business rules in a business process (handling routing and escalation for instance), you can use them to correlate events, you can control user interfaces and even manage data quality and integrate. Plus, of course, you can make decisions. As a result I find it more helpful to think of Decisions as a “first class object” when I am modeling a business. Thus Business Processes can use Decisions or be triggered by them, Events can likewise invoke Decisions or be sent by them etc. Decisions can be implemented as Decision Services and fit into the technical side of things easily with well defined interfaces (you pass them data, they give you answers). Data mining and predictive analytics can be used to improve the accuracy of decisions (by ensuring the branch values in your decision tree is statistically significant say) or to make it possible to add rules you could not add before (such as a discount rule that uses the likelihood of a customer cancelling their subscription – a prediction – to increase the discount offered as a retention device). Decisions evolve and improve without disrupting the processes or systems that rely on them.
In other words I like to look at Processes and Decisions as peers and then use business rules to manage the logic in both.
More on BPM and decisions here and on the relationship between rules and decisions here.
Hope you enjoy the book 😉