SAP S/4HANA ist eines der am weitesten verbreiteten ERP-Systeme in Unternehmensumgebungen. Gemäß 6sense-Daten von 2026 hält es knapp 10% des globalen ERP-Markts mit über 26.000 erfassten Kunden. Mit wachsender Verbreitung steigt auch die Notwendigkeit, SAP mit anderen Geschäftssystemen zu verbinden – einschließlich PIM.
Was ist SAP-PIM-Integration?
SAP-PIM-Integration ist die Verbindung zwischen einem SAP-ERP-System und einer Product-Information-Management-Plattform. In den meisten Fällen handelt es sich um SAP S/4HANA, obwohl viele Unternehmen noch SAP ECC 6.0 einsetzen und die gleiche Funktionalität benötigen. Die beiden Systeme verfolgen unterschiedliche Zwecke und verwalten unterschiedliche Datentypen.
SAP verwaltet Transaktionsdaten: Materialstammsätze, Preise, Bestände, Beschaffung und Finanzbuchungen. Es ist das operative Kernstück. Ein PIM-System verwaltet Marketing- und Kanalonhalte: Produktbeschreibungen, technische Spezifikationen, digitale Assets, Kategoriestrukturen und kanalspezifische Varianten. Dies sind Produktattribute, deren Verwaltung SAP nie gut beherrscht hat.
Wenn die beiden Systeme integriert sind, bleibt SAP die Autorität für SKUs, Preise und Bestände. Das PIM-System übernimmt die Produktanreicherung mit allem, was für die Veröffentlichung von Produkten auf E-Commerce-Plattformen, SAP Commerce Cloud, Retail-Portalen, Druckkatalogen und digitalen Marktplätzen notwendig ist. Kein System ersetzt das andere. Sie teilen sich die Verantwortung und tauschen Daten bidirektional aus.
Warum SAPs natives Produktdatenmanagement nicht ausreicht
SAP S/4HANA beinhaltet zwar ein Produktstammdatenmanagement über seinen Materialstamm. Aber der Materialstamm ist für Supply-Chain- und Finanzzwecke konzipiert – und das sieht man ihm an. Produktattribute werden in fixen Tabellenstrukturen gespeichert, was das Hinzufügen neuer Felder oder kanalspezifischer Varianten mühsam macht. Produktlokalisierung für unterschiedliche Märkte ist nicht vorhanden. Rich-Media-Verwaltung und Content-Workflow-Management existieren entweder nicht oder erfordern umfangreiche Anpassungen.
In Projekten, die wir für Hersteller von Industrieausrüstungen und chemische Distributoren durchgeführt haben, hielt der SAP-Materialstamm typischerweise zwischen 30 und 60 Attribute pro Produkt. Der PIM-Katalog für die gleichen Produkte benötigte 200 bis 400 Attribute pro SKU, um Kanäle richtig zu bedienen. Diese Lücke ist der Grund, weshalb SAP-PIM-Integration nicht optional, sondern unverzichtbar ist.
Die reine Attributanzahl erfasst jedoch nicht das gesamte Problem. SAP speichert Produktattribute in fixen, zweckgebundenen Ansichten: Basisdaten, Vertrieb, Einkauf, MRP, Buchhaltung. Das Hinzufügen einer Marketingbeschreibung, einer kanalspezifischen Kategoriebezeichnung oder eines lokalisierten Produktnamens erfordert entweder die Zweckentfremdung eines bestehenden Felds oder benutzerdefinierte Entwicklung. Keine dieser Optionen skaliert gut, wenn ein Katalog auf Zehntausende von SKUs über mehrere Märkte hinweg wächst. SAP-Fiori-Apps verbessern zwar die Benutzerfreundlichkeit, lösen aber nicht das strukturelle Problem: Der Materialstamm ist das falsche Behältnis für Inhalte, die angereichert, lokalisiert und über Kanäle hinweg verteilt werden müssen.
SAP ECC und das Migrationsfenster
Ein großer Anteil der Unternehmen, die derzeit SAP-PIM-Integrationen durchführen, nutzt SAP ECC 6.0 statt S/4HANA. Der Standard-Support für ECC 6.0 endet am 31. Dezember 2027. Migrationen dauern typischerweise 18 bis 36 Monate, was bedeutet, dass viele Organisationen bereits eine Migration planen oder durchführen.
Das hat Auswirkungen auf die Integrationsentwicklung. Eine Integration, die speziell für ECCs IDoc-basierte Schnittstellen entwickelt wurde, muss für die OData-API-Schicht von S/4HANA neu architekturiert werden. Unternehmen, die ihre SAP-PIM-Integration jetzt mit OData und einem Connector aufbauen, der sowohl ECC als auch S/4HANA unterstützt, vermeiden einen Neubau nach der Migration.
Ein weiterer Aspekt ist das SAP-Clean-Core-Prinzip. Die empfohlene Architektur von SAP S/4HANA entmutigt benutzerdefinierten Code in der ABAP-Schicht und drängt Integrationen zur Standard-API-Oberfläche. PIM-Integrationen, die auf benutzerdefinierten ABAP-Erweiterungen oder nicht-standardisierten BAPIs beruhen, erzeugen technische Schulden, die dem Clean-Core-Gedanken widersprechen und zukünftige Upgrades erschweren.
Wie SAP-S/4HANA-PIM-Integration technisch funktioniert
Datenaustausch-Protokolle
Die primäre Schnittstelle für SAP-S/4HANA-Integrationen ist ihre OData-API-Schicht. SAP S/4HANA macht Produktstammdaten über Standard-OData-Services zugänglich, die es externen Systemen erlauben, Records auf kontrollierte, authentifizierte Weise zu lesen, zu erstellen und zu aktualisieren. S/4HANA fügt native OData-V4-Unterstützung und das RAP-Framework (RESTful Application Programming) zum Erstellen und Konsumieren von APIs hinzu, was es sauberer macht als ältere SAP-Generationen. Dies ist der wartbarste Ansatz und der, den der AtroCore-SAP-Connector nutzt.
Für Legacy- oder komplexere SAP-Landschaften bleiben zwei ältere Protokolle relevant. IDocs (Intermediate Documents) sind Flatfile-Nachrichtenformate für Batch-Datenaustausch, oft mit SAP-ECC-Umgebungen oder älteren S/4HANA-Konfigurationen. BAPIs (Business Application Programming Interfaces) sind Funktionsmodule, die SAP-Geschäftslogik für Remote-Aufrufe bereitstellen. Die meisten modernen PIM-Integrationen vermeiden BAPIs für den Produktdatenaustausch, da OData besser strukturiert und einfacher zu versionieren ist.
Attribut-Mapping und Feldmapping
Einer der zeitaufwändigsten Teile jeder SAP-S/4HANA-PIM-Integration ist das Attribut-Mapping. SAP organisiert Produktdaten in Materialtypen, Ansichten und Klassifizierungsmerkmale. Ein PIM-System hat sein eigenes Attributmodell, oft auf EAV-Basis (Entity-Attribute-Value), das flexible, benutzerdefinierte Attributstrukturen ermöglicht.
Das Feldmapping zwischen den beiden Systemen muss Namenskonventionen, Datenformat-Unterschiede und strukturelle Unstimmigkeiten berücksichtigen. SAP-Klassifizierungsmerkmale (gespeichert in Tabelle CT04) bilden auf PIM-Attributgruppen ab, aber das Mapping ist selten 1:1. Maßeinheiten, Sprachcodes und Kategoriehierarchien – alles benötigt explizit definierte Übersetzungsregeln vor Synchronisationsbeginn.
Eine detaillierte Attribut-Mapping-Übung zu überspringen ist einer der häufigsten Gründe, dass SAP-PIM-Integrationsprojekte Zeit- und Budgetplan überschreiten.
Synchronisationsmuster
Das richtige Synchronisationsmuster hängt vom Datentyp und davon ab, wie schnell sich diese Daten bewegen müssen.
Geplante Batch-Synchronisation verschiebt Daten in definierten Zeitfenstern, beispielsweise nachts oder alle vier Stunden. Dies eignet sich für Produktinhalte, die selten wechseln und wo eine Verzögerung von wenigen Stunden zwischen Systemen akzeptabel ist. Die meisten initialen Integrations-Setups starten hier.
Ereignisgesteuerte Synchronisation triggert Datenübertragung, wenn eine bestimmte Änderung in einem der Systeme auftritt. Ein neuer Materialstammsatz, der in SAP erstellt wird, triggert einen Push zu PIM. Ein in der PIM-Workflow genehmigtes Produkt triggert einen Push zur E-Commerce-Plattform. Dies erfordert Workflow-Tools zusätzlich zum Kern-Connector.
Manuelle Synchronisation auf Abruf ermöglicht es Bedienern, Feeds bei Bedarf zu triggern, beispielsweise vor dem Launch eines saisonalen Katalogs oder nach einem Batch-Produkt-Upload. Dies ist keine langfristige Strategie, hilft aber während Migrations- und Testphasen.
Die meisten Produktions-SAP-PIM-Integrationen starten mit geplanter Batch-Synchronisation und legen dann ereignisgesteuerte Trigger für hochpriorisierte Datentypen auf, sobald die Basis-Verbindung stabil ist.
Datenflusrichtung
Die Integration läuft in den meisten Enterprise-Setups bidirektional. Von SAP zu PIM: Materialnummern, Basispreise, Maßeinheit, Produkthierarchie-Knoten und Verfügbarkeitsstatus. Von PIM zu SAP: angereicherte Produktbeschreibungen, Klassifizierungsdaten und in manchen Fällen Produkthierarchie-Updates.
Wenn PIM auch als Publikationsebene zu E-Commerce, Marktplätzen oder Druck fungiert, erweitert sich der Datenfluss: SAP füttert das PIM, das PIM reichert an und transformiert, und verteilt dann an nachgelagerte Kanäle. Dies wird manchmal Hub-and-Spoke-Modell genannt, und hier entfaltet ein PIM-System seinen größten Wert in einer komplexen IT-Umgebung.
SAP-PIM-Integrationsmuster
Muster 1: Direkte PIM-Integration
Das PIM-System verbindet sich direkt mit SAP S/4HANA über dessen OData-API. Das PIM verwaltet Produktanreicherung, Lokalisierung und Content-Management. SAP verwaltet Transaktionen und operative Daten. Der Datenaustausch zwischen den beiden Systemen läuft geplant oder ereignisgesteuert.
Nach unserer Erfahrung ist dies der Ausgangspunkt für die meisten Projekte. Es funktioniert gut, wenn das Datenmodell relativ stabil ist und der Integrations-Umfang auf Produktstammdaten und eine kleine Anzahl nachgelagerter Kanäle begrenzt ist.
Muster 2: PIM als Integrations-Hub
In diesem Muster fungiert AtroPIM oder AtroCore als zentrales Daten-Hub, empfängt Produktdaten von SAP und verteilt diese an mehrere nachgelagerte Systeme: E-Commerce-Plattformen, digitale Marktplätze, Content-Management-Systeme, Druckproduktions-Workflows und Retail-Portale. Das PIM wird zur Schicht, wo Channel-Aktivierung, Content-Syndication und Produktlokalisierung stattfinden, bevor Daten einen Vertriebskanal erreichen.
Das PIM verwaltet Datentransformation und kanalspezifische Formatierung. SAP muss nichts über die nachgelagerten Systeme wissen. Das eliminiert Datenschwellen zwischen Kanälen und konzentriert Daten-Governance an einem Ort.
Unsere Kunden in der Baustoffverteilung stehen oft vor dieser Situation. Sie empfangen Materialstammdaten von SAP, müssen aber an fünf oder sechs verschiedene Vertriebskanäle publizieren, jeder mit unterschiedlichen Datenformaten und Attributanforderungen. SAP direkt mit jedem Kanal zu verbinden schafft Wartungsaufwand, der mit jedem neuen Kanal wächst. Alle Kanäle durch ein zentrales PIM laufen zu lassen reduziert diese Komplexität erheblich.
Muster 3: Integration via Middleware
SAP Cloud Integration Suite (auch SAP CPI oder SAP Integration Suite genannt) kann als Middleware zwischen SAP S/4HANA und einem PIM-System fungieren. Dies fügt eine verwaltete Integrations-Schicht hinzu, die Message-Routing, Datentransformation, Fehlerbehandlung, Audit-Logging und Monitoring übernimmt.
Dies ist die Architektur, die Inriver PIM für seine SAP-Verbindung nutzt. Vorgefertigte iFlows in der SAP Integration Suite übersetzen und mappen Produktdaten zwischen den beiden Systemen. Es erfordert eine SAP Business Technology Platform (BTP) und ist besser geeignet für Organisationen, die bereits in SAP-Integrations-Tools investiert haben.
Akeneo PIM folgt einem ähnlichen Ansatz und verlässt sich auf SAP Integration Suite oder iPaaS-Plattformen von Drittanbietern wie Alumio, um die Lücke zu überbrücken. Die Akeneo REST-API nutzt OAuth-2.0-Authentifizierung, und Datenmapping und -transformation finden in der Middleware-Schicht statt. Pimcore und Contentserv folgen ebenfalls diesem Muster und nutzen API-gesteuerte Konnektivität mit SAP Integration Suite oder benutzerdefinierten Middleware-Adaptern.
Der Middleware-Ansatz fügt Infrastruktur-Kosten und Komplexität hinzu, bietet aber besseres Monitoring, Audit-Fähigkeit und Ausrichtung auf SAP-Integrations-Roadmap. Für Organisationen, die bereits SAP BTP betreiben, ist der zusätzliche Aufwand oft gerechtfertigt.
Geschäftsergebnisse von SAP-PIM-Integration
Die operative Begründung für SAP-PIM-Integration ist unkompliziert, sobald man die Zahlen durchgerechnet hat, wie Produktdaten in einer typischen Fertigungs- oder Vertriebsumgebung tatsächlich fließen.
Time-to-Market. Wenn Produktdaten automatisch von SAP in ein PIM-System fließen und dort angereichert und genehmigt werden, bevor sie publiziert werden, verzögern sich Produktlaunches nicht mehr durch manuelle Dateneingabe. In der Sicherheitsausrüstungsproduktion beispielsweise kann eine neue Produktlinie mit 80 SKUs und obligatorischen Sicherheitszertifikaten pro Markt innerhalb von Stunden nach SAP-Genehmigung über E-Commerce- und Distributor-Portale live gehen – statt Tage für manuelle Export-, Bearbeitungs- und Upload-Zyklen zu benötigen.
Datenqualität und Vollständigkeit. PIM-Systeme erzwingen Attribut-Vollständigkeit, bevor Inhalte einen Kanal erreichen. Ein Produktstammsatz mit fehlenden technischen Spezifikationen oder nicht-validierten Bildern passiert nicht den Genehmigungsworkflow. Dies reduziert direkt Produktrückgaben verursacht durch ungenaue oder unvollständige Produktinformationen zum Kaufzeitpunkt.
Kanal-Konsistenz. Ein einzelner Anreicherungspass im PIM pusht konsistente Produktbeschreibungen, Bilder und technische Spezifikationen zeitgleich über jeden Kanal. Ohne Integration verwalten kanalspezifische Teams eigene Kopien von Produktdaten, und Inkonsistenzen sammeln sich mit der Zeit an.
Reduzierte manuelle Arbeit. Das Entfernen des manuellen Export-und-Import-Schritts zwischen SAP und nachgelagerten Kanälen beseitigt eine Großquelle von Dateneingabe-Fehlern. Produktteams verbringen Zeit auf Content-Qualität statt Datenlogistik.
Der ROI-Fall ergibt sich aus schnelleren Produktlaunches, niedrigeren Rückgabenquoten dank besserer Produktdaten und reduziertem Personalaufwand für manuelle Datenbearbeitung. Bei größeren Katalogen amortisiert sich oft allein der letzte Punkt innerhalb des ersten Jahres.
AtroPIM und AtroCore: Direkte SAP-PIM-Integration
AtroPIM ist eine Open-Source-PIM-Lösung, die auf der AtroCore-Plattform aufgebaut ist und sowohl als SaaS-Service als auch für On-Premise-Deployment verfügbar ist. Es verbindet sich mit SAP S/4HANA direkt über den SAP S/4HANA PIM E-Commerce Connector, der die OData-API-Schicht von SAP nutzt. Keine zusätzliche Middleware-Software ist erforderlich.
Der Connector unterstützt sowohl das PIM-Integrations-Muster (AtroPIM verwaltet Produktanreicherung und Inhalte, tauscht Daten mit SAP aus) als auch das Full-Integration-Muster (AtroCore fungiert als zentrales Daten-Hub für die Verbindung von SAP mit nachgelagerten Kanälen für Content-Syndication und Channel-Aktivierung). Unternehmen können mit der einfacheren PIM-Integrations-Konfiguration starten und später auf Vollausbau expandieren, ohne die Grundlage umzubauen.
AtroPIM beinhaltet ein integriertes DAM zur Verwaltung digitaler Assets neben Produktdaten. Produktbilder, technische Dokumente und Mediendateien werden in der gleichen Plattform wie Produktinhalte verwaltet, und beide fließen über denselben Connector in SAP und von SAP weg. Es gibt kein separates DAM-Integration, das gepflegt werden muss.
Technisch unterstützt der Connector:
- One-Way- und bidirektionale Datensynchronisation
- Alle Standard-Datentypen, einschließlich Bilder und digitale Assets
- Jedes Datenformat: XML, JSON, CSV
- Benutzerdefinierte Datenstrukturen und geschäftsspezifische Attribute
- Geplante Synchronisation mit pro-Feed-Konfiguration
- Ereignisgesteuerte Synchronisation wenn das Workflows-Modul aktiv ist
- Manuelle Datenexport auf Abruf zu SAP S/4HANA
- Audit-Trail für alle Synchronisations-Aktivitäten
Alle Feed-Konfigurationen sind transparent und editierbar. Es gibt keine Black-Box-Transformationslogik. Das ist wichtig in Enterprise-Umgebungen, wo Integrations-Verhalten auditiert, modifiziert und zwischen Teams weitergegeben werden muss.
Der Connector ist in zwei Lizenz-Stufen verfügbar: PIM Integration und Full Integration. One-Time-Datenexport zu SAP und bidirektionale geplante Synchronisation sind in der Full-Integration-Stufe enthalten. Ereignisgesteuerte Synchronisation und on-the-fly-Datentransformationen erfordern die Module Workflows und Synchronization, separat verfügbar.
Daten-Governance in SAP-PIM-Integration
Jede bidirektionale Integration erzeugt irgendwann einen Konflikt. Eine in SAP aktualisierte Produktkategorie überschreibt eine in PIM vorgenommene Korrektur. Ein in PIM bearbeiteter lokalisierter Produktname wird bei der nächsten Synchronisation überschrieben. Ohne explizite Regeln, die definieren, welches System welche Attribute besitzt, sammeln sich diese Konflikte geräuschlos, bis sie ein Datenqualitätsproblem werden.
Die praktische Lösung ist, Dateneigentum auf Attribut-Ebene vor der Implementierung zu definieren. SAP besitzt Materialnummern, Basispreise, Maßeinheit und Bestandsstatus. Das PIM besitzt lange Beschreibungen, Marketing-Texte, digitale Assets, technische Attributsätze und kanalspezifische Varianten. Für gemeinsame Attribute wie Produktnamen oder Kategorie-Zuordnungen muss ein System als Autorität designiert werden, und die Integration muss diese Zuweisung erzwingen.
Das Konzept eines Golden Record (eine einzelne, autoritative Version der Produktattribute) erfordert explizite Governance-Regeln, nicht allein eine technische Verbindung. Attribute-Konflikte über Tausende Produkte hinweg manuell zu lösen ist teuer und langsam; die Regeln voraus zu bauen ist nicht.
Datenvollenständigkeits-Regeln fügen eine zweite Schicht hinzu. Bevor ein Produktstammsatz auf irgendeinen Kanal veröffentlicht werden kann, kann das PIM erfordern, dass ein definierter Satz von Attributen gefüllt, validiert und genehmigt wird. Das verhindert unvollständige Produktdaten von Kunden und erstellt eine Audit-Spur wer was und wann genehmigt hat.
AtroCore beinhaltet Daten-Validierung und Deduplizierungs-Logik mit in die Plattform eingebauten Genehmigungsworkflows. Diese können konfiguriert werden, um Governance-Regeln durchzusetzen, bevor Daten das PIM zu SAP oder nachgelagerten Kanälen verlassen.
Integrations-Planung: Was zuerst zu bewerten ist
Umfang und Architektur einer SAP-PIM-Integration hängen von vier Dingen ab, die es lohnt sich zu etablieren, bevor technische Arbeit beginnt.
Das erste ist die aktuelle Datenabdeckung. Ein Daten-Audit über beide Systeme wird Lücken und Datenqualitätsprobleme offenbaren, die die Integration entweder amplifiziert oder behebt. Diesen Schritt zu überspringen neigt dazu, eine Integration zu erzeugen, die schlechte Daten schneller bewegt. Das Ergebnis sollte eine klare Karte sein, welche Attribute wo existieren, welche fehlen und welche zwischen Systemen in Konflikt stehen.
Das zweite ist der nachgelagerte Umfang. Wenn SAP und PIM die einzigen zwei beteiligten Systeme sind, ist der Integrations-Umfang handhabbar. Wenn das PIM E-Commerce, Marktplätze, einen Druck-Workflow und ein B2B-Portal füttern muss, ändert sich das Architektur-Design entsprechend. Das bestimmt, ob Muster 1 oder Muster 2 der richtige Ausgangspunkt ist.
Das dritte ist die Daten-Frische-Anforderung. Preise und Bestände benötigen Echtzeit-Updates. Produktbeschreibungen und digitale Assets können typischerweise eine nächtliche Synchronisation tolerieren. Verschiedene Datentypen in ein einzelnes geplantes Batch zu mischen schafft unnötiges Risiko; Feed-Trennung nach Datentyp ist der einfachere und zuverlässigere Ansatz.
Das vierte ist die Post-Launch-Governance-Verantwortung. Integrationsprojekte, die ohne definierten Governance-Prozess versendet werden, neigen dazu, Inkonsistenzen mit der Zeit zu sammeln. Dateneigentum, Konflikt-Auflösungsregeln und einen Monitoring-Ansatz bei Design-Phase zu etablieren zahlt sich während des Betriebs erheblich aus.
Häufige Integrationsfehler
Das ERP als Single Source of Truth für alle Produktdaten behandeln. SAP-Materialstamm wurde für operative Daten designt, nicht Marketing-Inhalte. Produktbeschreibungen, Kanal-Attribute und digitale Assets durch SAP zu zwingen erzeugt Datenschwellen und technische Schulden.
SAP separat mit jedem nachgelagerten System verbinden. Point-to-Point-Integrationen sind anfangs schnell zu bauen, aber langsam und teuer zu unterhalten. Jeder neue Vertriebskanal erfordert eine neue Verbindung. Ein PIM als Distributions-Hub zu nutzen reduziert das erheblich.
Attribute-Mapping vor technischer Implementierung überspringen. Datenmodell-Unterschiede zwischen SAP und einem PIM-System sind fast immer größer als erwartet. Feldmapping über Attribut-Namen, Hierarchien und Codierungsstandards hinweg braucht Zeit. Diese Lücken während Test statt Planung zu entdecken verlängert Zeitpläne.
Alles in ein Batch-Fenster synchronisieren. Zeitkritische Daten (Preise, Verfügbarkeit) auf den gleichen Plan wie niedrig-priorisierte Inhalte (Bild-Metadaten) zu legen bedeutet, das ganze Batch muss mit der schnellsten erforderlichen Frequenz laufen. Feed-Trennung nach Datentyp und Dringlichkeit reduziert Last und macht Fehlerbehandlung einfacher.
Für ECC bauen während Migration zu S/4HANA läuft. Unternehmen mid-Migration sollten nicht in eine IDoc-basierte Integration investieren, die ersetzt werden muss. Jetzt auf OData zu bauen zukunftssichert die SAP-S/4HANA-PIM-Integration.
Fazit
SAP-PIM-Integration ist eine Architektur-Entscheidung, keine Produktwahl. Der richtige Ansatz hängt davon ab, wie viele Systeme Produktdaten brauchen, wie häufig sich die Daten ändern und wie viel Governance-Infrastruktur existiert. Direkte OData-basierte Integration deckt die meisten PIM-Only-Use-Cases ab. Middleware-basierte Ansätze mit SAP Integration Suite eignen sich für Organisationen bereits in der SAP-Welt. PIM-as-Hub eignet sich für Unternehmen, die Produktdaten an mehrere nachgelagerte Kanäle verteilen und Channel-Aktivierung, Content-Syndication und Produktlokalisierung von einem einzelnen Punkt aus verwalten.
Die 2027-ECC-Wartungs-Deadline macht dies zu einer Entscheidung mit Uhr daran. Unternehmen, die noch IDoc-basierte SAP-PIM-Integrationen auf ECC betreiben, brauchen unabhängig davon einen Migrations-Weg. Jetzt auf OData und S/4HANA zu bauen vermeidet einen zweiten Rearchitektur-Pass in zwei Jahren.
AtroPIM und AtroCore decken alle drei Integrationsmuster über einen einzelnen Connector mit einem Datenmodell und einer Governance-Schicht, die mit dem Geschäft wachsen können.