Why ERP cannot see assemblies

Enterprise Resource Planning (ERP) systems provide a comprehensive framework for planning and coordinating resources. They organise materials, costs, schedules and financial commitments across the enterprise.

In engineering-driven projects, however, execution problems frequently arise at the level of assemblies. These problems remain invisible to ERP until they manifest as delays, replanning or cost overruns.

This invisibility is not the result of missing data or insufficient configuration. It is a structural limitation rooted in what ERP systems are designed to represent.

The planning perspective of ERP

ERP systems operate in the domain of planning certainty. They translate demand into material requirements, orders and schedules based on assumed product structures and lead times.

From this perspective, the Bill of Materials is primarily a planning object. It supports aggregation, procurement and cost calculation rather than execution readiness.

Assemblies appear as collections of items, not as execution units with evolving maturity.

Assemblies as execution units

In engineering-driven projects, assemblies are not static groupings. They are the points where definition, coordination and dependency resolution converge.

An assembly may exist formally in the BOM while remaining non-executable in practice. Interfaces may be unresolved, dependencies incomplete and constraints still under discussion.

ERP has no structural representation for this state. An assembly is either present or absent in planning terms; its executability is not evaluated.

Why progress appears coherent

From an ERP perspective, progress often appears coherent. Materials are ordered, operations are scheduled and costs are allocated according to plan.

This coherence is derived from planning logic, not from execution reality. It reflects assumed readiness rather than observed executability.

As long as planning assumptions remain unchallenged, assemblies that are structurally blocked remain invisible.

Change propagation without readiness awareness

Engineering-driven projects are characterised by continuous change. As definitions evolve, dependencies propagate across assemblies.

ERP systems manage change through revisions and replanning. They update quantities, dates and costs, but they do not evaluate whether assemblies are ready to absorb these changes in execution.

As a result, execution risk accumulates at the assembly level while planning structures remain internally consistent.

The execution dimension ERP does not represent

The inability of ERP to see assemblies as execution units is not a flaw. It reflects a design focus on planning stability rather than execution readiness.

Assemblies exist in ERP as planning artefacts, not as evolving execution carriers. The distinction between formal definition and practical executability lies outside the system’s scope.

In engineering-driven environments, this distinction becomes critical. Execution coherence depends on understanding not only what is planned, but what can actually be executed.