ERP-modernisering in 2026: cloud, AI en clean core

ERP-modernisering in 2026 betekent drie beslissingen in volgorde: wat uw ERP moet ophouden te doen, hoe schoon u de core houdt en of uw data goed genoeg is om AI nuttig te maken. Voor SAP-klanten staat achter alle drie een harde datum: het mainstream-onderhoud van ECC eindigt op 31 december 2027, met betaald verlengd onderhoud tot eind 2030.

Dit is voor CIO's, CFO's en enterprise-architecten die de analyse hebben afgerond en nu moeten uitvoeren. Het behandelt de krachten die tot actie aanzetten, de architectuur met backbone en satellieten, clean core, de governancekloof, AI-gereedheid en een risicotabel voor de komende 18 maanden.

In 2024 kochten de meeste leiders nog tijd: ze bestudeerden ECC-tijdlijnen, discussieerden over hybride versus volledige migratie en draaiden sandboxtests zonder zich te committeren. Dat venster is gesloten. De technische schuld in ECC- en Oracle E-Business Suite-landschappen is niet langer theoretisch. Ze toont zich in mislukte regressietests na updates, in auditbevindingen over maatwerkcode waar niemand eigenaar van is, en in data die 12 uur nodig heeft om tussen planning- en uitvoeringssystemen te komen.

De deadline. Na 2027 kunnen ECC-klanten tegen een hogere vergoeding verlengd onderhoud afnemen tot eind 2030. Daarna biedt SAP een overgangsoptie voor ERP private edition voor 2031 tot 2033, maar alleen via RISE, en SAP is expliciet dat het een betaald overgangsaanbod is, geen verlenging van het onderhoud. Intussen constateerde Gartner-onderzoek, gemeld door The Register, dat eind 2024 slechts ongeveer 39% van de circa 35.000 ECC-klanten van SAP S/4HANA-licenties had gekocht of afgenomen. Gelicentieerd is niet hetzelfde als gemigreerd. De partnermarkt wordt krap.

Het budgetmodel. Cloud-ERP verschuift uitgaven van capex-licenties naar abonnementen. Dat klinkt schoner. In de praktijk vinden CFO's cloudkosten minder voorspelbaar: onder RISE with SAP en SAP GROW voegen de groei van Full User Equivalent (FUE), add-onservices en integratieoverhead kosten toe die niet in de oorspronkelijke businesscase zaten.

Fragmentatie in finance en supply chain. Financeteams draaien AI op crediteuren en debiteuren terwijl auditprocessen nog templates gebruiken die voor een ander tijdperk zijn gebouwd. Supply chains zijn deels gemoderniseerd: SAP IBP voor planning, ouder warehouse management voor uitvoering, Ariba voor inkoop maar handmatige goederenontvangsten. Het knelpunt is niet de technologie. Het zijn de koppelingen tussen systemen.

ERP is één laag, niet de hele stack. ServiceNow draait in veel enterprises de procesorkestratie, Salesforce de klantworkflows, Workday of SuccessFactors de HR-levenscyclus. ERP is de financiële backbone geworden, niet de alles-in-één proceshub waarvoor het in de jaren negentig werd verkocht.

Het model waarmee de meeste enterprise-architecten nu werken, is een financiële backbone (SAP S/4HANA of Oracle Fusion) omringd door gespecialiseerde platforms.

Laag	Wat hier zit	Wat hier niet zit
Financiële backbone	Grootboek, controlling, inkoop, voorraad, productie-uitvoering, wettelijke afsluiting	Workflowgoedkeuringen, CRM, workforce management, analytics
Workflow	ServiceNow voor IT- en operationele processen, goedkeuringen, wijzigingsbeheer	Transactionele vastlegging
Klantbetrokkenheid	Salesforce of SAP Sales and Service Cloud	Financiële verwerking
Workforce	Workday of SAP SuccessFactors	Operationele transacties
Analytics	SAP Business Data Cloud, SAP Analytics Cloud, Power BI, Snowflake	Het system of record

De scheiding is bewust. Alles terug in SAP proppen voegt wrijving toe, vertraagt updates en vertroebelt het eigenaarschap. CRM, workflow, analytics en EHS in één systeem proppen is wat eerdere programma's zo pijnlijk maakte.

De vraag om te stellen: waar moet het ERP niet meer voor verantwoordelijk zijn? Sla die over en u bouwt dezelfde monoliet opnieuw op een nieuwere licentie. Mijn stuk over ERP-modernisering met SAP en ServiceNow werkt één variant van die splitsing uit.

In augustus 2025 verving SAP zijn extensibility-model met drie lagen door vier clean core-niveaus. Niveau A gebruikt alleen vrijgegeven, stabiele API's, side-by-side op SAP BTP of in het systeem met ABAP Cloud. Niveau B gebruikt klassieke API's en technologieën die SAP nog als clean beschouwt. Niveau C reikt naar interne objecten en vraagt speciale maatregelen. Niveau D is niet clean.

De public edition (SAP Cloud ERP, verkocht als SAP GROW) staat alleen niveau A toe, dus het platform dwingt clean core af en absorbeert twee grote releases per jaar. De private edition (SAP Cloud ERP Private, onder RISE) en on-premise staan nog klassieke extensies toe, dus clean core hangt daar af van governance. Hoe dan ook: een zwaar aangepast systeem maakt van elke upgrade een project en van elke regressietest een crisis.

Wat clean core van u vraagt:

1. Haal ongebruikte maatwerkcode uit de core. Elk maatwerkprogramma dat u behoudt, moet u bij elke upgrade testen.
2. Bouw nieuwe extensies waar mogelijk op niveau A: op SAP BTP, met SAP Build of in het systeem met ABAP Cloud.
3. Gebruik standaardprocessen overal waar SAP ze levert en pas alleen aan waar regelgeving of een echt concurrentieverschil dat vereist.

De weerstand is cultureel, niet technisch. Businessleads die 15 jaar op maatwerkcode vertrouwden, verwachten nog steeds dat het “gewoon opnieuw wordt gebouwd”. Die verwachting hoort bij 2012.

Een typisch ECC-landschap telt 1.500 tot 3.000 maatwerkobjecten, op basis van assessments die ik heb uitgevoerd in maakindustrie en dienstverlening, en slechts ongeveer een kwart laat actief zakelijk gebruik zien. De rest is historisch ballast die de migratiekosten opdrijft en auditrisico oplevert.

De praktische stap: draai nu een usage scan. Zet uit gebruik wat inactief is. Publiceer een cut list voordat het ontwerp begint. Teams die clean core vanaf week één plannen, hebben veel betere upgradeervaringen dan teams die het zien als een beperking om omheen te werken. Mijn artikel over clean core-strategie gaat dieper in op de methode.

Nu ERP één laag onder velen is, wordt de vraag van eigenaarschap kritiek. Wie is eigenaar van:

1. De API tussen Salesforce en het ERP?
2. Een workflow die SAP en ServiceNow overspant?
3. Conflicterende wijzigingsprioriteiten wanneer beide systemen tegelijk updates nodig hebben?

Ik heb gezien dat dit go-lives maanden vertraagt. Teams realiseren zich niet dat ze vastzitten tot integratietests de overlap blootleggen.

In één geval raakten vijf systemen hetzelfde leveranciersstamrecord aan. Vijf. Niemand had een eigenaarsdocument voor stamgegevens, en niemand had ontworpen wie wat mocht wijzigen, in welk systeem. Dat is geen technologiefout. Het is een governancefout die de technologie blootlegde.

AI-waarde in ERP is echt, maar hangt af van datakwaliteit en een schone architectuur. Joule beslaat nu S/4HANA, SuccessFactors, Ariba en andere SAP-producten, en de agents van SAP draaien onder Joule-assistenten. Agentic use cases op SAP BTP worden opgeleverd, het is geen slideware. Ze hangen allemaal af van schone, consistente, gestructureerde data.

Als uw data dubbel is, inconsistent gecodeerd of in maatwerktabellen staat die S/4HANA niet herkent, heeft AI niets betrouwbaars om mee te werken. Financeteams die AI op crediteuren draaien, merken dat snel: facturen worden aan de verkeerde leverancier gematcht omdat de leveranciersstamgegevens nooit zijn opgeschoond.

De volgorde die werkt: eerst clean core, dan datagovernance, dan analytics, dan AI. Stappen overslaan versnelt niets. Het verplaatst het probleem naar later.

1. 01Stel de grens vastBeslis wat het ERP niet meer moet doen
2. 02Maak de core schoonZet ongebruikte code uit gebruik, bouw nieuw op niveau A
3. 03Beheer de dataEén eigenaar per dataobject
4. 04Bouw de analyticsSAP Business Data Cloud, SAC of Power BI op beheerde data
5. 05Voeg AI toeJoule en agents op een betrouwbare basis

AI met iets betrouwbaars om op te werken

Risico	Signaal	Praktische reactie
Druk door de ECC-deadline	Mainstream-onderhoud eindigt december 2027; de meeste ECC-klanten hadden eind 2024 geen S/4HANA-licentie	Leg nu de resourceplannen met partners vast; senior dagtarieven in de VS liggen al op $1.800 tot $3.500
Maatwerkcodeschuld	1.500 tot 3.000 maatwerkobjecten, ongeveer een kwart in actief gebruik	Draai usage scans, publiceer een cut list, start sprints om code uit te faseren
Verstoring door releases	Releases botsen met financiële afsluiting en pieken in de supply chain	Plan releasevensters buiten de afsluiting; automatiseer regressietests
Risico bij datamigratie	Late harmonisatie levert defecten op die teams ten onrechte als bugs bestempelen	Vroege dimensionering; controles van bank-, belasting- en compliancedata vóór de designfreeze
Gaten in integratie-eigenaarschap	Vijf of meer systemen die gedeelde stamgegevens raken	Publiceer een autoriteitsmatrix; één eigenaar per dataobject
Twee lifecycle-tools	Hybride landschappen draaien Solution Manager en SAP Cloud ALM naast elkaar	Cloud ALM als standaard voor cloudprogramma's; mainstream-onderhoud van Solution Manager 7.2 eindigt eind 2027

Voor de uitvoeringsversie van deze risico's, zie tien fouten bij ERP-modernisering die u moet vermijden, en voor de migratiepaden zelf de gids over de migratie van ECC naar S/4HANA.

Wat is clean core in SAP S/4HANA?

S/4HANA zo dicht mogelijk bij de standaard houden en extensies neerzetten waar upgrades ze niet kunnen breken. Sinds augustus 2025 beoordeelt SAP extensies van niveau A (alleen vrijgegeven API's, op SAP BTP of in het systeem met ABAP Cloud) tot niveau D (niet clean). De zakelijke reden is bescherming bij upgrades: een clean systeem absorbeert releases in dagen, een zwaar aangepast systeem maakt van elke release een project.

Wat is de architectuur met backbone en satellieten voor ERP?

Het ERP (SAP S/4HANA of Oracle Fusion) doet waarvoor het gebouwd is: financiële administratie, voorraad, inkoop, productietransacties en wettelijke rapportage. Gespecialiseerde platforms doen de rest: ServiceNow voor workflow, Salesforce voor klantbetrokkenheid, Workday of SuccessFactors voor HR en analyticsplatforms voor inzicht. Dat allemaal in het ERP proppen levert een monoliet op die traag wordt bijgewerkt en zwaar wordt aangepast.

Hoe pakken bedrijven de SAP ECC-deadline van 2027 aan?

Begin met SAP Readiness Check. Die brengt het volume aan maatwerkcode, afhankelijkheden van add-ons en datadimensionering in kaart, de drie factoren die bepalen of u brownfield, greenfield of selectief gaat. Complexe enterprise-migraties duren doorgaans 18 tot 24 maanden van assessment tot go-live. Als u dus nog geen aanpak hebt gekozen en gesprekken met partners hebt gestart, is een go-live in 2027 nu al krap. Verlengd onderhoud tot 2030 kost meer en koopt tijd, geen innovatie.

Wanneer is AI waardevol bij ERP-modernisering en wanneer niet?

Wanneer de data schoon, consistent en gestructureerd is en het proces duidelijke regels heeft: automatisering van crediteuren, vraagvoorspelling en anomaliedetectie in financiële transacties zijn bewezen cases. AI is geen sluiproute langs slechte data of governancegaten. Beslissingen op basis van slechte input zijn moeilijker te onderscheppen dan handmatige fouten. Clean core, datagovernance en stabiele processen komen eerst.

Wat zijn de grootste fouten die bedrijven maken bij ERP-modernisering?

Het behandelen als een technologieproject, waardoor het clean core-debat al is verloren voordat de businessleads aan tafel zitten. Datagovernance starten na het ontwerp, terwijl beslissingen in week één maanden testen hadden bespaard. Niet definiëren wat het ERP moet ophouden te doen, waardoor de core-scope standaard uitdijt, en zo is de vorige monoliet gebouwd.

Wat kost ERP-modernisering?

Een brownfield-conversie van ECC naar S/4HANA kost voor een bedrijf in het middensegment doorgaans $2 tot $8 miljoen aan implementatiekosten, plus het doorlopende abonnement. Enterprise-programma's met wereldwijde scope, veel maatwerk en veel entiteiten kunnen $20 tot $100 miljoen of meer kosten. Neem naast licenties ook integratie, testen en operationele ondersteuning mee in het model, en modelleer onder RISE en SAP GROW de FUE-groei over de looptijd van het contract.