The Beginning, the Success, and the End of ERP in Metalworking | Newsletter

ERP in metalworking. Where it came from, why it worked, and why the model as we know it is under pressure. No demo, no code, just an honest story.

First, some background on me, because it’s relevant for what follows.

I’m a mechanical engineer by training (vocational and bachelor’s degree), studied innovation and business administration, and completed a certification as SAP consultant (Business Systems Integrations). In my previous role, I spent four years as project lead for implementing and integrating ERP, Ridder iQ in that case, a Dutch metalworking ERP.

After that, I continued independently with system integrations. Over the past 8 years, I’ve guided more than twenty implementations and work daily with all the major ERP brands in the Dutch metalworking market. Bemet, MKG, ISAH, Navision / Business Central, Fledge, you name it. These are the dominant players in the Netherlands, but the patterns I see apply broadly across metalworking ERP worldwide.

And the pattern is the same everywhere.

All brands I mention in this article are purely for illustration, there’s nothing fundamentally wrong with them and nuance always applies. This is not advice. For advice, you can reach me at vanenkhuizen.com.

I’m speaking from daily experience here. And honestly, a bit of frustration too (if you’ll allow me that), because when you work with all these existing brands for years, you start recognizing patterns you can no longer ignore…

”Which ERP should I choose?” is the wrong question

I get that question weekly. I think I have around thirty packages that I personally review almost monthly to see how they’re developing. And I understand the question, you want to move your business forward, you’re looking for a system. But there’s an assumption behind it that no longer holds: that one package should do everything.

There’s a kind of myth in the market that an all-in-one ERP system for metalworking exists that just works.

I’ve spoken to hundreds of companies and I’ll say it honestly: I’ve never seen anyone who is truly satisfied.

Not because the vendors are bad, but because you’re always dealing with the trade-off between a generic process and a specialized process. Most metal companies excel at one-offs and custom work, you can’t build one package that fits everyone.

What happens next: a package gets chosen before anyone has thought about the bigger architecture. And then you get shortcomings. Then you buy additional modules, then you do customization, then a consultant comes in, and before you know it you’re in a complex landscape that nobody really oversees anymore.

And don’t forget: the entire business model of current ERP companies is largely based on consultancy, not primarily on licenses.

Consultancy costs average five to ten times the purchase price. The longer the implementation takes, the more the vendor earns. That interest doesn’t always align with yours as a customer.

The question should really be: how do I bring it all together? What’s my architecture? Can I integrate, adapt, and do I own my own data? I wrote extensively about this in Why ERP No Longer Needs to Be the Center of Your Factory.

Overview of the traditional ERP landscape in the metals industry

Five generations of software, and where you probably are

To understand where we stand, you need to know where we came from. Because ERP wasn’t always called ERP.

Timeline of five generations of ERP software

5 Generations of ERP

Gen 1 & 2, the foundation.

The first systems were MRP: Material Requirements Planning. Think: trucks with materials in the right place at the right time, that was it. The entire background of computing is largely based on logistics challenges in the military and large trading companies, the first algorithms solving this existed as early as the 1960s.

In the 1980s, the first database-driven packages emerged and the consultancy model began: a party built a custom solution for you from their own template. I still see packages from that era running in the wild to this day.

Gen 3, where most metal companies still are today.

Packages you could customize: build your own screens, add tables, define integrations. Built on SQL and Postgres databases, .NET frameworks. An entire industry emerged from this in the Netherlands, parties that used industry knowledge to build something scalable for companies that had no software expertise themselves. And it was a good time to start doing that.

Many companies are now somewhere between Gen 3 and Gen 4. Partially customizable systems, strong industry knowledge, but no full web interface yet. That’s not necessarily a problem, as long as the fundamentals are sound.

Gen 4, where we are now.

This is about web browsers and web interfaces. Most vendors have moved here now, or started as cloud-natives. This means you essentially run everything in your web browser. You no longer need a local software client or local installation.

An API, the connector that lets systems communicate with each other, has become a standard to make this possible.

But note the difference: there are parties that rebuilt their old package into a web browser, and there are parties that were built as web applications from day one.

That’s not the same thing. An old package that you put in the cloud is still an old package, the architecture doesn’t change, only the invoice. If you’re wondering whether an ERP upgrade is worth it, also read: Should you upgrade your ERP? Probably not.

Gen 5, just started, since 2025.

This has everything to do with agentic AI, the lowering barrier to programming, and the rapidly changing software market in specialized apps. Think: Claude Code with Opus 4.5+ and GPT 5.3… + platforms like N8N.

I notice it in my own work. I have an accounting package I barely log into anymore. When I want to send an invoice, I tell an AI agent. It generates a new customer, checks VAT numbers, adds the line items, looks at previous sales, writes the appropriate text, and sends me a message when it’s ready. When I approve with my voice, the invoice gets sent.

I only go into the system when there’s an exception. The interface disappears, the system works for me, not the other way around. This is going to work the same way for many manufacturing companies.

From traditional ERP interface to AI-driven business operations

What ERP actually can’t do

A side note that often gets forgotten. When you look at everything in an ERP, you’re missing a few things that are essential for the shop floor.

There’s no machine in it. There are no 3D viewers. There’s no system for creating detailed work instructions. There’s nothing that provides a closed loop at a detailed production level. Combining machine data with registered production data, downtime tracking, questionnaires for disruptions, that doesn’t really fit in ERP.

These are all things you either solve with customization or with costly integrations. And that gives you a complex landscape again. ERP in itself is just a label for a set of functionalities that vary per package. Every package has its strengths and weaknesses. If you want to know how a Manufacturing Execution System fills that gap, there’s a comprehensive guide on that.

Comparison of ERP functionality versus shop floor needs

The five red flags

If you currently have software or are considering a selection, and you recognize several of these points: pull the handbrake.

I’m not saying you should immediately stop what you have. But these are signals you need to take seriously. We all know what happens when you ignore red flags.

1. No open API

Straight up: if your package has no open API, no connector, you have a massive problem.

A RESTful API is nothing more than a standardized way to retrieve, send, update, and delete data. That’s exactly what you need to build apps, and exactly what agents need to work with.

When I visit a client and they want to build a Unified Namespace, the first thing I ask myself is: can I access the data? Are there APIs? Are they well documented? Is there no absurd limit of 100 messages per day?

If that’s the case, you can forget 99% of all AI applications, because your system simply doesn’t have that connector. And what am I supposed to do as an integrator? Go through the database with a workaround, and then I can’t even write back without breaking things.

2. The data isn’t yours

Imagine this: you’ve had your database on-premises for years. Your vendor says: we’re moving it to the cloud, everything will be better. You say okay. But first, it doesn’t get better if you don’t rethink the package. And second, that data is no longer in your own environment.

If you want to download that database one-to-one so you could ever rebuild it yourself, you can’t. Then you have to request it, then it costs money again, then you’re dependent.

Have you ever tried to make a full backup, just locally? Under GDPR, the European data protection regulation, it’s already a requirement that you can access your own data. But apparently that’s still being ignored.

3. No self-sufficiency

If you need a consultant for every screen adjustment, every report, every workflow change, you’re in the old model. And that’s going to slow you down hard.

I’m fine with the idea that sometimes you’re better off with guidance, I don’t want you to think you have to do everything yourself. But imagine you want to bring in an independent party, like me or a partner. That person needs to actually be able to do it, at least within reasonable bounds. If even that’s not possible, that’s not a partnership. That’s dependency.

4. Updates break integrations

Many integrations in the market have zero version control. They were built by consultants: thrown together quickly, written to a file for the client, and when the next client wants the same thing, it gets pulled from a drawer and adapted. No relationship between versions. No changelog. No documentation.

When a package update comes along, it’s a gamble whether everything keeps running. And when it falls over, and that happens regularly, it’s another consultancy project. And that’s been exactly the revenue model.

With versioned APIs, you don’t have that problem. Version 1 is the API, version 2 adds functionality, version 3 again. If an integration is built on a version, it doesn’t just fall over. And if something does change, you can see exactly what’s different and fix it in no time.

5. No events or webhooks

When an order gets released, a date gets scheduled, a status changes, you want your system to tell the rest of your ecosystem. A signal. An event. Not that you have to ask every five minutes: “has anything changed?”

Do the math. If you ask every minute whether there are new orders, that’s 60 times per hour. If you have 1,000 API calls per day, you’ve already exceeded your limit just by checking delivery times. And I haven’t even mentioned a production app, where someone marks something as complete and it only shows up on the floor 10 minutes later. People don’t like that, they’ll work around it, and your adoption has failed.

You don’t want a system of record where things get written away. You want a system of experience, things that live, that notify, that react.

Five red flags in ERP selection and evaluation

Four paths, depending on where you are

In a high-mix world, every company is unique. Different size, different production structure, different machining combinations, different supply chain interaction. Whether you hold inventory or work make-to-order, whether you outsource heavily or keep everything in-house, that determines what you need. But broadly, I see four scenarios.

Small (~5 people)

Up to about five people, you often manage just fine without any system. You send invoices from a simple accounting package, handle the rest with your head and a few lists. Nothing wrong with that.

The in-between phase (~5-30 people)

This is where it honestly gets a bit odd. You’re too big for just an accounting package, but you don’t need a full ERP. And yet that’s exactly what you often get offered.

I think most companies in this category are better off today with a solid accounting package and a few targeted apps alongside it. An accounting package handles invoices, quotes, purchasing, time tracking, and tax returns. Costs a few dozen per month. No consultant needed, you can set it up on your laptop on a Sunday evening and you’re done.

And then you only think about how to get that order into production. You bring in apps for that, a CAM package, a quoting tool, maybe a work preparation tool. And between those, you start building integrations yourself. Use a workflow tool like N8N if you really want to go for it. Learn it. Your future as a company depends on how well you integrate your systems, don’t put that entirely in someone else’s hands.

Can ERP work at twenty people? Sure. But you’ll probably get 90% functionality you don’t need, with unnecessary complexity and cost. And your budget is probably better spent on specialized tools than on trying to stuff everything into one package. If you want to compare options, check out the 10 best ERP software for metalworking and metal fabrication.

Scaler (growing, multiple departments)

Start by stripping down rather than adding on. Look at a Unified Namespace as a connecting layer. Let your ERP do what it’s good at, transactions and financials, and build your operational layer around it with your own apps and integrations.

If your ERP already has integrated accounting and that works, fine. But your focus won’t be on putting more into it. See it as a part of your ecosystem, not as the center. And if your red flags aren’t too severe, you can leave that system in place and build around it.

Group (multiple locations, intercompany, high process requirements)

Here, centralized ERP is still defensible for now, and sometimes simply necessary. If you’re dealing with financial consolidation, intercompany transactions, audits, or high process assurance requirements, I can well imagine that combining apps yourself or custom development isn’t always workable. The complexity of multiple entities, consolidated reporting, and regulatory accountability demands a system that handles that thoroughly.

But even then: build your production apps and shop floor tools separately, so you can create exactly what your people on the floor need. Because at the end of the day, it’s all about improving productivity.

Four paths for ERP strategy by company size

What I see in practice

The question is shifting. Two years ago, companies came to me asking “which ERP should I get?” Now I increasingly hear: “how do I get off my ERP?” Or: “what can I build myself?”

And I notice it in myself. Integrations that used to take me a long time, I now handle in a fraction of the time. Complete end-to-end solutions. That’s not future talk, that’s now.

What I’ll say concretely: ERP as we know it is going to disappear. Not tomorrow, not for everyone at the same time, but the direction is unmistakable. We’re going to work with APIs and command lines. Agents, automations, and workflow platforms will take over the orchestration. The idea that you sit in a screen clicking around to run your business processes, that’s the old model.

Large companies with high process requirements will still need centralized systems for now. Nothing wrong with that. But they too will find that the shell around it, the modules that have to do everything, the consultants for every change, becomes less and less relevant.

The tools are here. The equation has fundamentally changed.

And just like with casino tips: know when to stop. Know when to say: my vendor has done what they can, but their interest is probably to keep doing more, keep adding, keep creating complexity. And that’s probably no longer in my best interest.

The era of ERP as an all-encompassing system is coming to an end. And if you ask me whether that’s a bad thing: no. It’s about time.