Chapter One
Defining Business Requirements Building the foundation
Business requirements are the bedrock of the DW/BI system. Business requirements guide the development team in making the biggest strategic choices, such as prioritizing subject areas for implementation, and in making the smallest tactical design decisions, such as how to present key performance indicators on the users' screens. In this chapter, we cover the process of gathering business requirements and converting them into a DW/BI system strategy. We describe the process of interviewing business and IT representatives, categorizing their requirements into analytic themes, converting those themes into incremental projects, and working with senior management to prioritize those projects. We also include a partial set of example requirements for the Adventure Works Cycles business.
As Figure 1.1 illustrates, the Business Requirements Definition is the foundation of the Lifecycle methodology. Business requirements and their associated business value give you the guidance you need to make decisions in all three downstream tracks. As you'll see, they influence the project scope and plan as well.
This chapter is primarily about resisting temptation. Gathering business requirements is often outside a technical person's comfort zone. The overall success of the project is largely determined by your understanding of the business requirements and your relationships with the business people. Resist the temptation to just start loading data.
In this chapter you learn the following:
* The importance of understanding business requirements and securing solid business sponsorship * How to define enterprise-level business requirements, including the interview process, developing analytic themes, linking themes to business processes, developing the data warehouse bus matrix, and prioritizing business processes with senior management * How to plan the initial business process dimensional model implementation and gather project-level business requirements * What a typical requirements summary document looks like and how it links to analytic themes and business process implementations
The Most Important Determinant of Long-Term Success
There is one common factor in successful business intelligence projects: delivering business value. Your DW/BI team must embrace the goal of enhancing business value as its primary purpose. This seems like an obvious statement, and we almost always get a chorus of agreements when we state this principle to the DW/BI teams with which we work. But most DW/BI folks are technologists at heart. We like the certainty of computers and programming. It works or it doesn't; if it doesn't, we can debug it.
You can't deliver business value unless you work closely with business people. You need to understand their language and learn to see the world from their point of view. You'll be working in a non-technical, highly ambiguous, politically sensitive environment. Are you feeling queasy yet? Many of us went into the computer trade specifically to avoid such discomfort. But this unsettled environment is what the DW/BI system is all about. You must develop the business knowledge and people skills right along with your technical skills in order to meet the needs of your business users. We realize the entire team will not become smooth-talking MBAs. However, someone on the team must have strong business and communications skills, and everyone will be more effective if they work to develop some of these skills.
So, while many DW/BI teams and consultants pay lip service to business value, the reality of their day-to-day behavior is that technology rules. Do not let this happen to you. Technology is important; business value is mandatory.
As you read this book, you'll encounter recommendations that may seem unnecessarily complicated or just plain unnecessary. Every time you're tempted to dismiss the authors as overly fond of their design methodology, or just overzealous, consider whether your reactions are driven by your technical convenience, or by the business users' needs. Never lose sight of the business.
Uncovering Business Value
If you're going to be driven by business value, you need to go out and identify, understand, and prioritize the needs of the business. This is easier said than done if your focus has historically been on technology. Fortunately, the Business Dimensional Lifecycle provides the tools to work through an entire development iteration of a data warehouse, beginning with business requirements.
Where do you start with your business intelligence system? What is the first step? The consultant in us immediately blurts out the standard consulting answer: "It depends." In fact, it does depend on a host of factors, such as how your organization works, what you already know about the business, who is involved in the project at this point, what kinds of DW/BI efforts came before, and many other factors. Let's talk about the most common scenario first, and then we'll address a few exceptions.
More often than not, the DW/BI system starts as a project hosted by the Information Technology (IT) organization. There is generally some level of business interest; in fact, the business folks may be the source of inspiration. But they are pushing for information in a form they can use, not specifically for a DW/BI system (unless, of course, they had access to a well-built data warehouse in their last job and they really miss it).
Most often, the IT-driven DW/BI project gets started because the CIO decides the company needs a data warehouse, so people and resources are assigned to build one. This is a dangerous situation. Please refer to the first point in this chapter: Focusing on business value is the most important determinant of long-term success. The problem with the IT-driven DW/BI system is that it almost always centers on technology. The team has been assigned the task of building a "warehouse," so that's exactly what they do. They get some hardware and some software and start extracting data.
We know some of you are thinking, "Oops, I already bought the ETL server and the user reporting tools." That's probably okay, but put those tools aside for the moment. Step away from the keyboard. If you get sucked into the technology, you're missing the whole point. You can build a technically great DW/BI system that provides very little business value. As a result, your project will fail. You have to start with business value, and identifying business value involves several major steps:
Recruiting strong business sponsorship Defining enterprise-level business requirements Prioritizing business requirements Planning the project Defining project-level business requirements
We'll run through each of these steps in the following sections.
Obtaining Sponsorship
Developing solid business sponsorship is the best place to start the DW/BI project. Your business sponsors (it is generally good to have more than one) will take a lead role in determining the purpose, content, and priorities of the DW/BI system. You will call on them to secure resources and to evangelize the DW/BI system to the rest of the organization. This includes activities such as arranging for a planning meeting with senior staff, or speaking to a room full of business users at the project kick-off. You need to find at least one person in the organization who scores well in each of the following areas:
Visionary: Someone who has a sense for the value and potential of information and some clear, specific ideas on how to apply it. Resourceful: Someone who is able to obtain the necessary resources and facilitate the organizational change the data warehouse will bring about. Reasonable: Someone who can temper his or her enthusiasm with the understanding that it takes time and resources to build a major information system.
Often, if you've been with your company for a while, you already know who these people are. In this case, your task is to recruit them onto the project. However, if you're new to the company, or you have not been out of the IT group much, you'll need to go out and find your business sponsors. In either case, the best way to find and recruit these people is by conducting an enterprise business requirements gathering project. It's worth the effort. Good business sponsorship can provide the resources and support you need to deliver real business value.
Defining Enterprise-Level Business Requirements
From a technical point of view, one long-term goal of the DW/BI team is to build an enterprise information infrastructure. Clearly, you can't do this unless you understand business requirements from an enterprise level. It is especially important in larger organizations to begin with this broad understanding because it is rare for the DW/BI team to have such an enterprise-level perspective. It's also particularly important for organizations that are just starting their first DW/BI system (or starting over) because getting the enterprise perspective built into the initial project helps you avoid painful and costly redesign down the road.
In these cases, the high-level version of the Lifecycle presented in Figure 1.1 doesn't give you quite enough information about how best to get started. In particular, the little arrow that goes both ways between Project Planning and Business Requirements Definition actually breaks down into several sub-activities, as shown in Figure 1.2.
In this subsection of the Lifecycle, defining the business requirements happens in several distinct steps. The rest of this section describes each of these steps in more detail.
NOTE We use the term "business process" throughout this section but do not describe it in detail for another few pages, when it makes more sense in the context of the requirements definition process. For now, think of it as a subject area or data source.
Establishing Initial Project Scope
Begin with the creation of an initial project scope based on the team's upfront knowledge of the organization's business needs and its experience in developing DW/BI systems, along with input from the business participants. The scope usually covers only the enterprise-level requirements definition and requirements prioritization steps in detail, leaving the initial project implementation plan for later when you have a much better idea of what the project needs to accomplish from a business perspective. The initial scope usually involves only user interviews, interview write-ups, a few meetings, and the creation of the final requirements document. It usually takes three to six weeks (or more) depending on how many interviews you do.
REFERENCE
Additional information about project planning and management in the context of the Business Dimensional Lifecycle can be found in The Data Warehouse Lifecycle Toolkit (Wiley, 1998), Chapter 3.
Gathering and Documenting Enterprise-Level Business Requirements
The enterprise requirements definition step is designed to gather a broad, horizontal view of the organization from a business point of view. The process flow chart in Figure 1.3 breaks the Enterprise requirements definition box from Figure 1.2 down into its subtasks. As we see in Figure 1.3, the core part of defining business requirements involves gathering and documenting those requirements.
While the four steps that are circled on the left side of the figure are shown as separate subtasks, we usually do them in a pipeline fashion, conducting an interview, extracting its analytic themes, identifying their supporting business processes, and placing each business process in the initial bus matrix. We'll describe each of the core subtasks in Figure 1.3 in this section, leaving the senior management prioritization session for its own section.
Preparation
Requirements definition is largely a process of interviewing business and technical people, but before you get started, you need to do a little preparation. Learn as much as you can about your business, your competitors, your industry, and your customers. Read your organization's annual report; track down any internal strategy documents; go online and see what's said about your organization, the competition, and the industry in the press. Find out what the big challenges are. Learn the terms and terminology the business people use to describe what they do. In short, do your homework.
Part of the preparation process is figuring out whom you should actually interview. This usually involves carefully examining an org chart with your sponsor and other key supporters. There are typically four groups of people you need to talk to early on: senior management responsible for making the strategic decisions for the organization; mid-management and business analysts responsible for exploring strategic alternatives and implementing decisions; source systems experts (the folks who really know what kinds of data issues are out there for you to trip over); and finally, people you need to interview for political reasons. This last group may not add any value, but if they're omitted, they could cause problems. Increasingly, there is a fifth group of people who may need the data warehouse-operational decision makers needing real-time or near real-time access to historical and integrated data. Your initial interviews should sample the operational community to see if such interest exists, and if so, a representative group of these users should be included in the interviews.
It's easy to start the interview list with the CEO and his senior staff. Add the analysts and managers who are known as leaders in the business intelligence area-folks whom senior management and co-workers turn to when they need information. They are also usually the folks who bug the IT organization the most. If you've been at your organization more that 12 months, you know who these people are. They have their own Access databases, they write SQL against the transaction system, and they create reports and charts with whatever tools they have available (mostly Excel and Access). Finally, add on a couple of the key IT folks who can educate you about the nature of the source systems.
NOTE
You are just making the list of whom to interview at this point, not the interview schedule. Start the schedule with a few people you know and trust before you turn to senior management. At the same time, make sure you get the elusive executives on the calendar as early as possible. Some of these folks can be tough to pin down.
A major goal during the interviews is to build positive working relationships with the business folks. These relationships will build on your understanding of the business issues your organization faces. In short, be prepared. Fortunately, gathering this information is not as difficult as it used to be, thanks to the Internet. However, you still have to read it.
Interviewing Business and IT
The next step in requirements gathering is actually talking to business users. Interview individuals or small groups (two to five people at most), rather than hold a large group design session. The individual interview allows each person to present his or her views on what the challenges are and what is required for success. It also gives the DW/BI team more opportunities to capture and clarify critical information. Finally, individual interviews are less work for the business folks. They take only an hour or so, rather than a whole day or two for group design sessions. On the downside, individual interviews collectively take longer and are more work for the DW/BI team.
(Continues...)
Excerpted from The Microsoft Data Warehouse Toolkitby Joy Mundy Warren Thornthwaite Ralph Kimball Copyright © 2006 by John Wiley & Sons, Ltd. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.