Load-centric vs order-centric: one picture of the difference
Print the schedule a commercial heat-treat shop actually runs, and it is not a list of orders. It is a list of loads: this recipe, this furnace, these parts, going in together at ten past two. The orders are still there — every part in a load belongs to one — but they are not the rows. The load is the row.
Most ERPs print the other list. That single difference is why the useful schedule ends up on a whiteboard, and it is easiest to see as a picture.
What the picture is built to show
Two facts, and an order-centric model can state neither.
Read it left to right and three order lines — three different customers — converge on one load. The furnace does not care whose parts they are: same recipe, compatible fixturing, room to spare, so they run together. That is a load being assembled, and it happens on almost every charge.
Now read the red line on its own. One order line — Turbine Ltd’s rings — leaves for two loads. Harden now, temper later: different furnace, different recipe, hours apart, both part of the same line’s history. Neither run is optional and neither can stand in for the other.
So the link between order lines and loads is many-to-many, running in both directions at once. That is not an edge case the shop hits occasionally. It is the normal shape of a day’s work.
Why order-centric software can’t draw the red line
An order-centric system models a line moving through operations, each step occupying a resource for a while. It is a genuinely good model — it fits a machine shop almost perfectly, where a part goes to a mill, holds it, and moves on.
Ask it which parts were in the furnace together and the honest answer is a shrug. It knows each line was “at heat treat.” It does not know which lines shared a charge, because the horizontal links in the picture — parts from different orders sitting inside one node — have nowhere to live. You can bolt on a note field, but a note is not a record you can schedule against, price, or trace. The whiteboard exists precisely to hold what the note cannot.
Make the load the node, and three things stop fighting you
The fix is not a heat-treat plug-in bolted onto the order. It is treating the load as a real object in its own right — its own furnace, its own recipe, its own list of the lines that went into it. Once it is real:
You schedule what you actually run. Weight, piece count, fixturing and work-zone volume are properties of the load, not the order. Planning loads is packing furnaces; planning orders is guessing at it. The schedule and the shop floor finally describe the same thing.
You price where the cost is incurred. A furnace cycle costs about the same half full as full, so heat treat is billed across weight, piece and load together — and only a model with the load as a real object can put a number on the thing being charged for. Order-centric pricing has to pretend a cycle belongs to one order when it never did.
Traceability joins up without anyone maintaining it. Lot to load to cycle actuals to certificate exists because each link is a real relationship, not a note somebody remembered to write. That is the chain an auditor walks, and it is why the load has to be first-class rather than a field on the order.
None of this is a feature you switch on. It is which noun the software treats as real — the order, or the load. We built the load as the unit of work; the picture above is the data model, not an illustration of it.