SAP Governance im Betrieb – wo technische Schulden wirklich entstehen

Stand: Oktober 2026 · David Riederich · Aus dem englischen Original maschinell übersetzt

In SAP-Landschaften werden technische Schulden oft mit Transformationsprojekten verbunden: überhastete Designentscheidungen, unklarer Scope, Kompromisse vor dem Go-live. Diese Themen sind relevant. In vielen Organisationen entstehen die größten technischen Schulden aber nicht im Projekt selbst. Sie wachsen danach – im laufenden Betrieb.

Projekte haben meist sichtbare Strukturen: Streams, Steering Committees, Eskalationswege und definierte Verantwortlichkeiten. Der Betrieb hat häufig etwas anderes: viele kleine Änderungen, viele lokale Interessen und keine starke Architekturperspektive über die gesamte Landschaft hinweg. Genau dort wird Governance entscheidend.

Das eigentliche Risiko: Architektur erodiert leise

Große SAP-Programme sind sichtbar. Sie haben Aufmerksamkeit, Budgets, Zeitpläne und Managementdruck. Entscheidungen können trotzdem unvollkommen sein, aber sie sind in der Regel zumindest explizit.

Im Betrieb ist die Situation anders. Änderungen gelangen über Support-Anfragen, lokale Verbesserungsideen, abteilungsspezifische Anforderungen, kleine Erweiterungen, Schnittstellenanpassungen und pragmatische Workarounds in die Landschaft.

Jede einzelne Änderung kann isoliert betrachtet sinnvoll wirken. Ein lokaler Prozess wird etwas einfacher. Eine Abteilung bekommt das Feld, das sie benötigt. Ein Report wird angepasst. Eine Schnittstelle wird erweitert. Ein Workaround vermeidet eine größere Diskussion.

Über die Zeit erzeugen diese kleinen operativen Entscheidungen jedoch die tatsächliche Architektur des Systems. Nicht das Zielbild. Nicht die Programmfolie. Das reale System.

Projekte definieren Architektur auf dem Papier. Der Betrieb entscheidet, ob sie überlebt.

Governance ist keine reine Projektdisziplin

Governance wird häufig während Transformationen eingeführt und nach dem Go-live schrittweise zurückgefahren. Die Annahme ist einfach: Wenn das Projekt abgeschlossen ist, kann Governance reduziert werden.

Genau dann wird die Landschaft jedoch besonders verletzlich. Nach dem Go-live beginnt das System, reales Organisationsverhalten aufzunehmen: Ausnahmen, Abkürzungen, lokale Prioritäten, Support-Zwänge und ungelöste Prozesskonflikte.

Wenn Governance nur während des Projekts existiert, kehrt Komplexität über den Betrieb zurück. Nicht als ein großer Designfehler, sondern als hunderte kleine Entscheidungen.

Warum im Betrieb oft mehr Schulden entstehen als im Projekt

In Projekten sind Entscheidungen meist sichtbar, weil sie Teil von Scope, Budget und Zeitplan sind. Im Betrieb werden Entscheidungen dagegen oft als kleine Änderungen behandelt.

Genau das ist das Problem.

Viele operative Änderungen sind aus Ticket-Sicht klein, aus Architektur-Sicht aber erheblich. Ein neues Feld, eine neue Regel, eine neue Ausnahme, eine neue Schnittstelle oder eine lokale Prozessabweichung wirken zunächst harmlos. Wenn jedoch jede Abteilung lokal optimiert, wird das System zum technischen Abbild organisatorischer Silos.

Typische Muster sind:

• Abteilungen beantragen Änderungen für ihren lokalen Prozess, ohne bereichsübergreifende Auswirkungen zu berücksichtigen
• Applikationsverantwortliche genehmigen Änderungen innerhalb ihres Bereichs ohne Architekturprüfung
• Support-Teams setzen pragmatische Lösungen um, die dauerhaft bleiben
• externe Partner optimieren für ihren Scope statt für die gesamte Landschaft
• lokale Varianten werden akzeptiert, weil ihre Infragestellung interne Konflikte erzeugen würde
• Schnittstellen werden erweitert, weil Prozessharmonisierung politisch schwieriger ist

So werden SAP-Landschaften schwer veränderbar: nicht weil ein einzelnes Projekt gescheitert ist, sondern weil der Betrieb keinen Mechanismus hatte, um architektonische Kohärenz zu schützen.

Das Silo-Problem

Silodenken ist einer der stärksten Treiber von SAP-Komplexität. Jede Abteilung optimiert tendenziell für ihre eigenen Ziele, Zeitpläne und Schmerzpunkte. Das ist nachvollziehbar. SAP-Systeme respektieren organisatorische Silos jedoch nicht.

Eine Änderung im Einkauf kann die Finanzprozesse beeinflussen. Eine Ausnahme im Vertrieb kann Auswirkungen auf die Logistik haben. Eine Anpassung in den Stammdaten kann Reporting-Effekte erzeugen. Ein lokaler Workflow kann Support-Komplexität für die IT schaffen. Eine kleine Integrationsentscheidung kann das gesamte Betriebsmodell beeinflussen.

Ohne Governance trifft jedes Silo lokal rationale Entscheidungen. Das Ergebnis ist eine global irrationale Landschaft.

Die meiste SAP-Komplexität ist lokal nicht irrational. Sie wird erst systemisch irrational.

Governance ist Entscheidungsarchitektur

Governance wird oft als Kontrolle, Reporting oder Bürokratie missverstanden. Nützliche Governance beantwortet in Wahrheit eine praktische Frage:

Wie treffen wir SAP-Entscheidungen so, dass die Landschaft über die Zeit beherrschbar bleibt?

Deshalb ist Governance nicht dasselbe wie Projektmanagement.

• Projektmanagement fragt: Wie bekommen wir das umgesetzt?
• Architektur fragt: Was macht das langfristig mit dem System?
• Governance fragt: Wer entscheidet, nach welchen Kriterien, und wer trägt die Folgen?

Im Betrieb wird diese Unterscheidung noch wichtiger. Es gibt möglicherweise keinen Projektleiter. Es gibt möglicherweise kein Transformationsgremium. Es gibt vielleicht nur eine fachliche Anfrage, einen Applikationsverantwortlichen, ein Support-Team und einen Implementierungspartner.

Genau dort muss Governance funktionieren.

Drei Fragen, die jedes operative Governance-Modell beantworten muss

Ein Governance-Modell muss nicht schwergewichtig sein. Aber es muss drei Fragen konsequent beantworten.

1. Welche Änderungen sind architekturrelevant?

Nicht jedes Ticket braucht ein Architecture Board. Aber manche Änderungen dürfen niemals rein lokal oder rein technisch behandelt werden.

Beispiele sind:

• neue Prozessvarianten
• neue oder erweiterte Schnittstellen
• neue Custom Fields, hinter denen Prozesslogik steht
• Workflow-Abweichungen
• Änderungen mit Auswirkungen auf Stammdaten oder Reporting-Konsistenz
• Ausnahmen vom Standardverhalten
• Erweiterungen, die operative Verantwortung erzeugen

Governance muss definieren, welche Änderungen vor der Umsetzung breiter bewertet werden müssen.

2. Welche Kriterien werden verwendet?

Ohne Kriterien folgen Entscheidungen dem Druck. Die lauteste Abteilung, die dringendste Eskalation oder die bequemste Lösung gewinnt.

Nützliche Kriterien sind zum Beispiel:

• Auswirkungen auf den SAP-Core
• Fit-to-Standard-Alternativen
• Integrations- und Datenfolgen
• bereichsübergreifende Auswirkungen
• operative Verantwortung
• Upgrade- und Release-Auswirkungen
• langfristige Kosten der Abweichung

Es geht nicht darum, jede Entscheidung langsam zu machen. Es geht darum, die Konsequenzen sichtbar zu machen, bevor sie dauerhaft werden.

3. Wer trägt die Folgen?

Operative Änderungen leiden oft unter einem einfachen Problem: Der Anforderer besitzt den Bedarf, aber nicht die langfristigen Folgen.

Eine Abteilung fordert eine Änderung an. IT setzt sie um. Ein Partner liefert sie. Später muss der Betrieb sie warten, upgraden, erklären und supporten.

Governance ist unvollständig, wenn sie Änderungen nur genehmigt. Sie muss auch definieren, wer das verantwortet, was diese Änderungen erzeugen.

Was ohne operative Governance passiert

Fehlende Governance erzeugt selten einen einzelnen dramatischen Fehler. Sie erzeugt schleichende Erosion.

Die Symptome sind vertraut:

• lokale Prozessvarianten wachsen ohne gemeinsame Bewertungslogik
• Abteilungen optimieren eigene Änderungen, ohne Landschaftsauswirkungen zu verstehen
• externe Empfehlungen werden akzeptiert, weil keine unabhängige Bewertung existiert
• Architekturentscheidungen werden in Tickets getroffen statt bewusst geprüft
• temporäre Lösungen werden dauerhaft, weil niemand sie erneut hinterfragt
• Integrationsentscheidungen werden fallweise statt landschaftsweit getroffen
• Verantwortlichkeiten werden nach der Umsetzung unklar

Keines dieser Themen wirkt am Anfang katastrophal. Zusammen erzeugen sie Systeme, die schwerer zu upgraden, schwerer zu betreiben und schwerer zu steuern sind.

Governance sollte den Betrieb schneller machen, nicht langsamer

Ein häufiger Einwand lautet, Governance verlangsame die Dinge. Schlechte Governance tut das. Gute Governance reduziert wiederkehrende Debatten, unklare Eskalationswege und Nacharbeit.

Der Betrieb wird schneller, wenn Teams wissen:

• welche Änderungen lokal entschieden werden können
• welche Änderungen eine Architekturprüfung brauchen
• welche Abweichungen fachliche Verantwortung benötigen
• welche Themen eskaliert werden müssen
• welche Prinzipien nicht umgangen werden dürfen

Ziel ist nicht, jede operative Änderung in ein Gremium zu zwingen. Ziel ist, jene wenigen Entscheidungspunkte zu definieren, die die gesamte Landschaft schützen.

Ein pragmatisches Governance-Modell für den SAP-Betrieb

Für viele SAP-Organisationen kann operative Governance mit wenigen praktischen Mechanismen beginnen.

1. Change-Klassifizierung

Jede Änderung sollte vor der Umsetzung klassifiziert werden: lokal, bereichsübergreifend, architekturrelevant, integrationsrelevant oder core-relevant.

Bereits diese einfache Klassifizierung verhindert, dass Architekturentscheidungen in gewöhnlichen Tickets versteckt werden.

2. Kurzes Impact Assessment

Für architekturrelevante Änderungen reicht oft ein kurzes Impact Assessment. Es sollte beantworten:

• Welche Prozessbereiche sind betroffen?
• Erzeugt oder erweitert die Änderung eine Variante?
• Hat sie Auswirkungen auf Integration, Daten oder Reporting?
• Wer verantwortet die Änderung nach der Umsetzung?
• Gibt es eine Standardlösung oder eine einfachere Alternative?

3. Klare Entscheidungsrechte

Der Fachbereich sollte den fachlichen Nutzen verantworten. IT sollte technische Nachhaltigkeit verantworten. Architektur sollte landschaftsweite Kohärenz verantworten.

Governance definiert, wie diese Perspektiven zusammengeführt werden, bevor Entscheidungen zur Systemrealität werden.

4. Varianten- und Ausnahmenregister

Varianten und Ausnahmen sollten sichtbar sein. Ein einfaches Register kann festhalten, warum sie existieren, wem sie gehören und wann sie überprüft werden sollen.

Das ist keine Dokumentation um ihrer selbst willen. Es ist ein Gedächtnissystem für die Organisation.

5. Wiederkehrender Architektur-Review

Architekturprüfung sollte nicht nur in Projekten stattfinden. Sie sollte eine wiederkehrende operative Routine für ausgewählte Änderungen, Ausnahmen und Integrationsentscheidungen sein.

Andernfalls entfernt sich die Landschaft schleichend von ihrer beabsichtigten Architektur.

Die Rolle unabhängiger Bewertung

Operative Governance wird besonders schwierig, wenn Unternehmen keine eigene SAP-Architektur- oder Governance-Funktion haben. In solchen Umgebungen tragen Key-User, Applikationsverantwortliche und externe Partner oft den Großteil der Entscheidungslast.

Externe Partner können kompetent und zuverlässig sein. Sie sind jedoch häufig auch Teil des Delivery-Modells. Ihre Empfehlungen können durch Projektumfang, verfügbare Skills, Implementierungspräferenzen oder kurzfristige Machbarkeit geprägt sein.

Eine unabhängige Perspektive hilft, drei Dinge zu unterscheiden:

• was technisch möglich ist
• was den unmittelbaren fachlichen Bedarf löst
• was für die SAP-Landschaft nachhaltig ist

Diese Unterscheidung ist entscheidend. Viele Lösungen funktionieren. Nicht alle davon will man ein Jahrzehnt lang mittragen.

Governance muss Transformation und Betrieb verbinden

Transformationsprogramme können Zielarchitekturen, Clean-Core-Prinzipien und Entscheidungsgremien einführen. Wenn diese Strukturen jedoch nicht in den Betrieb übergehen, baut die Organisation schrittweise genau jene Komplexität wieder auf, die sie eigentlich reduzieren wollte.

Nachhaltige Governance verbindet beide Welten:

• Transformations-Governance für große Programmentscheidungen
• Architektur-Governance für System-, Integrations- und Erweiterungsentscheidungen
• Operative Governance für laufende Änderungen, Varianten und Ausnahmen

Der eigentliche Test ist nicht, ob Governance während des Projekts funktioniert. Der eigentliche Test ist, ob sie sechs Monate nach dem Go-live noch funktioniert.

Fazit: Governance schützt das System vor schleichender Erosion

Governance ist keine Meeting-Struktur. Sie ist kein Reporting. Sie ist keine Bürokratie.

Governance ist die Architektur von Entscheidungen. Im SAP-Betrieb schützt sie die Landschaft davor, durch isolierte Anforderungen, lokale Optimierungen und ungeprüfte Ausnahmen umgeformt zu werden.

Ohne Governance wird Architektur reaktiv. Clean Core wird zum Schlagwort. Und der Betrieb erzeugt technische Schulden schneller, als Projekte sie abbauen können.

Gute Governance kontrolliert Veränderung nicht um ihrer selbst willen. Sie verhindert, dass Veränderung zu unbeherrschter Komplexität wird.

Häufige Fragen zu SAP Governance

Was ist SAP Governance?

SAP Governance definiert, wie Entscheidungen über Prozesse, Architektur, Erweiterungen, Integrationen und Abweichungen getroffen, bewertet und verantwortet werden. Sie schafft Klarheit über Rollen, Kriterien und Verantwortlichkeit.

Warum ist Governance im SAP-Betrieb wichtig?

Viele SAP-Landschaften werden durch kleine operative Änderungen komplex: lokale Ausnahmen, Schnittstellenanpassungen, Workarounds und abteilungsspezifische Erweiterungen. Governance hilft sicherzustellen, dass solche Änderungen bewertet werden, bevor sie langfristige technische Schulden erzeugen.

Wie unterscheidet sich Governance von Projektmanagement?

Projektmanagement koordiniert Delivery. Governance definiert Entscheidungsrechte, Bewertungskriterien und Verantwortung für Konsequenzen. Beides ist notwendig, erfüllt aber unterschiedliche Zwecke.

Verlangsamt Governance den SAP-Betrieb?

Schlechte Governance kann Abläufe verlangsamen. Gute Governance macht den Betrieb schneller, weil klar ist, welche Änderungen lokal entschieden werden können, welche eine Architekturprüfung benötigen und welche eskaliert werden müssen.

Wann sollte Governance eingeführt werden?

Governance sollte eingeführt werden, bevor operative Änderungen zu dauerhafter Komplexität werden. Ein pragmatischer Startpunkt ist die Klassifizierung von Änderungen, die Definition von Entscheidungskriterien und der Aufbau einfacher Review-Routinen für Abweichungen, Integrationen und architekturrelevante Änderungen.

Zurück zu den Insights