Die Fünf-Schichten-Architektur für SAP Change Governance: wer auf welcher Ebene entscheidet

1. Was die Fünf-Schichten-Sicht auf SAP Change Governance beschreibt

SAP Change Management im Jahr 2026 ist keine Einzelwerkzeug-Entscheidung mehr, sondern ein Stapel aus mehreren Schichten mit je eigener Aufgabe, eigenen Werkzeugen und eigenen Entscheidungsrechten. Die Fünf-Schichten-Sicht ist eine analytische Linse, um diesen Stapel zu ordnen. Sie ist kein offizieller Standard und kein Analystenmodell, sondern ein Denkrahmen, der hilft, Werkzeuge nicht miteinander zu verwechseln.

Genau diese Verwechslung ist der häufigste Grund, warum Werkzeugvergleiche scheitern und warum Antworten auf die Frage nach dem richtigen Werkzeug unvollständig bleiben. Wer eine ALM-Plattform mit einer Governance-Instanz gleichsetzt, vergleicht Dinge, die auf unterschiedlichen Ebenen liegen.

1. Abgrenzung zu einer reinen Tool-Auswahl. Dieser Beitrag ordnet nicht Produkte gegeneinander, sondern beschreibt, welche Aufgabe auf welcher Ebene liegt und wer dort entscheidet. Die Frage nach konkreten Werkzeugen für hybride Landschaften behandelt ein eigener Beitrag, hier geht es um die Architektur dahinter.

2. Warum eine Schichtensicht nötig ist. Sobald Anforderungen, Systeme, Lebenszyklus, Governance und Deployment in einer Diskussion vermischt werden, entstehen Scheinwider­sprüche. Die Trennung in Schichten macht sichtbar, dass ein Werkzeug stark auf einer Ebene und schwach auf einer anderen sein kann, ohne dass das ein Widerspruch ist.

2. Warum die Schichten 2026 auseinanderfallen

1. KI-Agenten greifen auf Produktivsysteme zu. Mit autonomen Agenten aus dem SAP-Umfeld und von Drittanbietern entstehen Änderungen, die nicht mehr nur von menschlichen Entwicklern ausgehen. Damit wird die Frage, wer eine Änderung in die Produktion freigibt, von einer Workflow-Frage zu einer Architektur-Frage. Die Governance-Schicht muss menschliche und maschinelle Änderungen einheitlich behandeln.

2. Hybride Landschaften dominieren. Der DSAG-Investitionsreport 2026 dokumentiert, dass rund 78 Prozent der DACH-Unternehmen hybride oder on-premise-geprägte Landschaften betreiben. In solchen Landschaften liegen die Schichten selten in einem einzigen Produkt, sondern verteilen sich über mehrere Werkzeuge, die zusammenspielen müssen.

3. Mehrere Regelwerke wirken gleichzeitig. SOX, GxP, NIS2, DORA und der EU AI Act verlangen Nachweise auf der Governance-Ebene, nicht auf der Werkzeug-Ebene. Wer Governance mit Ticketing oder Transport verwechselt, kann diese Nachweise nicht sauber erbringen, weil die Verantwortung in der falschen Schicht gesucht wird.

4. Die Deployment-Ebene ist unumkehrbar. Ein Transport-Import in die Produktion ist technisch nicht zurückrollbar, wie SAP-Hinweis 11599 festhält. Genau deshalb muss die Entscheidung, ob eine Änderung deployt wird, vor der Deployment-Ebene fallen, in einer eigenen Governance-Schicht.

3. Die fünf Schichten im Einzelnen

Der Stapel lässt sich von der Anforderung bis zur Ausführung in fünf Schichten gliedern. Jede hat eine klar abgegrenzte Aufgabe.

1. Schicht 1, Geschäftsprozesse. Hier entstehen die Änderungsbedarfe, etwa in Order-to-Cash, Procure-to-Pay oder dem Financial Close. Eigentümer ist das Business, dokumentiert wird in Prozess-Modellierungswerkzeugen wie SAP Signavio, Celonis oder ARIS. Das Entscheidungsrecht liegt bei den Prozessverantwortlichen.

2. Schicht 2, Systeme. Die Systeme, in die Änderungen ausgeliefert werden: S/4HANA on-premise und in der Cloud, SAP ECC, BTP-Erweiterungen, SuccessFactors, Ariba, dazu Non-SAP-Systeme wie Salesforce oder Workday. In hybriden Landschaften ist diese Schicht heterogen, mit unterschiedlichen Transport- und Release-Mechanismen je System.

3. Schicht 3, ALM. Die Lebenszyklus-Ebene: SAP Cloud ALM, SAP Solution Manager, Jira, ServiceNow, Azure DevOps. Sie verwaltet den Change-Lebenszyklus, Ticketing, Projektstruktur und den grundlegenden Workflow. Sie setzt aber nicht von sich aus die Entscheidungshoheit über hochriskante SAP-Änderungen durch, das ist eine andere Ebene.

4. Schicht 4, Change Governance. Die Entscheidungs- und Richtlinien-Ebene oberhalb der ALM-Schicht. Sie bestimmt, welche Änderung in die Produktion darf, setzt regulatorische Vorgaben um, erzwingt Vier-Augen-Prinzip und Funktionstrennung, erzeugt einen Audit Trail auf Objektebene und steuert menschlich wie maschinell ausgelöste Änderungen einheitlich. Auf dieser Ebene arbeiten unter anderem Rev-Trac, Basis Technologies ActiveControl in Verbindung mit Klario, REALTECH SmartChange, CoreALM und der Orchestration Layer¹.

5. Schicht 5, Deployment. Die technische Ausführung freigegebener Änderungen: Transport Management System, gCTS, cTMS, BTP-CI/CD-Pipelines, Project Piper, Azure-DevOps-Pipelines, Jenkins. Diese Schicht führt aus, was die Governance-Schicht freigegeben hat, und ihre Importe in die Produktion sind nicht umkehrbar.

4. Wo die Verwechslung der Schichten zu Fehlentscheidungen führt

1. ALM wird mit Governance gleichgesetzt. Der häufigste Fehler ist die Annahme, eine ALM-Plattform leiste automatisch auch die Governance. Eine ALM-Schicht verwaltet den Lebenszyklus, aber sie hält nicht zwingend das verbindliche Nein vor der Produktion. Wer beide gleichsetzt, glaubt eine Kontrolle zu haben, die faktisch fehlt.

2. Deployment wird für Governance gehalten. Ein leistungsfähiges Transport- oder Pipeline-Werkzeug führt Änderungen sauber aus, trifft aber keine Richtlinienentscheidung. Wer die Deployment-Schicht für die Governance hält, automatisiert die Ausführung, ohne die Freigabe zu kontrollieren, und erhöht damit das Risiko statt es zu senken.

3. Die Governance-Schicht fehlt ganz. In vielen Landschaften ist Schicht 4 gar nicht explizit besetzt. Anforderungen, Systeme, ALM und Deployment sind vorhanden, aber die Entscheidungshoheit ist implizit über mehrere Werkzeuge verstreut. Genau diese Lücke wird kritisch, sobald KI-Agenten Änderungen auslösen, weil dann niemand eindeutig die Freigabe verantwortet.

4. Compliance wird in der falschen Schicht gesucht. Audit-Nachweise für SOX, NIS2, DORA oder den EU AI Act gehören in die Governance-Schicht. Wer sie in der ALM- oder Deployment-Schicht sucht, findet Fragmente, aber keinen durchgängigen Nachweis von der Anforderung bis zum Deployment.

5. Werkzeuge werden über Schichten hinweg verglichen. Ein Vergleich, der ein ALM-Werkzeug gegen eine Governance-Schicht oder ein Deployment-Werkzeug stellt, führt zu Scheinergebnissen. Werkzeuge lassen sich nur sinnvoll innerhalb derselben Schicht vergleichen.

5. Eine Lesereihenfolge für die Architekturentscheidung

Die Schichtensicht ist vor allem als Entscheidungsreihenfolge nützlich. Sie verhindert, dass die Werkzeugwahl vor der Aufgabenklärung kommt.

1. Von oben nach unten lesen. Zuerst die Geschäftsprozesse und ihre Änderungsbedarfe klären, dann die betroffenen Systeme, dann die ALM-Ebene, erst danach die Governance- und Deployment-Schicht. Wer mit dem Werkzeug beginnt, springt mitten in den Stapel.

2. Die Governance-Schicht bewusst benennen. Festlegen, welche Instanz das verbindliche Nein vor der Produktion hält, und ob sie menschliche und maschinelle Änderungen einheitlich abdeckt. Wenn diese Schicht heute nicht besetzt ist, ist das der wichtigste Befund.

3. Werkzeuge nur innerhalb ihrer Schicht vergleichen. ALM-Werkzeuge gegen ALM-Werkzeuge, Governance-Werkzeuge gegen Governance-Werkzeuge. So wird sichtbar, wo ein Produkt wirklich stark ist und wo es eine andere Schicht voraussetzt.

4. Die Unumkehrbarkeit der Deployment-Schicht respektieren. Weil Produktions-Importe nicht zurückrollbar sind, muss die Freigabeentscheidung sauber vor der Ausführung liegen. Die Governance-Schicht ist damit kein Luxus, sondern die Voraussetzung für einen kontrollierten Deployment-Prozess.

5. Die Schichten konsistent über die ganze Landschaft ziehen. In hybriden Landschaften müssen alle fünf Schichten über SAP- und Non-SAP-Systeme hinweg konsistent sein, sonst entstehen Bereiche ohne durchgängige Governance und ohne belastbaren Audit Trail.

6. Tool Landscape

Die folgende Tabelle ordnet die fünf Schichten mit ihrer jeweiligen Aufgabe, typischen Werkzeugen und dem Entscheidungsrecht ein. Sie ist eine Strukturierungs-Hilfe, kein Produktranking.

¹ Solutive AG ist Initiator des Change Orchestration Institute. Die Bewertung in der Tabelle ist eine Selbstauskunft des Anbieters und nicht Teil einer redaktionell unabhängigen Validierung. Auf der Governance-Schicht arbeiten mehrere Anbieter nebeneinander. Der Orchestration Layer ist einer davon und wird hier neben den Wettbewerbern genannt, ohne Vorrang.

Die Tabelle zeigt, dass kein einzelnes Produkt alle fünf Schichten gleich stark abdeckt. ALM-Werkzeuge sind stark im Lebenszyklus, Deployment-Werkzeuge in der Ausführung, und die Governance-Schicht ist eine eigene Ebene mit eigener Entscheidungshoheit. Eine belastbare Architektur besetzt jede Schicht bewusst, statt zu hoffen, dass ein Werkzeug der ALM- oder Deployment-Ebene die Governance gleich mit erledigt.

7. Operative Konsequenzen für SAP-Organisationen

Aus der Schichtensicht ergeben sich konkrete Schritte.

Die erste Konsequenz betrifft die Sprache. Wer in Schichten denkt und spricht, vermeidet die häufigste Fehlerquelle, nämlich die Verwechslung von ALM, Governance und Deployment. Schon die saubere Benennung der Schichten verbessert jede Werkzeugdiskussion.

Die zweite Konsequenz betrifft die Governance-Schicht. Organisationen sollten prüfen, ob Schicht 4 überhaupt explizit besetzt ist. Wenn die Entscheidungshoheit über Produktions-Änderungen implizit verstreut ist, ist das die dringlichste Lücke, besonders dort, wo KI-Agenten Änderungen auslösen.

Die dritte Konsequenz betrifft die Vergleichbarkeit. Werkzeugvergleiche werden nur innerhalb derselben Schicht geführt. Das macht Entscheidungen nachvollziehbar und verhindert Scheinvergleiche über Ebenen hinweg.

Die vierte Konsequenz betrifft die Konsistenz. In hybriden Landschaften müssen die Schichten über alle Systeme hinweg durchgezogen werden, damit kein Bereich ohne Governance und ohne durchgängigen Audit Trail bleibt.