The Right Balance Between Core And Cloud

This article was written in cooperation with Katarina Preikschat, Blockchain Portfolio Developer at MHP.

Anyone dealing with a transformation project (even those on the periphery) has been familiar with the greenfield and brownfield approaches for many years now, even though this ‘color guide’ has since become somewhat obsolete. Yet despite everyone knowing the right terminology, very little practical progress has been made. According to the 2020 Investment Report by DSAG (the German-speaking SAP user group), just ten percent of the companies surveyed confirmed that they are already using S/4. Nine percent plan to switch this year. This is a significant increase compared to previous years, but the slowly growing momentum is likely to drop again due to the effects of COVID-19.

Core or cloud?

In our experience, companies hold back from undertaking a rapid transformation process for a variety of reasons, a key one being inconsistent communication and information from SAP: On the one hand, the Walldorf-based company showcases S/4 as a multifunctional digital core. On the other hand, SAP emphasizes its Intelligent Enterprise idea, the concept of mapping end-to-end processes using a series of specific applications that are often run in the cloud and not necessarily developed by SAP. So which format should companies choose?

It’s clear to us that both merit serious consideration! Any transformation project should aim to utilize the advantages of the relevant format as effectively as possible and ultimately take the SAP product strategy into account. The main advantage of S/4 is the ability to optimally map out central financial and logistics processes and to supply the relevant data in real time. S/4 links online transaction processing (OLTP) and online analytical processing (OLAP), which is a genuine innovation. SAP’s plans to continue limiting its support to core processes with S/4 can be inferred from a number of acquisitions over the past few years: In 2018 alone, SAP acquired Contextor (Robotic Process Automation), Qualtrics (experience management), Core Systems (field service management), Callidus Software (sales management), and Recast.AI (bots and machine learning). The SAP world now includes some previous acquisitions too, including Concur (travel management), Ariba (purchasing management), and SuccessFactors (human resources management).

Most of the technologies acquired to date have not been integrated into the S/4 code. Instead, they still operate as stand-alone applications with their own advantages, and they can be connected to the digital core with relative ease via SAP Cloud Platform (SCP).

Planning the transition

When transitioning to S/4 Hana, companies need to decide what they plan to run using the digital core and what they want to run using cloud applications or SAP Cloud Platform in order to ensure that processes are truly captured end-to-end and supported consistently. In principle, there are three approaches for dealing with existing customer-specific applications on SAP ECC to be replaced by S/4 Hana.

If companies primarily wish to protect their investments in current processes and functions, customizations and in-house developments, they can transfer these features more or less entirely from ERP/ECC 6.0 to S/4 Hana and simply adapt them to the new technical environment. This approach still requires comprehensive adaptation of the S/4 standard. In this scenario, the innovation potential of S/4 is largely untapped. If companies have an interest in protecting their investments but also in benefiting from digital innovation, an in-depth analysis of all aspects is worth the effort: Which developments can be outsourced to cloud applications or SCP? Which developments need to be mapped to the S/4 standard (even though the standard would have to be adapted for this purpose)?

If companies are primarily preparing for a full transition to the cloud and wish to minimize maintenance work, the best approach is to align an S/4 Hana on-premises system as closely as possible with the standard. Everything that requires extensive adaptation should be outsourced to the cloud.

The best approach for each company depends entirely on the specific scenario – in particular on which processes and functions are supported by in-house developments. In our view, none of the three approaches warrants the decision to bypass an in-depth analysis.

The core/cloud balancing act

Here’s how one automotive manufacturer decided to proceed: Working with MHP, the OEM first analyzed its over 1,500 in-house developments implemented in SAP ECC to determine whether mapping to SAP Cloud Platform made sense.

The analysis was based on a set of criteria that included data sources and data volume, type of access and required functions. We then defined a number of use cases that were implemented on the SCP as pilot projects to gain experience with the new technologies and services. Some of these use cases represented scenarios that already existed while others were completely new.

For example, we designed and implemented a prototype for a contract management application. The aim of this prototype was to streamline the existing, non-transparent contract process and to establish a more reliable documentation process. Furthermore, it had to be possible for the contracting parties to agree on the authenticity and immutability of the documents being exchanged. During the implementation process we used a wide range of SAP services in the standard form that is part of the SAP Cloud Platform offering, including the Hana service, the document service, Adobe Forms and the SAPUI5 UI development toolkit.

Blockchain

We also used the SCP Hyperledger Fabric-based Blockchain as a Service to integrate a blockchain to increase trust. This service provides the necessary infrastructure and frameworks. It consequently considerably accelerated implementation of our prototype blockchain application. The SCP service also enables secure integration of the blockchain into SAP system landscapes, thus providing a secure interface to the outside world. For example, data from SAP Extended Warehouse Management (EWM) can be made available to external partners reliably via the blockchain.

In the case of the contract management application created by the automotive manufacturer, it is possible to guarantee the integrity of the data stored centrally in locations such as Hana. This guarantee of integrity allows the contracting parties to rely on the immutability of contract documents without the need for an intermediary. The immutable rules on blockchains – known as smart contracts – also ensure that processes are adhered to and at the same time documented in a manner that is immutable, meaning that preventative measures against dubious transactions and forgery are already built in.