An initiative by Solutive AG
solutive.ag
Change & Release

Transport Management bei SAP: Vom Request zum produktiven Deployment

Transport Management steuert den Weg von Änderungen vom Entwicklungssystem bis in Produktion. Drei Fehlerklassen dominieren den Alltag.
May 6, 2025
min Lesezeit
11

Was das SAP Transport Management System steuert und verwaltet

Transport Management bezeichnet in der SAP-Welt die Disziplin, mit der Entwicklungs-, Customizing- und Konfigurationsänderungen kontrolliert zwischen Systemen bewegt werden. Die technische Grundlage ist das SAP Transport Management System (STMS): ein ABAP-Programm, das Transportrouten, Importwarteschlangen und Transportprotokolle verwaltet. STMS ist kein optionales Add-on, sondern Bestandteil jeder SAP-Basis-Installation.

Ein Transport Request (TR) ist das atomare Artefakt. Er enthält Objekte (Programme, Dictionary-Strukturen, Customizing-Einträge) und wird als Einheit exportiert und importiert. Was in einen TR aufgenommen wird, entscheidet der Entwickler oder Customizer zum Zeitpunkt der Anlage. Was exportiert wird, ist danach versionsstabil und kann nicht mehr verändert werden.

Die Transportlandschaft ist die Abfolge von Systemen, durch die ein TR läuft. Typisch: Entwicklungssystem (DEV) → Qualitätssicherungssystem (QAS) → Produktivsystem (PRD). Erweiterte Landschaften umfassen Pre-Production-Systeme, Schulungssysteme, Sandbox-Systeme. Für jede dieser Stationen gibt es eine Importwarteschlange. Transport Management bedeutet: steuern, was wann in welche Warteschlange kommt, in welcher Reihenfolge importiert wird und was passiert, wenn ein Import fehlschlägt.

Downgrade-Problem, Object Overtaking und Missing Dependencies im Alltag

Die häufigsten Fehler im SAP-Transport-Management sind kein Zeichen von technischer Inkompetenz. Sie sind strukturell und entstehen immer dann, wenn mehrere parallele Entwicklungslinien auf dasselbe Produktivsystem zielen.

Downgrade-Problem. Entwickler A ändert Objekt X in TR-1. Entwickler B hat dasselbe Objekt X aus einem älteren Stand in TR-2. TR-2 wird nach TR-1 importiert. Ergebnis: Die Änderungen von Entwickler A sind überschrieben. Das System enthält eine ältere Version, ohne dass eine Fehlermeldung erscheint. Das Downgrade-Problem ist unsichtbar, bis es Auswirkungen hat.

Object Overtaking. TR-1 und TR-2 sind unabhängig voneinander. TR-2 wird versehentlich vor TR-1 importiert, obwohl TR-1 logisch zuerst kommen müsste (weil TR-2 auf Änderungen aus TR-1 aufbaut). Ergebnis: Laufzeitfehler, inkonsistenter Systemzustand, manuelle Korrekturen.

Missing Dependencies. TR-1 setzt voraus, dass ein Dictionary-Objekt existiert, das erst in TR-2 angelegt wird. TR-1 wird ohne TR-2 importiert. Ergebnis: Syntaxfehler, Aktivierungsfehler, Systemabbrüche.

Collision Detection Failure. In einer Landschaft ohne Cross System Object Lock (CSOL) können zwei Entwickler dasselbe Objekt gleichzeitig in parallelen TRs bearbeiten. Keiner weiss vom anderen. Wer zuletzt importiert, gewinnt. Wer vorher importiert hat, verliert seine Änderungen.

CSOL, Sequenzprüfung und kontrollierte Importzyklen

Cross System Object Lock (CSOL). CSOL ist der technische Mechanismus, der verhindert, dass dasselbe Objekt gleichzeitig in mehreren parallelen TRs in verschiedenen Entwicklungslinien enthalten ist. Wenn Entwickler A Objekt X in TR-1 der Wartungslinie aufnimmt, wird Objekt X für die Projektlinie gesperrt. Entwickler B in der Projektlinie kann Objekt X erst aufnehmen, wenn TR-1 in Produktion ist oder explizit freigegeben wurde. CSOL ist kein Nice-to-have. In Landschaften mit parallelen Entwicklungslinien ist es die einzige technische Absicherung gegen das Downgrade-Problem.

Sequenzprüfung und Abhängigkeitsanalyse. Vor dem Import in Produktion wird geprüft: Sind alle vorausgesetzten TRs in der Warteschlange? In der richtigen Reihenfolge? Sind alle Objekte konsistent? Diese Prüfung kann manuell erfolgen, ist dann aber fehleranfällig. Werkzeuge für Transport-Orchestrierung automatisieren diese Prüfung.

Kontrollierte Importzyklen. Anstatt TRs ad hoc und einzeln zu importieren, werden sie in definierten Zyklen gebündelt: tägliche, wöchentliche oder release-gebundene Import-Batches. Jeder Import-Batch wird vor dem Import geprüft, nach dem Import validiert. Abweichungen werden protokolliert. Kontrollierte Importzyklen sind die operative Grundlage für Release Governance.

CSOL-Lücke in Cloud ALM und der Schatten-Transport als Audit-Risiko

CSOL-Lücke in SAP Cloud ALM. SAP Cloud ALM bietet CSOL in der Variante Cross-System Object Lock for Distributed Development: Es erkennt, wenn dasselbe Objekt in verschiedenen Systemlandschaften gleichzeitig geändert wird. Es bietet aber keinen Single-Landscape-CSOL: Wenn ein Kunde nur eine S/4HANA-Landschaft hat und darin parallele Wartungs- und Evolutionslinien führt, greift der Cloud-ALM-CSOL nicht. Diese Lücke ist in der SAP Community dokumentiert und von SAP bisher nicht geschlossen (Stand: April 2026). Für Kunden, die heute ChaRM mit Single-Landscape-CSOL betreiben, bedeutet eine Migration zu Cloud ALM den Verlust dieser Schutzfunktion.

Schatten-Transporte. Als Schatten-Transport gilt jeder Import, der ausserhalb des kontrollierten Change-Prozesses in ein System gelangt. Typische Varianten: Notfall-Importe durch Basis-Administratoren ohne Change-Record, Customizing-Direktänderungen in Produktionsmandanten, Import durch Umgehung der Importwarteschlange. Schatten-Transporte sind das häufigste Audit-Finding in SOX-regulierten Umgebungen. Sie erscheinen nicht im Change-System, können aber über Systemlogs nachträglich identifiziert werden.

CSOL als Pflicht, feste Importfenster, kein Transport ausserhalb des Systems

CSOL als nicht-verhandelbare Anforderung. In jeder Landschaft mit parallelen Entwicklungslinien wird CSOL aktiviert und durchgesetzt. Kein TR ohne CSOL-Check. Das gilt auch für Notfallsituationen: Der Notfall-Import geht durch den CSOL-Prozess, nicht daran vorbei.

Feste Importfenster. Importe in Qualitätssicherungs- und Produktivsysteme finden in definierten Fenstern statt. Das Importfenster ist bekannt, geplant und kommuniziert. Importe ausserhalb der Fenster erfordern eine explizite Ausnahme mit Genehmigung und Protokoll. Feste Importfenster sind die operative Voraussetzung für Release Governance.

Kein Transport ausserhalb des Systems. Jede Änderung an einem SAP-System, die nicht über einen TR läuft, ist ein Protokollbruch. Das umfasst auch Customizing-Direktänderungen in Produktion, die technisch möglich, aber prozessual verboten sind. Die Durchsetzung erfolgt über Berechtigungskonzepte: Produktion erhält nur Leseberechtigungen für Entwicklungstransaktionen. Wer Direktänderungen in Produktion vornehmen muss (echter Notfall), dokumentiert dies sofort und legt einen Documentary Change an.

Tool Landscape

Zusammenfassung

Transport Management ist die Schnittstelle zwischen Change-Entscheidung und Produktions-Realität. CSOL, Sequenzprüfung und definierte Importzyklen sind die drei Kernmechanismen für Transport-Integrität.

Autor:
Christian Steiger