An engineering bill of materials that defines the product from a design perspective, listing components and assemblies as engineered.
**eBOM** commonly refers to the **engineering bill of materials**: a structured list of all components, subassemblies, and materials that define a product from the *design and engineering* perspective.
An eBOM:
– Is created and maintained primarily in CAD, PLM, or engineering systems.
– Reflects how the product is engineered, including versions, options, and configuration rules.
– May include virtual or logical groupings (e.g., functional assemblies) that do not map 1:1 to manufacturing steps.
– Is typically version-controlled and tied to engineering change processes.
It usually precedes and feeds other BOM views, such as the manufacturing BOM (mBOM) and service BOM, but is not itself a detailed manufacturing routing or work instruction.
In industrial and regulated manufacturing, the eBOM:
– Defines the **design-intent structure** that downstream systems (PLM, ERP, MES, QMS) must respect.
– Serves as the reference for design traceability, change impact analysis, and configuration control.
– Is used to derive controlled manufacturing structures (mBOMs, routings) that are then executed on the shop floor.
– May be part of the design history, technical file, or device master data in regulated sectors, but does not by itself represent executed production.
The eBOM is often managed under strict revision control and approval workflows, especially where design changes must be formally assessed and documented.
In a typical integrated landscape:
– **PLM** manages the eBOM as the source of design truth.
– **ERP** consumes eBOM data to help generate purchasing, planning, and sometimes mBOM structures.
– **MES** uses information derived from the eBOM (often via mBOMs and routings) to drive work orders, work instructions, and as-built records.
MES usually does **not** own the eBOM. Instead, it:
– References product structures that originate from eBOM definitions.
– Maps engineering structures to manufacturing operations and work centers.
– Records **as-built** configurations that can be compared back to eBOM and mBOM for conformance.
For complex, nested assemblies (such as in aerospace):
– The eBOM may contain deep, multi-level structures with many optional or alternate parts.
– MES and ERP systems must map these engineering structures to executable mBOMs and routings.
– As-built traceability in MES depends on correctly relating the executed structure back to the eBOM-defined design intent.
In such contexts, differences between the eBOM and mBOM (e.g., grouping or sequencing changes) must be carefully controlled and documented to maintain traceability and compliance.
**Included in eBOM:**
– Part numbers and descriptions as engineered.
– Hierarchical product structure (assemblies, subassemblies, components).
– Engineering-relevant attributes (e.g., specifications, materials, versions, design options).
**Generally not included or only indirectly represented:**
– Detailed operation sequencing or routing logic (this belongs more to process plans or mBOM/routing data).
– Shop-floor resources, labor standards, or scheduling parameters.
– Actual production records, as-built data, or quality results.
eBOM is frequently contrasted with:
– **mBOM (manufacturing bill of materials):**
– mBOM is oriented to *how* the product is built (operations, work centers, sometimes pack levels).
– eBOM is oriented to *what* the product is as engineered.
– **As-built BOM or configuration:**
– As-built structures describe what was *actually produced* in a specific lot, unit, or serial number.
– eBOM describes the *intended design* and allowable configurations, not the executed outcome.
– **Service BOM:**
– A service BOM structures the product from a maintenance or service viewpoint.
– eBOM structures the product for design and engineering.
Recognizing these distinctions is important when integrating PLM, ERP, and MES and when discussing traceability or change impact across systems.