When to Use ERP/MES vs. an AM-Specific Quality Management Software

If you’re a CTO, Head of IT, or integration partner supporting additive manufacturing, you’ve probably heard the question, “We already have ERP and MES. Why do we need anything else?”.

It’s a fair challenge, and it’s also where many AM programmes quietly create long-term pain. Not because ERP/MES are the wrong choices, but because teams try to make them do jobs they weren’t designed to do. The result is a familiar outcome, an MES full of custom fields and file attachments, an ERP pressed into reporting, and a spreadsheet layer that still carries the real burden of proof.

The simplest way to avoid that outcome is to treat AM quality as an architectural problem. Where should different types of truth live?

ERP — Business Truth

ERP is the system of record for commercial reality (customers, orders, inventory, purchasing, cost and finance). It’s essential. It’s also not built to represent the physics of a build job, powder reuse histories, or part-level inspection evidence.

When ERP is forced into that role, it becomes slow and brittle. Every new machine, test method, or customer reporting requirement becomes an IT request. And the data that matters ends up being “stored” rather than “usable”.

MES — Execution Truth

MES is the heartbeat of execution. It coordinates workflow, dispatching jobs, routing operations, tracking WIP, recording sign-offs and timestamps. For AM production environments, MES adds structure and accountability, and it often integrates nicely into wider factory operations.

But MES is usually job- and workflow-centric. It can track that a build happened. It rarely holds (in a native and analysable way) the full AM evidence chain that quality teams and auditors actually care about such as powder genealogy, parameter sets, machine context, post-processing routes, inspection results, and stability over time.

So organisations extend MES. They add a field here, an attachment there, a custom report somewhere else. The result looks like progress, until you try to answer a question such as “Which parts were built with this powder mix, under these parameters, and how did they perform after heat treatment?” .

That’s when you realise the system can store evidence, but can’t connect it.

Overloading MES

You don’t need a maturity model to spot it. If quality reporting still depends on exporting to Excel, if audits trigger a scramble to assemble information from multiple places, or if every new machine introduces another mapping exercise, you’ve probably asked MES to become something it isn’t, a production-level AM quality software. This isn’t a criticism of MES. It’s a category mismatch.

What an AM-specific quality software is for

Production AM needs a place where quality evidence lives as a structured, linked model, not as disconnected files. That is the purpose of an AM-specific production-level quality management software (P-QMS) such as amsight, a digital quality backbone that sits alongside MES in the production layer.

The value is not “more dashboards”. The value is that the system is built to ingest and normalise AM-specific data and keep it connected at part level across the chain: powder → build → post-processing → inspection. Once that exists, traceability becomes consistent, reporting becomes repeatable, and disciplines like SPC become practical because the data is no longer fragmented.

A simple rule for what goes where

Here’s a clean way to split responsibilities:

• ERP remains the home of commercial truth.
• MES remains the home of execution truth.
• The AM quality software becomes the home of quality truth (part-level evidence, qualification data, stability metrics, and repeatable reports).

That separation doesn’t add complexity, it reduces it. It prevents the “everything ends up in one system” trap, and it avoids long-term customisation debt.

Where to start without a giant project

You don’t need to replace anything to start. Most teams begin with one production slice such as a single programme, a machine cluster, or a product family where quality documentation hurts most. Centralise the evidence chain for that slice (powder history, build parameters, post-processing, inspection) and make it queryable and reportable. Once the model is in place, scaling to more machines and sites is expansion, not reinvention.

If you want the most concrete picture of this approach, start with traceability as the foundation.

Because in production AM, the question isn’t “Do we have ERP and MES?” It’s “can we prove quality, understand variation, and scale, without turning the IT landscape into a bespoke science project?”.‍