SAP BOM

A BOM is a structured list of the components required to produce a finished or semi-finished product, each with a quantity. For a bicycle, the BOM lists the frame, wheels, chain and so on. BOMs can be multi-level (components that themselves have BOMs), forming the product structure.

It is worth being precise about what a BOM is not. It is not a routing, which lists operations rather than components. It is not a recipe, which is the process industry equivalent carrying both. And it is not a parts list for service, which is often a different structure entirely because a maintenance engineer needs what can be replaced rather than what it was built from.

• Header & items: the product and its components.
• BOM usage: e.g. production, engineering, costing.
• Multi-level BOMs and where-used lists.
• Alternative & variant BOMs for product variants.

Two fields on a BOM item carry more weight than they appear to. The item category decides whether a component is stocked, non-stock, a text line or a phantom. The component quantity is per base quantity of the header, not per unit, so a BOM with a base quantity of a hundred describes what is needed to make a hundred, and misreading that scales every requirement wrongly.

CS01 creates a BOM, CS02 changes it and CS03 displays it. CS11 explodes it level by level, CS12 shows every level flattened, and CS15 is the where-used list, which answers the question that matters before any change: what else contains this component.

A BOM belongs to a material, a plant and a usage. Usage is the part people miss: a production BOM, an engineering BOM and a costing BOM can all exist for the same material and contain different things, because engineering and manufacturing genuinely disagree about what counts.

Item categories on the components matter too. A stock item is issued from inventory. A non-stock item is procured directly for the order. A text item documents something with no material behind it. A phantom assembly is a grouping that exists in the structure and never as physical stock, so it explodes straight through to its own components.

The tables are MAST linking material to BOM, STKO for the header and STPO for the items.

Half an hour, and it connects one master record to planning, production and cost at once.

1. Display a BOM with CS03 and note the components and quantities.
2. Run CS11 to explode it. Sub-assemblies expand into their own components, and the quantities multiply through the levels.
3. Run MRP for the finished material with a demand against it. Requirements appear for every component, derived from this structure.
4. Create a production order. The components are copied onto it as reservations, again from the BOM.
5. Run a cost estimate. Material cost is the sum of the components at their prices, and it came from the same place.
6. Now change a quantity in CS02 and repeat steps three to five. Everything moves.

One record feeding planning, execution and costing is why BOM accuracy matters more than almost any other master data in production. See MRP for the planning side and routing for the other half of the pair.

The BOM drives MRP (what components to plan/procure), production orders (what to consume), and product costing (roll-up of component costs). An incorrect BOM causes wrong planning, wrong production and wrong costs, so BOM accuracy is critical. It works together with the routing (the steps) to define how a product is made.

It also decides what can be changed safely. Because one BOM often serves several products through shared sub-assemblies, a change reaches further than the person making it expects, and the where-used list is the check that prevents that. Engineering change management exists to make such changes dated and traceable rather than immediate, which matters where a product is certified or regulated.

• How many levels. Deep structures mirror how the product is genuinely built and create more items to plan and confirm. Flat structures are simpler and lose visibility of sub-assemblies.
• Phantom or real sub-assembly. A phantom groups components without being stocked, which suits an assembly that never sits on a shelf. A real one is planned, produced and stocked.
• One BOM per usage or a shared one. Separate engineering and production BOMs are honest about the difference and mean two things to maintain.
• Alternative BOMs. Where a product can be made from different components, alternatives with a production version each is the right model rather than one BOM edited when substitution is needed.

A bill of materials is not static, and how changes are made determines whether history stays meaningful.

Direct change edits the BOM with a validity date. Simple, and the previous state is not recorded beyond the date boundary.

Change master records go further. A change number carries a reason, an effective date and a status, and changes are made under it. That gives you an audit trail: what changed, when it became valid, who authorised it, and which objects it touched. In regulated manufacturing this is not optional.

The important behaviour is date effectivity. A BOM change valid from the first of next month does not affect production orders already created, because they copied the components when they were created. So changing a BOM does not fix orders already in flight, and a change intended to take effect immediately has to be accompanied by a decision about existing orders.

Where-used becomes essential here. A component appearing in forty parents means a change reaches forty products, and the list is the check before rather than the discovery after.

The practical failure is a BOM corrected in a hurry with today's date, while a batch is mid-production against the old structure, producing a variance nobody can explain a month later.

• Scrap, and where it is modelled. Component scrap on the BOM item, assembly scrap on the material, operation scrap on the routing. Each answers a different question, and leaving all three at zero means planning assumes perfect yield.
• Variants or separate materials. A product in six colours can be six materials with six BOMs, or one configurable material with a variant structure. The second is far more powerful and considerably more to set up.
• Where the BOM is maintained. Engineering owns the design and manufacturing owns what is actually consumed. Separate usages let both be true.
• How change is controlled. Direct edits for a business that moves fast, change masters where traceability is required.

• Inaccurate BOM, wrong planning/production/costing.
• Wrong BOM usage selected.
• Not maintaining variants/alternatives.

• Changing a shared component without the where-used list. The change reaches every parent that contains it.
• Scrap factors left at zero. Planning then assumes perfect yield and consistently under-orders components.
• Validity dates ignored. BOMs are date-effective, and a change applies from a date rather than to orders already created. See confirmations and capacity for what consumes it downstream.

• Maintaining one BOM for engineering and manufacturing when they genuinely differ. One of the two ends up wrong, and it is usually the one that plans production.
• Phantom assemblies used to tidy the structure rather than to model reality. They explode through, so they change what is planned and reserved.

Reading a BOM is straightforward, and structuring one so planning, production and costing all behave correctly is the part you do in the course.

The check before any BOM change is the where-used list. A component in forty parents means the change reaches forty products, and finding that out afterwards is how a correction becomes an incident.