bw strategy - how to create enterprise wide strategy

How to create a strategy for an enterprise-wide

implementation of SAP BW GLOBAL ASAP FOR BW ACCELERATOR

SAP BUSINESS INFORMATION WAREHOUSE

Creating concepts for enterprise wide SAP BW implementations

Version 2

BW STRATEGY ASAP FOR BW ACCELERATOR

©1998 SAP AMERICA, INC. AND SAP AG


Table of Contents

HOW TO CREATE A BW STRATEGY FOR AN ENTERPRISE WIDE / GLOBAL IMPLEMENTATION OF SAP BW ........................................................................................................................................................1

GLOBAL ASAP FOR BW ACCELERATOR ........................................................................................................1 TABLE OF CONTENTS................................................................................................................................3

1 PURPOSE OF THE PAPER ..................................................................................................................4

2 WHAT IS AN INFORMATION MODEL? ...............................................................................................4 2.1 BUSINESS INFORMATION REQUIREMENTS...........................................................................................4 2.2 THE DESCRIPTION OF INFORMATION SUPPLY CHAIN ............................................................................4 2.3 SAP BW BUSINESS CONTENT IS THE BLUEPRINT FOR YOUR INFORMATION MODEL ...............................5

3 SAP BW STRATEGY OVERVIEW........................................................................................................5 3.1 SCOPE OF SAP BW IMPLEMENTATION STRATEGY ...............................................................................5 3.2 TASKS ..............................................................................................................................................7 3.3 DELIVERABLES ..................................................................................................................................7 3.4 SCOPE OF SAP BW WITHIN AN ENTERPRISE WIDE IT LANDSCAPE ........................................................8 3.5 TEAM REQUIREMENTS........................................................................................................................8 3.6 METHODOLOGY OF SAP BW STRATEGY AND SAP BW IMPLEMENTATION.............................................8

4 STRATEGY BLUEPRINT ......................................................................................................................9 4.1 SUMMARY .........................................................................................................................................9 4.2 EXECUTIVE WORKSHOPS.................................................................................................................10 4.3 BEST PRACTICE & EXAMPLES ...........................................................................................................12

5 PROGRAM DEFINITION AND STRATEGY STUDY ..........................................................................16 5.1 SUMMARY .......................................................................................................................................16 5.2 INFORMATION MODEL ......................................................................................................................17 5.3 SYSTEM ARCHITECTURE RECOMMENDATIONS...................................................................................24 5.4 IMPLEMENTATION APPROACH...........................................................................................................28 5.5 CHANGE MANAGEMENT STRATEGY (COMMUNICATION STRATEGY).....................................................32 5.6 PROGRAM MANAGEMENT APPROACH ...............................................................................................32 5.7 RISK ASSESSMENT..........................................................................................................................32

6 PROGRAM CHARTER........................................................................................................................32

7 APPENDICES......................................................................................................................................33 7.1 APPENDIX I: EXAMPLE: GLOBAL AND COMMON ENTITIES (HERE: ORGANISATINAL) ................................33 7.2 APPENDIX II: SYSTEM ARCHITECTURE DESIGN CRITERIA....................................................................34 7.3 OVERVIEW: SAP BW VERSION 2.0B ARCHITECTURE........................................................................35

©1998 SAP AMERICA, INC. AND SAP AG

1 Purpose of the paper Starting an enterprise-wide SAP BW implementation requires strategic planning. This paper outlines the most important steps that should be followed when creating an SAP BW strategy. It describes conceptual considerations. It is targeted for project leaders for large SAP BW projects/ and decision makers that are involved in creating strategies for the implementation of enterprise wide or global implementations involving SAP BW.

2 What is an Information Model?

2.1 Enterprise-wide Business Information Requirements and data structures One important deliverable of the SAP BW strategy will be what we call an integrated information model. The information model is the foundation for a successful rollout of enterprise wide integrated analytical applications.

Process engineering projects focused on efficiency of processes, sometimes forgetting what kind of people are involved and how the people can effectively measure the effectiveness of the processes in order to continuously improve them. Information modeling (The process of creating the Information modeling) puts people in focus. It looks at how people are using information to fulfill their roles within an enterprise.

One dimension of the Information model is the documentation of business strategies and objectives, the main processes (value chains) , and the main players (people and roles) controlling the process, the information needed for the players to monitor the processes. The results of the analysis are then documented with performance indicators (measures that measure either processes or strategies/goals or satisfy legal requirements) and the main objects (dimensions) of the performance indicators.

The business requirements then should be summarized in a data model and the definition of global (enterprise-wide) data requirements. The enterprise-wide requirements are a framework for the SAP BW roll-out and must be considered when implementing SAP BW solutions for smaller units of the company. The other dimension is the Information Supply Chain.

2.2 The Description of Information Supply Chain Another area where Information modeling focuses is the information management process. The information model is a logical design model and explains, how to structure information, where and how to gather information, how to professionally manage information and how to display, distribute or access information from a information manager point of view. The model serves as blueprint for professional enterprise wide information management, and as a communication bridge between business and “information technology”.

©1998 SAP AMERICA, INC. AND SAP AG 4


The information model should describe how information flows through the enterprise environment (including customer, vendor and market) and how information is used by the receivers. There are many analogies that can be used for “information management processes”; One that we found very useful was that of a newspaper or news agency. If you compare your company’s information management with the processes of “professional” information providers, such as a news agencies, where information really is the main and key product, it might help to make people understand what you want to discuss with them.

In summary: The information model describes the main business goals, main business processes, key peoples roles and tasks within these processes, explores the performance indicators and explains the data and information flows in the enterprise environment. It also explains the information technology used to streamline the flows of information, where data comes from and thereby defines the information supply chain.

2.3 SAP BW Business Content is the blueprint for your Information Model The SAP BW has not only the functionality of a data warehouse. It also comes with business intelligence in form of business information models. SAP has already “created” an enterprise wide information model, with pre-configured performance indicators, reports, information models and communication and extraction logic from the mySAP.com applications and industry specific market data. Effectively you should always use the business content as a reference and use it closely as possible within your enterprise wide projects and enhance business content when required. By using Business content you make sure that you follow a road that does not end in “stove-piped business area data-marts” (not integrated information islands), but rather use parts of a model that is integrated and covers most of your business processes. It is the Business content that enables you to create an enterprise wide warehouse step by step.

3 SAP BW Strategy Overview

3.1 Scope of SAP BW implementation strategy We recommend to implement SAP BW iteratively across the entire enterprise. With its business content SAP BW not only has “ready to show” reports and information models, it also delivers consistent enterprise wide meta data (data on data) that form the basis of an enterprise wide solution. SAP BW business content will enable you to realize a true iterative approach. The business content makes sure that if you start a analytical application rollout (e.g. in the supply chain management area) that it is integrated at the end with other areas (say Financials) that you like to cover later in the implementation project cycle. When using the Business Content you can focus on one analytical application area without ignoring the whole picture. This whole picture has been modeled already for you as the SAP Business Content.

However, it is important for an roll out to have a clear picture of the “whole” picture of your enterprise scope and to analyze carefully what should be realized with an enterprise wide SAP BW

The strategy described below is based on the assumption that SAP BW will be rolled out building solutions for users in different business areas step-by-step. (Business area could be a division, a department, main process, etc.) The strategy develops a plan for a “series of projects” (referred to as program) undertaken by the different areas of the company in order to create the enterprise-wide business information warehouse and serves as a basis for each increment of the SAP BW roll-out within your organization.

The strategy phase should not exceed 15 weeks. Usually it takes 4 to 12 weeks. With every implementation of one application area, the strategy should be revised and “reality –checked.

The methodology can be used to create plans for:



how to roll-out a BW solution within a local company (local enterprise wide) (e.g. complete BW business content within one company (CRM, SCM, Finance, Human Resources)

how to roll-out a BW solution within on business area (global analytical application roll-out) (e.g. Global inventory transparency)

how to roll-out a BW solution across a large, multinational organization .

The complexity usually increases with the size of the company (large organizations, different languages, cultures, time zones, etc.) the strategy can also be applied to “smaller” companies dealing with rolling out SAP BW solutions.

Enterprise wide implementations in large companies face two very distinct environments and thus different information requirements a) the headquarter and the b) the local subsidiary

Usually information needed in headquarters feed strategic and tactical decisions, data tends to be aggregated, the information models are usually simple (from an information structure point of view) and have a narrow scope. The users of the headquarter information are users from the headquarter and from the subsidiaries. The sources of the data are usually the systems of many subsidiaries. However, the headquarter system faces issues like languages, timezones, calender,…(see later chapters)

The information models of the subsidiaries are more complex, data more detailed and information required for a wide range of operational, tactical and strategic decisions. Users tend to be the users of one subsidiary and the sources are local systems. The challenge of the subsidiary is the integration of different analytical applications.

In a perfect scenario the global information requirements are specified before the subsidiary information models are created, and the information models of the subsidiary follow global or common data structures (see later chapters). One benefit of a BW strategy is to find out the main global data and information areas, later driving and influencing every subsidiary implementation.



3.2 Tasks The main purpose of the BW strategy is to ensure a “common” understanding of the importance of information at your company and the strategic weight of SAP BW as a solution for the business. Through the four phases of the creation of the SAP BW strategy, you will understand the information requirements from an enterprise wide / global perspective, you will create an enterprise wide information model (logical design of the solution), you will come up with a recommendation on system architectures, implementation approach, program management to insure integration and make recommendation on the maintenance phases of the SAP BWs in your organization .

Four main tasks are being described in more detail:

Strategy Blueprint

Identify business opportunities. Find out if the organization is ready for the implementation of an enterprise-wide or even global business warehouse. Explore the possibilities and opportunities to build solutions for the entire company using SAP BW technology and check against the SAP BW solution map. Find out about strategies, goals, business processes, information flows and performance indicators. The Blueprint phase main ingredient are the Executive Workshops focusing on information modeling, in which the Strategy Teams:

Get commitment for a global / enterprise-wide SAP BW project. Determine the business case and enterprise scope for a global / enterprise-wide business information warehouse and become familiar with the organizational information supply chain as well as high level business requirements for an information model from a business and IT point of view.

Program Definition and strategy study

Study findings of the executive workshop. Draft strategy covering business and IT requirements for the enterprise-wide business information warehouse and information management. Create information model (roles, information needs, information access, information gathering, global information and data model) recommend system architecture, implementation approach and program organization.

Define Program Charter

Definition of projects: goals, timelines, staffing, organization.

3.3 Deliverables The strategy should have the following output:

Documentation of

Business information requirements: Goals, Strategies, Key Processes, KPI’s., Roles, business area organization (one part of the information model)

IT requirements: IT strategy, data sources landscapes, technical solutions, organization

Recommendations on

Information Supply Chain (the other part of the information model)

Globally defined data model (data structures)

System Architecture and SAP BW landscapes

Implementation approaches, timetable of roll-out projects

Organizational recommendations for implementing and maintaining an enterprise wide business information warehouse.

Change Management Strategy (Communication Strategy)

Program Management Approach



Risk Assessment

3.4 Scope of SAP BW within an enterprise wide IT landscape There are 3 distinct roles SAP BW can play in an enterprise-wide implementation:

SAP BW as corner stone of business performance management and analytical applications Here, BW serves as a main “watch tower” of business performance management. It includes pre-configured information models and ready to go KPIs(key performance indicators) Pi’s (performance indicators).

SAP BW as an information warehouse: as high performance data warehouse, as active meta data or master data repository. , OLAP with specifics, front-end for consumer and professional, web deployment

SAP BW as a platform /service provider to other mySAP.com components. BW serves as a platform for strategic planning, financial consolidation, supply chain management cockpit or planning environment.

Obviously , BW can play those three roles simultaneously.

3.5 Team requirements The team drafting the SAP BW strategy will range from 2 to 10 people, depending on the scope and complexity of the business environment.

The team should have: Strategy Methodology knowhow Good knowledge of company Information management , data warehousing Know How Analytical and communication skills Understanding of the business and/or the industry SAP BW Business know-how (Content and Technology) SAP Basis skills

The creation of a BW strategy is both creative and analytical. Usually small teams are more effective than large ones. The team should include members of IT and strategy experts.

3.6 Methodology of SAP BW Strategy and SAP BW implementation When implementing SAP BW on a global scale, this paper can give you directions when carrying out the first phase. It outlines a step-by step procedure and tries to give an overview of tasks and deliverables of an BW strategy.

The “local” or single SAP BW implementation projects can follow the ASAP for BW methodology and this methodology cover more tactical and operational tasks in an SAP BW implementation.

This and other papers you can find on ASAP CDs or online at service.sap.com /BW.



4 Strategy Blueprint

4.1 Summary

4.1.1 Deliverables

The strategy blueprint phase enables you to understand the business from a global / enterprise wide view. You should get an overview of the business, get an overview of the main business processes, the main information needs, how information should is being accessed and how information is being managed. Very important in this phase are the workshops in which you challenge your understanding of your analyses. Potentially prepare demos to show BW to main players.

4.1.2 Tasks

It is an analysis phase and some of the tasks that should be carried out are:

Talking to people, interviewing people, studying material (intra-net, company magazines) Reviewing existing projects: to get an overview of strategy, goals, Main Information needs, benchmarking with industry data, etc. Preparing customer specific solution maps, etc., Analysis on existing Warehouse solutions, BW projects in the organization,

For the preparation of the executive workshops you should:

Gather high-level information on the company’s organizational structure, strategies, objectives, core believes, the company’s core business processes, gather high-level information of key success factors.



Gather first information on the company’s business areas with its user roles, their decision processes and tasks, their Key Performance Indicators to measure the processes (example see slide below). (if it is a global warehousing project: Consider global and local data, information)

Gather high-level information on the company’s IT infrastructure, on the company’s information supply chain: The flow and storing of data within the company (Data Sources, consistency, availability of Information, existing solutions, “information islands”, Information delivery process and data access strategies)

Identify key business processes and technical constraints., Benchmark data against industry trends, Compare the key performance indicators found with Best Practice Models from SAP (Industry Business Content), Identify preliminary opportunities for improvements of the current information model.

Prepare a high-level opportunity assessment and first ideas, how to create a SAP BW strategy and how to implement an enterprise-wide warehouse.

Prepare a presentation for the Executive Strategy Workshop. The presentation in front of senior management serves as a first milestone: the decision point for further steps.

4.2 Executive Workshops

4.2.1 Deliverables

Create vision and goals, understand scope, benefits and risks

It is very important to have a clear vision of what can be achieved from global and/or enterprise wide analytical application implementation. The first step towards an integrated business information architecture is to find out whether there is the need for a business information integration. One of the most critical success factors in enterprise warehousing is not only that there are clear objectives and good reasons and benefits for of a global information management, but also whether the organization agrees to the objectives and sees and understands the benefits of it.

Get involvement and commitment from management of all involved business areas

If there is no strong commitment from the organization, then the mission “To create the framework for global and enterprise warehousing “ is bound to fail. Communication, convincing, and selling is one of the most critical issues especially in a global implementation. Indeed, the workshop is a very good opportunity to “sell” the vision of integrated enterprise wide analytical application.

One customer defined “Global Analytical Application” as a top priority next to the “Global Process Reengineering” and “e-business”. Not only the IT departments, but cross functional teams were set up to come up with a framework for best practice processes across the enterprise and for “best practice “information” .

Create awareness for Information Modeling and Information reengineering

There is a big difference in “Understanding what the business users want to get out of a system” and in “Understanding how information could improve the entire business system”. If you only “create reports” that the people want to see, it is likely that you will create value added from an IT point of view. You will more or less focus on the 2nd big issue: the information Chain and undoubtedly will create value by streamlining the information supply chain with implementing BW. Focusing only on the reporting will not open the benefits that real information modeling could give you.

There is an interesting quote about data that could be turned into

25% of the enterprise data we know that we know

25% of the enterprise data we know that we don’t know



but 50% from the enterprise data we don’t know that we don’t know (Quote)

By challenging the top executives and business decision makers to rethink how they look at information and how they deal with information today, you can trigger an information engineering process. In this stage the information model is restricted to the major areas of the company, the main and most important information processes and key performance indicators of your company and industry. Over the implementation cycles of the SAP BW this information model will be constantly refined. A framework should be established, setting scope and high level instructions for further detailed design and data architecture.

Draft first solutions to be discussed

After drafting an high level information model, you can create ideas of how the information supply chain might look like: meta data , master and transaction data architecture, system architecture, data flows and data access should be considered. Also it is very crucial to cluster data / information as globally or locally relevant. (see appendix for list of typically global / local elements). Also you should prepare and create awareness for the methodology you are using for implementing BW.

4.2.2 Tasks

Conduct the executive workshop The key areas are to discuss information models (business areas and processes, user roles and performance indicators) including the information supply chain (how is information gathered, managed and disributed). Previously gathered information are presented, discussed and verified during the workshop. Any revisions necessary should be documented and included in the final results summary. The detailed schedule for the workshops as previously defined might include separate sessions, breakout sessions, common sessions to reconcile statements and a session for the final agreement on all the major results. The strategic decisions agreed upon in the workshop are documented and taken as input for the study. The main topics of the Executive Workshops should be conducted with business managers and IT management involvement: Business goals and benefits of a global warehouse implementation, success factors, business areas (geographically and/or departmentally), user roles, business processes and key performance indicators, future information supply chain and architecture options are stated. From that you can derive a first draft of a high level business scope, implementation strategy and system architecture Output of these workshops can be “core statements” on the information model, key performance indicators etc. e.g. “We will not have regional warehouses. ” or The top ten goals are .... and are measured by ..... “. For our company we will globally only collect detailed information on the top ten products” etc.

You should determine the process necessary to gain approval of the key strategy elements. In some cultures, it may only be necessary to gain a verbal consensus during the workshop. From these workshops you should get a first picture of what the scope of the enterprise project could be, where are the biggest opportunities are, where the gaps are in the company’s information supply chain and have an overview of options where and how to implement BW.



4.2.3 Organization and Staffing of the Workshops

Most of information system projects fail because of the lack of commitment of top management level. “Information systems are not mission critical”, “Somehow we will get to the information”, “I thought we are getting the information out of our process systems”: Those replies are often found at management level and usually it is IT (information technology department) that has to provide ways how to deal with information. If information is treated as a strategic resource the tasks of gathering data , creating and distributing information across the enterprise is a vital business process that should be very carefully modeled and discussed not only by IT . Like a sales / purchasing process it must be streamlined, manageable and most of all it is one of the core business processes in a company, not merely an IT process.

The executive workshops should give you the opportunity to challenge management regarding information, position yourself strategically and give you the feeling if your project has at all a chance.

How should the workshops be organized and who should attend the meetings? The workshops should be split up according to your findings in the first steps of your business analysis. Usually the business areas are very obvious to all people in the organization. (Business areas could be divisions, departments, processes, etc.) As example take a split according to main processes: “Customer Relation”, “Supply Chain”, “Finance”, “Human resource”, …

Top management should nominate so called “information owners” for these “areas”. They should be close to senior management and be respected by others. Since the information model also captures the business goals (trying to measure them later on!) and visions, the workshops should be close to those creating and communicating the goals and vision

The information owners can then later be appointed sponsors or project leaders of “local” projects that will be driven by your strategy and global definitions.

The workshops should be rounded up by single interviews with key players in the company that deal with information, asking where problems exist with the way information is accessed today. They could be secretaries, assistants of executives or even executives themselves. Please see an example time table and agenda proposal (next chapter)

4.3 Best practice & examples

4.3.1 Time table and agenda for the workshops (An example)

Short Planning phase

(Interviews with sponsors and leaders of units, invitations, Agenda, etc)

Evening Before: Executive Dinner

1st day : Workshop KickOff

(Sponsors, Unit leaders, Info Owners from units/organisations, CIO,

StrategyProject Team, Moderator) Agenda:

BW Strategy Goals, Intentions (Sponsors)

Introduction and Expectations (Leaders of units)

• Introduction of unit and introduction of information responsible

• High level expectations, high level information requirements

Group Work (Info Owner(s))

Where are the problems with information supply in the unit?



How does the ideal information supply chain look like in the unit?

Presentations of work

Group Work

Biggest Challenges?

How should a High level global information supply chain look like?

(Mixed teams)

2nd …. 4th day: Interviews: Unit 1,2,3…

Interviews with Info Owners and important information consumers : Info-Owners and Project Team: Processes in Unit, Roles, Tasks, KPIs (60 –120 minutes) (see guideline for Interviews)

Project Team : Documentation and Open questions 2-3 hours

Interviews: Review of documentation and open question clarification (60 min.)

IT-Workshop:

Landscapes, Organisations, Current solutions, strategy (Project Team, CIO, Global Teams)

Last day: (participants like on first day) ½ day

Presentation of findings (Project Team)

4.3.2 Guideline for Interviews with Info Owners

Introduction

Interview-objectives and Interview Process,

Introduction of participants

General questions

Decribe Unit/Organisation within corporation

Describe main processes in unit/Organisatinon

What are you doing and what are your taks?

Important topics/ objectives of unit/org.

Information requirements?

What are the main challenges of the unit/org?

What information are needed for doing your job, measuring the success?

What decisions do you have to take? How often?

Strategic, tactical, operational,

Measures/Products/Customers?

Goals of organisation, unit?

How do they fit to global company wide goals?

Can you quantify the org. goals?



Name the 5 Top KPIs

Can you classify the KPIs?

Master data key figures, process key figures?

How are problems, deviations measured?

Who are the most important customers (internal/external) of your oranisation?

Who are the most important „vendors“ of your organisation?

What are the products/ services of your organisation?

Reporting-Requirements

How up-to date should the information be? (Year, Month, Day, real-time, ...)

How often do you need them?

Characteristics

What are the basis entities (Customer, Material,.....) for the analyses?

Dimensions

What views on the KPIs do you need?

History/ Future? Date

Do you need past data, future data (planning)

Do you need to document historical data?

What standard reports, analysis do you carry out or do you produce routinely?

Examples?

Ad hoc reports?

What else would make sense? How can they be we improved?

Drill down

What sequence of drill-downs do you need?

Output

How are information displayed; distributed, sold

Layouts, Medium?

Data sources

Do you know where the data sources are? From Where do you get the information?

Are there problems with getting the right information?

Authority

Can you group users in your organisation: Occasional, Frequent, Power and can you estimate %?

Can everyone see everything?

Expected run time of analysis

How long can you wait for information (seconds, minutes, days,...)

End

What success factors should a change in the information systems have?



Short Summary

Short desciption of next Stepps

Thank you

4.3.3 Documentation of key findings of the Workshop

Examples how to document business areas for the business information warehouse, processes and roles, their tasks and performance indicators:

Vision of an information supply chain.

• How many sites/ business areas would have to have access

• How many and what sites (systems) will give information

• What sites would be the “owners” of the BWs

• Who needs to be involved in a global project

• Is data harmonization to be done, Has it been carried out?

• Who would be responsible of data) .

4.3.4 Direct or indirect business benefits/ Opportunities with SAP BW/ Areas that can be covered during the workshops BW ENABLES INTEGRATED, FAST, RELIABLE, TIMELY AND CONSISTENT REPORTING AND HELPS MAKING FAST AND URGENT DECISIONS IN AN RAPID CHANGE OF MARKETS AND COMPETITION. BW BENCHMARKS BUSINESS GOALS BY STANDARD KPIS (KEY PERFORMANCE INDICATORS) OFFERED BY BUSINESS CONTENT. BW INTEGRATES AND STANDARDISES A COMPANY‘S INFORMATION GATHERING AND DISTRIBUTION AND FACILITATES THE HARMONISATION AND GLOBALISATION OF DATA AND INFORMATION .BW ENABLES THE INTELLIGENT USE OF LARGE DATABASES THUS HELPING ANALYSING ALL INTERNAL AND EXTERNAL RELATIONSHIPS (E.G. INTERNET



PAGE HIT ANALYSING) CUSTOMER RELATIONSHIP MANAGEMENT, SUPPLY CHAIN PLANNING AND MONITORING, DECISION SUPPORT, MARKET ANALYSING ETC. 1. TCO EFFECT (COST REDUCTION FOR PLANNING, IMPLEMENTATION AND OPERATIONS INFORMATION SUPPLY CHAIN. BW HELPS TO STANDARDISE THE INFORMATION SUPPLY CHAIN THUS PINPOINTING AT WEAK OR EXPENSIVE SPOTS IN THE COMPANY’S INFORMATION GATHERING AND DISTRIBUTION PROCESSES AND SYSTEMS. EXAMPLE: IN A LOT OF COMPANIES THE INFORMATION GATHERING AND DISTRIBUTION IS DONE INDIVIDALLY BY EVERY DEPARTMENT SEPERATELY, USUALLY SYNERGIES ARE NOT EXPLORED. “ISLANDS OF INFORMATION ARE BUILT”. BW CAN THEREFORE BE USED TO REDUCES VARIOUS INTERFACES, BRINGING DOWN COSTS OF MAINTENANCE, COMPLEXITY AND INCREASING TRANSPARANCY. BUSINESS INTELLIGENCE.. IT HELPS TO INSOURCE SOME KIND OF INFORMATION THAT HAD TO BE BOUGHT EXTERNALLY (EXAMPLE: CUSTOMER SATISFACTION SURVEYS WERE ALWAYS CARRIED OUT FOR TRAINING, THE EVALUATION OF THE FEEDBACK WAS DONE EXTERNALLY) IT BUILDS THE BASIS FOR BUSINESS INTELLIGENCE. BUSINESS CONTENT. BW COMES WITH BUSINESS MODELS AND PRECONFIGURED KPIS IN ORDER TO EASE IMPLEMENTATION IT RESOURCE LEVERAGING : RUN SAP BW WITH EXISTING RESOURCES, LEVERAGE SAP BASIS SKILLS ,LEVERAGE KNOW HOW FOR HARDWARE, LEVERAGE KNOW HOW FOR OPERATING SYSTEM, LEVERAGE KNOW HOW FOR DATABASE MANAGEMENT ,LEVERAGE R/3 BUSINESS KNOW HOW ,LEVERAGE PARTNERSHIP TO IMPLEMENTATION PARTNERS, DIRECT OR INDIRECT CBI EFFECT

BUSINESS PROCESS BENCHMARKING: IT HELPS TO MEASURE VALUE CHAINS ACCROSS THE COMPANY. PROCESSES AND ACTIVITIES TO OPTIMIZE THEM.

5 Program Definition and Strategy Study

5.1 Summary

5.1.1 Deliverables

The strategy should entail the following topics:

Executive Strategy Workshop Results

Information model: Scope and Information Supply Chain

System Architecture,

Implementation Approach

Change Management Strategy (Communication Strategy)

Program Management Approach

Risk Assessment

5.1.2 Tasks

The processes involved in this phase are: Gather further information, Interviewing people in the organization, analyzing and coming up with ideas. There are management techniques that support these tasks. Since they are not SAP BW specific, we will not go into a detailed discussion.



The SAP BW strategy is likely to be a company specific solution. There are some tasks and cornerstones, however, that we would like to discuss: In the next chapters we will focus on how to structure possible outcome, give ideas on potential content of your strategy and provide a framework for your strategy.

5.2 Information Model Within this task you will detail out and enhance the findings of the workshops and your analysis works done for the workshops. You will have to carry out interviews with key people within the likely scope of the implementation. By defining the information model you create a logical design of your solution. You also set the scope of the implementation.

5.2.1 Analysis of the organizations/ Regions/Countries

One important scoping criterion are organizational structures within an enterprise. An enterprise is usually divided into different sectors, based on products, processes, geography, human resource factors or just plain history. Usually responsibilities of the executive boards are good first indicators of a structure of the enterprise. Sometimes business areas are spanned across these sectors, forming n-dimensional matrices of responsibilities in the enterprise. They should also be considered when setting up the executive workshops, but are also a well suited for scoping of a SAP BW implementation.

Questions for this step are:

How global the SAP BW implementation will be. Will it be cross-divisional, stay within the divisions?

How will the rollout be: Simultaneously, one after the other. Obviously if there are many synergies, or the reporting requirements are similar, a very coordinated (cross divisional) rollout sould take place.

If there are processes covering different business areas or sectors, it becomes obvious that data should be shared across the different areas. These data are usually relevant for enterprise wide and global information systems. In order to benchmark business areas it is necessary to share information globally. An analysis of the organization is essential for a better understanding of the business, but also for distinguishing between global, common and local data and information.

5.2.2 Process analysis

The process analysis is a 1000 ft picture of the processes that take place in the value chains of a company. Of interest are processes that span organizational units. Note them down as global processes. (example = consolidation of financial data for creating legal documents)

You should also find out so called “common”, i.e. best practice business processes (example unified management reporting) These are processes that are identical in different organizational units. (e.g. the management reporting in different countries.

From a high level and theoretical point of view, you can differentiate enterprise internal processes and relationship centric processes. (processes, that are focused on relationships). The relationship processes can be divided into two areas. Processes that take place in the more immediate environment of the enterprise (environment I) and processes of the enterprise II (environment I: close relationships like customers, partners, investors and vendors and environment II: competitors, market information). The value of an enterprise wide business information lies in the integration of information coming from all “environments”, Since eventually all relevant information should be found, the scoping is very important for the iterative cycles or phases of the warehouse. Many customers start looking first at the internal, then relationship centric processes, since the SAP BW business content has focused on information models of internal processes.



In the strategy phase you will only focus on the global and the common (best practice) processes, since they are an indicator that will require or share global information and data. The common processes usually give you a good hint of the strategic direction of the company. (A manufacturing company will usually have implemented best practice manufacturing processes and systems, a marketing company will have implemented guidelines for their marketing, etc)

5.2.3 People and Roles Analysis

On a very high level you should now be able to assign people to the global and common processes. Define their roles and their information needs. What types of users are likely to access data of the global information warehouse(s) and can you identify certain information needs of formatting needs for the information (offline vs. online reporting; consumer or analyst, etc) .

5.2.4 Information analysis

5.2.4.1 Dimensions of the key performance indicators

If not already done in the workshops you must define global or common KPIs for the identified global and common processes, i.e. how are the processes measured. They can also be derived from enterprise goals and enterprise process measurement.

Those KPIS must be described and owned (see below) . From an data modeling point of view an even more interesting part of the Kpis are the objects are the dimensions (objects) of the key performance indicators. The definition (meta data) and the data contents (data) of those objects will hold the data model together and must be designed with care.

Example: Profitability as a key performance indicator can be measured by “customer, customer group, product, region, etc. ) Those dimensions must be defined and communicated, since they could/should be consistent across the information system enterprise wide..

5.2.4.2 Global , Common and Local Data/ Information

Global information: Global information is information needed or produced by global or common processes. Usually defined and needed by the corporate headquarters of an organization. Examples: global processes such as financial consolidation (tax, legal reporting. The financial and controlling departments are sophisticated in this area and know the requirements. They are well prepared for global requirements in terms of global data definitions, interfaces, accuracy and granularity of data/ information needed by the headquarters.. Usually global information needs are fairly aggregated (time and object wise. Purely global information models are usually simpler compared to local, operational information needs and models.

Definition: Global data entities are entities that everyone shares, since they are part of a global reporting process. Structures (Meta Data) and contents should be defined by the headquarters.

Best practice (Common) information: Best practice information is not needed globally, nor needed locally. Common information would greatly increase transparency of processes across several business areas. If data of process X in area Y is stored according to common rules, information users can “understand” the and benchmark process Y. Mayor business benefits can result from best practice information shared across the company. Unfortunately, it is in these (usually locally defined) business areas where resistance to follow a “common” model is strongest. The “best practice” information is the real challenge of the information model. It has a weak lobby (neither global nor local) and if applied converts hidden data to transparent information...

Local information: Local information is only used and shared within one business area/ unit.

In your strategy you will focus on what KPIs and objects should be globally defined (structures and content: Structure: i.e. Material number = “18 digit number” and Cotent: “Will always start with X…”

See appendix I on list of global information.



5.2.4.3 Information Sources Analysis

Where are the source of information stored? Are their any global sourcing systems or strategies: What are the leading systems (e.g. for master data, currency exchange rates, calendars) but also are their common sourcing: Sales data only from R/3 SD or COPA?

At this stage you create a list with potential source systems (countries, types of systems, releases, expected changes of the systems, contacts) and global sourcing strategies.

5.2.4.4 Information Access Analysis

One information model decision is to determine whether global data should also “make” sense to local information consumers already at the source of creation, i.e. should global data converted into information at the source of origin or should it be converted into information at the center. This has implications on responsibilities and data quality. How will users want to access the information?

5.2.4.5 Information types and layers

You should cluster information based on who is using the information and what kind of decisions can be supported by the information: What information is strategic, what information is tactical and what information is operational. Usually this is important for the system architecture later and design criteria such as “how data is accessed”, “presented” and “stored”. You should specify what type of data is needed and relevant for what stage in building the global warehouse.

5.2.4.6 Time

According to the types of information make sure you know how long in the future and how long in the past information is relevant to the users. This will be a very good indicator for estimation of data volumes.

5.2.4.7 Responsibilities

The responsibility of information has different meanings and involves different people. Who is responsible of the definition of information, i.e. the metadata, Who is responsible of the quality and correctness of data, who is in charge of the changing / maintaining information/ data; Who is responsible of accessing the data, etc. Already now you should specify on high level the responsibility levels of the different types of data and information. E.g. local or global responsibility, IT or departments, etc. The analysis of responsibilities will later in the physical implementations be an important strategic frame for authorization levels.

5.2.5 Info Model: Information Requirements

The outcome of all these analyses will be your first part of the information model. Your information model will focus on business needs, business strategies (outcome of workshops and interviews) You will have analyzed the scope of potential BW implementation(s) , focused on key processes and roles in the enterprise. It will entail some recommendations on global or at least common data or information needs.

One mechanism how to structure the information are key performance indicators that ware usually derived from business goals in the business areas. One possible way to structure your outcome could be:

Scope (organization, business areas) -> Company wide Strategies ->Company wide processes and Key people (Key tasks and Objectives) ->

Company wide key performance indicators (KPIs) -> Dimensions of the KPIs

For the KPIs and their dimensions note down: Time requirements, Responsibilities, Ownership, strategic or operational usage of the data.



5.2.6 Info Model: Information Supply Chain

The more technical aspects of the logical design we refer to as the information supply chain. It focuses on:

Where does data/information come from. How is the data sourced, staged and kept. How are information accessed and used. For all components there must be strategies on how to implement them, and how to technically design them (physical design) In this phase you will need a good overview of what you would like to achieve. A picture will be most useful that can be understood by all future BW project leaders, making them understand that they are a part of a total picture.

Components:

The main components when creating an information supply chain are:

Access to information (Front-end)

Staging and Keeping

Sourcing

Meta Data

Authorization

Master Data

Transformation processes

Global data model

For each component there might be a different strategy how to implement it.

Example: One example of how information will flow through the enterprise:



5.2.7 Information Layers

When looking at one BW instance we can find layers of information granularity, where data is consistently stored.

DATA ACCESS LAYER: (user , role oriented)

INFOCUBE –type layer (cumulated, subject oriented)

ODS type - layer (detailed, subject and process oriented)

OLTP type - layer (very detailed, document oriented)

MASTERDATA & Hierarchies ( enterprise wide , shared across the INFOCUBE and ODS layer)

METADATA LAYER ( enterprise wide , shared across the INFOCUBE and ODSlayer)



Information layers might also be different from the typical user access point of view. Usually a

manager is more interested in subject oriented data, where a clerk is more interested in the single transaction data. Sometimes, however a drill trough is required from one layer to another. Therefore BW has the possibilty to drill down and through these layers. The first consideration when designing a BW one must check which information requirement can be/should be satisfied by what information layer. Some of the considerations are:

Marketing manager

Sales representative

Sales representative.

Sales representative

Sales clerk

Infocubes

ODS

Sales Order Item Status: Why was the customer granted a special rebate?

Sales Order Status: How much has been delivered for an entire sales order / customer

Has this customer ordered more /less compared to last year?

OLTP

Master data Meta

Data

Accuracy of data (rule of thumb, INFOCUBE layer should only contain daily accuracy)

Detail of data: Document or item numbers and information should not be modeled as dimensions if possible

Type of reporting: Ad-hoc vs. standard reporting; multidimensional vs. flat reporting

Type of user: information consumer, occasional user, power user

Numbers of users

Technical restrictions-performance,

Functional restrictions

It is very important to understand that with SAP BW the boundaries between the layers will vanish, since SAP BW gives the users the possibility to drill down to each of the information layers. It is this special feature which puts a lot of importance to the design of the company specific information layers. In an SAP BW design you should have a good understanding and overall strategy as to what level to information granularity you want to employ for what types of requirements.

5.2.8 Information integration

Looking at an entire enterprise information model, you must consider other components in the IT landscape: systems like ERP software , CRM and e-commerce software systems. There are true integration benefits if you can define a common strategy involving all enterprise related components (not only for BW) BW comes with a very close link to other my.SAP.com components. Please consider other strategies (R/3, B2B) and align your BW strategy with them. From an information point of view it is important to know the sources of the information (data) and the potential systems that access the BW data. There might be information requirements that you did find during the interviews and workshops that you have carried out. Later you will want to think about drill through mechanism from one system (e.g. BW, reporting data) to another system (e.g. B2B system, operational data) .



5.2.9 Global Issues of the Information Model

5.2.9.1 Ownership of meta data and data

As already stated, the clear assignment of responsibilities are very important. The larger a system will get, the more important the assignment. On a global scale you will have to deal with many levels and many different levels of the company hierarchy. It is vital to have a good strategy of how responsibilities are structured and managed :

• Ownership of key performance indicators and their dimensions

• Ownership of definitions

• Ownership of changes

• Responsibility of data quality

• Responsibility of changing data (esp. Master data)

•

5.2.9.2 Languages

SAP BW is available in many languages. As of SAP BW 20 b SAP BEW supports

English, German, French, Spanish, Portuguese, Japanese, Korean, Dutch, Italian, Danish, Norwegian, Swedish, Finnish, Czech, Russian, Hungarian, Polish, Simplified Chinese, Traditional Chinese.

5.2.9.3 Cope Pages

One SAP BW system can only support one code page. One codepage holds a certain amount of letters of different languages. It cannot contain all letters of all languages.

5.2.9.4 Different Time Zones

In a global warehouse you will have to deal with different time zones. Your models will have to cope with issue: Definition of the day barrier, Data Capture of “global” and local time and dates

From an SAP BW technical point of view there are no problems with time zones

5.2.9.5 Calenders

Within the information model check if different calendars are in use and how you want to synchronize them. Since calenders can be upoaded from any R/3, a BW system should chosse which Source system is the “calender” master of the BW.

5.2.9.6 Currencies

Currency translation can occur in a SAP BW at the time of updating data into SAP BW or at the time of reporting. As with calenders a SAP BW can upload currencies and their exchange rates from any R/3 system connected to the SAP BW system. If there are many systems connected you might want to choose a leading master system for currencies.



5.3 System Architecture Recommendations

5.3.1 Deliverables

Within this part of the strategy you will give recommendations on the physical design of a BW development landscape and a SAP BW productive landscape. You also will give recommendations how to use the components of BW for the different types of information you have analyzed in the previous tasks.

5.3.2 Tasks

Considering input from the previous tasks you translate your information supply chain vision (logical design) into a physical design. You take the input received in the executive workshops in order to align physical design to your business and IT strategies. You must have strong technical knowledge of systems in general and BW in particular.

5.3.3 SAP BW Development vs. Productive Landscapes

.SAP recommends to have for each productive system handling one information layer at least one development and consolidation system.(Please refer to SAP BW ASAP Accelerator on Correction and Transportation )

When designing SAP BW landscapes it is important that you should differentiate between a development landscape and a productive landscape. One could have only one global development and consolidation system, however many productive SAP BW systems. To increase integration efforts in the development of an enterprise wide SAP Business Information Warehouse, a central (or at least centrally controlled) development system makes sense.

5.3.4 SAP BW Landscaping

5.3.4.1 Single SAP BW Architecture

It has always been a good strategy to design a large system first without looking at system boundaries. As a rule of thumb one should pretend to design all the SAP BW information layers within one BW system, although it is possible to separate it.

Only if there is a valid need you should split the system .There are three (technical) reasons for splitting one system into many systems performance, authorization and different languages (i.e. cope pages) (see Global ASAP for BW Accelerator: Technical considerations for enterprise wide SAP BW implementations) Mostly, however, it is because of political reasons, that decentralized solutions are favored. Please check appendix II for System Architecture criteria.

There are “integration” benefits of central SAP BW system: administration and reporting. Administration: Currently (SAP BW 2.0) there are no monitoring tools within SAP BW that are specialized on monitoring data flows across many SAP BW systems, which makes administration more complex. However, there are automation functions that make it possible. Reporting: Although it is possible to drill through the information layers, even when they are separated in many systems, in a pure SAP BW Bex environment you can only log on to one SAP BW system at a time. Users would have to “jump” actively from one system to another.

It is very hard to control and harmonize developments in non central SAP BW systems. There are, however, possibilities to do it. (?) If there are no good reasons, you should always try to have only one global development SAP BW.

If you split the information layers in your productive system, you should split your development system accordingly.



Very often we find BW architectures to mirror the R/3 system architecture in place,

5.3.4.2 Multi SAP BW Architectures

When designing a multi SAP BW landscape of different BW systems, technically , there are essentially two basic building elements (bricks) that can be found in a multi-system BW Architecture:

Consolidation/ Aggregation: Many sources can be consolidated into one single BW

Distribution/ Replication: One BW “distributes” information to more BWs (data mart interface) Both ways can coexist in one BW Landscape. The mortar between the bricks is called Data Mart interface (see Global ASAP for BW Accelerator: Technical considerations for enterprise wide SAP BW implementations).

5.3.4.2.1 Consolidation/ Aggregation Brick

The picture above describes a typical consolidation scenario. Data is being merged from different sources to create a BW (e.g. on a regional basis) to again be consolidated into a global Warehouse.

5.3.4.2.2 Distribution/ Replication Brick



A common warehouse strategy for a Warehouse architecture is called “Hub and spoke” strategy. This strategy describes a typical distribution and replication model. The idea is to form a central “version of truth” (ODS) for data coming from different systems. From this center of truth data is being distributed (replicated ) into different locally owned data marts.

The technical communication between the BW systems is done through the data mart interface. The data mart interface is explained in detail by the Global ASAP for BW Accelerator: Technical considerations for enterprise wide SAP BW implementations

5.3.5 OS/ DB

The following databases support SAP BW.

Oracle, Informix, DB2/400, DB2/UDB, DB2/390,MS SQL Server, SAP DB

The following OS support SAP BW:

HP UX 11.0, AIX 4.3.x. (x>=2) Reliant UNIX 5.44 and 5.45, Tru64 UNIX 4.0D, E, F,G, 5.0A, SOLARIS 2.6, 7, 8, Linux /Intel RedHat 6.1 EV, NT 4.0/ Intel, Windows 2000, OS 390 2.6-2.9, OS/400 V4R4,

Please find more about OS ans DB combinations in http://service.sap.com/bw and about other details in www.service.sap.com/dbosplatforms.

On requirements of the frontend please check SAPNotes number 26417

5.3.6 Integration Issues

5.3.6.1 Integration with Other SAP Products • SAP APO Demand Planning writes data into BW system.


http://service.sap.com/bw

http://www.service.sap.com/dbosplatforms


• SAP SEM as of SEM Release 2.0 writes plan data into BW system. • Industry Solutions and New Dimension Products supply business content for SAP BW. • Extractors as R/3 Plug-Ins for R/3 Systems to extract data from R/3 into SAP BW.

5.3.6.2 SAP Business Information Warehouse and mySAP.com

SAP BW is a component of mySAP.com Edition 1 and is shipped as part of this edition with the full functionality, including the R/3 Plug-In.

Release Planning and Maintenance Strategy (see Service.sap.com/ReleaseStrategy)

BW Release

Release type

SAP Basis state Availability Maintenance finish

date Can be upgraded to

1.2A GA 4.0B July 1998 End of June 1999 1.2B

1.2B GA 4.5A Feb. 1999 End of June 2001 2.0A, 2.0B

2.0A CA 4.6A Nov. 1999 End of Nov. 2000 2.0B

2.0B GA 4.6C Aug 2000 End of Aug 2003

Corrections for the SAP Business Information Warehouse are made available in several Support Package types. Corrections for the BW frontend are contained in BW Frontend Patches Corrections for the BW server are contained in BW Support Packages. Corrections to meta data and to extractors (in the R/3 Plug-In) are contained in BW-BCT Add-On Support Packages.

5.3.6.3 BW Extractors

It is important to understand that SAP BW is a separate system. IN the setting up of a SAP BW there are two distinct installation processes. First, the SAP BW needs to be sized, configured and installed. Second, a plug in (often also referred to as “BW extractors”) needs to be installed in the R/3 system. This plug in will enable the optimized interface between the BW and R/3 system.

BW Extractors are supplied with the BW Release. They are part of the R/3 Plug-In and have to be applied to the OLTP system. SAP BW supports all the R/3 default releases that are currently being maintained. All BW Extractors are compatible with the BW Release with the corresponding release number as well as with at least one earlier release.

5.3.6.4 R/3 Plug Ins

The R/3 Plug-In is an R/3 interface that enables the integration of a mySAP.com component (SAP APO, SAP BBP, SAP BW, SAP CRM, SAP SEM) with one or more R/3 Systems. R/3 Plug-Ins allow you to use several components concurrently. Most of the Plug-Ins are Add-Ons - enhancements to the R/3 standard software with additional functions. Plug-Ins supply the components with transaction data and master data in real time.

In the past, Plug-Ins were shipped separately. The R/3 Plug-In (release PI 99 and PI-A 99) introduced in November 1999 replaces the previous individual Plug-Ins, guaranteeing the compatibility of the Plug-Ins with each other and simplifying maintenance. In addition, it will be possible to use components like SAP APO or SAP CRM together with certain Industry Solutions starting with R/3 Plug-In release PI 2000 (PI 2000.1 will be available from May 2000).

The R/3 Plug-In is

• Downward compatible with previous versions - the new version can be installed without requiring changes to existing settings/processes.

• Downward compatible with previous releases of the components - when you upgrade the Plug-In, you can continue to use the existing version of the component.



Possible R/3-SAP BW integrations

R/3 Release BW Server Release

3.0D 3.0F 3.1H 3.1I 4.0B 4.5B 4.6A 4.6B 4.6C

1.2B A A A A A A B E F

2.0A B B B B B B E F

2.0B B 1 C C D D B 2 D D

A = BW-BCT 1.2B B = Use PI-A 99 (or PI 99), both available C = Use PI-A 2000.1 (or PI 2000.1), both available from May 2000 D = Use PI 2000.1 E = Use PI 99 F = Use PI 99, available from April 2000 1 Maintenance of Plug-In ends September 2000

Special care needs to be taken . The plug ins require certain hot package Levels of the R/3 system.

For details please check Service.sap.com/ BW/ release & maintenance.

5.3.7 Sizing

Categories of sizes have been developed for the hardware sizing for an SAP BW system. Those “t-shirt” sizes can only be rough estimates and a guiding path for the exact determination of the sizing and configuration of the hardware needed to support an SAP BW system. There are benchmarks of certain OS/DB vendors available.

Please check Service.sap.com BW Page -.Service & Support – BW ASAP “Sizing and Performance”.

5.3.8 Global Issues

Here only a list of issues that have to be considered when creating a strategy:

Performance, Heterogeneuous data sources environments, Distribution of information, Networks

5.4 Implementation Approach

5.4.1 Iterative SAP BW implementations

The implementation approach of an enterprise wide warehouse is to implement iteratively. Starting with a project or projects in one or two units (countries…), then create a first strategic framework, starting to design global (or enterprise wide, i.e. cross organizational) requirements, implement the next unit, and so on. It does not make sense to create global enterprise wide warehouses in a big bang. It can however, make sense to create templates (globally) and use these templates as starter packs for every local implementation.

5.4.2 Top down vs. Bottom Up Strategy

Fist create a global* (cross business area) warehouse (top), set global standards, create a full and global structure, later create the local (bottom) warehouses.

The Bottom up means: create locals first, then create the global layers.



The “Top Down” enables a rigid implementation of globally defined standards, a well defined set of data and meta data, but faces the problems of a very long start up and preparation phase. It needs the backing and financing of Top Management.

The bottom up approach is a more pragmatic, easy to implement way for the bottom (local) layers of BWs. The challenge of this approach is to monitor and control the adherence to globally set standards and a globally defined meta data structure, especially when it is being implemented decentrally and/or in parallel. The danger of the approach is the lack of consistency among the multiple BW systems and the difficulty in consolidating many BWs into one for instance global BW.

* in a local enterprise wide implementation global = cross unit and local = single unit

Advantages/ Disadvantages Table:

Bottom Up Top Down

Speed of implementation + -

Motivation (locally) + -

Consistency & integration - +

5.4.3 Best Practice Implementation Approach

The best practice approach is a hybrid approach: Implement one or two local BWs (pilots) , create an integration team with the help of the local BW implementation teams, define global information requirements and structures, have a global strategy in place, set up of global templates, then create local implementations with the help of the integration team knowing and respecting global structures/ templates, after each round of local implementation, revise the global design and strategy.

One examples of a mixture of the two basic forms is a distribution of a BW template (with Company defined business content: a set of data models that are predefined) which forms the basis of all BW implementations which combine a minimum of built in standards with the flexibility of the bottom up approach.

The final architecture of a BW system landscape is in theory not coupled with the implementation strategy. In practice the strategy does have an effect on the final result. A typical distribution/replication brick tends to be more the result of a top down approach, the consolidation brick more the result of a bottom up approach. In theory, however, one could also achieve a “hub and spoke” architecture with a bottom up approach.

The final result of a multi site implementation is influenced by many factors and very often not a “black and white” picture. Often compromises have do be done in order to meet changed assumptions and conditions. Nevertheless, it must be stressed that a clear, well understood, and communicated BW System landscape and a plan for implementing it is essential for a successful enterprise-wide implementation.

Depending on the scope we can differentiate between different roll-out models of BW implementations. Here short definitions of the terms are provided.

5.4.3.1 Local data mart

A local warehouse is a warehouse that contains local data for local eyes and uses data from one restricted business area



5.4.3.2 Local Enterprise-wide Warehouse

The idea of an enterprise wide warehouse is to give information from all business areas to potentially everyone in the company or a group of companies in one geographic area. The challenge is the integration of the information, the sharing of data that are relevant to different business areas (could be departmental, functional, divisional, etc.). There should be common business interests between all the areas to share the data across the different business areas. The data in the global warehouse, therefore, must be made common (best practice) across these areas. In some cases data is common already across the different areas, in other cases data coming from the local business areas must be transformed into a shareable data.

5.4.3.3 Global Enterprise-wide Warehouse

The idea of a global data warehouse is to share data that come from different business areas (could be departmental, functional, divisional, etc.) that are also geographically dispersed. There must be many common business interests between all the areas to share the data also across the different business areas. The data in the global warehouse, therefore, must be made common across these areas. In some cases data is common already across the different areas, in other cases data coming from the local business areas must be transformed into a shareable data. Usually the headquarters management is driving global warehouses and are the main users. However, local users should also be allowed, since global warehouses without local involvement are bound to fail, therefore it makes sense to let local users participate and “involve” local implementers .

5.4.3.4 Analytical Applications Roll-out (Global data marts)

If there is only one business interest that drives the sharing of data across different this should lead to a “specialized global data mart. Usually driven by one business area, there is a need to share data only within specialized business area geographically dispersed. A typical common business interest of a multinational company is the legal consolidation of all the subsidiaries; data from all subsidiaries are collected to from one “global” “sheet of income “ and “balance sheet”. The data coming from different sources are similar and related.

5.4.4 Implementation of SAP BW and other mySAP.com applicatoins

We are often asked in what sequence SAP BW and other mySAP.com components should be implemented and if it makes sense to implement in parallel or if it is better to implement sequentially.

Technically there are no restrictions or benefits from one or the other implementation sequence. We are experiencing all options from our customers.

Many customers that are implementing SAP BW have already implemented R/3. SAP BW is the second SAP product that they implement. Those implementations can be easily compared with classical data warehouse projects (the big difference is the close integration of R/3 and SAP BW and the existence of Business Content).

Some of those customers are implementing all new mySAP.com components from SAP in parallel. Mostly, SAP BW has had a head start in their implementation simply because it was in the market first.

There are a few customers that implement SAP BW as the first mySAP.com application in order to ease information transition from legacy system to mySAP.com.

Most of the implementations, however, are based on the sequence in which SAP released the mySAP.com applications. We expect that parallel implementations will increase.

The same can be said of the roll-out of SAP BW. For most customers it is the second roll out of an SAP product. It’s dimensions are usually much smaller than the R/3 roll-out.



5.4.4.1 Sequential implementations

5.4.4.1.1 First SAP BW then SAP component

SAP BW and SAP SEM

SAP SEM uses a SAP BW as a data basis from where it’s applications get and put the data. When designing the SAP SEM processes SAP BW should be considered. For the implementation SAP BW know-how is required. Technically a SAP BW is a core component and has to be configured in a SAP SEM project in parallel. There is also the possibility to first do an SAP BW project and afterwards start with SAP SEM.

For more details, please check Global ASAP accelerator SAP BW & SAP SEM.

5.4.4.1.2 First mySAP.com component then SAP BW

R/3 and SAP BW

From a true data warehouse perspective it makes sense to build the warehouse once the transaction system are up and running and stable.

Advantage of this approach: no negative time/configuration effects on BW implementation, usually sound SAP knowledge within customer who wants to implement BW. Challenges: BW can have an effect how processes are being optimised and configured. Designs of processes are already finished and unlikely to be changed because of a late BW implementation. There is a danger that customers take the BW implementation to lightly, treated as: “It is not production critical, therefore treated as an “add-on” to ERP backbone.

5.4.4.2 Parallel implementation

SAP BW and SAP APO

SAP APO uses SAP BW as an integral part (no extra SAP BW installation is required). Although one could argue that before a real supply chain management can take place, data harmonization has to take place, technically the SAP BW used by SAP APO should be configured with close cooperation with the SAP APO team and implemented quasi simultaneously.

SAP BW and SAP R/3

The implementation complexity increases the more systems are being involved. Usually the cost and risks are higher, since a whole team will specialize on the SAP BW installation. The benefits, however, of a parallel implementation outweigh costs and risks:

Process and information are analyzed. Because SAP BW is in scope data architectures are likely to be followed. Consistent and harmonized data are more likely.

• Reduced investment into ABAP–reports and “legacy” R/3 reporting techniques, because SAP BW reporting capabilities are considered.

• True Management involvement is more likely, since budgets are bigger (R/3 and BW)

• Administration and problem solving methods for “integrated” systems are already explored within the time frame of the implementation project.

• No “us” and “Them” mentality in the basis administration

The strategy for implementing SAP BW and R/3 in parallel:

Phase 1: Project Preparation:

SAP R/3 and SAP BW are being considered, planned, staffed and budgeted



Phase 2: Business Blueprint

Business Requirements from process reengineering and information modeling , balanced

Set priorities of the report requirements (KPIS) into MUST, NEED, NICE

Check Business Content for match of your requirements.

Only plan and communicate implementation of reports/ KPIs that are either found in the Business Content or are MUST reports

Phase 3: Realization

Implement Business Content fulfilling the requirements and enhance it only for “MUST” reports.

Phase 4:

Test Integration of R/3 and SAP BW, Mass testing

Phase 5:

Go live with R/3 and SAP BW

Stabilize and improve R/3 and SAP BW (technically and only existing solutions)

then

Phase 1 (BW)

Improvement SAP BW by implementing of all reports / KPIs

5.5 Change Management Strategy (Communication Strategy) Very important is the early and effective selling of a global / enterprise wide project. It must be decided how this can be best achieved. The use of internet, events, newsletters, etc help.

Fill out an communication matrix with the axes:

Stakeholders, Type of information needed/ wanted for stakeholder, frequency of informing , how

This matrix must then be monitored.

5.6 Program Management Approach We recommend to form a “global” strategy project group that is in charge of refining the strategy, creating “global” information requirements, monitoring the adherence of the global templates, making sure the many BW implementations are coordinated from a budget, design , quality, time point of view, taking care of the development environment (if there is a global development BW landscape in place)

5.7 Risk Assessment You should assess the risks of the strategy, making sure that you can act to avoid them or al least be react in a way that you have planned.

6 Program Charter You should create a program (strategy) charter with : Timetable of local projects, staffing of the strategy project team, requirements of staff of local teams, listing the goals of the global initiative, list of deliverables, budgets and list of stakeholders. This document should be signed by all team members and sponsors ot the



7 Appendices

7.1 Appendix I: Example: Global and common entities (here: organisatinal)

Business Area

Organisational Element

Category Naming Convention

Financials

Company Code global

Company global

Business Area global TBD

Consolidation Business Area global XX##

Functional Area unknown

Credit Control Area global

Operating Concern global XX##

Controlling Area global XX##

Cost Centre Grouping global TBD

Profit Centre local

Sales Sales Organisation global XX##

Distribution Channel local

Division global TBD

Sales Office local

Sales Area local

Sales Group local

Shipping point global XX##

Loading Point local

Transportation Planning Point local

Make

Plant global XX##

Storage Loc. local



Purchasing Organisation. global XX##

Purchasing Group local

Production Scheduler local

MRP Controller local Etc.

7.2 Appendix II: System Architecture Design criteria General & Organization

Languages

Organization of COMPANY X, geographic Structure of COMPANY X

Geography

Scope and likelihood of organizational changes

History, Power, Independence of COMPANY X organizational units

Outsourcing

Business:

Organizational structure set up of COMPANY X

Requirements for cross-company function integration in warehouse

Formation of critical masses for efficient BW System operation (users, navigation)

Local flexibility

IT/ System:

Volumes (Data, Transactions) & Speed (Growth factors)

Users, Navigations

System Management (Contingency, Configuration Changes, Time Zones,...)

Language (system technology and application support), Codepages

Consideration of SAP components release strategy

Security

Risks (Telecommunication ., Response-times, failure, language barriers)

Technical infrastructure (networks, client PC,...)

Data warehouse

BW Management (Monitoring, Loading, Connecting,....)

Granularity of data, Overall Design Issues: Information requirements

Performance (Loading), Performance (Reporting)

Local committment

Cost:

IT-Cost : Hardware, Telecommunications, Support, License Support:



Availability of know-how for system operation,24 hour 365 days,

7.3 Overview: SAP BW Version 2.0B Architecture The main evolutionary step of the BW Architecture with Version 2.0B is the introduction of a new layer, BW Operational Data Store (BW ODS).

We are aware that this term has taken many definitions. This leads to the certainty of miss-interpretations and incorrect assumptions about what the BW ODS is and what it is not. We decided not to confuse the market by inventing a new term, but to introduce an ODS that is well within in the range market expectations for ODS functionality. Though our approach leveraged existing theory, we were primarily driven by the need to solve the widest possible range of user needs.

Most importantly though, our architecture now encompasses the following features:

• Near comprehensive data extraction from R/3 at its most granular level

• The ability to transform, merge, hold and export data within the ODS.

• Drill down from R/3 to the ODS and or the R/3 Transactions

• Full featured web front end

The Architecture of BW Version 2.0B will be explained discussing the important functional issues in the data warehouse area. The following picture illustrates the BW Version 2.0B Architecture from the perspective of process data integration:



7.3.1 Data Integration

7.3.1.1 Quality Check of Source System Input – Persistant Staging Area

The extracted data from the various source systems (DataSources) are stored without modification in the Persistent Staging Area (PSA) after entering the BW. Each Datasource (extraction) defines in the PSA a table. The structure of a PSA table is called Transferstructure. Additional information like load-packagenumber are added.

The data can then be checked whether they are correct from a business or process point of view (e.g. correspondence to the average number of loaded data records) and thus worth to be further processed in the data warehouse.

7.3.1.2 Data Cleansing and Transformation – BW ODS

Once the transactional data are found valid to be further processed they are passed from the PSA to the BW Operational Data Store Layer.

While transfering the data from the PSA to the ODS rules (Transfer Rules) can be applied to clean them and transform them to company wide confirmed characteristic values. If it is meaningful at this stage business logic may also be applied (Update Rules).

The cleansed and homogenized data will be stored in an ODS-Object which is from an end-user perspective a transparent table. Before a record is loaded into an ODS-Object a referential integrity check is performed against the consitent master data model of BW.

7.3.1.3 Integration of Data from different Source Systems – BW ODS

The integration of Data that describe the same process but offered by different source systems (datasources) is another issue.

The data are loaded into BW and stored in different PSA tables each having their own transferstructure. Integration is achieved applying transferstructure specific rules while transfering the data into the same consolidated structure of an ODS-Object.

Thus the ODS-Objects of the inbound level of the BW Operational Data Store offer data that are subject oriented, consolidated and integrated with respect to the same process that are operated on different source systems.

7.3.1.4 Integration of Data from different Processes – BW ODS - InfoCube

Integration of data from different operational processes is accomplished as follows: The consolidated, homogenized data of each process is stored in an own ODS-Object. A new ODS-Object or InfoCube with the desired multi process integration structure is defined. The data of each datasource ODS-Object are transfered to the target structure applying additional business logic and if necessary transformation rules.

As a result each integration process results in network of ODS-Objects. The number of ‘ODS-Objects levels‘ is technically not limited.

The same is of course true for InfoCubes.

Thus an integration of different processes is guaranteed.



7.3.1.5 Data and Data Warehouse Integration – Consistent Master Data Model

In BW Entities are called Characteristics. An Infoobject is the BW metaobject that describes a characteristic. Defining an infoobject means beside others the generation of a master table with all related attributes. Multi-language descriptions of a characteristic values are supported by a separate infoobject Text table. Further on BW offers the possibility to store complex unbalanced hierarchies in a separate Hierarchy table.

All infoobject table structures support slowly changing dimensions.

The PSA is not only the BW inbound area for transactional data but also for master data.

Input from different source systems for the same characteristic is stored in different PSA tables. Each PSA-table offering input for the same characteristic will be loaded into their master table applying source system specific transformation and cleansing (Transfer Rules) to get a common definition.

The common definition of a characteristic offered by the master, text and hierarchy table is addressed by ODS-Objects and InfoCubes during data retrieval. Thus guaranteeing consistent view to transactional data whether stored in an ODS-Object or a multidimensional InfoCube.

The master data tables a accessed during transactional data load into ODS-Objects or InfoCubes to guarantee referential integrity of data.

7.3.2 Data Granularity – BW ODS and InfoCubes

The inbound ODS-Objects of the BW Operational Data Store should store the data at the same level of granularity as offered from the PSA (i.e. the source system) but this is under the control of the user and not enforced by BW.

With respect to R/3 source systems the strategic objective of SAP BW is to incorporate the lowest level of granularity (document level, line item) and to allow reporting on this level. With BW 2.0 SAP provides the details for almost all of the application areas including MM and B2B procurement, SD and CRM, FI-AP/AR, FI-AA, FI-TV, CO-OM, CO-PA, PP, QM, PM, APO, HR-PA, HR-PE, PS.

Whereas the level of granularity of data offered by legacy system is under the responsibility of the customer.

Thus BW offers with the inbound level ODS-Objects of the ODS the foundation data at a singular level of granularity.

Data can also stored at a atomic level in an InfoCube. Only performance, business and analysis needs (e.g. a non-volatile data scenario) guide the user in his decision where to store the data for final reporting. InfoCubes offer with the star schema and the Line Item Dimension feature i.e. the linkage of master tables directly to the fact table, the more effective structure to navigate efficiently on a huge amount of granular data if this is really needed.

7.3.3 Historical Data - BW ODS

The inbound level ODS-Objects form the historical foundation of the entire data warehouse. To allow huge amount of records in these tables, table partitioning is supported.



7.3.4 Reporting and Analysis

The following picture illustrate the BW Version 2.0B Architecture from the perspective of reporting and analysis:

7.3.4.1 Volatile Scenarios – BW ODS

There exist a lot of business scenarios which require the possibility to modify fact values or status information of already loaded transactional records at least within a certain time span.

An order status tracking scenario is a good example.

Such scenarios are not suitable for InfoCubes. As the modification of an already loaded fact record in the fact table would automatically invalidate all physically stored aggregates of an InfoCube.

From a certain amount of data in an InfoCube using aggregates is the prerequisite for query performance. Therefore modifications of already loaded InfoCube fact records is not supported by BW.

Volatile scenarios are supported in BW using ODS-Objects.

While loading records into an ODS-Object already existing records may be modified or even deleted.

7.3.4.2 Non-Volatile Scenarios – BW ODS - InfoCubes

InfoCubes offer the suitable implementation for the classic non volatile multidimensional reporting and analysis scenario in a data warehouse.

If records are just added to an ODS-Object a non-volatile scenario is supported too.

7.3.4.3 Most Recent Reporting – BW ODS

A further reporting requirement is to have transactional input available for reporting as soon as they are loaded.



This is supported by ODS-Objects combining (‚joining‘) the tables with the activated data and the modified/ new data.

Data Access- BW ODS - InfoCubes

Data access to the transparent master data tables, text tables and ODS-Objects are possible for 3-party tools for example using the ODBC driver of the data base provider.

Data access to InfoCubes is provided using the further enhanced ODBO driver.

Administration and Operation – BW ODS

7.3.4.4 Loading Data into an ODS-Object

An ODS-Object consist of three tables:

A table with active records, i.e. ready for reporting or continuous loading

A table with new, modified records as area for new loaded records.

A Change log table for roll-back

New, modified data are merged into the active version using a separate activation step.

7.3.4.5 Unloading ODS-Object Data

ODS-Objects may be datasources for InfoCubes or ODS-Objects. The load status of a target is logged allowing delta uploads to the targets.

For outside BW usage ODS-Objects content may be unloaded into tables or flat files.



For flexibility and for performance reasons BW offer the possibility to operate the ODS on a separate server.


bw strategy - how to create enterprise wide strategy

Documents