ISO 22400 — Manufacturing KPIs

What ISO 22400 covers

ISO 22400 (see the ISO standards library) defines a broad catalogue of manufacturing KPIs — availability, performance, quality, allocation ratio, utilization effectiveness, and more. AssetAI does not implement that full catalogue or claim conformance to the standard itself; it computes the subset most plant teams actually track day to day — availability, MTTR, MTBF, PM compliance, and OEE — as a byproduct of the work orders your technicians already close.

Where the numbers actually come from

Every KPI on this page traces back to a work order or a production log, not a manual spreadsheet entry. That matters because a KPI is only as trustworthy as its source record:

• MTTR and MTBF are computed from Start/Complete timestamps that technicians stamp on breakdown and corrective work orders — if clock actions are late or skipped, the numbers drift.
• Failure counts and downtime hours are attached to work orders that enforce failure mode, cause, and remedy at closure, so they're gated to real records rather than free-text notes.
• OEE is calculated per asset from production logs (availability × performance × quality) and ranked worst-first — assets without a production log are skipped entirely, so plant-wide OEE coverage depends on how many assets are logged.
• Downtime cost is derived from a configured rupee-per-hour rate on the asset record, multiplied by logged downtime hours, then ranked as a top-8 Pareto — it's a configured rate, not a cost-accounting derivation.

None of this depends on sensor or PLC-level telemetry; the inputs are the work-order, meter-reading, and production-log data your team enters or syncs into the system, which keeps the KPI layer usable in plants that haven't invested in shop-floor connectivity yet.

Dashboard tiles vs. the Analytics module

AssetAI splits KPI reporting into two layers, and it helps to know which one you're looking at:

• The company dashboard always shows four fixed 30-day tiles — downtime cost, downtime hours, MTTR, and PM compliance — colour-toned for a quick scan. PM compliance turns green at 90% or above.
• The Analytics module is where the fuller KPI set lives, with a rolling window you can switch between 30, 90, 180, and 365 days (90 by default), plus the full OEE ranking across assets.

This separation means a plant manager checking the dashboard before a shift meeting sees the same four numbers every time, while someone building a monthly leadership review pulls the longer window and asset-level OEE ranking from Analytics.

What this is — and isn't — good for

These KPIs are built for internal reporting and operational visibility, not for audit or certification evidence. There is no third-party certification scheme for ISO 22400 software conformance, and AssetAI does not claim or imply one. If your plant is pursuing a formal TPM or quality-framework audit, treat these numbers as a practical starting point for internal discussion, not a substitute for that process.

Teams that get the most out of this are typically already using AssetAI for breakdown and work-order capture and want the KPI layer as a natural extension of that data — not plants shopping for a standalone KPI-reporting tool. If you're evaluating AssetAI from scratch, the CMMS basics and OEE explained pages are a good starting point, and the full feature list and industry pages cover how this fits alongside work-order and PM scheduling. For sector context on where Indian manufacturing is headed, IBEF's industry data is a useful external reference. When you're ready to see it against your own plant's data, book a demo.

What ISO 22400 help.

Getting reliable KPIs out of any system is less about the formulas and more about the discipline behind the data entry — this section covers what plant teams should get right before they lean on these numbers for a leadership review.

Common mistakes that quietly break the numbers

Most KPI distrust comes from a handful of avoidable habits, not from the calculation logic itself:

• Backdating clock actions. If a technician stamps "Complete" hours after the actual fix, MTTR looks worse (or artificially better) than reality. The fix is procedural — close work orders in real time, not at shift-end in a batch.
• Skipping production logs. Since OEE is only computed for assets with a production log, plants that log output inconsistently end up with partial OEE coverage and a Pareto ranking that's missing entries, not zero-rated ones.
• Treating downtime cost as a P&L figure. The downtime cost per hour on an asset record is a configured rate you set, not a cost-accounting output — if it's left at a default or copied across dissimilar assets, the rupee ranking will mislead rather than inform.
• Assuming PM compliance alone means the plant is healthy. It's one tile out of four for a reason; a plant can hit its PM schedule and still carry a high breakdown count if failure modes aren't being addressed at root cause.

None of this requires new tooling — it requires making sure the work-order habits already in place (start/complete stamps, failure mode/cause/remedy at closure) are followed consistently, since what a CMMS actually reports is downstream of what gets recorded in it.

Rolling out KPI tracking without disrupting maintenance work

For Indian manufacturing plants — many running mixed vintages of equipment, contract labour, and multiple shifts, as is typical across the industry tracked by IBEF — the practical rollout sequence matters more than picking a KPI list on day one:

• Start with the four dashboard tiles (downtime cost, downtime hours, MTTR, PM compliance) since they're always-on and need no separate configuration — they're a byproduct of work orders you're likely already closing.
• Move to the Analytics module once a few weeks of consistent work-order closure exist, so the 30/90/180/365-day windows have enough real data to be meaningful rather than skewed by a partial first month.
• Prioritise production logs for the assets that matter most to output — bottleneck lines, high-cost-per-hour equipment — rather than trying to log everything at once; OEE coverage builds incrementally, and worst-first ranking still surfaces the assets worth acting on first.
• Treat this as one layer of a broader reliability practice — KPI tracking pairs naturally with the planned-maintenance and root-cause habits associated with total productive maintenance, even though AssetAI doesn't implement TPM as a formal program.

None of this requires a parallel reporting tool — it's the same AssetAI work-order and production-log data, viewed at a different cadence. If you're evaluating whether this fits your plant's current maintenance setup, the use cases page walks through how other functions plug into the same records, or you can book a demo to see the KPI views against a sample dataset.