Академический Документы
Профессиональный Документы
Культура Документы
enterprise-wide
implementation of SAP BW
GLOBAL ASAP FOR BW ACCELERATOR
SAP BUSINESS INFORMATION WAREHOUSE
Version 2
BW STRATEGY ASAP FOR BW ACCELERATOR
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
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
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.
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
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.
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,
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.1 Deliverables
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
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.
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.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)
IT-Workshop:
Landscapes, Organisations, Current solutions, strategy (Project Team, CIO, Global Teams)
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?
End
What success factors should a change in the information systems have?
Short Summary
Short desciption of next Stepps
Thank you
Examples how to document business areas for the business information warehouse, processes and
roles, their tasks and performance indicators:
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.1 Summary
5.1.1 Deliverables
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.
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.
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)
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) .
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..
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.
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?
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.
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.
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:
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:
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.
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) .
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
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.
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.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.
.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.
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,
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).
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.
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
• 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.
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)
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.
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.
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”.
Here only a list of issues that have to be considered when creating a strategy:
Performance, Heterogeneuous data sources environments, Distribution of information, Networks
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 - +
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.
A local warehouse is a warehouse that contains local data for local eyes and uses data from one
restricted business area
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.
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 .
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.
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.
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
Make
Plant global XX##
Storage Loc. local
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:
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.
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.
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.
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
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.
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.
The following picture illustrate the BW Version 2.0B Architecture from the perspective of reporting
and analysis:
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.
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.
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 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.
New, modified data are merged into the active version using a separate activation step.
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.