Using Business Rules to make processes smarter, simpler and more agile
Daryl Pereira 270002AW8D email@example.com | | Tags:  impact09 business rules
0 Comments | 3,354 Visits
James Taylor, CEO of Decision Management Solutions, ran an illuminating presentation at IBM Impact on decision management, business process management (BPM) and business rule management systems (BRMS).
James started his presentation with the salient point that many sessions at IBM Impact start with a slide explaining how the world is getting ever more complex and changes are happening faster. He then shows his version.
An example of the changes we face are that there is more regulation coming so you need to be compliant; at the same time you need to be more agile. Other issues include managing uncertainty and cutting costs.
Faced with these challenges, BPM has a lot to offer. Our processes should be smarter: We need to learn from data and through experimentation.
Without engaging in BPM, many decisions are made manually; some are automated but a lot of decisions are not made at all. After implementing a BPM approach, more decisions are automated, less decisions are manual and less decisions are avoided. This means the experts you have making manual decisions can spend more time adding value in other areas:
For instance, in the old scenario, underwriters couldn't leave their desks; there were policies to process. As soon as the underwriting process is automated, however, underwriters spend more time visiting clients and looking at which agents were selling better. They become real knowledge workers with plenty more to offer. A BPM does not put them out of a job.
However, you do have to take into account just how much you do automate. Not all decision making fits into a process. James makes the distinction between processes and decisions:
So, decision management needs to be considered. This is not a technology: it's a way about thinking about a problem. For instance, how do you handle uncertainty? Can this be reduced to a decision-making process? Each potential decision should be evaluated on whether it makes sense for inclusion in a decision management system.
What constitutes a decision?
Some decisions are large and strategic; e.g. the question of whether you should move your computing into the cloud. These strategic decisions happen rarely and are often resolved at the executive level.
James quotes Peter Drucker:
So, on the other side of the scale are operational decisions. These are smaller (micro) but cumulatively can have a large effect on the enterprise. The decision services James is discussing are mainly located at this level.
He offers a number of examples:
Applying a business rule management system
Once you have discovered the decisions, you need to apply decision services. The following is a standard implementation model showing where the decision services sit within the IT infrastructure and how business users interact directly with the decision service system, rather than with programmers:
Business rules drive decisions. The artifacts that guide decision making can be in policy docs, regulations, histories (past data) and legacy applications. Business rules allow you to pull all these into a single place.
James makes a distinction between business process rules and decision rules. Some rules don't need to be in a BRMS, such as rules tied to process or system flow; these should be handled by a BPM system.
One of the advantages of using a BRMS is that it offers a more amenable interface for business users. A business user needs to run their business; they don't want to manage rules. When they interact with a BRMS, they should feel like they are maintaining their business, not maintaining their systems. James shows an example of how the rules can be put in MS Word using ILOG BRMS--an example of putting the rules into the systems used by business users.
Another advantage of ILOG BRMS is the reduction in IT costs. Hotwire presents a good example of this.
Analytics and decision analysis
Analytics is key, but the problem is not gaining the insight; rather it is how you act on what you learn. For instance if you have data mining tools that allow you to segment customers, you can build a decision tree within a BRMS that applies a different set of rules to each segment. You may have a set of rules for those customers that a data mining application would flag as being of high value.
For instance, predictive analytics can be used to look at customer behavior to find out whether a customer is more likely to renew (say for a healthcare service). Using scorecards and tables, you can incorporate this into a BRMS.
There is a loop between information, decision, action and reaction. But analysis is about looking at the information and the decisions made, and to ensure that these are optimal. You can't go back in time and apply different rules to a customer and see the effect. However, you can do standard A/B testing where you apply different rules to different customer samples and test the results to see which is optimal. You need to continue this over time to ensure that as the external environment changes, you are using the best set of rules.
You also can apply modeling and simulation to test scenarios, such as 'how would I responde if a competitor goes bankcrupt?'.
You can capture the complexity of the decision in a decision service to make processes simpler:
And remember, beyond simplicity, processes will also become more agile.
James succinctly describes the consequences of implementing decision management as follows:
So, what action should you take to get started? Consider the following:
Get more information on ILOG BRMS.