Successful projects with SAP BI-IP
Taking note of the following considerations will greatly enhance your prospects of a successful planning project. Every planning project provides its own challenges but the following topics are always relevant.
Project organization
Project structure
Practice has shown that it is advisable to appoint a steering committee over the project like the governing body of a joint stock company. The steering committee can then also make decisions the project management itself is not authorized to (like releasing resources, settling of a dispute with regard to the project, etc.). The project management should provide the steering committee with at least a monthly status report in order for the steering committee to be able to intervene if necessary.
Another useful approach includes involving the specialist departments in the project management in order to overcome potential opposition against the project more easily.
In so doing, one has to be aware of the fact that a planning project is always prone to meet the resistance of those involved. The reasons for that are:
A well run planning project considerably increases the transparency of planning data. This means less room for individual calculations on the side which reduces the scope for design each planner has. Usually, this is welcomed by the management.
Often, planning is done in a decentralized way with MS Excel or MS Access. A comparison of the time needed to open an Excel file on the local hard drive with that of opening a planning application that retrieves data from a central server and transports it via the network, will always be in favour of local files.
Project operation
Key people for the planning process should be regularly invited to meetings in order to involve them early, to demonstrate progress being made, and to get their feed back.
Project start
By far the most important factor in a planning project with SEM-BPS is a comprehensive and detailed planning process analysis. The planning process can effect the data model, authorizations and the use of tools to monitor and manage the planning. The following points need to be clarified in detail before the start of the project:
Who plans what indicative figures on which planning level?
The various planners should form groups. Out of these groups will later come the roles that are important for assigning authorizations. It needs to be clear whether figures or also quantities are being planned. It might be possible to deduce one indicative figure from the other.
An important factor in the process analysis is the planning level. Is the planning to be done on the level of individual materials or rather on the level of a product group? Is the planning to be done for an individual cost centre or for a cost centre group? The answers to these questions have a great impact on the data model.
How is the planning being done?
In an analytical planning process with SEM-BPS, it is possible to calculate target figures on the basis of quantity structures and preconditions. This is the case if one for example takes the number of staff at one cost centre (divided into different occupation groups) as the starting point to calculate the planned wage rate.
A simpler approach would be to take previous year’s target figures increased or decreased by a factor to calculate the target figures. Both approaches require differently complex data models and planning functions.
Are there any redundant elements in the process?
At this stage, it is important to clarify whether there are any elements or steps in the planning process that can be repeated. For example: The planner has a planning layout at his/her disposal which he/she can use to create default values on the basis of previous data increased or decreased by a factor given to all planners alike. He or she can then overwrite these default values and add his or her own values. If the management changes the common factor and the planning is done again on this basis, it has to be ensured that his or her manual adjustments don’t get overwritten. The data model should allow for such a security mechanism (e.g. an individual version for manual adjustments).
Top-down versus Bottom-up
The top-down approach assumes that all planning is done on a superior level (e.g. controlling area) with the results afterwards being transferred to lower levels (e.g. cost centres) following a defined distribution logic.
In a bottom-up approach all planning is done on a lower level with the results afterwards being transferred to the superior level.
You will often find a mixture where the planning is first done bottom-up with the aggregated results afterwards being checked by the management and compared with the business objectives. Once this check is completed, the planners on the lower levels are usually asked to adapt their planning in a certain way and the aggregation is repeated. Alternatively, it is also possible, using a central percentage figure, to automatically adapt the lower level planning.
Does monitoring the planning process need the support of the system?
It has to be clarified whether those in charge of the planning need the support of the system to monitor the planning process. BPS provides support with its status and tracking system. In some cases however, SAP BW reporting might do the job.
Authorizations
In many SAP BI projects authorization is often considered at a very late stage. Within a SEM-BPS planning project however, authorization plays an important role as it can impact the data model in the same way as it does in pure SAP BW projects. Please also note the OSS notes 315094 and 551971, as well as the document "Authorization in an SAP BW project" from the SAP Service Marketplace.
Authorization might be issued on several levels:
The classical authorization check can be done with the authorization objects available in BPS. The authorization object R_PM_NAME, for example, controls access to planning maps. Further restrictions on planning areas (R_PAREA), planning levels (R_PLEVEL), and specific planning functions (R_METHOD) are possible.
An alternative approach in BPS is to restrict access to planning objects (e.g. profit centre) by using user-specific variables (replacement type "fixed value" and "restriction by user allowed").
If however authorization "User Exit" variables are used, authorization values can be retrieved flexibly from any sources (e.g. ODS objects or transparent tables). If dedicated planning maps are used for this, it is even possible to authorize the department to solely issue authorizations for the planning objects, if that is desired.
Another option is the use of variables with the "authorization" replacement type. In this case, authorization values are read via the SAP BW reporting authorizations. This assumes an existing SAP BW authorization concept.
Data modelling
Data modelling is regarded by many customers as a black box they tackle only reluctantly for fear to commit a mistake with far-reaching consequences. You should observe the following simple rules:
The starting point for the design is the data model of the actual data. The actual data usually builds upon a SAP BW Business Content data model (InfoCube). The bigger the difference between the data model of the planning data and that of the actual data, the more difficult common reporting gets.
Remove all characteristics you don’t need!
Example:
The actual data model for cost centre accounting (InfoCube 0CCA_C11) contains besides the allocation cost centre (characteristic 0COSTCENTRE) also characteristics for partner cost centre and partner assignment. In the context of planning in SAP SEM-BPS, it is highly unlikely that you will ever going to plan in such detail. These characteristics are therefore redundant.
Add those characteristics you do need!
Example:
You are planning your sales and turnover. Your sales and distribution data model (InfoCube 0SD_C05) contains the characteristic 0MATERIAL. Planning on this level however would be too complex. You prefer planning on a product hierarchy level (characteristics 0PRODH1 - 0PRODH9). These characteristics are not contained in the data model of the actual InfoCube data because it is possible to do a report about product hierarchy of the characteristic 0MATERIAL which contains the product hierarchy characteristics as nodes. If you, however, would like to plan on a specific hierarchical level, you will need the relevant characteristic in the InfoCube for the planning data. Once you have planned on the product hierarchy level, you are able to automatically distribute the results via a BPS standard function to the materials.
Adopt the SAP BW Business Content key figure definitions!
This recommendation follows directly from the recommendation to divert from the actual data model as less as possible. SAP Business Content usually defines business key figures with a combination of the characteristics "Version" (0VERSION) and "Value type" (0VTYPE), plus a key figure (0AMOUNT, 0QUANTITY, etc.).
User Interface
The user interface choice determines the techniques that might be used if planning maps or planning layouts are extended. There are three user interfaces to choose from:
- Web Application Designer or Web Interface Builder (HTML)
- SAP GUI, Microsoft Excel (BEx Analyzer)
- SAP GUI & SAP List Viewer (ALV)
A web-based solution like the Web Interface Builder comes with the advantage of not needing a local installation, which makes a rollout easier. Plus, it is easier to integrate in a business portal. An MS Excel solution recommends itself by the wide acceptance and use of Excel in the departments and the way it is easily upgraded with Visual Basic (VBA). Both solutions, Web Interface Builder as well as MS Excel based planning applications are adaptable with ABAP. However, SAP has either not authorized these interfaces (MS Excel) or else they are not well documented (Web Interface Builder).
SAP List Viewer is of minor importance for projects because it neither has the advantages of a HTML web-based solution nor the departments’ acceptance of an MS Excel integration.
Recommendation:
Try to avoid upgrading user interfaces and go instead for the interface that grants you the highest acceptance of the departments.
Historical data
Usually there are two reasons why you need historical data (actual data) in your SAP BW planning InfoCube:
Planners often need past data to plan for the future. This data is mostly shown in a comparison column next to the planning data.
Actual data can also be used to forecast planning data or to transfer planning data from one level to another.
Two ways to access actual data
You load the actual data via an export datasource from your actual data InfoCube into the plan data InfoCube. If you don’t have the data in SAP BW you can either use a flat file or load the data by using DB Connect or a different SAP supported method. Loading the actual data with an export datasource has the disadvantage of keeping it in SAP BW , which in the long run is redundant. The advantage of transferring data from the actual data InfoCube to the plan data InfoCube however is, that through this process an aggregation takes place which enables the user to access the actual data in the plan data InfoCube more quickly. This is due to the lower number of records in the plan data InfoCube compared with the actual data InfoCube.
If SAP BW contains the actual data, it is also possible to access it directly. The SAP report "SAP_CONVERT_TO_TRANSACTIONAL" converts a Basic InfoCube into a transactional InfoCube that can be used in planning. Please also note the OSS note 411725. For both, the plan data InfoCube and the actual data InfoCube a basic planning area is now being created. The two basic planning areas are then going to be linked by a multi-planning area which in turn provides access to plan and actual data. Since the actual data InfoCube can only be either loaded or planned it is necessary to align planning processes and SAP BW loading processes. Basically, this is possible by using process chains:
In a SAP BW process chain, it is, with the help of the two function modules RSAPO_SWITCH_TRANS_TO_BATCH and RSAPO_BATCH_TO_TRANS, possible to switch the InfoCube from "can be loaded" (SAP BW default setting) to "can be planned" (necessary for SEM-BPS). At the beginning of the process chain the InfoCube is set to "can be loaded". After the actual data has been successfully loaded, the InfoCube is then set to "can be planned" by the second function module.
Recommendation:
Assuming that there is enough free disk space, it is recommended to load the actual data into the plan data InfoCube. This grants independence of SAP BW loading processes as well as a better reading performance due to the lower granularity of actual data in the plan data InfoCube.
Planning functions
Wherever possible use the standard functions delivered by SAP. They are usually the best choice with regard to implementation effort and performance. If there is no standard function for your specific requirements available, use FOX formulas. As ABAP coding is being generated out of FOX formulas, the performance of planning functions created that way might not be satisfying in singular cases. If that is the case or if the task cannot be performed using FOX, create the planning function with ABAP.
Planning layouts
Keep your manual planning layouts as small as possible. This concerns MS Excel-based layouts as well as layouts created with the Web Interface Builder. If you want to show a lot of reference data, try to move this information to SAP BW reports (BEx Analyzer or Web Application Designer).
Reporting (SAP BW)
Always define a MultiProvider as an InfoProvider for your actual and planning data, even if you keep actual and planning data in one InfoCube. This gives you enhanced flexibility. If up to now, you have built your reporting on a Basic InfoCube you can copy the queries to a newly created MultiProvider with the RSZC transaction. This is possible whenever the target InfoProvider contains at least the characteristics and key figures of the source InfoProvider.
In SEM-BPS (BW-BPS) the data is written to a transactional InfoCube data request. As soon as the number of records in a data request exceeds the threshold value of 50.000, the request is closed (see also OSS Note 333260). In order for queries to read data from an open request, the query definition must contain the variable "most recent data" (technically 0S_RQMRC) and the characteristic "Request ID" (technically 0REQUID). If you are not sure which of your queries you still need to adapt, you can use the function module "RSSEM_QUERY_READ_MOST_RECENT" (transaction SE37) to show you all queries that are not yet using the variable.
Performance
If you experience performance problems these can be analyzed using the BPS_STAT0 transaction. A detailed description of this transaction as well as tips and recommendations on how to solve performance problems are contained in the SAP document "Performance Guide SAP SEM/BW-BPS" available in the SAP Service Marketplace.