Your S/4HANA Program Is the Last Free Shot at AI-Ready Product Master Data

Most S/4HANA programs will govern material, business partner and finance data well enough to cut over. That is the ERP job. It is not the AI job.

AI agents do not read one SAP object at a time. They reason across relationships: which supplier ties to which material, which material feeds which product configuration, which configuration carries which price in which market. That chain usually lives half inside SAP and half in PIM, PLM, CRM, supplier portals and regional databases. If the program only cleans what S/4 needs to boot, those adjacent systems keep their own definitions of the same thing. The migration still succeeds. The agent still walks into a mess.

Stibo Systems’ Damien Fellowes makes that case in Turn your SAP S/4HANA migration into an AI-ready data foundation. The practical lesson for PIM buyers is sharper than another MDM pitch. An S/4 program is one of the few moments when master data gets budget and executive attention at the same time. Miss the window, and you rebuild the foundation later for an AI initiative that has neither.

What "good enough for cutover" actually leaves behind

ERP-centered MDM optimizes governed master data for the models and processes the ERP needs. AI-ready MDM extends ownership, rules and relationships across domains so a model can trust the business context, not only the transactional record.

That sounds like a small scope change. It is not. On many programs the master data workstream is defined first around what must migrate and operate in S/4. Material, partner and finance get owners, rules and cleanup. Product content in the PIM, engineering specs in PLM, supplier self-service portals, ecommerce catalogs and regional attribute tables stay “out of scope for now.” Everyone knows they disagree on basic identity. Nobody has a migration workstream to force them to agree.

We have seen this movie in smaller form. Incomplete product data does not send you down a ranking. It drops you from the answer. Akeneo’s car-seat shortlist and the 44 percent data tax say the same thing from the commerce side: confidence in AI is high, and a large share of project effort still goes to reconciling missing attributes and conflicting product information. An S/4 cutover that leaves PIM and supplier data outside the governed model simply schedules that tax for the next budget cycle.

Fellowes’ useful distinction is between documenting governance and encoding it. A policy PDF that says who owns the product record does not stop a busy quarter from shipping a second definition in a retailer feed. Rules that live in the platform, with lineage and provenance on changes, give an agent (and an auditor) something to follow. Freshness matters too. Pricing, inventory rebalancing and supplier-risk monitors need current data. A foundation built only for periodic reconciliation before go-live will not feed those use cases.

Why the migration is the window

Outside a transformation program, everyone agrees master data is a problem. Few people get funded to fix it at enterprise scale. Competing priorities win every quarter.

An S/4 program forces the questions that usually stay unanswered: who owns this data, who enforces the rules, how regional variants get reconciled. The budget and the project team are already there. After go-live, that concentrated sponsorship usually moves on. You can still clean master data later. You will need a new business case, a new sponsor and a new funding cycle to do the same work.

That does not mean MDM replaces SAP’s migration tooling. SAP still executes and validates the transition. The master data layer prepares, harmonizes and governs what those processes depend on, then keeps governing after cutover across the wider estate. Stibo cites a manufacturing customer that, as part of its S/4 journey, reduced more than 200 legacy data models to five semantic models across 500-plus applications and 1,000-plus interfaces. The number is less interesting than the shape of the work: fewer shared meanings, not more point-to-point mappings.

SAP MDG is not the wrong answer. It is the wrong boundary if you stop there.

SAP Master Data Governance can govern and consolidate SAP and third-party data. With Reltio inside SAP Business Data Cloud, SAP’s multidomain story is broader than it used to be. The buyer question is no longer whether SAP can reach past S/4. It is where you want enterprise ownership and semantics to live across SAP, non-SAP and whatever agents you add next.

If your world is mostly SAP-centered, MDG may be the control plane you want. If product, supplier, customer and location must stay independent of one ERP suite, and must serve PLM, PIM, CRM, channels and AI consumers from one semantic model, an independent multidomain layer or a deliberate coexistence model is the diligence item. Stibo Systems’ STEP is one answer in that category. It is not the only one. ViaMedici and Syndigo also sell multidomain MDM alongside product content, with different strengths in manufacturing complexity and retail syndication. The shortlist is the architecture choice, not a single vendor name. “We bought MDG” is not the same sentence as “our PIM and our supplier portal share the same product identity the agent will call.”

A product in the real business is rarely only an SAP material. It is material attributes plus PIM content, PLM specifications, regional classifications and supplier relationships. Governing the complete business meaning is the AI-ready bar. Assuming every relevant attribute belongs in one application is the cutover bar.

What we would do if we were mid-S/4 this quarter

We would not reopen the whole program for a philosophy debate. We would widen three scopes before the workstream freezes.

First, list every system that currently holds a competing definition of product, supplier or customer: PIM, PLM, portals, regional databases, ecommerce. Put each on the master data map with an owner, even if the first release only harmonizes identifiers and a short mandatory set.

Second, encode the rules that decide valid, complete and duplicate in the platform, not in a SharePoint guideline. Tie lineage to changes so an AI input can be traced.

Third, ask the AI question in the same steering pack as cutover readiness. Can an agent follow supplier to material to sellable product to market price without a human copying fields between three tools? If the answer is no, the migration is still on track for ERP. It is not on track for agentic work.

Fixing this during the program adds work. Fellowes’ claim, and the one we would test with a program lead, is that data rationalization can run in parallel with process design and testing rather than as a bolted-on phase. Skipping it pushes the inconsistencies into UAT and the months after go-live, where they are louder and more expensive.

S/4HANA standardizes how processes run. Master data standardizes what the data means. AI agents reasoning across product, supplier and finance depend on that meaning already existing. The program is the rare free shot. After go-live, the same cleanup is just another AI project with a data tax attached.

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