How to choose a manufacturing ERP

Choose the process before the product

Make-to-stock, make-to-order and engineer-to-order are different buying problems. Write down how a real order enters your business, how its bill of materials changes and when you promise delivery. Include rework, subcontracting and partial shipment. A feature checklist becomes useful only when each requirement has a business owner and a concrete example.

Run a connected demonstration

Give every shortlisted vendor the same small, anonymized dataset: a multi-level BOM, two work centers, a late component and an urgent customer change. Ask the team to create the order, plan material, release work, capture labor and receive finished goods. Then reconcile the transaction to inventory valuation and job cost. Record where a person rekeys information or opens another application.

Draw the system boundary

ERP, MES, WMS and planning may be native modules, separately licensed products or partner integrations. None of these architectures is automatically wrong. Document the system of record, synchronization frequency, failure handling and support owner for every boundary. A single login alone does not establish a single transaction model.

Select with acceptance criteria

Before signing, define what a passing pilot looks like. Specify a reconciliation tolerance, the required traceability path and the owner of master-data cleanup. Evaluate training and operational recovery alongside features. Use the directory to form a shortlist, then verify your specific edition, partner and country requirements. A vendor overview is the beginning of due diligence, not its result.

Prepare a representative test pack

Build a small test pack that contains one ordinary order and one difficult order. Add the relevant item records, units, bill of materials, routings, stock balances, supplier commitments and opening assumptions. Remove customer and employee identifiers that are not needed for the exercise. Include a written description of the intended result, so a vendor cannot quietly simplify the process during the demonstration. Give each candidate the same pack and enough preparation time to identify missing requirements. Record questions raised during preparation; they often reveal more about the proposed scope than a polished standard demonstration.

Inspect planning when reality changes

After the first schedule is created, delay a critical receipt and reduce the available capacity of one work center. Ask the vendor to show which commitments become infeasible and how planners would respond. Inspect whether a suggested alternative changes material allocation, overtime, subcontracting or customer promise dates. Require an explanation of the assumptions behind the new plan. A diagram of the final schedule is insufficient when the team cannot explain its constraints. Capture the steps needed to return to a valid plan and who is authorized to accept the operational consequences.

Make traceability a reverse journey

Start with a shipped finished item and ask the system to identify the contributing production activity and tracked materials. Then start from one component lot and ask which work orders and shipments it reached. Include a partial completion, a returned component and a corrected production report if those are relevant to your business. The purpose is to verify that the intended records remain connected after exceptions, not merely that a traceability screen exists. Agree in advance which tracking identifiers and documents the business needs, and have the responsible operations owner confirm the result.

Turn the findings into a purchasing decision

For each scenario, write down what was demonstrated, what required an extension and what remains unresolved. Name the proposed delivery team and the person who will accept the result. Compare implementation work, recurring administration and support responsibility over the same period. A candidate that fits the core process may still require a pilot for a critical integration or localization requirement. Keep those conditions visible in the proposal and acceptance plan. The final decision should explain why the selected configuration fits the operating model, with enough evidence that another stakeholder can review the reasoning.

Follow the money through a partial completion

Illustrative example: an order calls for 20 assemblies. Ten are complete, two require rework, and eight remain on the line. The first ten ship before the outside processor's invoice arrives. Ask finance to explain which costs are in finished inventory, work in progress and cost of sales at that moment. Then post the late invoice and inspect the adjustment. These numbers are a test design, not a customer result. The useful output is a bridge from estimated to actual cost, with material, labor, overhead and subcontracting differences separated. An impressive job margin is unhelpful if it excludes unreceived invoices or abandoned work. Agree how partially completed operations and scrapped components are reported before comparing profitability screens.

Decide how much execution detail earns its upkeep

A machine connection, individual labor booking and operation-level inspection each create records someone must maintain. Specify the decision each record supports. A low-volume workshop may need accurate completion and exception reporting more than second-by-second machine events. A high-volume line may need more immediate feedback to prevent repeated defects. Demonstrate a missed scan, duplicate completion and wrong labor booking, including correction authority. Reject a design that reaches accurate totals only because a consultant repairs transactions outside the ordinary workflow. Capture an operating-day checklist covering unposted production, negative availability, overdue subcontract receipts and unresolved quality holds. Assign each queue to a named role. That artifact is often more useful at launch than another dashboard.

What the documentation can establish

Microsoft's engineering change documentation describes product versions and readiness checks in Dynamics 365 Supply Chain Management. That is a specific documented mechanism, not evidence that another product has the same behavior or that a proposed configuration meets your needs. Use it to sharpen questions about release controls, then validate those controls in the exact system offered.

Common questions

Continue your research

The following profiles provide a starting point for checking vendor-described scope. Inclusion is not a ranking or a statement that every requirement is supported.