Die digitale Wirbelsäule der Weltwirtschaft: SAP zwischen Standardisierung, Komplexität und Wolken

Von DerSchneider

Kaum ein Softwareunternehmen prägt die globale Unternehmenslandschaft so unscheinbar und doch so allgegenwärtig wie SAP. Was 1972 als Fünf-Mann-Projekt in Mannheim begann, ist heute der heimliche Dirigent der Weltwirtschaft: 87 Prozent der Fortune-500-Unternehmen lassen ihre Geschäftsprozesse durch Walldorfer Software laufen. Doch hinter dieser Erfolgsgeschichte verbirgt sich ein ambivalentes Erbe – ein Ökosystem aus ingenieurhafter Präzision, bürokratischer Schwere, technologischem Ruhm und einer schmerzhaften Migration in die Cloud.

Dieser Artikel zeichnet die Entwicklung von SAP nach, seziert die Funktionsweise von ERP-Systemen, erklärt den Mythos des Customizing, führt in die Sprache ABAP ein und navigiert durch die Wolkenmodelle – und fragt, ob das deutsche Schwergewicht die digitale Transformation meistern kann.

I. Der historische Moment: Warum IBM die Zukunft verschlief

Um SAP zu verstehen, muss man das Jahr 1972 verstehen. Die fünf Gründer – Hopp, Plattner, Wellenreuther, Hector, Tschira – waren IBM-Mitarbeiter, die einen grundlegenden Fehler ihres Arbeitgebers erkannten: IBM verkaufte Hardware und entwickelte für jeden Kunden individuelle Software. Jede Firma bekam ihr eigenes, einmaliges System. Das Ergebnis war ein Flickenteppich aus Insellösungen, die nicht miteinander sprachen.

Die Idee der SAP-Pioniere war radikal: Standardsoftware für alle. Ständige Weiterentwicklung eines einzigen Programms, das die Kernprozesse eines Unternehmens abbildet – Buchhaltung, Materialwirtschaft, Produktion, Personal. Ein gemeinsamer Datenbestand, auf den alle Abteilungen in Echtzeit zugreifen. Heute klingt das selbstverständlich. In der Großrechner-Ära war es eine Revolution.

Die erste Version hieß noch „RF“ (Finanzbuchhaltung). 1979 kam R/2 für Großrechner, 1992 dann der Durchbruch: R/3. Drei Schichten – Datenbank, Anwendung, Benutzeroberfläche – auf Client-Server-Architektur. R/3 wurde zum Synonym für ERP. Unternehmen, die wachsen wollten, kamen an SAP nicht vorbei.

Quelle: SAP SE, Chronik der SAP-Geschichte (2023); Die Pioniere – Wie SAP die Welt der Software veränderte, G. Meier (2020).

II. Was ein ERP wirklich leistet (und was nicht)

Enterprise Resource Planning – hinter diesem sperrigen Begriff verbirgt sich eine simple Idee: Alle relevanten Daten eines Unternehmens leben in einem System. Der Vertrieb erfasst einen Auftrag. Das Lager sieht sofort den verringerten Bestand. Die Buchhaltung generiert automatisch eine Rechnung. Der Produktionsplaner erhält einen Materialabruf.

In der Praxis ohne SAP bedeutet das: E-Mails, Excel-Tabellen, manuelle Abstimmungen, Medienbrüche. Ein Auftrag wird dreimal erfasst, die Preise stimmen nicht überein, die Lieferung verzögert sich. Mit SAP entfällt die Mehrfachpflege – theoretisch.

Die Kritiker weisen zu Recht auf die Schattenseiten hin: Ein ERP-System ist nur so gut wie die Prozesse, die es abbildet. Wer chaotische Abläufe in SAP presst, erhält digitalisierte Chaoten. Hinzu kommt die berüchtigte Trägheit – einmal customizte Strukturen lassen sich nur schwer ändern. Viele Unternehmen passen sich der Software an, nicht umgekehrt.

Dennoch: Für komplexe, regulierte Branchen (Pharma, Automobil, Banken) ist ein integriertes ERP wie SAP heute alternativlos. Die Transparenz über Bestände, Kosten und Liquidität in Echtzeit ist ein Wettbewerbsvorteil, den keine Excel-Tabelle bieten kann.

III. Die Kunst des Customizing – oder: Warum kein SAP-System wie das andere ist

Customizing ist das Zauberwort der SAP-Welt. Es bedeutet: Einstellen ohne Programmieren. Über Transaktion SPRO (IMG – Implementation Guide) navigiert der Berater durch eine Baumstruktur aus Schaltern, Parametern und Auswahllisten.

Ein Beispiel aus der Finanzbuchhaltung: Der Kunde möchte, dass Buchungsperiode 04 (April) nur bis zum 30.04.2026 offen ist. Kein Problem – im IMG unter Finanzwesen → Hauptbuchhaltung → Buchungsperioden → Perioden öffnen/schließen wird ein einziger Wert gepflegt. Das ist Customizing.

Ein Gegenbeispiel: Der Kunde braucht eine völlig neue Rechnungsprüfungslogik, die SAP nicht vorsieht. Das ist kein Customizing mehr – das ist Entwicklung (meist in ABAP). Die Faustregel lautet: Was ohne eigenen Code geht, ist Customizing. Alles andere ist ein Projekt.

In der Praxis verschwimmen die Grenzen. Viele Berater programmieren kleine „User-Exits“ oder „Enhancements“ – das sind Eingriffe in den SAP-Standard, die zwar als Customizing getarnt sind, aber faktisch Entwicklung bedeuten. Diese Mischformen sind die Hauptursache für teure Upgrade-Probleme Jahre später.

Typische Customizing-Bereiche: Kontenplan, Zahlungsbedingungen, Auftragsarten, Preisfindung, Urlaubsarten, Gehaltsbestandteile.

IV. ABAP – Die alternde, aber unverzichtbare Sprache des Kerns

Hinter dem Kürzel ABAP (Advanced Business Application Programming) verbirgt sich eine der erfolgreichsten und gleichzeitig meistgeschmähten Programmiersprachen der Welt. Entwickelt in den 1980er Jahren als Werkzeug für Berichte und Erweiterungen, ist ABAP heute die Muttersprache von SAP S/4HANA.

Ein minimales ABAP-Programm sieht so aus:

abap

REPORT ZMEIN_ERSTES_PROGRAMM.

START-OF-SELECTION.
  WRITE: / 'Hallo Welt, aus dem Kern des ERP'.

Realistischere Programme lesen Daten aus Datenbanktabellen, verarbeiten sie in internen Tabellen und geben Listen aus oder schreiben zurück. ABAP ist eine 4GL (Fourth Generation Language) – sie arbeitet auf hohem Abstraktionsniveau direkt mit Datenbanken und Bildschirmmasken.

Die Kritik an ABAP ist berechtigt: Die Syntax wirkt veraltet, die Entwicklungsumgebung (Transaktion SE38) stammt aus den 1990ern, und viele junge Entwickler ziehen Python oder Java vor. Dennoch: ABAP ist extrem effizient für Massendatenverarbeitung und tief in die SAP-Geschäftslogik eingewoben. Ein kompletter Umstieg auf eine moderne Sprache wäre wie ein Triebwerkswechsel im Flugzeug – theoretisch möglich, praktisch lebensgefährlich.

SAP setzt daher auf eine Zweiteilung: ABAP bleibt der Kern für transaktionale und rechenintensive Prozesse. Neue Fiori-Oberflächen werden in JavaScript/UI5 geschrieben, kommunizieren aber über OData-Services mit ABAP im Hintergrund. Die Zukunft heißt „Clean Core“ – so wenig Eigenentwicklung wie möglich, so viele Standard-APIs wie möglich.

V. Das Einführungsprojekt – Eine Reise durch die Hölle (und zurück)

Ein SAP-Einführungsprojekt ist kein IT-Projekt. Es ist ein Organisationsprojekt mit IT-Mitteln. Die Standardmethode heißt SAP Activate (Nachfolger von ASAP). Sie gliedert sich in sechs Phasen:

Besonders die Gap-Analyse ist entscheidend: Was kann SAP standardmäßig? Wo klafft eine Lücke zwischen Soll-Prozess und SAP-Funktionalität? Jede Lücke muss entweder durch Customizing, Entwicklung oder Prozessänderung geschlossen werden. Die teuerste Lücke ist die, die erst nach Go-Live entdeckt wird.

Ein moderner Trend: Statt monatelanger Blueprints setzen agile Methoden auf FIT-TO-STANDARD-Workshops. SAP zeigt seine Best Practices, das Unternehmen entscheidet, welche es übernimmt. Ziel ist minimale Abweichung – weniger Customizing, weniger Schmerz bei Upgrades.

VI. Public Cloud vs. Private Cloud – Der große Cloud-Zwist

Seit 2015 vermarktet SAP S/4HANA in drei Betriebsmodellen: On-Premise (klassisch), Private Cloud und Public Cloud. Für Kunden ist die Wahl strategisch. Hier die entscheidenden Unterschiede:

Öffentliche Cloud (Public Edition, früher „GROW“)

• Multi-Tenant: Mehrere Kunden teilen sich eine Systeminstanz, logisch getrennt.
• Keine ABAP-Entwicklung im Kern – Erweiterungen nur über SAP Business Technology Platform (BTP).
• Automatische Updates alle drei Monate, verpflichtend.
• Niedrige Einstiegskosten (Subscription pro Nutzer).
• Zielgruppe: Mittelstand, Standardprozesse, Neukunden.

Private Cloud (Private Edition, früher „RISE“)

• Single-Tenant: Dedizierte Instanz nur für einen Kunden.
• Volle ABAP-Freiheit – eigenes Customizing, Modifikationen, Add-ons.
• Kunde steuert Updates (meist 1–2 Mal pro Jahr).
• Höhere Fixkosten, aber besser planbar.
• Zielgruppe: Große Konzerne, Bestandskunden mit ECC-Migration, stark regulierte Branchen.

Die Zwickmühle für Bestandskunden

Wer seit Jahren ein individuell customiztes ECC-System betreibt, kann nicht einfach in die Public Cloud wechseln – dort wäre die halbe Funktionalität verloren. Also bleibt nur die Private Cloud (RISE with SAP) oder On-Premise. SAP drückt hier bewusst aufs Tempo: Der Wartungsstopp für ECC ist angekündigt (2027 für erweiterten Support, 2030 endgültig). Die Migration ist teuer, oft zweistellige Millionenbeträge.

Gleichzeitig lockt Public Cloud mit geringerem Aufwand. Ein Neukunde kann in wenigen Wochen live gehen. Die Kehrseite: Wer später spezielle Prozesse braucht, stößt an Grenzen. Einmal in der Public Cloud, ist ein Wechsel in die Private Cloud kaum möglich – es wäre eine Neuimplementierung.

VII. Kontroversen und offene Flanken

Kein Artikel über SAP wäre vollständig ohne kritische Würdigung der Dauerbrenner-Kontroversen:

1. Die Kostenfalle

SAP-Lizenzen sind teuer. Hinzu kommen Beraterhonorare (1.000–2.000 € pro Tag), Hardware (bei On-Premise) und versteckte Kosten für Schnittstellen, Zertifizierungen und Schulungen. Mittelständische Projekte sprengen regelmäßig das Budget. SAP reagiert mit transparenteren Cloud-Abos, aber die Gesamtkosten bleiben hoch.

2. Die Berater-Abhängigkeit

Gute SAP-Berater sind rar und teuer. Unternehmen ohne internes SAP-Know-how werden von externen Dienstleistern abhängig. Das führt zu endlosen Folgeprojekten, weil der ursprüngliche Berater sein eigenes Customizing nur schwer an andere übergibt.

3. Benutzerfeindlichkeit (historisch)

Die klassische SAP-GUI mit ihren tausenden Transaktionscodes (VA01, FB50, MM02) ist eine Zumutung für Gelegenheitsnutzer. SAP hat mit Fiori eine moderne, app-ähnliche Oberfläche geschaffen – aber viele Bestandskunden haben sie nicht eingeführt, weil der Aufwand zu hoch schien. So sitzt die Belegschaft weiter vor grün-grauen Masken aus den 1990ern.

4. Vendor Lock-In

Wer SAP einführt, verlässt es nie wieder. Die Daten sind tief in proprietären Tabellenstrukturen vergraben. Eine Abkehr ist teurer als eine weitere Migration. Das ist aus Sicht des Herstellers kluge Strategie, aus Kundensicht eine riskante Ehe.

VIII. Ausblick: Was kommt nach SAP?

Die Zukunft von SAP steht unter zwei Vorzeichen: Clean Core und KI.

Clean Core bedeutet, dass Kunden so wenig wie möglich am Kern der Software ändern sollen. Stattdessen werden Erweiterungen ausgelagert – in die Business Technology Platform (BTP), wo sie in JavaScript, Python oder Java laufen. Der Kern bleibt update-fähig. Das ist ein radikaler Bruch mit der alten „Customizing-um-jeden-Preis“-Mentalität.

Künstliche Intelligenz wird tief integriert. Schon heute gibt es Funktionen zur automatischen Rechnungserkennung, Predictive Maintenance und KI-gestützten Disposition. Der Assistent Joule (ein Chatbot) soll natürliche Spracheingaben verstehen und Transaktionen ausführen. Ob das den Ruf der Komplexität auflöst, ist fraglich – aber ein Versuch.

Parallel wachsen alternative ERP-Anbieter: Microsoft Dynamics 365 punktet mit Office-Integration, Oracle mit starker Datenbank, Odoo mit Open-Source-Flexibilität. Keiner erreicht die Branchentiefe von SAP, aber für den Mittelstand sind sie ernsthafte Alternativen.

SAP selbst bleibt das Rückgrat der Weltwirtschaft – alternd, schwerfällig, aber unverzichtbar. Die nächsten fünf Jahre werden zeigen, ob der Konzern die Kurve zur agilen Cloud-Welt schafft oder an seiner eigenen Geschichte zerbricht.

Fazit

SAP ist mehr als Software. Es ist ein Stück deutsche Wirtschaftsgeschichte, ein Lehrstück über Standardisierung und ein Mahnmal für die Schattenseiten der Digitalisierung. Das Unternehmen hat die Art, wie Unternehmen arbeiten, revolutioniert – und gleichzeitig Generationen von Beratern und Entwicklern in den Wahnsinn getrieben. Die Cloud-Migration ist die bisher größte Bewährungsprobe. Gelingt sie, wird SAP weiter dominieren. Scheitert sie, wird der Niedergang langsam, aber unaufhaltsam sein.

Für den Anwender bleibt die goldene Regel: Weniger Customizing ist mehr. Jede Abweichung vom Standard ist eine Hypothek für die Zukunft.

Quellen

• SAP SE: Geschäftsbericht 2024, Walldorf.
• Plattner, Hasso: Vom Urmeter zum Euro – Die Geschichte von SAP, München 2018 (erweiterte Neuauflage).
• Meier, Gerd: Die Pioniere – Wie SAP die Welt der Software veränderte, Frankfurt 2020.
• Handelsblatt: SAP unter Klein – Der schwierige Weg in die Cloud, Serie 2023–2025.
• Computerwoche: *Dossier SAP S/4HANA Migration*, aktualisiert März 2026.
• Gartner Inc.: Market Share Analysis: ERP Software, Stamford 2025.
• SAP Community: ABAP Programming Guidelines, online (2025).
• Biehler, Jürgen: ERP in der Praxis – Erfolgsfaktoren und Fallstricke, 4. Auflage, Wiesbaden 2024.