Business Rules for Everyone

I was reading Rajgo’s post on Business Rules and the SDLC series and thought would jot some of my experiences with customers.

Recently one of our(YASU Technologies ) shared some interesting numbers in claims processing. They were basically reviewing claims adjustment automation (not including the actualy scanning of claims forms and resolving the data errors). Essentially mainly the settlement rules. Prior to using QuickRules they were relying on a legacy claims processing software and this part of the process was yield them around 20% automation.

At the point when they looked at business rules technology-they were doing the rules in the ‘proverbial code’. Being a healthcare insurance major the claims got pretty complex pretty soon. 

The key problems were:

1. A lot of the settlement was happening manually. In other words adjusters would ‘decide’ on how to settle the claim

2. Whenever the claims processing software was not able to resolve a particular claim it would route the claim to a manual queue which would then be looked by the adjuster.

In addition to the fact that this was increating operating costs, there were several suspected leakages (which at that point was hard to measure as a function of capture-but now we can safely say that this was mainly due to the manual adjudication process).

Post Implementation metrics

We kept following to understand how the automation was improving (as a function of time)-this mainly gave an indication of how well the new processing application was delivering business value.  Automation was a direct function of efficient capture of business rules-the process didnt change and was mapped even before BRMS intreoduction.

As with any business rules capture the first phase of the capture involved:

1. Reviewing existing legacy code, extracting rules from this code.

2. Review of past specification documents and any notes on claims previously adjusted.

3. Interviews with some adjusters… but most importantly the process involved identifying manual claims and understanding the result of manual adjudication. This was done for some claims, this was a pretty signifciant move as otherwise the project would have been jeopardized (there is no single way to pinpoint the go-live for such an implementation).

Post implementation each manual claim that was adjusted was reviewed with adjustor and the decisioning logic was captured. Each claim was captured as a scenario and used as a regression testing case as well. This was really important as mutually exclusive rules were a likelihood in a complex healthcare process.

Learnings from this case

The major learning we had from this is what I wanted to share here:

1. Rules capture is an ongoing process. It is an enhancement exercise. Having said this, systems need to be in place when automating manual proceses to understand the method of decisioning the agent is utilizing.

2. Regression analysis is important for ensuring the there are no conflicting rules.

3. Many times business makes up business rules to explain siuations. What this means is that rules evolve over a period of time. This is very important -several times the decision is known but uncovering the decisioning process and method is a huge effort.

In my next post i wanted to see if could formalize this portion. I would love to share experiences which anyone has with respect to process automation and how they went onto capture decisioning logic (when the manual process functions were replaced by automation decisioning touchpoints).

I was recently in an interesting situation. The customer had a clear business rules problem. The background was they were using Siebel. The pricing rules were all encoded into the Siebel system and it was hard for the sales agent to actually review the prices. The sales agent had 1 single pricing model to price the product. The issue was that in that particular industry pricing is a function of the length of the contract. This is true for many industries, for example take car leases. Leasing a car would mean that you are going to pay for two costs : 1. Depreciation 2. Finance charges incurred on the car. Since the automobile industry is such a mature industry it may not matter if you took a 1 year lease or a 18 month lease (depreciation calculations are relatively simple). But consider other industries that are market driven but have other factors that drive price. For some reason this system was never designed that way.

 Imagine a product that is not that commoditized - and yet there is a expected market rate and a formal discounting mechanism. Unfortunately for this prospect there were some ‘pricing experts’ who would create a range of discounts and concessions that the sales agent could offer. This would show up on the screen (with the price not changing for term of the license).

They had been drained through the dollar with implementation and integration and it was tough for spending any additional money. A typical IT scenario and i suspect something which was the case with most CRM implementations.

There were two business issues as i saw:

1. Decisioning on the price was being done by a sales agent with the customer. It could have potentially several implications:

a. Underselling or overselling - which meant the days active in the sales cycle were higher.

b. Underselling would mean that you are leaving something on the table (when you know that there is an expected market rate).

c. Overselling could mean a longer time-to-close - which means the asset is in the market without being optimally charged for.

d. Concessions and discounts are not through analysis (definitely an enterprise level decisioning) of data.

Unfortunately the IT team felt that having a few parametric database tables will solve the problem. The minor snag in the solution was that the pricing and concession rules were not going to be visible (unless ofcourse a mini decision engine was being all ground up) and the efficiencies will continue to linger.

What is the cost of time to close in sales(or sales cycle)?

Most CFOs will crank up numbers and tell you what it means.

1. A 10% reduction in the sales cycle means 10% lower leads. So perhaps some of the marketing budget will be impacted- a cost avoided.

2. 10% reduction in sales cycle means there is 10% better cash flows. for example if you have a sales cycle of 6 months and 18 days are reduced off the sales cycle it means you receive 10% more money in that fiscal year (unless ofcourse you have saturated the market)

3…..

 I could go on… Concessions/discounts and pricing are really prime areas where an enterprise needs controls as well. Why was the last price quote for 140k and not 150k? Which discounts are leading to faster closes? Today some of this information is captured but not to level of detail one would like. Trouble (atleast from the vast number of Fortune 500 companies) is that there are only a few departments measured along those parameters.

I received a lengthy RFP with some 50 features thrown in and i at once realized it was from the New! ‘do it yourself guide to selecting rules vendors’. I was surprised because the problem at hand really didnt require all 1001 features listed. And worse no one knew the original problem itself when it was time to review!  

Unfortunately when the evaluation went down to the software developer who was looking at the products most of these implications were never even communciated to the developer and ofcourse a list (or RFP) was prepared wiht the choiciest of features or “do it yourself guide” for rules engine selection(and to good measure each company’s ‘10 blah blahs you need to have in a rules engine’). Did he understand why they needed backward chaining for instance for this business problem? The ultimate answer was as suspected, they didnt know and also they didnt really care as I felt that it was prudent to point to the customer that the original value proposition for business rules was being lost in a plethora of feature functions that vendors were adding!

To me it appeared the following were the core set of constructs really needed for this business case:

1. Good decision table construct (to capture pricing matrices especially time series based one)

2. A good decision tree/flow chart construct to capture sequential logic.

3. Back end support to collect events to enable easy restrospective evaluation of which concessions/prices worked.

4. Access control at various levels (for example a sales agent needs to just see the rules versus the pricing expert’s needs to model)

5. Simulation of various scenarios during design time before a decison is deployed.

I proposed QuickRules from my company since it met all of these and tried to narrow their requirements utilizing the few things they required. A few months ago, there was another vendor (someone i wouldnt name) who was complaining about some of the expert systems algorithms and how they are not needed.

Personally i found algorithms like RETE to be extremely useful in case of validation rules. But it comes to looping (for example manipulating OrderItems within an Order) or likes some of the algorithms pose a lot of difficulty, likewise the whole notion of matrix like rating sheets and pricing sheets.