Sunteți pe pagina 1din 39

SAP NetWeaver

BW 7.3:

Rapid Deployment
Solution for Advanced
Planning and
Optimization-Demand
Planning





















For Internal Reference Only
Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 2




Table of Contents

Overview

Scope Definition

Terminology

Assumptions

Technical Approach and Architecture

Implementation Strategy

Solution Details

Team Structure

Timelines

Appendix






























Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 3



Overview:

This document provides a means of rapidly deployable business warehouse data architecture solution for
implementing Advanced Planning and Optimization Demand Planning project for key Supply Chain and
Manufacturing Logistic client spanned across different regions on the globe. This document provides an
insight about specific interfaces from BW perspective that focuses on real world business scenario and
gives an overview of demand planning functionality.

Scope Definition:
In Scope: SAP BW Data Extraction, Modeling and Reporting Solution for Demand Planning module
specific to business requirement.

Out of Scope: Technical Configurations related to Demand Planning.

Terminology:
This section provides an overview about Demand Planning concepts, building blocks and a general
application flow which will help users to gain insight about Demand Planning component and its usage for
different Industry Sectors.

APO-DP Terminology and Flow Overview:

Figure 1 is a simple illustration stating fact that SAP APO-DP is an integral component of SCM.



SCM
APO
DP


Figure 1






Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 4



SAP Demand Planning Flow Overview:

Please refer the Figure 2 for SAP Demand Planning Flow Overview. This information is an important
ingredient which should be understood by BW developers in order to execute SAP BW and SAP APO-DP
Integrated projects. The terminologies are mere adaptation from SAPs Application help. They provide an
insight about DP concepts so that BW developers can have a functional and process overview before
they start with actual development. Understanding these factors before implementing the BW solution can
avoid process loop holes and strengthen the data modeling solution.


Basic Planning Object Structure
Planning Area
Characteristics Key Figures
Basic Units of Measure
Basic Currency
Memory Storage
Buckets Profile
APO
Infocubes
Planning Book
Time
Series
Objects
Live
Cache
Version
Aggregates
Characteristic
Combinations
Actual Key
figures
Planned Key
figures
Planning Versions


Figure 2

Definition:

Demand Planning is a powerful and flexible tool that supports the demand planning process in your
company. Use APO Demand Planning (DP) to create a forecast of market demand for your company's
products. This component allows you to take into consideration the many different causal factors that
affect demand. The result of APO Demand Planning is the demand plan. Using the DP library of statistical
forecasting and advanced macro techniques you can create forecasts based on demand history as well
as any number of causal factors, carry out predefined and self-defined tests on forecast models and
forecast results, and adopt a consensus-based approach to reconcile the demand plans of different
departments.

Demand Planning (DP) is an application component in the SAP Advanced Planner and Optimizer (APO)
of SAP Supply Chain Management that allows companies to forecast market demand for a company's
products and produce a consensus demand plan.



Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 5



Key Figures:

It contains data that is represented as a numerical valueeither a quantity or a monetary value.
Examples of key figures used in Demand Planning are planned demand and actual sales history.

Characteristics:

Planning characteristics are usually such as a product, location, brand or region. The characteristics used
in Demand Planning are the same as those used in the SAP Business Information Warehouse.
For example: 9AMATNR for product and 9ALOCNO for location.

Master Planning Object Structure:

A master planning object structure contains plannable characteristics for one or more planning areas. In
Demand Planning, the characteristics can be either standard characteristics and/or ones that you have
created yourself in the Administrator Workbench. Characteristics determine the levels on which you can
plan and save data.
The master planning objects structure is the structure on which all other planning objects structures are
based.
A master planning object structure forms part of the definition of a planning area. The existence of a
master planning object structure is therefore a prerequisite for being able to create a planning area.
Characteristic Value Combinations:
A characteristic value combination is the combination of characteristic values with which you want to plan.
It is sometimes referred to as a characteristic combination. You can only plan data if you have defined
such a combination.
Characteristic value combinations are planned for master planning object structures. The combinations
are then valid for all planning areas based on this planning object structure.
Aggregates:

An APO aggregate contains a subset of the characteristics in the master planning object structure. The
creation and use of aggregates is optional. The data is always saved on the lowest level of detail. If
aggregates exist, the system saves the planning data on the defined aggregate levels as well as on the
lowest level of detail.

Basic Unit of Measure:

It is the basic unit of measure used for assigning to planning books.

Basic Currency:

It is the basic currency in which users want to visualize the data.






Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 6



Time Series Objects and LiveCache:

1. Time Series: Before you can create and work with planning books, you must create time series
objects for the planning area. This process is sometimes known as initializing the planning area.
The system creates a network of characteristics and key figures in LiveCache.
You can create time series objects for a version and a period of time. You can delete time series
objects and see which time series objects exist for a planning area. It is possible to extend the
time series into the future and delete the last periods from LiveCache by reinitializing the time
series periodically. In such a way you can maintain a "rolling horizon".

2. LiveCache: In APO transaction data is not stored in tables like R3. If you want to view / check /
extract transaction data then you will have to use standard BAPI's. These BAPI's are available for
different kind of data like sales orders, manufacturing orders, stocks, planned independent
requirements, etc. In Live cache data is stored based on Time series and order series. LiveCache
is one of the databases used in APO system. LiveCache is often called memory based database.
The difference between other DB and LiveCache is, it is recommended to store all the data in
DataCache in LiveCache, and if most of the data is stored in LiveCache, this means data is on
memory.

Data Storage Concept in DP:

In Demand Planning and Supply Network Planning, you can store data in three ways:

1. In LiveCache time series objects.
2. In LiveCache orders.
3. In an InfoCube.

Each key figure in a planning area has its own storage method.

1. LiveCache Time Series Objects: The data is stored in buckets, with no reference to orders. This
storage method is suitable for tactical, aggregated planning. It is the usual method for saving
current Demand Planning data.

2. LiveCache Orders: The data is stored with reference to orders. This storage method is suitable
for operative planning, such as in a classical SNP setup.

3. InfoCubes: The data is stored in an InfoCube in the Administrator Workbench. This storage
method is suitable for data backups, old planning data, and actual sales history.

Time Bucket Profiles:

1. Storage Buckets: It is used for storing data. In storage buckets you specify:

1. One or more periodicities in which you wish the data to be saved.
2. The horizon during which the profile is valid.









Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 7



2. Planning Buckets: Its used for planning the data. The planning buckets profile defines the
following:

1. Which time buckets are used for planning?
2. How many periods of the individual time units are used?
3. The sequence in which the time periods with the various time units appear in the planning
table.

You can have multiple planning buckets profiles, and therefore multiple planning horizons, for one
planning book. The planning buckets profile is attached to the data view within the planning book.


Planning Area:

Planning areas are the central data structures for Demand Planning and Supply Network Planning.
The planning area is created as part of the Demand Planning/Supply Network Planning setup. A planning
book is based on a planning area. The end user is aware of the planning book, not the planning area. The
liveCache objects in which data is saved are based on the planning area, not the planning book.

The planning area specifies the following:

1. Unit of measure in which data is planned.
2. Currency in which data is planned (optional).
3. Currency conversion type for viewing planning data in other currencies (optional).
4. Storage buckets profile that determines the buckets in which data is stored in this planning
area.
5. Aggregate levels on which data can be stored in addition to the lowest level of detail in order to
enhance performance.
6. Key figures that are used in this planning area.
7. Settings that determine how each key figure is disaggregated, aggregated, and saved.
8. The assignment of key figures to aggregates.
DP Data Marts:
The data mart in APO consists of InfoCubes. In the InfoCubes, you store actual data and older planning
data. If you have a data warehouse, such as the SAP Business Information Warehouse (BW), the DP
data mart is a subset of the data from your data warehouse.
You can set up data marts either using APO systems administrator workbench or by setting up separate
BW system.
The data mart setup process consists of the creation of InfoCubes in APO and the loading of actual
and/or planned data. Actual data can be used as input for time series forecasting or causal analysis, or
for a comparison of the demand plan with actual demand. Planned data could consist of forecasts
submitted by individuals or departments, such as product line forecasts from sales representatives.



Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 8



Macros:

They are used to perform complex calculations quickly and easily. Macros are executed either directly by
the user in interactive planning or automatically at a predefined point in time during a background job. The
definition of macros is optional.

Planning book:

The most important tool of the demand planner is the planning book. With it, you can design the content
and layout of the interactive planning screen so that it corresponds to your planning requirements. In the
planning book, you select characteristics and key figures that the demand planners require for their tasks.
Each book can contain several views in which you can compose key figures for detailed analyses and
planning tasks.

In the planning book you define the following elements:
Key figures and other rows.
Characteristics.
Functions and applications that can be accessed directly from this planning book.
User-specific planning horizons.
User-specific views on the planning book, including initial column, number of grids, and
accessibility of the view for other users (there is no limit on the number of views you can have
within one planning book).
APO Demand Planning comes with preconfigured views for:
1. Univariate forecasting (time series forecasting).
2. Causal analysis.
3. Composite forecasting.
4. Promotion planning.
Assumptions:

1. The solution described is related to specific industry and may not be deployed As Is.
2. The document is interpreted by the readers who have basic knowledge of SAP Business
Warehouse principles and terminology.
3. One must uses SAP R/3 or SAP ERP Central Component (ECC) with the modules Sales and
Distribution (SD), Materials Management (MM) and Production Planning (PP) already, and that
they do not use any SAP industry solutions.
4. There wont be any major process changes as part of the project.
5. For DP, one central Demand Plan is created for the entire supply chain. This might encompass
having one or multiple distribution sites, but demand planning is central.
6. For SNP we assume an average supply network with no more than about ten production or
distribution sites.
7. Alert Monitor to report exceptions are not the part of this solution.
8. A toolkit of statistical forecasting techniques.




Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 9



Technical Approach and Architecture:
Technical Components:

1. SAP BW 7.3
2. SAP SCM 7.02
3. SAP ECC 6.05

Comparison Analysis:

This section discusses the approach for implementing data modeling solution for APO- Demand Planning
Implementation.

Data modeling solution for implementing APO-Demand Planning requires BWs data warehouse
workbench in order to stage data for planning purpose. In addition BW environments reporting concept is
required in order to create technical queries for Forecast Accuracy and so on.

APO-DP environment by itself contains datawarehouse workbench but there are certain factors which
completely determine whether we need to use separate BW environment or the BW environment
contained in the APO- DP.
.
Below table provides comparison analysis for two options for maintaining BW environment. Options are
weighed against standard parameters.

1. One single environment for APO-Demand Planning and BW Datawarehouse workbench.
2. Different environments for APO-Demand Planning and BW Datawarehouse workbench.


Parameters Single Environment for APO-
DP and BW
Different Environments for
APO-DP and BW
Cost Low High
Complexity and Maintenance Low High
Performance Low High
Reporting Flexibility Low High
Analytic Capability Low High
Legacy Mapping Effort Low High
Data volume handling capacity Low High


There are several reasons when we want to keep BW and APO as one instance. One might be the lower
investment and another reduction of complexity and maintenance. So, the choice depends very much on
the reporting requirements.

SAP recommends usage of different instances of BW and APO.BW serves as a Data Consolidation and
Reporting tool whereas APO is dedicated to specific planning functions.

The kind of information which is necessary for planning can be retrieved from BW using the DATAMART-
Interface. It also helps to compare the previous years planning data which is written back to the original
Infocubes that also holds the new sales-data.




Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 10



Reporting is defined and performed on the BW-System. BW is tuned to make quick and efficient reporting
possible using tools like compression, aggregates and the entire set of OLAP-Functions. BW is also the
right place from data administration point of view.

In BW environment, you define when data is loaded (Scheduler) from which system and to whom it may
be presented (Authorizations). Consequently BW is the place where you control the flow of information
not only to power- or end-users but also to other system-components.


System Landscape:


Figure 3 provides an overview of system landscape which can be implemented in order to support the
solution.

SAP Solman 7.1(SLM)
SAP ECC 6.0
SAP SCM 7.0
SAP BW 7.3
SAP PI 7.3
IBM MQ Series
(Middleware)
Legacy Systems
(Facility)
Legacy Systems
IBM Datastage 8.5
SAP EP 7.0
EHP1 SPS5
SAP GUI 7.0
SSO
RFC
IDOC
IDOC
RFC
File Adaptor
File Adaptor
RFC
&
CIF
File Adaptor
File Adaptor



Figure 3

Note: Proposed architecture shown above can vary from project to project based on business
requirement and complexity.





Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 11



Implementation Strategy:

The strategy to execute a project of similar kind will involve certain factors:

1. Interaction of SAP with legacy servers: This involves the means to extract data from various
business legacy environments located in different regions and placing it on SAP Application
servers.
2. Data Volume Handling Capabilities: This factor involves consideration of database sizes for
BW and APO-BW environments, taking into account data loads from legacy environments.
3. Global Planning Requirements: The data warehouse has to be designed in such a manner so
as it should act as a unified data warehouse for different regions, and should have the ability to
report data in planning books at specified time intervals.
4. Usage of Middleware and ETL Tools: Its quite critical to select appropriate technical tools for
middleware and ETL tasks. Common tools used for these tasks are mainly Datastage, SAP PI
and SAP BW in-house environments.


5. Master Data Consistency: A well devised requirement gathering activity should consider all
intricacies of consolidating master data from legacy environments, performing cleansing
operations and loading it to SAP ECC environment. Suggested methods used for these tasks can
be LSMW (explained in detail in later sections) or automated interfaces from legacy, created via
middleware data extraction techniques.

Solution Details:
The solution details described in this section gives a jump start to business
analysts/consultants/developers in order to implement APO-Demand Planning data modeling solution
with SAP BW as datawarehouse and flat file as external source system.

The interfaces described in this section are generic in approach considering the factors of reusability and
adaptability to different sectors and business scenarios.

Details mentioned focus on key SAP BW configurations, master data and transaction flow design by
providing an insight about SAP BW 7.3 modeling layer concepts.

The solution encompasses handful of information regarding Process chain designs, job scheduling and
cutover management allowing reader to implement solution to the entirety.















Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 12



Cross System Configuration:

Application Server Settings (Related System: SAP BW 7.3)

In order to implement Flat File Interface solutions, it is mandatory to organize SAPs Application server
folders.
This is done to make sure all inbound and outbound interfaces stay clean of each other.
Developers can follow below mentioned steps to categorize different files coming to a specific folder in
Application Server.

1. Create 2 different folders on Application Server one for each Inbound and Outbound Interface.
2. Within Inbound create 4 new folders namely New, Processed, Error and Archive.
3. All files coming from legacy should be routed to New folder via middleware and then processed
further to BW and APO-BW.
4. Files which have been read successfully after BW data loads should move from New to
Processed.
5. All files which ran into an error state while data loading in BW should move to Error folder.
6. All files which have been successfully moved to Processed folder should move to Archive folder
after x number of days as per business requirement.




































Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 13



Flow Chart:
File in Application Server
File moved to NEW Folder
Successful
Loading
Process
Move to ERROR Folder
Move to PROCESSED Folder
Duration >
7days Retain in PROCESSED FOLDER
Move to ARCHIVE Folder.
Clean Up the Files in ARCHIVE
folder after say 30 days
END
START
NO
YES
YES
NO
After successful records pull by BW InfoPackage

Figure 4

Note: The above mentioned logic requires a custom program which should be developed using
ABAP and UNIX level commands. This task should be carried out by an experienced ABAP
developer.

Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 14



Logical Path Creations (Related System: SAP BW 7.3)

With the concept of Logical path, BW developers need not to give actual physical path name while
running infopackage. Logical path should be mapped to actual physical path using FILE transaction.

Creation of Logical Path makes it easy while mentioning file path at BW infopackage level.
Logical paths are configured via TCODE-FILE with the help of Basis Administration developers.

Logical Path should be created in order to fetch data from Flat file inbound interfaces.

Developers should keep following things in mind while configuring Logical path.

1. Always add timestamp to the logical path name such as ZBACKORDER_US_<YYYYMMDD>.
2. Maintain proper naming convention for logical paths as per business areas, you can follow
naming convention such as Z_BACKORDER_US_20120101, this makes sure that each region
gets separate name and it can be leveraged by different infopackages( BACKORDER refers to
business area, US refers to region and 20120101 refers to current date).
3. Configure logical name to fetch current timestamp via FILE TCODE.

Note: The configurations described above require an experienced BASIS developer who has prior
experience of working on Logical path creation and Application server settings.

Number Range Conversion Settings (Related System: SAP APO BW, SAP BW 7.3 and SAP ECC)

SAP Standard and Best Practices suggests that number ranges for material numbers should be
maintained consistent across different environments. Number range indicates the kind of format and
length specifications for material data values.
In case of data being loaded from legacy environments, there is always a possibility of bad data, number
range settings make sure that data entering in SAP environments adheres to certain format and length
standards.

Configuration:

Use TCODE-OMSL in different environments such as APO-BW, BW and ECC and maintain same kind of
settings. This makes sure that when material values are transferred from one system to another, they
behave in same manner.

Advantages:

1. Consistent Number range setting allows master data integrity across different environments.
2. It keeps the format and length specifications of master data in synch with transaction data.
3. The master data objects hold more clean and formatted data.

Data Extraction (Sources, Methods and Datasources) (Related System: SAP BW 7.3)

Flat File Interface:

Legacy environments are mapped to BW via flat file interfaces.

Data from external legacy environments can be transferred to BW system via flat file interfaces.

SAP BW 7.3 provides flat file as one of the source system which allows Datasources to fetch data from
flat files and then send it to higher data targets in BW via extraction and transformation logic.


Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 15



Flat file Datasources are created via standard BW Administrator Workbench and are mapped to BW
DSOs and cubes via standard transformation concept.
Master Data Components and Setup (Related System: SAP ECC)

As per SAP suggested practices, master data should always be maintained in ECC which is considered
as safe source.

In order to interface master data coming from legacy environment business can opt for LSMW solution.

LSMW (Legacy System Migration Workbench):

It is a tool that supports data migration from legacy (non-SAP systems) to SAP systems. The LSMW is a
cross-application component (CA) of the SAP system.

The tool has interfaces with the Data Transfer Center and with batch input and direct input processing as
well as standard interfaces BAPI and IDoc.

LSMW-Features:

This tool migrates user defined datasets, which are combined as per business criteria. LMSW comprises
following main functions:

1. Read data (legacy data in spreadsheet tables and/or sequential files). You can use any
combination of PC and server files.
2. Convert data (from the source into the target format).
3. Import data (to the database used by the SAP application).


In this way, master data can be maintained in ECC environment by business through LSMW-(Legacy
System Migration Workbench) process for mass uploads of Materials and Customers.

Plants as per following regions are manually configured in ECC environment.

Note: The configurations described above for LSMW and master data configurations require an
experienced ABAP or Techno Functional resource who has prior experience of configuring master data in
ECC.

Standard Master Data Extractors:

SAP suggests usage of standard ECC extractors to pull master data records from ECC.

BW and APO-BW system extract data from ECC via standard extractors for Material, Plant, Customer
and Material Plant.

Developers can leverage below mentioned standard extractors delivered by SAP as standard content:

Material Attribute: 0MATERIAL_ATTR
Material Text: 0MATERIAL_TEXT

Customer Attribute: 0CUSTOMER_ATTR
Customer Text: 0CUSTOMER_TEXT


Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 16



Material Plant Attribute: 0MAT_PLANT_ATTR
Material Plant Text: 0MAT_PLANT_TEXT

Standard Extractors are mapped to standard/custom Infoobjects in BW and APO-BW as per business
requirement.

Transaction Flow for Inbound and Outbound Interface (Related Systems: SAP BW and SAP APO-
BW)

The transaction flow diagrams follow SAP BW 7.3 basic modeling principles where developers need to
follow architectural standards and mold design as per their business logic.

Below section explains the data modeling solution in order to implement business processes such as
Forecast Analysis, Historical Demand, Backorder and Inventory Count.


Business Lines Overview:

Customer Forecast:

As a part of Demand Planning solution, companies implement Forecast Analysis interfaces in order to
carry out forecast of market demand for companys products based on different factors such as region,
customer, material group etc.

Historical Consumption:

Business requires historical data in order to carry out Statistical Forecasting. The data is being utilized by
planning books and used by business for predicting forecast

Backorder and Inventory Count:

These are standard counts of Inventory and Backorder which are required by business in order to plan for
future. These records serve as an input to forecasting models and hence are leveraged by business to
depict forecast values for materials as per customer and plants.


















Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 17



BW Data Modeling:

Figure 5 provides a standard SAP BW 7.3 data flow overview. With SAP BW 7.3, SAP suggests usage of
different layered data modeling concept in order to enhance extraction, transformation and reporting
experience.

L
S
A
Data Acquisition layer
Quality and Harmonization Layer
Data Propagation Layer
Corporate
Memory
Business Transformation Layer
Reporting Layer
(Architected Data Marts)
Virtualization Layer
Operational
Data Store
Architected
Data Mart Layer
Enterprise
Datawarehouse Layer

(Architected Data Marts)
Figure 5

LSA (Layered Scalable Architecture):

The concept of LSA defines the usage of different modeling layers as templates in order to offer various
extraction and reporting scenarios to business. This concept highlights the reusability of data flow
templates and hence provides an efficient way to perform data modeling and reporting.

The below mentioned definitions of various layers are derived using standard SAP Application help
content in order to encourage users to follow them while working on data modeling and data flow designs:

Enterprise Datawarehouse Layer:

1. Data Acquisition Layer: The data acquisition layer receives the data from the flat files and
distributes in the BW system. BW Datasources form an integral part of this layer.

2. Quality and Harmonization Layer: This layer helps to clean and harmonize the data. Datastore
objects form an integral part of this layer.

3. Data Propagation Layer: This layer offers a consistent base for distributing and reusing data.
The data in this layer should not be transformed so that it can be re used by business
transformation layer.



Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 18



4. Corporate Memory: This layer stores the history of data loaded from source systems. This layer
can be leveraged in scenarios to reconstruct or reload data to Data Mart Layer without having a
need to re pull data from source systems. The usage of this layer is totally dependent on
business decision.


Architected Data Mart Layer:

1. Business Transformation Layer: As the name suggests this layer is used to mold data as per
business rules. Datastore Objects can be used in this layer in order to fetch data from different
data targets in Data Propagation layer.

2. Reporting Layer: This layer is generally constructed with the help of infocubes providing users
an easy and flexible way for dimensional reporting. Infocubes can either be semantically
partitioned or not depending on business requirement in order to enhance performance.

3. Virtualization Layer: This layer is generally filled by Multiproviders which are the preferred way
of SAP BW reporting. There is not much difference between Reporting and Virtualization Layer. It
depends on specific scenario.

Operational DataStore:

An operational data store supports operational data analysis. In an operational data store, the data is
processed continually or in short intervals, and is read for operative analysis. In an operational data store,
the mostly uncompressed datasets are therefore quite up-to-date, thus providing excellent support for
operative analyses.

Note: All layers defined above are subjected to actual realization of BW implementation projects. It is not
mandatory to use all the above layers which creating data flows. Although they are recommended by SAP
as best practices, but their actual creation is determined by business logic and developers modeling
strategy.

Recommendations:

Always use Data Acquisition layer in order to interface data from legacy. This is one of the mandates in
order to bring data from source systems.

Use Data Propagation layer in order to store and redistribute data to higher layer. Make use of Datastore
Objects in this layer.

Use Business Transformation layer in order to carry out complex business logic transformations and then
make use of reporting layer in order to support Business reporting.

Inbound and Outbound Interface Overview:

Users should leverage BW 7.3 Layered Scalable Architecture Concept as explained in above section and
implement inbound/outbound interfaces for specific business lines solution.








Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 19



The below diagram provides interface overview for APO-DP and BW. Please note that this diagram is a
mere adaptation of a generic interface, developers can modify the design within each environment as per
the project considerations.

SAP-BW Datawarehouse
Infocubes
Infoobjects
Data Marts
SAP BW Reporting Analysis
Forecast Accuracy
SAP ECC
Master Data
SAP APO-DP
Planning Book
Planning Area
Inventory Backorder
Customer Forecast
Historical Consumption
Outbound Flow from APO-DP/APO-BW to BW
Inbound Flow from BW to APO-DP/APO-BW


Figure 6


Figure 6 depicts:

1. Data flow from BW to APO-BW for Inbound Interface.
2. Data flow from APO-BW to BW for Outbound Interface.
3. Master Data residing in SAP ECC is connected to both BW and APO-BW environments.
4. Forecasting methods are computed in APO-BW.
5. Forecast Accuracy Reporting is carried out in BW.

Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 20



Creation of these inbound (Figure 7a) and outbound (Figure 7b) interfaces requires data modeling effort
in both environments.

Developers need to follow the same concept of Enterprise Data Warehouse and Architected Data Mart
Layer in both the environments.


The concept of individual layers in each of the sections can vary depending on the business requirement.

Best Practices suggest usage of Layered Scalable Architecture for high performance and long run
datawarehouse and reporting solution.

Users can refer to below Data flow diagram which is a citation from actual project implementation. The
layers highlighted below suggest the usage of Layered Scalable Architecture. This is just an example;
different projects can implement this solution as per their specific business logic.
Legacy
I
N
T
E
R
F
A
C
E
Datasourc
e/
DataMarts
DSO Infocube
I
N
T
E
R
F
A
C
E
Datasourc
e/
DataMarts
Infocube
Legacy BW
APO-BW
Data
Acquisition
Layer
Data
Propagation
Layer
Business
Transformation
Layer
Data
Propagation
Layer
Data
Acquisition
Layer
Customer Forecast
(BW DSO)
Master
Data Grief
Customer
Forecast
(BW Cube)
Customer Forecast
APO-(BW Cube)
Checkpoint 1
Checkpoint 2 Checkpoint 3
INBOUND FLOW


Figure 7a



Datasourc
e
I
N
T
E
R
F
A
C
E
Datasourc
e/
DataMarts
DSO
I
N
T
E
R
F
A
C
E
Datasourc
e/
DataMarts
Planning
Book
APO- BW BW
Data
Acquisition
Layer
Data
Propagation
Layer
Data
Propagation
Layer
Data
Acquisition
Layer
DSO
Data
Propagation
Layer
File on
Server
OUTBOUND
FLOW

Figure 7b









Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 21



Process Chain Design:

Process Chain:

A Process chain is an automated way to extract, transform and load data to BW Data targets across
different layers. Process chains are driven by data modeling logic. Process Chains should be designed
considering following factors in mind:

1. Create separate Master Data and Transaction Data Chains.
2. Create separate chains for each regional flow.
3. Follow standard naming convention across all Process Chains.

In order to implement process chain design for SAP BW and APO-DP Inbound and Outbound flow,
developers need to create process chains in both BW and APO-BW environment.


Inbound Interface: Process Chain

Users can follow the below mentioned steps as a jump start to create process chains in SAP BW 7.3
environment:

1. Create Master Data Attribute chain comprising all key master data required, as per business
logic.
2. Create Master Data Text Chain comprising all key master data required, as per business logic.
3. Create Master Data Meta Chain with Attribute and Text chain as sub chains (local chains).
4. Create chain for transactional data for each region separately leveraging different infopackages
as configured in logical path configurations explained in Section: Logical Path Configurations.
This ensures each region has specific process chain and it can run on its own time independent
of other region. Users can leverage standard Copy Functionality Wizard to copy process chains
for one region from other.
5. Add Customize program to move legacy files from one folder to another as a process step after
BW Infopackage load, The success criteria of the infopackage load should determine in which
folder the file should move. For example, if the infopackage load is successful, file moves from
NEW to PROCESSED folder otherwise it move from NEW to ERROR folder (in case of
infopackage load error).

Below is an example Process chain for Inbound flow within SAP BW 7.3 , this is just for users
reference and they can mold it as per their business requirement.

SAP APO-BW:

Users can follow the below mentioned steps as a jump start to create process chains in SAP APO-BW
environment:
1. Create Master Data Attribute chain comprising all key master data required, as per business
logic.
2. Create Master Data Text Chain comprising all key master data required, as per business logic.
3. Create Master Data Meta Chain with Attribute and Text chain as sub chains (local chains).
4. Create chain for transactional data for each region separately leveraging different infopackages
for different regions.
5. Add Custom logic and program if required in the process chains.

Below is an example Process chain for Inbound flow within SAP APO-BW, this is just for users
reference and they can mold it as per their business requirement.


Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 22



Outbound Interface: Process Chain

SAP APO-BW:

Users can follow the below mentioned steps as a jump start to create process chains in SAP APO-BW
environment:

1. Create transaction data chain comprising planning book datasource load from planning book via
regional infopackages.
2. Load data till DSO/Cube as per business logic.
3. Add Custom Logic or code if required.

Below is an example Process chain for Inbound flow within SAP APO-BW, this is just for users reference
and they can mold it as per their business requirement.

SAP BW:

Users can follow the below mentioned steps as a jump start to create process chains in SAP BW 7.3
environment:

1. Create transaction data chain comprising Datamarts loads from APO-BW data targets via
regional infopackages.
2. Load data till DSO/Cube as per business logic.
3. Add Custom program process to extract data from DSO in BW to generate output file on SAP
Application Server.

Below is an example Process chain for Inbound flow within SAP APO-BW, this is just for users reference
and they can mold it as per their business requirement.

Recommendations:

Regional Process chains leveraging regional infopackages and Data Transfer Processes should be
created in order to avoid regional data load timing conflicts.

Process Chain Design is a standard BW Development activity which should be carried out by an
experiences SAP BW developer.

Job Scheduling Strategy:

This section drives the importance of scheduling process chains in such a manner that different regions
get forecast data as per their Timezone settings. Consider a scenario where a business is implementing
Demand Planning Solution for regions such as US, UK, China and Europe. In that scenario it becomes
critical to schedule process chain in such a manner that system gets updated data as per their regions
local time.
Users can make use of following job strategy while designing scheduling strategy for SAP-BW and SAP
APO-BW process chains:

Inbound flow:

1. Create event to check if transaction file with current days timestamp is available on SAP Server.
2. If file is available then execute Master Data Meta Chain in BW and APO-BW, if not then throw an
exception or time out error, indicating the transaction data file is not available on the server. This
makes sure that BW process chains only start if there is valid file on SAPs Application server and
avoids any unnecessary file loads.
Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 23



3. Once Master Data Chain is finished then run Transactional data chain in BW, and then execute
transaction data chain in APO-BW for specific region and business process.

Outbound Flow:

1. Trigger APO-BW jobs after planning book macro jobs.
2. Execute jobs to run APO-BW process chains.
3. Once APO-BW job finishes, run the specific business process and regions process chain in BW.

Above mentioned strategy is mere citation of generic job scheduling processes in SAP BW environment,
Users can leverage the same and modify it as per their business requirement.

Cutover and Migration Procedure:

Determining Cutover Strategy and migration developed objects to higher testing and production
environments is always an arduous task for BW developers. In recent times, it has been observed that
most of the implementation projects suffer serious risk related to business timelines when it comes to
cutover and migration stabilization.

In order to reduce these risks in future, users should keep in mind below mentioned factors:

Migration Methodology:

1. Follow standard SAP Transport Organizer tool to collect objects in development
environment.
2. Maintain proper naming convention for the transports in order to avoid confusion in later
stages.

3. Segregate the objects collection as per each object type and functional area, for example
a transport request for Inventory cubes should be different from transport request for
backorder cubes.
4. Follow below mentioned release sequence while releasing objects from Development to
higher testing environment:

1. Cross system configurations if any.
2. Source System transports for Datasource and any customizations if required.
3. Application server logical file commands and file path definitions.
4. Application components.
5. Infoobjects, Infocatalogs and Info areas.
6. DataStore Objects and Cubes.
7. Datasources/Data Marts (After Manual Replication of Datasources from source
system).
8. Infopackages.
9. Transformations.
10. Data transfer Processes.
11. Multiproviders.
12. Process Chains/Events etc.
13. Queries.
5. Carry consistency check for the transport requests using program
RSO_TLOGO_CHECK_REQUEST in order to see if there is any missing dependent
object which is required for the transport.




Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 24



Cutover Strategy:

1. Create a step by step detail cutover plan listing down all manual tasks and assign
each individual to that task.
2. Monitor transports closely and make sure that all transports follow the release
sequence as determined by the BW developers or cutover analyst.
3. There are always chances of getting transport errors while cutover migrations,
make sure you trouble shoot them in a proper manner and then fix those issues
within cutover window.
4. Make sure to replicate Datasources/data marts in BW and APO-BW in case of
datasource transports.
5. Perform a sanity check of all transported objects by looking in the target system
and verifying that all imported objects are in active state.
6. Maintain manual table entries or configuration before data loads.
7. Perform manual initialization of delta Datasources.
8. Perform OTO (One Time only) data loads manually to load historical data if
required.
9. Schedule the process chains in higher environment as per job scheduling
strategy and monitor.

The Migration and Cutover explanation provided in above section is to guide users about the
methodology implemented while executing these tasks. Its just an overview and can vary from project to
project.


Team Structure:
Please refer Figure 8 for the proposed team structure.

Manager
SAP / (IM BI/DW)
IM BI/DW SAP
Senior Consultant
SAP BASIS
Senior Consultant
SAP APO DP Functional
Senior Consultant
SAP BW
Consultant
SAP APO-DP Functional
Consultant
SAP BASIS
Consultant
SAP BW with ABAP
skills
Consultant
SAP BW/Datastage
BTA(Optional)
SAP BW
BTA(Optional)
SAP BW


Figure 8

Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 25



Note: The actual team size can vary, depending on the complexity of the project and timelines.


Timelines:
Please refer Figure 9 for the Timelines. The timelines are dependent on the phases such as Advance
Prep, Blueprint, etc. and may vary from project to project depending upon the complexity of the project.




Figure 9
















Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 26



Appendix:
1. Key Issues: The below table provides a snapshot of issues, error description and steps taken to
resolve the issues along with SAP notes.

Seria
l #
Issue Type

Error Description Resolution Steps Related
SAP Note
#
1 Transporting Info
packages
Info package with
logical system error or
Info package doesn't
find source system
after import or Logical
system conversion
setting missing.

Apply SAP Note
1644090 and
maintain the logical
system conversion
in RSA1 and
Transport
Connection.
Carry out re-import
after applying note.
1644090
2 Transporting Info objects

Errors occurred during
post- handling
RS_AFTER_IMPORT
for IOBJ L.
Inconsistency between
number range object-
IOBJNM and maximum
SID.

Carry out RSRV
check Comparison
of Number Range
and Maximum SID"
for characteristic
0IOBJNM to
determine whether
there is an
inconsistency
between the
number range
object and the
maximum SID.
In case of
inconsistency
remove the error via
using RSRV
Correct Error


NA
3 Transporting Error DTP

Error while
transporting/overwriting
Error DTP. DTP in
version M/A does not
exist.

Apply SAP Note
1643318
Re-import the set of
Error DTP's.

1643318
4 Transporting Process
Chains

Error during remote call
of destination ' ... ' -
RSPC051"

Apply SAP Note
659160
Re-import the
affected process
chains.

659160
Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 27


Seria
l #
Issue Type

Error Description Resolution Steps Related
SAP Note
#
5 Activating transported BW
objects

Capturing the activated
Data source in the
transport package
results in an error with
the message "Invalid
call sequence for
interfaces when
recording changes"

Apply SAP Note
1612875
Re activate the
object and capture
in the transport
Import the new
transport to the
target system.

1612875

6 Transporting
transformations

Transport getting
cancelled with return
code=12
Check
table RSTRANRO
UTMAP for the
affected
transformation, see
if field CODEID is
blank, delete the
rule explicitly
Re import the
transformation as
explained in
detailed section
983036
7 Objects not locked
properly in the Transport
request
Few of the objects in
BW transports didn't
have object directory
entry, hence gave error
on releasing the
transports.

Manually create
object directory
entries for the
missing elements
Release the
transport
NA
8 Object locked in multiple
transports
BW Objects get locked
in multiple transports
which give error while
releasing the tasks
Check for the
existence of object
in other transports
and make sure the
objects are released
or merged with
current transport.
Follow the detailed
NA

2. Technical Areas Explored:

1. Error Stack: A request-based table (PSA table) into which erroneous data records from
a data transfer process is written. The error stack is based on the data source, that is,
records from the source are written to the error stack. Please navigate to the below link in
order to know more about it.

http://help.sap.com/saphelp_banking60/helpdata/en/42/fa1acfcf2c1aa2e10000000a4220
35/frameset.htm

2. Referential Integrity: Referential integrity is the property that guarantees that values
from one column depend on values from another column. This property is enforced
through integrity constraints. It prevents users or applications from entering inconsistent
data. Please navigate to the below link in order to know more about it.

Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 28



http://help.sap.com/saphelp_nw04s/helpdata/en/3a/14c43bb7137503e10000000a114
02f/frameset.htm

3. APO BW Data marts: The data mart scenario is one use of the Business Intelligence
capabilities of SAP NetWeaver. The data mart contains a static snapshot of operational
data. The Data Mart portion of APO DP is basically the SAP BW component with all BW
related transactions and objects available.

Please navigate to the below link in order to know more about it.

http://help.sap.com/saphelp_bw320/helpdata/en/80/1a6110e07211d2acb80000e829f
bfe/frameset.htm


3. Generating Datasource from Planning Book:

The steps mentioned below explain the concept of generating datasource from planning book in
APO-BW.

Step 1:
Login to APO system and open the SAP menu. Go to Administration of Demand Planning and
Supply as shown below:




Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 29




Step 2:
This will take you to the S&DP Administration screen as shown below:



Here you will find the list of all the planning areas created in the system for Demand Planning.
Double click on the Planning Area for which you want to create a Data Source.

Step 3:
After double clicking on a particular Planning Area, following screen will appear. Here go to
Extras -> Data Extraction Tools














Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 30






























Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 31



Step 4:
By selecting above option following screen will appear:

















Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 32



Here click on the Generate DataSource and then system will ask for the DataSource name and
other settings.



Note: The DataSource generated will by default have name starting with 9A.
This is as per the SAP standard naming conventions.























Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 33



The various settings that we can do on this screen are: For example, No Extraction of Data
Records without Key Fig Values:




Set this indicator if you want to prevent the system from transferring data records to InfoObjects
in the Business Information Warehouse if all key figures in the data record have the value zero.
Depending on your data this can drastically reduce the volume of information that the system
transfers, and as a result improve performance.




















Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 34





In the lower box you specify how many data records are transferred in one package. When
transferring large data volumes it is essential that the data is split into packages to avoid memory
problems. When the source system has finished reading the data packages, it is transferred to
BW and processed further. In this box it is possible to change the default for all data extraction in
the system or just the value for the current planning area.























Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 35



Parallel Processing Profile



You can also enter a parallel processing profile that you have previously created in Customizing
(Demand Planning -> Profiles -> Maintain Parallel Processing Profile). This determines how and if
the reading and transfer of the packages is split into parallel processes. As such the block sizes
that you enter in the parallel processing profile should be significantly smaller than the package
sizes above.





















Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 36



Step 5:
With the following options we can test, transport or replicate the DataSource.



















Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 37



4. Resources and References:

Authors:

Srinivas Dodda
Consultant (USI- Hyderabad)
srdodda@deloitte.com

Shinku Chadha
Consultant (USI- Delhi)
schadha@deloitte.com

Rahul Mahajan
Consultant (US-Philadelphia)
ramahajan@deloitte.com

Reviewers:

Mohammad Ashraf
Senior Manager (USI-Hyderabad)
mashraf@deloitte.com

Santosh Taware
Manager (US-Chicago)
staware@deloitte.com

Links:

http://help.sap.com/saphelp_scm50/helpdata/en/8f/9d6937089c2556e10000009b38f889/frameset
.htm
http://www.sdn.sap.com/irj/bpx/index?rid=/webcontent/uuid/240738f8-0a01-0010-4889-
bd254c570cd4
https://kx.deloitteresources.com/default.aspx
https://kx.deloitteresources.com/C14/USInformationManagement/default.aspx





















Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 38



Rapid Deployment Solution

2/14/13 Business Warehouse P a g e | 39


About Deloitte
Deloitte provides audit, tax, consulting, and financial advisory services to public and private
clients spanning multiple industries. With a globally connected network of member firms in
140 countries, Deloitte brings world-class capabilities and deep local expertise to help
clients succeed wherever they operate. Deloitte's 165,000 professionals are committed to
becoming the standard of excellence.
Deloitte's professionals are unified by a collaborative culture that fosters integrity,
outstanding value to markets and clients, commitment to each other, and strength from
cultural diversity. They enjoy an environment of continuous learning, challenging
experiences, and enriching career opportunities. Deloitte's professionals are dedicated to
strengthening corporate responsibility, building public trust, and making a positive impact in
their communities.
Deloitte refers to one or more of Deloitte Touche Tohmatsu, a Swiss Verein, and its
network of member firms, each of which is a legally separate and independent entity.
Please see www.deloitte.com/about for a detailed description of the legal structure of
Deloitte Touche Tohmatsu and its member firms. Please see
http://www.deloitte.com/us/about for a detailed description of the legal structure of Deloitte
LLP and its subsidiaries.
Internal Usage Statement
This publication is for internal distribution and use only among personnel of Deloitte Touche
Tohmatsu, its member firms, and its and their affiliates. Deloitte Touche Tohmatsu, its
member firms, and its and their affiliates shall not be responsible for any loss whatsoever
sustained by any person who relies on this publication.
Copyright 2012 Deloitte Development LLC. All rights reserved.
Member of Deloitte Touche Tohmatsu

S-ar putea să vă placă și