March 8, 2002

The Cost of Integrity

Don't let transactional system standards keep you from reaping BI benefits

By Ram Reddy

During the course of implementing business intelligence (BI) systems within major corporations, I repeatedly run into the same challenges. It has often become evident that neither the IT people nor the business users of BI systems have the mindset to deploy and use BI systems correctly. IT practices and customer expectations arise from experience with the online transaction processing (OLTP) world.

Pursuit of data integrity and BI technology evaluations frequently derail BI projects from realizing their business objectives.

OLTP and BI applications shouldn't be approached with the same mindset. OLTP applications are typically engineered to support millions of transactions over many years. In contrast, BI applications, in extreme cases, may be used only once to make a business decision. OLTP systems can't support their volume of transactions without excellent data integrity and accuracy; BI systems require data at a more aggregated level, which tolerates a little more inaccuracy. OLTP technology investment decisions are based on operating efficiencies and reducing cost per transaction; BI system technology investments should be based on return on investment (ROI) criteria.

An example from Paul Westerman's book Data Warehousing: Using the Wal-Mart Model (Morgan Kaufmann, 2000) illustrates the IT practice and user mentality needed for BI systems. The business users were asked if they wanted to roll out a buggy and crash-prone BI system or wait until the kinks were worked out. The resounding answer was to roll out the crash-prone BI system because it was helping them make informed decisions! You would never consider doing that for an OLTP system.

To further put this problem in perspective, consider the difference between macro- and microeconomic data. Macroeconomic data is essential for governments at all levels to make decisions — such as the number of roads to build and other major infrastructure items. For making these types of decisions, approximate population data such as "1.5 million" is good enough. There is no added value in gathering detailed numbers revealing that the exact population numbers 1,523,121 citizens. The marginal costs of getting data at that level of accuracy are significant. And even when you go through the expense to obtain that detail, it will never be complete because of the dynamic nature of the system being measured: Births and deaths during and after the measuring period make 100-percent accuracy impossible. The typical BI system uses data at the macroeconomic level of accuracy to deliver business value. However, the IT professional is trained to cleanse data to near 100-percent accuracy for use with OLTP systems.

BI systems integrate data from multiple OLTP systems to generate BI. In most cases, a transaction transforms as it passes through multiple systems across the firm's various functions — such as sales, marketing, order entry, billing, accounts receivable, warranty claims, and return merchandise authorizations. The transaction may begin in the prospect database as shown in Figure 1, but it may end in any one of multiple systems in the firm. Taking data at any point in time from all these systems and integrating it within a BI framework creates anomalies. The transaction is in flux. Data from various OLTP systems will never balance from an accounting standpoint. Many BI development projects get hijacked into fruitless data-cleansing efforts before the system even gets implemented. I have been part of numerous BI projects in which the IT team quixotically chases data-cleansing windmills.

The business subject matter experts (SMEs) who understand the data could easily stop the wild goose chase, but they are often not part of the DBA teams responsible for the extraction, transformation, and loading of operational data into the data warehouse. The SMEs and a statistics expert should be the ones determining the level of data cleansing and integration required to achieve the business benefits from that system. How often do you find a person with strong statistical skills in your BI team? The statistics expert has the expertise to determine the level of data cleansing required to deliver the accuracy the BI system needs.

It goes against the IT professional's grain to put data into a system that isn't completely accurate. This philosophy is the biggest stumbling block for the IT professional to successfully developing and deploying BI systems. In addition, the user perception that BI systems are a different beast needs to be managed very well — especially by the IT function.

BI is perhaps at an awkward stage in its evolution. In the past, BI teams were part of the data warehousing group. BI functionality was the purview of analysts and power users. In today's competitive marketplace, BI systems are increasingly used by front-line managers within the firm and across the extended enterprise. The approach I advocate in this article is derived from my personal experience in helping businesses use BI systems for competitive advantage.

But before I go any further, let's have a brief overview of the three generic BI categories. This overview will set the stage for a discussion on what it will take to successfully develop, deploy, and obtain business value from BI systems.

WHAT IS BI? THREE TYPES

BI systems integrate data from internal and external sources to generate intelligence that the business can use to make better decisions faster. There are three generic categories of BI systems: historical, analytic, and predictive. Figure 2 illustrates this categorization with a car metaphor. Historical BI can be likened to looking in the rearview mirror. BI is gathered from analysis of historical transaction data — typically integrated from OLTP and data warehouse systems.

This backward-looking analysis aids the decision maker by providing feedback on what worked and what did not. For example, it may help a retail firm decide on the optimal mix of products for a particular store location, based on past sales experience. From an implementation view, this is the easiest category of BI systems to implement, if the BI team doesn't get caught up in extensive data cleansing efforts.

Analytic BI is generally an iterative process. A BI system is in place to analyze data sources (some realtime) and generate intelligence for decision-making. It's through trial and error that these systems get developed. It's very similar to driving a car. The driver uses feedback from the surrounding systems (odometer, steering wheel, and so on) to operate the car. For example, a BI system in this category may help a regional manager of a retail chain fine-tune the pricing and promotional policies daily, based on scanner data and inventory levels. The firm needs process maturity to deal with wrong decisions that are made on the basis of intelligence from such a system. Instead of trying to assign blame, the process needs to be reviewed to identify the causes for the erroneous recommendation, remedy the cause, and get back to using the system.

The last category is predictive BI. In Figure 2, it relates to the forward-looking headlights of the car. BI systems integrate and analyze internal and external data sources to generate intelligence about future events. This intelligence is used to make proactive, future-oriented decisions. The intelligence in this category could be the predicted demand for the firm's output in the next year. This demand may have been computed from statistical analysis of macroeconomic data — that is, a good leading indicator for the firm's product. Predictive BI systems that depend on external data sources are straightforward to implement. Those that base the predictions on historical data within the firm need a statistics expert to determine the level of data cleansing necessary.

• Privacy
• Your California Privacy Rights
• Copyright © 2008 United Business Media LLC