SAP-Systemlandschaft und Mandantenkonzept

Aufbau einer SAP-Systemlandschaft: die 3-Systemlandschaft

SAP empfiehlt eine 3-Systemlandschaft aus einem Entwicklungssystem (DEV), einem Qualitätssicherungssystem (QAS) und einem Produktivsystem (PRD). Jeder der drei zentralen Mandanten bekommt damit sein eigenes System.

Der Grund liegt in der Technik. Repository-Objekte und mandantenübergreifendes Customizing sind für alle Mandanten eines Systems gleich. Eine Änderung in einem Mandanten wirkt sofort in allen anderen. Nur wenn Entwicklung, Test und Produktion in getrennten Systemen laufen, erreicht eine Änderung die Produktion erst, nachdem sie getestet wurde.

Der Weg ist immer derselbe: Änderungen entstehen im Customizing-Mandanten der Entwicklung, gehen per Transport in den QS-Mandanten und nach erfolgreichem Test in die Produktion. Wenn von „dem SAP-Testsystem“ die Rede ist, ist meist das QS-System gemeint. Dort prüfen Fachbereiche Änderungen, in vielen Landschaften mit Daten aus der Produktion.

Kleinere Installationen kommen manchmal mit zwei Systemen aus. Der QS-Mandant liegt dann im Entwicklungssystem. Der Nachteil: Mandantenübergreifende Änderungen im Customizing-Mandanten wirken auch auf die laufenden Tests. Eine Landschaft aus nur einem System empfiehlt SAP nicht, weil nach dem Produktivstart kaum noch entwickelt werden kann.

Sandbox, Schulung, Pre-Production und Projektlandschaft

Sandbox: SAP beschreibt einen optionalen Sandbox-Mandanten im Entwicklungssystem, in dem Sie Einstellungen ausprobieren, bevor Sie sie im Customizing-Mandanten machen. Für Upgrade-Proben, neue Funktionen oder Migrationstests betreiben viele Unternehmen zusätzlich ein eigenes Sandbox-System. Es braucht keinen Weg in die Produktion.

Schulung: Den Schulungsmandanten ordnet SAP dem QS-System zu. Er braucht einen stabilen, definierten Datenbestand, damit jede Schulung gleich abläuft.

Pre-Production: Manche Landschaften haben zwischen QS und Produktion ein weiteres System, das der Produktion möglichst gleicht. Dort laufen Abnahme-, Performance- und Cutover-Tests.

Projektlandschaft: Große Vorhaben wie ein Release-Wechsel oder ein Rollout bekommen oft eine eigene Landschaft. Die bestehende Kette bleibt für Wartung und Support zuständig, das Projekt entwickelt parallel in eigenen Systemen. Korrekturen aus der Wartung müssen dann auch im Projekt ankommen. SAP Solution Manager unterstützt das als Retrofit und spricht dabei von N+1-Landschaften.

Jedes zusätzliche System bedeutet zusätzliche Transportwege, zusätzliche Refreshs und zusätzlichen Hauptspeicher.

Transportwege mit TMS

Die Transporte zwischen den Systemen steuert das Transport Management System (STMS). Die Systeme einer Landschaft bilden eine Transportdomäne. Eines davon ist der Transport Domain Controller, der die Konfiguration zentral hält. Die Transportwege legen fest, in welchem System Änderungsaufträge konsolidiert werden und welche Systeme sie automatisch weitergeleitet bekommen.

Für die 3-Systemlandschaft bietet STMS eine Standardkonfiguration. Sie verbindet die Entwicklung über einen Konsolidierungsweg mit der QS und die QS über einen Belieferungsweg mit der Produktion. Vorsicht in bestehenden Landschaften: Die Standardkonfiguration ersetzt alle bisherigen Einstellungen für alle Systeme. Kommen Pre-Production oder eine Projektlandschaft dazu, pflegen Sie die zusätzlichen Wege gezielt von Hand.

Das Mandantenkonzept: welche Mandanten wohin

Das Mandantenkonzept legt fest, welche Mandanten es in jedem System gibt, wofür sie da sind und was in ihnen geändert werden darf. SAP beschreibt drei zentrale Mandanten, die es in jeder Landschaft gibt, und drei optionale:

Mandant	System	Zweck und Änderungen
`CUST`	Entwicklung	Customizing-Mandant. Hier entstehen Customizing und Eigenentwicklung, Änderungen werden aufgezeichnet und transportiert. Mandantenübergreifende Änderungen sind nur hier erlaubt.
`TEST`	Entwicklung	Entwicklertestmandant. Entwickler prüfen ihre Änderungen vor der Freigabe. Customizing und Repository sind gesperrt.
`SAND`	Entwicklung	Prototyp- oder Sandbox-Mandant. Einstellungen ausprobieren, bevor sie im Customizing-Mandanten gemacht werden. Mandantenübergreifende Änderungen sind gesperrt.
`QTST`	Qualitätssicherung	QS-Mandant. Test der transportierten Änderungen vor dem Produktivgang. Customizing kommt nur per Transport.
`TRNG`	Qualitätssicherung	Schulungsmandant. Anwender lernen neue Funktionen mit Testdaten. Customizing und Repository sind gesperrt.
`PROD`	Produktion	Produktivmandant. Nur Produktivbetrieb: kein Customizing, keine Entwicklung, keine Tests.

SAP empfiehlt, alle Customizing-Einstellungen in einem einzigen Customizing-Mandanten vorzunehmen und von dort zu transportieren. Jeder weitere Mandant, in dem Customizing gepflegt wird, ist eine Quelle für Abweichungen.

Technisch setzen Sie das Konzept in SCC4 um: mit der passenden Mandantenrolle, etwa Customizing für CUST, Schulung/Ausbildung für TRNG und Produktiv für PROD, mit den Änderungsoptionen und mit einem Schutz gegen Überschreiben für den Produktivmandanten. Wie das im Einzelnen geht, zeigt der Artikel SAP-Mandant anlegen, löschen und in SCC4 einstellen.

Was jedes System in S/4HANA kostet

In S/4HANA liegt der Datenbestand im Hauptspeicher der SAP-HANA-Datenbank. Dazu kommt Arbeitsspeicher für Abfragen und Zwischenergebnisse. Wie viel Hauptspeicher ein System braucht, hängt also direkt davon ab, wie viele Daten darin stehen. Eine Schätzung für ein bestehendes System liefert der Sizing-Report aus SAP-Hinweis 1872170.

Für die Landschaft heißt das: Entscheidend ist, wie jedes System befüllt wird. Ein Entwicklungssystem mit Customizing und einigen Testfällen bleibt klein. Jedes System, das per Systemkopie oder per Mandantenkopie mit Anwendungsdaten aus der Produktion kommt, erbt dagegen die komplette Historie. Es braucht fast so viel Hauptspeicher wie die Produktion.

System	Typische Befüllung	Hauptspeicher
Entwicklung	Customizing und gezielt angelegte Testdaten	klein
Qualitätssicherung	oft Kopie aus der Produktion	nahe an der Produktion
Pre-Production, Wartungs-QS	oft Kopie aus der Produktion	nahe an der Produktion
Sandbox-System	Kopie der Produktion oder nur Customizing	klein bis nahe an der Produktion
Schulung	definierte Schulungsdaten oder Kopie	klein bis nahe an der Produktion
Produktion	alle Daten	Maßstab

Vereinfachtes Beispiel. Die Produktion hält 3 TB Daten im Hauptspeicher. QS, Pre-Production und Sandbox sind Vollkopien. Zusammen sind das rund 12 TB, drei Viertel davon in Systemen, in denen niemand produktiv arbeitet. Eine Projektlandschaft bringt weitere Kopien dazu.

Mit dem Hauptspeicher wachsen Storage und Backups jedes Systems. Und Arbeitsspeicher ist seit Herbst 2025 deutlich teurer geworden, mehr dazu im Artikel RAM-Preise und S/4HANA.

Non-Prod nach Zweck dimensionieren

Für jedes Nicht-Produktivsystem lautet die Frage: Was wird dort getestet, und welche Daten braucht es dafür? Die Antwort fällt je System anders aus.

Entwicklung und Entwicklertests: Customizing und gezielt angelegte Testfälle. Produktivdaten sind hier selten nötig und wegen personenbezogener Daten auch nicht wünschenswert.
QS und Regressionstests: produktionsnahe Daten. Für die meisten Tests reichen die letzten Monate, dazu offene Vorgänge und die Stammdaten.
Wartung und Fehleranalyse: aktuelle Belege, damit sich Fehler aus der Produktion nachstellen lassen.
Schulung: ein definierter Datenbestand, der sich vor jeder Schulung wiederherstellen lässt.
Last- und Performancetests: Hier zählt das Volumen. Dafür bleibt eine Vollkopie das passende Mittel, am besten nur für die Dauer der Tests.

Dazu kommen Hebel, die unabhängig vom Kopierverfahren wirken: Non-Prod-Systeme ohne Hochverfügbarkeit betreiben, Systeme nur so lange vorhalten, wie ein Projekt sie braucht, nicht mehr benötigte Mandanten löschen und die Produktion selbst durch Archivierung verkleinern. Grundlage ist eine Bestandsaufnahme: Datenbankgröße und Hauptspeicher jedes Systems, nicht nur der Produktion. Wie Sie einen QS-Refresh mit diesem Ziel planen, zeigt das Runbook für den QS-Refresh.

Zeitscheiben statt Vollkopien

Die Standard-Mandantenkopie kennt keinen Zeitraum. Ihre Kopierprofile wählen Datenarten aus, nicht Jahre. Wer die QS mit Produktionsdaten füllt, bekommt deshalb die gesamte Historie, auch wenn für die Tests ein paar Monate reichen.

Der Data Refresh Operator kopiert stattdessen eine Zeitscheibe, zum Beispiel die letzten 90 Tage, plus alle abhängigen Objekte aus älteren Jahren, aufgelöst bis zum Fixpunkt. So lässt sich jedes Non-Prod-System mit dem Zeitraum füllen, den sein Zweck verlangt. Die Datenbankgrößen aller verbundenen Systeme misst DRO im Control-System selbst. Das ist die Bestandsaufnahme aus dem vorigen Abschnitt.

–75 %: HANA-RAM in Non-Prod
–60 %: Storage & Backup

Richtwerte aus Referenzszenarien. Die tatsächlichen Effekte hängen von Systemgröße, Historie und Refresh-Zyklen ab.

DRO läuft ab SAP S/4HANA 2023 und ersetzt die Mandantenkopie, nicht die Systemkopie. Für Last- und Performancetests oder ein Sandbox-System per Systemkopie bleiben die bekannten Verfahren. Wie sich der Speicher in QS, Test und Sandbox zusammensetzt, zeigt die Seite HANA-Speicher in Non-Prod senken.

Quellen

SAP-Hilfe: Systemlandschaft (SAP NetWeaver 7.3)
SAP-Hilfe: Mandanten und ihre Rollen (SAP NetWeaver 7.3)
SAP-Hilfe: Konfiguration des TMS (SAP NetWeaver 7.3)
SAP-Hilfe: Entwicklungs-, Qualitätssicherungs- und Produktivsystem konfigurieren (SAP NetWeaver 7.3)
SAP-KBA 2461322: Where to find information on configuring and using Retrofit? Solution Manager 7.2 (SAP-Support-Portal, Anmeldung nötig)
SAP-Hinweis 1872170: ABAP on HANA sizing report (S/4HANA, Suite on HANA) (SAP-Support-Portal, Anmeldung nötig)

SAP-Systemlandschaft und Mandantenkonzept: DEV, QS, Produktion, Sandbox