Structures & MRP

Bills of Materials, Recipes and Kits

A structure says what something is made of. Manufacturing calls it a bill of materials, food production calls it a recipe, and distribution calls it a kit — but they are the same shape, and the platform models them once.

One graph, any depth

A structure is a parent with children, and a child can itself be a parent. An assembly contains sub-assemblies which contain components, to whatever depth your product genuinely has. There is no fixed number of levels.

What each component line carries

• Quantity — how many of the child go into one of the parent.
• Scrap — expected loss, so requirements reflect what you must buy rather than what ends up in the product. A component with 5% scrap needs more purchased than consumed.
• Sequence — the order components are consumed or assembled, which drives works instructions.
• Revision — which version of the structure this line belongs to.
• Effectivity dates — when this line applies. See the next article; this is not optional.

Kits versus assemblies

The distinction is what happens to stock. A kit is picked and shipped as its components — the parent may never exist as stock. An assembly is built: components are consumed and the parent is received into stock as a new item. Decide which you are modelling before configuring, because they produce different movements.

Scrap is not a rounding fudge

Use scrap for genuine, predictable loss — offcuts, evaporation, test failures. Do not use it to compensate for inaccurate quantities, because it will disguise the inaccuracy in exactly the reporting that would otherwise reveal it.

Getting structures in

Import them rather than keying them, and import the deepest level first so a parent never references a child that does not yet exist. Verify a sample by exploding it and comparing against your existing system before trusting the whole set.

Effectivity Dates and Revisions

Every line in a structure carries effectivity dates — the window during which that component belongs to that parent. This is deliberately not optional.

The question effectivity answers

A structure without dates can only tell you what a product is made of now. The question that actually gets asked is what it was made of in March — and it is asked in the worst circumstances, usually after a recall, a customer complaint or a supplier defect.

If a supplier tells you a batch of components shipped between two dates was defective, you need to know which of your products used that component during that window and which customers received them. Without dated structures, the honest answer is that you cannot tell, and the practical answer is to recall everything.

Changing a structure

You do not edit a structure line to change a component. You end the effectivity of the old line and start a new one from the changeover date. Both remain, so both the old and the new answer are available depending on the date you ask about.

Revisions

A revision groups a set of lines as a named version. Effectivity dates say when something applied; revisions say which design it belonged to. Use revisions where your engineering process already thinks in versions, and rely on dates for the chronological question.

Planning a changeover

Because effectivity is dated, a future change can be entered in advance. Set the new line to start on the changeover date and end the old one the day before, and the system builds correctly on the day without anyone remembering to make the edit at midnight.

Check remaining stock of the outgoing component when planning the date — a changeover that strands inventory is an expensive way to be tidy.

Explosions are dated too

When you explode a structure, the date matters. Exploding for a works order due next month uses the structure effective then, not the one effective today. If an explosion looks wrong, check the date you asked about before checking the structure.

Routings and Requirements Planning

A structure says what a product is made of. A routing says how it is made — the operations, in sequence, and where each happens.

Routings

Each operation carries its work centre, its sequence, and the time it takes, usually split between setup and run time. Setup is per batch and run is per unit, which is why doubling a batch rarely doubles the elapsed time.

Routings give you works instructions, capacity requirements per work centre, and a basis for costing labour and machine time against a product.

Requirements planning

Planning takes demand — orders, forecasts, minimum stock levels — explodes it through the structures, nets off what you already have and what is already on order, and tells you what must be made or bought and by when.

Netting is the part worth understanding. Requirements are not gross: if you need 100 and hold 30 with 20 on order, the requirement is 50. That is why stock accuracy determines whether planning output is useful. Planning against wrong stock produces wrong suggestions with complete confidence.

Lead times

Working backwards from a due date through each level's lead time is what produces the start dates. A component with a six-week lead time needs ordering six weeks before it is consumed, not before the finished item is due. Enter realistic lead times, including the ones your suppliers actually achieve rather than the ones they quote.

Planning suggests, it does not act

Output is a set of suggestions for a person to review and convert into real orders. It does not place purchase orders on its own. Treat a run that produces surprising suggestions as a question about the data — usually stock, lead times or an effectivity date — rather than as an instruction.

Before you rely on it

• Stock must be accurate, including reservations.
• Structures must be complete and correctly dated.
• Lead times must be realistic.
• Open purchase orders must be in the system, or planning will suggest buying what is already coming.

Run planning in parallel with your existing method for a cycle or two and compare, before anybody acts on it.