Source: https://launchpad.support.sap.com/#/notes/2211255 (Version 4 from Apr 21, 2017 in English)
Symptom
IBP is a highly configurable system and it is possible to configure it in a way that's not optimal for performance. This note describes some general guidelines to achieve good performance for a planning area in IBP both in terms of configuration and sizing.
Other Terms
IBP, S&OP, Scaling, Performance, Planning Area
Reason and Prerequisites
None. This note is generally valid fo S&OP3.0, IBP4.0, IBP5.0 and IBP6.0
Solution
1. Sizing and Planning Area Complexity
- It is highly recommended to perform sizing prior to project start to work through the current and future sizing requirements and to also attempt to get the right initial size of the system.
- Sizing is primarily based on the number of stored key figure value (which we call planning points). As each planning area is different in terms of key figure calculations and planning views and charts being used, the details of system performance need to be verified by each project
- During your implementation project, it’s recommended to verify the sizing assumptions after uploading data into the system.
- SAP recommends a phased approach to go-live with complex planning areas with many configured key figures and to plan for a performance test.
2. Keep your Configuration as Simple as possible
Attributes
- Use as few attributes as possible in master data and even more so in planning levels.
- Do not make attributes as key of master data types or roots of planning levels that really aren’t.
Master Data Types:
- Keep the number of Master Data Types to a minimum. Fewer Master Data Type also typically reduces the number of planning levels and the need for joins for calculations across multiple planning levels.
Key Figures and Planning Levels
- Model key figures at the required detail with regard to time and attributes. A finer granularity than needed carries a performance penalty. (e.g. if you don't have to plan at the ship-to level for customer, don't)
- You can use non-key attribute of a master data type as root attribute in Planning Levels. That way you don’t need to model additional Master Data Types
- Minimize the overall number of planning levels in your planning area (but do not increase the amount of data you need to store while doing this)
- Minimize the number of root attributes in a planning level. A root attribute is to model an independent dimension (which means the root attribute is a key to the key figure data). It is recommended to have no more than 5 root attributes for a planning level.
- Minimize the number of calculations that include different input planning levels wherever possible (but without increasing the number of key figure values you need to store)
- Avoid on the fly attribute transformations as much as possible, as corresponding queries can be slow. Instead try to store the result of attribute transformation to a stored key figure using Copy Operator.
Attribute as Key Figures
- If you use key figures that are filled via a master data “attribute as key figure”, use time-independent key figures instead of time-dependent ones. If Time Dependent Attribute as Key Figures are required, use From Periods and To Periods settings in Attribute as Key Figure configuration to limit the number of time periods this attribute needs to be copied to.
- In case, an attribute value is not time independent and needs to vary over time, then load it as a regular key figure.
- Do not configure master data attributes used in Supply Planning – such as CRATIO, PRATIO or TRATIO as attributes as key figures. There are key figures for this purpose.
- Attributes of master data types can be used in calculations: You don’t need to add integer attributes as key figures just for using them in calculations.
Aggregations and Disaggregations
- If request level calculation is SUM or AVG, use the aggregation mode of SUM or AVG instead of CUSTOM. For Min , Max or Weighted Average Calculations continue using CUSTOM aggregation mode.
- If you need to disaggregate a key figure based on a calculated key figure, avoid the Advanced Simulation Operator if possible as it may have some performance impact.. Rather consider using copy operator to copy the calculated key figure to a stored key figure using a batch job.
- Keep the number of attributes in the planning views to minimum necessary. More than 6 attributes in planning view may affect disaggregation performance.
Verification (very important)
- Check for attributes or key figures that are not used in planning views or analytics and remove them from planning area or even from master data. You can ask SAP for help if you have a large number of attributes to check.
3. Topics that require Special Performance Consideration:
Multiple Planning Areas:
- If you have multiple planning areas in your system, it is recommended to have separate master data types for each.
Data Integration
- Schedule large data loads during off hours. During import jobs users might be blocked from saving data.
- Implement a delta mechanism to limit the number of rows per periodic data import job.
- Don’t load data frequently if not required.
- Use the purge functions to purge data that is not used in the system. There are different options: PURGE (Purge Operator for time series) , PCH ( Purge Change History) , Deletion of Key Figure Values and/or master data.
Change History:
- Only switch on change history for planning areas and individual key figures where it’s really required.For example Key Figures that are changes from excel.
- Usually it’s not required to track changes for key figures loaded from external systems. If you need to make manual changes to such key figures, which you want to track in the change history, it is better for logical and for performance reasons to introduce an additional key figure where you make the change and use an overwrite calculation (defaulting).
Snapshots and Copy Operator
- Avoid Snapshots or Copy of key figures with complicated calculations. Instead try to copy the input key figures and then reconstruct the calculation with the copied key figured.
- For example if you want to snapshot a Key figure with currency and/or UOM conversions, first snapshot the key figure without conversion and later apply conversion on the snapshotted key figure.
- It is recommended to use Copy Operator instead of Snapshots if you’re not using cascading of Key Figures for snapshots or if you don’t need the entire time series in the snapshot.. Copy Operator is preferred because you can change the duration, define Target Key Figures and you have the flexibility to modify calculations.
Global Configuration Parameters.
- Make sure the following global configuration parameters are configured to the recommended default settings to get better performance. The defaults are available in the system for reference:
- TRACE->TRACELEVEL .
- Make sure it is not set to D for debugging or some parts of the application like disaggregation will be slowed down
- PLAN_VIEW->MAX_RESULT_ROW_SIZE
- INTEGRATION-STAGCLEANUP
- PLAN_VIEW->MAX_DIM_MEMBERS
- SCN_COUNT_MAX
Planning Operators:
- Schedule the planning operators staggered so that they don’t overlap each other and cause unwanted locking.
Scenarios and Versions:
- Creating many versions can increase your system database size. It is recommended to have 4 or less versions.
- Try using more baseline key figures as reference key figures for versions in place of version-specific key figure
- Ensure that the number of end user created scenarios remains reasonable and manageable. This requires educating the users on use cases.
