The suffering of proprietary developments

Under version R/2, but especially under R/3, customers' own developments were still part of SAP's strategy and played an important role in the success story. SAP provided customers with the necessary solutions as standard solutions in the form of modules. On the one hand, all modules were self-contained, but on the other hand, they were fully integrated with each other when additional modules were used. A successful part of the strategy was also the possibility of adapting the modular standard solutions through modifications, if required. In addition, the greatest benefit for customers was the ability to supplement the standard solutions with their own developments of customer-specific requirements. A really great concept for the customers! This combination and integration also led SAP to its leading market position.

Overstrained support

However, due to the global growth in customers, SAP may have had a problem with this. The ongoing maintenance and provision of modifications, as well as ensuring the integration of the numerous customer-specific in-house developments, probably overwhelmed support. It seems reasonable to assume that the problem should be solved with S/4 by adjusting the strategy. 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 the widely communicated cloud-only strategy. The only problem was that many customers, especially existing customers, had a big problem with this - until DSAG came to the rescue.

SAP changed its S/4 strategy from cloud only to cloud first, but this did not solve the customer problems. As standard solutions, the cloud solutions and the public cloud no longer allow any customer-specific adaptations. Only the private cloud is left for this, but from the point of view of the system architecture, this also represents only limited outsourcing. As a result of this situation, most existing customers go down the path of hybrid system landscapes with the existing on-prem variant supplemented by cloud solutions. With this approach, however, they run into the problem of the still often missing integration.

In addition to the challenges of the limited modifications, it is a huge task and effort to bring the numerous in-house developments into the S/4 transformation. This starts with the selection of the additional developments with regard to what is still needed and what is not. Above all, many reports are no longer used after users have left the company. The "mucking out" of in-house developments is a good deed, because it can also reduce operating expenses. At the same time, one should carefully examine which in-house developments can be completely or at least partially replaced by the new S/4 applications.

This fit-gap analysis is one of the focal points in every S/4 transformation project. The result also shows which existing in-house developments need to be changed and where new in-house developments are necessary. The reasons for this are changes in processes or functional alignment with the new S/4 applications. In many projects, implementation is also prioritized for reasons of time and cost.

In any case, all in-house developments must be checked for their technical functionality during the S/4 conversion. The reasons for this are the 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 is that you cannot start early enough.