The right balance between core and cloud

Greenfield and brownfield have long been part of the vocabulary of all those who have even remotely anything to do with the changeover - even if this "color theory" is now somewhat outdated. However, very little has happened yet. In the DSAG Investment Report 2020, only ten percent of the companies surveyed stated that they were already using S/4. Nine percent are planning to make the switch this year. This is a significant increase compared to previous years. However, due to the effects of Covid-19, the slowly emerging momentum is likely to slow down again somewhat.
Core or Cloud

In our experience, a variety of reasons are keeping companies from a rapid transformation. One key aspect is a communicative and factual contradiction that SAP itself creates: On the one hand, the Walldorf-based company presents S/4 as a multifunctional digital core. On the other hand, SAP is stressing the idea of the "intelligent enterprise" that maps end-to-end processes with the help of a series of specific applications that are often operated in the cloud and do not necessarily originate from SAP. So what should companies rely on?

It is clear that you have to keep both in mind! When it comes to deployment, it is then a matter of making optimum use of the respective strengths and ultimately taking SAP's product strategy into account. The strength of S/4 Hana lies primarily in optimally mapping the central financial and logistics processes and supplying them with data in real time.

Online transaction processing (OLTP) and online analytical processing (OLAP) are closely interlinked, which is a real novelty in this form. The fact that SAP will continue to limit itself to supporting core processes with S/4 can be seen from a number of acquisitions in recent years: In 2018 alone, Contextor (RPA), Qualtrics (experience management), Coresystems (field service management), Callidus Software (sales management), and Recast.AI (bots and machine learning) were acquired.

Previous acquisitions - including Concur (travel management), Ariba (purchasing management) and SuccessFactors (human resources management) - are now an integral part of the SAP world. Most of the technologies acquired in this way have not been integrated into the S/4 code, but continue to operate as standalone applications with their respective advantages and can be connected to the digital core quite conveniently via the SAP Cloud Platform (SCP).

Planned changeover

When migrating to S/4 Hana, companies need to decide what they want to map in the digital core and what they want to run via cloud applications or the SAP Cloud Platform - whereby it should be ensured that processes are really considered end-to-end and supported end-to-end. There are basically three approaches to dealing with existing customer-specific applications on the SAP ECC to be replaced when transforming to SAP S/4:

If companies primarily want to protect their investments in current processes and functions, customizations and in-house developments, they can transfer these as completely as possible from ERP/ECC 6.0 to S/4 Hana and merely adapt them to the new technological environment. This presupposes comprehensively adapting the standard under S/4 as well.

In this case, the innovation potential of S/4 remains largely unused. If companies are interested in protecting their investments while also benefiting from digital innovations, a detailed evaluation of all objects is recommended: Which developments can be sensibly outsourced to cloud applications or the SCP? And which should be mapped in the S/4 standard - even if this has to be adapted for this purpose?

If companies are primarily concerned with preparing for a complete switch to the cloud and want to minimize maintenance effort, they should align an S/4 Hana on-premises system as closely as possible to the standard. Everything that requires extensive customization is outsourced to the cloud.

What is the best approach for a company depends entirely on the specific situation - especially on which processes and functions are supported by in-house developments. In our view, there is no way around a precise analysis.
Core-Cloud balancing act

This is how an automotive manufacturer, for example, proceeded: Together with MHP, the OEM first analyzed its more than 1,500 proprietary developments implemented in SAP ECC to determine whether it made sense to map them to the SAP Cloud Platform.

The assessment was based on a catalog of criteria that took into account, among other things, the data sources and volume, the form of access, and the functions required. We then defined a series of use cases that were implemented as pilots on the SCP in order to gain experience with the new technologies and services. Some of these were already existing scenarios, but others were newly conceived use cases.

Among other things, we designed and implemented the prototype of a contract management application. The goal of this application is to streamline the previous non-transparent contract process and to document it in a comprehensible manner. In addition, a consensus was to be created between the contracting parties on the authenticity and immutability of exchanged documents. For the implementation, we used a number of SAP services that are available in this form in the standard SAP Cloud Platform - such as the Hana Service, the Document Service, Forms by Adobe, and the UI Development Toolkit SAP UI5.

Blockchain

In addition, the "Hyperledger Fabric Blockchain as a Service" was used to integrate a blockchain as a trust layer. The service not only provides the infrastructure and frameworks and thus significantly accelerates the prototypical realization of a blockchain application. The SCP also enables secure integration of the blockchain into the SAP system landscape and thus a secured interface to the outside world.

This means, for example, that data from SAP Extended Warehouse Management (SAP EWM) can be made available to external partners via the blockchain in a trustworthy manner. Or - as in the case of the car manufacturer's contract management application - the integrity of the data in central stores such as Hana DB can be reliably guaranteed. This integrity function thus guarantees the contract partners the immutability of contract documents without the need for an intermediary.

The unchangeable rules on the blockchain - so-called smart contracts - also ensure that processes are adhered to and at the same time documented in a forgery-proof manner. Dubious actions and attempts at deception are thus preemptively counteracted.