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
Has this customer ordered more /less

Marketing manager Master data Meta compared to last year?
Data
Sales representative
Infocubes
Sales Order Status: How much has

Sales representative.
been delivered for an entire sales
order / customer
ODS
Sales representative
Sales clerk Sales Order Item Status: Why was the

OLTP customer granted a special rebate?
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:
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.

• 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 SAP Basis Maintenance finish Can be upgraded

Availability
Release type state date 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 B1 C C D D B2 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)
Busines Organisational Category Naming

s Area Convention
Element
Financial Company Code global

s
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

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

BW Strategy - How To Create Enterprise Wide Strategy

Transféré par

Droits d'auteur :

Formats disponibles

How to create a strategy for an

Creating concepts for enterprise wide SAP BW

©1998 SAP AMERICA, INC. AND SAP AG

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

2 WHAT IS AN INFORMATION MODEL? ............................................................................................... 4

©1998 SAP AMERICA, INC. AND SAP AG

2 What is an Information Model?

2.1 Enterprise-wide Business Information Requirements and data

2.2 The Description of Information Supply Chain

©1998 SAP AMERICA, INC. AND SAP AG 4

3 SAP BW Strategy Overview

3.1 Scope of SAP BW implementation strategy

©1998 SAP AMERICA, INC. AND SAP AG 5

©1998 SAP AMERICA, INC. AND SAP AG 6

©1998 SAP AMERICA, INC. AND SAP AG 7

3.4 Scope of SAP BW within an enterprise wide IT landscape

3.5 Team requirements

 Strategy Methodology knowhow

3.6 Methodology of SAP BW Strategy and SAP BW implementation

©1998 SAP AMERICA, INC. AND SAP AG 8

For the preparation of the executive workshops you should:

©1998 SAP AMERICA, INC. AND SAP AG 9

4.2 Executive Workshops

Create vision and goals, understand scope, benefits and risks

©1998 SAP AMERICA, INC. AND SAP AG 10

Conduct the executive workshop

©1998 SAP AMERICA, INC. AND SAP AG 11

4.2.3 Organization and Staffing of the Workshops

4.3 Best practice & examples

©1998 SAP AMERICA, INC. AND SAP AG 12

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

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

4.3.2 Guideline for Interviews with Info Owners

©1998 SAP AMERICA, INC. AND SAP AG 13

Name the 5 Top KPIs

©1998 SAP AMERICA, INC. AND SAP AG 14

4.3.3 Documentation of key findings of the Workshop

Vision of an information supply chain.

©1998 SAP AMERICA, INC. AND SAP AG 15

5 Program Definition and Strategy Study

The strategy should entail the following topics:

©1998 SAP AMERICA, INC. AND SAP AG 16

5.2 Information Model

5.2.1 Analysis of the organizations/ Regions/Countries

5.2.2 Process analysis

©1998 SAP AMERICA, INC. AND SAP AG 17

5.2.3 People and Roles Analysis

5.2.4 Information analysis

5.2.4.1 Dimensions of the key performance indicators

5.2.4.2 Global , Common and Local Data/ Information

Global information: Global information is information needed or produced by global or common

©1998 SAP AMERICA, INC. AND SAP AG 18

5.2.4.3 Information Sources Analysis

5.2.4.4 Information Access Analysis

5.2.4.5 Information types and layers

5.2.5 Info Model: Information Requirements

©1998 SAP AMERICA, INC. AND SAP AG 19

5.2.6 Info Model: Information Supply Chain

©1998 SAP AMERICA, INC. AND SAP AG 20

5.2.7 Information Layers

©1998 SAP AMERICA, INC. AND SAP AG 21

Has this customer ordered more /less

Sales Order Status: How much has

Strategy Methodology knowhow

Phase 2: Business Blueprint