Einheitliches Reporting für ECC und S/4HANA in SAP Datasphere

Warum ist hybrides ECC- und S/4HANA-Reporting in SAP Datasphere relevant? Bei einer unternehmensweiten Umstellung auf SAP S/4HANA migrieren global aufgestellte Unternehmen nur selten alle Geschäftsbereiche, Funktionsbereiche oder Regionen gleichzeitig. Solche schrittweisen Rollouts führen zu langen Übergangsphasen, in denen operative und historische Daten parallel in den bestehenden SAP-ECC-Instanzen und im neuen digitalen Kern von S/4HANA vorgehalten werden müssen.

Um ein unterbrechungsfreies globales Reporting und Transparenz für das Management aufrechtzuerhalten, müssen diese unterschiedlichen Umgebungen in einem einheitlichen analytischen Layer konsolidiert werden. Die Kombination von Legacy-ECC-Tabellen (etwa BSEG, BKPF oder VBAK) mit modernen S/4HANA Core Data Services (CDS) Views bringt jedoch erhebliche Herausforderungen mit sich. S/4HANA-CDS-Views abstrahieren die zugrunde liegenden Datenstrukturen und enthalten häufig komplexe, mehrschichtige Berechnungslogik sowie reichhaltigere Metadaten als ihre Legacy-Pendants.

Um diese strukturellen und semantischen Diskrepanzen zu überwinden, können Unternehmen innerhalb von SAP Datasphere eine strukturierte, mehrschichtige Datenarchitektur implementieren. Dieser Ansatz bietet ein skalierbares Framework, das Datenintegrität, durchgängige Gültigkeit des Reportings und minimale Unterbrechungen über den gesamten Migrationszyklus hinweg sicherstellt.

SAP Datasphere Architekturüberblick: Inbound, Harmonization und Propagation Layer

Um diese architektonischen Unterschiede aufzulösen, trennen wir die Aufnahme der Rohdaten, die Transformationslogik und die Nutzung im Reporting in dedizierte, voneinander entkoppelte Layer. Eine saubere Trennung der Zuständigkeiten (Separation of Concerns) stellt sicher, dass Änderungen in den Quellsystemen keine Kettenreaktion von Fehlern in der gesamten Reporting-Landschaft auslösen.

Die empfohlene SAP-Datasphere-Architektur besteht aus mindestens drei Layern: Inbound, Propagation und Reporting. Für diesen Anwendungsfall ist ein zusätzlicher Layer - Harmonization - erforderlich.

Werfen wir einen genaueren Blick auf die drei Layer, die angesichts dieser Herausforderung der Datenvereinheitlichung einer näheren Erläuterung bedürfen:

Identifikation des Quellsystems

Eine grundlegende Anforderung an eine Multi-Source-Architektur ist das explizite Einfügen einer Quellsystem-Kennung, idealerweise unmittelbar zum Zeitpunkt der Datenaufnahme. Mithilfe von SAP Datasphere Replication Flows befüllen wir für jeden im Inbound Layer gelandeten Datensatz ein technisches Feld namens SRC_SYS_ID (z. B. „SAPECC“ oder „SAPS4“).

Dieses Feld fungiert als Diskriminator über die gesamte Datenpipeline hinweg. Es ermöglicht eine präzise Filterung, unterstützt das Auditing der Datenherkunft (Lineage) und verhindert systemübergreifende Datenkollisionen in nachgelagerten Modellen, in denen sich Geschäftsschlüssel andernfalls überschneiden könnten.

Sehen Sie sich die Aufzeichnung unseres Webinars an: "Bridging Business and Analytics: The Plug-and-Play Future of Data Platforms"

Entwurf des Harmonization Layer für ECC-Daten

Da S/4HANA-Daten bereits gemäß der modernen CDS-Geschäftssemantik strukturiert im Inbound Layer eintreffen, dienen sie als Blaupause für unseren Designstandard. ECC-Daten treffen nicht in demselben standardisierten und angereicherten Datenmodell ein, sondern in einer eher rohen Form.

Der Harmonization Layer (HL) konzentriert sich ausschließlich darauf, Legacy-ECC-Daten so zu transformieren, dass sie diesem S/4HANA-Zielstandard entsprechen. Zwar unterstützt SAP Datasphere Graphical Views, doch ist hier der Einsatz von SQLScript Views aufgrund der enormen Flexibilität und der komplexen Skripting-Möglichkeiten klar zu bevorzugen.

Innerhalb des HL sind drei Kernbereiche zu adressieren:

• Strukturelle Angleichung: Legacy-ECC-Felder müssen explizit gemappt, umbenannt und typisiert werden, sodass sie die entsprechenden Felder der S/4HANA-CDS-Views exakt abbilden.

• Semantische Abstimmung: Mit S/4HANA wurden grundlegende architektonische Konsolidierungen eingeführt, allen voran das Universal Journal (ACDOCA). Der HL muss komplexe Joins, Filter und berechnete Felder nutzen, um diese modernen Geschäftsregeln auf Basis der zugrunde liegenden Legacy-ECC-Tabellen nachzubilden (z. B. durch Kombination von BKPF, BSEG und CO-Nebenbüchern).

• Modularer Aufbau: Um Skalierbarkeit zu gewährleisten, sollte die Transformationslogik in wiederverwendbare Graphical oder SQL Views zerlegt werden. Die Zentralisierung der Kernlogik vermeidet Code-Duplizierung und vereinfacht die spätere Wartung.

Im unten gezeigten Beispiel werden die ECC-Tabellen LIKP und VBUK in einer View des HL Layer verwendet, um die Struktur der CDS-View I_DeliveryDocument aus S/4 nachzubilden.

Aufbau eines einheitlichen Propagation Layer mithilfe von UNION-Logik

Sobald die Legacy-ECC-Daten innerhalb des HL strukturell angeglichen sind, weisen sie ein identisches Schema mit den nativen S/4HANA-Daten aus dem Inbound Layer auf. Im Propagation Layer (PL) werden diese beiden Datenströme zusammengeführt.

Da die zugrunde liegenden Schemata nun vollständig identisch sind, kann eine UNION-ALL-Operation die Datensätze gefahrlos konsolidieren. Die S/4HANA-Daten gelangen direkt vom Inbound Layer zum UNION-Knoten, ohne dass zwischengeschaltete strukturelle Transformationen erforderlich sind, was den Verarbeitungsaufwand minimiert.

Als Beispiel würde der relevante Auszug aus der View des Delivery Document Propagation Layer wie folgt aussehen:

lt_deliverydocument =
SELECT
    "s4"."DeliveryDocument",
    "s4"."DeliveryDocumentType",
 -- ... [Weitere Felder] ...
    "s4"."SRC_SYS_ID",
    "s4"."UPDATE_DTTM"
FROM "SD_IL_S4_IDELIVERYDOCUMENT" AS "s4"
UNION ALL
SELECT
    "ecc"."DeliveryDocument",
    "ecc"."DeliveryDocumentType",
 -- ... [Weitere Felder] ...
    "ecc"."SRC_SYS_ID",
    "ecc"."UPDATE_DTTM"
FROM "ECC_HL_DELIVERYDOCUMENT" AS "ecc";

Nach dem Erstellen dieser Zusammenführung der beiden Quellsystem-Datensätze kann die eigentliche Logik des Haupt-PL-Layers angewendet werden. Beispielsweise werden die lokalen Tabellen für Lieferkopf und -position über ihre jeweiligen Schlüssel sowie das Feld SRC_SYS_ID verknüpft (joined).

Dynamische Flexibilität der Pipeline

Ein wesentlicher Vorteil dieses Designs ist seine Anpassungsfähigkeit an sich ändernde Projektanforderungen. Da die Datenströme innerhalb eines SQLScript-Modells sauber voneinander getrennt sind, lässt sich der gesamte ECC-Datenstrom sofort auskommentieren oder isolieren, falls eine Geschäftseinheit vorzeitig migriert oder sich der Reporting-Umfang ändert. Diese Anpassung erfordert keine strukturellen Änderungen (Code/Metadaten) an nachgelagerten Views, Analytic Models oder SAP-Analytics-Cloud (SAC) Dashboards.

Durch das Auskommentieren des ECC-Teils in der View des PL Layer werden die Daten aus dem markierten Abschnitt entfernt, ohne das Schema der PL-View zu beeinträchtigen.

Verwaltung von Associations zwischen Fakten und Stammdaten

Die Konsolidierung von Transaktionsdaten über unterschiedliche Systeme hinweg birgt erhebliche Risiken bei der Verwaltung von Stammdatenbeziehungen. In Multi-Source-Landschaften überschneiden sich Geschäftsidentifikatoren häufig. So kann etwa die Kunden-ID 100045 oder die Material-ID MAT-99 im Legacy-ECC-System eine bestimmte Entität bezeichnen und im neuen S/4HANA-Tenant eine völlig andere, nicht damit zusammenhängende Entität.

Um eine fehlerhafte systemübergreifende Datenzuordnung zu verhindern, müssen Modelle quellensensitive Associations implementieren. Jede Association zwischen einer Fact View und einer Master-Data-Dimension-View innerhalb des Propagation Layer muss einen zusammengesetzten Schlüssel aus dem eindeutigen Geschäftsidentifikator und der SRC_SYS_ID verwenden.

Dieser Ansatz garantiert eine absolute Datenisolierung. Ein ECC-Transaktionsdatensatz wird ausschließlich mit seinen zugehörigen ECC-Stammdatenattributen verknüpft, während ein S/4HANA-Datensatz direkt an die S/4HANA-Stammdatenattribute gebunden bleibt.

Betriebskontinuität während der SAP-S/4HANA-Migration sicherstellen

Über die technische Angleichung hinaus liefert diese Architektur langfristige Betriebskontinuität in allen Phasen der S/4HANA-Transformation: davor, währenddessen und danach.

Wenn eine regionale Migration abgeschlossen ist, müssen Sie weder Ihre zentrale Anwendungslogik noch Ihre Reporting-Views umbauen. Die Daten werden schlicht nicht mehr aus der Legacy-ECC-Instanz aktualisiert und fließen fortan nativ über den S/4HANA-Pfad. Die historischen ECC-Daten bleiben innerhalb des Modells als unveränderliches analytisches Archiv für mehrjährige Vergleichsauswertungen zugänglich.

Betriebliche Erweiterung: Filterung über eine Control Table

Um maximale Agilität zu erreichen, können Sie die Logik um einen Lookup auf eine zentrale Konfigurations- bzw. Control Table erweitern. Dadurch können Data Engineers die Ausführung von Legacy-ECC-Daten je nach aktiver Migrationswelle dynamisch herausfiltern oder umschalten – allein durch Aktualisieren eines Statuswerts in der Control Table, anstatt Code zu ändern (auszukommentieren).

Implementierung eines einheitlichen Reporting-Modells für ECC und S/4HANA in SAP Datasphere: Unser Fazit

Die erfolgreiche Umsetzung eines unternehmensweiten Reportings während einer SAP-S/4HANA-Transformation erfordert weit mehr als die bloße Anbindung unterschiedlicher Datenquellen. Gefragt ist eine skalierbare Architektur, die strukturelle Unterschiede harmonisiert, die fachliche Semantik bewahrt und unabhängig vom Ursprung der Daten eine konsistente Analyse- und Reportingbasis schafft.

Durch den Einsatz dedizierter Inbound-, Harmonization- und Propagation-Layer in SAP Datasphere können Unternehmen ein einheitliches Reporting-Modell etablieren, das während des gesamten Migrationsprozesses stabil bleibt. Dieser mehrschichtige Ansatz minimiert nicht nur Unterbrechungen bei schrittweisen Rollouts, sondern vereinfacht auch die langfristige Wartung, verbessert die Data Governance und ermöglicht eine nahtlose gemeinsame Nutzung historischer und operativer Daten.

Aus unseren Projekten haben sich insbesondere folgende Best Practices als entscheidend für eine erfolgreiche Implementierung erwiesen:

• Strenge Namenskonventionen durchsetzen: Verwenden Sie standardisierte Präfixe für SAP-Datasphere-Spaces und -Objekte, um Wartbarkeit, Transparenz und die Zusammenarbeit zwischen Entwicklungsteams zu verbessern.

• SRC_SYS_ID frühzeitig einbetten: Fügen Sie die Quellsystem-Kennung bereits bei der Datenreplikation beziehungsweise der initialen Rohdatenaufnahme hinzu. So stellen Sie eine eindeutige Datenherkunft sicher, vermeiden Schlüsselkollisionen und ermöglichen zuverlässige systemübergreifende Associations.

• Transformationslogik modular gestalten: Wiederverwendbare Harmonization Views reduzieren Redundanzen, erleichtern die Wartung und erhöhen die Skalierbarkeit Ihrer Datenmodelle.

• Auf zukünftige Erweiterbarkeit auslegen: Ein sauber strukturierter Harmonization Layer ermöglicht es, künftig weitere SAP- oder auch Nicht-SAP-ERP-Systeme in die bestehende Reporting-Landschaft zu integrieren, ohne nachgelagerte Reporting-Modelle neu entwickeln zu müssen.

• Fachliche Logik von quellspezifischer Logik trennen: Dadurch bleiben Reporting-Modelle und SAP-Analytics-Cloud-Dashboards stabil, selbst wenn sich Quellsysteme ändern oder Legacy-Systeme schrittweise außer Betrieb genommen werden.

Insgesamt schafft diese Architektur eine zukunftssichere Grundlage für ein unternehmensweites Reporting. Sie unterstützt hybride ERP-Landschaften während der gesamten Transformationsphase und ebnet gleichzeitig den Weg für den langfristigen Betrieb einer vollständig modernen SAP-Systemlandschaft.

Sprechen Sie mit unseren Experten über Ihre Transformationsziele und erfahren Sie, wie wir Sie beim Aufbau einer einheitlichen, zukunftssicheren Reporting- und Analytics-Landschaft mit SAP Datasphere unterstützen können.