SAP BW Rapid Deployment Solution for APO_v1 6

5/24/2018 SAP BW Rapid Deployment Solution for APO_v1 6

1/39

SAP NetWeaverBW 7.3:

Rapid DeploymentSolution for AdvancedPlanning andOptimization-DemandPlanning

For Internal Reference Only


2/39

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


3/39



Overv iew:

This document provides a means of rapidly deployable business warehouse data architecture solution forimplementing 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 aninsight about specific interfaces from BW perspective that focuses on real world business scenario andgives an overview of demand planning functionality.

Scope Defin i t ion:

In Scope: SAP BW Data Extraction, Modeling and Reporting Solution for Demand Planning modulespecific 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 generalapplication flow which will help users to gain insight about Demand Planning component and its usage fordifferent 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


4/39



SAP Demand Planning Flow Overview:

Please refer the Figure 2 for SAP Demand Planning Flow Overview. This information is an importantingredient which should be understood by BW developers in order to execute SAP BW and SAP APO-DPIntegrated 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 beforethey start with actual development. Understanding these factors before implementing the BW solution canavoid 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

APOInfocubes

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 yourcompany. Use APO Demand Planning (DP) to create a forecast of market demand for your company'sproducts. This component allows you to take into consideration the many different causal factors thataffect demand. The result of APO Demand Planning is the demand plan. Using the DP library of statisticalforecasting and advanced macro techniques you can create forecasts based on demand history as wellas 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 differentdepartments.

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'sproducts and produce a consensus demand plan.


5/39



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 usedin 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. InDemand Planning, the characteristics can be either standard characteristics and/or ones that you havecreated yourself in the Administrator Workbench. Characteristics determine the levels on which you canplan and save data.

The master planning objects structure is the structure on which all other planning objects structures arebased.

A master planning object structure forms part of the definition of a planning area. The existence of amaster 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 definedsuch 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. Thecreation and use of aggregates is optional. The data is always saved on the lowest level of detail. Ifaggregates exist, the system saves the planning data on the defined aggregate levels as well as on thelowest 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.


6/39



Time Series Objects and LiveCache:

1. Time Series: Before you can create and work with planning books, you must create time seriesobjects 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 seriesobjects and see which time series objects exist for a planning area. It is possible to extend thetime series into the future and delete the last periods from LiveCache by reinitializing the timeseries 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 fordifferent kind of data like sales orders, manufacturing orders, stocks, planned independentrequirements, etc. In Live cache data is stored based on Time series and order series. LiveCacheis 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 inDataCache in LiveCache, and if most of the data is stored in LiveCache, this means data is onmemory.

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. Thisstorage method is suitable for tactical, aggregated planning. It is the usual method for savingcurrent Demand Planning data.

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

3. InfoCubes: The data is stored in an InfoCube in the Administrator Workbench. This storagemethod 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.


7/39



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

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 oneplanning 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 planningbook 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 planningarea.

5. Aggregate levels on which data can be stored in addition to the lowest level of detail in order toenhance 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 ofInfoCubes.In the InfoCubes, you store actual data and older planningdata. If you have a data warehouse, such as the SAP Business Information Warehouse (BW), the DPdata 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 separateBW system.

The data mart setup process consists of the creation of InfoCubes in APO and the loading of actualand/or planned data. Actual data can be used as input for time series forecasting or causal analysis, orfor a comparison of the demand plan with actual demand. Planned data could consist of forecastssubmitted by individuals or departments, such as product line forecasts from sales representatives.
http://help.sap.com/saphelp_scm50/helpdata/en/36/1878606bca5d02e10000009b38f983/content.htmhttp://help.sap.com/saphelp_scm50/helpdata/en/36/1878606bca5d02e10000009b38f983/content.htm


8/39



Macros:

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

Planning book:

The most important tool of the demand planner is the planning book. With it, you can design the contentand layout of the interactive planning screen so that it corresponds to your planning requirements. In theplanning 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 andplanning 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, andaccessibility of the view for other users (there is no limit on the number of views you can havewithin 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.

Assumpt ions :

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 thatthey 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 ordistribution sites.

7. Alert Monitor to report exceptions are not the part of this solution.8. A toolkit of statistical forecasting techniques.


9/39



Technical Appro ach and Arch i tecture:

Technical Components:

1. SAP BW 7.32. SAP SCM 7.023. SAP ECC 6.05

Comparison Analysis:

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

Data modeling solution for implementing APO-Demand Planning requires BWs data warehouseworkbench in order to stage data for planning purpose. In addition BW environments reporting concept isrequired 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 whichcompletely determine whether we need to use separate BW environment or the BW environmentcontained in the APO- DP..Below table provides comparison analysis for two options for maintaining BW environment. Options areweighed 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 forAPO-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 lowerinvestment and another reduction of complexity and maintenance. So, the choice depends very much onthe reporting requirements.

SAP recommends usage of different instances of BW and APO.BW serves as a Data Consolidation andReporting 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 originalInfocubes that also holds the new sales-data.


10/39



Reporting is defined and performed on the BW-System. BW is tuned to make quick and efficient reportingpossible using tools like compression, aggregates and the entire set of OLAP-Functions. BW is also theright 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 informationnot 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 thesolution.

SAP Solman 7.1(SLM)

SAP ECC 6.0

SAP SCM 7.0

SAP BW 7.3

SAP PI 7.3IBM MQ Series

(Middleware)

Legacy Systems(Facility)

Legacy Systems

IBM Datastage 8.5

SAP EP 7.0EHP1 SPS5

SAP GUI 7.0

SSO

RFC

IDOC

IDOC

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


11/39



Implementat ion 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 variousbusiness legacy environments located in different regions and placing it on SAP Applicationservers.

2. Data Volume Handling Capabilities: This factor involves consideration of database sizes forBW 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 soas it should act as a unified data warehouse for different regions, and should have the ability toreport data in planning books at specified time intervals.

4. Usage of Middleware and ETL Tools: Itsquite critical to select appropriate technical tools formiddleware and ETL tasks. Common tools used for these tasks are mainly Datastage, SAP PIand SAP BW in-house environments.

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

Solut ion Detai ls :

The solution details described in this section gives a jump start to businessanalysts/consultants/developers in order to implement APO-Demand Planning data modeling solutionwith 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 andadaptability to different sectors and business scenarios.

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

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


12/39



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 SAP s 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 inApplication 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 Errorfolder.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 .


13/39



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 usingABAP and UNIX level commands. This task should be carried out by an experienced ABAPdeveloper.


14/39



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 whilerunning 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_.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 regiongets separate name and it can be leveraged by different infopackages( BACKORDER refers tobusiness 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 priorexperience 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 bemaintained consistent across different environments. Number range indicates the kind of format andlength specifications for material data values.In case of data being loaded from legacy environments, there is always a possibility of bad data, numberrange settings make sure that data entering in SAP environments adheres to certain format and lengthstandards.

Configuration:

Use TCODE-OMSLin different environments such as APO-BW, BW and ECC and maintain same kind ofsettings. This makes sure that when material values are transferred from one system to another, theybehave 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 fromflat files and then send it to higher data targets in BW via extraction and transformation logic.


15/39



Flat file Datasources are created via standard BW Administrator Workbench and are mapped to BWDSOs and cubes via standardtransformation 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 across-application component (CA) of the SAP system.

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

LSMW-Features:

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

1. Read data (legacy data in spreadsheet tables and/or sequential files). You can use anycombination 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-(LegacySystem 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 anexperienced ABAP or Techno Functional resource who has prior experience of configuring master data inECC.

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, Customerand Material Plant.

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

Material Attribute: 0MATERIAL_ATTRMaterial Text: 0MATERIAL_TEXT

Customer Attribute: 0CUSTOMER_ATTRCustomer Text: 0CUSTOMER_TEXT


16/39



Material Plant Attribute: 0MAT_PLANT_ATTRMaterial Plant Text: 0MAT_PLANT_TEXT

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

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 tofollow architectural standards and mold design as per their business logic.

Below section explains the data modeling solution in order to implement business processes such asForecast 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 tocarry out forecast of market demand for companys products based on differen t 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 byplanning 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 todepict forecast values for materials as per customer and plants.


17/39



BW Data Modeling:

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

L

S

A

Data Acquisition layer

Quality and Harmonization Layer

Data Propagation LayerCorporate

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 variousextraction and reporting scenarios to business. This concept highlights the reusability of data flowtemplates 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 helpcontent 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 anddistributes 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. Datastoreobjects 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 businesstransformation layer.


18/39



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

Architected Data Mart Layer:

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

2. Reporting Layer:This layer is generally constructed with the help of infocubes providing usersan easy and flexible way for dimensional reporting. Infocubes can either be semanticallypartitioned 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 wayof SAP BW reporting. There is not much difference between Reporting and Virtualization Layer. Itdepends on specific scenario.

Operational DataStore:

An operational data store supports operational data analysis. In an operational data store, the data isprocessed 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 foroperative analyses.

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

Recommendations:

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

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

Use Business Transformation layer in order to carry out complex business logic transformations and thenmake 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 andimplement inbound/outbound interfaces for specific business lines solution.


19/39



The below diagram provides interface overview for APO-DP and BW. Please note that this diagram is amere adaptation of a generic interface, developers can modify the design within each environment as perthe 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.


20/39



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

Developers need to follow the same concept of Enterprise Data Warehouse and Architected Data MartLayer 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 rundatawarehouse and reporting solution.

Users can refer to below Data flow diagram which is a citation from actual project implementation. Thelayers 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

ER

F

A

C

E

Datasource/

DataMarts

DSO

I

N

T

ER

F

A

C

E

Datasource/

DataMarts

PlanningBook

APO- BW BW

DataAcquisition

Layer

DataPropagation

Layer

Data

Propagation

Layer

Data

Acquisition

LayerDSO

Data

Propagation

Layer

File on

Server

OUTBOUND

FLOW

Figure 7b


21/39



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 designedconsidering 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 businesslogic.

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 independentof other region. Users can leverage standard Copy Functionality Wizard to copy process chainsfor one region from other.

5. Add Customize program to move legacy files from one folder to another as a process step afterBW 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 fromNEW to PROCESSED folder otherwise it move from NEW to ERROR folder (in case ofinfopackage load error).

Below is an example Process chain for Inbound flow within SAP BW 7.3 , this is just for usersreference 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-BWenvironment:

1. Create Master Data Attribute chain comprising all key master data required, as per businesslogic.

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 usersreference and they can mold it as per their business requirement.


22/39



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 viaregional 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 referenceand 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.3environment:

1. Create transaction data chain comprising Datamarts loads from APO-BW data targets viaregional 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 referenceand 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 anexperiences SAP BW developer.

Job Scheduling Strategy:

This section drives the importance of scheduling process chains in such a manner that different regionsget forecast data as per their Timezone settings. Consider a scenario where a business is implementingDemand Planning Solution for regions such as US, UK, China and Europe. In that scenario it becomescritical to schedule process chain in such a manner that system gets updated data as per their regionslocal 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. Thismakes sure that BW process chains only start if there is valid file on SAPs Application server andavoids any unnecessary file loads.


23/39



3. Once Master Data Chain is finished then run Transactional data chain in BW, and then executetransaction 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 productionenvironments is always an arduous task for BW developers. In recent times, it has been observed thatmost of the implementation projects suffer serious risk related to business timelines when it comes tocutover 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 developmentenvironment.

2. Maintain proper naming convention for the transports in order to avoid confusion in laterstages.

3. Segregate the objects collection as per each object type and functional area, for examplea transport request for Inventory cubes should be different from transport request forbackorder 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 programRSO_TLOGO_CHECK_REQUEST in order to see if there is any missing dependentobject which is required for the transport.


24/39



Cutover Strategy:

1. Create a step by step detail cutover plan listing down all manual tasks and assigneach 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 issueswithin cutover window.

4. Make sure to replicate Datasources/data marts in BW and APO-BW in case ofdatasource transports.

5. Perform a sanity check of all transported objects by looking in the target systemand 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 themethodology implemented while executing these tasks. Its just an overview and canvary from project toproject.

Team Struc ture:

Please refer Figure 8 for the proposed team structure.

Manager

SAP / (IM BI/DW)

IM BI/DWSAP

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


25/39



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

Timel ines:

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

Figure 9


26/39



Appendix :

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

Serial #

Issue Type Error Description Resolution Steps RelatedSAP Note

#

1 Transporting Info

packages

Info package withlogical system error orInfo package doesn'tfind source systemafter import or Logicalsystem conversionsetting missing.

Apply SAP Note1644090 andmaintain the logicalsystem conversionin RSA1 andTransportConnection.

Carry out re-import

after applying note.

1644090

2 Transporting Info objects Errors occurred duringpost- handlingRS_AFTER_IMPORTfor IOBJ L.Inconsistency betweennumber range object-IOBJNM and maximumSID.

Carry out RSRVcheck Comparisonof Number Rangeand Maximum SID"for characteristic0IOBJNM todetermine whetherthere is aninconsistencybetween thenumber rangeobject and the

maximum SID. In case of

inconsistencyremove the error viausing RSRVCorrect Error

NA

3 Transporting Error DTP Error while

transporting/overwriting

Error DTP. DTP in

version M/A does not

exist.

Apply SAP Note1643318

Re-import the set ofError DTP's.

1643318

4 Transporting ProcessChains

Error during remote callof destination ' ... ' -RSPC051"


Re-import theaffected processchains.

659160


27/39



Serial #

Issue Type Error Description Resolution Steps RelatedSAP Note

#

5 Activating transported BWobjects

Capturing the activatedData source in thetransport package

results in an error withthe message "Invalidcall sequence forinterfaces whenrecording changes"


Re activate the

object and capturein the transport

Import the newtransport to thetarget system.

1612875

6 Transportingtransformations

Transport gettingcancelled with returncode=12

Checktable RSTRANROUTMAPfor theaffectedtransformation, seeif field CODEIDisblank, delete the

rule explicitly Re import the

transformation asexplained indetailed section

983036

7 Objects not lockedproperly in the Transportrequest

Few of the objects inBW transports didn'thave object directoryentry, hence gave erroron releasing thetransports.

Manually createobject directoryentries for themissing elements

Release thetransport

NA

8 Object locked in multiple

transports

BW Objects get locked

in multiple transportswhich give error whilereleasing the tasks

Check for the

existence of objectin other transportsand make sure theobjects are releasedor merged withcurrent transport.Follow the detailed

NA

2. Technical Areas Explored:

1. Error Stack:A request-based table (PSA table) into which erroneous data records froma 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 inorder to know more about it.

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

2. Referential Integrity: Referential integrity is the property that guarantees that valuesfrom one column depend on values from another column. This property is enforcedthrough integrity constraints. It prevents users or applications from entering inconsistentdata. Please navigate to the below link in order to know more about it.
http://help.sap.com/saphelp_banking60/helpdata/en/42/fa1acfcf2c1aa2e10000000a422035/frameset.htmhttp://help.sap.com/saphelp_banking60/helpdata/en/42/fa1acfcf2c1aa2e10000000a422035/frameset.htmhttp://help.sap.com/saphelp_banking60/helpdata/en/42/fa1acfcf2c1aa2e10000000a422035/frameset.htmhttp://help.sap.com/saphelp_banking60/helpdata/en/42/fa1acfcf2c1aa2e10000000a422035/frameset.htmhttp://help.sap.com/saphelp_banking60/helpdata/en/42/fa1acfcf2c1aa2e10000000a422035/frameset.htm


28/39



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 Intelligencecapabilities 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 BWrelated 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 inAPO-BW.

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


29/39



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 toExtras -> Data Extraction Tools


30/39




31/39



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


32/39



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

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


33/39



The various settings that we can do on this screen are: For example, No Extraction of DataRecords wi thout 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 systemtransfers, and as a result improve performance.


34/39



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


35/39



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 ifthe 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 packagesizes above.


36/39



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


37/39



4. Resources and References:

Authors :

Srinivas Dodda

Consultant (USI- Hyderabad)[email protected]

Shinku ChadhaConsultant (USI- Delhi)[email protected]

Rahul MahajanConsultant (US-Philadelphia)[email protected]

Reviewers:

Mohammad Ashraf

Senior Manager (USI-Hyderabad)[email protected]

Santosh TawareManager (US-Chicago)[email protected]

Links:

http://help.sap.com/saphelp_scm50/helpdata/en/8f/9d6937089c2556e10000009b38f889/frameset.htmhttp://www.sdn.sap.com/irj/bpx/index?rid=/webcontent/uuid/240738f8-0a01-0010-4889-bd254c570cd4

https://kx.deloitteresources.com/default.aspxhttps://kx.deloitteresources.com/C14/USInformationManagement/default.aspx
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]://help.sap.com/saphelp_scm50/helpdata/en/8f/9d6937089c2556e10000009b38f889/frameset.htmhttp://help.sap.com/saphelp_scm50/helpdata/en/8f/9d6937089c2556e10000009b38f889/frameset.htmhttp://help.sap.com/saphelp_scm50/helpdata/en/8f/9d6937089c2556e10000009b38f889/frameset.htmhttp://www.sdn.sap.com/irj/bpx/index?rid=/webcontent/uuid/240738f8-0a01-0010-4889-bd254c570cd4http://www.sdn.sap.com/irj/bpx/index?rid=/webcontent/uuid/240738f8-0a01-0010-4889-bd254c570cd4http://www.sdn.sap.com/irj/bpx/index?rid=/webcontent/uuid/240738f8-0a01-0010-4889-bd254c570cd4https://kx.deloitteresources.com/default.aspxhttps://kx.deloitteresources.com/default.aspxhttps://kx.deloitteresources.com/C14/USInformationManagement/default.aspxhttps://kx.deloitteresources.com/C14/USInformationManagement/default.aspxhttps://kx.deloitteresources.com/C14/USInformationManagement/default.aspxhttps://kx.deloitteresources.com/default.aspxhttp://www.sdn.sap.com/irj/bpx/index?rid=/webcontent/uuid/240738f8-0a01-0010-4889-bd254c570cd4http://www.sdn.sap.com/irj/bpx/index?rid=/webcontent/uuid/240738f8-0a01-0010-4889-bd254c570cd4http://help.sap.com/saphelp_scm50/helpdata/en/8f/9d6937089c2556e10000009b38f889/frameset.htmhttp://help.sap.com/saphelp_scm50/helpdata/en/8f/9d6937089c2556e10000009b38f889/frameset.htmmailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


38/39




39/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 itsnetwork 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/aboutfor 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
http://www.deloitte.com/us/abouthttp://www.deloitte.com/us/abouthttp://www.deloitte.com/us/about

Documents

SAP BW Rapid Deployment Solution for APO_v1 6