How SAP Customization Is Suffering

In R/2, but especially in R/3, customers’ own developments were still part of SAP’s strategy and played an important role in its success. SAP provided customers with the necessary solutions in the form of standard modules. All modules were self-contained, but, at the same time, they were fully integrated with each other. A successful part of the strategy was also the possibility of adapting the modular standard solutions through customization, if required. The greatest benefit for customers was the ability to supplement standard solutions with their own developments of customer-specific requirements. A great concept for the customers! This approach made SAP as successful as it is today.

Overwhelmed support

However, due to an ever-increasing number of customers, the degree of customization quickly became a problem. Ongoing maintenance and provision of modifications, as well as ensuring the integration of the numerous customer-specific in-house developments, probably overwhelmed support. It is reasonable to assume that SAP sees S/4 as the solution. The new application platforms cloud, public cloud and private cloud were to replace the previous on-prem variants. Thus, SAP’s customers were put under pressure with a widely communicated “Cloud Only” strategy. The thing is, many customers had a big problem with this – until user groups came to the rescue.

SAP ruefully changed the S/4 strategy from “Cloud Only” to “Cloud First”, but this did not entirely solve customers’ problems. As standard solutions, public cloud solutions no longer allow any customer-specific adaptations. The private cloud still does, but it limits outsourcing options. As a result, most customers choose hybrid system landscapes, with their existing on-prem landscapes supplemented by cloud solutions. However, with this approach, they run into the problem of lack of integration.

It is a huge task to transform the countless in-house developments to S/4. This starts with evaluating of what is still needed and what is not. Customers should carefully examine which in-house developments can be completely or at least partially replaced by new S/4 applications.

Preferably immediately

This fit-gap analysis is one of the focal points in any S/4 transformation project. The result also shows which existing in-house developments need to be changed and where new in-house developments might be necessary. All in-house developments should be checked for their technical functionality during S/4 conversion because of massive changes in the existing data sets due to simplification as well as technological changes in programming. SAP provides very good services and tools for this. A good tip from my own experience and from many projects I’ve witnessed: You can never start too early.