SAP S/4HANA ist eines der am weitesten verbreiteten ERP-Systeme in Unternehmensumgebungen. Nach Daten von 6sense aus 2026 hält SAP S/4HANA knapp 10% des globalen ERP-Marktes mit über 26.000 erfassten Kunden. Mit wachsender Verbreitung steigt auch die Notwendigkeit, SAP mit anderen Geschäftssystemen zu verbinden – einschließlich PIM-Lösungen.
Was ist SAP-PIM-Integration?
SAP-PIM-Integration ist die Verbindung zwischen einem SAP-ERP-System und einer Product Information Management-Plattform. Meist handelt es sich dabei um SAP S/4HANA, doch viele Unternehmen betreiben noch SAP ECC 6.0 und benötigen dort dieselbe Funktionalität. Die beiden Systeme erfüllen unterschiedliche Aufgaben und verwalten verschiedene Arten von Daten.
SAP verwaltet Transaktionsdaten: Materialstammsätze, Preise, Bestände, Beschaffung und Finanzbuchungen. Es ist der operative Kern. Ein PIM-System verwaltet Marketing- und Kanalcontent: Produktbeschreibungen, technische Spezifikationen, digitale Assets, Kategoriestrukturen und kanalspezifische Varianten. Dies sind die Produktattribute, für die SAP nie konzipiert wurde.
Wenn die beiden Systeme integriert sind, bleibt SAP die autoritative Quelle für SKUs, Preise und Bestände. Das PIM-System kümmert sich um die Produktanreicherung mit allem, was für die Veröffentlichung auf E-Commerce-Plattformen, SAP Commerce Cloud, Retail-Portalen, Druckkatalogen und digitalen Marktplätzen erforderlich ist. Keines der Systeme ersetzt das andere. Sie teilen sich die Verantwortung und tauschen Daten bidirektional aus.
Warum SAPs native Produktdatenverwaltung nicht ausreicht
SAP S/4HANA verfügt zwar über Produktmasterdatenverwaltung durch seinen Materialstamm. Aber der Materialstamm ist für Supply-Chain- und Finanzzwecke konzipiert – und das zeigt sich. Produktattribute werden in festen Tabellenstrukturen gespeichert, was das Hinzufügen neuer Felder oder kanalspezifischer Varianten unbeholfen macht. Produktlokalisierung für verschiedene Märkte fehlt. Rich-Media-Verwaltung und Content-Workflow-Management existieren entweder gar nicht oder erfordern umfangreiche Anpassungen.
Bei Projekten, die wir für Hersteller von Industrieausrüstungen und chemische Distributoren implementiert haben, enthielt der SAP-Materialstamm typischerweise zwischen 30 und 60 Attribute pro Produkt. Der PIM-Katalog für dieselben Produkte benötigte 200 bis 400 Attribute pro SKU, um die Knalanforderungen zu erfüllen. Diese Lücke ist der Punkt, an dem SAP-PIM-Integration essentiell – nicht optional – wird.
Die reine Attributanzahl erfasst das vollständige Problem nicht. SAP speichert Produktattribute in festen, speziell angefertigten Ansichten: Grunddaten, Vertrieb, Beschaffung, MRP, Rechnungswesen. Das Hinzufügen einer Marketingbeschreibung, eines kanalspezifischen Kategorielabels oder eines lokalisierten Produktnamens erfordert entweder die Zweckentfremdung eines bestehenden Feldes 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 das Benutzererlebnis beim Arbeiten in SAP, lösen aber dieses strukturelle Problem nicht: Der Materialstamm ist der falsche Behälter für Content, der angereichert, lokalisiert und über Kanäle hinweg verteilt werden muss.
SAP ECC und das Migrationsfenster
Ein großer Teil der Unternehmen, die derzeit SAP-PIM-Integrationen durchführen, tun dies auf SAP ECC 6.0, nicht S/4HANA. Der Mainstream-Support für ECC 6.0 endet am 31. Dezember 2027. Migrationen dauern typischerweise 18 bis 36 Monate, was bedeutet, dass viele Organisationen bereits mitten in einer Migration sind oder planen.
Das ist wichtig für das Integrationsdesign. Eine Integration, die speziell für ECCs IDoc-basierte Schnittstellen gebaut wurde, muss für SAP S/4HANAs OData-API-Schicht umstrukturiert werden. Unternehmen, die ihre SAP-PIM-Integration jetzt mit OData und einem Connector aufbauen, der sowohl ECC als auch S/4HANA unterstützt, vermeiden eine komplette Neuentwicklung nach der Migration.
Die andere Überlegung ist das SAP-Clean-Core-Prinzip. Die empfohlene Architektur von SAP S/4HANA entmutigt benutzerdefinierten Code in der ABAP-Schicht und treibt Integrationen zu seiner Standard-API-Oberfläche hin. PIM-Integrationen, die auf benutzerdefinierten ABAP-Erweiterungen oder nicht-standardisierten BAPIs beruhen, generieren technische Schulden, die mit Clean Core in Konflikt geraten und zukünftige Upgrades erschweren.
Wie SAP-S/4HANA-PIM-Integration technisch funktioniert
Datenaustauschprotokolle
Die primäre Schnittstelle für SAP-S/4HANA-Integrationen ist seine OData-API-Schicht. SAP S/4HANA stellt Produktmasterdaten über standardisierte OData-Services bereit, die es externen Systemen ermöglichen, Datensätze 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) zur Erstellung und Nutzung von APIs hinzu, was den Umgang einfacher macht als bei älteren SAP-Generationen. Dies ist der wartbarste Ansatz und derjenige, der vom AtroCore-SAP-Connector verwendet wird.
Für ältere oder komplexere SAP-Landschaften bleiben zwei ältere Protokolle relevant. IDocs (Intermediate Documents) sind Flatfile-Nachrichtenformate für den 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.
Attributzuordnung und Feldzuordnung
Einer der zeitaufwändigsten Teile jeder SAP-S/4HANA-PIM-Integration ist die Attributzuordnung. SAP organisiert Produktdaten in Materialtypen, Ansichten und Klassifizierungsmerkmale. Ein PIM-System hat sein eigenes Attributmodell, oft EAV-basiert (Entity-Attribute-Value), das flexible, benutzerdefinierte Attributstrukturen ermöglicht.
Die Feldzuordnung zwischen den beiden Systemen muss Benennungskonventionen, Datentypformate und strukturelle Nichtübereinstimmungen berücksichtigen. SAP-Klassifizierungsmerkmale (in der Tabelle CT04 gespeichert) werden PIM-Attributgruppen zugeordnet, aber die Zuordnung ist selten eins-zu-eins. Maßeinheiten, Sprachcodes und Kategoriehierarchien benötigen alle explizit definierte Übersetzungsregeln, bevor die Synchronisierung beginnt.
Eine detaillierte Attributzuordnungsübung zu überspringen ist einer der häufigsten Gründe, warum SAP-PIM-Integrationsprojekte zeitlich und budgetär aus dem Ruder laufen.
Synchronisierungsmuster
Das richtige Synchronisierungsmuster hängt vom Datentyp und davon ab, wie schnell diese Daten sich bewegen müssen.
Geplante Batch-Synchronisierung verschiebt Daten in definierten Zeitfenstern, beispielsweise nachts oder alle vier Stunden. Dies eignet sich für Produktcontent, der sich selten ändert und bei dem eine Verzögerung von wenigen Stunden zwischen Systemen akzeptabel ist. Die meisten anfänglichen Integrationssetups beginnen hier.
Ereignisgesteuerte Synchronisierung triggert Datentransfer, wenn eine spezifische Ä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 Core-Connector.
Manuelle bedarfsgesteuerte Synchronisierung ermöglicht es Operatoren, Feeds bei Bedarf zu triggern, beispielsweise vor einem saisonalen Katalogstart oder nach einem Batch-Produkt-Upload. Dies ist keine Langzeitstrategie, aber nützlich während Migrations- und Testphasen.
Die meisten produktiven SAP-PIM-Integrationen beginnen mit geplanter Batch-Synchronisierung und implementieren dann ereignisgesteuerte Trigger für hochpriorisierte Datentypen, sobald die Basisverbindung stabil ist.
Datenfließrichtung
Die Integration läuft in den meisten Enterprise-Setups bidirektional. Von SAP zu PIM: Materialnummern, Basispreise, Maßeinheiten, Produkthierarchieknoten und Verfügbarkeitsstatus. Von PIM zu SAP: angereicherte Produktbeschreibungen, Klassifizierungsdaten und in einigen Fällen Produkthierarchie-Updates.
Wenn PIM auch als Publishing-Schicht zu E-Commerce, Marktplätzen oder Print fungiert, erstreckt sich der Datenstrom weiter: SAP speist das PIM, das PIM reichert an und transformiert, und verteilt dann an nachgelagerte Kanäle. Dies wird manchmal Nabe-und-Speiche-Modell genannt, und hier schafft ein PIM-System in einer komplexen IT-Umgebung den meisten Wert.
SAP-PIM-Integrationsmuster
Muster 1: Direkte PIM-Integration
Das PIM-System verbindet sich direkt mit SAP S/4HANA über dessen OData-API. Das PIM kümmert sich um Produktanreicherung, Lokalisierung und Content-Management. SAP kümmert sich um Transaktionen und Betriebsdaten. Der Datenaustausch läuft zwischen den beiden Systemen auf geplanter oder ereignisgesteuerter Basis.
Nach unserer Erfahrung ist dies der Ausgangspunkt für die meisten Projekte. Es funktioniert gut, wenn das Datenmodell relativ stabil ist und der Integrationsumfang auf Produktmasterdaten und eine kleine Anzahl von nachgelagerten Kanälen begrenzt ist.
Muster 2: PIM als Integrations-Hub
In diesem Muster fungiert AtroPIM oder AtroCore als zentrale Daten-Nabe, empfängt Produktdaten von SAP und verteilt sie an mehrere nachgelagerte Systeme: E-Commerce-Plattformen, digitale Marktplätze, Content-Management-Systeme, Druckproduktions-Workflows und Retail-Portale. Das PIM wird zur Schicht, in der Kanalaktivierung, Content-Syndizierung und Produktlokalisierung stattfinden, bevor Daten einen Vertriebskanal erreichen.
Das PIM verwaltet Datentransformation und kanalspezifische Formatierung. SAP muss nichts über die nachgelagerten Systeme wissen. Dies eliminiert Datensilo zwischen Kanälen und konzentriert Data Governance an einem Ort.
Unsere Kunden im Baustoffvertrieb stehen häufig vor dieser Situation. Sie erhalten Materialstammsätze von SAP, müssen aber auf fünf oder sechs verschiedene Vertriebskanäle veröffentlichen, die jeweils unterschiedliche Datenformate und Attributanforderungen haben. Das Verbinden von SAP mit jedem Kanal einzeln erzeugt einen Wartungsaufwand, der mit jedem neuen Kanal wächst. Das Leiten aller Kanäle durch ein zentrales PIM reduziert diese Komplexität erheblich.
Muster 3: Integration über 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 verwaltet.
Dies ist die Architektur, die Inriver PIM für seine SAP-Verbindung verwendet. Vorgefertigte iFlows innerhalb der SAP Integration Suite übersetzen und ordnen Produktdaten zwischen den beiden Systemen zu. Dies erfordert eine SAP Business Technology Platform (BTP)-Umgebung und eignet sich besser für Organisationen, die bereits in SAP-Integrations-Tools investiert haben.
Akeneo PIM verfolgt einen ähnlichen Ansatz und nutzt SAP Integration Suite oder iPaaS-Plattformen von Drittanbietern wie Alumio, um die Lücke zu schließen. Die Akeneo-REST-API nutzt OAuth-2.0-Authentifizierung, und Datenzuordnung sowie 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 bessere Überwachung, Nachverfolgbarkeit und Ausrichtung mit SAP-Integrations-Roadmap. Für Organisationen, die bereits SAP BTP betreiben, ist der zusätzliche Aufwand oft gerechtfertigt.
Geschäftsergebnisse der SAP-PIM-Integration
Der operative Fall für SAP-PIM-Integration ist einfach, sobald Sie die Zahlen durchgerechnet haben, wie Produktdaten in einer typischen Fertigungs- oder Distributionsumgebung 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 veröffentlicht werden, sind Produktstarts nicht mehr durch manuelle Dateneingabe gebremst. In der Sicherheitsausrüstungs-Fertigung beispielsweise können 80 SKUs mit obligatorischen Sicherheitszertifizierungen 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 Attributvollständigkeit, bevor Content einen Kanal erreicht. Ein Produktstammsatz mit fehlenden technischen Spezifikationen oder nicht validierten Bildern passiert die Approval-Workflow nicht. Dies reduziert direkt Produktrückgaben, die durch ungenaue oder unvollständige Produktinformationen am Kaufpunkt verursacht werden.
Kanalkonsistenz. Ein einziger Anreicherungspass im PIM verteilt konsistente Produktbeschreibungen, Bilder und technische Spezifikationen über jeden Kanal gleichzeitig. Ohne die Integration pflegen kanalspezifische Teams ihre eigenen Kopien der Produktdaten, und Inkonsistenzen sammeln sich über Zeit an.
Reduzierte manuelle Arbeit. Das Entfernen des manuellen Export-und-Import-Schritts zwischen SAP und nachgelagerten Kanälen eliminiert eine große Quelle von Dateneingabefehler. Produktteams konzentrieren sich auf Content-Qualität statt Datenlogistik.
Der ROI-Case stammt aus schnelleren Produktstarts, niedrigeren Rückgabequoten durch bessere Produktdaten und reduziertem Personalaufwand für manuelle Datenbearbeitung. Bei größeren Katalogen deckt das letzte Item allein oft die Integrationskosten im ersten Jahr.
AtroPIM und AtroCore: Direkte SAP-PIM-Integration
AtroPIM ist eine Open-Source-PIM-Lösung, gebaut auf der AtroCore-Datenplattform, verfügbar sowohl als SaaS-Service als auch für On-Premise-Deployment. Es verbindet sich direkt mit SAP S/4HANA über den SAP S/4HANA PIM E-Commerce Connector, der SAP-OData-API-Schicht nutzt. Keine zusätzliche Middleware-Software ist erforderlich.
Der Connector unterstützt sowohl das PIM-Integrationsmuster (AtroPIM verwaltet Produktanreicherung und Content, tauscht Daten mit SAP aus) als auch das Full-Integration-Muster (AtroCore fungiert als zentrale Daten-Nabe, verbindet SAP mit nachgelagerten Kanälen für Content-Syndizierung und Kanalaktivierung). Unternehmen können mit der einfacheren PIM-Integration-Konfiguration starten und später zur Nabe-und-Speiche-Konfiguration expandieren, ohne die Grundlagen neu zu erstellen.
AtroPIM includes built-in DAM zum Verwalten digitaler Assets neben Produktdaten. Produktbilder, technische Dokumente und Mediendateien werden auf derselben Plattform wie der Produktcontent verwaltet, und beide fließen durch denselben Connector in und aus SAP. Es gibt keine separate DAM-Integration zu warten.
Technisch unterstützt der Connector:
- Unidirektionale und bidirektionale Datensynchronisierung
- Alle Standard-Datentypen, einschließlich Bilder und digitaler Assets
- Beliebiges Datenformat: XML, JSON, CSV
- Benutzerdefinierte Datenstrukturen und geschäftsspezifische Attribute
- Geplante Synchronisierung mit Konfiguration pro Feed
- Ereignisgesteuerte Synchronisierung, wenn das Workflows-Modul aktiv ist
- Manuelle bedarfsgesteuerte Datenexporte zu SAP S/4HANA
- Audit-Trail für alle Synchronisierungsaktivitäten
Alle Feed-Konfigurationen sind transparent und editierbar. Es gibt keine Black-Box-Transformationslogik. Das ist wichtig in Enterprise-Umgebungen, wo Integrations-Verhalten geprüft, modifiziert und zwischen Teams übergeben werden muss.
Der Connector ist in zwei License-Stufen verfügbar: PIM Integration und Full Integration. Einmaliger Datenexport zu SAP und bidirektionale geplante Synchronisierung sind in der Full-Integration-Stufe inbegriffen. Ereignisgesteuerte Synchronisierung und Echtzeitdatentransformationen erfordern die Workflows- und Synchronization-Module, separat verfügbar.
Data Governance in SAP-PIM-Integration
Jede bidirektionale Integration produziert irgendwann einen Konflikt. Eine in SAP aktualisierte Produktkategorie überschreibt eine im PIM vorgenommene Korrektur. Ein im PIM bearbeiteter lokalisierter Produktname wird beim nächsten Sync überschrieben. Ohne explizite Regeln, die definieren, welches System welche Attribute besitzt, sammeln sich diese Konflikte unmerklich an, bis sie ein Datenqualitätsproblem werden.
Die praktische Lösung besteht darin, die Dateneigentümerschaft vor der Implementierung auf Attributebene zu definieren. SAP besitzt Materialnummern, Basispreise, Maßeinheiten und Lagerstatus. Das PIM besitzt lange Beschreibungen, Marketing-Copy, digitale Assets, technische Attributmengen und kanalspezifische Varianten. Für gemeinsame Attribute wie Produktnamen oder Kategoriezuweisungen muss ein System als Autorität designiert werden, und die Integration muss diese Zuordnung erzwingen.
Das Konzept eines Golden Record (eine einzige, autoritative Version der Produktattribute) erfordert explizite Governance-Regeln, nicht nur eine technische Verbindung. Das manuelle Auflösen von Attributkonflikten über Tausende von Produkten ist teuer und langsam; das Aufbauen der Regeln vorab ist nicht.
Regeln zur Datenvollständigkeit fügen eine zweite Schicht hinzu. Bevor ein Produktstammsatz zu einem Kanal veröffentlicht werden kann, kann das PIM erfordern, dass ein definierter Satz von Attributen gefüllt, validiert und genehmigt wird. Dies verhindert, dass unvollständige Produktdaten Kunden erreichen und erstellt einen Audit-Trail darüber, wer was und wann genehmigt hat.
AtroCore includes Datenvalidierung und Deduplizierungs-Logik, mit Approval-Workflows eingebaut in die Plattform. Diese können konfiguriert werden, um Governance-Regeln zu erzwingen, bevor Daten das PIM zu SAP oder nachgelagerten Kanälen verlassen.
Integrationsplanung: Was zuerst zu bewerten ist
Umfang und Architektur einer SAP-PIM-Integration hängen von vier Dingen ab, die es wert sind, vor jeder technischen Arbeit festzustellen.
Das erste ist aktuelle Datenabdeckung. Ein Datenaudit über beide Systeme offenbart Lücken und Datenqualitätsprobleme, die die Integration entweder verstärken oder beheben wird. Diese Schritt zu überspringen tendiert dazu, eine Integration zu produzieren, die schlechte Daten schneller bewegt. Das Ergebnis sollte eine klare Karte sein, welche Attribute wo existieren, welche fehlen und welche zwischen Systemen in Konflikt geraten.
Das zweite ist nachgelagerter Umfang. Wenn SAP und PIM die einzigen beiden beteiligten Systeme sind, ist der Integrationsumfang handhabbar. Wenn das PIM zu E-Commerce, Marktplätzen, einem Print-Workflow und einem B2B-Portal speisen muss, änderst sich das Architekturdesign entsprechend. Das bestimmt, ob Muster 1 oder Muster 2 der richtige Startpunkt ist.
Das dritte ist Datenfresh-Anforderungen. Preise und Bestände benötigen Echtzeit-Updates. Produktbeschreibungen und digitale Assets können typischerweise eine nächtliche Synchronisierung tolerieren. Diese in einem einzigen geplanten Batch zu mischen, erzeugt unnötiges Risiko; die Trennung von Feeds nach Datentyp ist der einfacheren und zuverlässigeren Ansatz.
Das vierte ist Post-Launch-Governance-Eigentümerschaft. Integrationsprojekte, die ohne einen definierten Governance-Prozess ausgeliefert werden, tendieren dazu, Inkonsistenzen über Zeit zu sammeln. Das Einrichten von Dateneigentümerschaft, Konfliktauflösungsregeln und einem Monitoring-Ansatz in der Design-Phase zahlt sich während Operationen erheblich aus.
Häufige Integrationsfehler
Das ERP als einzige Quelle der Wahrheit für alle Produktdaten zu behandeln. SAP-Materialstamm wurde für Betriebsdaten konzipiert, nicht für Marketing-Content. Das Zwingen von Produktbeschreibungen, Kanalattributen und digitalen Assets durch SAP erzeugt Datensilo und technische Schulden.
SAP mit jedem nachgelagerten System einzeln zu verbinden. Point-to-Point-Integrationen sind anfangs schnell zu bauen, aber langsam und teuer zu warten. Jeder neue Vertriebskanal erfordert eine neue Verbindung. Die Nutzung des PIM als Verteilungs-Hub reduziert dies erheblich.
Attributzuordnung vor technischer Implementierung zu überspringen. Datenmodellunterschiede zwischen SAP und einem PIM-System sind fast immer größer als erwartet. Die Feldzuordnung über Attributnamen, Hierarchien und Kodierstandards hinweg benötigt Zeit. Die Entdeckung dieser Lücken während Tests statt Planung verlängert Zeitleisten.
Alles in einem Batch-Fenster zu synchronisieren. Das Platzieren zeitsensitiver Daten (Preise, Verfügbarkeit) auf demselben Zeitplan wie Content mit niedriger Priorität (Bildmetadaten) bedeutet, dass der gesamte Batch mit der schnellsten erforderlichen Frequenz ausgeführt werden muss. Die Trennung von Feeds nach Datentyp und Dringlichkeit reduziert Last und vereinfacht Fehlerbehandlung.
Für ECC zu bauen, wenn zu S/4HANA migriert wird. Unternehmen in der Mitte einer Migration sollten nicht in eine IDoc-basierte Integration investieren, die ersetzt werden muss. Das Bauen auf OData jetzt future-proofs die SAP-S/4HANA-PIM-Integration.
Fazit
SAP-PIM-Integration ist eine Architekturenscheidung, keine Produktwahl. Der richtige Ansatz hängt davon ab, wie viele Systeme Produktdaten benötigen, wie oft sich die Daten ändern und wie viel Governance-Infrastruktur existiert. Direkte OData-basierte Integration deckt die meisten PIM-Only-Anwendungsfälle ab. Middleware-basierte Ansätze mit SAP Integration Suite passen Organisationen, die bereits im SAP-Ökosystem sind. PIM-als-Hub passt zu Unternehmen, die Produktdaten zu mehreren nachgelagerten Kanälen verteilen und Kanalaktivierung, Content-Syndizierung und Produktlokalisierung von einem einzigen Punkt aus handhaben.
Die Wartungs-Deadline für ECC 2027 macht dies eine Entscheidung mit einer Uhr darauf. Unternehmen, die noch IDoc-basierte SAP-PIM-Integrationen auf ECC ausführen, benötigen unabhängig davon einen Migrationspfad. Das Aufbauen zu OData und S/4HANA jetzt vermeidet einen zweiten Restrukturierungs-Pass in zwei Jahren.
AtroPIM und AtroCore decken alle drei Integrationsmuster durch einen einzigen Connector ab, mit einem Datenmodell und einer Governance-Schicht, die mit dem Geschäft wachsen können.