DEV Community

Cover image for Evaluate Manufacturing ERP Like an API, Not a Feature Matrix
James Sanderson
James Sanderson

Posted on

Evaluate Manufacturing ERP Like an API, Not a Feature Matrix

Robotic assembly line running under Industry 4.0 control software

If you are the engineer in the room during an ERP selection, you are probably not the one filling in the requirements matrix. You are the one who will spend the next three years integrating whatever wins.

That gives you a different and more useful evaluation lens. The functional questions are being handled — badly or well, but handled. Nobody is asking the questions that determine whether you can build anything on top of this system, and those questions have a much longer half-life than whether the quality module supports your inspection plan out of the box.

Here is the test list I would run, roughly in order of how much pain each one saves.

1. Can you get data out incrementally, cheaply, and on a stable schema?

Not export. Not a nightly CSV. A supported, incremental feed of transactions and master data into your own warehouse.

Ask specifically:

  • Is there a change-data-capture or delta mechanism, or does every sync mean full extracts?
  • Are you billed per API call, per row, or per user? Per-call billing turns a fifteen-minute sync into a budget line.
  • Is the schema documented and versioned, or are you reading internal tables that can change in a point release?
  • What is the rate limit, and what happens at the limit — throttling or errors?

Every AI or analytics capability your business will want gets built on this feed. A platform where data is expensive or fragile to extract is a constraint on everything downstream, and it is one you cannot engineer around later.

2. Can an external service write back transactionally?

This is the test almost nobody runs and the one that separates systems you can automate from systems you can only report on.

The demo request: an external service authenticates, reads the current production schedule, proposes a change, and commits it. Then ask what happens when it commits the same change twice.

What you want to hear:

  • A real REST or event API with documented resources, not a middleware product sold separately.
  • Idempotency keys, or at minimum a documented dedupe strategy.
  • Meaningful error semantics — a 409 when the underlying record moved, not a 200 with a failure buried in a response body.
  • Transactional boundaries you can reason about. Does a partially applied multi-line work order roll back?

Without write-back, every recommendation your systems generate ends with a human retyping it into a screen. That is where the return on automation goes to die.

Colleagues analysing an operational report

3. What is the extension model, and where does the code live?

Every ERP has a way to add logic. They differ enormously in how much you regret using it.

Find out:

  • Does extension code run inside the ERP runtime or as external services it calls?
  • Is it under source control you own, with a real diff and a real review?
  • Is there a test framework, or is testing manual clicking in a sandbox?
  • What happens at upgrade — automatic regression suite, or a partner statement of work?

External services against a stable API are almost always the right answer. In-platform customisation is a permanent upgrade tax, and the cost lands on whoever is here in three years, which is statistically likely to be you.

The dividing line we use: anything a competitor could buy off the shelf belongs in the packaged system; anything that encodes how your business actually wins belongs in software you own. That framing drives how we do custom software development around packaged manufacturing suites.

4. Does the integration surface respect the systems already on the floor

ERP is one node. You will also have some combination of MES, PLM, WMS, quality systems, EDI partners and machine-level data collection.

Write the boundaries down before selection ends:

  • PLM owns part definition and revision; ERP consumes released BOMs.
  • MES owns real-time execution and machine interaction; ERP owns the order, the cost and the material commitment.
  • WMS owns location-level movement; ERP owns the balance.
  • Quality owns non-conformance workflow; ERP owns the hold and the disposition cost.

Then check that the ERP's model can actually express those boundaries. Some platforms assume they own all of it and become difficult when asked to be one participant among several.

5. Sandboxes, environments and deployment

Unglamorous and decisive.

  • How many non-production environments, and how are they refreshed from production?
  • Can you script a refresh, or does it require a support ticket with a lead time?
  • Is there any concept of promoting configuration between environments, or is configuration re-entered by hand?
  • Can integration credentials be scoped per service, or is there one admin account everyone shares?

That last one is where a surprising number of otherwise sensible deployments quietly fail their first security review.

6. The AI questions that are actually architectural

Every vendor now demos an assistant. Treat that as table stakes — they are broadly equivalent and they answer questions a user could already have filtered for.

The questions that matter are the ones above, because the models that change your economics get trained on your pooled history and served by external services that need to act. Demand sensing, scrap and yield prediction, dynamic lead times, autonomous expediting: all of them need cheap egress and real write-back. Neither appears on the functional matrix. Both determine whether any of it is buildable.

A quick scoring suggestion

If you get to influence the weights, argue for integration and data openness at fifteen to twenty percent of total score, separate from functional fit. It is routinely at zero, folded into a vague technical section that nobody defends.

You will not win the argument on elegance. Win it on cost: every one of these tests maps to engineering days you will otherwise spend, and days are the unit the finance team already understands.


Frequently Asked Questions

What single test reveals the most about an ERP's API?
Ask for a live external write-back of a schedule change, then ask what happens if it is submitted twice. Idempotency behaviour tells you how seriously the API was designed.

Is per-call API pricing a dealbreaker?
Not automatically, but model it against your real sync frequency before signing. It frequently turns routine integration into a recurring budget conversation.

Should extension logic run inside the ERP?
Prefer external services against a documented API. In-platform code becomes an upgrade tax paid by whoever maintains it later.

How do we stop ERP from claiming ownership of everything?
Document system-of-record boundaries for PLM, MES, WMS and quality before selection ends, and verify each candidate can express them.

Do embedded AI assistants matter in evaluation?
Very little. They are near-identical across vendors. Data egress economics and transactional write-back decide what you can actually build.


Longer version with the fit-gap method and a full five-year cost model: Best ERP Software for Manufacturing in 2026.

Top comments (0)