Business intelligence (BI) is exceptional at taking cuts of data and displaying it as reports and dashboards. BI can even reform data within analytic frameworks, allowing the user to view the data from many perspectives. However, BI is not great at transforming data based on business logic, allowing for new forms of analysis. An example might be posing a question such as “what would happen to my call center costs if I automatically approved all claims below this new dollar figure?” In this article, I will explore how organizations can combine business rules management systems (BRMS) and BI solutions to create new power analytics, such as a claims leakage analysis or Sarbanes-Oxley compliance analysis. I will also illustrate how this same powerful combination of tools used to form these new analytics can move from passive analysis to operational automation. 

What Does Actionable Mean?

Actionable means that you not only have a complete understanding of what is happening, but you have a reasonable understanding of where and why it is happening. With that basis, you are in a position to take action.

A Framework for this Discussion

For this discussion, I will use an example of automobile claims processing in the insurance industry. Most readers have either submitted an auto claim or can effectively imagine this situation. I will pose two questions as a typical business executive:

  1. How much money are we paying on automobile claims that we are not obligated to pay?
  2. If we automatically approved all claims below $1,000 for noninjury accidents, what would happen to our costs?

Question 1 reflects a question on compliance. Question 2 reflects what the effect would be as a result of a change to a business policy.

I will start the discussion using question 1: Compliance.

Why is Most BI Not Actionable Today?

BI software excels at taking large sets of data - organizing and combining that data into different views. You can easily pull a subset of claim data such as: analyze only the claims from 2007. You can easily carve and slice the data to answer many questions beyond the obvious. How many claims did we pay in 2007? How much was the average claim? What percentage did we pay? Even deeper, what percentage did we pay by region?

This type of analysis can be used to start the process of answering our real questions, but it can’t be used to actually answer our real questions. Classic BI cannot answer a question like: How much money are we paying on automobile claims that we are not obligated to pay? Or, what percentage of claims paid by region were compliant with my claims approval policy?

This is because BI can cut, sort and represent existing data, but it cannot analyze data to determine what each transaction should be if a policy was followed. Typically, BI is used to refine the scope of the question, and then manual review and analysis takes over. This is very expensive, and many of these manual analysis paths go nowhere.

Moving from BI to Manual Analysis - The Typical Last Mile

When you move into the manual analysis you will typically use a set of business rules to analyze the data. When you look at one of these claims, we use the current claim payment policy to judge which claims are valid and which are invalid. The instructions within the policy are business rules. You will typically use a statistically relevant subset of our claims to perform your analysis because it is too costly to assess every claim. If the policy is not very specific, there is room for interpretation and our analysis (audit) has the potential for error. If you have many people doing this analysis, then you have further room for difference in interpretation by the different auditors, increasing the potential for errors in our analysis.

It is understandable why people feel frustrated. BI often creates as many questions as answers. This starts a typical cycle of questions generating more questions. The answers are often difficult to understand and to prove.

How Do Business Rules Make BI Actionable?

I will summarize a pattern for using a BRMS to accomplish this analysis. I don’t have room to go into detail - email me if you are interested.

  1. Use a BRMS to code the rules for approving claims. These are the same rules used to perform a manual audit. BRMS will bring structure to these rules ensuring the rules are not ambiguous, etc. This is typically a fast and low-cost process.
  2. Take all 2007 claim transactions and use the BRMS to make each approve/deny claim decision again. You leave your original transactions (the ones made by your people) in place. This step will create a second challenger transaction record (stored in a different database). This decision will be based on a new BRMS automated policy. Each original transaction will now have a second challenger transaction.
  3. Now using classic BI tools, you can compare the two data sets and answer a whole new set of questions. By comparing the original and challenger transactions (one at a time or in groups), you can answer questions like:
    • What percentage of our transactions (original) are consistent with the policy validated transactions (challenger)? This will tell you what percentage of our transactions are policy compliant.
    • What percentage of transactions that were paid,should not have been paid? This answers our original question. But you can go so much further!
    • What percentage of claims did you deny that you should have paid? This helps assess litigation risk.

You can then begin to use low-cost BI techniques to cut your data to get detailed answers.

    • Sort the data by region to see if we have a particular region that is noncompliant with the approval policy.
    • Sort the data by training level of claims personnel to see if individuals with certain training are more or less compliant.
    • We can even use this technique to very quickly assess compliance to policy for every person processing claims, netting a clear list of personnel who are have more than 10 percent noncompliance.

You have now not only answered the question of “How much money are we paying on automobile claims that we are not obligated to pay?,” but you have a framework to drill down in detail to determine in exactly what environment or in what situation we are making these unnecessary payments. You can now quickly move to actions. Actions such as “assure all employees complete training level X by a certain date” if we determine that that noncompliance is happening in less-trained employees. Or, “move to investigation” if you deem that there is a high percentage of noncompliance in a given regional office by a specific set of employees.

Note: Using rules-based analysis, you no longer have to do a statistically relevant subset of our transactions. Because this is automated, you can assess each and every transaction for compliance.

Question 2: Analyze and Act on Change in Business Policy.

A More Sophisticated Analysis to Action Cycle

Recall question 2: ‘If we automatically approved all claims below $1,000 for noninjury accidents, what would happen to our costs?” How does rules-based analysis help?

You will basically follow the pattern outlined above. But instead of automating the rules associated with the policy that is inforce, you will build the rules associated with the new/changed policy. You will again take a set of historic transaction records and create a set of new challenger transactions. In this case, the challenger transactions reflect the outcome of these claims if you used the new policy.

You can now easily answer questions such as: How many claims would have been approved under the new proposed policy that was denied under the current policy? Interesting, but that’s only the tip of the iceberg. Below are some questions that can be answered (and some associated process) that make this analysis very powerful.

  • You can now identify what percentage of historical transactions already comply with the new policy. Each historical transaction that meets the new policy reflects processing costs that were paid but would not have been paid under the new policy. If you have 1 million transactions a year that fit the scope of the policy (<$1,000 and noninjury) and we already approve 90 percent of these, and the average transaction processing cost is $22, then we know by automating this new policy we will eliminate $19.8 million in cost.
  • If on the other hand you have historically denied 50 percent of these claims with an average claim payment (net to the insurance company) of $65, than you can compare your $32 million increased claims cost against our $20M reduction in processing costs, we see that the new policy will save internal resources, but not save money.

Nobody can deny the need to use BI technology and techniques to analyze data. But when business rules are combined to form new data, based on existing policy or proposed policy, the analysis can deliver more specific answers, which are actionable. These techniques can help close the loop on critical organization questions. Even further, because a BRMS is a form of automation, the same business rules used to analyze transaction data can be put into production and used to automate those transactions, taking significant operational costs out of the organization.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access