1. Business Planning & Simulation and BW Monitoring
UNWBW1 – Business Information Warehouse
NetWeaver Support Consultant Training

2. BW-BPS Business Planning & Simulation Monitoring & Technical Risks
Content
Introduction
Reporting
Business content
Data loading
InfoCube Design
Aggregates
BW-BPS Business Planning & Simulation
Monitoring & Technical Risks

3. General Concepts of Planning
Business Planning & Simulation (BPS) enables you to produce planning applications.
Actual data is available in InfoCubes, Planning data is to be determined in planning sessions. There are two main directions:
Top Down
Bottom Up
Manager
· per business unit
· per quarter
Regional Manager
· per region
· per month
Regional Sales Manager
· per customer
· per article
Since BW Release 3.5, the Planning functionality from SEM (SEM-BPS Business Planning and Simulation) is included in BW, named BW-BPS. It allows for the creation of planning applications in order to determine planning data with the help of customizable planning functions. Planning operates on data available in BW-InfoCubes.
A planning process in a company can be carried out as a top-down, a bottom-up process or as a mixture of both. BW-BPS supports the modeling of business-wide planning scenarios considering the organizational company structure, providing inclusion of master data and transactional data, planning tools (manual planning, planning functions) and monitoring tools (status & tracking system). An Example for a top-down scenario (based on a product hierarchy):
On Planning Level 1, the Board of Directors plans an increase of sales revenues of 10% for all product groups.
On Planning Level 2, the sales managers for each product group allocate the goals set by the management to their product groups.
On Planning Level 3, the employees responsible for the single product groups start planning on the single products belonging to their product group, distributing the aims for the product group to the products.
In a bottom-up process, these plans from low level are verified/approved and passed on to the higher level of planning
Planning is performed on different aggregation levels of data by different employees responsible for certain areas of business. This can be modeled using the hierarchy of planning objects (areas-levels-packages).
Aggregation
Allocation

4. Objects in Planning (I)
Planning area: A standard planning area is assigned 1:1 to an InfoCube (not necessarily transactional), either local or in a remote system. It provides all characteristics and key figures contained in the InfoCube. Data can also be restricted by using characteristic relationships. A Multi planning area is a view over several standard planning areas.
Planning level: A planning area can be divided into planning levels via restriction to a subset of characteristics and key figures and by selecting certain characteristic values.
Planning package: A planning package is actually used for planning functions or manual planning. It is again a subdivision or subset of a planning level using further restrictions on characteristic values provided by the planning level. A planning level always contains the planning package 0-ADHOC, with selections identical to the planning level.
Planning Area
Planning Level
Planning Package
...
For structuring the planning environment/modeling the planning architecture, several hierarchical elements are available, representing different levels of detail.
Starting with a Planning Area (which equals to an InfoCube and all its characteristics and keyfigures), one can create multiple planning levels in order to restrict the data according to specific business planning requirements (e.g. restrict to a costcenter, then to a region or a product category). These restrictions can be realized via choosing a subset of characteristics and keyfigures from the cube and via selecting single or multiple values for these characteristics. Here, variables defined on Planning Area level can be used.
Multi Planning Areas combine several Planning Areas in a new one, allowing for the access of data from different InfoCubes.
The Planning Levels can further be subdivided into Planning Packages, which are the objects the planning functions (see next slide) operate on. The data from the planning level can further be restricted using additional selections on charateristic values. The planning packages can be used to define planning tasks and then be assigned to the responsible employee. For each Planning Level, there is always one default Planning Package, the ‚adhoc package‘, which can be used for planning. It is important to know that planning functions (such as manual planning, formulas and the delivered standard functions) operate on Planning Packages, i.e. the data selected therein.
An example would be:
Planning Area = Sales Cube
Planning levels = Costcenter 1, Costcenter 2, ... ;
Planning packages = [Region A, Product Group 1], [Region A, Product Group 2],...
Use the hyperlinks provided on the slide for further details.
...

5. Objects in Planning (II) - Methods
Manual planning: A layout that is used to display data and for manual data entry. Each layout is assigned to a planning level and can be executed for each contained planning package. It can be displayed as ALV Grid or as Microsoft Excel spreadsheet.
Planning function: Definition of an automatic function that can be used to manipulate data. There are three main types:
· Predefined planning functions (such as copy, revaluation, distribution,…)
· Fox-formulas (self defined, e.g. quantity x price)
· Exits (self-defined, e.g. calculate revenue depending on number of workdays in company calendar)
Functionality
Complexity
Parameter group: Preset of values/variables for the execution of a planning function to which it is assigned.
Planning sequence: A user-defined list of planning functions that can be processed sequentially. Can be defined on local and global level.
There are several methods for manipulating data in the planning environment either manually or automatically.
In order to display or enter data from/into a Planning Package, a layout needs to be created which defines what characteristics and keyfigures are displayed and the way they are displayed (header, lead/data columns, order, hierarchies etc.). This layout is also the basis for the other planning frontends (web/planning folder). Two interfaces can be chosen: ALV grid or MS Excel.
For processing larger amounts of data, automatic planning functions can be used, e.g. for copying actual data to plan data, for revaluation etc. There are several functions available in different flavors of functionality and complexity.
Whereas a planning function corresponds to the abstract definition of a function like f(x,y,z) = ... (and conditions), a parameter group specifies the concrete values (x,y,z) for which a planning function is to be executed.
An example:
Planning function: f(x,y) = revaluation of x%, condition country y ;
parameter group 1: x=10% for country y=DE; parameter group 2: x=12% for country y=FR.
All of these methods are assigned to a planning level and operate on a planning package in that planning level, i.e. a planning package must be specified for the execution of a planning function.

6. The Planning Workbench – BPS0
Hierarchy of Planning Areas, Levels and Packages
Detail area for selected object
The planning workbench is the main tool for the planning administrator. Here he can customize all necessary objects for planning.
The top left window contains a list of available Planning Areas, either those included in a planning profile or all (Menu EditGeneral Overview). It is designed as a hierarchy of Planning Areas, Levels and Planning Packages contained therein. Doubleclicking one item here will display the object details in the detail area on the right-hand side. Context-sensitive functions (change object, create subobject) are available from the context menu (right-click).
The bottom left window displays the planning functions available in the last selected Planning Level. It is built of a hierarchy of planning functions and parameter groups, manual plannings and layouts, and planning sequences. Before executing one of these functions (doubleclick!), a Planning Package has to be selected in the top left window. In order to display/create/change an object here, use the context menu (right-click).
All manipulation of data performed here will be processed in the planning buffer. There are two ways to save information: Either save only the planning model (Menu Planning  Save Model, SHIFT-F6) or save the model and the planning data in the InfoCube (Save-Button or Menu Planning  Save all, CTRL-S).
Hierarchy of Planning functions, sequences, parameter groups and layouts (manual planning) assigned to selected planning level

7. Planning Layout – Manual planning
Planning Layouts are used for display and manual entry of planning data.
Excel Interface
ALV Interface
Appearance of characteristics in header, lead or data column can be customized. Totals can be switched on/off and displayed as hierarchy.
Planning Layouts are defined for Planning Levels but are executed for Planning Packages. They are the basis for the other planning frontends such as Planning Folders or Web Interfaces.
Planning Layouts are defined in three steps, defining the header fields, lead and data columns, layout types, hierarchies and the layout display tool (ALV/Excel).
There are three main layout types: 1) Keyfigures in data columns, 2) Keyfigures in data columns, rows defined individually, 3) Keyfigures in lead columns.
When entering plan data, the F4-help for characteristic values is available.
Using the Excel interface, the Excel functionalities can be used. However, there may be problems when using the Delete, Insert or Sort functions of Excel.

8. Planning Functions and Parameter Groups
Each planning function requires in its definition the fields to be changed or the fields for condition, respectively.
It is possible to gather planning functions with their parameter groups in a local or global planning sequence. The functions are then executed collectively in dialog or in background.
The parameter group determines the values of the parameters of the planning function.
Larger amounts of data can be processed using planning functions. They operate on planning packages, i.e. on the data selected therein. When not executed in global planning sequences, the changes only affect data in the planning buffer. One single execution of a planning function in the planning buffer can be undone with the UNDO-function.
There is a number of standard planning functions delivered by SAP, such as Copy, Revaluation, Repost etc. In the planning function, the operands and fields for conditions must be specified. The parameter group defines the values the function is executed with; the planning function is executed via the parameter group.
For further functionality and complexity, Fox formulas and Exits can be used.
Planning sequences allow for the execution of several planning functions in a row. Executing a local planning sequence corresponds to the sequential execution of the contained planning functions.
Global planning sequences enable you to execute planning sequences in background. However, the changes are written immediately into the InfoCube, i.e. they cannot be undone easily.

9. Planning Folder Interface
Planning Frontends
Web Interface
Web interfaces can easily be customized in the Web Interface Builder using web enhancements like style sheets. Also, the Excel Web component can be used (not shown here).
Planning folders can be configured quite similar to web interfaces via drag&drop. The Excel interface can be used here, too.
Planning Folder Interface
There are two main planning frontends, one web-based and the other SAPGUI-based. They have similar capabilities and properties.
Web interfaces can be customized via transaction BPS_WB and executed via BPS_WIF0.
Planning folders are maintained in UPSPM and executed via UPSPL.
The frontends can be composed from basic objects like
Planning layouts
Planning functions (as buttons)
Variable selections
Tabstrips
Charts and images
Pulldown menus for function/package/variable selection
The web interfaces can be employed in the Status and Tracking scenario.
Notes on Planning Folders: (Web), (GUI).

10. Performance Analysis – Tools
Tools for the performance analysis of Planning Functions:
BPS_TRACE: Trace the execution of a planning function
BPS_STAT0: Analysis of single execution of a planning function
BPS_STAT1: Statistical analysis of manual planning, planning functions etc.
STAD
ST03
ST05
SM04
SM50
...
BPS related
System related
BPS_STAT0
Most common problems with BPS concern (1) performance, (2) locking and (3) understanding how data is aggregated/allocated when planning on different levels of detail.
There is a number of notes concerning performance of BPS, which is one of the main problem areas. The most useful source is the SEM-BPS / BW-BPS performance guide (note ), which is available on the service marketplace: service.sap.com/bw, Menu Item: SAP BW Business Planning and Simulation > Performance. It contains a detailed description on how to setup, analyse and evaluate sample cases. The most important performance analysis tools are transactions BPS_TRACE, BPS_STAT0, BPS_STAT1 in combination with STAD, ST03 etc.
Information on benchmarking using technical content is available in note
Often, customers have trouble with locks on planning data caused by Planning Package selections. Note contains information on some useful tools, e.g. the report UPF_PACKAGE_INTERSECTION_CHECK to determine whether two Planning Packages interfere in order to find lock issues. Note explains in detail how the locking algorithm in BW-BPS works.

11. BW-BPS Business Planning & Simulation Monitoring & Technical Risks
Content
Introduction
Reporting
Business content
Data loading
InfoCube Design
Aggregates
BW-BPS Business Planning & Simulation
Monitoring & Technical Risks

12. Monitoring Tools BW related System related RSA1 ST03 RSRT RSRV
RSRTRACE
STAD
ST05
SM04
SM50
...
RSMO
RSPC
BW related
System related
ST03
RSRT
This slide shows the most important monitoring tools for BW. Some of them focus more on data loading (WHM), such as RSMO, RSPC, others focus more on reporting (RSRT, RSRTRACE).

13. Monitor for Data Extraction and Load (RSMO)
Green: successful data extraction / load
Yellow: extraction / load not finished
Red: extraction / load failed
Drill down on failed InfoPackage for details

14. RSMO Monitor Details
Tab Details provides more information about points of failure during extraction and load
Select node and right-click for context menu showing options including Help and IDoc details (where appropriate)
When a step is highlighted, its status information is shown below
The overview tree allows you to navigate with the current functions (IDoc or PSA maintenance, simulated booking,...) using the context menu.
The logs on rebuilding, cancellation, and deletion are also integrated, as are the functions for activating the ODS object data, and for the further update of the data in the data targets.
Technical information that cannot be displayed in the text of the Monitor detail tree, is displayed in the footer row when you select a node.
When you load master data, an error log of all the incorrect data records is created. You can call up this log from the monitor detail screen or the monitor Wizard. The system checks master data for duplicated data records and overlapping time intervals, and to see whether lower-case letters have been used.

15. Sizing Project Risks (I)
Question
Answer
Did you create a quicksizing project in SAPNet ?
Does this project take future increases in data volume into account ?
Example:
There is a quicksizing project existing.
It is valid for the first step of the project only.
Background
There should be a sizing roadmap for all future project steps (for example the GoLive of additional functionality or an increase in data volume).

16. Sizing Project Risks (II)
Question
Answer
Do you need to upload more than 1 million rows per hour?
Have you performed an upload volume test?
Example:
Yes, we only have an 1 hour time window to get 2 million sales data into BW at night.
No, not yet.
Background
Uploading less than 1 million rows per hour is usually no critical issue. Higher Volumes than 1 million rows per hour can be achieved but this needs to be carefully tested and tuned

17. BW Sizing Strategy: T-Shirt Model
It is always recommended to directly contact the hardware vendors when sizing a BW system. The hardware vendors all have competency centers or services which specialize hardware in sizing SAP application
There is no one particular recommended hardware platform for BW. See for additional information on platforms.
For a detailed sizing use the quicksizer (alias /quicksizer)

18. High Availability Risks
Question
Answer
Discuss / describe in detail: What happens when the business processes are not available for 3 hours during the day or for 12 hours during the night?
Example: As we need the sales data reporting every morning, we need to be able to recover in 4 hours to get the upload done in another 3 hours during the night.
Discuss and describe in detail: What is the financial impact when the business processes are not available?
Example: We will not be able to create new sales orders. We would lose about 1 Million Euros per hour.
Discuss the maximum affordable downtime, e.g. For offline backups
Example: Our maximum affordable downtime is 1h/week. We can‘t perform offline backups
Background
Not all components are really critical for the customer‘s business. Try to find out. Identify where the customer needs a sophisticated HA concept. For general information see SAP Service Marketplace, alias /ha

19. Landscape Risks Background
Question
Answer
Do you plan to connect several components in a complex landscape?
Example: We will connect 2 APO Systems with 10 R/3, 1 CRM and 1 BW System
Does BW share the hardware and/or database with another (productive) system
Example: BW shares the resources with our CRM system
Background
Several R/3 Systems connected to one BW System:
Since more than one R/3 source system is used it’s necessary that all R/3 source systems do have a current and valid plug-in installed.
Since more than one source system are connect it’s necessary to organize an upload scenario from the different source system into the BW system that takes care of the workload situation in the source system as well as in the BW system. Additionally, it needs to be organized that time windows for upload are available to minimize the influence of upload during the reporting time windows.

20. Landscape Complex Landscape Upload from several source systems
Connected systems in different time zones
Since more than one R/3 source system is used it’s necessary that all R/3 source system do have a current and valid plug-in installed.
Since more than one source system are connect it’s necessary to organize an upload scenario from the different source system into the BW system that takes care of the workload situation in the source system as well as in the BW system. Additional it needs to be organize that time windows for upload are available to minimize the influence of upload during the reporting time windows.

21. System Management Risks
Question
Answer
Do the different project teams set up an overall upload schedule?
Does BW Basis coordinates the upload/roll up/change run jobs of the different project teams?
Example: No, right now every project teams runs upload/roll up/change runs independently of each other.
Background
Since the data maintenance jobs do have a large impact on the system workload, all kind of these activities need to be coordinated, even though the different application areas are independent from each other.

22. Data Modeling Risk Background Answer
How detailed will the data be stored? (Aggregation over time)
How detailed will the data be stored? (Aggregation over detail of data)
How many InfoProviders are used for operational reports
How long will the operational data remain in the BW system? (Years)
hourly daily weekly monthly
item order plant company
< >=100
< >=10
How often is the data archived? When do you delete the PSA tables?
We don‘t archive the data, the PSA tables are not deleted.
Are the InfoCubes compressed regularly?
We don‘t compress our Cubes.
Background
Operational reporting is typically time critical and the involved objects may become very large over time. It’s very important that customers have a clearly defined retention time for that data.
Tactical reporting and or strategy reporting which normally report over a longer period than operational reporting should not use the operational data for reporting, otherwise the detailed data would have to remain for too long in the system.

23. Reporting Risks Background
Question
Answer
Do you plan to report on stock data?
Do you plan to report on daily level data ?
Are there end-users connected over WAN?
YES NO
Do you monitor the performance closely?
Do you build appropriate aggregates?
Our basis team is monitoring the database.
We don‘t need aggregates, BW has to be fast without them.
Background
The more features and data a query uses and or processes the longer the processing time gets. Additionally large graphics and WAN connection slow down the performance of the queries as well.
Performance problems can be avoided if a close monitoring is in place and if the right aggregates are built.

24. EarlyWatch Alerts EarlyWatch Alert: red rating for BW KPIs
 Report is red

25. BW KPIs – Aggregates EarlyWatch Alerts
NrDelAggr (Number of Aggregates recommended to delete)
Number of aggregates not used during query execution/aggregates that are almost as large as the InfoCube Attention: don’t delete them without a careful review!
NrAggr0Call (Number of aggregates with no calls)
Number of aggregates not used at all during query execution
NrBuildAggrCube (Number of aggregates recommended to build - cube level)
Stastistics on Cube level indicate missing aggregates
NrBuildAggrQuery (Number of aggregates recommended to build - query level)
Stastistics on query level indicate missing aggregates

26. BW KPIs – Runtime EarlyWatch Alerts Runtime>20sec
Percentage of queries running more than 20 sec
AvgRuntime
Average runtime of all queries
Avg.OLAPINIT time
Avg.OLAP time
Avg.DB time
Avg.FRONTEND time
FE/DB time
Relation between FRONTEND and DB time
*See Note for further details*

27. BW KPIs EarlyWatch Alerts DB Size > 10 TB Nav.Steps
Total number of navigation steps
Indication for the workload
Avg.Cells
Average number of Excel Cells send to Frontend