Het begin, het succes en het einde van ERP in de metaal
Van MRP in de jaren 60 tot agentic AI in 2026, een eerlijk verhaal over vijf generaties ERP, vijf rode vlaggen, en waarom het model onder druk staat.
ERP in de metaal. Waar het vandaan komt, waarom het werkte, en waarom het model zoals we het kennen onder druk staat. Geen demo, geen code, gewoon een eerlijk verhaal.
Even over mijn achtergrond, want dat is relevant voor wat volgt.
Ik ben van huis uit werktuigbouwkundige (MTS + HBO), heb studies gedaan rondom innovatie en bedrijfskunde, en een opleiding tot SAP-consultant gevolgd (Business Systems Integrations). In mijn werk voor mijn werkgever was ik vier jaar lang projectleider voor het implementeren en koppelen van ERP, Ridder iQ in dat geval.
Daarna ben ik als zelfstandige verdergegaan met systeemkoppelingen, heb ik afgelopen 8 jaar meer dan twintig implementaties begeleid, en werk ik dagelijks met alle grote merken in de Nederlandse metaal. Bemet, MKG, ISAH, Navision / Business Central, Fledge, noem ze maar.
En het patroon is overal hetzelfde.
Alle merken die ik noem in dit artikel zijn puur ter illustratie, er is niets fundamenteel mis met ze en de nuance bestaat altijd. Dit is geen advies. Advies kun je van me afnemen via vanenkhuizen.com.
Ik spreek hier vanuit dagelijkse ervaring. En eerlijk gezegd ook een beetje frustratie (mag dat ook even?), want als je jarenlang met al die bestaande merken werkt, ga je patronen herkennen die je niet meer kunt negeren…
”Welk ERP moet ik kiezen?” is de verkeerde vraag
Ik krijg die vraag wekelijks. Ik denk dat ik zo’n dertigtal pakketten heb waar ik zelf bijna maandelijks naar kijk hoe die zich ontwikkelen. En ik snap de vraag, je wilt vooruit met je bedrijf, je zoekt een systeem. Maar daar zit een aanname achter die niet meer klopt: dat één pakket alles moet kunnen.
Er is een soort mythe in de markt dat een alles-in-één ERP-systeem voor de metaalbewerking bestaat dat gewoon werkt.
Ik heb honderden bedrijven gesproken en ik durf het eerlijk te zeggen: ik heb het nog nooit gezien dat iemand echt tevreden is.
Niet omdat de leveranciers slecht zijn, maar omdat je altijd te maken hebt met de afweging tussen een generiek proces en een specialistisch proces. De meeste metaalbedrijven zijn goed in enkelstuks en maatwerk, je kunt niet één pakket maken dat voor iedereen past.
Wat er dan gebeurt: er wordt een pakket gekozen vóórdat er is nagedacht over de grotere architectuur. En dan krijg je tekortkomingen. Dan ga je modules bijkopen, dan ga je maatwerk doen, dan komt er een consultant bij, en voor je het weet zit je in een complex landschap dat eigenlijk niemand meer overziet.
En vergeet niet: het hele businessmodel van huidige ERP-bedrijven is grotendeels gebaseerd op consultancy, niet hoofdzakelijk op licenties.
De consultancykosten zijn gemiddeld een factor vijf tot tien van de aanschafprijs. Hoe langer de implementatie duurt, hoe meer de leverancier verdient. Dat belang ligt niet altijd bij jou als klant.
De vraag zou eigenlijk moeten zijn: hoe breng ik het allemaal samen? Wat is mijn architectuur? Kan ik koppelen, aanpassen, en ben ik eigenaar van mijn eigen data? Ik schreef hier eerder uitgebreid over in Waarom ERP niet meer het centrum van je fabriek hoeft te zijn.
Vijf generaties software, en waar jij waarschijnlijk zit
Om te snappen waar we staan, moet je weten waar we vandaan komen. Want ERP heette vroeger helemaal geen ERP.
5 Generaties ERP
Gen 1 & 2, de basis.
De eerste systemen waren MRP: Material Requirements Planning. Denk aan: vrachtwagens met spullen op de juiste plek op het juiste moment, dat was het. Eigenlijk is de hele achtergrond van computers grotendeels gebaseerd op logistieke uitdagingen in het leger en grote handelsbedrijven, de eerste algoritmes die dat oplosten bestonden al in de jaren ‘60.
In de jaren ‘80 kwamen de eerste database-gedreven pakketten en begon het consultancymodel: een partij bouwde voor jou een maatwerkoplossing vanaf een eigen template. Ik zie tot op de dag van vandaag nog pakketten uit dat tijdperk in het wild draaien.
Gen 3, waar de meeste metaalbedrijven vandaag nog zitten.
Pakketten die je kon aanpassen: eigen schermen bouwen, tabellen toevoegen, koppelingen definiëren. Gebouwd op SQL- en Postgres-databases, .NET-frameworks. Hier is een hele industrie op ontstaan in Nederland, partijen die met branchekennis iets schaalbaars neerzetten voor bedrijven die zelf geen software-expertise hadden. En dat was een goede tijd om daarmee te beginnen.
Veel bedrijven zitten nu ergens tussen Gen 3 en Gen 4. Deels aanpasbare systemen, sterke branchekennis, maar nog geen volledige webinterface. Dat is niet per se een probleem, mits de fundamenten kloppen.
Gen 4, waar we nu zitten.
Hier gaat het om webbrowsers en webinterfaces. De meeste leveranciers zijn hier nu naartoe gegaan, of zijn hiermee als cloudnatives begonnen. Dit houdt in dat je in feite alles in je webbrowser uitvoert. Je hebt geen lokale softwareclient of lokale installatie meer nodig.
Een API, de stekkerdoos waarmee systemen met elkaar communiceren, is vooral een standaard geworden om dit te kunnen doen.
Maar let op het verschil: er zijn partijen die hun oude pakket in een webbrowser hebben omgebouwd, en er zijn partijen die vanaf dag één als webapplicatie zijn gebouwd.
Dat is niet hetzelfde. Een oud pakket dat je in de cloud zet is nog steeds een oud pakket, de architectuur verandert niet, alleen de factuur. Wie twijfelt of een ERP-upgrade de moeite waard is, leest ook: Moet je je ERP upgraden? Waarschijnlijk niet.
Gen 5, net begonnen, sinds 2025.
Dit heeft alles te maken met agentic AI, de drempel om te programmeren en de snel veranderende softwaremarkt op het gebied van specialistische apps. Denk aan: Claude Code met Opus 4.5+ en GPT 5.3… + platformen zoals N8N.
Ik merk het in mijn eigen werk. Ik heb een boekhoudpakket waar ik bijna niet meer inlog. Als ik een factuur wil sturen, vertel ik het aan een AI-agent. Die genereert een nieuwe klant, checkt btw-nummers, voegt de regels toe, kijkt naar eerdere verkopen, schrijft de juiste teksten erbij, en stuurt mij een bericht als hij klaarstaat. Als ik goedkeur met mijn stem, wordt de factuur verstuurd.
Ik ga alleen nog in het systeem als er een uitzondering is. De interface verdwijnt, het systeem werkt voor mij, niet andersom. Dit gaat ook zo werken bij veel maakbedrijven.
Wat ERP eigenlijk niet kan
Even een kanttekening die vaak vergeten wordt. Als je kijkt naar wat er allemaal in een ERP zit, dan mis je een paar dingen die voor de werkvloer essentieel zijn.
Er zit geen machine in. Er zitten geen 3D-viewers in. Er zit geen systeem in waarmee je uitgebreide werkinstructies kunt maken. Er zitten geen dingen in die te maken hebben met een gesloten loop op gedetailleerd productieniveau. Machinedata combineren met geregistreerde productiedata, stilstandregistratie, vragenlijsten bij verstoringen, dat past eigenlijk niet in ERP.
Dat zijn allemaal dingen die je of met maatwerk moet oplossen, of met kostbare integraties. En daardoor krijg je weer een complex landschap. ERP op zich is gewoon een benoeming van een aantal functionaliteiten die varieren per pakket. Ieder pakket heeft z’n sterktes en z’n zwaktes. Wie wil weten hoe een Manufacturing Execution System dat gat vult, vindt daar een uitgebreide gids over.
De vijf rode vlaggen
Als je nu software hebt of een selectie overweegt, en je herkent meerdere van deze punten: trek aan de handrem.
Ik zeg niet dat je meteen moet stoppen met wat je hebt. Maar het zijn signalen die je serieus moet nemen. We weten allemaal wat er gebeurt als je rode vlaggen negeert.
1. Geen open API
Gewoon keihard: als jouw pakket geen open API heeft, geen stekkerdoos, dan heb je een gigaprobleem.
Een RESTful API is niets meer dan een gestandaardiseerde manier om data op te halen, te versturen, bij te werken en te verwijderen. Dat is precies wat je nodig hebt om apps te bouwen, en precies wat agents nodig hebben om mee te werken.
Als ik bij een klant kom en ze willen een Unified Namespace bouwen, is het eerste wat ik me afvraag: kan ik bij de data? Zijn er API’s? Zijn die goed gedocumenteerd? Zit er geen bizarre limiet op van 100 berichten per dag?
Als dat zo is, dan kun je 99% van alle AI-toepassingen gewoon vergeten, omdat je systeem die stekkerdoos simpelweg niet heeft. En wat moet ik dan als integrator? Via de database erin met een omweg, en dan kan ik niet eens terugschrijven zonder dingen stuk te maken.
2. De data is niet van jou
Stel je voor: je hebt je database jarenlang lokaal staan. Je leverancier zegt: we zetten het in de cloud, wordt alles beter. Je zegt oké. Maar ten eerste wordt het niet beter als je het pakket niet herziet. En ten tweede staat die data dan niet meer in je eigen omgeving.
Als je die database één op één wilt downloaden zodat je het ooit zelf opnieuw kunt opbouwen, kan dat niet. Dan moet je het aanvragen, dan kost het weer geld, dan ben je afhankelijk.
Heb je wel eens geprobeerd om een volledige backup te maken, gewoon lokaal? Volgens de GDPR, de Europese databeschermingswet, is het al een vereiste dat je bij je eigen data kunt. Maar blijkbaar wordt dat nog steeds genegeerd.
3. Geen zelfredzaamheid
Als je voor elke schermaanpassing, elk rapport, elke workflowwijziging een consultant nodig hebt, zit je in het oude model. En dat gaat je keihard afremmen.
Ik geloof prima dat je soms beter af bent met begeleiding, ik wil niet dat je denkt dat je alles zelf moet doen. Maar stel je voor dat je er een onafhankelijke partij bij wilt halen, zoals mij of een partner. Dan moet die persoon dat wel kunnen, tenminste binnen redelijke perken. Als zelfs dat niet kan, dan is dat geen partnerschap. Dat is afhankelijkheid.
4. Updates breken koppelingen
Veel koppelingen in de markt hebben totaal geen versiebeheer. Ze zijn gemaakt door consultants: snel in elkaar gezet, naar een bestandje geschreven voor de klant, en als de volgende klant hetzelfde wil wordt het uit een la getrokken en aangepast. Geen relatie meer tussen de versies. Geen changelog. Geen documentatie.
Als er dan een update van het pakket komt, is het een gok of alles blijft draaien. En als het omvalt, en dat gebeurt regelmatig, is dat weer een consultancytraject. En dat is precies het verdienmodel geweest.
Met geversioned API’s heb je dat probleem niet. Versie 1 is de API, versie 2 voegt functionaliteit toe, versie 3 weer. Als een koppeling op een versie is gebouwd, valt die niet zomaar om. En als er toch iets verandert, kun je precies zien wat er anders is en het binnen no-time rechtzetten.
5. Geen events of webhooks
Als er een order wordt vrijgegeven, een datum wordt gepland, een status verandert, dan wil je dat je systeem dat vertelt aan de rest van je ecosysteem. Een signaal. Een event. Niet dat je iedere vijf minuten moet vragen: “is er iets veranderd?”
Reken maar even mee. Als je iedere minuut vraagt of er nieuwe orders zijn, is dat 60 keer per uur. Als je 1000 API-calls per dag hebt, ben je alleen met het opvragen van levertijden al over je limiet. En dan heb ik het nog niet over een productie-app, waar iemand iets gereedmeldt en het pas 10 minuten later op de vloer verschijnt. Dat vinden mensen niet fijn, dan gaan ze eromheen werken, en je adoptie is mislukt.
Je wilt geen system of record waar dingen worden weggeschreven. Je wilt een system of experience, dingen die leven, die notificeren, die reageren.
Vier paden, afhankelijk van waar je staat
In een high-mix wereld is ook ieder bedrijf uniek. Andere grootte, andere productiestructuur, andere bewerkingscombinaties, andere keteninteractie. Of je voorraadhoudend werkt of make-to-order doet, of je veel uitbesteedt of alles intern houdt, dat bepaalt wat je nodig hebt. Maar grofweg zie ik vier scenario’s.
Klein (~5 man)
Tot een man of vijf red je het vaak prima zonder enig systeem. Facturen stuur je vanuit een simpel boekhoudpakket, de rest regel je met je hoofd en een paar lijstjes. Daar is niks mis mee.
De tussenfase (~5-30 man)
Hier wordt het eerlijk gezegd een beetje raar. Je bent te groot voor alleen een boekhoudpakket, maar je hebt geen behoefte aan een volledig ERP. En toch is dat precies wat je vaak krijgt aangeboden.
Ik denk dat de meeste bedrijven in deze categorie vandaag de dag beter af zijn met een goed boekhoudpakket en een paar gerichte apps ernaast. Een boekhoudpakket kan facturen, offertes, inkoop, uurregistratie en btw-aangifte. Kost een paar tientjes per maand. Geen consultant nodig, je kunt het zondagavond op de keukentafel met je laptop regelen en je bent klaar.
En dan ga je alleen nadenken over hoe je die order in de productie krijgt. Daar haal je apps bij, een CAM-pakket, een calculatietool, misschien een werkvoorbereidingstool. En daartussen ga je zelf aan de slag met koppelingen. Gebruik een workflowtool als N8N als je echt los wilt gaan. Leer het. Je toekomst als bedrijf hangt af van hoe goed je je systemen integreert, leg dat niet volledig in andermans handen.
Kan ERP werken bij twintig man? Zeker. Maar je krijgt waarschijnlijk 90% functionaliteit die je niet nodig hebt, met onnodige complexiteit en kosten. En je budget kun je waarschijnlijk beter besteden aan gespecialiseerde tools dan aan het proberen alles in één pakket te stoppen. Wie wil vergelijken kan terecht bij de 10 beste ERP-software voor metaalbewerking en plaatbewerking.
Opschaler (groeiend, meerdere afdelingen)
Begin met uitkleden in plaats van erbij stoppen. Kijk naar een Unified Namespace als verbindende laag. Laat je ERP doen waar het goed in is, transacties en financien, en bouw je operationele laag eromheen met eigen apps en koppelingen.
Als je ERP al geintegreerde boekhouding heeft en dat werkt, prima. Maar dan zal je focus niet meer zijn om daar meer in te stoppen. Zie het als een onderdeel van je ecosysteem, niet als het centrum. En als je rode vlaggen er niet te veel zijn, kun je dat systeem gewoon laten staan en eromheen bouwen.
Groep (meerdere locaties, intercompany, hoge proceseisen)
Hier is gecentraliseerde ERP voorlopig nog verdedigbaar, en soms gewoon nodig. Als je te maken hebt met financiele consolidatie, intercompany transacties, audits, of hoge eisen aan je procesborging, dan kan ik me goed voorstellen dat zelf apps combineren of eigen ontwikkeling niet altijd werkbaar is. De complexiteit van meerdere entiteiten, geconsolideerde rapportage en wettelijke verantwoording vraagt om een systeem dat daar grondig mee omgaat.
Maar ook dan: bouw je productie-apps en werkvloertools apart, zodat je precies kunt maken wat je mensen op de vloer nodig hebben. Want het einde van de dag draait alles om het verbeteren van de productiviteit.
Wat ik in de praktijk zie
De vraag verschuift. Twee jaar geleden kwamen bedrijven bij me met “welk ERP moet ik nemen?” Nu hoor ik steeds vaker: “hoe kom ik van mijn ERP af?” Of: “wat kan ik zelf bouwen?”
En ik merk het aan mezelf. Integraties waar ik normaal lang mee bezig was, regel ik nu in een fractie van de tijd. Complete end-to-end oplossingen. Dat is geen toekomstmuziek, dat is nu.
Wat ik concreet durf te zeggen: ERP zoals we het kennen gaat verdwijnen. Niet morgen, niet voor iedereen tegelijk, maar de richting is onmiskenbaar. We gaan werken met API’s en commandoregels. Agents, automatiseringen en workflowplatforms gaan de orchestratie overnemen. Het idee dat je in een scherm zit te klikken om je bedrijfsprocessen te draaien, dat is het oude model.
Grote bedrijven met hoge proceseisen zullen voorlopig nog gecentraliseerde systemen nodig hebben. Daar is niks mis mee. Maar ook zij zullen merken dat de schil eromheen, de modules die alles moeten kunnen, de consultants voor elke wijziging, steeds minder relevant wordt.
De tools zijn er. De rekensom is fundamenteel veranderd.
En net als bij de casino speeltips: weet wanneer je moet stoppen. Weet wanneer je moet zeggen: mijn leverancier heeft gedaan wat hij kan, maar het belang van hem is waarschijnlijk om meer te blijven doen, meer toe te voegen, meer complexiteit te creeren. En dat is waarschijnlijk niet meer in mijn beste belang.
Het tijdperk van ERP als allesomvattend systeem loopt ten einde. En als je me vraagt of dat erg is: nee. Het wordt tijd.
Verder lezen
- Waarom ERP niet meer het centrum van je fabriek hoeft te zijn, het fundament van dit verhaal
- Moet je je ERP upgraden? Waarschijnlijk niet, waarom eenvoud eerst komt
- 10 beste ERP-software voor metaalbewerking, vergelijk de opties
- De werkelijkheid achter ERP en de cloud, strategie of marketing?
- MES in 2026: wat je moet weten, en wat je nu zelf kunt bouwen
- Unified Namespace: weg met spaghetti-integraties, de verbindende laag
- Deep dive UNS: vragen en antwoorden, voor wie dieper wil
- AI in de fabriek: drie niveaus, waar je kunt beginnen
Vragen over jouw situatie? Neem contact op voor een vrijblijvend gesprek.
Alle genoemde software- en leveranciersnamen dienen ter illustratie en zijn geen aanbeveling of beoordeling.