SAP Clean Core mit Open Source: Kernseife

SAP Abap Test Cockpit (ATC)

Während SAP unablässig predigt, dass der digitale Kern eines S/4 Hana unberührt bleiben muss, stehen Bestandskunden vor Bergen historisch gewachsenen Custom Codes (Z-Entwicklungen), die sich nicht einfach per Mausklick auflösen lassen. Das standardmäßige Prüfwerkzeug ATC (Abap Test Cockpit) erweist sich in der Praxis oft als unbarmherziger und starrer Richter. Es überflutet Entwickler mit einer Lawine von Warnungen, sobald diese auf SAP-interne Objekte zugreifen, für die SAP selbst keine Stabilitätsgarantie abgibt – selbst wenn diese Zugriffe seit Jahrzehnten stabil laufen und für die Geschäftsprozesse des Kunden absolut unkritisch sind.

In dieser architektonischen Zwickmühle hat SAP ein Werkzeug veröffentlicht, dessen Name an Realsatire grenzt: Projekt Kernseife. Aus einer kritischen Perspektive ist dieses Tool das offizielle Eingeständnis der SAP, dass ihre eigenen Standard-Messmethoden für den Clean Core zu grob, zu bürokratisch und für reale Kundenprojekte schlicht unpraktikabel sind. SAP hat hier im wahrsten Sinne des Wortes „Seife für den schmutzigen Kern“ entwickelt, um das gewaltige Problem der technischen Altschulden überhaupt erst messbar und handhabbar zu machen.

Open Source: Kernseife auf GitHub

Technisch betrachtet handelt es sich bei Projekt Kernseife um ein im Mai 2025 veröffentlichtes Open-Source-Werkzeug, das SAP-Bestandskunden kostenlos über die Entwicklungsplattform GitHub (unter github.com/SAP/project-kernseife) zur Verfügung gestellt wird.

Das Ziel dieses Projekts ist es, das Messen und Steuern der Clean-Core-Richtlinien zu verbessern und für Entwicklerteams erträglich zu machen: insbesondere in der Dimension Extensibility (Erweiterbarkeit) innerhalb von S/4 Private Cloud- und On-prem-Systemen.

Das Werkzeug schließt eine funktionale Lücke im standardmäßigen Abap Test Cockpit, indem es das starre SAP-Prüfdiktat um ein benutzerdefiniertes Klassifizierungssystem (Custom Classification) erweitert. Projekt Kernseife besteht im Wesentlichen aus zwei Komponenten: Einem angepassten ATC-Prüflauf, der auf den offiziellen SAP-Clean-Core-Prüfungen aufsetzt; und einer flexiblen Bewertungsmatrix, die es den Entwicklern erlaubt, eigene Einstufungen für Abap-Objekte zu hinterlegen.

Abap- und Clean-Core-Autonomie

Der entscheidende Vorteil für den SAP-Bestandskunden liegt darin, dass er die Lufthoheit über die Bewertung seines Codes zurückgewinnt: Wenn ATC einen Zugriff auf ein internes SAP-Objekt standardmäßig als gefährlichen Verstoß markiert (was zu einer Flut von Warnungen führt), SAP aber selbst keine granulare Information zu diesem Objekt bereitstellt, kann das Unternehmen über Projekt Kernseife definieren: In unserem spezifischen geschäftlichen Kontext ist dieser Zugriff stabil und zulässig. Das Tool überschreibt in diesem Fall die pauschale Warnung der SAP und verhindert so, dass Entwickler in einer unendlichen Flut von Fehlalarmen (False Positives) ertrinken.

Governance und Clean-Core-Orchestrierung mit Kernseife

Kernseife repariert keinen Code, sie macht den Schmutz nur verwaltbar: Ein fataler Trugschluss wäre es zu glauben, dass der Einsatz von Projekt Kernseife das System automatisch reinigt. Das Tool ist ein reines Mess- und Governance-Instrument. Es zeigt den ECC-Anwendern lediglich präziser an, wie schmutzig der Kern tatsächlich ist und wo die echten, blockierenden Risiken (Level-D-Modifikationen) liegen, während unbedenkliche Altschulden sauber ausgeblendet werden. Die teure Arbeit der Code-Bereinigung und des Refactorings müssen die Abap-Entwicklerteams nach wie vor manuell oder über agentische KI-Plattformen von Drittanbietern wie Nova Intelligence oder West Trax leisten.

Die Implementierung von Projekt Kernseife setzt ein funktionierendes Customer Center of Expertise (CCoE) oder eine starke interne Governance-Struktur voraus. Da das Tool auf kundenindividuellen Klassifizierungen basiert, muss zwingend definiert werden, wer im Unternehmen das Recht hat, eine SAP-Warnung dauerhaft zu tolerieren. Ohne einen klaren Freigabeprozess und qualifizierte Tool-Verantwortliche droht Projekt Kernseife zu einer Ausrede zu verkommen, mit der sich Entwickler den schmerzhaften, aber notwendigen Clean-Core-Vorgaben entziehen, indem sie kritische Befunde einfach per Custom-Eintrag stummschalten.

Reise in die SAP-Cloud

Das Versprechen von der unbeschwerten Reise in die SAP-Cloud hat sich in den Chefetagen deutscher Unternehmen zu einem der kostspieligsten Mythen der modernen ERP-Geschichte entwickelt. Unter dem werbewirksamen Label Rise with SAP preist der Softwarekonzern seine S/4 Cloud Private Edition als den risikofreien Zwischenschritt für all jene Bestandskunden an, die den technischen Tiefgang einer On-prem-Lösung mit den vermeintlichen Vorzügen des Cloud Computings verbinden wollen.

Doch es gibt ein akribisch konstruiertes Geflecht aus kommerziellen Stolperfallen und kaufmännischen Daumenschrauben, das die verlockende Wolke sehr schnell in eine existenzbedrohende Kostenfalle verwandelt. Aus Sicht der SAP-Community ist es unerlässlich, die Mechanismen dieser Private-Cloud-Falle zu dekonstruieren, damit S/4-Bestandskunden nicht sehenden Auges in die finanzielle Abhängigkeit schlittern.

Die architektonische Sollbruchstelle dieser Transformation beginnt bereits an der kaufmännischen Basis: dem Übergang von einer einmaligen Investitionsausgabe (CapEx) hin zu dauerhaft wiederkehrenden Betriebskosten (OpEx). In der traditionellen On-prem-Welt erwarb der Bestandskunde unbefristetes Eigentum an seinen Softwarelizenzen. Selbst wenn ein Unternehmen sich entschied, den teuren Wartungsvertrag mit der SAP aufzukündigen, blieb das rechtmäßige Nutzungsrecht am ERP-Kern auf ewig im Firmensafe gesichert.

Rise with SAP

Mit dem Einstieg in das Rise-Programm und der damit verbundenen vertraglichen Contract Conversion gibt der Kunde dieses wertvolle Eigentum jedoch unwiederbringlich an der Himmelspforte ab. Er mutiert vom stolzen Eigentümer zum wehrlosen Mieter, dessen Nutzungsrechte mit dem Ende der Vertragslaufzeit schlagartig erlöschen. Sollte das Unternehmen die rasant steigenden Cloud-Subskriptionsgebühren eines Tages nicht mehr zahlen können oder wollen, droht der absolute Kontrollverlust: Nach Vertragsende bleiben dem Kunden lediglich die nackten, unstrukturierten Rohdaten auf der Festplatte. Ohne die dazugehörigen, in der Cloud verbliebenen SAP-Algorithmen sind diese Daten für betriebswirtschaftliche Abfragen und den täglichen Betrieb vollkommen wertlos. Ein Cloud-Exit ist von der SAP schlicht nicht vorgesehen.

Gesteuert wird dieses neue Mietverhältnis über die intransparente Metrik der Full Use Equivalents (FUE). SAP inszeniert dieses Modell gerne als flexiblen Befreiungsschlag, der es Unternehmen erlaubt, Lizenzen innerhalb eines vordefinierten Werte-Pools dynamisch zwischen verschiedenen Nutzertypen wie Core- oder Advanced-Usern hin- und herzuschieben. Die verheerende Kostenfalle verbirgt sich jedoch in der neuen Vermessungsmethode!

Cloud-Metrik, STAR und TCO

Während in der klassischen ECC-Welt die Lizenzierung auf der tatsächlichen, messbaren Nutzung der Software basierte, vermisst SAP in der S/4-Cloud-Welt ausschließlich nach den im System vergebenen Berechtigungen. Da in organisch gewachsenen IT-Landschaften Berechtigungen über Jahrzehnte hinweg großzügig und unkontrolliert vergeben wurden, führt dieser berechtigungsbasierte Scan bei einer unvorbereiteten Migration zu einer massiven Überlizenzierung. Unabhängige Experten warnen eindringlich davor, dass diese neue Cloud-Metrik die Lizenzkosten um alarmierende 50 bis 150 Prozent in die Höhe treiben kann, da selbst für reine Gelegenheitsnutzer teure Professional- oder Advanced-Lizenzen fällig werden, nur weil ihnen systemseitig weitreichende Rollen zugeordnet sind.

Der von SAP angebotene STAR-Service (S/4 Trusted Authorization Review) entpuppt sich dabei keineswegs als neutrales Optimierungswerkzeug, sondern als ein automatisches Klassifizierungswerkzeug, das unklassifizierte Nutzer direkt dem teuersten Lizenztyp zuordnet und somit als Hebel für teure Nachlizenzierungen dient.

Ein weiterer, kaufmännischer Knebel ist die vertraglich festgeschriebene Preisdynamik. Die von SAP angebotenen TCO-Kalkulatoren suggerieren eine langfristig stabile Kostenstruktur, verschweigen aber im Kleingedruckten die automatische, jährliche Gebührenerhöhung von fixen 3,3 Prozent, die nach dem Prinzip einer Staffelmiete auf dem Bestellformular ausgewiesen wird.

Über einen marktüblichen Fünfjahresvertrag hinweg summiert sich dieser scheinbar kleine Aufschlag zu einer massiven Kostensteigerung von fast 18 Prozent. Doch die finanzielle Eskalation erreicht ihren Höhepunkt, wenn es um geschäftskritische Systemverfügbarkeiten geht.

Service Level Agreement

Reicht dem S/4-Bestandskunden das im SAP-Standard enthaltene Service Level Agreement (SLA) von 99,7 Prozent nicht aus – weil beispielsweise in einer globalen Just-in-time-Produktion jede Minute Systemausfall Millionen kostet – und fordert es eine Erhöhung auf branchenübliche 99,9 Prozent, schlägt die SAP unbarmherzig zu. Für diesen minimalen Uplift um 0,2 Prozent verlangt der Konzern einen astronomischen Aufschlag von 50 Prozent auf die gesamte, wiederkehrende jährliche Netto-Vertragsgebühr aller betroffenen Produkte. Bei einer moderaten Systemlandschaft mit einem jährlichen Rise-Lizenzwert von einer Million Euro bedeutet dies zusätzliche, wiederkehrende Kosten von sage und schreibe einer halben Million Euro pro Jahr – ein Preis-Leistungs-Verhältnis, das in der gesamten IT-Branche seinesgleichen sucht.

Besonders dramatisch wird die Situation, wenn der Rise-bestandskunde die Projektrisiken einer S/4-Migration ins Auge fasst: Hier zwingt SAP ihre Kunden zu einer risikoreichen Doppelzahlung! Der Kunde muss an der Kasse sowohl für die Conversion-Dienstleistung als auch für die laufende Cloud-Subskription bezahlen. Kommt es im Zuge des Projekts zu unvorhergesehenen Komplikationen, einem akuten Fachkräftemangel oder gar zu einem vollständigen Projektstopp, zeigt sich die unbarmherzige Härte des Cloud-Vertrags.

Während SAP bei einem Projektabbruch kulanterweise auf Teile der Conversion-Dienstleistungskosten verzichten mag, bleibt der Kunde vertraglich unerbittlich zur vollen Zahlung der monatlichen Cloud-Subskription für die ungenutzten Systeme verpflichtet. In diesem Szenario steht der Bestandskunde vor den Trümmern seiner IT-Infrastruktur: Ein Weg zurück in die On-prem-Welt ist versperrt, da die Lizenzen bereits konvertiert und vernichtet wurden, und ein Weg nach vorn in die Cloud ist aufgrund des gescheiterten Migrationsprojekts blockiert, während die monatlichen Mietgebühren unaufhaltsam weiterlaufen.

Neue Technik mit alten Problemen

Flankiert wird dieses System durch den kompromisslosen Zwang zur Hana-Datenbank. Kunden, die ihre ERP-Systeme über Jahrzehnte hinweg kostengünstig und stabil auf Datenbanken von Drittanbietern wie Oracle oder DB2 betrieben haben, erleben beim Wechsel in die Private Cloud eine kalte Enteignung: Der Wert der bisherigen Datenbanklizenzen wird von SAP nicht angerechnet und verfällt ersatzlos, während gleichzeitig ein saftiger Aufschlag von meist 15 Prozent für die Hana-Runtime-Datenbank fällig wird.

Wer zudem versucht, seine Datenströme in einer vernetzten Lieferkette flexibel an Drittsysteme oder moderne KI-Plattformen anzubinden, gerät augenblicklich in die nächste Mautstation namens Digital Access. Da diese indirekte Nutzung in der Rise Private Cloud in der Regel nicht enthalten ist, muss jedes über Schnittstellen erstellte Dokument nachlizenziert werden. Wer dem entgehen will, wird auf die Business Technology Platform (SAP BTP) und in die Business Data Cloud (SAP BDC) gezwungen. Dort warten jedoch intransparente, im Voraus zu bezahlende Credits, die am Ende des Vertragsjahres bei Nichtnutzung verfallen, während jede Überschreitung unerbittlich zu teuren Listenpreisen abgerechnet wird.

Aus betriebswirtschaftlicher Sicht wirbt SAP damit, dass das Rise-Paket in der Private Cloud die Gesamtbetriebskosten (TCO) im Vergleich zu einer klassischen Vor-Ort-Installation um bis zu 20 Prozent senken könne. Diese Behauptung hält einer detaillierten Prüfung jedoch selten stand, da sie meist auf unrealistischen Annahmen über ineffiziente eigene Rechenzentrumskosten basiert. In der Realität bedeutet der Wechsel in die Private Cloud eine bilanzielle Transformation, bei der bisheriges Anlagevermögen (CapEx) in dauerhafte, wiederkehrende Betriebsausgaben (OpEx) umgewandelt wird. Dieser Prozess ist für den SAP-Bestandskunden faktisch unumkehrbar. Mit dem Abschluss des Cloud-Vertrags gibt der ERP-Anwender seine wertvollen, zeitlich unbegrenzten On-prem-Nutzungsrechte auf und tauscht sie gegen ein volatiles Mietverhältnis ein, bei dem er nach einer Kündigung im schlimmsten Fall auf nutzlosen Rohdaten ohne die interpretierenden Algorithmen der SAP sitzt. Der Weg in die S/4 Private Cloud Edition erweist sich somit auf fast allen Ebenen als ein betriebswirtschaftliches Minenfeld. Wer den Versprechungen der SAP-Vertriebler ohne fundierte IT-Strategie, ohne spezialisierte Rechtsberatung, ohne unabhängige Lizenzmesswerkzeuge und ohne Kernseife vertraut, gibt nicht nur seine digitale Souveränität auf, sondern riskiert eine unkontrollierbare Explosion der Total Cost of Ownership auf Jahre hinaus.