With SAP Standard, SAP already covers most processes and requirements of companies - under SAP S/4HANA even more than ever before. Basically, this is comparable to a construction kit that provides suitable building blocks for all relevant requirements.
If a company implements SAP S/4HANA in the standard, then the system does not differ from systems of other companies. In the standard, all systems are the same.
However, it is often necessary to extend the standard with individual solutions. This is the case when certain requirements of a company have to be met - for example, when a company needs to map a completely unique solution in logistics or production.
SAP offers various options for extending the standard: modifications to the source code within the original program, user exits, business add-ins (BAdIs) or even customer-specific programming, the Z programs.
What are the advantages of Z programs?
The SAP standard cannot always meet all the requirements of companies. The Z programs are therefore a way of mapping individual requirements with your own solutions. In this way, each SAP system can be optimally adapted to the company's own needs.
In-house developments help, for example, to simplify certain processes in companies. For example, companies can automate recurring tasks with their help.
Why is it so time-consuming to migrate the customer's own code when switching to SAP S/4HANA?
Migrating the customer's own code in particular can take an enormous amount of time. That's simply because of the large amount of code that exists in most companies.
Two million lines of code - that's how much proprietary code each SAP customer has developed themselves on average, for example. It should therefore be clear that simply moving these volumes of data into a new system involves a considerable amount of work.
And there is something else: The code still has to be tested before migration, because otherwise it can lead to inconsistencies in the new system.
Accepting code more or less untested is therefore a risk that can jeopardize the entire migration. After all, code that runs smoothly on old systems does not necessarily do so in the new SAP S4/HANA system.
Technical aids can be used to reduce the migration effort. Code scanners, for example, are suitable for testing the code. They automatically scan the code for errors and inconsistencies.
However, this creates a new challenge that must be overcome. This is because the quantities of errors found are often considerable - six-digit error quantities are the rule rather than the exception.
However, the amount of code (and thus the number of possible errors) can be reduced simply by removing code that is no longer needed.
Often there is still code in the system that is now obsolete: applications have long since been replaced by new standards or belong to test programs that were only used once.
Those who remove this code and fundamentally clean up their system create the conditions for a smooth migration. In this way, they will also be better equipped to meet future requirements. One thing is clear: The better the data quality in the source system, the better the migration will work - fewer errors will occur and the quality of the loaded data will be higher.
What to do when switching to S/4HANA? Can Z programs be transferred?
When a company switches to SAP S/4HANA, in-house developments (transactions, programs, function modules, etc.) can usually be transferred as well. Whether this makes sense, however, is another question.
For one thing, SAP S/4HANA already maps most of the relevant requirements for many sectors and industries with its SAP best practice standards. Whether individual development is necessary at all or has not already become dispensable must be analyzed on a case-by-case basis.
As part of a system conversion, Z programs are checked for their need to be adapted to the SAP HANA database technology.
For example, selection results on SAP HANA database tables are not automatically sorted by key fields by definition. If such errors are not corrected, this can possibly lead to consequential errors in the processing of the data. In addition, conflicts are analyzed in reconciliation with the SAP S/4 HANA Simplification List.
When companies implement SAP S/4HANA for the first time, they also have the option of mapping their individual requirements using Fiori apps. Thousands of apps are already available for this purpose. In addition, custom apps can be developed.
The possibilities for expansion through individual apps are almost limitless. They basically make the Z programs superfluous today.
In addition, the migration to SAP S/4HANA offers the opportunity to part with an IT landscape that has often become very complex over the years and to make a fresh start with SAP S/4HANA.
For companies, this is a rare opportunity to get rid of obsolete data or faulty code in one fell swoop and arrive at a lean and efficient system in the standard. Often, not all Z programs in the system are needed anymore. With each upgrade, however, these can lead to additional work under certain circ*mstances.
For a fresh start with SAP S/4HANA, companies must migrate using the greenfield approach. Unlike the brownfield approach, this is not just a 1:1 copy of the existing system. Rather, SAP S/4HANA is set up completely from scratch.
Each individual Z program transferred to SAP S/4HANA as part of a system conversion (brownfield), on the other hand, creates more complexity and usually higher maintenance costs - and thus also reduces the benefits derived from SAP S/4HANA.
