SAP BW / BI. For more information, visit the EDW Homepage
This document contains the overview of SAP APO Demand planning in terms of BI consultant to understand the purpose and the flow of DP.
Author: Archana Suresh
Company: Cognizant Technology Solutions
Created on: 27 November 2012
Archana Suresh is working with Cognizant Technology Solutions with 6.1 years of experience. She is currently working on SAP BI 7 / BI 7.3 and has experience of BW 3.5 as well. She worked on different areas in BI/BW like extracting, modeling, reporting and production support.
Business intelligence is an ETL tool provided by SAP to analyze the data in feasible way to make decisions on their business. BI includes historical data i.e. actual sales or transactional data which are extracted from R3, non R3 and non-SAP systems where end users directly input their sales and other details in the system in different formats. Historical data provided by BI is not only used for understanding the sales that has happened in the past but also to plan for future to make their business transactions better. As historical data is generally recorded in R3, SAP has provided a planning tool called APO to plan their data of their business. With these information users can compare the actuals vs plan data in a single report and make their business better.
SAP has introduced a planning tool called APO – Advanced planning and optimization. With this tool planners analyze the historical data and measure the growth and falloff trends in their business and plan their productivity correctly in the future to make their business better.
APO in SAP
APO is a component of Supply Chain Management (SCM). SCM cycle includes the whole process of a product i.e. starting from manufacturing / raw materials till a complete product is delivered to the customer. It also provides details of all the vendors / distributors / customers involved with the product life cycle. It also includes the feedback from customers i.e. flaws about their products. In simple words, SCM is a whole picture of inflow and outflow of a product from the beginning till it reaches the destination.
APO – Planning tool
Advanced Planning and Optimization is a planning tool which is used to plan a complete life cycle of the product which includes the manufacturing plan till the transportation planning.
Modules of APO
Demand Planning (DP)
Supply Network Planning (SNP)
Production Planning and Detailed Scheduling (PP/DS)
Transportation Planning and Vehicle Scheduling (TP/VS)
In APO, planning is done in the same sequence in which it is mentioned above.
Understanding of APO Modules
Demand Planning is a standalone forecast tool from which data is provided to other modules of APO. Here forecasting is done based on historical data. Demand planning is the first step in APO planning; planners do their forecasting for long period and at very higher level.
Supply Network Planning
Supply Network planning is a cross-location, mid to long-term production and procurement planning method. Supply network planning is the second level of planning by the planner’s i.e. once the demand planners are done with their planning they will release their data to SNP based on which SNP planners will do their forecasting.
Production Planning and Detailed Scheduling
PPDS planners do their planning at very detailed and lower level. Based on the SNP planner’s data, PPDS planners forecast their data for days and hours basis. As the name indicates, planning done at this level will be used for immediate production requirement and distribution requirements. Material and capacity requirements are mainly considered here which is required for in-house production, external procurement, and stock transfer in a production plant at operation level.
Deployment is nothing but executing the best shipment process referring the best practice distribution planning process. The recommended shipment method will be then used by the transport planning system to process further.
Transportation Planning and Vehicle Scheduling
APO allows the business to even plan the routes while delivering the products to their customers. Every zones and lanes that their trucks should use while transporting the goods will be planned here by the planners considering the time, real time scenario’s etc.
TP considers all the resources availability like vehicles, roads, goods and the number of packaging boxes etc. They optimize every sequence of transportation which includes the number of items to be placed in a package till it reaches their customer on the promised date.
This provides the high level view and the activities in APO. As a BI consultant, we will be dealing mostly with Demand planning, as demand planning needs historical data, BI provides it in the way they need it. So let us understand the master data and transaction data flows and concepts and about few transactions in APO with which BI consultants will be dealing.
Let us consider a real time example to understand DP better.
A customer from moderate weather region is requested for 5000 pullovers in month of 1st quarter of the year, 1000 pullovers in 2nd quarter of the year, 4000 pullovers in 3rd quarter of the year and 10000 pullovers in last quarter of the year. DP planners will consider last 3 or 5 years approximate and will do their sales forecast accordingly. This might differ from region to region, as the sale in tropical region will be lesser than this count and the sale in temperate region will have more counts.
So the demand planners do their forecasting at higher level and also for longer period. Generally forecasting is done for 18 months based on 24 months of historical sales data. (It might differ from business to business). Actual transactional and historical sales data will be extracted from R/3 and BI systems to APO. Users do their business transactions in ECC and that will be referred / used to plan the activities for future in APO by planners.
APO Demand Planning – How it works
CVC is the master data of APO Demand planning. As the name indicates, all the characteristics which are considered as the key fields will be grouped together and the planning will be done based on these characteristics values combinations.
While loading the CVC to the planning books, if any of the CVC value is empty, then it will throw an error.
Data for CVC i.e. master data objects will be loaded from standard BI master data objects to SCM BI objects and then to CVC objects.
T-code to access CVC maintenance screen: /SAPAPO/MC62
(Master data from SCM BI will be loaded to corresponding CVC objects via this t-code; this activity will be done by APO consultant generally)
SAP provided live cache to access the planning data in APO for the ease of data accessibility and to perform the complex algorithmic activities very quickly even during the run time. Live cache is nothing but a RAM which will be running on the APO server; all the planning data will be directly captured and managed on live cache. Live cache will act multiple times faster than normal data base for run time calculation while having large number of data.
Planning is generally done in planning books which are part of planning areas. Planning area will look similar to work book and planning books can be considered as multiple sheets in the work book. A planning area can have multiple planning books whereas one planning book can belong only to one planning area. These planning areas will be part of live cache.
T-code to access Planning books / Planning areas: /SAPAPO/SDP94
(After selecting the planning book from the left pane, based on the selections provided the corresponding historical and planning data will be seen in the right pane – tabular column like structure)
T-code to create planning areas in APO: /SAPAPO/MSDP_ADMIN
Every planning area should be created based on MPOS (Master planning object structure). MSDP_ADMIN is used to created MPOS and planning areas. This activity will be done by APO functional consultant.
Role of BI in APO
APO is integrated with BI server in it. APO has standard and specific info objects which will be usually prefixed with ‘9A’. Generally info objects, DSO’s and cubes are created separately in SCM BI and it is integrated with standard BI through data sources. Master data and historical transactions data are loaded from standard BI to SCM BI and then from SCM BI the data will be loaded to the planning books.
BI standard info objects will be prefixed with ‘0’ whereas APO info objects will be prefixed with ‘9A’. While creating characteristics we can create it either as a BI info object or APO info object. But while creating key figures it is important to create it as APO info object, if not we will not be able to fix any values or quantities to that key figure (locking the values of the key figure as we will be using the same key figures in the planning areas too). Also when it is created as APO key figure, an additional field will be included which helps to input other key figure name which will hold “Notes” details. If the key figure is created as BI key figure, while taking the data back from planning book to the cubes, the information provided in the “Notes” in the planning area will be lost.
Master data could be loaded either from standard BI / R3 systems / flat files.
Functionality of DSO and info cubes in APO is similar to BI. DSO’s will exclusively act as acquisition layer. Data to planning books can never be loaded from DSO. So the data from Standard BI system will be staged in the DSO and loaded further to info cubes. All the transactional data (historical data) will be loaded to the planning books from the info cubes.
Every info cube should have an info object VERSION to load the data from that cube to the planning areas.
Actual sales history data (transactional data) will be extracted from standard BI system to SCM BI system.
Modeling of these objects and flow in APO system will be can be done either by BI consultants or APO-BI consultants, but data loading and monitoring of the processes from standard BI system will be usually taken care by APO consultants itself
Data loading process
T-code to load data from info cubes to planning area: /SAPAPO/TSCUBE
In this t-code the assignments between the cube info objects and the planning area info objects will be done. This activity is similar to the transformation source and target fields mapping in BI.
Once the data is available in the cube, we can load it the planning areas by providing the source name as the cube name and the target name as the planning book along with their versions.
Data to the planning areas cannot be loaded from DSO’s, because data cannot be loaded from normalized table. It can be loaded only from dimensional table.
The mandatory fields while loading are:
- Source: Cube name (If you check the F4 help, you can find only info cubes)
- Planning version under source should be an actual version that is available in the cube.
- Target: Planning area name
- Planning version under target should be a planning version that has to be updated in the planning area.
- Fiscal year period: Period for which the data has to be loaded
Generally during this activity, version of the data will be changed from actual to planning version.
Similar to data loading, we can also provide selection conditions (loading for specific selected data) and grouping conditions (similar to identifying semantic keys in DTP). Also we need to provide for which fiscal year period the data has to be loaded, it is also a mandatory field during this process.
Apart from these settings, we can provide additional settings as given below.
Once all these details are provided, we can execute the loading process either in the frontend or in the background.
Actual job of the BI consultant starts from this step.
Once the data are planned in the planning areas based on the actual historical data, to extract it back to the BI cubes, we need to create data sources on the planning books.
T-code to extract data from planning books to info cubes: /SAPAPO/SDP_EXTR.
This is similar to the extraction tool from other SAP systems to BI system.
We need to provide the planning area name, from which the data has to be extracted and provide some name for Data source and while clicking on ‘Generate data source’ it will generate a data source with the prefix ‘9A’. Here we can choose the fields for which the data has to be transferred from APO to BI system.
While creating data source, we can also determine how many records has to be transferred to BI in one data package (similar to DTP data package size).
These data sources are later replicated in standard BI and now we can extract the data from planning areas to BI.
Apart from generating the new data source, we can also display / change / check / repair / test / replicate / transport / delete the data source from this screen.
Generally while extracting data from planning area to the cubes, planning areas will be locked to the users to avoid inconsistency of the data.
Reporting on the planning area
We also have an option of creating backup cubes and reporting object from this transaction code by clicking on the button “Data Backup” and “Ad-Hoc Reporting” buttons respectively for a particular planning area.
Sometimes small businesses will not use separate BI system, they will use only SCM BI which will be used as a planning tool and also as a reporting tool. Reports can be created directly on the planning areas or on the SCM BI cubes.
To create a report directly on the planning area, select Ad-Hoc reporting, option to create virtual cube will be displayed, provide all the necessary details. Now the query will be automatically built on the newly generated virtual provider.
Data backup for the planning area
Apart from the BI historical data, all the data in the CVC objects and the planning objects will be taken as a backup to the APO cubes. In real time scenario, by any chance if the data in the planning book is deleted then it can be restored from these back up cubes.
By clicking on the data backup button, the following screens will appear from which cubes will be automatically generated.
Data Loading from SCM BI to standard BI
Based on the data source created, we can load the data directly to standard BI data targets or to APO targets and then to standard BI by using ‘Extract data source’ option on the APO cubes.
Once the data are loaded to standard BI, we can do all other activities as required, building the reports as per the business requirements on the cubes / sending the data to open hubs if required / manipulating the data for further usage to represent it as the business needs etc.
Few tips and points to remember regarding APO and BI flow
§ DP data will be released to SNP and SNP data to PPDS and PPDS to other modules.
§ Key fields of the planning area is called as CVC in APO
§ Data extracted from standard BI to APO is called as inbound data flow.
§ Data extracted from APO to standard BI is called as outbound data flow.
§ Data can be loaded only from multi-dimensional objects (info cubes) to the planning area.
§ Version and fiscal year period play important role while loading data from cubes to planning area.
§ As the planning book will be locked during the data extraction, it is always better to have two process chains, first one to extract the data to PSA and unlock the planning area. Second one to do a data mart loading in BI.
§ While sending the data from BI to APO, validate and remove the invalid CVC combination’s data to reduce the loading time and to make sure only valid data is sent to planning area.