Shot blasting degrades continuously and invisibly. Blades, liners and impellers wear from the moment they are fitted, and the machine compensates by taking longer and using more abrasive to reach the same finish. Nothing breaks, nothing alarms, and the cost climbs on a curve nobody is plotting.
Your ERP logs the pieces blasted and the abrasive purchased.
It won’t tell you the wheel has been drawing differently for a fortnight, or that blast time crept up to hide it.
Why the gap existsWhere the losses hide
Wear has no alarm. It shows first as a reading, then as consumption, and only at the end as a breakdown.
Worn blades throw less efficiently, so the same finish takes more media. Abrasive per tonne is the honest measure and it rises long before anyone opens the cabinet.
Operators add time to reach the finish they know is right. It is the correct thing to do and it silently converts a wear problem into a throughput problem.
A blast wheel’s motor current changes as the blades go. It is a reading weeks before it is a stoppage, and it is the earliest honest signal of the wear state.
The join
Same run, same clock, same asset — three streams that only mean something together.
Pieces blasted, abrasive purchased and issued, and the maintenance job when something is finally changed.
Blast wheel motor current and machine cycle time sampled continuously, abrasive consumption tied to the machine, and the operator’s log when a wheel is opened.
Abrasive per tonne and cycle time read against the wheel’s own current, so wear is visible as a trend rather than discovered as a failure.
What Munshi surfaces
Teal is normal, maroon is flagged. Illustrative data.
The shaded stretch is the wheel working harder for the same job. Values sit inside the range observed on real blast machines.
A trend, not a spike. This is what wear looks like on the cost side.
Operators compensating for a machine that is no longer throwing as it did.
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
Rework hours and consumable burn per casting.
Energy per batch, cycle deviation and re-treat loops.
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.