BACK

5 Things a Growing Company Must Know About System Landscape Optimization

Our Senior SAP Consultant takes a closer look at the BW piece of the SAP systems puzzle and explains what are the options companies should consider when running an SLO project.

 

Q1: Do we need the SLO service for the BW system?

As business grows, the system landscape grows as well due to new applications, expansion to further regions or takeovers of systems of acquired companies. This also entails changes of business requirements, including legal changes, mergers, acquisitions, re-organizations and carve-outs that call for remodeling the entire landscape. For such large and fragmented systems, there is a significant potential for optimization.

It’s no surprise that most of the SLO projects are focused on ERP systems. However, usually there are other SAP systems involved such as CRM, SRM, APO and BW which need to be considered as well.

 

Q2: Can we just do nothing and let the delta mechanism bring all the changes?

A typical SLO project includes direct DB updates to improve the performance and enable changes that are not supported by standard. These updates do not generate any change documents, and the SAP system in fact doesn’t know that those changes took place. Therefore, doing nothing will cause a mismatch between the ERP and BW for all the historical data. Moreover, new data created after SLO (e.g. updates on existing documents) will also cause a mismatch on BW, as the new data will come in new organizational units.

 

To sum it up, not considering BW at all is not a way forward.

 

sap slo project

Include BW in your SLO projects to avoid future difficulties

 

Q3: Can we reload all the changes on ERP into BW using standard ETL?

This is a valid question, as there are cases when this is possible, and sometimes even necessary. But, there are major obstacles that you should keep in mind:

Reload is affected by data volume – today, BW system sizes are counted in Terabytes, and it might take a few days or weeks to reload complete history. That means a business downtime of BW system, as well as performance impact on the source system(s)
Timing of the reload – the exact downtime is not known until the go-live date, and the reload can only start after the ERP has been converted. As a result, the BW will not be ready at the same time as the ERP system
Historical data & planning data within BW – data which is already archived in the ERP cannot be reloaded and will be lost in the BW as well after reload. Planning data could not be reloaded from ERP at all

On the other hand, reload might be a valid option if:
SLO on ERP affects only limited number of relatively small info providers, where reload can be performed within a reasonable downtime
Data model on the BW contains already aggregated information and thus it is not possible to derive the same conversion logic as on the ERP (usually this is the case of top layer info cubes only, where SLO on BW is possible for 1st level of DSOs)

Q4: Can we use a built-in functionality (transformations, data marts) to replicate changes in the BW?

SAP BW system offers data transformations by default. Between every source and target object there is a transformation, where a routine can be implemented to adapt the data to the customer’s needs. We can also load data from one info provider to another within the same system to apply transformations (so called data marts). Can we use this to replicate SLO on ERP?

Technically it is possible, but… there are several drawbacks of such an exercise which need to be considered:

A lot of manual effort – every object affected by SLO on ERP has to be duplicated, and a transformation routine needs to be implemented
It is impossible to estimate the BW system downtime
Higher risk – a lot of manual effort implies a lot of manual errors. SAP standard functionality does not support automation for such a scenario
Understanding of SLO on ERP – as mentioned before, SLO exercise usually means a change that is not supported by the SAP standard functionality and is done massively directly on the DB level. Having said that, an expert understanding of applied processes is needed in order to replicate these changes on BW.

 

sap slo projects avoid manual work

Plan ahead to avoid manual work during an SLO project

 

The advantage of this option over the reload from ERP solution is that it can be run in parallel with ERP transformations.

All in all, the option of using data-marts is again best suited only in the case of limited impact of ERP transformation on a small number of info providers.

Q5: What’s the best way to reflect SLO changes in a BW system?

The answer to this one is easy – engage SLO services for the BW as well. There is a tool-based approach for the BW available, working directly on the DB level to ensure top performance. So when planning an SLO project, do not forget to consider your BW system.

 


If you are interested in expert services and tools for making your SAP landscape better, have a look at our new webinar series.

SLO WEBINAR SERIES

Leave a Reply

Your email address will not be published. Required fields are marked *