Business people should be eager to dive in and explore the data that represents their business. After all, who knows better what information is needed? Unfortunately, few business people seem to agree. Consider yourself lucky if 10 percent of your users actually build their own reports from scratch.

As for the other 90 percent of the user community, it's up to every data warehouse (DW)/business intelligence (BI) team to provide an easier way to access the data. Here's a process for designing a starter set of BI application standard reports.

What Are BI Applications?

There's no commonly accepted definition of BI or a BI application, so we're offering our own: BI applications are the delivery vehicles of business intelligence — the reports and analyses that provide usable information to the business. BI applications include a broad spectrum of reports and analyses, ranging from simple fixed-format reports to sophisticated analytics with complex embedded algorithms and domain expertise. It helps to divide this spectrum based on the level of sophistication. We call the simple side standard reports and the complex side analytic applications.

It's possible to build BI applications without the benefit of a data warehouse, but this rarely happens. A well-built data warehouse adds value through the business dimensional model and the ETL process, so it makes no sense to replicate this effort to build a standalone BI application. Most successful BI applications are an integral part of the user-facing end of the data warehouse.

Standard reports usually have a fixed format, are parameter-driven and, in their simplest form, are prerun. Standard reports provide a core set of information about what's going on in a particular business area — sounds dull, but these reports are the backbone of BI applications. Examples from different industries include YTD Sales vs. Forecast by Sales Rep, Monthly Churn Rate by Service Plan and Direct Mail Response Rates by Promotion by Product.

The standard reporting system consists of several technology components. You must have a tool for the report designer — either someone in IT or a skilled business user — to define reports. You need management services for report storage, execution and security. Finally, your reporting system should have a navigation portal that helps users find the report they want.

Analytic applications are more complex than standard reports. They center on a specific business process and encapsulate domain expertise about how to analyze and interpret that process. They may include complex algorithms or data-mining models. Some analytic applications give users the advanced capability to feed changes back into the transaction systems based on insights gained using the application.

Others are sold as black-box or hosted systems. Common examples of analytic applications include budgeting and forecasting systems, promotion-effectiveness and category-management applications, fraud detection and Web path analysis.

Build vs. Buy

Most organizations build their own standard report set, using a purchased reporting tool to design and publish the reports on the corporate intranet — usually in an accompanying reporting portal. There are many popular tools that make it easy to define and publish reports and to customize the bundled portal.

The build versus buy decision for analytic applications is more complex. The market for packaged applications is growing both in quantity and quality, and it's increasingly common for organizations to buy them. However, almost every implementation of a packaged analytic application requires significantly more customization than required for a prebuilt transaction system. Evaluate a packaged application for its flexibility and ease of customization. Is it based on a well-designed dimensional model? If so, it should be easy to map your data model to that of the application. If the data model is tightly tied to the application itself, implementation may require significant effort, even if the application is sourced from your dimensional data warehouse.

Some organizations still build custom analytic applications, using a combination of standard tools and custom code to capture and apply best-practice business rules. Organizations with particular expertise in analyzing their business processes or that have unusual systems and business models are more likely to build their own applications.

Designing the Reporting System

You can't build reports until you near the deployment of the DW/BI project, but you can and should start the design process much earlier. As soon as you've finished interviewing business users about their information and analytic requirements, you can create your report specifications — the longer you wait, the harder it will be to remember the details. This step includes the following tasks:

Create the target report list. It's important to deliver value to business users as quickly as possible; don't wait for hundreds of reports to be developed and tested before letting users into the system. Identify 10 to 15 reports you'll create for the first round.

The best way to create the target report list is to start with a full list of candidate reports by reviewing the business requirements for every information request, desire or fantasy that anyone expressed. Give each report a name and description, and on a scale of one to 10, rate its business value and the effort it will take to build.

Once you have a complete list of candidates, prioritize them, group related reports and review the priorities with a small group of competent, interested business users. Negotiate a cutoff point for the initial delivery at 10 to 15 reports. Remind users that many of the lower-priority reports can be handed off to the departmental experts who were most interested in them.

Create the standard template. Think of the reporting system as a publication and yourself as the editor. To communicate effectively, you need consistent format and content standards. Create a template identifying the standard elements that will appear on every report (see mock-up, below). The basics include: