Breaking the Cycle of Failure

A business process model approach toward requirements analysis may improve your data warehouse project's odds of success

NO MODEL, NO UNDERSTANDING

For any business, your business processes exist but they may or may not have explicit models. However, for effective communication between your business users and data warehouse developers, you must explicitly model these processes. The relationship of your information systems to business processes is also important. OLTP systems control and record your business processes, and in general your data warehouse and BI systems contain measures of processes that are important to your business users. For example, in the assembly and test process, OLTP systems may record the assembled part's serial numbers, control the tests performed with their outcomes, and record the repair activities. The controlling and recording occur at a very low level of the process hierarchy, usually at the activity level, but business users want to see the process measures at different levels of the hierarchy. In fact, the metrics of the high-level processes are usually the most important to users, and the data warehouse system must support that.

In this example, the measures of interest could be the reject rates, repair times and costs, and the overall time and cost of the process. These measurements are not all at the lowest level of activity. The overall time of the process would be a measure of the process at the next level up in the process hierarchy. (See Figure 2.) The desired measures dictate which recorded values to use from the OLTP, not the other way around. A data structure approach is common in the data warehouse design, but by using the data structure-based approach, you lose the impact of the business process measures to business users.

This business understanding at the process level shows why the data model approach of using OLTP systems to determine the needs of a data warehouse can be so confusing to business users and why data warehouse developers cannot easily understand the business users. Unless your business process is very simple and both parties can intuitively and correctly understand it, you'll have a breakdown in communication. Without an explicit business process model, you must infer the business process meanings, hierarchies, and sequencing, which is very difficult if not impossible.

BUSINESS PROCESS COMPLEXITY

Business process models can become very complex when you carry out the low-level details. However, without an explicit model, data warehouse developers will have different internal models of the business than business users. Even different business users will have different internal models of the business. For example, sales may seem like an easy process for everyone to understand, but it is made up of many pieces that fit together.

Consider the following subprocesses and their impact on the sales process: item returns, rebates on items, rebates on total amounts, changing rebates when a return occurs, returnable packaging (such as a chemical tank that's returned when the chemicals are used up), multiple staged delivery, and cancellations after partial payment. Part of the requirements methodology is to determine what is and isn't important as well as the correct abstraction level of the processes. For instance, the OLTP systems may process returnable packaging as a sale followed by a return of goods for a refund. But the business impact may be much larger because the returnable packaging is expected to arrive and stock supplies of it may affect shipments and sales. The complexity of the model is exactly why you need an explicit model.

REQUIREMENTS AND DESIGN METHODOLOGY

The fundamental steps of a requirements methodology for a data warehouse and the connected BI systems should now be clear. The first step is to determine the business goals. The second step is to determine the business processes that are affected by or contribute to those goals and model them accurately. Now, your desired goals reflect the measures and metrics you need from these processes. A better understanding of your business processes often affects the understanding of your goals. The reverse is also true.

The next step is to connect OLTP systems to the business process model via the data definitions in the OLTP. You must identify the low-level recorded elements of the processes that you used in the computation of the process metrics in the transaction systems. For example, in the assembly and test process, a desired metric may be the elapsed time it takes to create an assembly; this time may require some extensive calculation from many different transactions. The recording of those transformations and computations is part of the responsibility of the data warehouse toolset.

Rate This Article Rating: 1 (best) 2 3 4 5 (worst) Comments: Optional e-mail address:

SATISFACTION AND SAVINGS

Constructing any software system without a robust method to determine the requirements is a risky undertaking, and constructing a data warehouse is no different. Business users understand the business as a set of business processes, and data warehouse developers must also understand it at that same level, otherwise the system will not meet the needs of the users. The methodology centered on explicit business process models for determining the requirements for a data warehouse provides a direction for better specification and maintenance of data warehouses. By using a systems model that connects the business process models with the transaction systems and the data warehouse designs, you can track and trace the requirements along with changes in the requirements. (See Figure 3) The results are satisfied users and data warehouses completed with reduced life cycle times providing great savings in construction costs.

The author thanks the directors of the Research Center for Data Warehouse Technologies at SAS Institute for their gracious support in the early stages of this research.

Mark Riggle [rigglem@mindspring.com] is an independent consultant with more than 20 years of experience in software research and development in programming language design, business intelligence software, artificial intelligence, and data warehousing.

RESOURCES

Hammer, Michael and James Champy. Reengineering the Corporation, HarperCollins, 1994

Penker, Magnus and Hans-Erik Eriksson. Business Modeling With UML: Business Patterns at Work, John Wiley & Sons, 2000

UML and the OMG: www.omg.org/technology/uml/index.htm

Business Process Reengineering Resource Center (for tools and process methods): bprc.warwick.ac.uk/bp-site.html

White papers on business process modeling: www.proformacorp.com/downloads/whitepapers.asp

For business rules:

UML models: www.mdcinfo.com/OIM/models/BRM.html

The Business Rules group (formerly GUIDE): www.businessrulesgroup.org/brgrefs.htm

Related Articles on IntelligentEnterprise.com:

"Enforcing the Rules," August 18, 2000: www.intelligententerprise.com/000818/webhouse.jhtml

"There Are No Guarantees," August 1, 2000: www.intelligententerprise.com/000801/webhouse.jhtml