Business Intelligence

Author Elizabeth Vitt, Michael Luckevich, Stacia Misner Pages 224 Disk N/A Level All Levels Published 04/17/2002 ISBN 9780735616271 ISBN-10 0-7356-1627-2 Price(USD) $39.99 To see this book's discounted price, select a reseller below.	More Information About the Book Table of Contents Sample Chapter Index Related Series About the Author Support: Book & CD Rate this book

Chapter 9: Identifying BI Opportunities

• Doing Your Homework
• Where Will Business Intelligence Be Used?
• Who Will Use the Application?
• What Information Do You Need?
• Sharing and Collecting Ideas
• Arrange a Brainstorming Session
• Define the Brainstorming Team
• Ask Business Questions
• Organize the Information Requirements
• Evaluating Alternatives
• Group Requirements into Opportunity Areas
• Grade Opportunities by Importance
• Grade Opportunities by Difficulty
• Rank Opportunities
• Summary

Chapter 9   Identifying BI Opportunities

The purpose of this chapter is to describe an easy-to-use process for brainstorming and evaluating specific BI opportunity areas in an organization. This process is divided into three primary steps:

• Doing your homework requires consideration of where business intelligence can be applied in an organization (for example, business units or functional areas), who is to benefit (for example, executives, analysts, and managers), and what types of information are needed (for example, dimensions and measures).
• Sharing and collecting ideas involves gathering people together to brainstorm and share their ideas and experiences about which business processes can benefit from business intelligence and what information can help them improve these processes.
• Evaluating alternatives uses standard criteria to assess the ideas collected during brainstorming efforts and identify those BI opportunities that offer the greatest benefits.

Doing Your Homework

• Where will the BI application be used in the organization?
• Who are the users, both within organizational units and at higher levels?
• What information is needed—specifically, what measures and dimensions?

Where Will Business Intelligence Be Used?

Whether you are investigating a functional area or business unit, the questions that need to be considered are pretty straightforward:

• What is working vs. what is broken?
• Where are you spending too much money for the apparent return?
• What processes are taking too much time?
• Where do you think you are missing opportunities?
• Where are you making bad decisions?
• Where are you making good decisions?

A review of critical functional areas and processes will quickly uncover many opportunities for consideration. Unlike traditional financial analysis, BI techniques are universally applicable to any area of business, and broken departmental processes can often be significantly improved or better managed with the faster and better information that business intelligence delivers.

The case studies in Part II of this book illustrated the value of using business intelligence to improve the core processes of various functional areas. At CompUSA the results of BI efforts were measurable store-level improvements in employee selling performance, loss prevention, and warranty data collection. The major savings and efficiencies at Audi AG were achieved in assembly line production because of better scheduling and managing of the product mix. Revenues at Disco S.A. were improved through the precise tuning of product offerings to customer segments. These examples of process improvements in functional areas are all extremely important to running the company on a day-to-day basis and making money.

Applying business intelligence to functional areas is an excellent place to begin your practice of business intelligence. The requirements for functional areas are generally easier to define, and the benefits are easier to conceptualize and measure than more aggressive BI endeavors that cross several functional areas. A functional BI application can also be relatively easier to implement because source data often comes from only one or a few OLTP systems as opposed to cross-functional or business-unit level applications that typically combine data from multiple sources. Functional area BI applications also tend to be more tactical in nature, oriented to the management of specific operations or employee behavior, rather than strategic and foundational to the basic directions of the company. For all these reasons, functional applications are typically the first baby steps of applied business intelligence.

A step up from functional or departmental BI applications are cross-functional and business-unit applications. These applications tend to be more strategic and oriented to high-level planning rather than the tuning of operational details. Consider the following examples of cross-functional and business-unit applications.

• Product and product line contribution analysis: In this application of business intelligence, variable costs are collected from all functional areas of the business, not just variable manufacturing costs, and then assigned or allocated to specific products or product lines. The potential payoffs are better understanding of alternative pricing strategies, pruning of unprofitable products or product lines, and new bundling of product offerings.
• Customer profitability analysis: In this application, revenues and costs are collected and then allocated to specific customers and customer groupings. The potential payoffs are customer (or customer group) pricing or discount structures, customer product differentiation, customer pruning, and channel economic analysis.

Because these applications are used by staff and managers from multiple departments, they are more difficult to define and obtain agreement on. Because they typically involve data from multiple functional areas (that is, multiple OLTP systems), they tend to be more difficult to build. Because the payoff is measured by better decisions rather than operational performance improvements, it is more difficult to identify the benefits when evaluating the opportunity and measure the results when the implementation is complete. Cross-functional and business-unit applications are essentially about decision making and strategic issues that are paramount to protecting and enhancing competitive advantage; they have potential for the greatest payoff and are more advanced forms of business intelligence.

While corporate strategies and goals are implemented from the top down, from the enterprise level of an organization to individual business units, business intelligence is typically implemented as a bottom-up process, with performance metrics originating from the business-unit level. Remember our discussion of key performance indicators (KPIs) in Chapter 1? Except in the most homogeneous of large corporations, enterprise-level business intelligence is usually only reporting KPIs from business units rather than drilling down through hierarchies to reach organizational details. These business unit KPIs tend to vary from unit to unit. For example, the consulting services business unit of a software manufacturer will examine KPIs such as staff utilization rates, while its retail business unit will analyze KPIs such as the number of customers and average selling price.

While these KPIs reflect the unique functions of each business unit, at an enterprise level it is important to compare performance among multiple business units. To do this, a company needs to have some top-down metrics that are driven by corporate management. These metrics are most likely standard financial indicators, such as revenue, margins, and costs.

Who Will Use the Application?

The rule of thumb is fairly simple: the lower the job classification of the target user, the more likely the need for detailed data that is operational in nature and particular to a specific functional area; the higher the job classification, the more likely the need for summarized data that supports the analysis of trends and patterns within and across functional areas.

Consider the following example of a telephone call center. Call center operators typically work with transaction-level information, including customer names and addresses, product numbers and descriptions, and so forth; this information is routinely provided by the company's OLTP system. The need may also be the same for the first-line supervisors whose roles are to help operators with a difficult or troubling problem. Now let's consider the customer support manager who oversees the operation. While this manager occasionally needs ground zero transaction detail, he or she more likely uses multidimensional and hierarchical information that describes operational performance, such as average response time to calls and customer satisfaction by shift, by department, by hour of day, and by support agent.

This example illustrates that the people who use a specific BI application are important considerations while sorting through BI opportunities and priorities within a functional area. BI systems have also made possible a new phenomenon—the easy access to operational information by analysts, senior managers, and executives outside the functional department. Traditional operations reporting up the company hierarchy have been slow, limited in scope, and paper based and therefore not of great interest or limited in usefulness to higher management. With business intelligence—fast, broad in scope, and not paper based—senior managers can quickly look into day-to-day operations, check out trends, follow up on hunches, and act quickly. Business intelligence empowers higher levels of management in new ways not previously possible—assuming company politics can be aligned, of course, which is no trivial task.

The Frank Russell Company in Chapter 5 provides an excellent example of empowering managers with valuable information. While its Picasso solution certainly improved operational performance within the various fund management groups, it also gave higher level managers broader and more timely information about overall assets under management, selling trends, and fund performance. This same benefit—more senior access to information—continued with the implementation of Einstein. For CompUSA in Chapter 6, a relatively homogeneous company in its business-unit organization, the BI system was designed to provide senior management with faster, more focused operational reporting and improved visibility at the store and district level.

As you determine who will use your BI application, try to think how your application can service the need of different users. What may first look like a moderately interesting opportunity within a functional area could prove to be very interesting and gain strong political support if the BI designs incorporate the interests of staff or senior managers higher up or outside the functional area.

What Information Do You Need?

Certainly, your mental model of how the business works is essential to establishing information requirements. Mostly, though, you need to work hard and steadily through the details and ask lots of questions. The following is a three-step guide that can help you consider the types of information you need.

Define the Measures

Most companies have a standard set of metrics and financial indicators for keeping track of the business and measuring a company's performance. Collectively these are known as measures. Historically, standard measures have been predominantly financial and single dimensional in nature. The measures for a business in today's world should focus on the critical success factors for each functional area, including additional parameters for measuring the broader strategies, goals, and objectives of the company as a whole. Ultimately, there must be a strong linkage between departmental performance indicators and top-level metrics for gauging the effectiveness of the company strategy and achieving goals and objectives.

A good way to start defining the measures for functional areas is by determining what metrics describe the performance of the base activities and the most important processes of a department. Metrics can be divided into two general categories: base measures and calculated measures. Base measures are measures that are captured at the transaction level. For example, unit sales data and amount sales data are both important base measures captured on a sales transaction. Average price, on the other hand, is not a base measure. Average price is a calculated measure that is computed by dividing the amount sales by unit sales for any aggregation of sales orders. Headcount is another example of a base measure. When amount sales is divided by headcount, the calculated measure sales per head—an important productivity metric—is created. Thinking through calculated measures that can be derived from base measures is a great method for identifying rich and easily obtained department performance indicators.

The most relevant measures are driven by the functional area and processes for which the BI application is being developed—the where consideration discussed earlier in this chapter. For example, sales-related measures (unit sales, amount sales, count of orders, backlog, and so forth) are relevant for the sales organization; production measures (assembly units, hours, inventory, and so forth) are relevant for the production department; employee measures (turnover, tenure, employee satisfaction, absenteeism, and so forth) are relevant for the human resources department. These should be obvious connections.

Less obvious is the impact of users—the who consideration discussed earlier. Here are two useful but not absolute rules of thumb:

• The lower the organizational level of a user, the greater the interest in the absolute values of a particular measure within a specific time period, especially compared to a benchmark or other measure of expected performance. For example, for a given day or week, what is the average minutes per call for customer support operators vs. a set standard? Lower levels of BI users focus mostly on short-term, correctable performance.
• The higher the organizational level of a user, especially one who is outside the functional department, the greater the focus on trends of measures over time. For example, are the average minutes per call going up or down during the last week or month? Trends are typically more important than absolutes.

Define the Dimensions

First measures; then dimensions. Once you understand the important measures for an application, you can then define the dimensions in which the measures can be described. (Recall from Chapter 2 that dimensions are defined as category-consistent views that provide context to measures.)

To understand how dimensions interact with measures, let's walk through a simple example: assume you want to analyze gross margins by product by region by quarter for the year 2001. The key word is by; it indicates a dimension reference. The breakdown of this analysis into dimensions and measures is as follows:

• The base measures are amount sales, unit sales, and unit cost. The calculated measures are cost (unit sales multiplied by unit cost) and gross margin (amount sales minus cost).
• The dimensions are time (quarters 1 through 4), products (A through C), and regions (1 through 3).

This example is simple and illustrates several precepts for defining the information that you need for a BI application:

• Decide on the measures and how they interrelate and are calculated before defining dimensions.
• Consider how you want to analyze measures over time. In almost all BI applications, you will find a time dimension. Time parameters are driven by the time horizon in which the BI analysis needs to be performed.
• While specifying dimensions, start thinking generally about where the data will come from or recognize early on the need to construct new ones from scratch if the dimension need is important enough.
• Instead of thinking of each of dimension singly, consider how multiple dimensions can describe a particular measure. Recall from the fruit seller example in Chapter 2 that analysis across multiple dimensions simultaneously makes the data useful for analysis.

Define the Level of Detail

For each combination of dimensions and measures, decide how much detail is desired; that is, what is the lowest level of information for each dimension that must be available across different user groups? Defining the lowest level is an important decision because all summarized data can be easily derived from the lowest level of detail.

Business requirements should drive the decisions about level of detail, yet be tempered by common sense. When you consider how much detail is required, consider the relative implications of summarized vs. detailed data. Summarized or high-level data tends to minimize the number of data points that you have to analyze, but it does not allow you to see trends at lower levels of detail. On the other hand, less summarized or low-level data means that you will need to analyze more data points to identify trends.

Consider the following example: a point-of-sale system contains up-to-the-minute sales information by customer, store, and product. At a rate of 10 sales per minute for 10 hours per day for 365 days a year, nearly 2.2 million data points are collected. If you view sales data summarized by month, you will not be able to see weekly, daily, and hourly trends. On the other hand, if you analyze data at its lowest level of detail—minute-by-minute—you will not be able to identify meaningful patterns. Rather, in this case, meaningful patterns begin to appear at the hour level.

Realistically, you will need some combination of both summarized and detailed views of the data to meet the analysis needs of all business users. The key is to strike a balance. The technique to finding this balance is deciding on a reasonable level of detail for the lowest level of data required across all users and then using the BI system to create hierarchical summaries from the detail. For detailed data, you also have the option to apply more advanced analytical techniques, for example, data mining, that thrive on crunching through large amounts of detailed data to find trends that are invisible to the human eye. After deciding on the level of detail, your IT organization can help evaluate the feasibility of accessing the data.

Sharing and Collecting Ideas

1. Arrange a brainstorming session.
2. Define the brainstorming team.
3. Ask business questions.
4. Identify information requirements.
5. Organize information requirements.

Arrange a Brainstorming Session

To facilitate each brainstorming session, we recommend using large sticky notes to document the brainstorming session. Sticky notes provide a quick, visual snapshot of group discussions and can be placed on the wall of an office or conference room to remind participants of what was said and document key information for later write-up. Because sticky notes are easy to move around, they also help participants identify and keep track of relationships among various information requirements.

Define the Brainstorming Team

Brainstorming sessions should definitely be business driven. Therefore, involving the IT organization at this early stage may not be necessary. An IT representative can offer perspective, but do not discourage free-form discussion by worrying too soon about technical considerations, such as the availability of certain data or how and when the data extraction process might work. The IT department should be involved at later stages once hard BI design questions are being proposed.

Brainstorming works best when one person skilled at the process facilitates the session, including writing ideas on the sticky notes.

Ask Business Questions

• Which product lines are generating the most margin in Florida?
• Why do we get more support calls from the West Coast than other regions?
• Who are the top sales representatives in the United States?
• When was the last time we saw this surprising pattern in product X sales?
• Why are sales so low in France this month?

"Why" questions are often the most interesting. They typically translate into many "what?" subquestions. For example, the question, "Why are sales so low in France?" could lead to the following questions:

• What is the forecast for sales in France?
• What were the sales in France last month? In the same month a year ago?
• What products are the biggest sellers in France?

The phrasing of questions provides important clues about measures and dimensions. To document the clues, do the following for each of the most important questions:

1. Write the question at the top of a sticky note. Leave room on the sticky note for information that will come later. Use only one sticky note per question.
2. Number the sticky notes sequentially and place them on the office or conference room wall. Post questions from the same functional area adjacent to each other.
3. If the brainstorming session is for cross-functional opportunities, for example, customer profitability analysis, use different-colored sticky notes for each department to capture its key questions or tag the sticky notes with the department name.

Figure 9-1 presents what a set of sticky notes might look like with questions posted.

Click to view graphic

Figure 9-1. Brainstorming questions on sticky notes

Identify Information Requirements

Once a meaningful sample of questions is documented, these can be translated into specifications for measures and dimensions—the objective of the exercise. The brainstorming group must think through what information is needed to answer the questions.

You can identify information requirements in any of three ways: by discussing the requirements within the group, by looking at current reports, or by using a sticky note or whiteboard to sketch sample reports with rows and headers that identify the information. Whatever the method, the objective is to state the measure or measures underlying each question and then identify the relevant dimensions for answering the question. Write the measures under the question on the sticky note and then write the dimensions below, connecting each with the word by. In addition, for each dimension add in parentheses the lowest level of detail likely required for answering the questions within the dimension area; that is, estimate the likely lowest level for drilling down.

Figure 9-2 presents the three questions on sticky notes that we asked earlier with a mapping of measures, dimensions, and lowest level of detail just described. Note that we have added additional measures that are implied but not obviously stated in the question. For example, for the product line in Florida question (#1), to analyze margin you need revenue and cost information. For the top sales representative question (#3), the measure was not explicitly stated in the question; therefore, several measures related to sales, orders, and commissions are suggested. Note also that all questions by default get a time dimension designation that the group decides on. The lowest level time horizon reflects the level at which meaningful trends occur.

Notice that several dimensions are included on the support call sticky note question (#2). The geography dimension is obvious because geography is referenced in the question. After discussion, however, the brainstorming group added customer and product, noting that this information was captured at the beginning of each call and that customer and product types were very likely drivers of call pattern anomalies such as the one asked in the question.

Click to view graphic

Figure 9-2. Brainstorming questions with supporting measures and dimensions

Organize the Information Requirements

Table 9-1 is a sample BI blueprint that organizes the information from the example sticky notes presented in Figure 9-2.

Table 9-1. A sample BI blueprint

Dimensions

Note #	Measure	Product	Geography	Customer	Call Class	Sales Rep	Time
1	unit sales	product #	region	NA	NA	NA	month
1	amount sales	product #	region	NA	NA	NA	month
1	cost	product #	region	NA	NA	NA	month
1	margin	product #	region	NA	NA	NA	month
2	# calls	product #	district	cust ID	level 1	NA	day
2	call length	product #	district	cust ID	level 1	NA	day
3	unit sales	product #	district	cust ID	NA	rep ID	week
3	amount sales	product #	district	cust ID	NA	rep ID	week
3	unit orders	product #	district	cust ID	NA	rep ID	week
3	amount orders	product #	district	cust ID	NA	rep ID	week
3	commission	product #	district	cust ID	NA	rep ID	week

At this point the brainstorming session (or sessions where multiple departments and complex processes are being reviewed simultaneously) is completed. The group has identified through a process of asking questions the most important measures and their related dimensions for answering the most significant questions agreed on by the group.

Last Updated: April 10, 2002

Top of Page