S/4HANA-Migration: Die letzte Chance auf KI-fähige Produktstammdaten

Die meisten S/4HANA-Programme werden Material-, Geschäftspartner- und Finanzdaten so weit unter Governance bringen, dass der Cutover gelingt. Das ist die Aufgabe des ERP. Es ist nicht die Aufgabe der KI.

KI-Agenten lesen nicht ein SAP-Objekt nach dem anderen. Sie denken in Beziehungen: Welcher Lieferant gehört zu welchem Material, welches Material fließt in welche Produktkonfiguration, welche Konfiguration hat in welchem Markt welchen Preis. Diese Kette liegt meist zur Hälfte in SAP und zur Hälfte in PIM, PLM, CRM, Lieferantenportalen und regionalen Datenbanken. Bereinigt das Programm nur, was S/4 zum Hochfahren braucht, behalten diese angrenzenden Systeme ihre eigenen Definitionen derselben Sache. Die Migration gelingt trotzdem. Der Agent läuft trotzdem in ein Chaos.

Damien Fellowes von Stibo Systems vertritt diese These in Turn your SAP S/4HANA migration into an AI-ready data foundation. Die praktische Lehre für PIM-Käufer ist schärfer als ein weiterer MDM-Pitch. Ein S/4-Programm ist einer der wenigen Momente, in denen Stammdaten gleichzeitig Budget und die Aufmerksamkeit der Geschäftsleitung bekommen. Verpassen Sie dieses Fenster, bauen Sie das Fundament später für eine KI-Initiative neu auf, die weder das eine noch das andere hat.

Was „gut genug für den Cutover“ tatsächlich zurücklässt

ERP-zentriertes MDM optimiert verwaltete Stammdaten für die Modelle und Prozesse, die das ERP braucht. KI-fähiges MDM dehnt Verantwortung, Regeln und Beziehungen über Domänen hinweg aus, sodass ein Modell dem geschäftlichen Kontext vertrauen kann und nicht nur dem Transaktionsdatensatz.

Das klingt nach einer kleinen Änderung des Umfangs. Das ist es nicht. In vielen Programmen wird der Stammdaten-Workstream zuerst daran ausgerichtet, was in S/4 migriert werden und laufen muss. Material, Partner und Finanzen bekommen Verantwortliche, Regeln und eine Bereinigung. Produktinhalte im PIM, technische Spezifikationen im PLM, Self-Service-Portale für Lieferanten, E-Commerce-Kataloge und regionale Attributtabellen bleiben „vorerst außerhalb des Umfangs“. Alle wissen, dass sie sich schon bei der grundlegenden Identität widersprechen. Niemand hat einen Migrations-Workstream, der sie zur Einigung zwingt.

Diesen Film haben wir schon in kleinerem Format gesehen. Unvollständige Produktdaten lassen Sie nicht im Ranking abrutschen. Sie fallen damit aus der Antwort. Akeneos Kindersitz-Shortlist und die Datensteuer von 44 Prozent sagen dasselbe aus Sicht des Commerce: Das Vertrauen in KI ist hoch, und ein großer Teil des Projektaufwands fließt weiterhin in den Abgleich fehlender Attribute und widersprüchlicher Produktinformationen. Ein S/4-Cutover, der PIM- und Lieferantendaten außerhalb des verwalteten Modells lässt, verschiebt diese Steuer einfach in den nächsten Budgetzyklus.

Fellowes unterscheidet sinnvoll zwischen dokumentierter und kodierter Governance. Ein Richtlinien-PDF, das festhält, wem der Produktdatensatz gehört, verhindert nicht, dass in einem hektischen Quartal eine zweite Definition in einem Händler-Feed landet. Regeln, die in der Plattform leben, mit Lineage und Herkunftsnachweis für Änderungen, geben einem Agenten (und einem Prüfer) etwas, dem er folgen kann. Auch Aktualität zählt. Preisgestaltung, Bestandsumverteilung und Monitoring von Lieferantenrisiken brauchen aktuelle Daten. Ein Fundament, das nur für den periodischen Abgleich vor dem Go-live gebaut ist, bedient diese Anwendungsfälle nicht.

Warum die Migration das Zeitfenster ist

Außerhalb eines Transformationsprogramms sind sich alle einig, dass Stammdaten ein Problem sind. Nur wenige bekommen Geld, um es im ganzen Unternehmen zu beheben. Konkurrierende Prioritäten gewinnen jedes Quartal.

Ein S/4-Programm erzwingt die Fragen, die sonst unbeantwortet bleiben: Wem gehören diese Daten, wer setzt die Regeln durch, wie werden regionale Varianten abgeglichen? Budget und Projektteam sind bereits da. Nach dem Go-live zieht diese gebündelte Unterstützung meist weiter. Sie können Stammdaten auch später noch bereinigen. Für dieselbe Arbeit brauchen Sie dann aber einen neuen Business Case, einen neuen Sponsor und einen neuen Finanzierungszyklus.

Das heißt nicht, dass MDM die Migrationswerkzeuge von SAP ersetzt. SAP führt den Übergang weiterhin aus und validiert ihn. Die Stammdatenschicht bereitet vor, harmonisiert und verwaltet, worauf diese Prozesse angewiesen sind, und führt die Governance nach dem Cutover in der gesamten Systemlandschaft fort. Stibo nennt einen Fertigungskunden, der im Rahmen seiner S/4-Reise mehr als 200 Altdatenmodelle auf fünf semantische Modelle reduziert hat, über mehr als 500 Anwendungen und mehr als 1.000 Schnittstellen hinweg. Die Zahl ist weniger interessant als die Art der Arbeit: weniger gemeinsame Bedeutungen statt mehr Punkt-zu-Punkt-Mappings.

SAP MDG ist nicht die falsche Antwort. Es ist die falsche Grenze, wenn Sie dort aufhören.

SAP Master Data Governance kann SAP-Daten und Daten aus Drittsystemen verwalten und konsolidieren. Mit Reltio in der SAP Business Data Cloud ist die Multidomain-Geschichte von SAP breiter als früher. Die Frage für Käufer lautet nicht mehr, ob SAP über S/4 hinausreichen kann. Sie lautet, wo die unternehmensweite Verantwortung und Semantik über SAP, Nicht-SAP und alle künftig hinzukommenden Agenten hinweg liegen soll.

Ist Ihre Welt überwiegend SAP-zentriert, ist MDG vielleicht die Steuerungsebene, die Sie wollen. Müssen Produkt, Lieferant, Kunde und Standort unabhängig von einer einzelnen ERP-Suite bleiben und PLM, PIM, CRM, Kanäle und KI-Konsumenten aus einem semantischen Modell bedienen, dann ist eine unabhängige Multidomain-Schicht oder ein bewusstes Koexistenzmodell der Punkt, den Sie sorgfältig prüfen müssen. STEP von Stibo Systems ist eine Antwort in dieser Kategorie. Es ist nicht die einzige. Viamedici und Syndigo verkaufen ebenfalls Multidomain-MDM neben Produktinhalten, mit unterschiedlichen Stärken bei komplexer Fertigung und bei der Syndizierung im Handel. Die Shortlist ist die Architekturentscheidung, nicht ein einzelner Anbietername. „Wir haben MDG gekauft“ ist nicht derselbe Satz wie „Unser PIM und unser Lieferantenportal teilen dieselbe Produktidentität, die der Agent abrufen wird“.

Ein Produkt ist im echten Geschäft selten nur ein SAP-Material. Es besteht aus Materialattributen plus PIM-Inhalten, PLM-Spezifikationen, regionalen Klassifikationen und Lieferantenbeziehungen. Die vollständige geschäftliche Bedeutung zu verwalten, ist die Messlatte für KI-Fähigkeit. Anzunehmen, dass jedes relevante Attribut in eine Anwendung gehört, ist die Messlatte für den Cutover.

Was wir tun würden, wenn wir dieses Quartal mitten in S/4 steckten

Wir würden nicht das ganze Programm für eine Grundsatzdebatte wieder aufmachen. Wir würden drei Bereiche erweitern, bevor der Workstream eingefroren wird.

Erstens: Listen Sie jedes System auf, das derzeit eine konkurrierende Definition von Produkt, Lieferant oder Kunde enthält: PIM, PLM, Portale, regionale Datenbanken, E-Commerce. Setzen Sie jedes davon mit einem Verantwortlichen auf die Stammdatenlandkarte, selbst wenn das erste Release nur Identifikatoren und einen kleinen Pflichtumfang harmonisiert.

Zweitens: Kodieren Sie die Regeln, die über gültig, vollständig und doppelt entscheiden, in der Plattform und nicht in einer SharePoint-Richtlinie. Verknüpfen Sie Lineage mit Änderungen, damit sich ein KI-Input zurückverfolgen lässt.

Drittens: Stellen Sie die KI-Frage im selben Steuerungsbericht wie die Cutover-Bereitschaft. Kann ein Agent vom Lieferanten zum Material zum verkaufsfähigen Produkt zum Marktpreis gehen, ohne dass ein Mensch Felder zwischen drei Werkzeugen kopiert? Lautet die Antwort Nein, ist die Migration für das ERP noch im Plan. Für agentische Arbeit ist sie es nicht.

Das während des Programms zu beheben, bedeutet zusätzliche Arbeit. Fellowes behauptet, und das würden wir mit einer Programmleitung prüfen, dass die Datenrationalisierung parallel zu Prozessdesign und Tests laufen kann statt als angehängte Phase. Wer sie überspringt, schiebt die Inkonsistenzen in den UAT und in die Monate nach dem Go-live, wo sie lauter und teurer sind.

S/4HANA standardisiert, wie Prozesse ablaufen. Stammdaten standardisieren, was die Daten bedeuten. KI-Agenten, die über Produkt, Lieferant und Finanzen hinweg schlussfolgern, sind darauf angewiesen, dass diese Bedeutung bereits existiert. Das Programm ist die seltene Gelegenheit, die nichts extra kostet. Nach dem Go-live ist dieselbe Bereinigung nur noch ein weiteres KI-Projekt mit angehängter Datensteuer.

Quelle: https://www.stibosystems.com/blog/turn-your-sap-s/4hana-migration-into-an-ai-ready-data-foundation