Why heat treat breaks a generic ERP

Ask a commercial heat-treat shop where the real schedule lives and you will often get an embarrassed answer: a whiteboard, a spreadsheet, or the memory of whoever builds the charges. The ERP is running. Somebody is paying for it. It just is not where the work is planned.

That is not a training problem or a discipline problem. It is a modelling problem, and it has one cause.

Generic ERPs model an order moving through operations

The standard shape is: an order arrives, it has lines, each line follows a routing, and each step occupies a resource for a while. It is a good model. It fits machining almost perfectly — a part goes to a mill, occupies it, and moves on. Utilisation, scheduling and costing all fall out of it neatly.

Heat treat does not work like that, because the furnace does not process orders. It processes charges.

A charge is assembled from whatever fits together: same recipe, same temperature, compatible fixturing, enough room. Which means one charge routinely carries parts from several different customers, on several different orders, at once. And in the other direction, one order line often passes through several charges — harden, then temper, frequently as a separate charge on a different furnace hours later.

So the relationship between order lines and furnace runs is many-to-many, in both directions, simultaneously. A model where an operation step occupies a resource cannot express that. It can express “this line is at heat treat”, which is not the same thing and is not enough.

What the workaround costs

Shops bridge the gap, and the bridge is always outside the system.

The whiteboard knows which parts are going in together. The ERP knows an order is “at heat treat”. When someone asks which parts were in the furnace with ours, only the whiteboard can answer, and only until it is wiped.

That is tolerable right up until it is not, and the moment it stops being tolerable is a quality event. A load comes out wrong. Now you need to know exactly what else was in it — and the record of that is a photograph somebody took of a whiteboard, or nothing.

The same gap shows up at audit, from the other direction. An auditor picks a job and asks which charge it ran in, what else was in that charge, and what the pyrometry looked like at the time. If charges are not first-class records, that chain has to be reassembled by hand.

What first-class means

Not a field on the order. A record in its own right, with its own identity, its own furnace, its own cycle, its own actuals — and its own list of the order lines that went into it.

Once the charge is a real object, several things stop being hard:

Capacity is checkable. A charge has a weight, a piece count, a fixture set and a work-zone volume. Whether the next line fits is arithmetic, not judgement.

Compliance has somewhere to attach. The question “can this furnace run this cycle at this temperature today” is asked about a charge, at the moment it is built, before the parts go in.

Evidence has somewhere to freeze. The recipe as resolved and the pyrometry in force get copied onto the charge and held there. Re-calibrate the furnace next week and last week’s charge still tells the truth about last week — because it is a copy, not a reference.

Traceability joins up on its own. Nobody maintains the chain. Lot to charge to cycle actuals to test result to certificate exists because each link is a real relationship rather than a note.

The temper problem, specifically

Worth calling out, because it is where “just add a heat-treat step” collapses.

Harden and temper are frequently separate charges. Different furnace, different temperature, hours apart, sometimes a different shift. Both are part of one order line’s history, and both need their own pyrometry evidence, their own actuals, their own sign-offs.

Model heat treat as a single operation step and one of those two runs is invisible. Model the charge as first-class and it is simply two charges linked to the same line — which is what physically happened.

What to ask, if you are evaluating

One question, and it separates the field immediately:

Show me a single furnace run containing parts from three different customers, and then show me one order line that went through two runs.

If the demo can do both without a workaround, the model is right and everything downstream — capacity, traceability, certification — has a foundation. If it needs a note field, a custom object, or “you would handle that in the scheduling module”, the whiteboard survives, and so does every problem attached to it.

We built the load as the unit of work for exactly this reason. It is not a feature. It is the shape of the thing.