S/4Hana Migration: How Business Benefits Today, Not Tomorrow
Blog SOH and S/4

S/4Hana Migration: How Business Benefits Today, Not Tomorrow

The migration to SAP S/4Hana is making slow progress in many companies. The reason is obvious: responsible managers are often missing clearly defined business cases that can be realized quickly. But only few are aware that there is one area where significant savings can be made rather soon: Reporting.

When introducing S/4Hana, SAP promised that the migration to this new version of the Business Suite would be non-disruptive. However, it has become obvious that the adoption of S/4Hana is more than just a migration. It requires answers to some fundamental questions related to a company’s SAP strategy. The reasons for this are the high number of functional changes required and the move towards “in-memory” technology implying some more fundamental adaptations to the related infrastructure.

Hence, the majority of migrations to SAP S/4Hana already started are still system consolidations or migrations that had to take place for various reasons anyhow – and are carried out now based on SAP S/4Hana as the latest available release of the SAP Business Suite. In contrast, there are only few migrations starting on the basis of system landscapes that have already been consolidated.

Additionally, required transformations may take two to three years even in standard scenarios. Experience shows: after such a long period of time, the business environment has often changed so fundamentally that the desired benefits can only be partially realized. As a result, management often has serious doubts about the benefits of migrating to SAP S/4Hana.


Overview of overall infrastructure

Therefore, IT managers should not only focus on business cases based on the bottom-up aggregation of improvements per single functionality. Benefit calculations like that are doubted by management anyway. Instead, the big picture should focus on overall system infrastructure. And here it shows:

Many companies maintain a rather complex landscape of transactional application systems – mostly based on the Business Suite by SAP – while running a separate set of reporting systems based on SAP products like SAP BW as well. These reporting systems usually combine a huge amount of data continuously replicated from transactional systems with additional data from third-party sources.

Since reporting requirements based upon these transactional data have increased significantly in recent years, the respective Business Warehouse instances are subject to almost the same high availability requirements as the transactional systems. A typical example is the daily order overview for sales: today, this overview is usually no longer provided by the transactional system, but by the Business Warehouse. For stock controlling too, data is replicated to the Business Warehouse from the transactional system where the stocks are created. So this system landscape topology has resulted in largely redundant data storage and processing with correspondingly high costs and high complexity in system management.

Two become one

Migrating to S/4Hana offers a way out. With S/4Hana it is possible to carry out transactional reporting directly from the transactional system in a very efficient way without replicating these data into a separate reporting system. So one business case for migrating to S/4Hana is rather obvious and substantial: to opt for a system landscape with a significant repositioning of the reporting systems. In this scenario one can avoid the continuous replication and the associated huge costs for replication and high-level SLAs, and focus the use of the Business Warehouse on aggregated data and the combination of internal with external third-party data.

Likewise, SAP could significantly push the adoption rate of SAP S/4Hana if it promoted this alternative approach by offering better standard procedures that are suitable for supporting the transformation to a situation where transactional reporting is done directly from the transactional S/4Hana system. The long-term SAP vision anyway is to have transactional applications and reporting applications operating on a unified Hana database avoiding additional replication and to fully utilize benefits of in-memory technology offered by Hana.

SAP Hana will support both reporting and transactional functions. Users will no longer even notice on which basis the respective functionality is set up. Although this is still a vision, S/4Hana represents a major step in this direction.

Technology not in the foreground

Such a merger requires consolidated data. These are often already present in large companies in particular – especially as the systems are nowadays often set up globally and individual regional systems are increasingly becoming obsolete. It is thus not so much technological aspects shaping such a fundamental restructuring of the IT infrastructure, but rather organizational and human resources aspects.

After all, hundreds of employees are working on the operation and maintenance of the separate reporting systems landscape in large companies. It is particularly important to emphasize to them that their expertise will continue to be of great importance – but on a changing technological basis for standardized reporting. The capacities freed up in this way can then be used to meet current challenges such as Advanced Business Analytics or Big Data.


About the author

Rainer Suletzki, ISG

Rainer Suletzki is Independent IT Management Advisor on behalf of Information Services Group (ISG).


Click here to post a comment

  • Because SAP S/4HANA is making slow progress in many companies, I think I should get a consultant to know if the technology will benefit our business. Hopefully, migrating to it will be efficient for us without needing to replicate data. If it will support both reporting and transactional functions, maybe this is going to be what we’ll need to grow our business.

Social Media

Sign up for e3zine´s biweekly newsbites

Please do not use administrative mail adresses like "noreply@..", "admin@.." or similar as these may get blocked for security reasons.

We use rapidmail for dispatching our newsletter. By signing up, you agree that the data you have entered will be transmitted to rapidmail. Please take note of their terms and conditions and privacy policy. terms and conditions .

Our Authors