Design Tip #151 BI Components for Business Value
January 8, 2013
© Kimball Group. All rights reserved.
Each data warehouse/business intelligence (DW/BI) lifecycle iteration delivers a coherent, incremental data set that provides value to the organization and can be implemented in a relatively short time frame. All too often, DW/BI teams lose their business focus during the project and concentrate on selecting a BI tool rather than providing full end-to-end solutions. Every lifecycle iteration should consider delivering at least three BI layer components: standard reports, self-service access, and targeted BI applications. Obviously, tools are important, but business needs come first. Let’s examine the three required BI components.
The DW/BI system should become the source for the organization’s preferred business process measures. To accomplish this, each lifecycle pass should include the creation of standard reports that provide business process monitoring capabilities. For example, the customer service call process should have standard reports with basic customer service metrics, such as the number of new calls by day, week, or month over a significant time period.
The metrics on these standard reports must be accurate. The BI team needs to work with representatives from the business to test and validate them. This validation includes documenting any differences between the DW/BI numbers and legacy versions of similar reports. The BI team will refer to this documentation repeatedly to help business users understand that the new DW/BI system reports are both correct and improved because they usually fix data quality and business rule problems in the old reports.
These standard reports are critical to a broad category of users who monitor the business at a relatively high level. They need simple, pre-defined report structures, perhaps with the ability to change parameters or drill down a level or two. They often want the same report emailed to them and viewable from a mobile device.
Beyond the foundation of standard reporting, the DW/BI team must also provide direct access to the data. This BI component used to be called ad hoc query tools, but the category has split over the last few years into BI tools and visualization tools with significant overlap in functionality.
BI tools generally provide access through a semantic model that captures the dimensional definitions and relationships to help translate the user selections into the underlying SQL or MDX language. This access is usually drag-and-drop at the column level and the output layout and formatting is determined by the user. The best BI tools allow drilling down, drilling across, setting constraints, browsing attribute values, and choosing various tabular and graphical output formats. Often these ad hoc explorations evolve into additional standard reports.
Visualization tools also use a model-based intermediate layer, but they tend to guide and control the look of the resulting reports and graphs. Visualization tools attempt to provide instant feedback to the analytic design process by making assumptions about the appropriate graphical output format. The graphing or visualization capabilities of these tools have moved beyond basic line and bar charts to include scatter charts, small multiples, animated time series, network representations, spatial maps, heatmaps, and treemaps.
Note that self-service access does not mean access for everyone. These tools are appropriate for the core DW/BI system users. Known as power users, super users, or business analysts, they understand the data, the tools, and the business well enough to successfully serve themselves; self-service isn’t viable without this prerequisite knowledge. There are a relatively small percentage of these core users in any given organization.
Targeted BI Applications
Above all else, the DW/BI system must deliver measurable value to the organization with each lifecycle iteration. This value should be tied to a specific analytic opportunity that was identified during the gathering of business requirements and is part of the justification for loading the given dataset. This could be standard reports if the information they contain has not been readily available, but more often, it is a specific set of analytic capabilities.
For example, a friend who works in an investment related firm found his organization needed to understand how their products were being sold through various channels. The problem was their products were sold through third parties and they did not have this sales data. He found a source that collected certain descriptions about the sale and applied a complex set of data cleansing steps and business rules that extracted a channel dimension from the descriptions. The business folks were then able to determine where to focus their sales resources, and negotiate more effective agreements and pricing based on this channel information.
The tools for delivering these specific capabilities could be standard reports, or self-service tools, or dashboards, or predictive analytics, or even a .Net or Java application. The BI team should be prepared to do whatever it takes to deliver the value all the way to the user.
It’s Harder than You Expect
Every DW/BI team must accept the responsibility of delivering end-to-end value to the organization. Once you understand you are serving multiple user communities with different analytic requirements and different levels of analytic skill and maturity, you realize there is no such thing as a single BI tool that solves all the problems; that is, there is no best BI tool. But there is a single architecture that should serve as the foundation for all the BI components. Your most direct path to success is to build a solid, enterprise-conformed, atomic level dimensional data warehouse which becomes the platform for all forms of BI. This platform delivers the greatest flexibility and will perform well with almost all BI tools. Then focus your BI resources on delivering business value using the appropriate BI components for the job.