<-- Back to full color view

Business Intelligence Business Requirements and the BI Portfolio How to Get it Right

Originally published February 19, 2008

More and more companies are learning the hard way that business intelligence (BI) business requirements are a different breed of cat. After paying hundreds of thousands of dollars in consulting fees for generic BI requirements, or after spending months and months generating traditional report requirements and functional specifications, major companies in many different industries have discovered that these approaches suffer from three primary deficiencies:

  1. They don’t provide the basis for a compelling business case that business leaders buy into – one that clearly articulates how business intelligence will be used within specific business processes to improve business performance.

  2. They don’t provide enough specificity with respect to the kinds of business intelligence applications that are needed. Business intelligence is a broad term that encompasses a wide range of different kinds of applications, from basic reporting and OLAP to sophisticated analytics.

  3. They don’t provide enough specificity to guide development of the business intelligence databases and applications that deliver the BI or to guide the business process changes that deliver the bang for the buck to the business.

Ultimately, the use of inappropriate and expensive BI business requirements methods leads to failed business intelligence investments and discrediting of business intelligence as a profit improvement tool, just at the time when more sophisticated competitors using business-driven requirements methods are reaping the strategic and financial benefits of business intelligence done right.

To avoid dissatisfied business users and unhappy senior executives, it is critical to understand what it means to get BI business requirements right, to use true BI business requirements to drive definition and prioritization of the BI portfolio as the foundation for a compelling business case, and to use BI business requirements to drive development of the BI databases, BI applications and enhanced business processes that create business value. To set the stage for discussing what it means to get BI business requirements right, we start with examples from our consulting experience that illustrate incomplete or insufficient BI requirements.

The Weakness of Generic BI Business Requirements

We often run into situations where major companies ask us to help develop a BI strategy, which includes a business case, a BI portfolio and opportunity map, and a BI requirements document. In many cases, the business intelligence team has already taken a stab at a business case and/or a requirements document, which typically contain statements such as:

  • “…produce enhanced organizational capabilities to manage data and information as organizational assets.”

  • “…provide a single version of the truth.”

  • “…enable consistent and reliable access to accurate corporate-wide data.”

  • “…provide more sophisticated reporting and analysis, faster turnaround, improved accessibility and enhanced quality.”

  • “…a single touch point where detailed financial transaction information can be filtered on user-entered selection criteria, viewed online, downloaded in standard file formats and used to generate real time reports.”

These examples of generic BI business requirements illustrate a key point. They are fine as far as they go, but the business executives and managers we deal with in major companies don’t find these kinds of requirements statements and value propositions compelling. In fact, it is just the opposite. They see no reason to get excited about business intelligence absent a more compelling business case and more concrete BI requirements that relate to the things they do, like conduct marketing campaigns, manufacture and ship products, buy raw materials, provide services to customers, and so forth. As a result, they underfund business intelligence, which limits its business impact and thereby justifies their skepticism.

Why BI Functional Requirements (Specifications) Are Not Enough

In the early days of the computer industry, it was critical to generate a functional requirements document because much of what computers did had to be custom-programmed. If you wanted the monitor to display a table full of business data, you had to capture that as a functional requirement – often expressed as a statement like “the system shall be capable of accepting data inputs and displaying the data in user-defined tabular formats.” In the modern BI world, we run across functional requirements such as:

  • The system shall provide the ability to drill down, drill across, and slice-and-dice.

  • The system shall provide the ability to specify organizational hierarchies and display performance scorecards for each organizational unit.

  • The system shall enable role-based access to information.

  • The system shall provide capabilities to route alerts to business users according to user-defined parameters.

  • The system shall enable integration of data from multiple disparate sources.

Unlike the world of custom systems development, BI functional requirements like those listed above are standard features of commercially available BI tools. While it is important to know what your company needs BI tools to do, BI functional requirements typically say little about the kinds of business information, analytical techniques and decision support that are required or the specific core business processes that the company seeks to improve via business intelligence. And yet we are approached on a regular basis when we teach our BI Requirements course at TDWI conferences by companies whose BI requirements approach is centered on capturing BI functional requirements like those illustrated above. While these are necessary to a degree, they are far from sufficient for creating business intelligence applications that satisfy business users’ needs.

Data Element Listings: Give Us Everything We Might Need and We’ll Figure Out What to Do with It 

A third common approach we see is the data element listing as a proxy for BI business requirements. The predominant logic here is that the company is not sure about how it wants to use business intelligence, so it seeks to prepare for any eventuality by creating a list of all the data elements for all the major subjects of the business that it might need to know something about. A typical data element listing might look like this:

  • customer first name

  • customer last name

  • customer account number

  • customer street address

  • customer city

  • customer state

  • customer ZIP code

  • customer phone number

While such data element listings can be helpful, and while we need to understand what business information is needed as a core expression of BI business requirements, the listing alone says nothing about how the information will be used or how it might need to be integrated with information about products, manufacturing locations, store locations, organizational units and other organizational information. Further, BI capabilities built on top of large stores of unintegrated subject data elements run the risk of spawning inconsistent business intelligence depending on how development teams and/or power users choose to integrate data for their specific purposes. In other words, simple data element listings don’t provide enough specificity to guide development of the BI databases and applications that deliver business intelligence or to guide the business process changes that deliver the bang for the buck to the business.

How to Get BI Right: Business-Driven BI Requirements

So far we have illustrated common approaches to BI business requirements and discussed how they are somewhat useful, but certainly not sufficient. In contrast, a well-structured set of BI business requirements:

  1. Establishes a clear linkage between business strategies, the core business processes via which the strategies are executed, and BI-driven business improvement opportunities, which is the basis for a BI business case that is compelling to the business stakeholders;

  2. Identifies and clearly describes what business information, analytical tools and techniques, and decision support is required by the business to realize BI-driven improvement opportunities to management processes, customer processes and/or operational processes;

  3. Provides the essential input to the process of defining specific BI projects and prioritizing those projects based on key criteria such as business impact and time-to-market;

  4. Provides the means of aligning business intelligence, business process improvement and balanced scorecard initiatives;

  5. Drives key data architecture decisions;

  6. Provides the basis for end-to-end traceability between BI requirements approved by business users and the delivered data stores and BI applications; and

  7. Provides a key baseline against which the performance of the BI initiative can be measured.

More and more companies have seen the shortcomings of traditional requirements approaches for BI purposes, and they can easily relate to the above characteristics of business-driven BI requirements. Therefore, if creating a well-structured set of BI business requirements is the goal, the next challenge is how to get it right. While much more goes into that than can be addressed in a short article, we can provide a high-level overview to get you started. The first step is BI opportunity analysis, as shown in Figure 1.

 

The goal of BI opportunity analysis is to identify – in business terms and for business executives, managers and analysts – the main ways that business intelligence can be used to improve business results. The outcome of the analysis is documented in a qualitative BI business case that describes potential BI-driven improvement opportunities in three broad areas: management processes, customer processes and operating processes. The BI opportunity analysis and the resulting business case are key inputs to the next step, as shown in Figure 2.

 

The business-driven process of defining the BI portfolio explicitly links business intelligence and one or more targeted business processes. In the center of Figure 2, we see that when we talk about defining BI-driven business improvement opportunities (BIOs), we get very specific about the business intelligence and how it will be used to improve business results. This approach overcomes the weaknesses of traditional approaches to BI requirements and establishes the basis for the last step in the process of developing a well-structured set of BI requirements, shown in Figure 3.

 

The last step in getting BI business requirements right is getting more specific about the requirements for business information, analytical tools and applications, and decision support – all in relation to previously defined BI-driven business improvement opportunities. For example, a management process such as performance management may have a requirement for specific business information in the form of metrics and key performance indicators, perhaps in a scorecard format. A customer process such as cross-selling may have a requirement for an analytical application that uses a data mining technique like collaborative filtering to identify product recommendations for customers at a company web commerce site. An operational process such as manufacturing may have a requirement for decision support in the form of alerts to executives when the cycle time for three consecutive orders to a major customer is outside of established targets. Armed with a specific understanding of the BI requirements for each specific BIO, we are then in a position to develop a comprehensive BI requirements document that can drive development of the BI databases, BI applications and enhanced business processes that create business value.

Getting BI Business Requirements Right Drives Business and Professional Success

Short of a major faux pas with a key customer, committing a social gaffe in the executive suite or consistently missing performance targets, nothing will derail a promising business or IT career faster than being associated with a high profile initiative that fails. And business intelligence is increasingly high profile because of the costs of doing it right and the strategic and financial consequences of doing it wrong. Most professionals we work with want to be part of successful initiatives because such initiatives help the company, provide a sense of professional accomplishment and satisfaction, and help careers. In the business intelligence world, the odds of success go way up if we get BI business requirements right. While there are a host of other issues that go into business intelligence success, they don’t matter much at all if we build the wrong things or the things we build aren’t used. A well-structured set of business-driven business intelligence requirements helps avoid those scenarios and sets the stage for delivering successful BI projects.

SOURCE: Business Intelligence Business Requirements and the BI Portfolio

  • Steve WilliamsSteve Williams
    Steve Williams is the President of DecisionPath Consulting. With more than 30 years of experience, he is a leading strategy consultant in the business intelligence (BI), analytics, and performance management fields. His clients have included Northwestern Mutual Life Insurance Company, Pinnacle Foods Group, Principal Financial Group, McCormick & Company, Toronto Hydro Electric System, and the U.S. Treasury and the U.S. Social Security Administration. Steve is a frequent speaker on BI, analytics, performance management, and business strategy at a number of industry events. Steve holds an MBA from the Darden School at the University of Virginia and a BS in Business Administration from the University of Maryland.

Recent articles by Steve Williams

 

Comments

Want to post a comment? Login or become a member today!

Be the first to comment!

 

Copyright 2004 — 2018. Powell Media, LLC. All rights reserved.
BeyeNETWORK™ is a trademark of Powell Media, LLC