Die Migration auf SAP S/4HANA im Brownfield-Ansatz („System Conversion“) stellt Unternehmen vor eine der komplexesten Herausforderungen ihrer ERP-Geschichte: die zwingende Transformation des historischen Stammdatenbestandes. Im Zentrum dieser Transformation steht die Customer Vendor Integration (CVI) und die Einführung des Geschäftspartners im Hintergrund in einem ECC-System. War der SAP-Geschäftspartner (Business Partner) in der ERP Central Component (ECC) 6.0 Welt oft nur ein optionales Konstrukt für spezielle Module (z. B. SAP-Treasury oder SAP CRM), so avanciert er in S/4HANA zum unumgänglichen, führenden Objekt für alle stammdatenbezogenen Prozesse. Die klassischen Transaktionen und Datenmodelle für Debitoren (FI-AR) und Kreditoren (FI-AP) werden obsolet und technisch durch den BP gekapselt.
Dieser Blogbeitrag bietet eine detaillierte Analyse des CVI-Prozesses, strukturiert entlang des bewährten adesso-Vorgehensmodells (Phasen 0 bis 7). Er richtet sich an Lösungsarchitekten, technische Projektleiter und Stammdatenverantwortliche, die verstehen müssen, dass die CVI keine rein technische Konvertierung ist, sondern ein massives Datenqualitätsprojekt, das den kritischen Pfad der gesamten S/4HANA-Migration diktiert. Das Scheitern der CVI-Synchronisation ist einer der häufigsten Gründe für den Abbruch oder die Verschiebung von S/4HANA-Projekten, da der Software Update Manager (SUM) ohne erfolgreiche CVI den technischen Upgrade-Prozess rigoros blockiert.
Die nachfolgende Analyse beleuchtet nicht nur die offensichtlichen Customizing-Schritte, sondern dringt tief in die Mechanismen der Synchronisation, die Fallstricke der Nummernkreislogik, die Möglichkeiten der BAdI-Erweiterungen und die post-migratorischen Betriebsszenarien ein.
Sie orientiert sich am adesso business consulting Geschäftspartner-Vorgehensmodell:
Phase 0: Discovery
Die Phase 0 markiert den Eintritt in das Migrationsvorhaben. In einer Brownfield-Umgebung ist das Altsystem oft über Jahrzehnte organisch gewachsen. Diese Historie resultiert in einer hohen Varianz an Datenqualität, obsoleten Customizing-Fragmenten und inkonsistenten Geschäftsprozessen. Deshalb dient die Discovery-Phase der fundierten Bestandsaufnahme und der Identifikation von Showstoppern, bevor signifikante Ressourcen investiert werden.
Der erste Schritt jeder S/4HANA-Initiative ist die Durchführung des SAP Readiness Checks. Im spezifischen Kontext der CVI identifiziert dieser Check die relevanten Simplification Items, welche die Diskrepanz zwischen dem ECC-Ist-Zustand und dem S/4HANA-Soll-Zustand aufzeigen. Der Business Partner ist eines der prominentesten und folgenreichsten Simplification Items in S/4HANA (S4TWL – Business Partner Approach (2265093)).
Eine detaillierte Analyse muss u. a. folgende Aspekte klären:
- Kontengruppen-Inventur: Welche Debitoren- und Kreditoren-Kontengruppen sind im Einsatz? Oft finden sich im System Kontengruppen, die vor Jahren für temporäre Zwecke angelegt wurden und deren Nutzung unklar ist. Hier lohnt sich eine detaillierte Analyse, um „Datenmüll“ aufzuräumen, da oft auch Kontengruppen über die Zeit angepasst wurden (z. B. Nummernkreise geändert oder ausgetauscht).
- Industriespezifische Erweiterungen (IS): Werden Branchenlösungen wie IS-U genutzt? Diese Module nutzten oft bereits im ECC den Business Partner, jedoch in einer anderen Konstellation oder Synchronisationsrichtung. Hier drohen massive Konflikte, wenn die bestehende BP-Implementierung nicht mit der neuen CVI-Logik des S/4HANA-Kerns harmoniert.
- Datenvolumen: Wie hoch ist das Volumen der Stammdaten? Die Anzahl der Datensätze (z. B. 50.000 vs. 5 Millionen) hat direkte Auswirkungen auf die Laufzeit der Synchronisation und die Dimensionierung der Hardware für die parallele Verarbeitung.
Unterschied Greenfield und Brownfield
Ein fundamentaler Unterschied zwischen Greenfield- und Brownfield-Ansätzen liegt im Umgang mit Altdaten. Eine Brownfield-Migration impliziert grundsätzlich, dass alle im System vorhandenen Stammdaten technisch konvertiert werden müssen, sofern sie nicht archiviert werden. Es gibt keine Möglichkeit, selektiv nur die „guten“ Daten zu migrieren, da die Datenbanktabellen (KNA1, LFA1) physisch konvertiert werden.
Daher muss in Phase 0 eine klare Trennlinie gezogen werden:
- Aktive Daten: Stammdaten, die in offenen Posten, laufenden Verträgen oder Bestellungen der letzten Geschäftsjahre verwendet wurden. Diese müssen qualitativ hochwertig transformiert werden.
- Inaktive Daten: Stammdaten, die seit Jahren nicht bebucht wurden, aber aus technischen oder rechtlichen Gründen (noch) nicht archiviert wurden. Hier gilt es, Strategien zu entwickeln, wie diese mit minimalem Aufwand durch die „Wall of Conversion“ gebracht werden können, ohne teure Bereinigungsprojekte zu starten.
Die Erfahrung zeigt, dass die Datenqualität der größte Risikofaktor ist und oft fehlt in Brownfield-Projekten die Zeit für ein vollwertiges Archivierungsprojekt, das Monate in Anspruch nehmen kann. Hier muss in Phase 0 eine strategische Entscheidung getroffen werden: Archivierung vs. „Rubbish“-Gruppen.
Das Konzept der „Rubbish“- oder „Sammler“-Account-Gruppen (z. B. Z999) bietet einen pragmatischen Ausweg. Die Strategie sieht vor, alle als obsolet identifizierten Stammsätze in eine spezielle Kontengruppe zu verschieben. Für diese Gruppe werden im späteren CVI-Customizing sämtliche Feldprüfungen (wie Bankdatenvalidierung, Steuer-IDs, PLZ-Checks) via BAdI oder Customizing deaktiviert. Dies erlaubt es, die technische Hürde der CVI zu nehmen, ohne historische Datenmüllhalden aufwendig sanieren zu müssen. Diese Entscheidung muss früh fallen, da sie die Aktivitäten der Phase 1 und 2 massiv beeinflusst.
Phase 1: Datenbereinigung und Archivierung
Nach der Initialanalyse beginnt in Phase 1 die operative Vorbereitung der Datenbasis. Das Credo dieser Phase lautet: „Garbage In, Garbage Out“ vermeiden, da die Datenqualität maßgeblich den Erfolg und die Dauer der späteren Synchronisation bestimmt.
Wie in Phase 0 angedeutet, ist die Reduktion des Datenvolumens der effektivste Weg, CVI-Fehler zu minimieren und die Laufzeit des Upgrades zu verkürzen. Daten, die nicht mehr existieren (weil sie archiviert sind), müssen nicht konvertiert, nicht geprüft und nicht gemappt werden.
Für die verbleibenden aktiven Daten muss eine rigorose Bereinigung erfolgen. Die CVI nutzt die Business Address Services (BAS) des BPs, welche deutlich striktere Validierungsregeln anwenden als die alten Tabellen KNA1/LFA1.
| Qualitätsdimension | Typisches Problem im ECC | Konsequenz in der CVI | Bereinigungsmaßnahme |
| Dubletten | Kreditor X und Debitor X sind dieselbe Firma, aber nicht verknüpft. | Es entstehen zwei separate BPs statt eines integrierten BPs. | Linkage-Analyse und Setzen des Feldes „Debitor“ im Kreditorenstamm (und vice versa). |
| Adressdaten | Veraltete PLZ, fehlende Regionen, falsche Länderformate. | Der CVI-Synchronisationslauf bricht mit Fehlermeldung ab (BAS-Validierung). | Nutzung von Adressvalidierungsdiensten (z.B. SAP Data Quality Management oder CDQ). |
| Steuerdaten | Doppelte oder ungültige USt-ID (VAT ID). | BP erlaubt standardmäßig keine doppelten Steuer-IDs (Eindeutigkeitsprüfung). | Bereinigung der Steuer-IDs oder Anpassung des Message-Controls (Vorsicht bei Compliance!). |
| Bankdaten | Ungültige IBAN-Formate oder Bankleitzahlen. | Synchronisationsfehler. | Validierung gegen Bankverzeichnisse. |
| Anreden | Feld „Anrede“ leer oder unstrukturiert (z.B. „Firma“ im Namensfeld). | BP benötigt zwingend eine Anrede zur Bestimmung des Typs (Person/Organisation). | Mapping-Regeln definieren oder Stammdaten anreichern. |
Der Report CVI_PRECHK (Master Data Consistency Check) ist das wichtigste Werkzeug dieser Phase, weil er die Anlage eines Business Partners basierend auf den aktuellen Debitoren/Kreditoren simuliert und diese gegen die Customizing-Regeln des BPs prüft. Zudem hat adesso business consulting ein eigenes, sogenanntes „Q-Check Tool“ entwickelt, um bei der Datenbereinigung zu unterstützen. Mehr dazu können Sie hier im folgenden Blog-Beitrag nachlesen.
Phase 2: Konzeption
Während die Datenbereinigung läuft, muss in Phase 2 das technische Fundament gelegt werden. Hier werden die betriebswirtschaftlichen Anforderungen in SAP-Konfigurationen übersetzt und Fehler in dieser Phase sind oft irreversibel oder nur mit massivem Aufwand korrigierbar.
Der Business Partner (BP) ist das führende Objekt, das strikt trennt zwischen den allgemeinen Daten (Name, Adresse), die für alle Rollen gelten, und den rollenspezifischen Daten.
Zu definieren sind u. a. die Geschäftspartner-Gruppierungen, die Geschäftspartner-Rollen sowie Pflichtfelder im Geschäftspartner, Anreden, Brachensysteme etc. Dabei ist die Vergabe der Nummernlogiken für den Geschäftspartner eine der komplexesten und diskussionsintensivsten Themen der CVI. Es muss u. a. entschieden werden, welche Kontengruppen mit welchen Geschäftspartner-Gruppierungen verknüpft werden, ob Stammdaten zusammengeführt oder getrennt gehalten werden sollen, oder aber auch welchen Geschäftspartner-Typen (z. B. Person oder Organisation) die Stammdaten erhalten sollen.
Phase 3: Technische Implementierung
In Phase 3 wird das ECC-System technisch „CVI-ready“ gemacht. Dies beinhaltet das Einspielen von Hinweisen, die Aktivierung von Business Functions und die Implementierung von Erweiterungslogiken anhand der Konzeptionierung aus Phase 2.
SAP hat das „CVI-Cockpit“ eingeführt, um die historisch verstreuten Transaktionen und Reports an einem zentralen Ort zu konsolidieren. Hier kann das Customizing zentralisiert an einem Ort ausgeführt werden.
Die Standard-Mapping-Regeln von SAP decken ca. 80-90 % der Anforderungen ab und für die verbleibenden Fälle, insbesondere bei Nutzung von Z-Feldern (Kundeneigene Felder) in KNA1/LFA1, sind Business Add-Ins (BAdIs) notwendig.
Wichtige BAdIs im Kontext der CVI:
- CVI_CUSTOM_MAPPER / CVI_MAP_LEGAL_ENTITY: Dieses BAdI ist der zentrale Einstiegspunkt für kundenspezifische Feldmappings.
- CVI_MAP_TITLE: Dient dem Mapping von Anreden.
- CVI_MAP_BANKDETAILS: Ermöglicht die Steuerung, wie Bankverbindungen übertragen werden.
Für Altdaten, die nicht bereinigt werden können und nicht archiviert wurden (siehe Phase 0), bietet SAP die Möglichkeit, bestimmte Prüfungen temporär auszusetzen, doch diese Funktion ist ein zweischneidiges Schwert. Sie ermöglicht den technischen Durchstich (Conversion), führt aber dazu, dass inkonsistente Daten im S/4HANA landen. Diese können später operative Prozesse blockieren (z. B. Zahlläufe, die abbrechen). Daher wird dringend empfohlen, diese Unterdrückung nur selektiv für die definierten „Rubbish“-Gruppen anzuwenden und nicht global.
Phase 4: Synchronisation und CVI-Ausführung
Dies ist die „heiße Phase“ im ECC-System vor der eigentlichen Konvertierung und das Ziel ist es, zu jedem existierenden Debitor und Kreditor einen Business Partner zu erzeugen sowie die Link-Tabellen zu füllen.
Die Massensynchronisation erfolgt über das Synchronisationscockpit (Transaktion MDS_LOAD_COCKPIT). Dieses Tool orchestriert die Erstellung der BPs.
Trotz aller Vorbereitungen werden Fehler auftreten. Das Post Processing Office (PPO) ist das zentrale Monitoring-Tool hierfür.
Der Arbeitsablauf im PPO ist iterativ: Fehler werden dargestellt und analysiert. Anschließend werden die Stammdaten korrigiert (z. B. über XD02/XK02), oder aber das Customizing wird nachgezogen. Nach der Korrektur muss der Synchronisationslauf für die betroffenen Objekte wiederholt werden. Alternativ kann der PPO-Auftrag direkt im PPO wiederholt werden.
Dieser Zyklus („Fix –> Retry“) kann je nach Datenqualität Wochen in Anspruch nehmen und muss im Projektplan entsprechend berücksichtigt werden.
Neben den klassischen B2B-Partnern müssen oft auch Kontaktpersonen (Ansprechpartner beim Kunden) synchronisiert werden. Diese werden als BPs vom Typ „Person“ angelegt und über eine Beziehung („Ist Ansprechpartner von“) mit dem Organisations-BP verknüpft.
Phase 5: Validierung und Testing
Nachdem das Synchronisationscockpit „grün“ meldet, darf man sich nicht blind darauf verlassen. Deshalb dient Phase 5 der Qualitätssicherung und stellt sicher, dass das System den strengen Kriterien des SUM-Updates standhält.
Es muss sichergestellt werden, dass die Anzahl der Business Partner plausibel ist und mit der Anzahl der Quellobjekte korreliert.
- SQL Checks & Reports: Vergleich der Einträge in KNA1 (Kunden) vs. BUT000 (Business Partner). Hierbei ist zu beachten, dass die Zahlen nicht zwingend identisch sind (z. B. wegen Dublettenzusammenführung), aber erklärbar sein müssen.
- Link-Tabellen: Die Verknüpfung wird in den Tabellen CVI_CUST_LINK (Debitor <-> BP) und CVI_VEND_LINK (Kreditor <-> BP) sowie CVI_CUST_CT_LINK (Kontaktperson) gespeichert. Jeder aktive Debitor muss hier einen Eintrag haben. Lücken in diesen Tabellen sind ein Alarmsignal und weisen auf fehlgeschlagene oder nicht durchgeführte Synchronisationen hin.
Zudem ist die Stichprobenartige Prüfung von komplexen Datenkonstrukten unerlässlich. Dazu zählen unter anderem:
- Partnerrollen: Wurden alle Partnerrollen (Warenempfänger, Rechnungsempfänger, Regulierer) korrekt in die entsprechenden BP-Rollen und Beziehungen übernommen?
- Adressversionen: Sind internationale Adressversionen (z. B. Kanji in Japan, Kyrillisch in Russland) korrekt im BP abgebildet?
- Bankverbindungen: Sind SEPA-Mandate korrekt verknüpft geblieben?
Der Software Update Manager (SUM) führt zu Beginn der Conversion einen harten Check durch (Simplification Item Check). Ist die CVI nicht vollständig (d. h. gibt es Debitoren ohne BP-Link), bricht der SUM ab und verweigert den Start der Downtime.
Phase 6: Konvertierung im Produktivsystem
Wurden die Daten im Qualitätssicherungssystem validiert und die Prozesse getestet, so können die Customizing Einstellungen in das Produktivsystem überführt werden. Anschließend erfolgt die finale Datenkonvertierung.
Phase 7: Post Go-Live Aktivitäten
Da zwischen der Geschäftspartner-Konvertierung und der eigentlichen SAP S/4HANA Umstellung durchaus Zeit vergehen kann, läuft die CVI erstmal nur technisch im Hintergrund. Sobald ein neuer Kunden- oder Lieferantenstammsatz angelegt wird, erzeugt die CVI den Geschäftspartner-Stammsatz. Hier kann es zu Fehlern kommen, die regelmäßig – auch nach Produktivsetzung – im PPO begutachtet und bereinigt werden müssen.
Sobald die Umstellung auf SAP S/4HANA erfolgt ist, sind im Bereich der CVI noch einige Tätigkeiten umzusetzen. Dazu zählen u. a. die Vergabe von Berechtigungen zur Pflege der Geschäftspartner-Stammdaten (GUI und/oder Fiori), der Wechsel der Synchronisationsrichtung (GP –> Kunde/GP –> Lieferant) und auch die Nutzung weiterer Innovationen (z. B. Beziehungsmanagement, Multiple Adressen, SAP S/4HANA Credit Management).
Fazit und Zusammenfassung
Die Customer Vendor Integration (CVI) ist weit mehr als eine technische Fleißaufgabe, sie ist das fundamentale Datenprojekt der S/4HANA-Transformation. Die detaillierte Betrachtung der Phasen 0 bis 7 verdeutlicht, dass der Erfolg nicht am Go-Live-Wochenende entschieden wird, sondern Monate vorher.
Wer hier Abkürzungen nimmt oder das Thema Datenqualität als „IT-Problem“ abtut, zahlt den Preis durch massive Projektverzögerungen, explodierende PPO-Fehlerlisten und inkonsistente Prozesse im neuen System. Der Brownfield-Ansatz zwingt Unternehmen dazu, ihre „technischen Schulden“ im Stammdatenbereich zu begleichen – eine notwendige Investition, um die volle Leistungsfähigkeit von S/4HANA nutzen zu können.
Sie stehen vor der Herausforderung einer S/4HANA Brownfield-Migration und benötigen Unterstützung bei der komplexen Customer Vendor Integration? Die Experten von adesso business consulting begleiten Sie sicher durch alle Phasen – von der Analyse bis zum Go-Live. Kontaktieren Sie uns für eine unverbindliche Erstberatung und profitieren Sie von unserer langjährigen Projekterfahrung in der SAP-Transformation.
