Before embarking on an SAP NetWeaver BW implementation, it's important to define your project goals and scope,...
as well as create a clear project timeline. In this SAP Press book chapter excerpt, you'll learn what some of the most common SAP NetWeaver BW implementation mistakes are and find strategies for avoiding NetWeaver BW project pitfalls.
Common SAP NetWeaver BW Implementation Mistakes
This chapter details common mistakes that are often made on SAP NetWeaver BW project implementations. Throughout this chapter, we will detail some of the most important ones and provide insight to how to address, or better yet, avoid them.
3.1 Unclear Definition of Goals and Scope
Implementing SAP NetWeaver BW, as with any project, you must start with clear goals and a clearly defined and documented scope. While it seems that any project manager would admit this is the most important task in SAP NetWeaver BW project management, its absence is the most common reason that projects miss their scheduled go-live date or are cancelled altogether. How can you make sure that the goals of SAP NetWeaver BW are clearly defined and communicated?
3.1.1 Develop Clear Project Scope Documentation
SAP NetWeaver BW scope definition needs to be agreed to and signed off on by all parties before any development can begin. The more detailed the scope documentation, the better the understanding of the requirements, timing, and implementation of SAP NetWeaver BW, and thus the more likelihood for success.
The scope document should be considered the most important document in the SAP NetWeaver BW project. The SAP NetWeaver BW scope should be first established as part of an initial scoping exercise, then refined through an interview process, and finally be subject to a scope document signoff (see Figure 3.1). This scoping exercise is part of the earliest phase of the project, the project-preparation phase.
Figure 3.1 SAP NetWeaver BW Scope Development Process
There are multiple subsequent documents that will establish the scope in even greater detail. However, these documents will come in the analysis phase of the project, not in project preparation. The critical components of the scope document include:
- Information that will be included in SAP NetWeaver BW
- Subject areas, with their priority status
- Scope of each subject area
- Summary of transformation needed
- Summary of the level of aggregation and summarization of data
- Description of the presentation tools.
The initial scoping document should provide information on the following critical areas in the scope process in Table 3.1.
|Business Requirements||Business reasons for the project and business questions answered by the implementation|
|Stakeholders||Roles and responsibilities of those in the implementation process|
|Critical Success Factors||Determinants and measures for a successful project|
|Source Systems||The source systems that are involved in the project and the sources of data in these systems|
|Data Access||The intended audience of the SAP NetWeaver BW project and their use of the information|
|Transformation||Any transformation that is needed to provide the data in its desired format|
|Security||The data-access security requirements to prevent unauthorized use of the information|
|Batch Window||The frequency of load and approximate timing of loads|
|Archiving/History||How much historical data is needed, and how long will this information be kept in SAP NetWeaver BW?|
|Testing Procedures||The basic process for testing and some testing and validation parameters|
|Master Data Requirements||The master data tables and information that are needed to support the reporting in SAP NetWeaver BW|
|Change Management||Strategy for rolling out the process changes to the organization|
|Timing||Project schedule and time line|
|Transition to Production Support||Some information on the go-live process and transition from development to production support|
Table 3.1 Critical Areas in Scope Process
3.1.2 Establish Milestones
Establishing milestones and measuring these milestones is one of the most important measures of a project’s chances for success. Setting these milestones allows the SAP NetWeaver BW team to understand and work to these goals. This process is called setting micro goals. The micro goal is a small, attainable goal that can track a project week to week. Examples are setting up connectivity with a source system, doing a test pull of data, and transformation of data in one area.
If you measure the micro goals, you can make sure that the project is on track. You can then quickly add resources to those areas where the micro goals are not being met. Often, project teams find themselves simply measuring against a macro goal, such as completing the analysis phase. Often, projects that focus too highly on larger goals do not know that they are behind schedule until it is too late to act.
How you will be setting the milestones is completely dependent on the nature of the SAP NetWeaver BW project. However, any SAP NetWeaver BW project can be divided in smaller parts based on the following criteria.
- Business Area
If you are implementing SAP NetWeaver BW on various business areas like MM, SD, FI, don’t implement them at once. Instead, implement those business areas one-by-one.
- Source Systems
If your SAP NetWeaver BW implementation involves many source systems, then dividing your milestones based on source systems will be a helpful approach.
Figure 3.2 shows that by breaking up the SAP NetWeaver BW project into smaller, more digestible chunks, it is much easier to see the whole picture, understand dependencies on other groups, and make sure that the SAP NetWeaver BW project will make its scheduled go-live date.
Figure 3.2 Example of Setting up Milestone for SAP NetWeaver BW Implementation
3.1.3 Avoid Scope Creep
Scope creep can occur in an SAP NetWeaver BW project just as easily as an SAP R/3 or SAP ECC project. The best way to prevent the scope creep in SAP NetWeaver BW is to have a firmly established scope right from the beginning and require signoffs on the scope document. Adding more detailed governance, such as the functional model process, further establishes the intended scope.
Keeping to and tracking against the scope is one of the more difficult challenges facing a SAP NetWeaver BW project, and there are no easy solutions to scope creep other than to clearly document all requirements.
A functional model is a document that clearly states the scope and delivery of the data in an SAP NetWeaver BW functional area. Chapter 5 walks through the functional model process in detail. This process helps to establish the SAP NetWeaver BW requirements, business questions, and needs. The functional model serves as the most important scope-management document, and a signed-off functional model can help avert scope creep and keep the project on track.
The best way to avoid scope creep is to allow end users to participate in the design phase and incorporate their suggestions.
3.1.4 Establish a Scope Change Control Process
As tightly as any SAP NetWeaver BW project team would like to control scope, changes inevitably occur. These could be the result of missed scope areas, new opportunity, changing business environment, or newly discovered challenges. Thus, scope cannot be assumed to be unchanging. A scope review and management process to allow for changes is vital to communicating and accepting these changes. This should involve review, communication, and escalation.
3.1.5 Take Advantage of Existing Legacy Systems
Many SAP NetWeaver BW projects are mainly upgrades from existing legacy reporting systems. This happens when a customer upgrades its legacy transactional systems with SAP R/3 or SAP ECC systems. To create a robust scope document, you can refer to the existing reports that the customer was using before migration. For example, a customer was using Mainframe for materials management when they migrated to the SAP R/3 MM module. They also adopted SAP NetWeaver BW as their reporting environment. The initial scope document was developed quickly based on the older system. When the customer saw the scope, they quickly agreed on that scope and subsequent SAP NetWeaver BW–related features were implemented in the next release.
You should always be aware of certain pitfalls of using legacy systems as a template for your SAP NetWeaver BW project, including:
- Extensive industry and SAP R/3 knowledge is required to map with SAP and legacy fields.
- Do not use fields from a legacy system. In your scope document, you should always define SAP-related fields.
- The customer is upgrading the system because they need new features, so don’t always stick to older systems.
Controlling the scope helps to avoid another common issue, an over-ambitious scope. This can often be the result of simply trying to do too much, too fast. Let’s find out more about over-ambitious scope now.
3.2 Over-Ambitious Scope
As with many SAP R/3 or SAP ECC projects, the failures that occur in SAP NetWeaver BW projects are often the result of attempting to implement too much at one time. SAP NetWeaver BW has the power to pull significant amounts of data from multiple source systems both in the SAP landscape and outside of this landscape. This freedom to bring almost any data into SAP NetWeaver BW tempts many organizations to become overly ambitious.
There are several things that need to be learned and accounted for in any SAP NetWeaver BW implementation. A developer must understand the information requirements, the data, and the presentation and loading needs, and must reconcile all these needs with the SAP NetWeaver BW tool. Thus, any overly ambitious scope forces the team to take shortcuts on the analysis and understanding of the data and information needs and thus can cause the SAP NetWeaver BW project to stall.
3.2.1 Start Small
How can an overly ambitious scope be avoided? The only answer is to start the SAP NetWeaver BW implementation plan with a small go-live scope and build from a small but well-designed base. This allows the process of implementing SAP NetWeaver BW to be firmly established. The lessons-learned from the first implementation can be used to make each subsequent implementation that much stronger.
A good example of a small project is one that limits the data to one source system, typically and most often the SAP R/3 or SAP ECC transactional system. Within that transactional system, the scope should also be reduced to one subject area, such as sales tracking or SAP General Ledger postings.
The smaller the scope, the more focused the team can be on understanding the requirements and delivering these as a quality deliverable on time. As previously stated, once the user loses confidence in the SAP NetWeaver BW solution and the information provided from SAP NetWeaver BW, it is extremely difficult to win the user back.
Thus, a small scope allows a robust user signoff and testing process. This makes sure that any data anomalies that occur on the source systems are fixed in that source system and that SAP NetWeaver BW is aggregating and reporting the data in the most effective manner.
Many organizations will opt to start with some small financial or sales reporting. They set up the extraction process to bring this data into SAP NetWeaver BW and present it with a limited number of queries. The users can then look at these queries and formulate the requirements for the next phases of rollout.
Because SAP NetWeaver BW is independent of the SAP R/3 or SAP ECC source system, in some cases new SAP NetWeaver BW functionality can be created and rolled out to the end users without coordination or synchronization with the SAP R/3 or SAP ECC rollout schedules. In other words, if the source data is available, SAP NetWeaver BW can allow the reporting on this data to go live without tying it to an overall project phase go-live involving the SAP ECC or SAP R/3 teams.
SAP NetWeaver BW can have many mini–project go-lives to stagger delivery of functionality, thereby preventing a big bang overly complex scope from crippling the SAP NetWeaver BW team. Often, a small go-live provides the momentum (and funding) needed for subsequent go-lives.
Advantages with Small Go-Lives
Team members can concentrate on business logic effectively.
Rigorous testing can be performed.
Quality delivery is assured.
Small go-lives allow robust user signoff.
3.2.2 Be Wary of Implementing SAP NetWeaver BW at the Same Time as SAP ECC or SAP R/3
Projects that attempt to implement SAP NetWeaver BW at the same time as the source SAP ECC or SAP R/3 system face especially big challenges. This can be compared to trying to climb a mountain whose summit is constantly moving. No sooner do you get a foothold and start to climb then the goal changes.
Having a constant and steady source system when implementing SAP NetWeaver BW helps ensure consistent rules for the data. When the SAP ECC or SAP R/3 system is evolving at the same time as the SAP NetWeaver BW system, this causes severe frustration and delays in the SAP NetWeaver BW project.
Take the example of a large company that was implementing the Materials Management (MM) module of SAP R/3 to enter and track its purchases. They set their transactional configuration and pricing for the purchase orders, and the data was first extracted into SAP NetWeaver BW. The purchasing data was configured into a sound data model.
As more data was extracted, the purchase order price fields became inconsistent. The net price was in one key figure value; later, this same key figure value included the freight charges. It took a lot of testing to determine that the issue was a result of a last-minute pricing configuration change on the SAP R/3 transactional system. A small decision in the source system can have huge ramifications for the SAP NetWeaver BW system.
The problem is that few of the people configuring pricing were aware of the impact of their decisions. Waiting until after their configuration was complete would have mapped the freight and net sales consistently and saved a great deal of time.
Many projects look to SAP NetWeaver BW to become the place for reporting of data for an SAP ECC or SAP R/3 implementation. However, when developing SAP NetWeaver BW at the same time as the source area in SAP ECC or SAP R/3, challenges are inevitable.
There are advantages to developing both systems at the same time. By developing both systems together, it is possible to have a clear integrated test process in conjunction with the SAP R/3 or SAP ECC systems.
Implementing SAP NetWeaver BW with SAP R/3 or SAP ECC also eliminates some of what would be throwaway work on the transactional systems. This is because the reporting functionality is often needed on the source system. If SAP NetWeaver BW is not there to provide this reporting, there must be some other system to provide this reporting.
In some cases, custom ABAP reports are created for temporary use on the transactional systems. Some, if not all, of these could be eliminated if the SAP NetWeaver BW system were there from the beginning to provide this type of reporting.
The biggest challenge is to try to implement SAP NetWeaver BW on a changing source system platform. Good communication and change management are needed to coordinate the transactional team and the SAP NetWeaver BW team.
In most SAP NetWeaver BW implementations, the SAP NetWeaver BW team usually lags the transactional team by four to six weeks (see Figure 3.3). This allows the transactional team to be more firmly established and create some sample configuration and data to configure, load, and test the SAP NetWeaver BW system.
To assure that the SAP NetWeaver BW project budget does not get exhausted waiting for SAP R/3 or SAP ECC configuration to finish, the SAP NetWeaver BW project should not kick off until four to six weeks after the associated SAP R/3 or SAP ECC project.
Figure 3.3 SAP NetWeaver BW Implementation Lagging Time with Respect to SAP R/3 or SAP ECC Implementation.
Setting the time line for an SAP NetWeaver BW project in coordination with the SAP ECC or SAP R/3 teams often means adjusting the SAP NetWeaver BW time line if the transactional time line shifts. It also means setting a realistic time line that can be achieved. Issues often occur when projects have an unrealistic time line.
3.3 Unrealistic Time Line
Some projects start with a time line that is either unintentionally or intentionally unrealistic. Project teams have been known to provide what they knew was an unrealistic time line simply to get management’s buy-in. This gets management on board, but then slowly the dates are moved into a more realistic time line.
Naturally, we don’t suggest this for long-term project management. Let’s look at another example. A project manager intentionally sets unrealistic time lines to motivate the team to act. The project managers felt that if they didn’t put a stake in the ground, the team would never move forward. This strategy backfired because most of the team members knew that the time table would never be met and therefore ignored the fact that their deliverables would be late.
A clear realistic time line is the most honest way to ensure longer-term success and keep the team motivated toward the goal of a successful go-live, within budget and on time.
Once a clear timeline is established, it needs to be clearly communicated to the team. This communication and other project-related standards become part of the project governance. This governance helps ensure that there are common standards for the project.
3.3.1 Don’t Forget the Time for Documentation and Training
There are some projects that calculate the time line based on development and testing of the system. Project managers simply don’t give much importance on documentation or training material for end users. This kind of approach should not be adopted at all. The success of any SAP NetWeaver BW implementation lies on usability of reports. If users are not properly trained, they will be able to run the reports and overall objective of having SAP NetWeaver BW fails.
There are several ways to manage SAP NetWeaver BW documents and display them to end users whenever they need. One option is to leverage the Document Management tool in RSA1 (see Figure 3.4). Here, you can create tutorials/user guides for several objects of SAP NetWeaver BW. These documents then can be accessed from reporting environment on demand.
Figure 3.4 Document Management Tool in SAP NetWeaver BW
You can create document for the SAP NetWeaver BW object types in Table 3.2.
|CTRT||Currency Translation Type|
|UOMT||Quantity Conversion Type|
|RASE||Reporting Agent Setting|
|RAPA||Reporting Agent Scheduling Package|
|DDAS||Data Access Service|
|EREL||Enterprise Report: Reusable Element|
|ITEM||Web Item (Format SAP BW 3.x)|
|BITM||BEx Web Item|
|TMPL||Web Template (Format SAP BW 3.x)|
|BTMP||BEx Web Template|
|DTPA||Data Transfer Process|
|PLST||Planning Function Type|
|THJT||Key Date of Type Derivation|
Table 3.2 Object Types for SAP NetWeaver BW Documentation