Nicht alles muss mit: SAP Eigenentwicklungen entkoppeln, bevor sie Ihren Umzug ausbremsen

Z-Programme und Modifikationen kosten in vielen S/4HANA-Projekten mehr Zeit als der Standard. Wie Sie sortieren, was abgeschaltet wird, was bleibt und was vorab aus dem Kern geht.

Das Wichtigste in Kürze

• In vielen Conversion-Projekten kosten die Eigenentwicklungen mehr Zeit als der SAP-Standard.
• Eine Inventur sortiert sie nach Nutzung und Bauart: abschalten, im Kern behalten oder auslagern.
• Anwendungen mit eigener Oberfläche und eigenem Prozess lassen sich vor der Conversion neben dem ERP neu aufbauen und verlassen damit den Conversion-Scope.
• Nach dem Umstieg wird nur die Schnittstelle angepasst. Oberfläche und Prozesslogik bleiben, wie die Anwender sie kennen.

SAP Eigenentwicklungen entkoppeln heißt: Anwendungen, die heute im ECC-Kern laufen, werden vor der Conversion auf eine Plattform neben dem ERP verlagert und greifen über Standardschnittstellen auf SAP zu. Der Kern wird schlanker, die Conversion trägt weniger Ballast, und die Anwendung läuft nach dem Umstieg weiter.

SAP Eigenentwicklungen entkoppeln: Warum gerade jetzt?

Für ECC auf einer Drittdatenbank ist eine Conversion nach S/4HANA nur bis Ende 2030 möglich (SAP News Center, 7.10.2026). Jede Eigenentwicklung im Kern muss bis dahin geprüft und entweder angepasst oder abgeschaltet werden. Je mehr im Kern liegt, desto länger dauern Analyse und Test, und desto weniger Puffer bleibt bis zur Frist.

Die DSAG begründet den Zeitbedarf ihrer Mitglieder ausdrücklich mit der Komplexität der Systemlandschaften (DSAG-Investitionsreport 2026). Knapp die Hälfte der ECC-Anwender, die noch in das System investieren, plant den Wechsel auf S/4HANA erst bis Ende 2030 und damit bis zur letzten Möglichkeit für eine Conversion von Drittdatenbanken. Welche Fristen genau gelten, fasst unser Überblick SAP Drittdatenbank 2030 zusammen.

Was zählt alles zu den Eigenentwicklungen?

Zu den Eigenentwicklungen zählt alles, was nicht SAP-Standard ist und trotzdem am ERP hängt. Dazu gehören Z-Transaktionen und Z-Reports, Modifikationen am Standard, eigene Workflows, Erfassungsmasken, Java-Anwendungen sowie Excel-Lösungen mit Schnittstelle ins ERP. Viele davon sind über Jahre gewachsen und kaum dokumentiert.

Im Einkauf ist es zum Beispiel die Freigabe von Bestellanforderungen mit eigenen Wertgrenzen und Vertretungsregeln. In der Logistik eine Erfassungsmaske für Wareneingänge mit Zusatzfeldern, die der Standard nicht kennt und die das Lager seit Jahren täglich nutzt. In der Instandhaltung eine Störmeldemaske im Portal, die Techniker unterwegs auf dem Tablet ausfüllen.

Abschalten, behalten oder auslagern: Wie sortieren Sie?

Sortieren Sie jede Eigenentwicklung nach zwei Kriterien: Wird sie genutzt, und hat sie eine eigene Oberfläche mit eigenem Prozess? Was nicht genutzt wird, schalten Sie ab. Was ohne eigene Oberfläche eng mit der Standardlogik verwoben ist, bleibt im Kern. Der Rest ist ein Kandidat zum Auslagern.

Für die erste Gruppe liefern Nutzungsdaten aus dem System schnelle Anhaltspunkte, etwa aus der Workload-Statistik oder dem ABAP Call Monitor (SCMON). Die dritte Gruppe ist der eigentliche Hebel: Sie verschwindet aus dem Conversion-Scope und ist danach sofort wieder verfügbar.

Wie läuft eine Inventur der Eigenentwicklungen ab?

Eine Inventur der Eigenentwicklungen verbindet technische Daten mit dem Wissen der Fachbereiche. Die Technik liefert, welche Objekte es gibt und wie oft sie genutzt werden. Die Fachbereiche sagen, welcher Prozess dahintersteht und ob er in dieser Form noch gebraucht wird. Erst beides zusammen ergibt eine belastbare Liste.

1. Objekte aus dem System exportieren: Z-Programme, Z-Transaktionen, Modifikationen und Erweiterungen.
2. Nutzungsdaten über mindestens zwölf Monate zuordnen.
3. Je Objekt den Prozess und den verantwortlichen Fachbereich benennen.
4. Die Gruppe festlegen: abschalten, im Kern behalten oder auslagern.
5. Kandidaten zum Auslagern nach Nutzerzahl und Aufwand priorisieren.

Ein Hinweis aus der Praxis: Zwölf Monate Nutzungsdaten sind das Minimum, weil Programme für den Jahresabschluss sonst als ungenutzt durchrutschen. Ein Z-Report, der nur im Dezember läuft, ist nicht überflüssig. Er wird nur selten gebraucht.

KI kann diese Inventur deutlich beschleunigen, indem sie Funktionen, Oberflächen, Logik und Integrationen bestehender Anwendungen automatisch erfasst und nach Nutzen und Aufwand vorsortiert. Die Entscheidung, was abgeschaltet wird, bleibt trotzdem beim Fachbereich.

Wie funktioniert Side-by-Side vor der Conversion?

Side-by-Side bedeutet, dass eine Anwendung außerhalb des ERP-Kerns läuft und über Standardschnittstellen auf SAP-Daten zugreift. Vor der Conversion heißt das: Die Anwendung wird neu aufgebaut, solange noch ECC dahinter läuft. Anwender arbeiten schon vor dem Umstieg in der neuen Oberfläche, und das Original im Kern wird abgeschaltet.

1. Die Anwendung wird auf einer Plattform neben dem ERP neu aufgebaut.
2. Sie greift über Standardschnittstellen lesend und schreibend auf ECC zu.
3. Anwender wechseln in die neue Oberfläche, die alte läuft für einen Übergang parallel.
4. Das Original im Kern wird abgeschaltet und aus dem Conversion-Scope genommen.
5. Nach der Conversion wird die Schnittstelle auf S/4HANA umgestellt.

Am Beispiel der Freigabe von Bestellanforderungen: Die neue App liest offene Bestellanforderungen aus ECC, zeigt sie dem Freigeber auf dem Smartphone und schreibt die Freigabe zurück. Die Z-Transaktion wird abgeschaltet. Nach der Conversion zeigt die Schnittstelle auf S/4HANA, und für den Freigeber ändert sich nichts.

Was bringt die Entkopplung außer Zeit?

Außer Zeit bringt die Entkopplung einen Kern, der nach der Conversion nah am Standard bleibt. Das ist die Idee von Clean Core: Erweiterungen laufen außerhalb des ERP und greifen über stabile Schnittstellen zu, damit das ERP updatefähig bleibt. Wer vor der Conversion entkoppelt, startet in S/4HANA bereits mit einem schlanken Kern.

Dazu kommt weniger Druck beim Go-live, weil Anwender die neue Oberfläche schon kennen. Außerdem kann die ausgelagerte Anwendung Daten aus Nicht-SAP-Systemen einbeziehen, etwa aus einem Lieferantenportal oder einem Fertigungsleitsystem. Das war im ABAP-Kern oft nur mit zusätzlichen Schnittstellen möglich. Wo die ausgelagerten Anwendungen laufen sollten, beschreibt SAP Clean Core ohne BTP.

Ein oft unterschätzter Effekt: Beim Neuaufbau wird Logik dokumentiert, die bisher nur im Code und in den Köpfen einzelner Entwickler steckte. Das senkt das Risiko, wenn langjährige Mitarbeitende das Unternehmen verlassen.

Wo stößt Side-by-Side an Grenzen?

Side-by-Side ist kein Allheilmittel. Logik, die tief in Standardprozesse eingreift, etwa in Preisfindung oder Buchungslogik, gehört weiterhin in den Kern oder in die von SAP vorgesehenen Erweiterungspunkte. Auch das Auslagern kostet Aufwand. Es lohnt sich vor allem bei Anwendungen mit vielen Nutzern, die nach der Conversion weiterlaufen sollen.

Prüfen Sie außerdem, ob für den Prozess inzwischen eine Standardlösung in S/4HANA existiert. Manche Eigenentwicklung von 2010 deckt der Standard heute ab. Dann ist Abschalten die bessere Wahl als Auslagern.

Und jede ausgelagerte Anwendung braucht einen Verantwortlichen im Betrieb. Wer eine Plattform neben dem ERP einführt, sollte von Anfang an klären, wer Updates einspielt und wer bei Störungen reagiert.

Warum Einzellösungen ab dem fünften Use Case teuer werden

Einzel-Apps oder schnell erzeugte KI-Prototypen lösen einen Use Case oft schnell. Die Kostenfrage beginnt ab dem fünften: Betrieb, Änderungen, Berechtigungen, Monitoring und Verantwortlichkeit skalieren ohne Plattform nicht sauber mit. Jede weitere Einzellösung bringt eigene Schnittstellen und eigene Lücken im Audit mit.

Gerade beim Entkoppeln vor der Conversion entstehen schnell viele kleine Anwendungen. Werden sie einzeln gebaut, verlagert sich der Wildwuchs aus dem ABAP-Kern in eine Sammlung von Insellösungen. Die Entkopplung zahlt sich erst aus, wenn die ausgelagerten Anwendungen in einem gemeinsamen Betriebsmodell laufen.

Unsere Empfehlung

Unsere These: Die Inventur der Eigenentwicklungen gehört an den Anfang jedes S/4HANA-Projekts, noch vor die Wegentscheidung. Sie verkürzt jede Variante. Brownfield wird schlanker, und bei Greenfield wissen Sie genau, welche Anwendungen neu entstehen müssen. Wer die Inventur auf die Testphase verschiebt, findet den Ballast dort, wo er am teuersten ist.

Rechnen Sie dabei in Prozessen statt in Objekten: Zwanzig Z-Programme, die gemeinsam eine Freigabe abbilden, sind ein Kandidat und nicht zwanzig. Welcher Weg danach für Sie passt, vergleicht der Beitrag zur S/4HANA Conversion Frist 2030.

Simplifier ist eine Enterprise-Plattform für Anwendungen und KI-Agenten, die neben dem ERP läuft und über Standardschnittstellen lesend und schreibend auf SAP zugreift. Eigenentwicklungen der Gruppe „auslagern“ entstehen dort neu, solange ECC noch läuft, und bleiben nach dem Umstieg erhalten. Bauen lässt sich heute vieles schnell, auch mit KI. Der Unterschied beginnt am ersten Produktivtag: Simplifier betreibt die Anwendungen mit Rollen, Freigaben, Audit Trail und Monitoring und hält sie über den Umstieg auf S/4HANA hinweg upgrade-sicher. Gern gehen wir Ihre Liste gemeinsam mit Ihnen durch.

Für die Inventur setzt Simplifier Miri ein, eine KI-Migrations-Agentin. Sie analysiert bestehende Anwendungen, etwa ABAP-basierte Z-Anwendungen oder Fiori- und UI5-Apps, und erfasst Funktionen, Oberflächen, Logik und Integrationen. Daraus entstehen eine Priorisierung nach Geschäftsrelevanz und Aufwand, technische Spezifikationen und ein Migrationsplan. Anschließend beschleunigt Miri den Neuaufbau auf Simplifier. Produktiv geht eine migrierte Anwendung erst, wenn sie fachlich validiert und getestet ist.