10 fouten bij ERP-modernisering die u moet vermijden

De fouten bij ERP-modernisering die de meeste schade aanrichten zijn strategisch, niet technisch: de go-live als eindstreep zien, legacyprocessen naar het nieuwe systeem kopiëren, te laat beginnen met data en verandermanagement, alles in het ERP-systeem bouwen en licenties tekenen zonder vijfjarenmodel. Ze worden zelden direct zichtbaar. Ze komen na de go-live aan het licht, wanneer de beloofde efficiëntiewinst uitblijft en de workarounds terugkomen.

Dit artikel is voor CIO's, CFO's en programmadirecteuren die een S/4HANA- of andere ERP-modernisering plannen of redden. Bij elke fout hieronder staat hoe die er in de praktijk uitziet en wat de oplossing is, gevolgd door een checklist met vroege waarschuwingssignalen van één pagina en wat de SAP-wijzigingen van 2026 betekenen.

Ik heb goed gefinancierde projecten met ervaren teams en een volle bank adviseurs toch tekort zien schieten. De oorzaak is zelden het systeem. Het zijn gaten in eigenaarschap, integratieplanning en communicatie tussen teams die beslissingen nemen die van elkaar afhangen.

1. De go-live als eindstreep zien

Zodra het systeem live is, gaan veel teams ervan uit dat het zware werk achter de rug is. Dan begint de echte druk: dagelijkse operatie, veranderende eisen en echt gebruikersgedrag zetten het ontwerp onder druk.

Ik heb projecten gezien waar de stuurgroep direct na de go-live wordt opgeheven. Zes maanden later stagneert de adoptie en is niemand eigenaar van de backlog.

De oplossing: financier een governanceperiode van 6 tot 12 maanden na de go-live. Verleng het mandaat van de stuurgroep. Monitor de adoptie van processen, niet alleen de beschikbaarheid. Stel quality gates na de go-live in met benoemde eigenaren.

2. Legacyprocessen migreren zonder ze te heroverwegen

Ik heb complete goedkeuringsketens precies zo zien nabouwen als ze waren, zelfs toen de helft van de betrokkenen niets met het huidige proces te maken had. Niemand had gevraagd of de stappen nog nodig waren. Het resultaat was een modern ERP-systeem met oude workflows: een duurdere versie van wat ze al hadden.

De S/4HANA-variant hiervan: maatwerk-batchjobs die ongewijzigd uit ECC worden overgenomen, gebouwd op tabelstructuren die niet meer bestaan. De migratie is technisch zuiver. De bedrijfslogica is kapot.

De oplossing: ontwerp processen opnieuw voordat de bouw begint. Loop met operations, finance en de leveringsteams samen elke workflow door en stel elke stap ter discussie.

Legacygebied	Wat vaak misgaat	Wat u in plaats daarvan doet
Maatwerkcode uit ECC	Ongebruikte maatwerkcode wordt naar S/4HANA meegenomen	Voer een gebruiksanalyse en de custom code checks van SAP uit; zet ongebruikte code buiten gebruik
Oude workflows	Goedkeuringsflows worden nagebouwd terwijl automatisering nu mogelijk is	Loop ze opnieuw door met de business owners; gebruik standaard Fiori-apps of SAP Build Process Automation
Niet-standaard stamgegevens	Flexibele legacy-inrichtingen komen niet door de validatie van S/4HANA	Zuiver en harmoniseer vóór de migratie, met SAP MDG waar dat past
Rapporten op legacytabellen	Directe tabeltoegang past niet bij het datamodel van S/4HANA	Bouw opnieuw op CDS views
Verborgen handmatige workarounds	Zijprocessen verschijnen na de go-live opnieuw	Gebruik process mining vóór de migratie en digitaliseer de gaten

3. Te laat beginnen met datamigratie

Slechte data naar een nieuw ERP-systeem verhuizen is als verhuizen zonder iets weg te gooien. De rommel gaat mee en is moeilijker op te ruimen zodra die in een gestructureerd systeem zit.

Ik heb ooit een go-live zien mislukken omdat niemand had opgemerkt dat een kerndataset records bevatte van vijf verschillende businessunits, elk met een eigen coderingslogica. De technische migratie was correct. De data was onbruikbaar. Rapporten braken, gebruikers verloren vertrouwen en het opruimen onder een live systeem kostte maanden.

De oplossing: maak van data een workstream met verantwoordelijkheid bij de business. Wijs procesverantwoordelijken aan, niet alleen technische consultants. Besluit wat u overneemt, archiveert of opnieuw opbouwt voordat de migratie begint. Voer minstens twee volledige mock loads uit, met een afhankelijkheidskaart voor de laadvolgorde en een gedefinieerde rollback voor elke load. Mijn artikel over waarom SAP-datamigratie mislukt gaat dieper in op dit onderwerp.

4. Verandermanagement als bijzaak behandelen

De gebruikelijke variant: verandermanagement is „al geregeld”, wat neerkomt op een paar dia's, een demo en één trainingssessie vóór de go-live.

Mensen verzetten zich niet omdat ze een hekel hebben aan verandering. Ze verzetten zich wanneer niemand uitlegt waarom dingen veranderen of hoe het hen helpt. Ze volgen het systeem net genoeg om de checklist te halen en gaan dan terug naar spreadsheets.

De gebruikelijke aanleiding is tijdsdruk: de training wordt ingekort om tijd terug te winnen, gebruikers worden bij de go-live overspoeld en de extra hypercare kost meer dan de training die is geschrapt.

De oplossing: geef verandermanagement vanaf het begin een eigen budget, een eigen planning en een senior eigenaar. Breng rollen vroeg in kaart, zoek lokale ambassadeurs en volg adoptie-KPI's naast de technische mijlpalen. Mijn gids voor een plan voor verandermanagement beschrijft de structuur.

5. Plannen op basis van roadmaps van leveranciers

Ik heb teams hun integratiestrategie zien baseren op een toekomstige release van een leverancier, die vervolgens 12 maanden werd uitgesteld. Intussen zaten ze vast aan het bouwen van tijdelijke workarounds, en die workarounds werden permanent.

Leveranciers maken roadmaps voor brede klantgroepen. Uw bedrijf staat zelden centraal in dat ontwerp.

De oplossing: behandel de roadmap als één van de inputs. Ontwerp rond wat vandaag algemeen beschikbaar is, test nieuwe functies in een sandbox voordat u erop plant en reken baten uit de roadmap als meevaller, niet als budget.

6. Geen plan voor het uitfaseren van legacysystemen

Ik heb ooit een bedrijf gezien dat jaarlijks een zescijferig bedrag betaalde om een oud systeem draaiend te houden voor zes gebruikers die twee keer per jaar rapporten nodig hadden. Niemand had een plan voor het uitfaseren opgesteld.

De oplossing: neem het uitfaseren vanaf dag één op in het projectcharter, met juridische zaken, compliance en datagovernance erbij, niet alleen IT. Spreek bewaartermijnen en een archiefaanpak af vóór de go-live, breng elke interface naar het oude systeem in kaart en koppel die af, en geef één team de opdracht om het uit te zetten.

7. De complexiteit van integratie onderschatten

Als integratie faalt, merkt de business het eerder dan IT, omdat workflows halverwege het proces stilvallen in productie, niet in een testsysteem.

Het gebruikelijke patroon: IT en de business gaan er allebei van uit dat de ander de integratie-eisen heeft vastgelegd. Geen van beiden heeft dat gedaan. Tegen de tijd dat de gaten bij het testen zichtbaar worden, is er geen tijd meer om opnieuw te ontwerpen.

De oplossing: begin met het integratieontwerp in de blueprintfase. Leg elk scenario, de middleware, de mapping en de berichtvolumes vast en stem per interface met de business af of het realtime of batch moet. Wijs vóór de go-live een interface-eigenaar aan met een SLA. Voor nieuwe SAP-programma's is de middleware SAP Integration Suite; SAP PI/PO valt eind 2027 uit het reguliere onderhoud.

8. Aannemen dat het ERP-systeem alles aankan

Ik heb gewerkt aan projecten waar teams complexe servicewerkstromen (IT-tickets, aanvragen voor assets, escalatieroutering) in het ERP-systeem dwongen omdat ze geen externe systemen zoals ServiceNow erbij wilden betrekken. Het resultaat waren overal maatwerkvelden, handmatige workarounds en gebruikers die vastzaten in een proces dat nooit paste.

ERP is sterk in gestructureerde, transactionele, financieel verankerde processen. Gespecialiseerde platforms doen IT-serviceverzoeken, workflow-orkestratie en kennisbeheer beter.

De oplossing: besluit bewust wat u niet in het ERP-systeem bouwt. Gebruik side-by-side-extensies op SAP BTP voor uitzonderingen, en ServiceNow of vergelijkbaar voor orkestratie buiten de transactionele kern. Mijn artikel over ERP-modernisering met SAP en ServiceNow behandelt die scheiding.

9. De licentiekosten op lange termijn onderschatten

Ik ken een team dat in jaar twee zijn licentie-uitgaven verdubbelde omdat het één functie nodig had die achter een hogere licentieklasse zat. De businesscase had alleen de kosten tot en met de go-live gemodelleerd.

ERP-licenties rekenen af op gebruikers, modules, transacties en API-gebruik, en de kosten schalen mee met het bedrijf, of u daarvoor hebt gepland of niet. Bij SAP betekent het Digital Access-model dat documenten die door systemen van derden worden aangemaakt licentiekosten kunnen hebben die niet in het oorspronkelijke commerciële model zaten. Onder RISE en SAP GROW groeit het aantal Full User Equivalents (FUE) mee met de adoptie.

De oplossing: bouw vóór het tekenen een licentiemodel voor drie tot vijf jaar. Koppel rollen aan licentietypen, modelleer de FUE-groei op een realistische adoptiecurve, begrijp indirecte toegang voordat u externe systemen koppelt en controleer na de go-live op inactieve gebruikers.

10. ERP als IT-project behandelen

Het meest voorkomende en meest schadelijke patroon. De planning begint bij IT, wordt geleid door IT en lost IT-problemen op.

Ik heb teams op papier elke mijlpaal zien halen terwijl de business zich nog steeds afvraagt waarom niets beter aanvoelt. Dat betekent meestal dat het ERP-systeem is gebouwd voor de processen van gisteren, zonder leiders uit operations, finance of commercie in het ontwerp.

De oplossing: zet vanaf het begin leiders uit commercie, finance en operations in de stuurgroep. Leg strategische afstemming vast in het charter, niet alleen de technische scope. Toets de doelen van het programma aan resultaten op bestuursniveau voordat het ontwerp begint.

Gebruik deze bij elke stuurgroep. Is een waarschuwingssignaal aanwezig, dan rapporteert de benoemde eigenaar erover totdat het is verdwenen.

1. CharterEigenaarschap en kostenGeen lead uit operations of finance, geen licentiemodel voor vijf jaar, geen datum voor uitfasering
2. BlueprintProces- en integratieontwerpHet huidige proces gekopieerd, interfaces nog niet ontworpen
3. Eerste mock loadDataNog geen rapport over datakwaliteit
4. Go-liveWat daarna gebeurtGeen gefinancierde governance voor de 12 maanden erna

Fout	Vroeg waarschuwingssignaal	Eigenaar
1. Go-live als eindstreep	Geen gefinancierd governanceplan voor de 12 maanden na de go-live	Sponsor
2. Gekopieerde legacyprocessen	Ontwerpworkshops starten vanuit schermen met „hoe we het nu doen”	Procesverantwoordelijken
3. Late data-aanpak	Geen rapport over datakwaliteit vóór de eerste mock load	Lead datamigratie
4. Verandermanagement als bijzaak	Het verandermanagementplan is een trainingskalender	Change lead
5. Afhankelijkheid van de roadmap	Een ontwerpbeslissing wacht op een functie die nog niet is uitgebracht	Oplossingsarchitect
6. Geen uitfasering	Geen uitfaseringsdatum voor enig legacysysteem in het charter	PMO
7. Integratie onderschat	Interfaces aan het eind van de blueprint niet ontworpen	Integratielead
8. ERP voor alles	Maatwerkobjecten voor niet-transactionele workflows	Enterprise-architect
9. Licenties	Geen licentiemodel voor vijf jaar in de businesscase	CFO
10. Programma alleen vanuit IT	De stuurgroep heeft geen lead uit operations of finance	Sponsor

Uitrolmodel. Voor nieuwe SAP-programma's is de standaard RISE with SAP op SAP Cloud ERP Private, of SAP GROW op de public edition (SAP Cloud ERP) voor middelgrote bedrijven. Nieuwe on-premise-uitrol is zeldzaam. ECC-klanten krijgen te maken met het einde van het reguliere onderhoud op 31 december 2027, wat de tijd verkort die er is om fouten 2, 3 en 7 te herstellen.

Clean core. SAP beoordeelt extensies nu op vier clean core-niveaus, van A (alleen vrijgegeven API's, side-by-side op BTP of in het systeem met ABAP Cloud) tot D (niet clean). De public edition staat alleen niveau A toe, wat het gesprek afdwingt dat achter fout 2 zit. De private edition staat nog klassieke extensies toe, dus de discipline moet uit governance komen. Klassieke maatwerkcode is wat van elke upgrade een project maakt. Mijn artikel over clean core-strategie gaat verder.

AI in de delivery-tooling. Joule zit nu in SAP Cloud ALM en de SAP Activate Roadmap Viewer, en SAP Build Code gebruikt Joule voor het ontwikkelen van extensies. Vraag partners hoe AI-tooling terugkomt in hun tarievenkaart. Zo niet, dan is de prijs hoog of verdwijnt de besparing in hun marge.

Lifecycle-tooling. SAP Cloud ALM is de tool voor lifecyclemanagement bij cloudprogramma's. Solution Manager 7.2 valt eind 2027 uit het reguliere onderhoud, dus landschappen waar beide draaien hebben een plan nodig voor de overstap.

De tien fouten zijn niet veranderd. De kosten van het fout doen wel. Bij een RISE-programma liggen de clean core-beslissing, het uitrolmodel en het FUE-model allemaal vast in de eerste weken van de mobilisatie. Het venster om ze te beïnvloeden is kort.

Waarom schieten ERP-moderniseringen na de go-live tekort?

De meeste teams plannen tot de go-live en stoppen dan. Niemand is eigenaar van verbeteringen, feedback, procescorrecties of de backlog. Een stuurgroep die bij de go-live wordt opgeheven is het meest betrouwbare teken van problemen. Financier vanaf dag één 6 tot 12 maanden governance na de go-live.

Wat is het risico van het kopiëren van legacyprocessen naar een nieuw ERP-systeem?

Het nieuwe systeem erft de oude inefficiënties tegen hogere kosten. Bij S/4HANA-migraties werken maatwerkcode en batchjobs die voor ECC-tabellen zijn gebouwd vaak niet, waardoor de migratie technisch zuiver kan zijn terwijl de bedrijfslogica kapot is.

Hoe schaadt slechte datakwaliteit een ERP-modernisering?

Dubbele leveranciers, inconsistente stamgegevens, legacycodes en onvolledige records gaan allemaal mee naar het nieuwe systeem tenzij iemand ze eerst opschoont. Rapporten breken, gebruikers vertrouwen de cijfers niet meer en het opruimen onder een live systeem kost maanden.

Waarom wordt verandermanagement in ERP-projecten zo vaak onderschat?

Omdat het in een projectplan niet zichtbaar is zoals configuratie dat is. Bestuurders nemen aan dat een paar trainingssessies genoeg zijn. Verandermanagement is mensen voorbereiden op wat er daadwerkelijk verandert in hun dagelijkse werk, vóór de go-live. Digital adoption-tools zoals WalkMe, nu eigendom van SAP, helpen met begeleiding in de applicatie, maar ze vervangen de uitleg van het waarom niet.

Waarom blijven legacysystemen jarenlang draaien na de go-live van het ERP-systeem?

Omdat niemand van plan was ze uit te zetten. Iedereen richt zich op het live krijgen van het nieuwe ERP-systeem en de oude systemen blijven aan voor compliance, naslag of gemak. Het uitfaseren moet vanaf dag één in scope zijn, met juridische zaken en compliance erbij.

Hoe veranderen RISE with SAP en clean core deze fouten?

Op de public edition maken de clean core-regels diepgaand maatwerk onmogelijk, wat het procesgesprek afdwingt dat achter fout 2 zit. Op de private edition zijn klassieke extensies nog toegestaan, dus clean core hangt af van governance. Integratie verhuist naar SAP Integration Suite nu het onderhoud van PI/PO afloopt. Licenties worden een vraag over FUE-groei. Het uitfaseren wordt urgenter omdat het parallel laten draaien van legacysystemen kosten toevoegt bovenop een meerjarig abonnement.