What matters when selecting an ERP for a manufacturing company?

For manufacturing companies the order type decides the ERP selection, not the length of the feature list. Make-to-stock, make-to-order and engineer-to-order place different demands on bills of material, routings and scheduling. Answering that question first makes systems genuinely comparable. Leaving it open means comparing feature tables that can do everything and decide nothing.

How the standard handles complex manufacturing: where it holds and where it tears

The general approach with criteria and checklist: ERP selection

Which question comes before all others?

The first question is not which system has the most manufacturing functions, but how you produce. A company with make-to-stock production and stable bills of material needs different planning than a make-to-order manufacturer where every bill of material is created with the order. And an engineer-to-order business with long lead times has different demands again on pre-costing and concurrent costing.

In practice most mid-sized manufacturers produce in a mixed way. Part of the revenue runs through recurring items, another through customer orders with variants. Exactly this mix is the real test, because it forces the system to represent two logics cleanly at the same time.

A sound selection therefore starts with an inventory of order types and their shares. Only once that distribution is on the table can systems be measured against it rather than against marketing promises.

Where does selection in manufacturing most often go wrong?

The most common mistake is the feature wish list. It comes about by every department writing down what the current system cannot do. The result is a list with several hundred points in which the three decisive requirements disappear among trivia. Every vendor ticks off nearly everything, and the selection turns into a price question.

The second mistake is variant diversity. It is almost always underestimated because daily work absorbs it through grown workarounds, often in spreadsheets beside the system. It therefore does not surface during selection, but hits with full force during the project.

The third mistake concerns the data foundation. In many manufacturing businesses bills of material and routings have grown over years and contain items that no longer exist and operations nobody performs that way any more. No system in the world repairs that during migration. It only makes it visible.

Which criteria genuinely carry?

Four criteria have proven sound in manufacturing projects. First, representing your dominant order type in the standard, without custom development. Second, scheduling: is simple backward scheduling enough, or do you need capacity limits and sequence optimisation? Third, the connection to the machines and to what is actually recorded on the shop floor. Fourth, costing, in particular whether you need concurrent costing.

What rarely decides is the number of available modules. A module that does not fit your process in the standard becomes more expensive during the project than a deliberate customisation at one clearly bounded point.

One criterion is regularly forgotten: how easily the system can be changed later. Manufacturing processes change when new products, machines or customers arrive. A system that can only be readjusted with considerable effort becomes a brake within a few years.

Industry solution or standard with an extension?

An industry solution takes work off your hands if it genuinely matches your order type. It costs you flexibility if it does not, because every deviation then leads to customising an already customised system. The honest test is therefore not whether an industry solution exists for your sector, but what share of your processes it covers without change.

For a growing number of manufacturers the standard carries further than it used to, because functions that required an add-on ten years ago are now included. The sensible route is usually a narrow extension exactly where your business is distinctive, and standard everywhere else.

What matters is that this boundary is drawn deliberately and documented. Where it is missing, a collection of special routes grows over the project that nobody oversees any more and that makes every later update expensive.