Implementing Sap BW With Sourcecode Inc.: Version 2.0 March 2006 ©

Implementing SAP BW
with SourceCode Inc.

Version 2.0 March 2006 2006 by SourceCode, Inc.

Implementing SAP BW

2006 by SourceCode Inc. Washington D.C. * New York * Mumbai info@sourcecodeinc.com

2

TABLE OF CONTENTS

INTRODUCTION ........................................................................................................................ 3
WHY SAP BW? ............................................................................................................................ 4
BW IMPLEMENTATION APPROACHES.............................................................................. 5
TIME DIMENSION - IMPLEMENTATION APPROACHES............................................... 6
SCOPE DIMENSION - IMPLEMENTATION APPROACHES ............................................ 7
IMPLEMENTING SAP BW OFFSHORE: FACTORS AFFECTING IT ........................... 11
REASONS FOR OFF-SHORING............................................................................................. 15
BW IMPLEMENTATION: THE ONSITE OFFSHORE MODEL.................................... 16
GLOSSARY ................................................................................................................................ 19
REFERENCES............................................................................................................................ 19

Implementing SAP BW


3

Introduction

In today's competitive business environment, the need to make faster, more informed decisions at all
levels in the organization has never been more important. However, the information to make these
decisions is often not readily available and accessible. The result is countless hours spent obtaining,
organizing and analyzing information to understand your business and make better, more informed
decisions.

Companies who recognize that information is a key part of building a competitive advantage have
embraced data marts, data warehouse and business intelligence solutions. These environments become
the focal point for the organization's information needs by storing integrated, accurate, historic and
detailed data for use across the enterprise. They enable transformation of raw data into applied strategic
knowledge, up the Information Value Chain.

Figure 1: Information Value Chain

When properly implemented, a data warehouse acts as a foundation for all information distribution and
reporting needs, thus providing an entire organization a "single version of the truth." Through direct
access to this data, business intelligence solutions minimize the time spent gathering data and maximize
the analytical capabilities. A data warehouse that is cross-functional and core to business strategy will
best position an organization for maximum results.

Implementing SAP BW


4

Key Characteristics of a Data Warehouse
Solves a critical business problem
Adds value beyond the mere collection of data
Aligned with stated business strategies and advances business strategy in a measurable way
Integrates key business processes, initiatives and capabilities
Enables business innovation by leveraging cross-departmental data (previously unattainable)
Integrates back-end analytical applications
Business models drive data warehouse solution
Integrates metadata across the data warehouse environment
Key Success Factors of a Data Warehouse Strategy
Strong internal collaborative sponsorship
An environment that provides the highest level of cross-functional/cross-organizational data
sharing
Application of rigorous data quality standards and improvement
Follows an architectural framework (blueprint)
Incorporates an architecture/methodology that allows a repeatable process for designing and
implementing data warehouses and data marts
Why SAP BW?
According to the Gartner Group, organizations that are pursuing a SAP ERP strategy with a high volume
of transaction data processing in SAP, the logical choice for a decision support environment is SAPs
complimentary tool Business Information Warehouse. The Gartner Group estimates that By 2008, more
than 80% of SAPs R/3 installed base will implement BW to meet their operational focused decision
support needs (0.8 probability).
SAP BW is all about meeting the reporting needs of the various role-players in an organization. It is a
central reporting tool that tightly integrates with online transaction processing systems like SAP R/3, at
the same time also pooling in data from other internal and external information sources. Traditionally, BW
implementations have focused on providing information owners with consolidated data, varying from a
day to a month. However, going forward, newer versions of BW will be supporting real time updates from
the OLTP system with latency reduced to almost a minute. With this new trend, BW implementations may
Implementing SAP BW


5

soon need to adopt a different strategy. The BW system could then act as a single point for all reporting
needs, both operational and analytical.

SAP BW shouldnt be viewed as a stand-alone data warehousing implementation, but one that can act as
the foundation of the organizations business intelligence architecture. SAP BW can act as a hub for all
closed-loop analytical applications, feeding and receiving data to other analytical applications like SAP
SEM, CRM and APO. When integrated with portals, it can form the basis of a collaborative Web based
business intelligence framework.

BW Implementation Approaches

Organizations implementing SAP solution suite can be categorized into two classes:

Brown Field Approach

These organizations have already implemented R3 and are looking at BW for leveraging the benefits
across the organization through better decision support.

Green Field Approach

These are organizations which do not have an existing enterprise wide integrated transaction processing
system in place but are looking at faster realization of benefits by parallel deployment of R3 and BW.

Brown field implementations are relatively easy to structure since the OLTP deployment has already
taken place and therefore the inter-linkages are less complicated. There are however certain limitations of
such implementations which are discussed in subsequent sections.

From a Green field implementation perspective, there are multiple parameters involved in terms of
structuring the BW implementation vis--vis the R3 implementation schedule. Green field implementations
obviously have their own set of challenges.

Structuring Dimensions
There are two key dimensions involved in structuring BW implementations:
Time Dimension
Scope Dimension
Implementing SAP BW


6

Time Dimension - Implementation Approaches

The following three approaches can be structured based on time dimension:

Parallel Implementation
Lagged Implementation
Deferred Implementation

Parallel Implementation
R3 Implementation and BW Implementation projects are executed in parallel.
Key Success Factors:
Program & project management
Quick resolution of issues on a day to day basis
Client team training and understanding of SAP (R3 as well as BW) before initiating the projects
Comprehensiveness and clarity of business process owners in simultaneously articulating the
requirements on the process as well as reporting aspects
Lagged Implementation
R3 Implementation and BW Implementation projects are mapped in such a way that there is phase-lag
between the two implementations. Therefore, start of BW blueprinting is linked to end of R3 blueprinting
phase and so on.

Clarity in articulation of reporting requirements
Capturing all possible business processes and reporting scenarios during blueprinting phase
Quick resolution of issues during each phase
Program & project management

Implementing SAP BW


7

Deferred Implementation
R3 Implementation and BW Implementation projects distance each other by a considerable time period.
Therefore, BW implementation in such cases would be initiated after R3 implementation has been
completed and has been operational for quite sometime.

Maintaining the organization-wide initiative and momentum gathered during R3 implementation
Change management

Keeping the ABAP related report development effort to minimum during the R3 implementation
Ensuring that R3 implementation takes into account the data modeling issues for BW
implementation, at least from a broader perspective

Scope Dimension - Implementation Approaches

The following two approaches can be structured based on scope of BW implementation:
Big Bang Implementation or Top-Down Approach
Pilot Implementation or Bottom-Up Approach

Implementing SAP BW


8

Figure 2: Top-Down Approach vs Bottom-Up Approach

Big Bang Implementation or Top-Down Approach
Implementation scope covers all organizational processes and reporting requirements.
The BW solution suite is deployed across various functions in parallel. Therefore, whether its finance,
materials, production planning or sales the end-users in all the functions would use BW simultaneously.

The upsides to a top down approach are:
Coordinated environment
Single point of control & development

The downsides to a top down approach are:
Cross everything nature of enterprise project
Analysis paralysis
Scope control
Time to market
Risk and exposure

Implementing SAP BW


9

Pilot Implementation or Bottom-Up Approach
Implementation scope covers select processes and key reporting requirements, which have a high
business impact.

The pilot implementation acts as a showcase and is followed by next phase of enhancement where in
other processes and reporting requirements are also covered.
The challenge lies in identifying those quick hit processes and reporting requirements while at the same
time keeping all business groups enthused about the implementation.

The upsides to a bottom-up approach are:
Quick ROI
Low risk, low political exposure learning and development environment
Lower level, shorter term political-will required
Fast delivery
Focused problem, focused team
Inherently incremental

The downsides to a bottom up approach are:
Likely curse of success (overwhelming success overwhelms resources)
Multiple team coordination
Must have a common architecture to integrate incremental data marts

Implementing SAP BW


10

Structuring Options

The above set of structuring dimensions and the state of implementation can throw open multiple
structuring options as shown below:

The above six structuring options can be rated broadly on various key impact parameters and compared
as shown below:

Figure 3: An SAP BW implementation phased along various structuring dimensions

Its important to note that the ratings shown above are relative across various options without
understating the fact that differences across organizations do exist and the impact of one can be
managed to some extent through adequate controls over a range of parameters mentioned above.

Identifying the right mix of implementation approaches and structuring, the BW Initiative is a critical factor
that can have a significant impact on the success of the initiative. Each organization is distinct in its
environment and therefore no two organizations might have the same recipe for success.

Implementing SAP BW


11

Implementing SAP BW Offshore: Factors Affecting It

The extent to which activities in a SAP BW implementation can be off-shored is contingent on several
factors. The section below discusses each one of them. It is important to consider all these factors
holistically before deciding on how much and what to offshore.

Type of Engagement

BW engagements can broadly be classified into three categories: baseline implementation,
enhancements to an existing implementation, and production support. The purpose of a baseline
implementation is to quickly deploy a BW based reporting and decision support system, which is based
on standard business content provided by SAP. Enhancement projects build on the baseline
implementation and incorporate customer requirements not met by standard business content. Some
examples of enhancement projects are: implementing additional reporting environments like Web
reporting, Portals interface, third party reporting tools, incorporating non-SAP data sources and creating
new info cubes. Production Support projects monitor the live production system ensuring successful data
loads into BW, resolving issues that end-users may face and incorporating minor enhancements to the
existing information models and queries.

The offshore component will vary depending on the type of engagement. A rough guide is given in Figure
4. The baseline implementation has been assumed to be a lagged big-bang implementation.

More work can be off-shored in an Enhancement project compared to the baseline implementation. The
business users have a good understanding of the features of the product and there is greater clarity in
specifying the requirements. BW implementations in which custom extractors and custom info cubes need
to be built are good candidates for off shoring. Developing custom extractors requires significant ABAP
programming efforts and should be off shored. As the efforts in these scenarios tend to be higher, the
cost reduction will also be higher when outsourced.

Enhancement projects such as implementing Web reporting for an existing BW implementation can be
successfully handled from offshore if the reporting requirements are static and the major effort is directed
towards Web enabling the queries with small cosmetic changes to the pages. If the requirement is to
incorporate additional functionality with significant changes to the reporting and cosmetic aspects, the
level of off shoring should be judicious.
Implementing SAP BW


12

Figure 4: A rough guide to the varying offshore component

Production support of BW systems is the best candidate for off shoring. While level one support can be
considered at onsite, level two and level three should be done from offshore. Skilled resources for quick
ramp-up and ramp-down are more readily available at offshore. If the support is handled by the same
vendor who has done the implementation, the transitioning is easier. If you are considering off-shoring the
support activities to a vendor different from the implementation partner, it is important to ensure an
effective knowledge transition. You should also consider having them at onshore for a short initial period
to gain a good understanding of the systems before moving work offshore. Additionally, it is important to
verify the information security practices of the vendor.

Implementation Approach

A BW implementation can be phased along various structuring dimensions as shown in Figure 3. Each of
these structuring options has its unique aspects and hence affects the extent to which the activities can
be executed at offshore in each phase.

The offshore component for each of the structuring options is shown in Figure 5. This should be viewed
as an approximate guide; the actual component may again vary depending on other factors.

Implementing SAP BW


13

Figure 5: The offshore component for various structuring options

In Figure 5, since blue predominates, apparently it may suggest that the offshore component is not
significant. However, since the realization and later phases comprises approximately 70% of the project
duration, the actual leverage drawn is substantial. Figure 6 contains the leverage drawn per phase and
the overall cost savings for a Parallel Big Bang BW implementation with significant custom development.

In all the structuring options, the planning and blueprinting phases should be executed onsite. Starting
with realization phase, one can start off-shoring.

The offshore component in the pilot structuring option generally tends to be low. BW pilot
implementations generally have a narrower scope and the emphasis is on demonstrating the analytical
reporting capabilities, brining in a culture of analytical decision support based information systems and
building confidence on the business warehouse as a product to meet business requirements. As delivery
timelines are smaller, peak team size tends to be high. High requirement changes are a characteristic of
pilot implementations and when executed in parallel with the OLTP implementation, it tends to be much
higher. In a lagged pilot the design and data requirements for the OLTP system are not as fluid as in the
parallel option. Hence off-shoring opportunities are comparatively higher. In a deferred pilot, the
dependencies on OLTP changes are minimum. Hence the offshore component should be higher than the
pilot and the lagged. However, it is offset to some extent because of the standalone nature of the project
in comparison to the pilot and the lagged options. Additionally, a pilot project should be seen as an
opportunity to build a strong foundation in terms of business process and reporting needs understandings
so that during big bang, off-shoring can be pursued more aggressively.
Implementing SAP BW


14

Big Bang BW implementations require dedicated project monitoring and control. In Big Bang BW
implementations, the extent of off-shoring is significantly higher with the lagged option having the highest
offshore component assuming similar implementation scope. A parallel implementation has dependencies
on the OLTP implementation in terms of business process design. Any change in the OLTP design
configuration may have an effect on the BW design. Thus the degree of interactions with the end-users
and business process owners is considerably higher. Off-shoring is a possible option in Big Bang
implementations as the scope of implementation itself spreads across the various business units, which in
turn implies that peak team sizes tend to swell. Also, usually Big Bang implementations tend to have
comparatively higher degree of non-standard configuration and development requirements, which in turn
increases the off-shoring potential.

Scale of Implementation

The scale of implementation determines the extent of off-shoring as it balances the coordination costs
and the cost savings. The scale is determined by the business units involved, geographical spread,
modules covered, number of source systems and the number of users. As each of these factors increase,
the scale increases and hence the offshore components. BW implementations as a standalone project,
with a small team size, covering single business units and only a few modules may not justify the setting
up of offshore facilities. The associated co-ordination costs will tend to offset the cost leverage gained
from off-shoring. Hence its preferable to have such projects onsite and as the scale of engagement
increases, off-shoring should be considered.

Project engagements where the scale is big and there are other projects being implemented
simultaneously are excellent candidates for off-shoring. The c-ordination and project management costs
tend to be small and gains significant.

Vendor Track Record

It is important to ensure that a vendor has a proven track record of executing offshore projects of a similar
nature. Thus it is essential to see the number of data warehousing projects that were successfully
executed using the onsite-offshore model and the required domain expertise. Ensure that the vendor has
robust quality processes and are certified at CMMI level 4 or higher. Check if the vendor has strong
project management and relationship management practices in place. The higher a vendor measures on
these parameters, the greater the off-shorability.

Implementing SAP BW


15

Reasons for Off-shoring

On mention of the word off-shoring the first thing that springs to mind is cost benefits. While this is true,
off-shoring offers many other equally important benefits. The various reasons and benefits of off-shoring
are discussed in the next section.

Cost Savings

The primary driver for off-shoring is the cost benefits. Figure 6 shows the typical cost savings for a parallel
Big-Bang BW implementation with significant custom development. The realization phase draws the
highest leverage with over 40 % savings. We achieved an overall savings of 30 % for one of our major
clients in the energy and utilities sector.

Figure 6: Cost savings on a Big-Bang BW implementation

Implementing SAP BW


16

Better Resource Utilization and Depth of Resources
Another major benefit is the ability to quickly ramp-up and ramp-down the team size as the project
progresses. This provides more flexibility to clients in terms of manpower requirement and ensures
optimum resource utilization. Off-shoring also ensures availability of a bigger pool of resources, which in
turn ensures a closer fit of skills for a particular project.

Quality and Consistency

The quality of services from our offshore development centers is high. Companies are able to achieve
process quality through quality measures like ISO 9000 and SEI-CMM levels. Use of Six Sigma
processes also figure in the priority list of methods for attaining quality.

Enhanced Productivity

Off-shoring also exploits the benefits of Follow-the-Sun Model. Sequential tasks draw the maximum
leverage. It increases productivity, reduces development times and hence lowers the time to benefit from
the implementation.

BW Implementation: The Onsite Offshore Model

A typical offshore execution model for a baseline BW implementation using the ASAP methodology is
shown in Figure 7. The important activities of each phase are shown. The project planning and business-
blueprinting phase should be executed onsite. These phases require close and heavy interaction with the
business users for understanding the requirements. Since they are critical to the success of a project,
doing them at onsite mitigates the associated risks and also helps in establishing a mutual confidence for
carrying out the offshore activities.

Starting with the realization phase, various activities can be done offshore. The extent to which these
activities can be executed at offshore is dependent on several factors that are discussed in subsequent
sections.

Implementing SAP BW


17

Figure 7: Offshore executing model for a baseline BW implementation using the ASAP methodology

The above model is for a baseline BW implementation. The percentage wise split of the major
activities in the realization and later phases is shown in Figure 8. The various specifics of a BW
implementation such as the type of implementation and scale of the program will require the
model to be suitably modified to get the maximum benefits with manageable risks.

Implementing SAP BW


18

Figure 8: The percentage wise split of the offshore component for each phase of the implementation
Implementing SAP BW


19

Glossary

BW: Business Information Warehouse
OLTP: Online Transaction Processing
ASAP: Accelerated SAP SAPs implementation methodology
Business Blueprint: ASAP Implementation phase primarily referring to the requirement analysis related
activities.
Realization: ASAP Implementation phase primarily referring to the configuration and development
related activities.
ABAP: Advanced Business Application Programming, development environment in SAP
InfoCube: Used to store information in BW in a multidimensional format
Business Content: Standard ready to deploy content delivered by SAP

References

1. mySAP Business Intelligence (http://www.sap.com/solutions/bi/)
2. Chief Executives define their own data needs, J ohn F Rockart, Harvard Business Review
3. Management Information Crisis, D Ronal Daniel, Harvard Business Review
4. Phasing SAP Business Information Warehouse Implementations by Sandeep Kumar
5. Supporting SAP Offshore by Byron Miller and Stephanie Moore - Giga Research
6. Offshore Data Warehousing : Proof Points by Lou Agosta - Giga Research

Implementing Sap BW With Sourcecode Inc.: Version 2.0 March 2006 ©

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Implementing Sap BW With Sourcecode Inc.: Version 2.0 March 2006 ©

Enviado por

Direitos autorais:

Formatos disponíveis

Implementing SAP BW

with SourceCode Inc.

Você também pode gostar