It records what happened — tonnes, kWh, rejects, downtime. It was never built to tell you why. Munshi connects the numbers you already have to the reasons behind them.
Record versus cause
It logs the heat, the weld, the batch, the reject — faithfully, after the fact. What it can’t hold is the cause: the crane that made the furnace wait, the night shift where the arc ran cold, the coating that failed twice before it passed.
That gap isn’t a reporting problem. It’s where the losses live — unattributed, un-costed, and free to recur. Munshi is the system of cause that sits beside your record and names them.
Every heat on record, on budget. Nothing flagged. Illustrative data.
Same heats. Two sit above the line — one a crane wait, one a re-charge after chemistry. Illustrative data.
Three moments
Heat 7 tapped 1.2 tonnes and booked its energy like every other heat of the shift. In the monthly total, it looks ordinary.
It held 38 minutes before tap, waiting on the crane — drawing power to stay at temperature, not to melt metal.
That this heat ran about 690 kWh a tonne against a 550 typical, with the 38-minute hold tagged as the cause — roughly 170 kWh, about ₹1,400, on one heat. A few heats a week like it is around ₹20,000 a month the total never explains.
The shift poured its heats and booked the castings that came out.
Two ladles stood waiting while the crane was committed elsewhere, and the pours that followed went in below temperature.
The pouring temperature that fell on those pours, the wait tagged as the cause, and the misruns found at knockout that trace back to them — nine castings sent back to remelt, their metal, moulding and labour all spent twice.
The batch went through the furnace and booked one cycle, like the batch before it.
It ran below the specified soak for part of the cycle, failed hardness, and went back for a second full run.
The dip under setpoint, the re-treat logged against the batch, and what the second run cost — around 210 kWh, about ₹1,800, for one batch that should have taken a single cycle.
Every figure Munshi surfaces carries the loss in the terms you can act on — the output you didn’t ship, and the rupees wherever the energy behind it is metered. Once a cause is confirmed on the floor, it’s written back to that asset’s own record, so the next recurrence is already named.
The join
Every cause Munshi surfaces comes from joining three streams on the same asset, at the same moment — what the operator logged, what the machine reported, what the IoT panel read on the line. Time-aligned, per asset. Munshi surfaces what moved together; your team confirms the cause — it never declares one on its own. Confirmed, that cause is written back to the asset’s record.
Stops, rejects and delays, entered on the floor as they happen.
Current, load, energy and cycle, read continuously from the asset itself.
The live reading on the line, sampled while the run is still going.
The shaded window is the only thing the join adds: the operator’s entry, the drop in furnace power and the energy still accruing all fall inside it. Read separately, each of the three is unremarkable. Illustrative data.
Munshi shows that 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.
Beside it, not instead of it
It works with SAP — or whatever you run — reads the same events, and adds the one thing the ERP was never built to hold: the cause. Your team doesn’t switch systems or abandon a single workflow.
Your system of record stays your system of record.
Munshi becomes your system of cause.
Get started
See it on your own floor.
Give us one asset and a single shift of your data, and we’ll show you the causes your ERP is already sitting on.