What did downtime cost — in rupees?

Getting a trustworthy ₹ number out of this dashboard is less about the software and more about the discipline around three or four fields on the asset master — and about knowing what the top-8 Pareto is telling you versus what it isn't. The mechanics are simple; the value comes from treating them as seriously as any other planning input.

Setting Up the Numbers So They Mean Something

Before the dashboard is useful, a handful of asset-record fields need to be right, and kept right:

• Downtime-cost-per-hour should reflect a realistic per-hour loss for that asset — lost production value, contribution margin, or whatever basis your plant uses — not a placeholder copied across every machine.
• Rated output is what turns downtime hours into a units-lost figure; if it's missing, that asset simply won't show units lost, which is safer than a guessed number.
• Production logs need to be entered for OEE to compute at all for an asset — a machine that never gets logged output will never appear in the OEE view, however much breakdown time it racks up.
• Review these fields on a cadence — a shift change, a line rebalance, or a cost revision are all reasons the old figure stops being true.

This is the same discipline covered in what is a CMMS: the software is only as good as the master data feeding it, and AssetAI is built to surface that gap rather than paper over it with defaults.

Common Ways the Pareto Gets Misread

A few habits quietly undermine the value of this dashboard even when the data is technically correct:

• Reading the top-8 Pareto as a full asset ranking. It isn't — it's the eight highest downtime-cost assets in the selected window. A machine ranked ninth may still be a real problem; it just isn't the most expensive one right now.
• Comparing windows without noting the change. A machine that looks stable at 90 days can look very different at 30 — a single long breakdown near the boundary date shifts things fast, since the window is fixed to 30/90/180/365 days rather than a custom range.
• Treating a skipped OEE asset as a zero. It's absent because there's no production log, not because performance was nil — worth flagging to whoever owns that shift's logging discipline.
• Chasing MTTR in isolation. A short MTTR on a frequently-failing asset can still cost more than a long MTTR on a rare one — the ₹ figure and the failure count both matter, which is why they sit on the same dashboard.

These are the same failure modes that make manual MIS tracking unreliable in the first place — the dashboard doesn't eliminate the need for judgment, it just gives that judgment better inputs.

Why This Matters Beyond the Shop Floor

Downtime cost and OEE aren't only shift-supervisor metrics — they're the numbers that justify capex requests, feed into TPM-style improvement programs, and increasingly show up in audits tied to ISO standards around maintenance and quality management. Having them recalculate from real work-order data rather than a weekly spreadsheet update makes that reporting defensible instead of approximate. If you're evaluating this alongside the rest of what AssetAI covers, the features overview and pricing pages are the next stops, or book a demo to see the dashboard against your own asset list.

Most plants track downtime cost and OEE in a spreadsheet that someone updates once a week — by which time the ₹ figure is stale and the "worst machine" has already changed. AssetAI replaces that MIS ritual with a rolling dashboard that recalculates itself every time a work order or production log is entered.

What Feeds the Numbers — and What Doesn't

The dashboard is only as trustworthy as the data behind it, and it's built to make that boundary explicit rather than hide it:

• Downtime-cost-per-hour and rated output are asset-record fields, entered once and reused in every calculation — get them wrong and the ₹ Pareto will be wrong, so they're worth reviewing quarterly, not set-and-forget.
• OEE is only computed where production logs exist. An asset with no logged output is skipped from the OEE view rather than shown as zero or estimated — a deliberate choice to avoid a misleading number standing in for missing data. See OEE explained and the standard reference on OEE for how the calculation is defined.
• There's no SCADA, PLC or IoT feed underneath this. Every figure traces back to a work order, a meter/production log, or a value on the asset master — entered by people on the floor, not sensors. That's a limitation to plan around if your plant runs unattended shifts with no one logging output.
• The failure Pareto isn't optional to populate — BM/CM work orders are structurally blocked from closing without a recorded failure cause and remedy, so the Pareto reflects what actually happened, not what got remembered at month-end.

Reading the Dashboard on the Shop Floor

The tile set (availability, MTTR, MTBF, PM compliance, backlog and backlog-over-14-days, cost, labour hours, downtime hours and cost, active assets, reorder-level spares, open breakdowns) is meant to be read in a standup, not compiled for one. A few practical notes:

• The window is fixed — 30/90/180/365 days from today, defaulting to 90. There's no custom date-range picker, which keeps every review comparing like-for-like periods instead of cherry-picked ranges.
• The downtime-cost Pareto ranks the top 8 assets, not the whole plant. It's designed to answer "where do we act this week," not to be an exhaustive asset-by-asset ledger.
• Per-asset OEE is sorted worst-first. The intent is that the biggest loss-maker is the first tile a shift supervisor sees, mirroring how TPM programs prioritize chronic loss over one-off breakdowns.
• There's no built-in threshold alerting — this is a pull dashboard you check, not a push notification that flags "MTTR crossed X." If your team needs that discipline, build it into a standing review cadence instead.

Where This Fits in Your Maintenance Stack

This feature sits alongside work-order management, PM scheduling and spares tracking rather than replacing your judgment about what to fix first — it just makes sure the judgment is based on real numbers. If you're evaluating how this fits your plant's setup, browse the full feature set, check industries for sector-specific notes, or look at use cases for how the same dashboard gets read differently across shifts and departments. For the broader case on why manufacturers in India are moving off spreadsheets, see the IBEF industry data or start with what is a CMMS if you're building the internal case. When you're ready to see it against your own asset list, book a demo.