Je S/4HANA-programma is de laatste gratis kans op AI-ready productstamdata

De meeste S/4HANA-programma's besturen materiaal-, businesspartner- en financiële data goed genoeg om over te gaan. Dat is de ERP-klus. Het is niet de AI-klus.

AI-agenten lezen geen SAP-object tegelijk. Ze redeneren over relaties: welke leverancier hoort bij welk materiaal, welk materiaal voedt welke productconfiguratie, welke configuratie draagt welke prijs in welke markt. Die keten leeft meestal half in SAP en half in PIM, PLM, CRM, leveranciersportalen en regionale databases. Als het programma alleen opschoont wat S/4 nodig heeft om te starten, houden die aangrenzende systemen hun eigen definities van hetzelfde ding. De migratie slaagt nog steeds. De agent loopt nog steeds een puinhoop binnen.

Damien Fellowes van Stibo Systems maakt dat punt in Turn your SAP S/4HANA migration into an AI-ready data foundation. De praktische les voor PIM-kopers is scherper dan weer een MDM-pitch. Een S/4-programma is een van de weinige momenten waarop stamdata tegelijk budget en executive aandacht krijgt. Mis dat raam, en je bouwt de fundering later opnieuw voor een AI-initiatief dat geen van beide heeft.

Wat "goed genoeg voor cutover" echt achterlaat

ERP-gecentreerde MDM optimaliseert bestuurde stamdata voor de modellen en processen die de ERP nodig heeft. AI-ready MDM breidt ownership, regels en relaties uit over domeinen, zodat een model de businesscontext kan vertrouwen, niet alleen het transactionele record.

Dat klinkt als een kleine scopewijziging. Dat is het niet. In veel programma's wordt de stamdata-workstream eerst gedefinieerd rond wat moet migreren en in S/4 moet draaien. Materiaal, partner en finance krijgen owners, regels en opschoning. Productcontent in de PIM, engineering specs in PLM, selfserviceportalen van leveranciers, e-commercecatalogi en regionale attributentabellen blijven "voorlopig buiten scope". Iedereen weet dat ze het oneens zijn over basisidentiteit. Niemand heeft een migratie-workstream die ze dwingt het eens te worden.

We hebben deze film in kleinere vorm al gezien. Onvolledige productgegevens zorgen ervoor dat je niet lager scoort. Het haalt je uit het antwoord. De autostoeltje-shortlist van Akeneo en de 44 procent databelasting zeggen hetzelfde vanaf de commercekant: het vertrouwen in AI is hoog, en een groot deel van de projectinspanning gaat nog steeds naar het reconciled maken van ontbrekende attributen en conflicterende productinformatie. Een S/4-cutover die PIM- en leveranciersdata buiten het bestuurde model laat, plant die belasting gewoon in voor de volgende budgetcyclus.

Het nuttige onderscheid van Fellowes is tussen governance documenteren en die encoderen. Een policy-PDF die zegt wie het productrecord bezit, voorkomt niet dat een druk kwartaal een tweede definitie in een retailerfeed ship. Regels die in het platform leven, met lineage en provenance op wijzigingen, geven een agent (en een auditor) iets om te volgen. Freshness telt ook. Pricing, voorraadherbbalancing en leveranciersrisicomonitors hebben actuele data nodig. Een fundering die alleen is gebouwd voor periodieke reconciliatie voor go-live, voedt die use cases niet.

Waarom de migratie het raam is

Buiten een transformatieprogramma is iedereen het erover eens dat stamdata een probleem is. Weinig mensen krijgen funding om het op enterpriseschaal te fixen. Concurrerende prioriteiten winnen elk kwartaal.

Een S/4-programma forceert de vragen die meestal onbeantwoord blijven: wie bezit deze data, wie handhaaft de regels, hoe worden regionale varianten reconciled. Het budget en het projectteam staan er al. Na go-live verplaatst die geconcentreerde sponsorship meestal. Je kunt stamdata later nog opschonen. Je hebt dan een nieuwe businesscase, een nieuwe sponsor en een nieuwe fundingcyclus nodig om hetzelfde werk te doen.

Dat betekent niet dat MDM de migratietools van SAP vervangt. SAP voert de transitie nog steeds uit en valideert die. De stamdatalaag bereidt voor, harmoniseert en bestuurt waar die processen op leunen, en blijft na cutover besturen over het bredere landschap. Stibo noemt een manufacturingklant die, als onderdeel van de S/4-reis, meer dan 200 legacy-datamodellen terugbracht naar vijf semantische modellen over 500-plus applicaties en 1.000-plus interfaces. Het getal is minder interessant dan de vorm van het werk: minder gedeelde betekenissen, niet meer point-to-point mappings.

SAP MDG is niet het verkeerde antwoord. Het is de verkeerde grens als je daar stopt.

SAP Master Data Governance kan SAP- en third-party-data besturen en consolideren. Met Reltio in SAP Business Data Cloud is het multidomainverhaal van SAP breder dan vroeger. De kopersvraag is niet langer of SAP voorbij S/4 kan reiken. Het is waar je enterprise ownership en semantiek wilt laten leven over SAP, non-SAP en welke agenten je daarna toevoegt.

Als jouw wereld vooral SAP-gecentreerd is, kan MDG het control plane zijn dat je wilt. Als product, leverancier, klant en locatie onafhankelijk van één ERP-suite moeten blijven, en PLM, PIM, CRM, kanalen en AI-consumers vanuit één semantisch model moeten bedienen, is een onafhankelijke multidomainlaag of een bewuste coexistence het diligence-punt. STEP van Stibo Systems is één antwoord in die categorie. Het is niet het enige. ViaMedici en Syndigo verkopen ook multidomain MDM naast productcontent, met andere sterktes in manufacturingcomplexiteit en retailsyndicatie. De shortlist is de architectuurkeuze, geen enkele vendornaam. "We hebben MDG gekocht" is niet dezelfde zin als "onze PIM en ons leveranciersportaal delen dezelfde productidentiteit die de agent gaat aanroepen."

Een product in de echte business is zelden alleen een SAP-materiaal. Het is materiaalattributen plus PIM-content, PLM-specificaties, regionale classificaties en leveranciersrelaties. Het besturen van de volledige businessbetekenis is de AI-ready lat. Aannemen dat elk relevant attribuut in één applicatie hoort, is de cutover-lat.

Wat we zouden doen als we dit kwartaal midden in S/4 zaten

We zouden het hele programma niet heropenen voor een filosofiedebat. We zouden drie scopes verbreden voordat de workstream bevriest.

Eerst: lijst elk systeem dat nu een concurrerende definitie van product, leverancier of klant houdt: PIM, PLM, portalen, regionale databases, e-commerce. Zet elk op de stamdatakaart met een owner, ook als de eerste release alleen identifiers en een korte verplichte set harmoniseert.

Tweede: encodeer de regels die bepalen wat valid, compleet en duplicaat is in het platform, niet in een SharePoint-richtlijn. Koppel lineage aan wijzigingen zodat een AI-input te traceren is.

Derde: stel de AI-vraag in hetzelfde steering pack als cutover-readiness. Kan een agent van leverancier naar materiaal naar verkoopbaar product naar marktprijs volgen zonder dat een mens velden tussen drie tools kopieert? Als het antwoord nee is, ligt de migratie nog op schema voor ERP. Niet voor agentic werk.

Dit fixen tijdens het programma voegt werk toe. De claim van Fellowes, en die we met een programmalead zouden testen, is dat data-rationalisatie parallel kan lopen met process design en testing, in plaats van als een aangesoldeerde fase. Overslaan duwt de inconsistenties de UAT in en de maanden na go-live, waar ze luider en duurder zijn.

S/4HANA standaardiseert hoe processen draaien. Stamdata standaardiseert wat de data betekent. AI-agenten die over product, leverancier en finance redeneren, hangen af van die betekenis die er al is. Het programma is de zeldzame gratis kans. Na go-live is dezelfde opschoning gewoon weer een AI-project met een databelasting eraan.

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