Manufacturing and industrial IoT fundamentals

The bill of materials is the structural recipe for a product, and it is a tree rather than a list — which is the whole reason explosion arithmetic exists.

Order: 250 x PUMP-A200

item                      level  type        qty per parent   total required
------------------------  -----  ----------  --------------  --------------
PUMP-A200                   0    finished           -               250
  HOUSING-SUB               1    assembly           1               250
    CASTING-88              2    purchased          1               250
    GASKET-12               2    purchased          2               500
    BOLT-M8                 2    purchased          6             1,500
  MOTOR-SUB                 1    assembly           1               250
    STATOR-40               2    purchased          1               250
    BEARING-6204            2    purchased          2               500
    BOLT-M8                 2    purchased          4             1,000
  LABEL-KIT                 1    purchased          1               250

BOLT-M8 appears twice:  1,500 + 1,000 = 2,500 required in total

Level zero is the finished item and each level below is what the level above consumes. Explosion is the recursive multiplication down that tree: quantity per parent times the parent's own requirement, all the way to purchased parts. That is the calculation material requirements planning performs, and it is why a single-table BOM design fails — a flat parts list cannot express that a gasket is consumed by a sub-assembly rather than by the pump.

BOLT-M8 is the detail that catches people. A common part appears at several places in the tree, so the requirement is a sum across branches rather than a lookup, and any query written as a join to one parent under-orders. The same applies to a sub-assembly that is also sold as a spare: it is both a level 1 component and a level 0 finished good, so the item master and the structure must be separate tables joined by a parent/child edge.

Two modelling consequences follow. The structure is effectively versioned, because engineering changes the BOM and a work order released last week must explode against the revision in force when it was released, not today's. And scrap allowance belongs on the edge, not the item: if welding loses 3% of castings, the requirement is 258 rather than 250, and storing that factor per item makes it wrong for every other product using the same casting.

A routing is the process half of the product definition: the ordered sequence of operations that turns the bill of materials into the finished item, each operation naming where it happens, how long it takes, and what setup it needs. A work centre is that where — a machine, a cell, a bench, or a group of interchangeable ones — carrying a capacity and a cost rate. The pairing matters because the BOM tells you what to buy and the routing tells you what to schedule, so capacity planning is entirely a routing question. The detail engineers miss is that operation time splits into setup time, which is per order, and run time, which is per unit; conflating them makes small orders look cheap and destroys every scheduling estimate. Routings are also versioned alongside the BOM, because moving an operation to a different machine changes both cost and capability.

An authorisation and a container: permission to consume defined materials and plant time to produce a defined quantity of a defined item, and the record of what actually happened while doing it. It is the central transaction of the domain in the way an order is in commerce, and almost every other manufacturing record hangs off it — material issues, labour bookings, machine data, quality results, scrap, genealogy. Its lifecycle is worth knowing by name: planned, released, in progress, completed, closed. The engineering consequence is that quantities are never a single number. A work order has an ordered quantity, a confirmed good quantity, a scrap quantity and a remaining quantity, and they disagree constantly. A schema with one quantity column on a work order is a schema that cannot answer whether the order is finished.

The same three words are used to describe production and they imply three different schemas, so the first question about any plant is which one it is.

                    discrete              batch                  continuous
------------------  --------------------  ---------------------  --------------------
unit produced       a countable item      a quantity made in     a flow, measured in
                                          one run                mass or volume
identity            serial number         lot or batch number    a time interval
recipe              quantity per unit     formula with a scale   ratios and setpoints
                                          factor
process definition  operations at work    phases and steps in    control loops
                    centres               equipment units
traceability key    serial -> component   batch -> input lots     timestamp -> lot
                    serials                                       assigned at packing
yield accounting    good units, scrap     yield per batch,        rate, and hours
                                          partial batches         spent off-specification
cost of a stop      WIP waits in queue    in-progress material    material is scrapped
                                          may be salvageable      and restart takes hours
example             pumps, cars, boards   paint, tablets, beer    steel, paper, refining

Read the identity row first, because it decides everything downstream. Discrete production can carry a serial per unit, so traceability is a graph of individual things and a recall can name exact units. Batch production cannot: the smallest identifiable thing is a run, so a defect means the whole lot is suspect. In continuous production even a lot is a fiction — it is a time window somebody assigned at the packing line, and the boundary is approximate by nature.

The cost-of-a-stop row is why deployment practice differs so sharply. Stopping a discrete line queues work; stopping a continuous process destroys in-progress material and buys hours of restart, which is the concrete reason a maintenance window in a refinery is quarterly and in an assembly plant may be nightly.

Most real plants are hybrids, and that is the trap. A pharmaceutical site makes tablets in batches and then packs them into serialised cartons, so the model must carry a batch-to-serial transition and the traceability query crosses it. Asking "where does batch identity become serial identity?" is a question that only someone who has built this asks.

A tree of physical things — enterprise, site, area, line, cell, machine, component — that gives every tag, event, work order and maintenance record a place to hang. It is the join key of the domain, in the way a customer identifier is in a commercial system, and its quality determines whether any analysis is possible. Without it you cannot answer "what was the output of line 2 last Tuesday", because the sensors know their own names and nothing else. The failure mode is that plants commissioned by different integrators over twenty years each invented their own naming, so the same machine class is FIL-02, Filler2 and L2-FLR in three systems and there is no key linking them. Building and owning that hierarchy is usually the largest unbudgeted task in an industrial data project, and it is not a lookup table — it changes as equipment moves.

Material that has been released to production and is neither raw stock nor finished goods: partly built units sitting in queues, in machines, or waiting for inspection. It matters commercially because it is capital tied up in something unsellable, and operationally because queue length is what turns a fast line into a slow lead time. It is hard to measure because it exists physically before it exists in any system: a unit is only recorded as having moved when someone books an operation, and bookings happen at the end of a shift, in batches, sometimes wrongly. So system WIP lags floor WIP, and the discrepancy is discovered at a stock count. Little's law is the useful framing — WIP equals throughput times lead time — because it shows that halving WIP at constant throughput halves lead time, which is why reducing it is a strategy rather than an accounting tidy-up.

Scrap is material that failed and cannot be recovered, so it is written off and the work order needs more input to hit its quantity. Rework is material that failed and can be corrected by additional operations, so it is recovered at the cost of unplanned labour and time. The distinction matters more than it sounds because they behave differently in every system: scrap consumes material and produces nothing, while rework consumes capacity that was not in the schedule and therefore silently steals it from other orders. Rework is also the standard place quality metrics are gamed, since a unit reworked into conformance counts as good at the end of the line while having failed in the middle. That is precisely what first pass yield exists to expose, and why a plant reporting high final yield and no first pass yield is telling you something.