A high-level manager at a large, well-established high-tech company recently explained his company's operational problems in two short, succinct statements:

1. "We can't always deliver the products we announce correctly."
2. "We don't always know exactly who our customers are."

These problems pose serious risks to the company's ability to remain competitive.

A quick look at the company's fulfillment process revealed two obvious signs of trouble.  First, the rate of complaints from the company's best customers was significant.  Second, growing pools of workers had formed at several points in the process focusing almost exclusively on problem resolution.

The manager's first impulse was to look at re-engineering the fulfillment process itself.  That course of action was a daunting one, however, because of the size, complexity, and distribution of the operation.  It also promised only incremental improvements at relatively high cost.

Probing deeper, however, it became apparent that the real source of problems did not lie within the fulfillment process at all.  The fulfillment process was highly dependent on other aspects of business operations, and these other aspects were simply not that well organized.

In IT terms, applications supporting the fulfillment process were dependent on data feeds from other operational systems.  IT therefore saw the matter as a data quality problem, and proposed a technical solution.  From the business perspective, however, the real problem did not lie with the data, but rather with the business processes that produced the data.

There were basically two such processes.  First was the company's product release process.  This process, which for more complex products typically stretched over many months, involved establishing valid product configurations based on a significant number of technical, packaging, and marketing guidelines (a.k.a. business rules).  It also orchestrated the timing of releases across the large number of worldwide geographical areas of company operations.  Each geographical area, of course, had its own local rules for releases, based on law, market factors, and customs.  Also important was coordinating the on-going review and approval process, which involves many levels of staff in different parts of the organization.

This product release process had evolved in an ad hoc manner over many years' time and was highly fragmented.  This produced flawed product and release data before it ever reached the fulfillment process.

The second business process supporting the fulfillment process was the company's customer process -- or rather the lack of one.  The company had never evolved a global view of the customer base (at least at the operational level), and consequently had no focal point for managing the complexities of customer data (e.g., subsidiary vs. parent company, account vs. customer, etc.).  Rules about customer identification and data could not be effectively enforced at the source (i.e., at the point of origin).  Although the company's data warehouse did support a consolidated version of customer information, this data was aimed for decision support rather than operational needs.

As a result of this analysis, the company began to focus more and more on the two upstream business processes, product release and customer.  Its motto became the following:

Doing it right at the source is a basic principle of the business rule approach.  As the above case study illustrates, it means re-examining the business processes that provide essential business inputs (e.g., product release information and customer information) for day-to-day operational processes.  Our name for these upstream support business processes is provisioning processes.

Provisioning processes present a high-yield opportunity to apply rule technology.  They are inevitably rule-intensive, but are not themselves highly dependent on incoming data feeds.  Also, they inevitably offer substantial opportunities for direct specification of rules by business-side workers.

From an IT perspective, provisioning processes produce what has traditionally been called reference data -- data that historically often appears as codes and/or in look-up tables.  Typical kinds of reference data, as suggested by the case study above, include product configurations, product families, customers, geographical areas, etc.  This is obviously just the tip of the iceberg.  A more complete list is presented in table 1.  For each, there is an associated provisioning process -- and a likely candidate for a business rule project.

The term reference data, unfortunately, does not do justice either to the problem or to the core issue of provisioning processes.  From a business perspective, provisioning processes are critical to the effectiveness of operational activities.  For example, in the case study above, at stake is no less than correct product configuration.  This capacity, by the way, encompasses support for fast product re-configuration -- increasingly a 'must' in today's competitive business environment.

From a business rule perspective, the core issue lies in standard business vocabulary -- the terms the business uses to communicate (and potentially to automate) fundamental aspects of its knowledge.  It turns out there is a whole lot more to "reference data" than just data!

# # #