One of the biggest and most important challenges in any implementation is gathering and understanding the end user and process team functional requirements. These functional requirements represent the scope of analysis needs and expectations (both now and in the future) of the end user. These typically involve all of the following:

• Business reasons for the project and business questions answered by the implementation
  
  
• Critical success factors for the implementation
  
  
• Source systems that are involved and the scope of information needed from each
  
  
• Intended audience and stakeholders and their analysis needs
  
  
• Any major transformation that is needed in order to provide the information
  
  
• Security requirements to prevent unauthorized use

This process involves one seemingly simple task: Find out exactly what the end users’ analysis requirements are, both now and in the future, and build the BW system to these requirements. Although simple in concept, in practice gathering and reaching a clear understanding and agreement on a complete set of BW functional requirements is not always so simple.

The Functional Model Document

After your team has clearly established the business needs during an early interview process, it will encounter a critical question. What is the best method to translate the organizational expectations to real requirements that can then be used to achieve a clear understanding and agreement of the scope between all project stakeholders?

The best method that I have found is to establish a complete functional model document. This functional model document serves as the design document for a subset of the overall requirements but associated to one specific subject area. Simply put, this document should answer the following questions: Why are we implementing this? What requirements are we trying to fill? What is the goal of this model?

This document should not contain any information about InfoCubes, operational data store (ODS) object or DataStore object structures. The functional model document instead is designed to clearly understand the intended scope of the implementation without using any BW terminology or data modeling information. In other words, you need to gather this document and its information regardless of the data warehouse or reporting tool that would provide the reporting. This allows the requirement gathering to commence independent of the BW environment. Once complete, it is the main document used to develop and plan the BW physical and logical model.

Typical Scope Management Issues

Most BW projects have some type of scope management and functional requirement gathering processes. Why is this document so different from these existing and understood processes? To answer these questions, you first have to examine why this process does not always yield complete results.

Most experts agree that the most common core reason for a BW project to fail is a lack of agreement on the scope and a lack of understanding of the requirements between the BW team and the process teams providing the requirements. In other words, an all-too-common quote after early demonstrations of the intended solution is, “I see that you built something, but, it is not what we agreed upon and clearly not what I need.” The BW effort then shifts to rebuilding the solution or retrofitting the requirements into an existing data model, often without optimal results.

This often occurs because the initial scope document or functional model document do not clearly spell out to a proper level of detail the real requirements. Often scope documents and functional requirement documents are not seen as an important enough deliverable and thus, are not completed to the level of detail needed for effective scope management.

Many scope documents contain statements such as “the scope of the implementation is to provide detailed sales analysis.” Statements like these can often lead to problems later when the process team expects certain information and functionality to be delivered as part of the solution, contrary to the BW team’s scoping and expectations. An often-understaffed BW team must now find a place in the budget and timeline to deliver the new scope or disappoint the stakeholders by deferring or denying the requirement.

The functional model document is intended to provide a clear and written detailed agreement of the entire scope between the BW implementation team and the process teams representing the end users. This is established in as much detail as possible and clearly documented and agreed upon before any BW development can take place. In practice this gets the design decisions as early as possible. While it cannot avoid all scope misunderstandings, it does provide a certain contract between the BW and process teams and this allows the proper expectations by all stakeholders. An effective functional model document aids in the design and enhancement phases of development (Figure 1).

Figure 1

The typical flow of any data warehouse life cycle

There are several reasons why the process of getting the scope agreement is difficult. Usually there is a combination of the following factors:

• The process teams have not completely decided on their own needs
  
  
• Communicating the needs of the process team is difficult
  
  
• The process teams do not understand the BW tool
  
  
• The BW team does not understand the process team’s analysis or transactional needs
  
  
• Neither team understands one or many R/3, SAP ERP Central Component (ECC), or legacy systems needed to provide the required analysis

Complete the Functional Model Document

You should complete the functional model document in the analyze phase of your BW project (Figure 2). One of the most important aspects of the functional model document is that it should be listed and tracked as a deliverable of the associated process team. For example, the procurement process team should complete a functional model for analyzing vendor performance.

Figure 2

Complete the functional model document during the design phase of the BW project. Ensure that management signs off on this before proceeding to build.

The reason this is considered a process-team deliverable and not a BW-team deliverable is because you want to shift the analysis gathering and ownership to the process teams. This gives them the incentive to gather and own the functional model document, because without a completed functional model document, no development can take place in the BW system.

Like a player anteing up in a poker game, the process teams are forced to bring something to the table before anything other than preliminary analysis is done on the requirements. Often the process teams will scrutinize their analysis needs and set priorities better if they are forced to write a functional model document for the reporting requirements that are needed. Without this ante, the process teams often gather up reporting requirements in a spreadsheet list and present this to the BW team and ask the BW team to fill in the details of the scope. This is not only an inefficient use of the BW team’s time, it often leads to conflict later as the needs are not clearly understood and therefore not clearly met in the design.

Even though the process teams primarily own the functional model document, it should not be considered a document that is solely developed by the process teams. The document requires a lot of back and forth from the BW team in order to complete all of the sections.

Sections of the Document

There are several sections to the functional model document. Each section requires collaboration between the BW team and the process teams to complete.

Subject Area

Each functional model document should cover one subject area. The definition of subject area can vary by project and scope, but the subject area represents one area of a BW implementation that can be tracked and staffed as one unit of work. A subject area can include many different interpretations. The subject area is not always designed only to reflect one actual business area, such as sales and distribution, or purchasing. This is because there are many BW teams who track their scope at a more granular level than simply by business area.

To determine the subject areas in a BW project, the scope should be examined to determine where different sub-groups of the BW team would be used to implement the functionality needed. For example, in some BW teams, procurement would be considered a subject area. The BW team would scope, staff, and deliver the procurement needs as a group deliverable. In this case, the procurement area would be one subject area, and one functional model document would be produced for purchasing.

In other projects, procurement is much more complex and would be delivered as more than one sub-group. For example, there may be one sub-group that delivers the purchasing; another that does vendor performance, and another that might deliver the receipt tracking.

Understanding and separating the subject areas allow you to determine how many functional model documents are required.

Business Questions

This section of the functional model document is designed to give an overall understanding of the business pains and the questions that this functional model should answer once implemented. Although this appears to be a very easy section to complete, it is often the one that process teams have trouble completing fully. The business questions detailed in this section are used for several things, which include the following:

• To help to make sure that the BW team understands the business pain and the business analysis needs
  
  
• To allow the physical BW model to be developed with specific needs in mind
  
  
• To help when scope questions arise

These business questions will also serve as a foundation for the test cases in the future, to make sure that the physical model, once implemented, answers the questions posed in this section.

These questions should be in bullet format, be listed with specific measurements, and include time horizons. In most cases there are several of these questions posed for each functional model. Examples include:

• Measure and track vendor performance to determine on-time delivery based on purchase-order expected dates and actual receipt dates across months
  
  
• Track inventory turns based on stock items across fiscal periods to determine stock availability levels
  
  
• Manage and track the voluntary turnover of a division in the calendar year based on the employee headcount

This is typically the first section of the functional model document because it sets a clear goal for the overall implementation. It clearly outlines the business pain and establishes a clear understanding of how this functional model will address the business pain.

History Requirements of Information

The history requirements help to define the information and source of data for the solution. If history is required, it is important to understand what history and how much history are required in order to complete the model. This is most important to understand when there are legacy systems involved. In other words, when this data model is first released to the end users, how much history data should be loaded into BW and what source should be used for this data?

Many projects that need to have the legacy data loaded into the BW system require that this data be harmonized with the ECC or R/3 data so they can compare and provide analysis. It can be very time-consuming to map the legacy master data to, for example, the ECC data. Understanding these requirements helps to define and understand the scope of the reporting needs.

Often times, a clear understanding of the history requirements can point out many potential issues with loading of history, such as:

• How far back and what is the volume of data required for historical loads?
  
  
• Is all master data needed for this historical data available and what is required to load this into BW?
  
  
• How will this legacy historical data be harmonized with the existing non-legacy applications to provide a coherent view of the data?

Data Sources Required to Complete Model

Data sources broadly refer to the places where data is stored currently and the scope of data to be loaded into the model. This section of the functional model typically requires input from the BW team. The goal of this section is to see what data is needed to satisfy the reporting requirements and where it is found.

One of the worst situations in any BW implementation is finding out late in the build phase of the project that all of the data sources are not known. New data sources can add significant scope to any BW project because it implies and can involve one or many of the following:

• New source system connections and Basis infrastructure changes
  
  
• New extractors or DataSources activated or developed
  
  
• Harmonization with existing data and transformation or translation of data

The goal of this section is to clearly understand where all required data is being sourced. This section should concentrate on the transactional data sources. It may require in some cases to analyze the specific fields of data. It should clearly state the specific area of the system from which data is to be extracted.

If the data is to come from a legacy purchasing system, this section should clearly state the system name, the tables, or files that are needed to load this data into BW, and some information about this data. If the data is from the ECC or R/3 system, the BW team should work with the process team to analyze standard delivered business-content DataSource extractors to determine which of these matches the data that is to be extracted. This helps to establish the scope and number of DataSources that you will need to satisfy the reporting requirements.

Volume, System, Frequency

Understanding the volume of data that is required helps to set the eventual data model. If data volume is substantial, the data needs to be partitioned into multiple ODS or DataStore object structures, or multiple InfoCubes when eventually loading the data into BW. Understanding this volume helps plan and scope out any potential performance issues that could bottleneck loading or query processing.

It is also helpful to know the frequency with which data is required for analysis. This helps to spot possible needs for intra-day loads or real-time analysis.

Dependencies, Constraints, Assumptions

Sometimes, the BW team cannot load data until after a certain procedure or load is run on the ECC, R/3, or legacy systems. It is helpful to know about any constraints or dependencies so that you can plan the data model accordingly. It also helps to spell out the assumptions regarding the data at an early phase to make sure the BW and the process teams share these assumptions.

Presentation Requirements

The presentation requirements refer to the actual queries, dashboards, etc., that will be used to show the data in BW to the end users. When the functional model document is being developed, the presentation needs should be understood, but the main focus of the functional model document should be on understanding the information that is needed to deliver the model.

This section should spell out the presentation needs, but it is typically not necessary to list all queries or analysis needs in detail. There is a basic understanding that as long as the data sources are clearly spelled out, that data is being loaded into BW. The presentation needs can be flexible and based on the needs of the organization. Thus, in this section, only the most vital presentation needs should be listed, with an understanding that the presentation layer of BW can be flexible to provide many different forms of analysis, as long as the source of data for the analysis is in BW.

This section should also list the audience and the form of distribution for the presentation. It is helpful to understand the roles of the BW users and how they will be accessing the presentation to understand and plan its delivery. For example, this section should state whether Web or portal access is required and if Microsoft Excel functionality will be part of reporting.

Security Requirements

Understanding and implementing security requirements are often left until the very end of the BW build process. This can be a mistake. If the security requirements are known from the beginning, the model can be planned and the presentation of data can be developed using the security requirements. If the security needs to be retrofitted into an existing complete model, some rework may be needed to complete the security requirements.

This section should state if the security is not needed at all. If it is needed, how should the security be implemented? Is the security by query? Are there certain key figure values in the data that are sensitive and thus should be protected? Are there certain characteristics that should be secured? For example, if several divisions of sales data are being loaded into BW, should all divisions be allowed to see each other’s sales? Is there a restriction on any other characteristic of the data?

Sign-Off

To make sure that all groups are in agreement on the functional model document, a sign-off process should be established. This way, any changes to the functional model can be discussed as a scope-change process. No development or planning on the BW physical model should commence until the functional model document receives sign-off.

Next Steps

Since the functional model document does not (and should not) contain any information on BW physical modeling structures such as InfoCubes, ODS or DataStore object structures, the next step, after sign-off, is to use the functional model to develop a physical or logical model. This would represent how the requirements found in the functional model document are being realized in BW. Since the requirements are clearly stated, the functional model document can be used to try to break the model or see if all the requirements for analysis are clearly met. It also allows project management to make more-informed project planning decisions based on the design because it most clearly represents the user requirements.

Scope Change Process

Since requirements are bound to surface in the design and build phase that are not covered or mentioned by the functional model document, it is important to have a clear and formal scope-change process to address requirements that were unknown or not clearly understood during the completion of the functional model document.

Gary Nolan

Gary Nolan is an SAP NetWeaver BW-certified consultant and author of Efficient SAP NetWeaver BW Implementation and Upgrade Guide and Efficient SAP NetWeaver BI Implementation and Project Management. Gary specializes in gathering and evaluating requirements, configuring SAP NetWeaver BW, and providing project management, performance management, and data architecture and data modeling expertise. A former platinum consultant with SAP America, Inc., Gary has more than 20 years of SAP experience, working with SAP NetWeaver BW since version 1.2B.

You may contact the author at melvan.consulting@yahoo.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.