I would like to follow up on articles about SLO (System Landscape Optimization) and Business Transformation that my colleague has posted recently. He explained how tools and the methodology can be used to transform SAP ERP systems in the context of M&A, divestiture, and corporate reorganization.
Many readers are interested and concerned about their SAP BW systems. When using the SLO approach to transform all ERP data, there is obviously some indirect impact on all interfaces and satellite systems.
In my post, I will focus on the impact on the SAP BW system. Since 2016, SAP has been taking SAP BW to the next level with the new release of SAP BW4/HANA. The impact of SLO data transformations here is the same as in the case of the classical SAP BW.
SAP BW is all but dead
SAP Business Warehouse (SAP BW) is an SAP business intelligence and data warehouse solution that comes with extensive predefined business content and very powerful data extraction mechanisms from SAP business applications. Thus, SAP BW is perfect for extracting data from the ERP, CRM, SRM, and SCM systems and transforming this data for reporting in queries, executed through a web browser or in Microsoft Excel. Contrary to the beliefs of some people, SAP BW is all but dead. It will not be “completely replaced” by S/4. More information on this misconception can be found here: http://www.datavard.com/en/why-s4hana-will-not-replace-sap-bw-and-why-people-still-get-it-wrong/
Normally, SAP BW systems use data extracted from all modules of SAP ERP. Therefore, transformation projects in almost all scenarios have a significant impact on BW systems. Up to a few years ago it might have made sense to “simply“ reload this data. However, in view of the increasing data volume and the resulting longer runtimes for such an exercise, a complete reload of all ERP data is usually no longer a viable solution.
Let’s get one thing out of the way to kick things of: SAP LT 2.0 covers BW, however only as a “restricted solution”. For certain scenarios, you may need the help of an implementation partner such as Datavard. Nevertheless, there are ways and means to successfully execute transformation projects within SAP BW.
Options to implement data transformations
Basically, the following approaches can be used to implement SAP BW data transformations:
Of course, data can be reloaded into BW Systems; however, there are a limitations and disadvantages that need to be considered.
Sometimes customers ask for a DataMart solution, where the BW System practically “loads itself“ and the transformation can be coded in accordance with relevant transfer rules.
- Conversion (e.g. SAP LT-based)
A tool based conversion solution based on the SLO methodology mirrors a transformation in BW along with ERP and can be realized in the production cutover at the same time as the ERP System.
- Hybrid Solutions
Hybrid solutions based on a mix of the various approaches, as for instance, a data transformations through DTPs, coupled with a reload on a “staging level“, followed by a “rollup“ into the reporting level.
Determining the scope and impact on your data model
The impact of data transformations with SAP LT on connected SAP BW systems is significant. The conversion technology in SLO tools such as SAP LT transforms data in ERP, including historical data, completely and consistently. This produces neither change documents, nor is any type of application logic triggered that would result in a change log for a BW extraction.
When analyzing the impact of an ERP transformation on BW, attention has to be paid to which data are changed, and where and how. Based on the results, a strategy can be chosen for the implementation of the transformation in BW.
Your first step should be to analyze the ERP transformation and to identify the affected business objects. This is best accomplished on the basis of ERP domains and the most important tables with relevant fields in the ABAP dictionary. If, for example, company codes are to be merged in ERP then, in addition to changes to tables and fields in the BUKRS domain, changes must also be assumed in FI documents. For all of these objects, the domain and the “header table“ must be identified. For company codes, this is the customizing table T001 in which the field BUKRS contains the company code.
A domain in ERP is the technical representation of a field. Domains are used in data elements which function as semantic field definitions. Based on the domain, a where-used list can be created for database tables and fields in ERP. Once the relevant objects and tables in ERP are known, one can turn to the BW System and use these tables and fields as a basis for analyzing the data extraction and ETL processes.
Ideally, as a first step the affected InfoObjects are identified in BW. Once they are known, a where-used list can be created in the BW System via the Administrator Workbench. This process clarifies the fundamental difference between ERP and BW: In the ERP System, the data model is largely predetermined by SAP, while BW leaves the modeling of the data structure completely to the customer. The standard content supplied by SAP regarding InfoObjects and data extraction is used by all customers – but the SAP-supplied modeling on the reporting level with InfoCubes and DSO’s is more a suggestion and example, and is rarely used. Typically, SAP customers use completely in-house developed DSOs and InfoCubes.
A where-used list of the InfoObjects describes your own data model and supplies information regarding BW objects in which relevant InfoObjects are used. These BW objects can be found in a where-used list through the Administrator Workbench.
The where-used list in the Administrator Workbench is useful for gaining an overview of the effect of an ERP transformation on a BW data model. The where-used list can also be displayed on the SAP Standard list and then stored via SAP GUI standard functions. To accomplish this, you activate transaction RSD1 and enter the name of the InfoObject. Click on “Display“ and then select the function Process • Where-used List (List-Based) from the pull-down menu. You can then save the displayed standard list via List • Export • Local File, and then import it into Microsoft Excel, for example.
With this method, the impact of transformation objects on an inventory of SAP BW objects can be discovered in order to analyze the BW structures for the purpose of developing a strategy for handling the data change itself. As input for the analysis, a significant piece of information is still missing – the relevant InfoObjects.
SAP Standard business content and custom info objects needs to be considered. Experienced BW consultants usually know the relevant InfoObjects by heart – but they must first understand the ERP conversion in order to apply their knowledge. If, for example, the chart of accounts is converted in an ERP System, then it is obvious that the BW InfoObject 0CHRT_ACCTS, which represents the chart of accounts in the BW System, is affected. But there are additional InfoObjects that need to be considered. In the SAP standard content, account numbers are stored in the InfoObjects as 0ACCOUNT and 0GL_ACCOUNT.
Additionally, cost elements must be considered in the InfoObject 0COSTELMNT. Armed with this information, an additional deeper analysis can be started. Of course, custom InfoObjects are still missing, and any list of relevant InfoObjects cannot be expected to be complete because even the most experienced consultant will never know all objects by heart. That is why the data extraction on the ERP side as well as the processing in the BW System should be carefully analyzed within the Data Warehousing Workbench. In this connection, attention should also be paid to transformations.
Technically, the database table RSOSFIELDMAP in BW can supply first indications regarding the inventory of relevant InfoObjects (see figure below). However, here you must be familiar with the ERP field names (for example, SAKNR for G/L account number).
If you now ask me what is the best way how to synchronize your ERP and BW, my answer would be in asking more questions to understand your scenario better. From my experience, I’m doing this kind of projects from more than 13 years now, I have a tendency to recommend the tool based approach as it has certain advantages. However, for some cases you may be fine with complete reload. To help you take decision on your own, I’ve put together a small comparison of the approaches in the table below.
I my next post, I will focus on analyzing different options for handling data transformations in the SAP BW system (data reload, DataMarts conversion and hybrid approach).
You can also find previous posts on SLO here: