BoM in PIM and ERP

A bill of materials lists every component and material needed to make one product: which items, in which quantities, and when production needs them. In most companies the list lives in ERP, because purchasing and production planning run there. The question for product data teams is how much of that structure belongs in the PIM, and who keeps it correct.

This article explains what a BoM is, how it differs between ERP, PLM and PIM, and how product structures, spare parts, configurable products and exploded views fit in a product record.

What is a bill of materials?

A BoM is a structured list. Each line names an item, a quantity and a unit. A line can be a raw material, a purchased part or a sub-assembly, and a sub-assembly has a BoM of its own. That nesting makes the BoM a tree: the finished product at the top, assemblies below, single parts at the bottom.

A bicycle shows the idea. The bike has a frame, two wheels and a drivetrain. A wheel has a rim, spokes, a hub and a tyre. The drivetrain has a chain, a crankset and a rear derailleur. Each level is a list, and each item on the list has its own article number.

Two views of the same tree are common:

• Single-level BoM: only the direct children of one item.
• Multi-level (indented) BoM: the full tree, every level below the product.

An aggregated list flattens the tree into one cumulative list of all parts and total quantities, with the hierarchy still readable. Production planning uses that to calculate material needs.

Who owns which BoM

The same product has more than one BoM, because different teams need different cuts of it. The common split:

Which system holds which BoM

System	What it owns	Who works in it	The question it answers
ERPEnterprise resource planningERP guide	Transactions and operations: orders, stock, purchasing, pricing and finance.	Finance, supply chain, purchasing and sales operations.	What did we buy, make, sell, ship and invoice?
PIMProduct information managementYou are here	Sellable product content: attributes, descriptions, asset links, translations and channel versions.	E-commerce, marketing, category and product content teams.	Is this product complete and ready to sell on this channel?
PLMProduct lifecycle managementPLM guide	The product while it is designed and engineered: specifications, bills of materials, changes and compliance.	R&D, engineering, quality and sourcing.	What exactly are we making, and which version is released?
PDMProduct data managementPDM guide	Engineering files and technical data: CAD models, drawings and revisions.	Engineers and product designers.	Which revision of this design is current?

• Engineering BoM (EBOM): the product as designed. It follows the drawings and CAD structure and sits in PLM or PDM. See what is product data management and PLM and PIM integration.
• Manufacturing BoM (MBOM): the product as built and bought. It adds packaging, consumables and routing, and is tied to suppliers, stock and work orders. It sits in ERP.
• Sales BoM: the product as sold. It shows what belongs in the box, which options exist and which parts can be ordered separately. It is the version a customer or dealer needs, and it belongs in the PIM.

The engineering BoM can contain items a customer never sees, such as internal fasteners. The manufacturing BoM can contain items that do not exist in the catalog. The sales BoM is a deliberate selection. Do not copy one into the other without deciding what each audience needs.

BoM in ERP versus BoM in PIM

In ERP the BoM is an operational tool. It drives material requirements, purchase orders, stock reservations and costing. It has to be exact, versioned and tied to article numbers, quantities and units. ERP is where inventory, procurement, sales, finance and production planning meet, so a wrong line has a direct cost.

In a PIM the same structure serves selling and service. It answers questions a customer or dealer asks: what is in the box, which parts fit this model, what does the assembly look like, which option adds which part. The PIM does not plan production and does not need cost or lead-time detail from the BoM.

That gives a practical split:

• ERP keeps the quantities, units, cost and planning data of the manufacturing BoM.
• The PIM keeps the structure the channels need, the descriptive data for each part, and the relationships between products.
• Both reference the same article numbers, so a change in one can be matched in the other. The wider boundary is covered in where ERP stops and PIM starts.

How a BoM can sit in the PIM data model

The PIM data model frames the rest of the product record. A BoM can be placed in that model in four ways. Which one fits depends on the PIM you run and on what you need to do with the list.

1. As a product attribute

   The list is a characteristic of the product. The PIM stores it as part of the product record. This is the simplest option and fits short, flat lists, such as the contents of the box.

2. As a separate object

   The BoM is its own object. You maintain it on its own and link it to the product it belongs to. This suits structures that are reused by several products or that have their own lifecycle.

3. As a hierarchy

   The PIM stores the BoM as a tree. Primary components sit at the top and subcomponents below. This fits multi-level products and lets the storefront show assemblies.

4. As an aggregated list

   One cumulative list holds every material and component, with quantities and the hierarchical relations written out. This suits exports and documents that need the full parts list in one place.

Many PIMs support more than one of these. If you only need the sales view, a hierarchy or a set of product relationships is usually enough. If you want the full manufacturing list in the PIM, ask first why: it is often a sign that a feed from ERP is missing.

Product structures and variants

A BoM is not the same as a set of variants. A BoM lists the parts inside one product. Variants are versions of a product that a customer chooses between, such as size, colour or voltage.

The two interact. A variant can have its own BoM when its parts differ: a 24 V motor and a 12 V motor are different items on different lists. Variants that only change a label or a colour option may share one BoM. Model the shared parts once at the parent level and override only what differs, so a change to a shared part is made in one place. More on structure and attributes is in PIM features and capabilities.

Spare parts

Spare parts are where the BoM matters most for customers. A service technician or a machine owner needs to find the right part for one specific model and revision.

A workable pattern in a PIM:

• Each spare part is a product with its own record, article number, description, dimensions and images.
• A relationship links the part to every product it fits. A part can fit many products, and a product has many parts, so this is a many-to-many link, not a text field.
• The relationship can carry extra data, such as the position number on a drawing, the quantity used and the valid revision range.
• Superseded parts point to their replacement, so old product pages do not end in a dead end.

The parts list of the product is then a view of its relationships. When ERP creates a new part, the integration brings the article in, and the product team adds the descriptive content and links it.

Configurable products

A configurable product has a base structure plus a set of options. Choosing an option adds or swaps parts. The final BoM is the base list plus the selected options.

Split the responsibilities this way:

• The PIM holds the options, their descriptions and images, and the rules that say which combinations are allowed.
• The ERP or a configurator builds the resulting manufacturing BoM from the chosen options.
• Both systems share the option and part identifiers, so an order that arrives with a configuration can be traced to the parts.

If the rules live in several places, the shop will offer combinations that production cannot build. Decide where the rules live and let the others read them.

Exploded views

An exploded view is a drawing that shows a product pulled apart, with each part marked by a number. It is the visual form of the BoM and the main way people choose a spare part.

To support it in a PIM:

• Store the drawing as an asset linked to the product, ideally together with the hotspot positions.
• Match each hotspot number to a part relationship, so a click on the drawing opens the correct part record.
• Keep drawing revisions linked to product revisions, so a customer does not see a drawing that no longer matches their model.

The drawing itself usually comes from engineering. The PIM publishes it and keeps the link between drawing, parts and product current.

Keep the PIM copy and the ERP copy aligned

The BoM drives production planning and material requirements in ERP. Planning and execution stay accurate when the structure in the PIM and the structure in ERP stay in sync.

Practical rules:

• Use article numbers as the key. Parent and child items must carry the same identifier in both systems.
• Move changes forward, do not retype them. A new revision in ERP or PLM should reach the PIM through an integration.
• Check on a schedule. Report parents with missing children, children with no parent and quantities that differ between systems.
• Keep status in step. A part that is blocked or phased out in ERP should not stay orderable in the shop.

Data quality rules for these checks are in product data quality and governance. For the base definition of the system, see what is PIM.

Where to go from here

Both tools are free and independent of any vendor.

Not sure you need a PIM yet?

A short check that shows whether a dedicated PIM helps your catalog, or whether spreadsheets and ERP still do the job.

Check if a PIM fits

Ready to compare vendors?

Answer questions about your scale, sector and must-haves and get a ranked shortlist.

Build my vendor shortlist