Business Intelligence Appliances: Disruptive Technology or Distractions?
May 23, 2007
Five steps for weaving data quality management into your enterprise data integration processes
May 28, 2007
Business Intelligence Appliances: Disruptive Technology or Distractions?
May 23, 2007
Five steps for weaving data quality management into your enterprise data integration processes
May 28, 2007

Operational BI – Four Flawed Assumptions

published in Information ManagementOperational business intelligence (BI) can be an integral part of a portfolio of BI solutions. But before you put it to use, see my May DM Review column for an explanation of several assumptions that can steer you wrong.

1. Assuming that you’re revolutionary.

While you might think that reporting from your operational system (online analytical processing [OLTP], enterprise resource planning [ERP], customer relationship management, supply chain management), i.e., operational BI, is breaking new ground, people have been doing it since these systems were first created. Failure to recognize their experience to learn something from it means you’ll be destined to repeat it.

Decades ago, operational systems were custom built or used proprietary databases. Nowadays, most are bought from application vendors and are implemented on relational databases. And because BI tools today can access relational databases easily, why wouldn’t you use your BI tool to access and report on operational data directly?

BI tool technology hasn’t changed much in the last several years, but the way it is marketed certainly has. Initially, these tools were marketed for organizations building data warehouses (DWs). BI projects always involved DWs or data marts or summary tables. In the 1990s, ERP application implementation teams were busy with Y2K and rolling out ERP modules – often replacing legacy custom-built applications. Since Y2K, however, these ERP teams and the ERP vendors have shifted their attention from getting the data into applications to getting useful business values out of that data. With new interest from the ERP vendors who started partnering with the BI vendors, they realized they could market their tools to be used for that task.

2. Assuming that everyone needs real-time data.

Accompanying the trend to use BI to get data directly from operational systems was the realization that businesspeople could get real-time data rather than waiting for day-old data in the DW. Certainly, many applications, such as call centers and inventory management operations, truly benefited from the real-time information. But then everyone wanted real-time data. Operational BI was seen as the way to get it.

Most business processes don’t need real-time data. In fact, real-time data would cause problems or create noise, e.g., inconsistent data results, that would have to be filtered out. Much of what businesspeople do is examine performance metrics, trend reports and exception reporting. Most are looking at daily, weekly, monthly and year-to-date (YTD) analysis, not hourly analysis or trends. There are some industries where that would be useful, but with most it doesn’t matter what was sold between 9:05 a.m. and 9:30 a.m. today.

Remember, you build performance management and BI solutions to satisfy a business need. Real-time BI often is suggested because it can be done technically, not because of a business need. Do you really want to spend the resources, time and budget for something the business doesn’t need?

3. Assuming that you have made the DW obsolete.

The other key assertion that I hear from operational BI advocates is that it makes the DW obsolete. My response is, “What alternate reality are you living in?!”

Nearly every enterprise, no matter how large or small, needs a significant data integration effort to create data consistency, data integrity and data quality. It doesn’t happen in real time; it takes substantial resources. It’s often asserted that 60 to 70 percent of a DW effort involves data integration. And that’s just the beginning, because data integration becomes an ever-expanding issue as more data sources, both internally and externally, are added as you enable more data for the business users. DW is essential to most enterprises to enable data consistency, ensure data integrity and quality, and store historical data for trending and analytics.

4. Assuming that operational BI should be separate from “legacy” BI.

For the last two decades, IT has treated enterprise applications and BI/DW as two separate worlds. Each group has been on its own to build up its systems and create reporting and analysis solutions.

But ERP vendors saw, before their clients did, that these worlds needed to converge. It was too costly to keep them separated, and it created dueling “single versions of the truth,” so they added DW/BI offerings to their product mix, rode the ERP wave and promoted operational BI.

Now business users can use the same BI tools to access data wherever it’s located – stored in relational databases for ERP or DW applications and emerging in unstructured data and other types of storage. They don’t need to know where their BI tools are getting the data. Their BI tool should access data from the ERP application and DW (or data mart, operational data store, cube) without their even being aware that the data is coming from varied sources.

Business users need information to do their jobs, so their BI tool should get that data regardless of where it is or what form it’s in.

Whether it’s operational BI or some other aspect of BI, making blind assumptions can trip up any project. Take a high-level view and make sure your organization isn’t making any of these assumptions with its operational BI projects.

Leave a Reply

Your email address will not be published. Required fields are marked *