ISO 22400 KPIs — and where MTBF and MTTR sit

Short answer: yes, both

ISO 22400-2 defines 34 key performance indicators for manufacturing operations, and mean time between failures (MTBF), mean time to repair (MTTR) and mean time to failure (MTTF) are among them. So is OEE, along with availability, quality and throughput. If head office has asked whether MTBF is "an ISO KPI", it is — and the definitions sit in Part 2 of the standard.

That is the whole answer. The rest of this page is the part that decides whether your MTBF number survives its first meeting.

What the 34 actually cover

The standard groups its indicators around the things a plant argues about every month:

• Time and utilisation — availability, and how much of the time you paid for actually turned into running hours.
• Effectiveness — OEE and its relatives, availability multiplied by performance multiplied by quality.
• Quality — good output against total output, scrap and rework.
• Reliability and maintenance — MTBF, MTTR and MTTF: how long a machine runs before it stops, and how long you take to get it back.

Two things are worth knowing before you quote it in a review. ISO 22400 comes in parts: Part 1 sets out the framework and vocabulary, Part 2 carries the definitions and formulas people actually cite. And the standard is sold, not published — you buy it from ISO or your national body. Anyone offering you "the full ISO 22400 list" for free is quoting somebody else's summary, including this one.

The part nobody tells you

The standard defines the formula. It does not hand you the data, and on an Indian shop floor the data is the entire problem.

MTTR is repair time divided by number of failures. Straightforward — until you ask when the repair started. If the fitter stamps "complete" at the end of the shift for three jobs he finished at eleven, two and four, your MTTR is fiction and it is flattering fiction, which is worse. A breakdown logged in a register on the supervisor's table and typed in on Saturday gives you the same problem a week later.

MTBF needs the opposite discipline: every failure counted, including the five-minute ones nobody raises a job card for. Miss those and MTBF climbs beautifully while the line keeps stopping. Any maintenance head who has presented a rising MTBF to a plant head who watched the machine stop twice that morning knows exactly how that meeting goes.

This is not an argument for better software. It is an argument for capture at the moment it happens, on the floor, by the person who did the work.

What a plant here actually runs into

Most Indian plants we see have some version of the same four problems, and none of them are in the standard:

• Mixed vintages. A 1998 lathe next to a 2023 machining centre. The old one has no controller to ask, so its downtime exists only if somebody records it.
• Contract labour on the night shift. Different hands every few months, so any process that depends on remembering a convention will decay. Whatever you build has to survive a new person on his first night.
• Three shifts, one register. A breakdown that starts at 5:50 and is fixed at 6:40 belongs to two shifts. If your capture makes the second shift own it, first shift's numbers look better than they are.
• A rupee figure nobody agrees on. Downtime cost per hour is a rate somebody sets. Set it once, copy it across dissimilar machines, and the Pareto chart ranks the wrong equipment with great confidence.

Doing it honestly, in the order that works

You do not need all 34. Almost nobody uses all 34.

1. Start with four numbers and a month of real capture — downtime hours, downtime cost, MTTR and PM compliance. All four fall out of work orders your technicians already close, so there is nothing extra to maintain.
2. Fix the stamping habit before you trust the trend. One month of start-and-complete stamped on the floor is worth a year of Saturday data entry.
3. Add production logs only where output matters — the bottleneck line, the machine with the highest cost per hour. OEE coverage grows from there; a worst-first ranking is useful long before it is complete.
4. Set the downtime rate per machine, deliberately. Contribution lost per hour on that line, not a number copied from the machine next to it. This is the figure that turns a maintenance argument into a money argument, which is the only form of it finance acts on.

Then, when someone asks whether you follow ISO 22400, the honest answer is a good one: these are the standard's definitions, computed from records we can show you, over a window we can state.

What this page is not claiming

AssetAI computes the subset above — availability, MTTR, MTBF, PM compliance and OEE — from work orders, meter readings and production logs. It does not implement all 34 indicators and it does not claim conformance to the standard.

There is no certification scheme for ISO 22400 software, from us or anyone else, and any vendor implying otherwise is selling you something that does not exist. If you are heading into a TPM or customer audit, treat these numbers as your internal evidence, not as a certificate.

New to this? Start with what a CMMS is and OEE explained. Ready to see it on your own machines rather than our slides? Book a demo.

Four habits that quietly break every KPI

When a plant stops trusting its own numbers, the cause is almost never the arithmetic.

• Batch-closing work orders. Stamping a shift's jobs at the end of it makes MTTR meaningless. Close on the floor, at the machine.
• Skipping the small stops. A ten-minute jam that never becomes a job card does not exist in MTBF. Enough of them and the metric says the line is healthy while the line is stopping.
• One downtime rate everywhere. A rate copied across dissimilar machines produces a confident ranking of the wrong equipment.
• Reading PM compliance as health. A plant can hit every scheduled PM and still break down constantly if nobody is closing the loop on why. It is one number out of four for that reason.

None of these need new tooling. They need the habits already in place — start and complete stamped live, failure mode and cause recorded at closure — to be followed on the night shift as well as the day one.

Rolling it out without slowing maintenance down

Give it a quarter, in this order:

• Weeks 1 to 4 — capture only. Work orders closed in real time on the shop floor. No dashboards in review meetings yet; the first month is always skewed.
• Weeks 5 to 8 — bring the four tiles into the daily shift meeting. Not the monthly review, the daily one. That is where a wrong number gets corrected by someone who was there.
• Weeks 9 to 12 — production logs on the bottleneck assets, then OEE. Take the longer analytics window to the leadership review, where a 90-day trend beats a 30-day snapshot.

That sequence exists because KPI projects fail in one specific way: dashboards shown to management before the floor trusts the capture. Once a plant head has been given a number that turned out to be wrong, getting a second hearing takes a year.

Want to see how the same records feed the rest of the work? The use cases page covers it, or book a demo and we will run it against a sample plant.