Eigener Code im Umstiegsprojekt

Eigenentwicklungen vor dem Umstieg auf SAP S/4HANA prüfen

Die meisten Häuser unterschätzen die Menge und überschätzen die Notwendigkeit. Beides lässt sich mit Zahlen aus dem eigenen System klären, nicht mit Meinungen.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Kleine Gruppen Präsenz und Live-Online Zertifizierte Trainer
Worum es geht

Niemand kennt den Bestand, alle verteidigen ihn

In der ersten Projektsitzung fällt fast immer eine Zahl, meist aus dem Bauch. Wenige Wochen später liegt eine Auswertung vor, und sie ist regelmäßig deutlich größer als die geschätzte Zahl. Das liegt daran, dass zum eigenen Bestand mehr gehört als die Programme, an die alle denken: Erweiterungen an SAP-Objekten, Formulare, Schnittstellenbausteine, Auswertungen einzelner Abteilungen, Hilfsprogramme aus alten Projekten und Reste, die nach einer Ablösung nie entfernt wurden.

Der zweite Effekt ist noch teurer. Sobald in einer Runde gefragt wird, ob ein bestimmtes Programm noch gebraucht wird, lautet die Antwort fast immer ja. Das ist keine Böswilligkeit, sondern eine vernünftige Vorsicht: Niemand möchte derjenige sein, der etwas abgeschaltet hat, das dann doch gebraucht wird. Deshalb führt die Frage nach der Notwendigkeit auf diesem Weg nie zu einer Reduktion, sondern nur zu einer längeren Liste.

Der dritte Punkt ist die technische Tiefe. Zwei Programme, die im Betrieb gleich aussehen, können sehr unterschiedlich teuer sein: eines liest über freigegebene Schnittstellen, das andere greift direkt in SAP-interne Objekte oder schreibt in SAP-Tabellen. Der Unterschied entscheidet über den Anpassungsaufwand jetzt und über die Kosten bei jedem künftigen Releasewechsel, und er ist von außen nicht sichtbar.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Schritt für Schritt

Der Ablauf, Schritt für Schritt

Sechs Stationen von der Inventur bis zur Abschaltung. Die Reihenfolge ist so gewählt, dass die teuren technischen Prüfungen erst auf dem Bestand stattfinden, der die Nutzungsprüfung überstanden hat.

  1. 1

    Vollständig inventarisieren

    Erfasst nicht nur eigene Programme, sondern auch Erweiterungen an SAP-Objekten, Formulare, Schnittstellenbausteine, eigene Tabellen und Auswertungen. Ergänzt je Objekt, wer es fachlich verantwortet und aus welchem Zusammenhang es stammt. Wo diese Angabe fehlt, ist das bereits ein erstes Ergebnis: Ein Objekt ohne fachliche Verantwortung ist ein starker Kandidat für die Abschaltliste.

    Geschafft, wenn: Eine vollständige Liste mit Typ, Zeitpunkt der letzten Änderung und, soweit vorhanden, einer fachlichen Verantwortung je Objekt.

  2. 2

    Nutzung über zwölf Monate messen

    Erhebt für jedes Objekt, ob und wie oft es im letzten Geschäftsjahr aufgerufen wurde. Ein volles Jahr ist nötig, weil Abschluss, Inventur und Saisonabläufe eigene Programme haben. Trennt in der Auswertung nach Aufrufen durch Personen und Aufrufen aus anderen Programmen, denn ein selten aufgerufenes Objekt kann in einer wichtigen Kette hängen.

    Geschafft, wenn: Eine Nutzungsspalte je Objekt und eine erste Trennung in benutzt, selten benutzt und im ganzen Jahr nicht aufgerufen.

  3. 3

    Widerspruch einholen statt Zustimmung

    Legt die Liste der ungenutzten Objekte den Fachbereichen vor, mit einer Frist und der Bitte um begründeten Widerspruch. Sagt dabei ausdrücklich zu, dass abgeschaltete Objekte für einen definierten Zeitraum wiederherstellbar bleiben. Diese Zusage nimmt der Sache die Schärfe und ist der Grund, warum die Liste am Ende tatsächlich kürzer wird.

    Geschafft, wenn: Eine bereinigte Abschaltliste mit dokumentierten Widersprüchen und den Gründen dafür.

  4. 4

    Den Rest technisch einstufen

    Bewertet die verbliebenen Objekte nach den vier Clean-Core-Stufen und prüft, welche Bereiche des Datenmodells sie berühren. Besonders im Blick behalten müsst ihr Zugriffe auf die entfallenen Summen- und Indextabellen des Rechnungswesens sowie alles, was Kunden- und Lieferantenstammdaten liest oder schreibt, weil dort der Geschäftspartner das führende Objekt ist.

    Geschafft, wenn: Eine Einstufung je Objekt von Level A bis D, ergänzt um die Stellen, an denen das Zielrelease eine Anpassung erzwingt.

  5. 5

    Ersatzweg je Objekt festlegen

    Für alles, was fachlich nötig ist und in Level C oder D liegt, entscheidet ihr den Weg: Standardfunktion nutzen, On-Stack mit ABAP Cloud neu bauen oder Side-by-Side auf der SAP BTP. Für transaktionale Anwendungen im System selbst ist das ABAP RESTful Application Programming Model der vorgesehene Weg, es baut auf Core Data Services, Verhaltensdefinitionen und Geschäftsobjekten auf.

    Geschafft, wenn: Eine Zuordnung von Ersatzweg und Aufwand je Objekt, aus der sich ein belastbarer Anteil am Projektaufwand ergibt.

  6. 6

    Abschalten, beobachten, entfernen

    Schaltet in Stufen ab: erst den Zugang sperren, dann eine festgelegte Zeit beobachten, dann entfernen. Haltet fest, wer wann was abgeschaltet hat und bis wann eine Wiederherstellung möglich ist. Diese Dokumentation ist weniger für die Technik als für das Vertrauen im Haus wichtig, denn sie macht aus einer riskant wirkenden Aktion einen nachvollziehbaren Vorgang.

    Geschafft, wenn: Ein messbar kleinerer Bestand, dokumentiert je Objekt, und ein Projektaufwand, der sich nur noch auf das bezieht, was wirklich gebraucht wird.

Vier Körbe, in die jedes Objekt kommt

  1. 01 Abschalten: im letzten Geschäftsjahr nicht aufgerufen, kein begründeter Widerspruch bis zum Stichtag.
  2. 02 Ersetzen: die Funktion gibt es inzwischen im Standard, das eigene Objekt ist nur noch Gewohnheit.
  3. 03 Neu bauen: fachlich nötig, technisch aber tief in SAP-Interna verankert, also upgradestabil neu aufsetzen.
  4. 04 Bleiben und anpassen: fachlich nötig, technisch sauber, betroffen nur von den Änderungen im Datenmodell.
  5. 05 Für alle vier gilt: eine Marke, ein Name, ein Datum. Ohne diese drei Angaben ist es keine Entscheidung.
Was du mitnimmst

Wie ihr aus einer Liste eine Entscheidung macht

Die Bewertung braucht drei Datenquellen und eine Regel für den Fall, dass sie sich widersprechen. Alles Weitere ist Fleißarbeit, die sich verteilen lässt.

Nutzung über ein volles Geschäftsjahr messen

Ein kürzerer Zeitraum verzerrt das Bild, weil Jahresabschluss, Inventur und saisonale Abläufe eigene Programme haben, die nur in wenigen Wochen des Jahres laufen. Erst nach zwölf Monaten habt ihr eine Aussage, die im Zweifel auch verteidigt werden kann.

Die Frage nach der Notwendigkeit umdrehen

Fragt nicht, ob etwas noch gebraucht wird, sondern legt eine Liste der ungenutzten Objekte vor und bittet um Widerspruch mit Begründung bis zu einem Datum. Der Unterschied im Ergebnis ist erheblich, weil die Beweislast dorthin wandert, wo das Wissen sitzt.

Technisch einstufen statt nur zählen

Sortiert jedes Objekt danach, wie tief es in SAP-Interna greift. SAP unterscheidet dafür vier Clean-Core-Stufen: Level A nutzt ausschließlich öffentlich freigegebene, stabile Schnittstellen mit Stabilitätszusage, Level B zusätzlich klassische SAP-Schnittstellen, Level C greift auf SAP-interne Objekte zu und gilt als nur teilweise konform, Level D umfasst nicht empfohlene Techniken wie Modifikationen oder schreibende Zugriffe auf SAP-Tabellen.

Gegen die Änderungen im Zielrelease halten

Prüft für jedes verbleibende Objekt, ob es Bereiche berührt, die sich im Ziel geändert haben. Die Simplification List führt diese Änderungen je Release auf, für SAP S/4HANA 2025 samt Feature Pack Stack 1 in der Fassung vom Februar 2026. Besonders betroffen sind Zugriffe auf entfallene Summen- und Indextabellen sowie alles rund um Kunden- und Lieferantenstammdaten.

Je Objekt eine von vier Entscheidungen treffen

Bleiben und anpassen, durch Standardfunktionen ersetzen, upgradestabil neu bauen oder abschalten. Wichtig ist, dass jedes Objekt genau eine dieser vier Marken bekommt und dass es dafür einen Namen und ein Datum gibt. Objekte ohne Entscheidung sind der Grund, warum solche Listen im zweiten Projektjahr unverändert wieder auftauchen.

Den Neubau ab sofort an Regeln binden

Solange das Projekt läuft, entsteht weiter Code. Legt jetzt fest, dass neue Erweiterungen upgradestabil gebaut werden, also On-Stack mit ABAP Cloud im System selbst oder Side-by-Side als entkoppelte Anwendung auf der SAP Business Technology Platform. Sonst räumt ihr an einem Ende auf, während am anderen nachwächst.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Was ABAP Cloud technisch bedeutet

ABAP Cloud ist das Entwicklungsmodell für clean-core-konforme, cloudfähige Anwendungen, Services und Erweiterungen auf der SAP Business Technology Platform, in SAP S/4HANA Cloud und in SAP S/4HANA. Es ist kein Aufruf zur Zurückhaltung, sondern ein technisch durchgesetzter Rahmen, und genau das macht es für die Bewertung eures Bestands nützlich.

Durchgesetzt wird der Rahmen über eingeschränkte Sprachversionen. ABAP for Cloud Development deckt nur eine Teilmenge des ABAP-Sprachumfangs ab, und der Zugriff auf Objekte ist eingeschränkt: Ein Objekt ist nur dann nutzbar, wenn es als freigegebene Schnittstelle mit einem Release-Kontrakt klassifiziert ist, in der Regel dem Kontrakt C1. Daneben gibt es die Sprachversion für Key User. Wichtig ist die Einschränkung dieser Regel: Objekte im selben Softwarepaket bleiben zugänglich, es ist also nicht alles verboten, was nicht von SAP stammt.

Für neue transaktionale Anwendungen im System selbst ist das ABAP RESTful Application Programming Model der vorgesehene Weg. RAP ist ein wesentlicher Bestandteil von ABAP Cloud und dient dem Bau transaktionaler SAP-Fiori-Apps, OData-basierter Services und Erweiterungen, aufbauend auf Core Data Services, Verhaltensdefinitionen und Geschäftsobjekten. Wer heute Ersatz für alte Dialogprogramme plant, plant ihn sinnvollerweise in dieser Richtung.

Die vier Stufen als gemeinsame Sprache

SAP hat das ursprüngliche Drei-Ebenen-Modell zum Clean-Core-Level-Konzept weiterentwickelt und unterscheidet seit August 2025 vier Stufen. Level A nutzt ausschließlich öffentlich freigegebene, stabile SAP-Schnittstellen mit Stabilitätszusage. Level B nutzt zusätzlich klassische SAP-Schnittstellen. Level C greift auf SAP-interne Objekte zu und gilt als nur teilweise konform. Level D umfasst nicht empfohlene Techniken wie Modifikationen, schreibende Zugriffe auf SAP-Tabellen oder implizite Erweiterungen.

Diese Einstufung leistet im Projekt mehr, als ihr Name vermuten lässt. Sie gibt Entwicklung, Betrieb und Fachbereich eine gemeinsame Sprache für eine Frage, die sonst in Meinungen endet, nämlich wie teuer ein Objekt in Zukunft ist. Eine Liste, in der neben jedem Objekt ein Buchstabe steht, macht die Diskussion über Prioritäten deutlich kürzer.

Wenn ihr auf ältere Beschreibungen im Netz stoßt, die von drei Ebenen sprechen, ist das kein Widerspruch, sondern ein früherer Stand. Für Unterlagen, die ihr jetzt erstellt, lohnt es sich, die vier Stufen zu verwenden, damit sie in ein paar Jahren nicht als überholt gelesen werden.

Die zwei Änderungen, die euren Bestand am häufigsten treffen

Im Rechnungswesen ist es das Universal Journal. Die Tabelle ACDOCA ist der gemeinsame Belegspeicher, interne und externe Sicht lesen aus derselben Quelle, und die früheren Summensätze in Hauptbuch, Controlling, Material Ledger, Anlagenbuchhaltung sowie Kreditoren- und Debitorenbuchhaltung sind entfallen, ebenso die Indextabellen, die bestimmte Selektionen beschleunigt haben. Jeder eigene Report, der auf diese Tabellen zugreift, steht damit auf eurer Liste, und in vielen Häusern ist das die größte einzelne Gruppe.

Im Stammdatenbereich ist es der Geschäftspartner. Er ist in SAP S/4HANA das führende und obligatorische Objekt für Kunden- und Lieferantenstammdaten, die Pflege läuft über die Transaktion BP, und die gewohnten Einstiege werden dorthin umgeleitet. Eigene Programme, die Kunden- oder Lieferantensätze lesen, schreiben oder anlegen, brauchen deshalb eine Prüfung, auch wenn sie im Betrieb unauffällig sind.

Beide Gruppen haben eine angenehme Eigenschaft: Sie lassen sich maschinell finden. Eine Suche über die betroffenen Objekte liefert die Liste, und diese Liste ist belastbarer als jede Schätzung. Für die Projektplanung heißt das, dass genau dieser Teil des Aufwands früh und ziemlich genau bezifferbar ist, während der Rest an eurer Entscheidung über Abschalten und Ersetzen hängt.

Warum die Bewertung auch ohne Umstieg lohnt

Ein aufgeräumter Codebestand zahlt sich unabhängig vom Projekt aus. Jede Aktualisierung wird günstiger, jede Fehlersuche kürzer, und die Einarbeitung neuer Kollegen hört auf, ein Rundgang durch die Geschichte des Hauses zu sein. Wer die Inventur einmal gemacht hat, sollte sie deshalb nicht als Projektartefakt behandeln, sondern jährlich fortschreiben.

Der zweite Ertrag ist eine bessere Verhandlungsposition. Ob gegenüber einem Dienstleister, der ein Angebot für die Anpassung macht, oder intern gegenüber einem Fachbereich, der eine Sonderlösung wünscht: Eine Liste mit Nutzungszahlen und Einstufungen ersetzt Meinungen durch Zahlen, und das verändert den Ton in beiden Gesprächen.

Der dritte Ertrag ist strategisch. Wenn ihr euch die Option offenhalten wollt, später auf eine stärker standardisierte Variante zu wechseln, ist der Abbau von Level C und D genau die Vorarbeit dafür. Ihr müsst diese Entscheidung heute nicht treffen, aber ihr könnt euch die Tür offenhalten, und das kostet in dieser Reihenfolge deutlich weniger, als sie später wieder aufzustemmen.

Die Streitfälle, die in jeder Bewertung auftauchen

Vier Fälle sorgen regelmäßig für längere Diskussionen. Der erste ist das Objekt, das selten läuft, aber wichtig ist, etwa eine Auswertung für den Jahresabschluss oder eine Meldung an eine Behörde. Nutzungszahlen allein bewerten es falsch, deshalb braucht die Liste neben der Häufigkeit eine Spalte für die Bedeutung, die der Fachbereich ausfüllt.

Der zweite ist das Objekt, das ein Dienstleister einmal geliefert hat und das seitdem niemand angefasst hat. Hier fehlt oft nicht nur die fachliche Verantwortung, sondern auch das Wissen über den Aufbau. Solche Objekte gehören zuerst geprüft, denn sie sind entweder verzichtbar oder sie sind ein Risiko, und beides sollte man wissen, bevor der Umstieg beginnt.

Der dritte ist der Report, der nur die Datenbasis für eine Tabellenkalkulation liefert, in der die eigentliche Arbeit stattfindet. Solche Ketten sind verbreitet und in der Bewertung heikel, weil das Objekt technisch klein und fachlich wichtig ist. Der vierte Fall ist das Formular, das nach außen geht, etwa an Kunden oder Behörden: Es ist selten aufwendig, aber jede Änderung daran ist sichtbar, und deshalb gehört es früh in die Planung statt in die Restliste.

Dazu passende Kurse

Damit die Einstufung eures Bestands im Haus entsteht und nicht als fremde Schätzung eingekauft wird, sind ABAP-Kurse für den eigenen Codebestand der direkte Weg.

Wer die fachliche Seite dazu braucht, findet bei cmt SAP-Kurse rund um Umstieg und Betrieb .

Wissen prüfen

Wie sicher bist du beim Thema wirklich?

Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.

Häufige Fragen

Wie viele unserer Eigenentwicklungen werden wir am Ende los?
Das lässt sich nicht vorhersagen, aber die Erfahrung im Vorgehen ist eindeutig: Der Anteil der Objekte, die im letzten Geschäftsjahr überhaupt nicht aufgerufen wurden, ist in gewachsenen Systemen erheblich. Entscheidend ist, dass ihr über zwölf Monate messt und dass ihr um begründeten Widerspruch bittet, statt nach Zustimmung zum Weiterbetrieb zu fragen.
Müssen wir alles in ABAP Cloud neu bauen?
Nein. In On-Premise und in der Private-Variante bleibt klassische ABAP-Entwicklung möglich. Sinnvoll ist die Regel für alles, was ohnehin angefasst wird: Was ihr neu baut oder grundlegend überarbeitet, baut ihr upgradestabil, also On-Stack mit ABAP Cloud oder Side-by-Side auf der SAP BTP. Für den Bestand entscheidet ihr nach Nutzung und Einstufung, nicht nach Prinzip.
Ist in ABAP Cloud alles verboten, was nicht von SAP kommt?
Nein, das ist ein verbreitetes Missverständnis. Eingeschränkt ist der Zugriff auf SAP-Objekte: Nutzbar ist, was als freigegebene Schnittstelle mit einem Release-Kontrakt klassifiziert ist, in der Regel C1. Eure eigenen Objekte im selben Softwarepaket bleiben zugänglich. Der Begriff lautet übrigens freigegeben und nicht öffentlich, das ist in Diskussionen ein sinnvoller Unterschied.
Woran erkennen wir, welche Programme das Zielrelease anfasst?
Über zwei Wege. Erstens die Simplification List, in der SAP die funktionalen Änderungen je Release führt, für SAP S/4HANA 2025 samt Feature Pack Stack 1 in der Fassung vom Februar 2026. Zweitens die maschinelle Suche nach Zugriffen auf die Bereiche, die sich geändert haben, insbesondere die entfallenen Summen- und Indextabellen im Rechnungswesen und die Kunden- und Lieferantenstammdaten.
Wer entscheidet am Ende über das Abschalten?
Der Fachbereich, der die Funktion verantwortet, und zwar mit Namen und Datum. Die IT liefert die Zahlen und den technischen Rahmen, sie sollte diese Entscheidung aber nicht allein tragen. Was hilft, ist eine Zusage zur Wiederherstellbarkeit für einen festgelegten Zeitraum, denn sie senkt die gefühlte Schwelle deutlich.
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem SAP-Programm den passenden Kurs für deinen Stand zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.

Den eigenen Code lesen können, bevor jemand ihn bewertet

In den ABAP-Kursen bei cmt geht es um genau die Fragen, die in der Bewertung auflaufen: Wie ist ein Programm aufgebaut, wo greift es zu, und was macht eine Erweiterung upgradestabil. Die Kurse laufen in Präsenz und Live-Online.