We expanded from Business Rules Management (BRM) to Decision Management a while ago, but I still hear some confusion on what the difference really is.
Technology
The technologies used for decision management definitely include business rules. We typically also add predictive analytics, business intelligence and/or optimization in that bucket. So, of course, they are clearly related. One is a superset of the other.
We expanded from Business Rules Management (BRM) to Decision Management a while ago, but I still hear some confusion on what the difference really is.
Technology
The technologies used for decision management definitely include business rules. We typically also add predictive analytics, business intelligence and/or optimization in that bucket. So, of course, they are clearly related. One is a superset of the other.
Approach
The big difference though is how you think about them, and how you go about engaging with the automation and improvement of your decisions.
In the “business rules only” days, the focus was mostly on getting natural language or pseudocode rules implemented into the system. Depending on your background, you may include rules elicitation or knowledge engineering as part of your business rules project effort. Some methodology still focus on the individual rules capture, and their categorization.
When we moved to decision management, the most exciting development was the focus on decision performance. The business analyst or expert was not asked to list the rules exhaustively. Instead, he/she was asked to think about the decision itself and the context in which we wanted to apply it. The main focus became the business objectives. If you have a business decision as a starting point, you can drive the elicitation effort with clear objectives in mind:
- Compliance
- Revenue increase
- Loss prevention
- Customer satisfaction
- etc.
These clear and measurable objectives can help accelerate the effort, and mostly ensure that you are all marching towards the same goal as a team, as a company.
I have seen executives request those key performance indicators and the impact that strategy changes would have on them… But this can be daunting, possibly impossible, effort if you link to them after the facts! While the proper set up from the start can make this whole thing extremely easy. The cool part is that you can measure after the facts, but you can also use those metrics as you develop your business rules to drive the conversation with the experts. It keeps the team on track. Some business rules might genuinely affect negatively the metrics- it is typically the case with federal regulations for example, but at least you know about it as you capture them.
Does that change my business rules?
I don’t think that you would have a very different structure in the end in your rules design or organization. What would be dramatically different though is the number of rules.
If you are cataloging rules, you might write every possible rules that ever existed or was mentioned in the organization, analyzing every single possible data point. There are instances where you would absolutely want to make sure you cover all the cases, but you might keep around some obsolete or legacy decision logic that is barely making a difference in your actual decisions.
As you write business-objective-driven rules, you would likely limit yourself to the rules that are critical, that are impactful.
I recall a project where rules were written 2 different ways and ended up with a factor 2+! A thousand and something rules were written by experts that were asked to be exhaustive. Meanwhile, business analysts could produce the same quality decision service with just a few hundreds rules. Guess which one ended up being the easiest to maintain?
