Die globale Unternehmenslandschaft steht vor einer der bedeutendsten technologischen Zäsuren der letzten Jahrzehnte. Mit der Ankündigung der SAP, die Standardwartung für das Kernprodukt SAP ECC 6.0 am 31. Dezember 2027 zu beenden, hat ein Wettlauf gegen die Zeit begonnen. Während Unternehmen bis Ende 2030 eine verlängerte Wartungsoption gegen Aufpreis in Anspruch nehmen können, ist der strategische Imperativ klar: Der Wechsel auf SAP S/4HANA ist nicht länger eine Option, sondern eine fundamentale Voraussetzung für die Zukunftsfähigkeit in einer datengetriebenen Welt. Diese Transformation markiert den Übergang von einem transaktionalen System zu einem intelligenten digitalen Kern. Dieser ermöglicht Echtzeit-Analysen, KI-gestützte Automatisierung und eine radikale Vereinfachung der Datenstrukturen.
Strategische Einordnung des Greenfield-Ansatzes
Die Wahl der richtigen Transformationsstrategie ist die erste und folgenreichste Entscheidung in jedem S/4HANA-Projekt. Während der Brownfield-Ansatz das bestehende System technisch konvertiert und Prozesse sowie Datenbestände weitgehend erhält, implementiert der Greenfield-Ansatz das System radikal neu. Diese Strategie ist insbesondere für Unternehmen attraktiv, deren aktuelle ERP-Landschaft durch jahrzehntelange Individualisierungen, ineffiziente Prozesse und mangelhafte Datenqualität belastet ist.
Das neue Datenmodell: Der Geschäftspartner als zentraler Anker
SAP hat in S/4HANA das traditionelle Datenmodell für Stammdaten grundlegend vereinfacht. Der Geschäftspartner (GP) ist nun das einzige Objekt für die Verwaltung von Debitoren und Kreditoren. Dieses Konzept ist nicht völlig neu, es wurde bereits in Lösungen wie SAP CRM oder SAP SRM verwendet, ist aber in S/4HANA nun zwingend für den digitalen Kern vorgeschrieben.
Dabei ist die Customer Vendor Integration (CVI) das technologische Herzstück, das die Synchronisation zwischen dem Geschäftspartner-Objekt und den im Hintergrund weiterhin benötigten Debitoren- und Kreditorenstammsätzen sicherstellt. In S/4HANA behält das System die alten Tabellen (wie KNA1 für Kunden und LFA1 für Lieferanten) aus Gründen der Kompatibilität mit nachgelagerten Prozessen und Berichten weiterhin bei, pflegt sie jedoch nicht mehr direkt. In einem anderen Blogbeitrag können Sie hier mehr darüber erfahren
Der GP fungiert als „Single Point of Entry“. Jede Anlage oder Änderung eines Geschäftskontakts erfolgt über die Transaktion „BP“ oder entsprechende Fiori-Apps. Sobald jemand einen Geschäftspartner speichert, synchronisiert die CVI-Komponente die entsprechenden Daten redundanzfrei in die Debitoren- oder Kreditorentabellen.
Die Einführung des Geschäftspartners löst ein fundamentales Problem der alten ECC-Welt: Die mangelnde Verknüpfung zwischen Kunden und Lieferanten. In vielen globalen Handelsbeziehungen agiert ein Partner gleichzeitig als Käufer und Verkäufer. Im ECC-System erforderte dies die Anlage zwei separater Stammsätze, deren manuelle Verknüpfung oft mühsam war, um beispielsweise ein Netting offener Posten zu ermöglichen. Mehr dazu können Sie hier lesen.
Der Business Partner ermöglicht eine ganzheitliche Sicht auf die Identität. Ein einziger GP-Stammsatz (identifiziert durch eine eindeutige GUID) kann mehrere Rollen einnehmen. Diese Rollen fungieren wiederum als Datenhaltungssichten. So existieren Rollen für Basisdaten wie Name oder Adresse, Rollen für Finanzdaten, für Vertriebs- und Einkaufsdaten.
Diese modulare Rollenarchitektur erhöht die Datenintegrität massiv. Änderungen an der zentralen Adresse wirken sich sofort auf alle Rollen aus, wodurch Inkonsistenzen zwischen Einkaufs- und Verkaufsabteilungen vermieden werden.
Die Lösung: Moderne Datenmigration mit dem Staging-Table-Ansatz
Im Greenfield-Szenario ist das SAP S/4HANA Migration Cockpit (Fiori-App „Migrate Your Data“) das maßgebliche Werkzeug für die Datenübernahme. In aktuellen Software-Releases hat SAP die ehemals getrennten Ansätze (File-basiert vs. Staging-basiert) technologisch vereinheitlicht. Heute agieren Staging-Tabellen als zentraler, temporärer Puffer im SAP S/4HANA-Schema, unabhängig von der Art der Datenanlieferung. Lesen Sie mehr zum Mirgration Cockpit hier.
Der Prozess mit der zuvor genannten App folgt einer klaren Struktur, bei der die Staging-Tabellen als Dreh- und Angelpunkt für die Datenvalidierung dienen:
- Projektanlage: Es wird ein Migrationsprojekt erstellt.
- Bereitstellung (Staging): Die Staging-Tabellen werden automatisch vom System generiert. Sie können nun auf zwei Wegen befüllt werden:
- Template-Upload (XML/CSV): Anwender:innen füllen die von SAP bereitgestellten Excel- oder CSV-Vorlagen aus. Beim Hochladen werden die Daten automatisch in die entsprechenden Staging-Tabellen transferiert.
- Direktbefüllung (ETL): Über SAP Data Services oder Drittanbieter-Tools werden die Tabellen direkt auf Datenbankebene (HANA) bespielt, was besonders bei Massendaten effizient ist.
- Vorbereitung & Mapping: Das System bereitet die Daten in den Staging-Tabellen vor. Hier erfolgt das Mapping von Altwerten auf S/4HANA-Strukturen (z. B. Kontengruppen auf GP-Gruppierungen).
- Simulation: Die Daten werden gegen die Ziel-APIs geprüft. Fehlerhafte Datensätze können direkt identifiziert und in den Staging-Tabellen oder via Korrekturdatei behoben werden.
- Migration: Erst nach erfolgreicher Simulation werden die Daten aus den Staging-Tabellen final in die S/4HANA-Applikationstabellen gebucht.
Durch die Nutzung von Staging-Tabellen als Zwischenschicht profitiert die Migration von einer deutlich höheren Stabilität und Transparenz. Da die Daten bereits im HANA-Schema liegen, kann man komplexe Konsistenzprüfungen und Simulationen performant durchführen, bevor man das produktive System verändert. Zudem ermöglicht dieser Ansatz eine einfache Korrektur: Schlägt eine Instanz fehl, muss man nur diesen spezifischen Datensatz in der Staging-Tabelle anpassen und erneut prozessieren.
Lessons Learned: Stolpersteine in der Praxis
Die Migration von Geschäftspartnern ist ein hochkomplexes Unterfangen, das weit über den bloßen technischen Import hinausgeht. In der Praxis haben sich drei bis vier typische Stolpersteine herauskristallisiert, die über Erfolg oder Misserfolg entscheiden können.
Stolperstein 1: Die Harmonisierung der Nummernkreise
Im Greenfield-Szenario stellt sich die Frage: Sollen die alten Nummern erhalten bleiben oder wird ein völlig neues Nummernschema eingeführt? Die „Selbe Nummern“-Logik ist bei Fachabteilungen beliebt, birgt aber technische Tücken. Wenn die Nummern für Debitoren und Kreditoren in der Vergangenheit überlappten (z. B. Kunde 1000 und Lieferant 1000 existierten parallel als unterschiedliche Einheiten), kann in S/4HANA nur einer von beiden die Nummer 1000 als Geschäftspartnernummer erhalten. In solchen Fällen ist eine sorgfältige Analyse der Nummernkreisintervalle (Transaktionen XDN1 für Kunden, XKN1 für Lieferanten) im Quellsystem zwingend erforderlich.
Best Practice: Es empfiehlt sich, für den GP-Nummernkreis eine interne Vergabe zu wählen. Die Debitoren- und Kreditorennummern setzt man über die CVI-Konfiguration auf ‚extern‘, um die GP-Nummer zu übernehmen. Dies stellt sicher, dass GP-Nummer und Debitoren- sowie Kreditorennummern identisch bleiben, solange keine Konflikte vorliegen. An dieser Stelle sei allerdings darauf hingewiesen, dass am Ende weiterhin mit den Kreditoren- und Debitorennummern gearbeitet wird. Man kann Kreditor und Debitor zu einem Geschäftspartner zusammenführen und dabei beispielsweise die Debitorennummer übernehmen. Der einzige Vorteil dabei: Man muss bei Eingabe der Nummer im Beleg auf Kundenseite nicht mehr viel überlegen. Auf der Lieferantenseite verwendet das System weiterhin die abweichende Lieferantennummer.
Stolperstein 2: Mapping-Fehler
Die CVI-Konfiguration erfordert eine präzise Zuordnung jeder ECC-Kontengruppe zu einer entsprechenden GP-Gruppierung in S/4HANA. Ein häufiger Fehler ist ein zu komplexes Mapping-Szenario, das versucht, veraltete Kontengruppen-Strukturen 1:1 abzubilden. Dies widerspricht dem Greenfield-Gedanken der Prozessvereinfachung. Es sollte darauf geachtet werden, dass die GP-Gruppierung primär die Nummernvergabe bestimmt. Eine Überfrachtung mit zu vielen Gruppierungen erhöht die Wartungskomplexität und behindert die Standardisierung.
Stolperstein 3: Unterschätzte Datenqualität der Quellsysteme
„Garbage in, Garbage out“ gilt besonders für S/4HANA. Die Validierungsprüfungen im neuen System sind deutlich strenger als im alten ECC. Typische Fehlerquellen sind:
- Inkonsistente Adressdaten: Fehlende Pflichtfelder wie Postleitzahlen oder ungültige Länderkürzel blockieren den gesamten GP-Import.
- Bankverbindungen: Veraltete IBAN-Strukturen oder unvollständige Bankstammdaten führen zu Simulationsfehlern.
- Steuernummern: S/4HANA validiert Steuernummern oft gegen Länderschemata, was bei ungepflegten Altdaten zu massiven Nacharbeiten führt.
Eine frühzeitige Datenbereinigung und Archivierung nicht mehr benötigter Stammdaten vor dem Migrationsstart sind daher keine optionalen Aufgaben, sondern kritische Pfad-Elemente.
Technische Validierung und Tooling-Einsatz
Über das Migration Cockpit hinaus sollten spezialisierte Analyse-Tools wie der SAP Readiness Check frühzeitig eingesetzt werden. Dieses Tool identifiziert nicht nur technische Inkompatibilitäten von Custom-Code, sondern gibt auch Aufschluss über die notwendigen Simplification Items im Bereich der Stammdaten.
Für komplexe Transformationen, bei denen man Daten aus mehreren Legacy-Systemen (SAP und Non-SAP) konsolidieren muss, reicht das Migration Cockpit allein oft nicht aus. Hier kommen Lösungen wie SAP Data Services oder Natuvion DCS zum Einsatz, die fortgeschrittene Transformationen, Dublettenprüfung (Fuzzy-Logik) und Datenanreicherungen ermöglichen.
Fazit und Ausblick
Der Wechsel auf SAP S/4HANA ist weit mehr als ein IT-Projekt. Es ist eine geschäftskritische Transformation, die das Fundament für die nächsten zwei Jahrzehnte legt. Die Migration der Geschäftspartner bildet dabei das Rückgrat des neuen Systems. Ein Greenfield-Ansatz bietet die einmalige Gelegenheit, dieses Rückgrat geradezurücken und von einer sauberen, standardisierten Datenbasis zu profitieren.
Zusammenfassend lassen sich drei Säulen für eine erfolgreiche GP-Migration identifizieren:
- Ganzheitliche Planung: Die Definition der Nummernkreislogik und des GP-Rollenmodells muss vor der technischen Umsetzung abgeschlossen sein, um teure Kurskorrekturen während der Implementierung zu vermeiden.
- Fokus auf Datenqualität: Die Investition in Datenbereinigung zahlt sich mehrfach aus – durch reibungslose Migrationsläufe, höhere Nutzerakzeptanz und die Fähigkeit, fortschrittliche Technologien wie Machine Learning effektiv zu nutzen.
- Change-Management: Die Umstellung vom gewohnten Debitoren-/Kreditorendenken hin zum Business-Partner-Konzept erfordert eine intensive Begleitung der Anwender:innen. Das Verständnis für das neue Rollenmodell ist essenziell für die tägliche Arbeit in Fiori.
Die Migration zum Geschäftspartner ist das Fundament für Ihre Prozesse in SAP S/4HANA – und genau hier trennt sich die Spreu vom Weizen. Bei adesso business consulting verstehen wir den Geschäftspartner nicht nur als technisches Feld, sondern als Herzstück Ihrer digitalen Transformation. Unser Team blickt auf zahlreiche erfolgreich begleitete Greenfield-Projekte zurück. Lassen Sie uns gemeinsam sicherstellen, dass Ihr Greenfield-Start hält, was er verspricht: eine saubere, standardisierte Datenbasis für Ihren zukünftigen Geschäftserfolg.
