Warum komplexe SAP-Systeme selten an Technik scheitern

Stand: Jänner 2026 · David

Wenn SAP-Landschaften schwerfällig, teuer und kaum noch wartbar werden, sucht man reflexartig die technische Ursache. In der Praxis zeigt sich jedoch: Die eigentliche Wurzel liegt fast immer in Entscheidungsprozessen, Organisationsmustern und fehlender Systemsicht – nicht in der Technik selbst.

Die Ausgangslage: Technik ist sichtbar, Ursachen sind systemisch

Custom Code, Schnittstellenflut, Performance-Probleme – das sind die sichtbaren Symptome. Sie sind real und müssen behoben werden. Aber sie sind fast nie die eigentliche Ursache.

Technik ist nur die Sprache, in der sich organisatorische Entscheidungen manifestieren. Komplexität entsteht dort, wo diese Entscheidungen unstrukturiert, unkoordiniert oder ohne langfristige Perspektive getroffen werden.

Drei Entscheidungsarten, die Komplexität erzeugen

1. Strategische Entscheidungen

Plattformwahl, Betriebsmodell, Cloud-Strategie, Standard-vs-Custom-Philosophie. Eine falsche oder fehlende strategische Weichenstellung wirkt jahrelang nach.

2. Taktische Entscheidungen

Wie wird eine Integration technisch umgesetzt? Welche Schnittstellenpriorität gilt? Bleibt ein Modul on-premise oder geht es in die Cloud? Hier entstehen die meisten technischen Schulden.

3. Operative Entscheidungen

Die „schnelle Lösung“ im Tagesgeschäft: eine zusätzliche Schnittstelle, eine lokale Ausnahme, ein Workaround „bis zum nächsten Release“. Diese Entscheidungen summieren sich unbemerkt zur größten Komplexitätsquelle.

Handlungsempfehlungen: Fünf pragmatische Maßnahmen, die sofort wirken

1. Entscheidungspfade sichtbar machen

Kartieren Sie die drei wichtigsten Pfade, über die Änderungen in Ihre Landschaft gelangen (z. B. Feature Requests → Fachbereich → IT, Integrationsanfragen, Release-Freigaben). Nur was sichtbar ist, lässt sich steuern.

2. Klare Ownership pro Pfad etablieren

Jeder Pfad braucht einen Business Owner und einen technischen/architektonischen Owner. Ohne namentliche Verantwortung bleibt jede Leitplanke wirkungslos.

3. Varianten kontrollieren statt verbieten

Varianten sind in großen Organisationen unvermeidlich. Führen Sie ein zentrales Varianten-Register mit Bewertung (Geschäftsmehrwert vs. technische Kosten) und Genehmigungsprozess. Das verhindert unkontrolliertes Wachstum.

4. Impact-Assessment zur Pflicht machen

Jede Änderung mit potenzieller Systemwirkung muss ein kurzes, standardisiertes Impact-Assessment durchlaufen (technisch, betrieblich, finanziell, Upgrade-Pfad). Drei Fragen reichen oft: Was lösen wir wirklich? Gibt es eine Standard-Alternative? Welche Folgekosten entstehen in drei Jahren?

5. Architektur-Routinen statt einmaliger Projekte

Architekturarbeit darf kein einmaliges Artefakt sein. Etablieren Sie wöchentliche oder 14-tägige Architektur-Reviews und ein festes Architekturboard. Architektur muss gelebt werden – wie ein Muskel.

Operationalisierung: Der 90-Tage-Plan, der ohne Großprojekt funktioniert

1. Tage 1–14: Mapping der drei wichtigsten Entscheidungspfade
2. Tage 15–30: Zuweisung klarer Business- und Architektur-Owner
3. Tage 31–45: Definition von je 2–3 Leitplanken pro Pfad (z. B. „Keine neuen Point-to-Point-Schnittstellen“, „Jede Abweichung braucht Impact-Assessment“)
4. Tage 46–60: Einführung eines 1-seitigen Impact-Templates (Pflichtfeld für jede Änderung)
5. Tage 61–90: Start einer wöchentlichen Review-Schleife + erstes Varianten-Register

Nach 90 Tagen haben Sie spürbar weniger Wildwuchs – ohne Millionenbudget und ohne monatelange Workshops.

Messbare Ziele (ohne KPI-Wahnsinn)

• Anteil der Änderungen mit vollständigem Impact-Assessment → Ziel: 100 % innerhalb von 6 Monaten
• Anzahl dokumentierter und genehmigter Varianten im Register
• Reduktion neuer Point-to-Point-Schnittstellen um ≥ 80 %
• Durchschnittliche Entscheidungszeit pro Änderung (sollte sinken, nicht steigen)

Häufige Einwände – und die ehrliche Antwort

„Das bremst uns nur.“
Gute Governance beschleunigt, weil sie Unsicherheit und Nacharbeiten reduziert.

„Wir haben keine Zeit für sowas.“
Die Alternative ist, in drei Jahren 70 % des IT-Budgets für die Pflege historischer Komplexität auszugeben – statt für Innovation.

Fazit: Architektur ist ein sozial-technisches Feld

Komplexität entsteht nicht durch fehlende Technik, sondern durch fehlende Struktur bei den Menschen, die Entscheidungen treffen.

Wer Komplexität nachhaltig reduzieren will, muss dort ansetzen, wo sie entsteht: bei Verantwortlichkeiten, Leitplanken und wiederkehrenden Routinen.

Nur wer Architektur als anhaltende Praxis begreift – und nicht als einmaliges Dokument – schafft SAP-Landschaften, die leicht, wartbar und zukunftsfähig bleiben.

Zurück zu Insights