A press reports how many, rarely at what cost to the tooling. Dies wear on a curve, and the underfills and laps that curve produces arrive at inspection two stages later, long after the die that made them has run another thousand hits. The downtime between runs is the other silent line — most of it never books, because the press was never technically down.
Your ERP logs the forgings made and the die fitted.
It won’t tell you the reject rate started climbing three hundred hits ago, or that half of last shift went to setup that was never recorded.
Why the gap existsWhere the losses hide
A worn die and a slow changeover both cost real output. Neither raises an alarm, and neither lands against the thing that caused it.
As a die wears, underfills, laps and flash defects rise on a curve. Counted as a monthly reject rate, the curve flattens into a number; read against the die’s own hit count, it tells you when to pull it.
Die changes, billet shortages and setup adjustments stop production without stopping the clock in a way the ERP sees. The shift comes up short with no reason attached.
A billet sticking, a misfeed, or a die filling wrong shows in the press load before it shows in a reject. The signal is there hits before the scrap is.
The join
Same run, same clock, same asset — three streams that only mean something together.
Forgings produced, die fitted, and the rejects booked at inspection later.
Press load per stroke and cycle time sampled continuously, the operator’s downtime and reject reasons tagged at the press, both tied to the die running.
Reject onset read against die life, and downtime read by cause — so a die is pulled on a trend and a changeover is charged to setup, not to the forging.
What Munshi surfaces
Teal is normal, maroon is flagged. Illustrative data.
Tagged at the press, so the hours land against the cause instead of the count.
Hits since the die was fitted, along the bottom. The climb is the die telling you when.
The shaded stretch is load running high for the same part — a feed or fill problem, hits before it is a reject.
When an outcome moves and a signal moves with it, Munshi shows both and says they moved together. It does not tell you one caused the other. The operator confirms the cause, and the confirmed cause is written back to that asset’s register — so the pattern is already named the next time it appears.
Related stages
Energy and scale lost while billets soak waiting on the press.
The stage that looks free, until you count the flash rework.
Get started
See this on your own line.
Bring a month you already understand. The useful test is whether Munshi finds what you already know — and then what you didn’t.