- Where Does the Business Rule Approach Apply?
- Let's Make a Deal
- Reempowerment for the Company's Provisioning Processes
- Business Rules as Customer Interface
- What about Web-Based Commerce?
- Reference
This chapter is from the book
This chapter is from the book
This chapter is from the book
Reempowerment for the Company's Provisioning Processes
There's a Lot More to Reference Data Than Just Data!
A high-level manager at a large, well-established high-tech company recently summarized his company's operational problems in two succinct statements:
“We can't always deliver the products we announce correctly.”
“We don't always know exactly who our customers are.”
These problems posed 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, at several points in the process growing pools of workers had formed, focusing almost exclusively on problem resolution.
The manager's first impulse was to consider reengineering 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, 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 well organized.
In IT terms, applications supporting the fulfillment process were dependent on data feeds from other operational systems. IT therefore viewed the issue 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 (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 ongoing review and approval process, which involves many levels of staff in different parts of the organization. The 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 even reaching 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 the company had no focal point for managing the complexities of customer data (for example, subsidiary versus parent company, account versus customer, and so on). Rules about customer identification and data could not be effectively enforced at the source (that is, at the point of origin). Although the company's data warehouse did support a consolidated version of customer information, this data was aimed for business intelligence (that is, customer profiles, trending, competitive strategy, and so on) rather than for operational needs.
As a result of this analysis, the company began to focus more and more on the two upstream business processes: the product release process and the customer process. Its motto became the following.
Note
“Do it once, right at the source.”
Doing it right at the source is another basic principle of the business rule approach. As the above case study illustrates, it means reexamining the business processes that provide essential business inputs (for example, product release information and customer information) for day-to-day operational processes. My name for these upstream support business processes is provisioning processes.
Provisioning processes present a high-yield opportunity to apply business logic 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, and so on. This is obviously just the tip of the iceberg. A more complete list is presented in Table 2-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 was no less than correct product configuration. This capacity, by the way, encompasses support for fast product reconfiguration—increasingly a must in today's competitive business environment.
Table 2-1. Examples of Provisioning Processes
|
A provisioning process and the associated business rules might focus on … |
|
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.2 It turns out there is a whole lot more to “reference data” than just data!