Three ways you can make sure your business rules projects succeed!
Finch, in the broadway musical “How to Succeed in Business Without Really Trying” (//en.wikipedia.org/wiki/How_to_Succeed_in_Business_Without_Really_Trying), rises to the top of the World Wide Wicket Company by following the advice in the book. Perhaps you won’t rise to the top of your company by following the advice in this blog post, but a little guidance can go a long way in keeping your business rules projects on track!
1) Start with a Decision-centric focus.
Decision Management Systems are focused on automating and improving a business decision. More precisely, they are targeted at operational business decisions – those high-volume, repeatable decisions that occur in business systems and processes that are both suitable for automation and good candidates for improvement.
One way to identify these decisions is to analyze your business processes. Decision points often occur in the activity before a gateway in a process where the branch in the process flow is determined by the business decision. The gateway itself is not the decision, but rather is a branch where the path taken in the process is based on the outcome of the decision made in the preceding activity. Oftentimes tasks that represent decision tasks will have names containing verbs indicative of decisions, like “Validate”, “Verify”, “Determine”, “Calculate”, “Check”, or “Analyze”. For example, in the process diagram below, the Validate Claim, and Verify Coverage activities are decision activities followed by decision gateways that direct the flow based on the decision.
Examples of operational decisions include validating an insurance claim, determining whether or not a customer is eligible for a discount, calculating sales commissions, assigning a trouble ticket to a customer service representative, determining whether or not a transaction is likely fraudulent, or providing product recommendations for up-sell or cross-sell offers. It is helpful to phrase the decision as a specific question, “Is this applicant eligible for unemployment benefits?” or “How much of a discount should we apply to this sale?”
Specifically defining the decision allows you to focus your efforts on discovering and automating the decision logic for that particular decision rather than focusing on discovering, documenting, and modeling all the business rules in a legacy application, or from a specific policy manual. A decision-centric focus provides a well-defined and practical scope that helps you ensure the success of your project.
Phrasing the decision as a question enables you to specifically identify the outputs of the decision. An eligibility decision might result in a simple “yes/no” or “eligible/ineligible” output but in the case of an “ineligible” decision, might also include the list of policies or business rules that resulted in the decision.
You can also begin to identify inputs upon which a decision is based and further refine the list of inputs as you discover all the business rules that apply to a given decision. For example, transaction data or claims data might be the input to a fraud decision. In the beginning it is not important to have an exhaustive list of decision inputs since you will flesh these out iteratively as you discover and elicit relevant business rules.
Once you have specifically identified and phrased your decision as a question, listed the required outputs, and identified the known inputs, you may want to identify the characteristics of the decision. Understanding decision characteristics — such as how frequently the decision is made (volume), how much time is allowed for making the decision (timeliness), and how frequently the decision changes (change frequency) — allows you to clarify the requirements for automating the decision.
2) Keep business performance at the front and center.
Improving business performance means making automated decisions that are consistent with our organization’s goals and objectives. It’s important to explicitly define the business objectives for your decision so they are clearly communicated and well-understood. For example, assume you are automating a product recommendation decision for your online retail channel that recommends products for cross-sell. Your business objective might be to increase revenue by increasing the average shopping cart amount in dollars by two percent.
Defining a KPI will allow you to directly measure and track the performance of our product recommendations against your business objectives. Here’s a definition that explains the characteristics of good KPIs —
“KPIs are quantifiable measures that help decision makers define and measure progress toward business goals. KPI metrics translate complex measures into a simple indicator that allows decision makers to assess the current situation and action quickly.”
Remember that all KPIs are metrics but not all metrics are KPIs. You will also want to define metrics that help you understand the characteristics of your decision input data and contributing metrics that help you understand variations of your KPIs. In our previous cross-sell example, you might define a KPI that measures the dollar change in average shopping cart value compared to the average shopping cart value before cross-sell recommendations. But you will also need to define some contributing metrics (for example a metric that measures cross-sell offer uptake) that help you understand whether or not the change is due to your new cross-sell recommendations.
It’s critical to measure business performance after deployment so you can improve over time but you can be more proactive. By defining your metrics upfront, and measuring them against your data extracts, you can refine your decision logic prior to deployment to ensure it will meet your business performance expectations and objectives. In an underwriting application you will likely have a metric that measures your decision outcome in terms of whether you accept, reject, or refer the application to manual underwriting. This metric is valuable prior to deployment since it enables you to anticipate and control the number of referrals to a level your underwriting team can realistically handle.
3) Use an agile approach.
The principles of agile development apply to developing decision management applications. It’s best to follow an incremental approach rather than a traditional waterfall SDLC where all business rules are discovered and analyzed upfront. In an agile approach the business rules that define a decision are discovered, analyzed, and implemented in short cycles so that the project team extends the scope of the decision over time as new rules are discovered and implemented.
When rule discovery is done as an isolated project ,where business analysts discover and document the full set of rules behind a decision, many problems aren’t discovered until later when the rules are implemented and can be executed and tested. We know of several projects that followed this path and spent months, or years in a few cases, discovering, documenting, and analyzing rules. When the rules were eventually presented to IT as requirements for a new system, the IT team encountered many problems and uncovered many issues causing a great deal of additional analysis.
The ABRD (Agile Business Rules Development) methodology is a free, vendor neutral methodology for decision management applications.
ABRD promotes short iterations in which you go through the rule discovery, rule analysis, rule design, rule authoring, and rule validation tasks in short two to four week cycles. Since the BRMS or DM product is used as early as possible, analysis and design issues are uncovered and resolved and the project team is able to make continual progress with each successive iteration building on the last.
For More Information
There are some good resources available for more detailed guidance on your decision management projects. James Taylor’s book Decision Management Systems provides many examples of real-world decision management systems to illustrate how they differ from traditional systems and how organizations are benefiting from them, as well as practical guidance on how to design and implement them. Ron Ross’ book Building Business Solutions and Barbara von Halle’s book The Decision Model provide approaches to help you discover and model operational business decisions. Jerome Boyer’s book, Agile Business Rule Development provides detailed information on how to apply ABRD to build decision services — though the implementation examples in the book are based on a specific BRMS, ILOG JRules.
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager