Perhaps the most difficult part of any Six Sigma program for business intelligence involves the initial definitions and metrics that provide the foundation. A Six Sigma BI initiative is focused on the customer and the customer requirements; a Six Sigma level of excellence in the product; and a rigorous, data-driven Six Sigma process to achieve quality and efficiency goals. There are three considerations:

What exactly is the business intelligence product?
How do we define and measure product quality?
Who are the customers?

Describing and defining the business intelligence product, and identifying the multiple customers for the business intelligence product, are the crucial bookends to determining the elusive business intelligence quality.

Defining the Business Intelligence Product

Identifying the business intelligence product, in all its myriad forms, can be a difficult process, especially with the growing number of stakeholders and uses. The term pervasive business intelligence has entered the industry terminology. There are myriad forms and varieties of business intelligence product. However, the core BI product is comprised of data, information and intelligence.

Data The raw material for the business intelligence product is data. Data are the facts and pieces of information collected by the organization from transactions with customers, other operations, research and knowledge arenas. This includes both structured and unstructured data.

Information The data is cleansed, integrated and translated into the intermediate product, which is business information.

Intelligence The intelligence end product is a result of the integration of the information and a person or system that has the expertise to use the information to make decisions related to management and/or operations of the business.

Defining and Measuring Business Intelligence Quality

Defining business intelligence product quality requires identifying the characteristics which the customer perceives as essential to product quality. In addition, we need to define the metrics that can be used to measure those critical to quality characteristics. (For example, query response time may be measured as seconds from key entry to reply.) BI quality means quality data, delivered in an easy-to-understand form to the right people and/or systems, at the right time. Effective management of business intelligence requires that we translate that general description for quality into specific characteristics and metrics that can be used to monitor and improve the product.

The customer most often considers quality of business intelligence to be linked to:

Functional requirements. How well does the BI product meet the defined (or not defined) functional requirements?

Quality of the information. Is it correct and to be trusted? (Note: the Master Data Management initiative, which is receiving extensive attention and resources across the industry, is focused on improving the quality of enterprise data. An MDM initiative can be an excellent first step in the creation of a lean Six Sigma BI program.)

Access and delivery of the information. Is it timely and in a format that is easy to understand and use?

In addition, the enterprise customer should be asking: Do the people (and, to a more limited extent, the systems) who are a critical component of the final business intelligence product have the attitude, the expertise and knowledge, as well as the freedom and empowerment to use the information well?

Who Are the Customers: Hearing the Voices

The success of Six Sigma in business has been based on efficiently producing a product that meets or exceeds the needs of the customer. Current best practices for business intelligence also focus on meeting customer requirements. For a Six Sigma BI program, however, we need to extend that customer focus to include defining and measuring the quality of the business intelligence product. The business intelligence customers, unlike those in the general business arena, are primarily internal to the organization. The first three groups of customers, the end user, the customer's customer, and the special needs group, are relatively easy to identify and to gather requirements from.

End users are the people and systems within the organization who create, use or in some way interface with business intelligence in doing their jobs. Gathering their requirements involves hearing them directly after identification. The customer's customers — or the customers of the organization — are the people external to the organization who use the systems and data that have been made available to them on a limited basis. Gathering requirements from these customers involves first gathering requirements from the internal customers who are making the data and/or systems available to the customer's customers, and then talking directly to them through focus groups and sampling. The special needs group are the end users who have important data and/or system needs, such as data mining or forecasting, which are not met in the course of satisfying the general needs of the remainder of the organization's users. Once they are identified, their requirements are gathered by hearing them directly.

The organization customer, in contrast to the first three, is a vague and rather hazy concept. The requirements of the organization refer most often to strategic and tactical plans and goals. For example, in gathering requirements for a support and maintenance engineering group for a utility, our development team quickly identified key members of the two groups of customers who would directly interface with the new business intelligence products. A third set of customers was revealed as we explored more functionality and expanded the vision for using the information. We found that a critical requirement was related to speedy access to extensive information on the correlation and communications of the maintenance activities with the supplies and inventory data. We had anticipated that having the specific timing data for the release and relief of inventory was essential. However, what we did not anticipate (and should have) was the critical nature and time restraints for geographic and hub-based information about the availability of inventories and resources.

Of course, that became painfully obvious after we had talked to several engineers and leads (who had lost valuable time) and some of the customer service reps (who had fielded the angry customer calls). This led us to a more detailed exploration of the needs of the organization as a whole. Finding and interviewing the right management and staff turned out to be a political nightmare. After several unproductive interviews and some brainstorming sessions with the rest of the team, including the project sponsor, we decided to attempt the creation of a virtual organization team to act as a voice for the organization.

It took some initial coercion and rather complicated political maneuvering. The team was created finally and included a senior analyst who worked in finance and budgets, an assistant to the enterprise architect, director-level reps from human resources and communications, and an IT manager who was responsible for some of the resource planning. That may not be the best make-up for most organizations, but it seemed to work in this case. It was rewarding to hear later that they turned that virtual organization team into a major contributor, with multiple roles, including strategic and tactical planning as well as management brainstorming. We had actually groped our way into a solution that was valuable to the requirements gathering for any BI project, and also proved to be successful for the organization in other ways.