Implementing SAP BI/BW

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.

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 SAP’s complimentary tool Business Information Warehouse. The Gartner Group estimates that “By 2008, more than 80% of SAP’s 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 maysoon 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 shouldn’t be viewed as a stand-alone data warehousing implementation, but one that can act as the foundation of the organization’s 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

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.

Key Success Factors:

• 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

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.

Key Success Factors:

• 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

 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 it’s 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

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

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


It’s 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 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.

 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.

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 below. 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.

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 it’s 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.

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

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.

 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.


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

 Glossary

BW: Business Information Warehouse
OLTP: Online Transaction Processing
ASAP: Accelerated SAP – SAP’s 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’, John 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

v,bm