S/4 Transformation and Strategy

While numerous existing SAP customers are carrying out the technical transformation to the Hana database platform, the DSAG investment survey shows that the adaptation of S/4 is still behind expectations:

How does Syniti explain this reluctance towards S/4?

Frank Schuler: In my view, there are two reasons for the current reluctance: Firstly, SAP S/4 Hana is not yet functionally equivalent to SAP ECC 6.0 and not all industry solutions have been fully implemented.

Although SAP has published the development plan, some customers are still waiting.

Secondly, the changeover can be complex and a detailed changeover plan is essential. Not all customers have such an executable plan.

As modules in HR and purchasing, for example, are no longer provided in the S/4 Hana core but in cloud applications, a cloud strategy is necessary.

The same applies to interfaces, customizations and the user interface: the integration of local solutions with cloud applications requires an interface strategy designed for real-time processing and possibly the addition of existing development standards.

And: external access strategies, including security concepts, are required in order to fully utilize the potential of the new SAP Fiori user interface and convince users.

SAP also advertises S/4 with innovative, new business processes - but what counts more: data management or process management?

Schuler: Ultimately, of course, improved business processes bring added value, but for them to work, the data has to be right, otherwise there will be media disruptions, for example.

Furthermore, artificial intelligence requires a whole new type of data quality. Even if the data is correct, clear and relevant, it can still be biased, for example, which does not lead to optimal results.

A high standard of data quality is only possible with functioning data management.

In your opinion, what are the advantages and disadvantages of the greenfield and brownfield approach for S/4 transformations?

Schuler: The question of whether to re-implement or convert cannot be answered in general terms; it requires a comprehensive evaluation. Firstly:

Depending on modules and customizations, but also on the data, a conversion may be technically impossible, especially if the system contains inconsistent legacy data.

Secondly, is it worth converting in terms of content? Conversion can only make sense if at least one of the existing systems has a process implementation, including data inventory, that is close to the target configuration.

The decisive factor is whether the rework exceeds the cost of a new implementation and whether the target configuration from a conversion can be achieved at all.

What processes and tools do you recommend for a landscape transformation as a prerequisite for an S/4 implementation?

Schuler: Even if conversion is possible, a process-oriented data migration tool can be indispensable. This is because data quality is not a purely technical issue:

Experts from the respective business areas must be involved in a structured manner in order to eliminate data inconsistencies and gaps. Otherwise, the new features of S/4 may simply not be usable.

When it comes to real-time evaluations of operational data, for example, and the optimal use of new data structures such as New General Ledger, Material Ledger or Business Partner, SAP S/4 Hana can provide virtually no added value without the right data quality.

And if further systems are to be consolidated into the converted S/4 system - and the associated cost savings often make up a decisive part of the profitability calculation - some projects without a reusable data management concept have to be stopped or at least postponed before they have even really begun.

Do you also use the SAP Data Hub in your transformation projects?

Schuler: Yes, we use the SAP Data Hub, but not for system conversions, because that's not what it's designed for:

Firstly, for replication-free access to huge data sets. This is necessary because storing and querying huge amounts of data requires sophisticated techniques such as Hadoop MapReduce. Replication in other applications such as Business Warehouse is therefore no longer possible.

Secondly, for massively parallel data processing including artificial intelligence. Replication-free access to huge volumes of data requires enormous processing capacities in order to make them available to the target applications in the required format.

And thirdly, for metadata management including lineage.

Are there key figures for data transformation in S/4 projects in terms of effort, time, costs, etc.?

Schuler: Yes, there are, but they are very specific. I would always recommend an individual assessment.

Does all the data in an ECC system have to be transferred to S/4 or are there also archive solutions?

Schuler: As a rule, not all ECC data should be transferred, especially not as it is. Conventional row-oriented memory is comparatively inexpensive, whereas column-based and in-memory memory costs a considerable premium in some cases.

Therefore, data objects that do not benefit from a column-based architecture, but also data objects that are rarely accessed, should be archived.

Real-time evaluations on operational data also require a whole new level of data quality. The data, including the master data, must be inherently consistent.

What experience do you have with classic ECC database sizes in the calculation of Hana memory sizing?

Schuler: The S/4 Hana sizing report as part of an S/4 readiness check gives a good indication. However, I would always plan a sandbox migration, not only to determine the actual storage requirements, but also to evaluate the entire conversion approach.