Bluestone Consulting Footsteps

Volume 4

In today's business environment, information is the most important asset for the success of
your business. Therefore, timely access to relevant information is becoming increasingly
critical. Many companies have built, or are in the process of building, business data
warehouses in order to effectively access data for business analysis.
Our Business Intelligence team members have been using SAP BI products since the very
early days. We have gained considerable understanding of the SAP BI solution through our
involvement with various projects. We decided to share our experiences via Bluestone's
Footsteps to make it easier for you to become skilled at the SAP BI Suite.
With each issue of Bluestone's Footsteps, you'll get insightful information in SAP BW, SEM
and Portals from the members of our team. Our goal is to lead you to a better understanding
of the BI solution through these articles.
We also want this publication to be a two way communication between you and our team.
We'll be happy to answer your questions as long as our space permits. You can send your
questions to footsteps@Bluestonestep.com .
Thanks,
Bluestone Business Intelligence Team

DISCLAIMER
Although we use extensive care to prepare the articles and responses to your questions in Bluestone's
Footsteps, we cannot assume any liability for its contents.
TRADEMARKS
SAP and mySAP are registered trademarks of SAP AG in Germany and in several other countries. All other
registered trademarks are the property of their respective holders.

Bluestone Consulting Footsteps

Volume 4

APO Demand Planning Data Flow into BW

by Hayrettin Cil, Consulting Program Lead
This paper outlines the dynamics of data flow from APO Demand Planning (APO-DP) into
BW and provides solution algorithms for possible show-stoppers in the integration process.
DP is used to generate demand plan information over the planning horizon. This
plan/forecast information is stored in LiveCache of APO system and export datasource is
used to extract this information into BW.
Important consideration points in the design and development of the BW architecture are:
Data
o Volume and historic information storage
o Time stamping and version management
o Transformation requirements, Data realignments in DP and its implications
Reporting
o Requirements
o Frequency
The point presented above combined with BW and APO installation scenario determines the
BW architecture. The recommended BW architecture is as below:

Figure 1: BW Structure for DP Sourced Information Reporting

Bluestone Consulting Footsteps

Volume 4

DATA VOLUME & HISTORY STORAGE

Under normal circumstances, the data volume generated by DP during a planning cycle
may increase over the time horizon and combined with the historic data storage needs of
the business, data volume needed to be stored in BW may also increase dramatically.
Efficient management of data generation and storage is one of the key points in the overall
design of the BW environment for DP reporting. The most important points that should be
considered are as below:

Check if all the data stored in LiveCache is relevant for reporting and restrict
accordingly while loading the data
Check if all the characteristics and key figures are relevant for reporting and do not
update the redundant characteristics and key figures
Always utilize compression after loading data into the infoproviders
Check if historic PSA information is needed and delete any redundant information

TIME STAMPING & VERSION MANAGEMENT

Individual businesses may employ different planning practices in DP and the usage of these
practices may dictate the usage of time stamping and versioning in BW for data extraction,
storage and reporting purposes.
The planning processes may vary from Operational Planning to Long Term Strategic
Planning. There may be the need for differentiation among these different planning results
in BW. Such an approach requires accurate versioning logic while loading information from
DP.
In addition to the above, majority of the businesses require time stamping for historic plan
information for differentiation among planning cycles and historic forecast analysis
purposes, i.e. variance analysis between the forecasts generated in January 2003 and
February 2003 for year 2004.
Below is a possible step by step solution for time stamping the Plan information while
loading the data into BW:
1. Create an infoobject (in our example Forecast Period) and add this infoobject as a
characteristic to the infoprovider storing DP information.
2. Create a custom ABAP table as below:
The user enters maintain this table based on the following logic:
If the DP data is to be extracted in calendar month January and if the DP
information corresponds to the Forecast generated as of February, user
maintains the tables as above.

Bluestone Consulting Footsteps

Volume 4

Figure2: Custom ABAP table for storing forecast period information

The user enters maintain this table based on the following logic:
If the DP data is to be extracted in calendar month January and if the DP information
corresponds to the Forecast generated as of February, user maintains the tables as
above.
Such table maintenance also allows correct time stamping of DP information if the data
needs to be reloaded from PSA for previous periods, i.e. if for any reason there is a need to
reload September 2003 generated DP information into the cube during January, the user
will enter January 2004 in month of extraction and September 2003 as the forecast period.
3. In the update rules of the infoprovider, a routine is developed to populate the
Forecast Period characteristic.
TRANSFORMATION REQUIREMENTS, DATA REALIGNMENTS IN DP AND
IMPLICATIONS
It is highly critical to design all the possible data transformations in advance in the case of
DP related BW developments. This is mainly due to the fact that there are 4 possible
different infoproviders from content and technical perspectives.
DP realignment functionality adds additional challenges to the transformation processes
from a BW perspective. There are several reasons behind the usage of realignment
functionality:

Obsolete entries
o i.e. material group is used in DP as a full characteristics and because of
product catalog reorganization, some of the previously used Product groups
may become obsolete but there needs to be a reorganization of the data to be
able to display the history information correctly and reclassified if these
changes are not reflected into BW historic actuals infocube and is not updated
into DP
Data Corrections
o Information coming from the BW may needed to be changed because of
quality concerns, i.e. wrong or non-conforming entries coming from material
master
Remapping

Bluestone Consulting Footsteps

Volume 4

o i.e. instead of individual entries by customer group in customer master, a

generalized customer group entry may be used for data entries in DP
Despite the fact that it is a powerful tool to use, utilization of realignment functionality
adversely affects the BW reporting especially in the case of actual vs. plan comparison type
reporting requirements as the data that is generated through DP will have a different
characteristics set than the actual data.
Minimization of the use of realignments mostly depends on the following points:

Efficient master data management (quality, control, cleansing) within BW and Source
systems
All possible master data remapping and transformation within BW (if cannot be done
in source systems)
Maximization of the use of navigational attributes in DP planning books
Addition of extra attributes to characteristics and the population of these in BW