Public oder Private Edition von SAP S/4HANA: wie viel Standard ihr vertragt
Zwei Produktlinien, zwei Releaseschemata und zwei Antworten auf die Frage, wer über euer System bestimmt. Die Wahl fällt an euren Prozessen, nicht am Angebot.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Erst die Namen, dann die Verwirrung
Wer sich heute in dieses Thema einliest, stolpert zuerst über die Bezeichnungen. SAP hat die Namen vereinfacht: Auf den Produktseiten heißt die Private-Variante inzwischen SAP Cloud ERP Private, und die Public-Variante läuft unter der Dachmarke SAP Cloud ERP. Die Produktnamen SAP S/4HANA Cloud Private Edition und SAP S/4HANA Cloud Public Edition bestehen daneben weiter und werden in der Produktdokumentation nach wie vor verwendet. In Angeboten treffen deshalb beide Bezeichnungen aufeinander, ohne dass ein Produktwechsel dahintersteckt.
Die zweite Stolperstelle sind die Releasenummern. Für On-Premise und die Private-Variante ist das aktuelle Hauptrelease SAP S/4HANA 2025 beziehungsweise SAP S/4HANA Cloud Private Edition 2025, der derzeit dokumentierte Stand ist der Feature Pack Stack 1 vom Februar 2026. Die Public-Variante zählt dagegen nach einem Schema aus Jahr und Monat, dort führt SAP aktuell das Release 2608. Wer 2608 und 2025 nebeneinander sieht und daraus auf ältere und neuere Stände schließt, vergleicht zwei verschiedene Produktlinien.
Die dritte und teuerste Verwechslung betrifft den Inhalt. Beide Varianten werden gern als dasselbe Produkt mit unterschiedlichem Betriebsmodell dargestellt. Das trifft die Sache nicht, denn sie unterscheiden sich in dem, was euer Haus mit dem System tun darf: wie ihr erweitert, wer den Aktualisierungstermin setzt und wie viel eures heutigen Customizings überhaupt Platz findet. Genau diese drei Punkte gehören in die Entscheidung, und nicht die Frage, wo der Rechner steht.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Unterschiede, die im Alltag ankommen
Die Gegenüberstellung ist aus den belegten Einzelpunkten aufgebaut, also aus dem, was SAP zu Erweiterbarkeit, Releasepflege und Oberfläche dokumentiert. Eine offizielle Vergleichstabelle, die alle drei Themen nebeneinanderstellt, gibt es in dieser Form nicht, und wer eine solche Tabelle zitiert, sollte gefragt werden, woher sie stammt.
Public-Variante
SAP Cloud ERP, in der Produktdokumentation weiterhin SAP S/4HANA Cloud Public Edition, Releasezählung nach Jahr und Monat, aktuell 2608
Private-Variante
SAP Cloud ERP Private, in der Produktdokumentation weiterhin SAP S/4HANA Cloud Private Edition, Hauptrelease 2025 mit Feature Pack Stack 1 vom Februar 2026
| Entscheidungsfrage | Public-Variante | Private-Variante |
|---|---|---|
| Wie erweitert ihr das System? | Kommt darauf an Über Werkzeuge für Key User, über ABAP Cloud im System selbst und über entkoppelte Anwendungen auf der SAP Business Technology Platform. Das ergibt upgradestabile Erweiterungen, verlangt aber, dass ihr euch auf freigegebene Schnittstellen beschränkt. | Stärke Dieselben Wege stehen offen, daneben bleibt klassische ABAP-Entwicklung möglich. Das ist die Flexibilität, für die dieses Modell gewählt wird, und zugleich der Punkt, an dem sich technische Schulden am leichtesten wieder ansammeln. |
| Wer bestimmt, wann aktualisiert wird? | Kommt darauf an Den Takt gibt SAP vor, die Releasenamen folgen dem Schema aus Jahr und Monat. Für euch heißt das: regelmäßige, kleinere Anpassungen statt großer Projekte, aber wenig Spielraum bei den Terminen. | Stärke Ihr bestimmt den Zeitpunkt innerhalb der Wartungsfristen mit. Ab dem Release SAP S/4HANA 2023 erscheinen die Hauptreleases im Zweijahresrhythmus und bleiben sieben Jahre in der Mainstream Maintenance, in den ersten beiden Jahren sind Feature Packs im Halbjahrestakt geplant. |
| Wie arbeiten die Anwender? | Kommt darauf an Über die Fiori-Oberfläche im Browser. Für Häuser mit eingeübten Tastaturwegen im SAP GUI ist das der sichtbarste Bruch und der Punkt, an dem Schulung tatsächlich Geld spart. | Stärke Fiori ist auch hier die vorgesehene Oberfläche, klassische Transaktionen und das SAP GUI bleiben daneben verfügbar. Der Übergang lässt sich damit in Etappen planen, statt ihn an einem Wochenende zu erzwingen. |
| Wie viel eures heutigen Customizings kommt mit? | Schwäche Ihr startet auf vorkonfigurierten Abläufen und weicht nur dort ab, wo der Standard es vorsieht. Für Häuser mit vielen gewachsenen Sonderwegen ist das der eigentliche Aufwand des Projekts, und er fällt im Fachbereich an. | Stärke Euer Customizing lässt sich weitgehend abbilden, bei einer Konversion kommt es sogar mit. Das ist bequem und genau deshalb gefährlich: Ohne bewusste Entscheidung nehmt ihr auch die Sonderwege mit, die niemand mehr begründen kann. |
| Wie schnell seid ihr produktiv? | Stärke SAP wirbt für den Einstieg über SAP GROW mit vorkonfigurierten, branchenspezifischen Abläufen und einem Start in wenigen Wochen. Das trägt, solange ihr wirklich im Standard bleibt, und es kippt, sobald der Fachbereich Ausnahmen durchsetzt. | Kommt darauf an Der Weg führt über eine Konversion oder einen begleiteten Neuaufbau und dauert entsprechend länger. Dafür ist das Ergebnis näher an dem, was eure Fachbereiche heute gewohnt sind. |
| Wie viel Aufwand macht die Pflege danach? | Stärke Weil Erweiterungen nur auf freigegebenen Wegen entstehen, überstehen sie Aktualisierungen weitgehend unbeschadet. Der Aufwand verlagert sich vom Programmieren zum regelmäßigen Prüfen und Nachziehen von Abläufen. | Kommt darauf an Das hängt allein an eurer Disziplin, und darauf lässt sich schlecht bauen. Wer konsequent auf ABAP Cloud und entkoppelte Anwendungen setzt, hat einen ähnlich ruhigen Betrieb. Wer klassisch weiterbaut, zahlt bei jedem Releasewechsel dafür. |
Wie erweitert ihr das System?
Über Werkzeuge für Key User, über ABAP Cloud im System selbst und über entkoppelte Anwendungen auf der SAP Business Technology Platform. Das ergibt upgradestabile Erweiterungen, verlangt aber, dass ihr euch auf freigegebene Schnittstellen beschränkt.
Dieselben Wege stehen offen, daneben bleibt klassische ABAP-Entwicklung möglich. Das ist die Flexibilität, für die dieses Modell gewählt wird, und zugleich der Punkt, an dem sich technische Schulden am leichtesten wieder ansammeln.
Wer bestimmt, wann aktualisiert wird?
Den Takt gibt SAP vor, die Releasenamen folgen dem Schema aus Jahr und Monat. Für euch heißt das: regelmäßige, kleinere Anpassungen statt großer Projekte, aber wenig Spielraum bei den Terminen.
Ihr bestimmt den Zeitpunkt innerhalb der Wartungsfristen mit. Ab dem Release SAP S/4HANA 2023 erscheinen die Hauptreleases im Zweijahresrhythmus und bleiben sieben Jahre in der Mainstream Maintenance, in den ersten beiden Jahren sind Feature Packs im Halbjahrestakt geplant.
Wie arbeiten die Anwender?
Über die Fiori-Oberfläche im Browser. Für Häuser mit eingeübten Tastaturwegen im SAP GUI ist das der sichtbarste Bruch und der Punkt, an dem Schulung tatsächlich Geld spart.
Fiori ist auch hier die vorgesehene Oberfläche, klassische Transaktionen und das SAP GUI bleiben daneben verfügbar. Der Übergang lässt sich damit in Etappen planen, statt ihn an einem Wochenende zu erzwingen.
Wie viel eures heutigen Customizings kommt mit?
Ihr startet auf vorkonfigurierten Abläufen und weicht nur dort ab, wo der Standard es vorsieht. Für Häuser mit vielen gewachsenen Sonderwegen ist das der eigentliche Aufwand des Projekts, und er fällt im Fachbereich an.
Euer Customizing lässt sich weitgehend abbilden, bei einer Konversion kommt es sogar mit. Das ist bequem und genau deshalb gefährlich: Ohne bewusste Entscheidung nehmt ihr auch die Sonderwege mit, die niemand mehr begründen kann.
Wie schnell seid ihr produktiv?
SAP wirbt für den Einstieg über SAP GROW mit vorkonfigurierten, branchenspezifischen Abläufen und einem Start in wenigen Wochen. Das trägt, solange ihr wirklich im Standard bleibt, und es kippt, sobald der Fachbereich Ausnahmen durchsetzt.
Der Weg führt über eine Konversion oder einen begleiteten Neuaufbau und dauert entsprechend länger. Dafür ist das Ergebnis näher an dem, was eure Fachbereiche heute gewohnt sind.
Wie viel Aufwand macht die Pflege danach?
Weil Erweiterungen nur auf freigegebenen Wegen entstehen, überstehen sie Aktualisierungen weitgehend unbeschadet. Der Aufwand verlagert sich vom Programmieren zum regelmäßigen Prüfen und Nachziehen von Abläufen.
Das hängt allein an eurer Disziplin, und darauf lässt sich schlecht bauen. Wer konsequent auf ABAP Cloud und entkoppelte Anwendungen setzt, hat einen ähnlich ruhigen Betrieb. Wer klassisch weiterbaut, zahlt bei jedem Releasewechsel dafür.
Was passt wann
- Wenn eure Prozesse im Kern branchenüblich sind und ihr wenige Abweichungen wirklich begründen könnt
- prüft die Public-Variante ernsthaft und plant den Aufwand im Fachbereich ein, nicht in der IT.
- Wenn euer Geschäft an Abläufen hängt, die es so im Standard nicht gibt, und ihr aktiven Eigenbau habt
- nehmt die Private-Variante und legt gleich fest, dass neue Erweiterungen nur noch upgradestabil gebaut werden.
- Wenn ihr euch nicht einig werdet, weil IT und Fachbereich unterschiedliche Bilder vom eigenen Standardgrad haben
- zählt zuerst die Abweichungen, denn die Diskussion ist danach meistens entschieden.
Fünf Prüfungen, und die Variante steht
- 01 Wie viele Abweichungen vom Standard könnt ihr heute noch geschäftlich begründen?
- 02 Greift euer Eigenbau nur auf freigegebene Schnittstellen zu oder tief in SAP-Objekte hinein?
- 03 Gibt es Zeiträume, in denen bei euch niemand am System arbeiten darf?
- 04 Arbeiten eure Anwender bereits über den Browser oder hängen Abläufe fest am SAP GUI?
- 05 Führt euer Weg über die Konversion des Bestands oder über einen Neuaufbau auf dem Standard?
Woran ihr die Antwort für euer Haus festmacht
Die Wahl wird schnell klar, wenn ihr sie an eurem eigenen System messt statt an einer Vergleichstabelle. Sechs Prüfungen reichen aus, und alle sechs beantwortet ihr mit Unterlagen, die ihr habt.
Die Abweichungen vom Standard zählen und begründen lassen
Geht eure Sonderwege durch und markiert die, für die heute noch jemand ein geschäftliches Argument nennen kann. Bleibt eine kurze Liste übrig, ist die Public-Variante eine ernsthafte Option. Bleibt eine lange Liste mit guten Gründen, spricht das für die Private-Variante, weil ihr dort mehr davon abbilden könnt.
Den eigenen Codebestand nach Bauart sortieren
Trennt Erweiterungen, die nur auf freigegebene Schnittstellen zugreifen, von solchen, die tief in SAP-Objekte hineingreifen oder sie verändern. Die erste Gruppe passt in beide Varianten. Die zweite Gruppe ist der eigentliche Grund, warum Häuser die Private-Variante wählen, und sie ist zugleich die Gruppe, die bei jedem Releasewechsel Arbeit macht.
Klären, wer bei euch den Aktualisierungstermin setzen darf
In der Public-Variante gibt SAP den Takt vor, in der Private-Variante bestimmt ihr den Zeitpunkt innerhalb der Wartungsfristen des Release mit. Wenn es in eurem Haus Zeiträume gibt, in denen niemand am System arbeiten darf, prüft früh, wie sich das mit dem jeweiligen Modell verträgt.
Die Oberfläche der Anwender ehrlich einplanen
SAP Fiori ist die vorgesehene Oberfläche für SAP S/4HANA. In der Installationsanleitung zum Release 2025 steht ausdrücklich, dass Fiori installiert und konfiguriert werden muss, um die volle Nutzererfahrung zu bekommen. In On-Premise und Private bleiben klassische Transaktionen und das SAP GUI daneben verfügbar, in der Public-Variante arbeiten Anwender über die Fiori-Oberfläche im Browser.
Den Weg dorthin mitdenken
Eine Konversion überführt euer bestehendes System und zielt auf die On-Premise- und Private-Welt. Wer auf die Public-Variante will, geht den Weg des Neuaufbaus. Diese Kopplung ist der Grund, warum die Variantenfrage vor der Wegefrage steht und nicht umgekehrt.
Die Betriebsverantwortung getrennt betrachten
Wer den Betrieb der technischen Basis abgibt, gibt damit weder die Berechtigungspflege noch die fachliche Konfiguration ab. Diese Frage entscheidet ihr unabhängig von der Variante, und sie gehört in eine eigene Runde, damit sie die Diskussion über Erweiterbarkeit nicht überlagert.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Erweiterbarkeit ist der eigentliche Unterschied
SAP unterscheidet zwei Wege für Erweiterungen. Side-by-Side bedeutet, dass entkoppelte Anwendungen auf der SAP Business Technology Platform laufen und unabhängig vom Kern bleiben. On-Stack bedeutet, dass eng integrierte, upgradestabile Erweiterungen im ERP-System selbst entstehen, und zwar mit ABAP Cloud. Diese Unterscheidung gilt für beide Varianten, sie beschreibt also nicht den Unterschied, sondern den gemeinsamen Rahmen.
ABAP Cloud ist das Entwicklungsmodell für clean-core-konforme, cloudfähige Anwendungen, Services und Erweiterungen auf der SAP BTP, in SAP S/4HANA Cloud und in SAP S/4HANA. Technisch wirkt es über eingeschränkte Sprachversionen: ABAP for Cloud Development deckt nur eine Teilmenge des Sprachumfangs ab, und der Zugriff auf Objekte ist eingeschränkt. Nutzbar ist ein Objekt, wenn es als freigegebene Schnittstelle mit einem Release-Kontrakt klassifiziert ist, in der Regel dem Kontrakt C1. Objekte im eigenen Softwarepaket bleiben daneben zugänglich, es ist also nicht alles verboten, was nicht von SAP stammt.
Der Unterschied zwischen den Varianten liegt darin, was daneben noch erlaubt ist. In der Private-Variante bleibt klassische ABAP-Entwicklung möglich, mit allen Freiheiten und allen Folgekosten. Wer diese Freiheit nutzt, sollte sie bewusst nutzen und nicht aus Gewohnheit, denn jede Erweiterung an einem SAP-Objekt ist eine Position auf der Liste, die beim nächsten Releasewechsel abgearbeitet wird.
Clean Core ist kein Slogan, sondern eine Einstufung
Der Clean-Core-Gedanke zielt darauf, den Kern standardnah und upgradestabil zu halten und Unterschiede dort zu bauen, wo sie das Geschäft wirklich unterscheiden. SAP nennt als Zweck, Innovationszyklen zu beschleunigen, technische Schulden zu begrenzen sowie Wartung und Upgrades zu vereinfachen. Das klingt nach Marketing, ist inzwischen aber als Einstufung ausformuliert.
Seit August 2025 gilt statt des früheren Drei-Ebenen-Modells ein Konzept mit 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, darunter Modifikationen, schreibende Zugriffe auf SAP-Tabellen und implizite Erweiterungen.
Für die Entscheidung zwischen den Varianten ist diese Einstufung ein nützliches Werkzeug, weil sie euren Bestand messbar macht. Sortiert eure Erweiterungen nach diesen vier Stufen. Was auf A und B liegt, passt in beide Varianten. Was auf C und D liegt, ist der Grund, warum die Private-Variante in eurem Haus zur Diskussion steht, und zugleich die Liste, die ihr über die nächsten Jahre abbauen wollt. Ältere Texte im Netz beschreiben noch das Drei-Ebenen-Modell, das ist nicht mehr der aktuelle Stand.
Was Anwender merken und was der Betrieb merkt
Für Anwender ist die Oberfläche der sichtbarste Unterschied. SAP Fiori ist die vorgesehene Oberfläche für SAP S/4HANA, und in der Installationsanleitung zum Release 2025 steht ausdrücklich, dass Fiori installiert und konfiguriert werden muss, um die volle Nutzererfahrung zu erhalten. In On-Premise und in der Private-Variante bleiben klassische Transaktionen und das SAP GUI daneben verfügbar, in der Public-Variante arbeiten Anwender über die Fiori-Oberfläche im Browser.
Dass das SAP GUI dabei abgekündigt sei, gehört ins Reich der Projektlegenden. SAP hat am 16. Juli 2026 die offizielle Unterstützung für SAP GUI for Windows 8.10 gestartet und den Support bis zum 30. Juni 2029 zugesagt. Für die Planung heißt das: Der Übergang zu Fiori ist eine Frage der Arbeitsweise und der Schulung, nicht ein Termin, der euch aufgezwungen wird. Wer beides trennt, kommt zu ruhigeren Entscheidungen.
Der Betrieb merkt den Unterschied vor allem am Takt. Ein Modell mit vorgegebenem Rhythmus zwingt zu regelmäßiger Prüfung eurer Erweiterungen und Abläufe, dafür entfallen die großen Sprünge. Ein Modell mit eigener Terminhoheit erlaubt Rücksicht auf Jahresabschluss und Hochsaison, verlangt dafür aber, dass jemand die Aktualisierung überhaupt auf die Tagesordnung setzt. Beides ist tragbar, nur sollte die Entscheidung dazu passen, wie euer Haus mit Terminen umgeht.
Die Reihenfolge, in der ihr entscheidet
Die Variantenfrage steht vor der Wegefrage. Erst wenn das Zielbild feststeht, ist entschieden, ob eine Konversion des Bestands überhaupt in Frage kommt oder ob ihr neu aufbaut. Und sie steht vor der Betriebsfrage, denn wer den Betrieb der technischen Basis abgibt, hat damit noch nicht entschieden, wie viel Standard er verträgt.
Als Reihenfolge hat sich bewährt: Zuerst die Abweichungen vom Standard zählen und begründen lassen. Dann den Eigenbau nach Clean-Core-Stufen sortieren. Dann die Variante festlegen. Dann den Weg dorthin wählen. Und erst danach über Betriebsmodell und Vertragsform sprechen. Jede andere Reihenfolge erzeugt Runden, in denen eine frühere Entscheidung wieder aufgemacht wird.
Was diese Reihenfolge zusätzlich leistet: Sie holt den Fachbereich früh an den Tisch. Die Frage, wie viel Standard euer Haus verträgt, ist keine IT-Frage, sie wird nur meistens dort gestellt. Wer sie zuerst im Fachbereich stellt und die Antworten schriftlich festhält, hat für alle folgenden Entscheidungen eine belastbare Grundlage.
Dazu passende Kurse
Damit die Diskussion über Standard und Sonderweg nicht an Vermutungen hängt, helfen SAP-Kurse zu den S/4HANA-Cloudvarianten , in denen die Abläufe im Standard einmal vollständig durchlaufen werden.
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.
Wo du genau das übst
Häufige Fragen
Heißt SAP S/4HANA jetzt anders?
Ist 2608 neuer als 2025?
Können wir in der Public-Variante gar nicht mehr in ABAP entwickeln?
Verlieren unsere Anwender das SAP GUI?
Können wir später von der Private- in die Public-Variante wechseln?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem SAP-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Den eigenen Standardgrad an echten Prozessen messen
In den S/4HANA-Kursen bei cmt laufen die integrierten Geschäftsprozesse im Standard durch. Danach könnt ihr benennen, welche eurer Abweichungen wirklich nötig sind, und genau das ist die Grundlage für diese Entscheidung.