Starting an SAP BW Project

Team-Fly

---

The first step toward acceptance of any new technology is providing a compelling and effective business case. Customers who have already implemented SAP R/3 are eager to use SAP BW, but first a good case must be made for SAP BW. Why do you need SAP BW? How will SAP BW benefit your organization? How does SAP BW fit in the rest of your company information delivery and management strategy?

Data Warehouse Implementation Methodologies

Before charting an SAP BW project, take a quick look at data warehouse development methodologies.

Top-Down Approach

The top-down approach is usually business driven, meaning that the data warehouse is a corporate directive. It has full support, business and financial, from senior management of a company, who has a clear understanding of what to expect from a data warehouse. The hardest part of top-down methodology is that all business organizations have to agree on a common set of Key Performance Indicators and other analytical key measurements needed to make tactical and strategic business decisions.

The benefit of this approach is that you have full corporate-level sponsorship to implement a data warehouse. However, in a corporate-wide initiative, the initial scope of what to implement can be very broad. Also, it will take a long time before end users actually see the value of a data warehouse. This does not mean that the top-down approach is not suitable; it depends on how you define scope, prioritize deliverables, set expectations, and execute your project deliverables on time in phases.

Bottom-Up Approach

The bottom-up approach has been the most common way of implementing data marts. In this case, either a business manager or a department manager steps up to launch a data warehouse project with full financial support. This approach has several advantages: limited scope of what to implement, control over what to analyze, and easier rollout at a department level.

Sometimes, technology evangelists quickly master an emerging data warehouse technology and convince the department head to show the business value of adopting the new technology. Here, the departmental IT team and the technology evangelists win the business sponsorship, and data marts go live quickly.

The problem with this approach is that the implementation scope is very limited. The implementation is not visible at the corporate level and carries with it typical data-mart-related issues, such as inconsistent enterprise-wide data definitions and supporting technologies.

Hybrid Approach-SAP Approach

SAP proposes a hybrid approach for BW that takes advantage of the top-down and bottom-up methodologies. Customers who implemented SAP R/3 have already gone through the pains of data standardization and implementing scalable technology infrastructure at the corporate level. This is one key feature of the top-down methodology: the corporate directive. On the other hand, individual department business drivers can exploit SAP BW technology to implement a specific, business-focused data mart solution today by leveraging the same corporate-wide OLTP infrastructures and data structures. These data marts do not become obsolete when a corporate-wide initiative is launched; instead, they become an integral component of the corporate information supply chain. The SAP Accelerated SAP (ASAP) methodology for BW is a hybrid of the top-down and bottom-up approaches in implementing data warehouses.

Planning for SAP BW

The ASAP methodology for SAP BW is the right place to start. It outlines five major milestones, as shown in Figure 5-1.

Figure 5-1: ASAP Methodology Road Map for Business Information Warehouse.

Initially, there is a lot of excitement about new technology, launching a project, and forming a new team. Then comes the settling-in stage, which involves realizing how much work is necessary and wondering if it is all possible. Then comes getting everything down to a deliverable model and implementing and supporting the solution.

To meet this challenge, ASAP methodology for SAP BW comes with several accelerators and "how-to" guides and templates that speed up the SAP BW learning and implementation process. These accelerators and how-to guides are available at the SAPNET Web site (new SAP workplace portal, http://service.sap.com). You need an SAP Online Service System (OSS) account to access SAPNET.

Note 

SAPNET is a knowledge base of SAP customers. Here you will find the latest information on product patches, problem reporting and resolutions, tips and tricks, methodology guides, and on all SAP products one can think of. The OSS also provides other services, such as Early Watch to monitor the state of your implementation and recommend solutions to resolve future problems, as well as to log on remotely to apply special patches to resolve problems immediately.

The Basis team configures its SAP R/3 or SAP BW instances for OSS connections. Check with your Basis team to set up an OSS account.

Several SAP BW partners and consulting organizations provide additional SAP BW implementation accelerators and business content that significantly reduce implementation time. Figure 5-2 shows ASAP methodology guidelines for SAP BW 1.2B. At the time of this writing, most implementation guides refer to SAP BW 1.2B implementation models. This methodology will be revised for SAP BW 2.0 functionality at some later time.

Figure 5-2: ASAP Methodology Templates and Accelerators for Business Information Warehouse.

Initial Assessment-Making a Case for SAP BW

As a starting point, do a quick assessment of your existing SAP R/3 reporting environment. Identify what users like and dislike when doing reporting on SAP R/3. Ask users, reporting developers, and data warehouse administrators questions such as, "How long does it take to implement a report on SAP R/3?" Take a look at the rest of the company data warehouses beyond SAP R/3 reporting. How do they construct and manage data warehouses? How do they deliver information to the end users? How many different technologies are used to support data warehouses and from how many vendors? How much data is extracted from SAP R/3 on a daily basis if most of the reporting is done outside SAP R/3? How is data extracted from SAP R/3, and what is its performance impact on R/3 business operations? What is the corporate SAP R/3 strategy? How does senior management want to manage information across the enterprise? Is senior management fully committed to SAP products?

Identify major reporting and data analysis problems and causes of such problems for both SAP R/3 and non-SAP R/3 data analysis environments. For example, users may complain that it takes too long to implement a report on SAP R/3. In some cases, when a report program is implemented and made available to users, it is no longer needed. A few users may find that SAP R/3's flexible analysis is not flexible enough to analyze data the way they want, or that it simply takes too long to run the reports.

From this fact-finding mission you will have sufficient material to justify SAP BW-not because it is a new technology but from a total cost of ownership (TCO) perspective. Initially, limit the scope of an SAP BW project to one of the common business process areas, such as Sales and Distribution, Financial Accounting and Material Management, or Human Resources. Draft a project charter that articulates the value of SAP BW in terms of its data analysis flexibility, speed, manageability, and information delivery. Present a case for SAP BW to your senior management. Get commitment from a high-level business sponsor before doing further SAP BW project-detailed scoping.

Note 

It is critical that you have a business sponsor for this project, such as a CIO or vice president of a business process. Make sure that the business sponsor is well respected in the company and has full financial commitment to support this project. Without solid business sponsorship, an SAP BW project will not do anything but become a prototype.

Caution 

Having more than one business sponsor for your first SAP BW project is not a good idea, because you will end up spending a lot of time prioritizing whose analytical needs should be implemented first. This will definitely delay the success of your first SAP BW implementation and reinforce the perception that SAP BW will take years to implement, just like SAP R/3 implementations. In reality, this is not the case, but don't try to oversell your first SAP BW implementation. Make sure that you set expectations right away and are fully understood by end users and the implementation team.

SAP BW Project Scope

Like any software product, SAP BW is still maturing, so keep this in mind when defining the scope of an SAP BW project. Limit the initial scope of data analysis needs to SAP BW provided business content. SAP BW version 1.2B is suitable for multidimensional data analysis against data at the summarized level. In SAP BW 1.2B, ODS drill-down capability to the document level is not possible from within the BEX Analyzer. Keep such detailed drill-down data analysis capability out of the BW project scope. However, SAP BW 2.0 overcomes the scope of SAP BW implementation due to new ODS capabilities that hold detailed data along with summary level information in the InfoCubes.

The SAP BW project scope outlines what data analysis functionality will be delivered. Be careful in defining the actual deliverables. Figure 5-3 shows end-user data analysis areas that will help you define the scope of the BW project. Data analysis and reporting needs are classified in the following groups:

Figure 5-3: Reporting and Data Analysis Categories and Boundaries of an SAP BW Project.

• Operational Reporting. Requires real-time state-of-business operations, such as overdue orders, orders on hold, or released sales orders at the time of inquiry. These types of inquiries are very much transaction-centric. Do not force real-time or near real-time reporting into the scope of an SAP BW project.

• Management Reporting and Analysis. Do not require a real-time state-of-the-business performance. Rather, use an agreed-upon time period.

  Business managers or business analysts define what that time period should be and for what data set. This could be daily, weekly, or monthly. For example, every morning, sales analysts want to know daily sales by product, by distribution channel, or product inventory on hand. Here, day-old data from transaction systems is sufficient to meet business needs. On the other hand, cost managers want to analyze reported expenses by employees by the cost center on a weekly basis. In general, management reporting such as overdue orders and backlog reporting, profitability analysis, and variance analysis (performance versus plan) assist in analysis or measurement based on key performance indicators or metrics of the business. Most often, the management reporting and data analysis are subject-centric, such as sales, finance, and human resources. These types of analytical applications are well suited for the SAP BW project.

• Enterprise-Wide Reporting. Covers a broad range of data analysis needs across several subject areas spanning several years of data. Here, analysts and data-mining experts explore large amounts of data for strategic planning. SAP BW 1.2B is not suited for a very large corporate-wide database (terabytes database) environment to handle hundreds of end users. However, with new ODS capability in SAP BW 2.0, the scope of a data warehouse can easily reach to a large enterprise data warehouse.

Figure 5-3 shows the boundaries of data analysis requirements and how SAP BW meets specific reporting and data analysis needs. This figure suggests that SAP BW is very suitable for management reporting and analysis when data refresh is done daily or weekly. Therefore, when you define the scope of the SAP BW project, stay within these boundaries. Note that due to new data management capabilities in SAP BW 2.0 such as ODS and multi-InfoCube joins, the scope of BW expands deep in to the corporate enterprise data warehouse implementation.

Figure 5-3 also shows that real-time operational reporting should not be considered when defining the SAP BW project scope. Depending on the business activity on your transaction systems (such as orders, invoices, and deliveries), you can refresh SAP BW with new data two or three times a day. However, if you include near real-time operational reporting in your first SAP BW project scope, make sure that the data volumes will remain low for several months. This will ensure that frequent data extracts from SAP R/3 for SAP BW have no impact on the OLTP operations and that SAP BW can update InfoCubes without interruptions. Keep operational reporting out of the SAP BW project scope.

Caution 

Some data warehouse vendors provide data replication tools. A data replication scheme copies a data set, usually a database table, from one source to a target and keeps the target in synch with the source. Often, it is assumed that SAP BW, being another data warehouse environment, "replicates" transaction tables to another database (R/3 or non-R/3). Note that SAP BW does not provide data replication services. Instead, SAP BW pulls predefined transaction data objects from one SAP R/3 instance to one and only one SAP BW instance. The structure of "changed" data-in SAP BW terminology, delta-does not resemble any transaction tables. In some data, such "change capture" tables may not even reside in any R/3 database tables. It may have been a buffered table or derived value processed during a transaction and captured for SAP BW.

If you need to replicate SAP R/3 tables, database-specific replication techniques are a good way to achieve that goal. Keep pure database-level data replication out of your SAP BW project scope.

SAP BW is very suitable for management reporting and typical OLAP needs, but to succeed in your first SAP BW project, you should remember the following:

• Select a single subject area; for example, Sales and Distribution, Financials, or Human Resources.

• Keep the project scope as simple as possible; limit dimensions

• Document the scope

• Balance business benefit and feasibility

• Sell iterative-phased implementation

• Get management sign-off

After management sign-off, manage the project scope effectively. In data warehousing projects, often project scope grows bigger and bigger or changes. To be successful in your first SAP BW project, hold firm to the signed-off project scope. If for some reason scope has to be revisited, immediately establish the impact on the project schedule, resources, and costs associated with this change. Immediately update management of the changes in the project scope, and get management sign-off again. Design an SAP BW model for the future but deliver a focused, high-value, high-impact solution immediately. Your goal here is to show the results as soon as possible and retain the project momentum for the next subject areas.

---

Team-Fly