Steel Mill Production Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the material model get underscoped so often?

Almost every quote we see for mill software describes production tracking: record what was made, when, on which line, against which order. That framing produces a batch and quantity model, which is what standard manufacturing software assumes, and it is wrong for steel in a way that cannot be patched later.

Steel is a divergent process with continuous re identification. One heat becomes several slabs, one slab becomes a coil, one coil becomes child coils and then cut lengths, and at every step the material can change grade, owner, destination and value. Standard software models convergence, where components come together into a part number and material is fungible against that number. In your mill nothing is fungible, because coil 44821 at commercial quality is a specific object with measured thickness, width, chemistry and mechanical results, and no other coil is a substitute for it except by test.

The consequence of getting this wrong is not a missing feature. It is that order to material matching, genealogy, certificate generation and yield costing all become impossible at once, because each of them reads the same graph. Teams discover this in month five, when the first downgrade arrives and the system has no way to represent that the piece changed identity without changing existence.

Insist on the material model in the first design session. Heat, cast sequence, slab, coil, child coil, cut length, each a node with parents, children and a recorded transformation event between them. Ask the supplier directly what happens to transition material from a mixed grade cast sequence, which inherits from two heats. If they have not thought about it, they will model it as belonging to one, and your certificates will be defensible right up until the first automotive audit.

What goes wrong when historic production data is migrated into the new model?

The migration in a steel build is not a table copy. It is a reconciliation exercise, and it is where projects lose their schedule.

The core problem is that the same physical coil carries different identifiers on three systems. The caster level 2 knows it as a slab number, the hot strip mill assigns its own coil number, the coating line assigns another, and the enterprise system knows a batch that maps to none of them cleanly. Joining them historically means matching on timestamps, weights and dimensions, and the matches are approximate. Anyone who tells you this is a scripted import has not done it.

Then there is the depth question. How many years do you actually need. Certificates you may need to reissue, recalls you may need to trace and yield baselines you want to compare against all pull in different directions, and every extra year multiplies the reconciliation work. Most mills we work with settle on a full graph for recent production plus a searchable archive of older certificate data, because reconstructing a five year old cast sequence to graph quality is rarely worth what it costs.

Two practical defences. First, run the reconciliation on a sample month before the project is priced, and count how many pieces fail to match automatically. That percentage is your migration budget in a single number. Second, make the historic data append only from the moment it lands. A genealogy record that can be silently edited afterwards is worth nothing in an audit, and a migration that allows quiet corrections has already destroyed the property you were buying.

Why do the level 2 and enterprise integrations break after launch?

The acquisition layer is where most of the effort in a steel project actually goes, and it is also where the system decays quietly once the delivery team leaves.

Each line breaks differently. A level 2 database from one equipment supplier gets patched during a maintenance window and a column changes meaning. An older line read through a historian starts buffering during a network fault and delivers three hours of readings at once with the original timestamps intact, which is correct behaviour that most naive pipelines mishandle. A line that was screen scraped because there was no other option breaks when the interface is updated. And the enterprise system integration, usually SAP, drifts because somebody adds a material type or changes a sales order structure without telling anyone outside finance.

The failures are silent, which is the real problem. A pipeline that stops receiving from the galvanising line does not raise an error, it simply reports nothing, and the plant wide yield number quietly excludes a line for a fortnight.

Design for it. Every source gets an expected reporting interval and an alarm on silence, not only on error. Every parser validates a schema contract on each read so an unexpected field raises a specific exception rather than parsing to null. Identifier reconciliation gets its own exception queue that somebody reviews daily, because pieces that fail to join are the ones that will be missing from a certificate later. And the boundary with the enterprise system is written down: decide which side owns each number, because ambiguity there is what generates reconciliation work for years.

What happens when certificate and traceability duties are not covered?

Customers ask for mill test certificates under EN 10204, and for a 3.1 certificate the actual chemistry and mechanical test results have to tie to the specific piece they received. Automotive and pressure equipment customers audit that chain, and they audit it by asking you to produce it in the room.

Where builds fall short is not the certificate template. It is the propagation rules and the audit trail behind them. A child coil inherits chemistry from its parent, which is easy. Transition material from a mixed grade cast sequence inherits from two heats, which is not, and a system that assumes rather than flags it has produced a certificate that is not defensible. Test results need to attach to the piece they were taken from, with the propagation to descendants visible rather than implied, so an auditor asking why this coil carries that tensile result gets an answer from the record instead of from an engineer's memory.

The second gap is edit history. If a piece history can be changed without an audit trail, your certificate is a claim rather than evidence. Make the genealogy an append only event log, with corrections recorded as new events that supersede rather than overwrite. That single design decision is the difference between a comfortable audit and an expensive one, and it costs almost nothing if it is chosen at the start.

Should you build custom or configure what you already own?

There is a real case for not building. A single line re roller working largely to stock with a limited grade range can run on an enterprise system with proper lot tracking and disciplined spreadsheets for years, and the money is better spent on the line itself. Complexity, not tonnage, is the threshold.

If you are a large integrated producer with the budget and the tolerance for a multi year programme, evaluate PSI Metals properly before commissioning anything. It genuinely does continuous order to material matching, it is built by people who know steel, and if your practices sit close enough to its model that configuration reaches them, you will get there faster than any build. Equally, if you already run a manufacturing system such as Plex across the plant, extending it may beat a second system on total cost simply because the shop floor data is already there.

The build case is narrower and more specific than most suppliers admit. It appears when your lines come from several different equipment suppliers and nothing joins them, because the joins between lines are your actual gap and they are far cheaper to build than a full metals suite. It appears when your practice rules for cast sequencing and rolling campaigns live in the heads of two schedulers approaching retirement. And it appears when licence and implementation cost is simply out of proportion to a mill of your size. Before you decide, ask a packaged vendor to demonstrate a downgrade and re application on your data, not theirs. That one scenario separates the products that fit from the ones that will be configured around forever.

How do hidden costs get into the quote?

Five items sit outside most steel quotes and inside most steel projects. Identifier reconciliation, discussed above, which is slow manual discovery work and is often priced as if it were a mapping table. The number of distinct level 2 suppliers represented in the plant, since each acquisition integration is separate work and a quote scoped on two lines will not survive the third.

Third, certificate formats. Automotive and pressure equipment customers often want their own layout, and several want submission into their own portal, which turns certificate generation into an integration. Fourth, scheduling depth. A viewing and sequencing tool costs a fraction of a genuine campaign optimiser, and the two get discussed with the same word. Ask which one is being quoted. Fifth, the bidirectional enterprise link, because orders in and production confirmations out is careful work with real consequences if a quantity is posted twice.

The defence is a written exclusion list attached to a fixed first release. Name the lines in scope, the certificate formats in scope, and whether scheduling means viewing or optimising. Then price the rest when the piece model exists and the unknowns have shrunk.

What separates a build that works from one that fails here?

The mills where this works start downstream. Order to material matching and genealogy from the hot mill onward deliver value in the first quarter, because reduced secondary inventory and fewer late orders show up quickly, and the caster scheduling work becomes far easier once the piece model already exists. The mills where it fails start at the caster, because it feels like the beginning of the process, and spend a year building scheduling on top of a material model that has not been proven by real production.

The second differentiator is who is in the room. A build that involves the order desk and two schedulers weekly produces practice rules encoded as data that schedulers can change without a release. A build specified by a steering committee produces rules embedded in code, and the first time a practice changes you are raising a change request.

The third is ownership. You should hold the repository, the infrastructure accounts and the unrestricted right to hire another firm, agreed before kickoff. A system that will run your mill for a decade and hold the evidence behind every certificate you issue should never depend on a licence renewal or a supplier relationship you cannot exit.