Business Rules for Everyone

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.

This entry was posted on Monday, April 16th, 2007 at 10:03 pm and is filed under Business Rules. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

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.

This entry was posted on Monday, April 16th, 2007 at 10:03 pm and is filed under Business Rules. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.