An engineer-to-order manufacturer, one whose products are designed for each order, is poorly served by ordinary manufacturing software. This piece sets out what engineer-to-order software and ERP must actually do.
Why ordinary manufacturing software falls short
Most manufacturing software assumes a product is defined before an order arrives: there is a catalogue, each product has a bill of materials and a routing, and an order draws on those existing definitions. Engineer-to-order breaks that assumption. In ETO work the product is engineered for the order, so the BOM and routing are produced by the job, not looked up. Software built on the catalogue assumption cannot represent that cleanly. It can be forced to, by creating a throwaway product per order, but the result is awkward, and the project nature of the job, its phases, budget, and schedule, has nowhere to live.
The core requirement: project and manufacturing as one
The defining requirement for engineer-to-order software is that it joins project management and manufacturing in one system. An ETO order is a project: it has engineering, procurement, manufacturing, assembly, and often installation phases, a budget, milestones, and a schedule. It is also a manufacturing job: it consumes materials, runs operations, and produces a physical product. ETO software has to hold both truths at once, the project view and the manufacturing view of the same order, without the manufacturer running two disconnected systems and reconciling them.
Handling order-specific engineering
ETO software must accommodate the fact that the bill of materials and routing are created during the job. It should let engineering build an order-specific BOM, revise it as the design develops, and feed the finished definition into procurement and production. It should track BOM revisions, because an ETO BOM changes through the life of the job, and a manufacturer must know which version is current and what changed.
Job-level costing
Because every ETO product is unique, there is no standard cost to lean on. Engineer-to-order software has to cost each job individually: capture the estimate made at quoting, then accumulate the actual cost, engineering hours, materials, operations, subcontracting, against that specific job, and show actual against estimate as the job runs. This is the costing model of project work, not of repetitive manufacturing, and it is essential, because job-level cost visibility is the only way an ETO manufacturer knows whether it is making or losing money on a contract before the contract ends.
Managing change
Change is constant in ETO work, and engineer-to-order software has to make change manageable. A customer revision or an engineering change should flow through the affected parts, the BOM, procurement, the schedule, the budget, in a connected way, so the impact of a change is visible rather than discovered later. Software where a change has to be hand-patched into several places loses control of ETO jobs.
Quoting and the estimate
ETO software should support the difficult act of quoting a product that does not yet exist, ideally letting an estimate be built from a preliminary BOM and an engineering estimate, so the quote is grounded rather than guessed, and so the quote can become the job's budget when the order is won. The link from estimate to budget to actual cost is what lets an ETO manufacturer learn whether it quotes well.
The takeaway
Engineer-to-order software and ERP must do what catalogue-oriented manufacturing software cannot: treat each order as a project and a manufacturing job at once, accommodate order-specific engineering and BOM revisions, cost each job individually against its estimate, and keep change under control. An ETO manufacturer should evaluate software specifically on the marriage of project management and manufacturing. For how we approach this, see our manufacturing work.