Last time^[1] I discussed how we tested (and retested) our system — to build an online credit system to approve online b2b transactions.  The last step involved monitoring and adjusting the implemented system.  Note that while I say "last step" understand that much of this is actually ongoing.

Monitor & Adjust

Monitoring and adjusting the system entailed these tasks:

1. Monitor rules based on code usability and commercial viability.
   
   
2. Do what-if analysis and track the overall performance of the rules.
   
   
3. Make adjustments to rules based on feedback and performance.

While the successful implementation of a Business Rules Engine (BRE) is a cause for celebration, the job does not stop there — the next phase is to monitor the project.  Monitoring relates to tracking rules and performance against intended goals.  Keep it simple, and ensure that rules do not become spaghetti code with numerous redundancies.  Projects should strive to minimize the total number of rules in order to better manage and maintain the integrity of the system.  One way to keep it simple is to track which rules are actually being triggered versus those that are never utilized.  Cases where rules are never triggered should be deleted (or expired) because this leads to a more efficient system.  Decision tables that reference specific outdated rules should be revisited.

The objective of a BRE is not just to code at near perfection — the real test is the commercial viability of the system.  Commercial viability relates to meeting set goals, such as obtaining an approval rate of at least 70% for customers.  This kind of goal is measurable, and any deviation — such as a high rejection rate — defeats the purpose of automation (and makes customers unhappy as well).

Striking the balance of keeping customers happy without increasing risks requires constant tweaking and monitoring of rules.  Performing what-if analysis by changing certain parameters and checking to see if rejections rates decline is a powerful tool.  Other changes may come from outside vendors, who may have a significant impact on current accounts — for example, a change in scorecards from outside vendors to reflect current economic conditions and increased default rates.  In our case, a what-if analysis was performed, showing that about 20% of approved credit lines would be declined, based on the new scoring model.  This was unacceptable from a customer standpoint since a sizeable number of limits had been granted over six months and continued to perform.  Based on results from this what-if analysis, a solution was crafted to ensure that customers would not experience a large drop in coverage while also ensuring that there was no increased risk.

A BRE project should be architected to be simple, process-driven, clean, and efficient, in order for users to understand the steps and objectives of the project.  Getting users to comprehend the project helps them to identify any gaps and to be more proactive at providing feedback on what works.  Users on the front lines are critical because they see and hear, straight from customers, what is working or (worst case) what is broken.

Change is imminent and at times unpredictable so using tools to monitor and adjust parameters is the next best thing, and a BRE provides the fastest way to execute these adjustments.  It is important to obtain feedback from the front lines, in order to adjust rules based on actual experience and regional trends that may impact the bottom line.

Conclusions — Lessons Learned

Technology will continue to evolve and provide competitive advantages, with applications that directly impact revenues or profits becoming the next "big thing."  I firmly believe that BRE is highly disruptive and an awesome business enabler that reverses control of technology to the rightful owner, the business expert who owns the domain knowledge.

This role reversal empowers the business to react to changes quickly — optimizing indicators, parameters, and business logic in line with strategic goals.  In the old structure, the technology team held the business logic in their black box, which led to frustrated users and mistrust from both sides.  BRE evolves the structure whereby critical business logic is housed in a black box and controlled by the business.

The BRE community needs to do more to educate and bring awareness to business users in order to remove the fear factor, which represents the biggest hurdle.  I hope my series of articles has provided a level of comfort and clarity by discussing a successful complex project that has been up and running for over ten years.  Communicating success stories in layman's terms and showing steps to implement BRE without a lot of confusing technical jargon goes a long way toward converting the business into believers.

References

[1]  Dencie Mascarenas, "Experiences in Re-Inventing a Business Process with Business Rules (Part 4): Test & Retest," Business Rules Journal, Vol. 12, No. 3 (Mar. 2011), URL: http://www.BRCommunity.com/a2011/b586.html

# # #