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.

Business Rules in “Vicious Cyclic Markets”-Fraud detection An Example…

Anti-virus software market is a market that I like to call the “Vicious Cycle Market”(VCM-There is my first three-letter acronym -TLA!). A “Vicious Cycle Market” market feeds on itself. Its characteristics are:

1. Drivers Promote the Market: The Primary Drivers of the market benefit with each new advancement. It serves as a challenge. For example each new version of an anti-virus software prompts a hacker to create a better virus and vice-versa. In other words lack of a virus means a doomed anti-virus market.
2. Time is of Essence: If the solution to the problem takes too long then it is no longer useful. The cost of not taking corrective action is way too high.
3. It is Viral: Looks obvious, but the fact is the driver multiplies and moves through the community.
4. The market lags the driver: In other words, the solution is a post-facto event.

Fraud detection is a simillar market. The primary critical challenges are:

1. Time is of essence: If it takes too long to detect it or the detect the underlying conditions the system fails.

2. Manual processes aid fraud: Training personnel to detect fraud is not always easy, if systems can prevent fraud or detect it that would be ideal.

3. Understanding conditions for detecting fraud requires stakeholder involvement: A surveillance inspector is required here - a developer would be a misfit.

The avoided costs are significant when you think of automating the fraud detection conditions using a BRMS. besides even throwing a number of people around for detecting fraud may not help - it simply wont solve the problem, especially if the number of transactions is very high.

We recently worked with a stock exchange to help them implement a fraud detection system. About 10 surveillance inspectors create fraud detection rules that form the heart of the system. Given that it is a stock exchange, it was interesting to see the peak transaction activity.

Benchmarks For Business Rules
I found this posting (referring to JBoss site) on Manners and Waltz.

It is true there are significant number of rule formats, that impact decisioning . Decision Tree, Procedural Logic Flows, Decision Tables and more. So its confusing out there.

IMHO this is going to be another stumbling block for the business rules apart from others:

1. Standards: Lets face it. There are none, and from what little i can glean from other initiatives (SBVR included) - the movement isn’t there. JSR-94 was JDBC to Databases (and yet it didnt address critical questions) and you have no SQL equivalent. This defeats the whole purpose of standardization. SBVR is to Business Process Modelling and there is is no BPEL in the rules market. SBVR itself sounds fairly difficult to master! I wonder if a Human Factor expert is on board at SBVR.

2. Benchmarks: I really dont understand when any vendor talks of 10 times or 100 times better performance.

3. Standard Rule Representations: I doubt if this is codified anywhere. Practically each tool has its own formats and ways of doing things.

And then finally the BIG question, where does BRMS fit into the Software Development LifeCycle.

Now as someone who feels that business rules has value, you might feel i am doing my cause a disservice. No, all i am saying is that the value of the technology has not yet taken shape and there is much confusion out there- it should have a much wider acceptance than it has now.

BPM Versus SOA - David Ogren’s Blog

Was reading David Ogren’s BPM Blog at:

http://www.ebizq.net/blogs/bpmblog/2006/03/soa_versus_bpm.php

I think its a thoughtful and well written article. The difference between SOA and BPM is thin but it has been well explained.

My opinion is, the line is blurring further down.

The last statement he makes does go well my thinking: “But the more strategic a BPM project, the more it will be intertwined with a company’s SOA strategy.”

“Oops! Trader mistakenly spends $251 million” - Another Business Rules Example

“TAIPEI, Taiwan - A Taiwan stock trader mistakenly bought $251 million worth of shares with a mis-stroke of her computer, meaning her company is looking at a paper loss of more than $12 million and she is looking for a new job.
The trader with Fubon Securities made a typo while filling in a small order from Merrill Lynch on Monday, creating confusion when many small firms inexplicably surged past the 7 percent trading limit.
“Something like this is difficult to explain to superiors,” a Fubon executive said on Tuesday.”

Read more at http://msnbc.msn.com/id/8382753/?GT1=6657

… my guestimate is that the poor soul, just added a couple of extra zeros there. well dont want to play the blame game, but really….

Bad testing? Bad User Acceptance Testing? I really dont know. My take? Form validation rules

-
NO TRADE, SHALL BREACH THIS:

If
The trade amount is greater than 25 million$
Then
……
(Do whatever, dont execute the trade…).

The result: some stocks inexplicably rose 7% that one day. (Apart from the obvious losses to the company).

In hindsight perhaps it is easy to talk about this. Sitting in front of my comp, sipping my coffee and writing this blog its easy to see. Visualization before the event would have been really tough. I empathize with the IT there and more so with the trader who lost his job. The article goes on to say that the trader was not familiar with the new computer system, but give the poor guy a break!

One could argue that its poor testing. But think of it, if within the process we have a “validate trade” ruleset (or group of business rules) along with perhaps a decision tree or whatever (some form of sequential logic really - call it workflow rules whatever or just plain procedural code) and this was visible to a business analyst, there was perhaps a much better chance of identifying it.

Better yet if the business rules were unit tested - it would have been flagged. It beats me, if for code the idea is to unit test, do integration testing and then user acceptance - why dont we do that for business rules - isolated independent business rules. Thats what the business rules approach will bring to the table - a discipline that could avoid errors.

So when one talks of “costs of correction” you know what it means - it is precisely these avoided costs that are de-risked. For critical form data, least one can do (whether you are going in for a Business Rules approach or not): Externalize the business rules-make sure the execution is visible. I would say externalize the rules (jar file, dll whatever) - just that act of having it externalized and tiered will help.

Am i going overboard and suggesting that Business Rules approach would solve everything? Perhaps even without a BR approach, good disciplined programmers would have caught it or perhaps users …, the point is you need the right tools for the right job.

We helped a leading investment bank in “Trade Lifecycle Management” a few years back. At first i couldnt believe it that the folks there were investing that kind of money in the project (and to think of it most rules there were validation rules).

My company’s(YASU Techologies) product architect wrote an interesting white paper on testing business rules. You can download a copy at:

“How Conventional Testing Methods are not equipped to handle Business Rules Implementations”

Control and Business Rules In Spreadsheets dont go hand in hand

For those organizations that are looking for control (compliance -SOX, Basel) whatever, here is the take. You never can have your policies embedded within the spreadsheet.

Sounds commonsense? Huh. But give me a dollar for every person out there who is using a spreadsheet with CRITICAL business rules embedded in it in organizations that *must* comply to such regulations and you will have a new millionaire.

Its true and its all out there. There are critical functions in financial institutes and its not a secret really. Perhaps i was the last one to recognize this, but it is true.

Forget about compliance it doesnt make business sense!

When you have 10s of frontline agents it becomes difficult to control where this information goes. It doesnt take deliberate action, it just needs to be an inadvertent one.

And let me make no appologies here - business rules engines (decision management) whatever fancy TLM(two or three letter acronym really) you call this by, helps you avoid this.

Google - YouTube acquistion and then Business Rules and Efficiency

I know, i am late to this. But its an interesting acquisition, nevertheless. video blogging is the future. Undoubtedly if expressing views and the notion of a community are important, video blogging should expand reach further.

By now you may have realized that i am pretty new to blogging and video blogging (i doubt if i will ever take it up-really).

Sometimes i wonder what is google really doing. I mean if one were to put a 5 year strategy map for google where is the thought process, what are the trends?

I dont know folks but did audio blogging ever come up? I mean i would love to express views on camera but i am way too shy for doing that. Voice hmmm … perhaps yes.

I call the google strategy as “Channel Creation For Expression”. And then there is this word “Sense”-Ad-sense and what not - so should it create a channel for sense? Search, Writing and then video. I know its stated in a much simpler fashion that it is truly but seriously - search, i think its such a fundamental utility. I would be willing to pay google for allowing me to search, the amount of time it saves is phenomenal. Where is the business rules portion you ask? well there is none - wanted to write about this and get it off my chest so had to write it. But efficiency is my fav topic.

I guess the primary reason that business rules market could grow and survive is the kind of business efficiency it brings to the table. And yet… i think its one of the most ignored markets because that efficiency is never truly recognized. Why is this the case?

The utlimate efficiencies that business rules brings is to the key performance indicators to the business and building that bridge is not easy - it requires visionaries to bring this out. And the momentum has never carried it forward-never made it go over the bell curve to mass majority to become a commodity software market (which would have been great).

So is this a perennial early adopter market? I mean even if Fortune 50s adopt it, lets face it-the market size is not big enough. It is still fragmented.

An interesting comment i heard recently was I can hire 1 out of 2 million Java Programmers to code in Java-business rules or no rules, how many business rules experts can i hire! Agreed, not many - no matter how easy the tool is you are still talking of IT efficiency. Thats not true value.

I have some ideas(!?) for this and for reasons of confidentiality i can’t discuss. I dont think right now any company in the rules market has the muscle to execute that strategy(aha there is the execution catch always). But it can be a winning one that could propel the market to the over 1 billion mark. Tough talk? Thats what blogs are there for, i thought.

Grammar, Phrases and the bells and whistles of natural language…..

Oflate many times i come across this notion of “building rules by natural language” - phrases, grammar-like….

Its an interesting notion and perhaps feasible with 1 language. Maybe i am missing something here….I feel that it hits out against the very foundations of internationalization. I feel most software applications are just about grappling with the notion of a global market and internationalization. Then you bring in the mix of grammar.

For would the same grammar & syntax work in German, Mandarin? And if one takes the average life of a software application to be 5-7 years - what does one know of the enterprise’s M&A strategy, growth into new markets. Would it work there?

Most recently a leading enterprise (Fortune 1000) was looking at business rules for a performance management application. 8 months back they had operations in mostly English speaking countries. They then ventured into China(over the last 8 months) - the change was pretty dramatic. The implications were all there to see…

I am not saying that natural language is not the way to go - but should marketing hype create the mindset.

Reducing Closure Time in Mortgage Lending - a Customer Perspective

We recently worked with one of the leading retail secondary lenders. In a market that is having a downturn cycle this customer has had little effect. Competitors for this customer i believe are seeing 30% drop in the number of loans they are closing.

With about several 100s of sales agents and 100s of employees - whose jobs are intact (when you consider that across the country in this industry it is that much harder to keep people!) it was truly humbling to know that we had a part to play.

About two years back the CIO of this company was visionary and embarked on automating eligibility and pricing guidelines from various lenders within their system. Prior to this sales agents needed to be trained in each product, and then there could have been a lot of mistakes. In fact the existing system hardly captured a few simple products.

Why was this and what does a rules engine have to do with this?

1. It turns out that the primary critical issue was that capturing these loan products within the IT system was time consuming.
2. Intra day rate changes were happening and this would often take 2 days to reflect within the system.
3. Rate lock-ins were handled manually by sales agents.

Reducing the closure time by about 20% - just about the efficiency required to manage the downturn

1. The business rules paradigm using QuickRules solved this by allowing product guidelines to captured rapidly.
2. Within a short while most product guidelines were up and running. Intra day changes now take less than half a day and hence there is very little in terms of manual pricing - its accurate and reflects the current pricing.
3. Since the rules engine supports invoking business rules as of a previous date rate lockins are automated - no manual processing.

End Result- Number of leads handled per agent increased. Since the manual steps reduced, the wait period reduced as well. A lot of the decisioning including suggesting the best product to the customer is now done by the rules engine.