Business Rule Re-Engineering

by Ronald G. Ross

An exciting new idea is emerging in the industry. I am not sure whether the idea has its roots in Business Process Re-Engineering (BPR), or in traditional database circles. More likely, its origin lies at the intersection of the two -- with that small, but potent, new group of professionals now focused on business rules. I discussed the idea most recently with Wanda Michaels of Kogawa Consulting.

The idea is based on the observation that the dollar-and-cents savings that result from successful BPR projects usually have more to do with rethinking business rules, than with re-doing workflow (i.e., business "process") per se. Actually, this should not come as a surprise. Since business rules are more basic to the company than workflow or business "process," the leverage they offer naturally should be greater.

Let me offer an example. A large retail concern had an existing business rule that all its products should be priced a least one cent less than the competition's. To support this rule, it ran continuous checks on competitors' product pricing. This resulted in frequent adjustments, and a never-ending cycle of re-tagging items in stock -- a time-consuming, expensive, and very cumbersome process.

Initially, the company sought to re-engineer the associated workflow. However, this produced no more than incremental improvements. Then the company decided to rethink the pricing rule itself.

The company had assumed that it would lose customers on as small as a one-cent price differential. After some discussion, this assumption was proven wrong. As a result, the price differential was raised to a higher level. This decision, in and of itself, reduced the workflow load to a more tolerable level. (To allow for fast-paced adjustment in the future, they also subsequently established the price differential as an easily-changed parameter for their IS environment.)

I am virtually certain that many, if not most, successful BPR projects tell a similar story. The obvious question is why not simply do Business Rule Re-Engineering? This is an idea whose time I believe has come.

In proposing this, let me be clear that I believe workflow still has a role to play. Stepping through as-is and to-be procedures (or business "processes") with users, if done correctly, remains one of the best techniques to identify and analyze business rules with re-engineering potential.

The difference with Business Rule Re-Engineering is really one of emphasis -- putting business rules at the center of things, rather than on the periphery. But such "adjustments" often have a way of producing thundering revolutions. Just think what Copernicus managed by putting the sun at the center of things, rather than leaving it on the periphery.

standard citation for this article:

Ronald G. Ross, "Business Rule Re-Engineering," Data Base Newsletter, Vol. 25, No. 2, (Mar./Apr. 1997), URL: http://www.BRCommunity.com/a1997/a357.html.

September 2005
The Fin de Siegle Legacy Mindset
By Ronald G. Ross -- (November/December 1999)

August 2005
Analysis Paralysis Just May Save Your Life
By Ronald G. Ross -- (September/October 1999)

July 2005
If We Had Started Coding Already...
By Ronald G. Ross -- (July/August 1999)

June 2005
Your Core Business Processes Need a Rule Engine
By Ronald G. Ross -- (May/June 1999)

May 2005
Four Things Wrong with the Way We Develop Information Systems
By Ronald G. Ross -- (January/February 1999)

April 2005
Push-Type Data Hub vs. Pull-Type Data Warehouse
By Ronald G. Ross -- (November/December 1998)

March 2005
What Knowledge Management is About (And What it Has To Do With Business Rules)
By Ronald G. Ross -- (September/October 1998)

February 2005
The Next Great Leap Forward ~ About the Changes You See
By Ronald G. Ross -- (May/June 1998)