David Straus wrote a nice article in Business Integration Journal this month - A Rule Does Not a Decision Make
"Rarely is a single business rule the basis for making any decision. More often, many rules interact to form a decision. An underlying concept in a decision architecture is that business decisions are the atomic unit we should be focused on, not the rules. "
Absolutely. Given the title of this blog is "Enterprise Decision Management" you might expect me to agree with this and sure enough I do. It has to be said, however, that one of the attractions of using a business rules management system with a structured rule repository is that you can re-use rules effectively between decisions. Oracle even uses the phrase "decision service" which maps pretty well to this concept. He goes on to talk about complexity in decisions
"Organizations want to make decisions that are far more sophisticated than they’re able to make using people to make decisions manually, or using “coding” to automate. These decisions are made up of hundreds of rules. Banks would minimally like to make consistent decisions on several factors associated with a decision such as a customer request to refund overdraft fees"
Well this gets more interesting. While it is certainly true that I know customers who use Blaze Advisor to manage very complex decisions with just rules (10s or 100s of thousands of them) his examples strike me as classic examples of the limit of rules as an approach and of the point at which analytics need to be added. Take the examples he uses:
- Does this person have a history of overdrafts (how often and over what time period)?
- Does this person make money for us (i.e., large average balance in a non-interest-bearing account)?
Now these are classic origination questions, that is to say rules in deciding whether to "originate" a credit product for someone. Many years of experience in Originations tells us that if you try and write more and more rules to manage the process, you end up excluding almost everyone. The rules are simply too "atomic". It does not matter if you can make them complete and consistency as David discusses, you need to balance them more intelligently. This is the essence of analytics - managing uncertainty and complexity of sources.
In the case David is examining what we need to do is assess two things that are uncertain - how much money are we likely to make from this person over time (something that involves retention trends, cross-sell potential, profitability of individual products etc) and the risk of bad debt (a complex intersection of things, often represented by the FICO score). Rather than try and write more and more rules to address this, it is much more effective to use data mining and predictive analytic techniques to build a predictive model for each of these such as a scorecard. This kind of model allows for potentially complex trade offs between factors while being statistically valid. A predictive model like this can then be integrated into the rules, at least in products like Blaze Advisor that understand what a predictive model is, and then used along with rules to make the decision. Egg is an example of a company that does this with Blaze Advisor and Capstone Decision Accelerator is a product Fair Isaac has developed, using Blaze Advisor and the FICO score and other predictive models, to handle this kind of situation.
EDM - focus on decisions but use rules and analytics as necessary.