Transfer Z programs to SAP S/4HANA

What are Z programs?

The terms Z programs and Z developments are collective terms for transactions, code, function modules and programs.

These are applications that are operated in addition to the original SAP programs - i.e. outside the standards. These add-ons map individual processes of companies and offer solutions that go beyond the standard.

However, if many Z programs accumulate over the years - as was the case in many companies under SAP ECC - this leads to an increasingly complex IT architecture over time.

This results in several problems at once:

• Maintenance and service costs increase.
• The responsiveness of IT decreases.
• In addition, companies must ensure that their individual solutions continue to function with every upgrade of the SAP system.

What does the "Z" in Z-Programs stand for?

Most SAP applications are written in ABAP, SAP's proprietary programming language. The acronym ABAP stands for "Advanced Business Application Programming." Developers can modify or extend SAP applications in ABAP.

To be able to recognize to which module or area in SAP a program belongs, certain naming conventions apply.

The so-called packages are decisive here. The packages contain objects defined within ABAP (such as data types, data objects or classes) and allow ABAP to be structured more easily.

For assignment and differentiation, the packages are marked - among other things - with certain initial letters in the naming. Packages with the initial letters A to S and U to X, for example, are reserved for SAP standard objects.

Customer-specific objects, on the other hand, can be created with the initial letters Z or Y - these are the well-known Z programs, Z developments or also Y programs.

What are the options for customizing SAP systems?

SAP customizing refers to the basic settings and adjustments of an SAP system. If a company introduces a new ERP system such as SAP S/4HANA, the SAP experts must first always make company-specific basic settings.

In addition to SAP Customizing, a company - which is implementing or operating an SAP ERP system - has various other options for adapting the SAP system to its individual requirements. Experts refer to these solutions as customer-specific ABAP developments.

For example, companies can modify the original programs. To do this, developers make changes to the original source code.

In this case, SAP refers to modifications. Such modifications should be the exception rather than the rule. The problem is that the modifications always have to be adapted to new versions in later releases or even completely reimplemented. This is time-consuming and usually takes a lot of time.

The SAP enhancement concept (see also Enhancement Framework) offers a solution to this problem.

Under this concept, companies insert their own code (source code plug-ins) as enhancements at suitable points in the source code specified by SAP.

Compared to modifications, enhancements require significantly less effort in the event of an upgrade. However, extensions should also be used with caution. There is no guarantee for a further use in case of a release change.

It is also possible to develop individual solutions that are outside the standard. These in-house developments are then linked to the original programs. Experts refer to these as Z-programs or Z-developments.

What are enhancement options, what are enhancement implementations?

In its SAP enhancement concept, SAP distinguishes between enhancement options and enhancement implementations.

Enhancement options are pure possibilities of enhancement. They are either defined explicitly (i.e., as potentially favorable locations for enhancements) or already exist implicitly.

Implicit enhancement options exist at all locations in ABAP programs that can be uniquely described (that is, for example, the beginning or end of a particular section of code).

Enhancement implementations, on the other hand, are the actual enhancements - that is, the source code fragments inserted at a specific point in the source code.

What is the Enhancement Framework?

The Enhancement Framework is a tool for developers. With this tool, they can add their own functions to SAP's standard software.

SAP has developed the Enhancement Framework primarily to partially integrate and replace the enhancement and modification concepts described at the beginning. In addition, the framework is already suitable for new technologies such as SAP Fiori.

The framework offers the possibility to realize modification-free enhancements of data objects and processes - by adding user-defined fields, customer-specific processing logic as well as by creating global classes and user-defined business objects.

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 circumstances.

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.