Optimizing your APO Demand Planning (DP) reporting and work processes is based on the dynamics of data flow from APO DP into its reporting engine, SAP Business Information Warehouse (BW). By explaining the relationship between APO and BW, I'll show demand planners and managers, sales managers, BW analysts, and BW and APO developers how to create useful, comprehensive reports in the BW environment. In addition, I will provide tips on how the APO and BW teams can work together efficiently. The collaboration between APO and BW teams ensures maximum efficiency of the systems and should lead to effective reports for the end-user community.

The BW team must consider design and development factors of the BW architecture when introducing DP data. Keep in mind the following data-related factors:

• Data volume and historic information storage
  
  
• Load management
  
  
• Transformation requirements, data realignments, and data manipulations in DP and its implications
  
  
• Time stamping and version management

Key reporting considerations include:

• Key performance indicators (KPIs)
  
  
• Reporting requirements
  
  
• Frequency

The previous points as well as the BW and APO installation scenario determine the BW architecture. Figure 1 shows a recommended BW architecture. For instance, it is a good idea to decouple the most current DP results from previous DP results by storing the most current results and previous results in separate InfoProviders. The majority of DP reports are executed using the latest DP results and keeping the dataset small by using a separate InfoProvider expedites the process. Additionally, use MultiProviders to generate all the reports for actual, plan, and forecast/plan versus plan comparison-type reporting. This approach reduces development and maintenance efforts for querying.

Figure 1

BW structure for DP-sourced information reporting

It is a best practice to use remote Info-Providers to generate instant reports out of DP. Under normal circumstances, data extraction from DP into BW InfoProviders takes a long time depending on the system architecture and infrastructure (around 14 hours in some cases). For example, demand planners may need to communicate DP results with demand managers and other business owners on a constant basis to get their input. However, a long time lag between the data entry/ forecast run in DP and reporting in basic InfoProviders decreases the efficiency of processes and decision making.

Data Volume and History Storage

In the majority of implementations, accumulated data volume generated by DP during a planning cycle increases over time. Combined with the historic data storage needs of the business, the volume of data needed to be stored in BW increases substantially. Therefore, efficient data management and storage is crucial to the overall design of the BW environment for DP reporting.

Your BW team should consider issues such as the number of DP cycles to be stored in BW (i.e., the number of monthly frozen Sales and Operations Planning [SOP] cycle results). Another factor is the relevancy of data in liveCache for reporting. For instance, if BW has actual data and you do not need to extract the actual information from DP, extract only forecast data into BW and use MultiProviders to generate reports for actual versus forecast comparisons. BW team members should also check whether Persistent Staging Area (PSA) information is needed and should delete any redundant information.

Time Stamping and Version Management

Time stamping is used in the BW architecture for DP results to differentiate among individual planning cycles. Individual businesses may have different planning practices in DP, and these practices may involve using time stamping and versioning in BW for data extraction, storage, and reporting purposes.

For example, planning processes may vary from operational planning to long-term strategic planning, so you may need to distinguish between those planning results in BW if the source of the information is the same. BW developers should ensure that the results of different planning types can be easily differentiated. This in effect increases the efficiency of report generation. BW developers should work with DP developers to develop a versioning strategy and ways to distinguish different planning results in BW InfoProviders. Such an approach requires exact versioning logic while loading information from DP into BW to allow for an accurate comparison between operational and strategic plans.

In addition to these factors, a majority of businesses require time stamping for historic plan information to differentiate among different planning results for forecast accuracy and trend analysis-type reporting. For example, you might want to compare variance analysis between the forecast generated for May 2005 in the January 2005 planning cycle and the forecast generated for May 2005 in the February 2005 planning cycle.

BW developers can use the following step-by-step process for time stamping DP information while loading the data from liveCache into BW:

1. Create an InfoObject. Name the InfoObject Forecast Period and add it as a characteristic to the forecast InfoProvider.
   
   
2. Create a custom ABAP table. The table stores a month of extraction and forecast period data as shown below:
   
   

   Month of extraction	Forecast period
   January 2004	Febuary 2004

   
   A BW super user maintains 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, the user maintains the tables as shown in the example. The BW super user also maintains the table by time stamping data in BW during regular extraction.
   
   
3. Develop a routine to populate the Forecast Period characteristic in the update rules of the InfoProvider.

Data Realignments in DP

The DP realignment functionality enables demand planners to change the characteristic values in liveCache. You have many reasons to consider using the realignment functionality. Perhaps you have obsolete entries in your system. For example, Sales manager of a customer is a full characteristic in DP and the information is stored in liveCache. If Sales manager of a customer is changed due to business reorganization or new assignments, the historical information in liveCache needs to be realigned to reflect the changes. However, if Sales manager is used as a full characteristic in an actual sales InfoProvider in BW, actual versus comparison reports will be inconsistent because of the realignment in DP. To overcome these types of obstacles, define these characteristics as navigational attributes, if possible, in BW and DP to allow for consistent reporting.

Another possible use of the realignment functionality is to correct data. Information coming from BW may need to be changed because of data quality problems. For example, some records in DP may have wrong entry for a characteristic because of a data transformation problem in BW or wrong data entry in SAP R/3. This characteristic information needs to be restated in DP to correct demand information.

Try to minimize the number of realignment runs in DP for a number of reasons. Most importantly, minimizing the realignment runs will increase your DP system performance and hence decrease DP cycle time. In addition, you will enable consistent and correct reporting.

Minimization depends on efficient master data management, including quality, control, and cleansing, within your BW and source systems. If master data remapping and transformation cannot be done in your source systems (e.g., because an invoice with incorrect information can't be further processed when the month has ended), perform these tasks in BW.

Also, maximize the use of navigational attributes in DP if the navigational attribute could be an attribute of other characteristics in DP, if characteristics in your system are frequently changed, or if DP is not used to enter data. In addition, add attributes to characteristics and populate them in BW.

Effective Reporting

You may need several kinds of reports from your DP results. The majority of these reports falls into one of the following categories:

• KPI reporting — forecast accuracy, for example
  
  
• Actual versus forecast comparison, including variance analysis
  
  
• Forecast trend analysis
  
  
• Outlook reporting

The most efficient and flexible approach to generate the above reports is to use a MultiProvider made up of actual (history) and forecast InfoProviders. You must first define the reports and their key elements. Then you should determine how to consistently report the actual and forecast data at different levels via detail analysis of report definition, report components, granularity, and information in BW Info-Providers and mappings. For example, if a high-level customer is used in actual InfoProvider and if you need a report that compares the actual sales to forecasted sales at the high-level customer level, then this field should also be populated in the forecast InfoProvider.

Specify your reporting requirements before the design phase to ensure an efficient design from the start. If you fail to specify these requirements in advance, you run the risk that your BW architecture will be unable to provide all the reports that you need. This is especially important because the reporting structures of the above report categories are affected by changes in design of the BW architecture. Figures 2 and 3 are examples of the reporting categories that businesses may require. Businesses can use these reports to generate annual outlook and trend reports and to plan for the rest of the year. These reports answer the following types of questions: "How I am doing?", "What is the latest estimate for the whole year?", and "Is there a trend in my sales?"

The reports in Figures 2 and 3 use the following characteristic InfoObjects:

• Period forecast made: This characteristic can be used to time stamp and identify planning cycles. In Figures 2 and 3, the period forecast made was set to April to display the latest forecasts for the rest of the year from May to December.
  
  
• Value type: This characteristic can be used to distinguish between actual and forecast data. For example, value type 010 can be used for actual data and value type 020 for forecast data. In Figure 2, the value type was used to differentiate between actual and plan.
  
  
• Version: This characteristic can be used to separately identify plan versions. For example, actual data from R/3 can be identified using version 0 and forecast data from DP using version DP. If some forecast data from sources other than DP is uploaded directly into BW, then you can use the version InfoObject to separately identify this data.

Most of the reports that businesses use to report actual and plan analysis require extensive use of the cell editor, structures, and exit variables. These advanced techniques require strong BW report writers.

If the majority of the required reports use information generated through the latest DP cycle results, then use two separate InfoProviders to maximize the performance of the reporting. One of the Info-Providers should store the previous DP cycle results and the other InfoProvider should store the latest DP results. The main advantages of this approach are reduced query runtimes and reduced system and network loads. As DP data accumulates, these advantages become even more obvious.

Another important consideration in the InfoProvider design is the definition of forecast accuracy KPI and the level of data at which the KPI is calculated. If the KPI is defined at a summary level instead of the detail level, then there are two options. One choice is exception aggregation in the key figure definition (i.e., the information only makes sense at a certain level) and the other is definition of specific aggregates in DP and extraction of the aggregated information into a different InfoProvider other than the regular detail-level DP InfoProvider.

In DP, statistical measures such as mean absolute deviation and coefficient of variation can be used to perform forecasting. These types of measures are meaningful only at the level where they are calculated because of their aggregation properties. To create a report from this information, create an aggregate in DP. Then build BW InfoProviders based on this aggregate definition via defining DataSources out of that specific DP aggregate and extracting the information from DP into BW InfoProviders.

Data extraction from liveCache takes a long time as a result of data volume and hardware specifications. This prevents instant or near-instant reporting out of liveCache through basic InfoProviders. If you need instant reporting from liveCache information, then build remote InfoProviders and report out of these remote InfoProviders for real-time reporting. Remote InfoProviders do not store data; they read the data during query runtime. Reading liveCache during runtime may be time consuming. To minimize any potential performance problems, remote InfoProviders should be defined in APO-BW and there should be few or no rules in the InfoSources.

DP results are vital to many organizations. The output of DP can be used for:

• Day-to-day operations execution
  
  
• Long-term strategic planning
  
  
• Supply and capacity planning
  
  
• Financial planning
  
  
• Asset management and planning

Efficient DP reporting enables the businesses to achieve their goals while minimizing effort and time spent on data processing and manipulations. In effect, it enables businesses to allocate most of their time and resources to making decisions rather than gathering information and processing data.