 
 
Last Updated on July 21, 2026 by Shrestha Dash
Key Highlights
- Engineer-to-order manufacturing is fundamentally different from make-to-order: the product does not exist when the order is placed, and the ERP implementation and process design should be architected around that reality, not adapted from a system built for stable BOMs and repetitive production.
- The most common engineer-to-order ERP implementation challenges begin with selecting a system that handles make-to-order well and assuming ETO is a close cousin. The difference surfaces in mid-project engineering changes, cost-to-complete visibility, and milestone billing, not during the demo.
- For many ETO manufacturers, CAD/PLM integration becomes a critical capability rather than an optional enhancement. When the BOM lives in CAD first and is manually re-entered into ERP, version mismatches and procurement errors follow. Designing this integration before implementation begins is critical.
- Change order management is commonly one of the more challenging areas of ETO implementations, yet it is one of the most frequent operational realities in any ETO environment.
Introduction
In engineer-to-order manufacturing, every customer order initiates a project. The product does not yet exist. The bill of materials has not been created. The routing has not been defined. The delivery schedule is an estimate built on engineering judgment, not production history. Until engineering completes its work, the ERP has nothing confirmed to plan against.
This is the reality that makes engineer-to-order ERP implementation challenges so distinct from implementations in other manufacturing modes and so frequently underestimated. The ERP is not being deployed into a stable environment with known products and repeatable processes. It is being deployed into an environment where the defining characteristic is that nothing is standard.
Most ERP implementations follow a sequence: document the current process, configure the system to support it, train users, go live. In ETO manufacturing, that sequence has an important prerequisite that most implementations skip: designing the process model first. Without it, the system ends up configured around how the business currently works, including all the workarounds, manual handoffs, and information gaps that existed before the implementation began.
This blog examines the specific patterns where engineer-to-order ERP implementation challenges that cause projects to miss the mark, and what the process-first alternative looks like in practice.
Why ETO Is Fundamentally Different from Every Other Manufacturing Mode
Understanding engineer-to-order ERP implementation challenges begins with being precise about what makes ETO operationally distinct.Â
The Manufacturing Mode Spectrum
| Mode | When Does the BOM Exist? | Is the Product Configurable? | Primary ERP Organizing Principle |
| Make-to-Stock (MTS) | Before the order | No – standard product | Forecast and inventory |
| Configure-to-Order (CTO) | At order entry | Yes – from predefined options | Variant configuration rules |
| Make-to-Order (MTO) | Before the order | Partial – customer-specific variants | Production scheduling |
| Engineer-to-Order (ETO) | After the order – during engineering | Fully custom – no predefined template | Project |
In MTO, the customer may specify color, dimensions, or materials but the product template and BOM structure already exist. Engineering adapts; it does not originate. In ETO, engineering originates the entire product. The BOM is created as part of the project. The routing is developed as designs mature. Procurement cannot begin until engineering releases components and even then, designs continue to evolve.
Many general-purpose manufacturing ERP systems designed for companies that make the same products repeatedly are built around stable BOMs, predictable scheduling, and standard cost models. In an ETO environment, many of those assumptions no longer hold. The BOM is dynamic. The schedule shifts as engineering progresses. Standard costing alone is often insufficient when no two jobs share the same product structure. This is often more than a configuration problem. It is a data model problem and it is one of the foundational engineer-to-order ERP implementation challenges that cannot be resolved by configuring a discrete manufacturing ERP more carefully.
ERP Selection Requirements Template
This resource provides the template that you need to capture the requirements of different functional areas, processes, and teams.
The Most Common ETO ERP Failure Pattern
The typical engineer-to-order ERP implementation challenge does not surface during the selection process. It surfaces six months into the implementation, when the team attempts to configure the system around ETO-specific workflows and discovers how far the underlying data model is from what they need.
A commonly observed implementation pattern follows a consistent sequence:
How ETO Implementations Typically Go Wrong
| Stage | What Happens | Why It Creates Problems |
| Selection | A system with strong MTO and job costing capability is selected | ETO complexity is underestimated; demo scenario uses a simplified job |
| Requirements | Standard manufacturing requirements are documented | ETO-specific needs such as dynamic BOM, project costing, milestone billing are partially captured |
| Configuration | System is configured for current-state workarounds | Disconnected processes are replicated in a new platform |
| Engineering handoff | BOM and routing workflows are designed late in the project | CAD integration deferred; manual re-entry continues |
| Go-live | System goes live with known gaps | Workarounds persist; adoption is limited in engineering |
| Post-go-live | Project profitability and change orders managed outside the system | ERP is used for finance; engineering and project management remain disconnected |
A consistent finding across ETO implementation guidance is that the most critical process to design correctly is the flow from engineering design to production execution — and it needs to be mapped in detail before implementation begins. Changing the BOM structure, part numbering conventions, or revision management approach after go-live is extremely disruptive.
The specific engineer-to-order ERP implementation challenges that most commonly remain unresolved are addressed in the sections that follow.
ERP System Scorecard Matrix
This resource provides a framework for quantifying the ERP selection process and how to make heterogeneous solutions comparable.
The CAD/PLM Integration Gap: Where BOM Errors Begin
In many ETO environments, the engineering BOM originates in CAD or PLM, not in ERP. An engineer designs a component, models the assembly, and the resulting structure becomes the basis for procurement, production planning, and cost estimation. In a disconnected environment, someone then manually re-enters that BOM into the ERP.
This manual bridge between CAD and ERP is where engineer-to-order ERP implementation challenges most visibly manifest on the shop floor.
What Happens Without Structured CAD-ERP Integration
- An engineer changes a component revision in CAD; procurement buys the old part number because the ERP item master has not been updated
- The BOM on the shop floor does not match the current engineering design; production builds to outdated specifications
- Revision control in CAD and revision control in ERP diverge over time; reconciling them requires manual effort that nobody owns
- Engineering change notifications are issued by email; the ERP is updated when someone gets to it which is often after procurement has already acted on the previous version
The decision about how CAD data flows into ERP, what triggers a BOM update, how revisions are managed, how engineering releases are approved before production acts on them should be designed before ERP configuration begins. Part numbering conventions, revision management approach, and the distinction between engineering BOM and manufacturing BOM all need to be resolved at the process design level, not discovered during configuration or testing.
CAD/PLM integration is consistently on the critical path of these projects and it is one of the engineer-to-order ERP implementation challenges most commonly deferred until after go-live, with predictable results.
Project Profitability Visibility: Why ETO Companies Find Out Too Late
One of the defining engineer-to-order ERP implementation challenges is the timing of financial visibility. In most ETO environments without a properly implemented ERP, project profitability is often not known until the job closes, weeks or months after delivery, when the opportunity to act has passed.
How Cost Visibility Degrades Without ERP Integration
| Cost Category | Without Integrated ERP | With Integrated ERP |
| Engineering labor | Captured weekly; not linked to job budget | Posted in real time against project WBS |
| Material cost | Known at invoice; not compared to estimate by phase | Committed cost tracked from PO; compared to budget line |
| Subcontract cost | Tracked in spreadsheet; reconciled at project close | Committed against project budget; variance visible before invoice |
| Estimated vs. actual | Compared post-delivery | Compared at every project review while the job is open |
The implementation goal should be to bring visibility forward to real time, not to improve post-delivery reporting, but to give project managers actionable information while the job is still open. When engineering hours are running 15% over estimate halfway through a project, a project manager with real-time cost data can act. One who discovers the overrun six weeks after delivery cannot.
Change Order Management: Where Most Implementations Are Weakest
Change is not an exception in engineer-to-order manufacturing; it is the norm. This is among the most consequential engineer-to-order ERP implementation challenges because it sits at the intersection of engineering, operations, and finance simultaneously.
Customers revise specifications mid-project. Material availability forces component substitutions. Engineering discovers a component cannot be manufactured as specified. Scope is added or modified after the contract is signed. The question is not whether changes will occur, it is whether the ERP handles them in a controlled, connected way, or whether each change triggers a chain of manual updates across disconnected systems.
What an Uncontrolled Change Order Process Looks Like
- The customer approves an engineering change verbally or via email
- Engineering updates the CAD model; the ERP BOM is updated separately, later
- The cost impact is estimated in a spreadsheet; it may or may not reach the project budget
- The schedule impact is noted by the project manager; the ERP production schedule may not reflect it
- The billing milestone is tracked in a contract document; finance is notified when the project manager remembers
Each of these disconnects is individually manageable. Across a 14-month project with 40 change events, they create an environment where nobody has a reliable picture of current contract value, current cost commitment, current schedule, or current billing eligibility.
A well-designed ETO ERP implementation can treat a change order as a system event: cost, schedule, and billing update simultaneously when an approved change is entered. Project managers see the revised cost-to-complete. Finance sees the updated contract value. Procurement sees updated material requirements. That connectivity must be designed deliberately at the process level before configuration begins because few ERP systems provide this capability out of the box without configuration.
How an Independent ERP Advisory Consultant Can Help Here
Engineer-to-order ERP implementation challenges are often not primarily a technology problem. They are a process sequencing problem. Most ETO implementations frequently miss the mark not because the wrong system was selected, but because the process model was not sufficiently designed before the system was configured.
Process-First vs. System-First Implementation Sequence
| Phase | System-First (Common) | Process-First (Independent Advisory Approach) |
| Pre-implementation | System selected; implementation partner engaged | Process model designed: engineering handoff, BOM structure, change order workflow, milestone billing |
| Requirements | Current-state process documented | Future-state process designed; gaps between current state and ERP capability identified |
| CAD integration | Deferred to post-go-live | Designed in requirements phase; part numbering and revision management aligned before configuration |
| Project costing | Configured using standard job costing | Estimated-vs-actual structure designed to match how the business estimates profitability |
| Change orders | Addressed via workaround | Workflow designed with cost/schedule/billing update logic before configuration begins |
| Go-live readiness | Gaps discovered in production | Known gaps resolved in design; go-live against a validated process model |
An independent ERP advisory consultant approaches engineer-to-order ERP implementation challenges by building the process model first, then mapping it to the selected system. The system is configured against the future-state process, not the current state including its workarounds.
ElevatIQ works with engineer-to-order manufacturers as an independent ERP advisory consultant. Our engagements begin with process re-engineering and enterprise architecture design, mapping the engineering-to-production workflow, designing the CAD/ERP data bridge, modeling the change order process, and defining the project costing structure before any configuration begins. We hold no implementation certifications with any ERP vendor and receive no commissions from software providers.
Conclusion
Engineer-to-order ERP implementation challenges often follow recognizable patterns which means they are also preventable. The ETO manufacturers who navigate implementations most successfully share a consistent characteristic: they invest in process design before system configuration. They understand that the ERP alone is not a solution to a process problem. It is a platform that amplifies whatever process it is configured around which means configuring it around the wrong process, or an under-designed one, produces a more expensive version of the problems that existed before.
The signals that an ETO implementation is heading in the wrong direction are recognizable before go-live:
- CAD/ERP integration is being deferred to a later phase because “the integration is complex and we need to go live first”
- The project costing structure in the ERP does not match the way the business estimates jobs, so estimated-versus-actual comparisons will not be meaningful
- Change order management is being handled outside the ERP, with a plan to “configure it properly in phase two”
- Engineers are not involved as active users in the implementation; they are being trained on the system after it is already configured
Each of these signals points to the same underlying issue: the process model was not designed before the system was configured. An independent ERP advisory engagement that precedes rather than follows the implementation partner engagement changes what the configuration phase produces and what the system delivers on go-live day.
ERP Selection: The Ultimate Guide
This is an in-depth guide with over 80 pages and covers every topic as it pertains to ERP selection in sufficient detail to help you make an informed decision.
Related Posts:
