Wenn von SAP S/4HANA die Rede ist, hört man oft dieselben Begriffe: SE16H, BP, WLF_IDOC. Doch diese Transaktionen gibt es – teils je nach Release – auch in ECC. Und selbst vielzitierte Datenstrukturen wie MATDOC bedeuten nicht, dass klassische Tabellen wie MSEG oder MKPF verschwunden wären – sie existieren als Views weiterhin und werden mit Daten befüllt, etwa für Kompatibilität mit BAPIs oder Reports.
Der wahre Unterschied zwischen ECC und S/4HANA liegt nicht an der Oberfläche, sondern im Fundament: Architektur, Datenmodell, Performanceprinzipien und Systemlogik.
1. Der HANA-Zwang – aber nur in S/4HANA systemisch genutzt
S/4HANA läuft ausschließlich auf der SAP HANA-Datenbank – einer spaltenbasierten, In-Memory-Datenbank mit extrem schneller Datenverarbeitung und hoher Komprimierung.
Aber:
Auch ECC kann auf HANA betrieben werden (Suite on HANA). Dabei bleibt das zugrunde liegende Datenmodell unangetastet. Es ist technisch zwar schneller – aber keine funktionale oder strukturelle Modernisierung.
S/4HANA dagegen nutzt HANA nicht nur als Speicher, sondern als Verarbeitungsplattform:
- Viele Tabellen werden ersetzt oder verschmolzen
- Redundanzen entfallen
- Abfragen laufen direkt auf der Datenbank, nicht mehr im ABAP-Stack
→ Nur S/4HANA nutzt HANA vollständig aus – ECC auf HANA bleibt ein Zwischenschritt.
2. Vereinfachtes Datenmodell & Prozesslogik
S/4HANA verfolgt das Ziel, Datenmodelle zu verschlanken und Prozesslogik zu harmonisieren.
Beispiele:
- ACDOCA ersetzt klassische FI-/CO-/AA-Tabellen wie BSEG, COEP, ANEP usw.
- MATDOC dient als zentrales Datenobjekt für Materialbewegungen. MSEG/MKPF sind in vielen Fällen nur noch kompatible Views.
- Business Partner (BP) ersetzt nicht nur Debitoren und Kreditoren, sondern integriert die Pflege dieser Stammdaten in eine einheitliche Logik.
Auch in der Prozesslogik finden tiefgreifende Änderungen statt:
- MRP:
Die klassische Transaktion MD01 ist weiterhin vorhanden. Zusätzlich bietet S/4HANA mit MD01N (MRP Live) eine HANA-basierte Planungslogik:
→ Für geeignete Materialien erfolgt der MRP-Lauf direkt auf Datenbankebene – ohne temporäre Tabellen, schneller, analytisch auswertbar. Beide Varianten existieren parallel, je nach Konfiguration. - Bezugsquellenfindung:
Statt starrer Source Lists kombiniert S/4HANA Einkaufsinfosätze, Verträge und Quellregeln kontextbasiert – oft automatisch während MRP oder BANF-Erstellung.
→ Die Datenmodellverschlankung bedeutet nicht weniger Funktion, sondern weniger technische Komplexität – bei mehr Integration.
3. Code Pushdown: Logik in der Datenbank
Ein zentrales Prinzip in S/4HANA:
„Bring the logic to the data.“
Was in ECC klassisch über ABAP-Schleifen, interne Tabellen und SELECTs lief, wird nun in CDS Views, AMDPs oder HANA Procedures abgebildet.
Vorteile:
- Verarbeitung dort, wo die Daten liegen
- Weniger Datenbewegung
- Deutlich höhere Geschwindigkeit
Eigene PoC-Erfahrung:
In mehreren Projekten ließ sich durch gezielten Pushdown bis zu 50 % Performancegewinn erzielen – ohne Hardwareänderung.
Aber:
Wenn Z-Coding dominiert, mit SELECT-LOOPs, Form-Routinen und unstrukturiertem Altcode, verpufft das Potenzial. Die Plattform kann nur so schnell sein, wie der Code es erlaubt.
4. Auflösung klassischer Modulsilos
S/4HANA durchbricht die Grenzen zwischen Modulen:
- FI & CO fließen im Universal Journal (ACDOCA) zusammen
- Stammdatenlogik wird zentral über BP geregelt
- MM, SD, LE teilen sich harmonisierte Datenstrukturen
- Reporting und Analyse basieren zunehmend auf modulübergreifenden CDS Views
→ Die Trennung in „Modulberater“ und „technische Entwickler“ verschwimmt. Gefragt ist Systemverständnis statt Transaktionswissen.
5. API-zentrierte, Fiori-native Architektur
S/4HANA wird als Digital Core gedacht – nicht nur als Transaktionssystem.
- REST-/OData-APIs sind Standard
- SAPUI5/Fiori ist vom Backend entkoppelt
- Externe Apps, Cloudlösungen und mobile Endgeräte kommunizieren über definierte Schnittstellen
→ Das System ist vorbereitet auf Integrationen, Cloud-Services, BTP-Anbindungen – und eröffnet neue Architekturräume.
Fazit: Architektur nutzen – nicht nur upgraden
S/4HANA ist nicht einfach ein ECC in neuem Gewand. Es ist ein neu konzipiertes ERP – mit anderer Datenhaltung, anderer Denkweise, anderer Performancephilosophie.
Wer nur migriert, aber weiterhin in Z-Coding, alten Modulmauern und transaktionszentriert denkt, wird keine echten Vorteile erleben.
Wer Architektur, Datenmodell und Prozesse neu denkt, wird mit Performance, Stabilität und Zukunftsfähigkeit belohnt.
ECC auf HANA ist ein Zwischenschritt.
S/4HANA ist ein Systemwechsel.