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:
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:
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:
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:
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:
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.
Recent articles by Steve Williams
Copyright 2004 — 2018. Powell Media, LLC. All rights reserved.
BeyeNETWORK™ is a trademark of Powell Media, LLC