Can I keep my TPM-style OEE while adopting ISO 22400 terminology?

You can usually keep your TPM-style OEE while adopting ISO 22400 terminology, but only if you treat them as two distinct KPI definitions and manage the mapping transparently. You cannot call an unchanged TPM-style metric “OEE per ISO 22400” unless it actually follows the ISO 22400 definitions.

What you can safely do

In most regulated, brownfield environments, a practical approach is:

• Keep TPM OEE as a legacy or shop-floor KPI where it works well for day-to-day improvement.
• Introduce ISO 22400 KPIs (e.g., OEE, OOE, TEEP, availability, performance, quality rate) in parallel, with clear formulas and data sources.
• Document a mapping that explains how TPM OEE relates to ISO 22400 metrics, where it differs, and where it should or should not be used.
• Constrain use cases: for example, allow TPM OEE for line-level Kaizen, but use ISO 22400 definitions for cross-site comparison, management reporting, or external communication.

Key differences you must manage

The feasibility depends on how far your current TPM OEE deviates from ISO 22400. Common gaps include:

• Loss categories: TPM OEE often mixes planned/unplanned losses differently from ISO 22400 (which is stricter about what goes into availability, performance, and quality).
• Ideal cycle time: TPM implementations may define it by target rate, marketing rate, or historical best. ISO 22400 expects a clearly defined, validated reference.
• Planned shutdowns and changeovers: Some TPM practices exclude part or all of these from OEE. ISO 22400 allows related KPIs (like OOE) instead of “quietly” excluding time.
• Scrap and rework handling: Quality rate and definition of “good units” must be consistent with your quality system, not just the OEE spreadsheet.

If you retain TPM OEE, these differences need to be spelled out, not assumed.

Governance and documentation expectations

In regulated, long-lifecycle environments, coexistence is mostly a governance problem, not a math problem. To avoid confusion and audit friction:

• Define both metrics formally: Maintain controlled documents that specify the exact formula, time base, inclusions/exclusions, and intended use for TPM OEE and ISO 22400 OEE.
• Use unambiguous names: For example, “TPM OEE (legacy)” vs “OEE (ISO 22400)” rather than both just called “OEE” in MES/BI dashboards.
• Implement change control: Any shift from TPM OEE to ISO 22400 in a system of record, or in a critical KPI, should go through formal change control and, where applicable, validation/qualification.
• Explain in procedures and training: Supervisors, engineers, and planners should be trained on which OEE is used where and why, especially if incentives or capacity decisions depend on it.

System and integration implications

In brownfield stacks, you should assume some systems are “hard-wired” to a specific OEE definition:

• MES/SCADA: Often configured with a particular OEE logic. Changing this to ISO 22400 can require significant reconfiguration, testing, and potential revalidation. In many plants it is safer to add new ISO 22400 metrics than to replace the existing OEE calculation.
• ERP/APS: Capacity and cost models may implicitly assume your TPM OEE values. Introducing ISO 22400 OEE without re-aligning planning parameters can distort utilization assumptions.
• BI tools and data warehouses: You may need separate fields (e.g., oee_tpm and oee_iso22400) with clear metadata, rather than overloading a single “OEE” column.

Full replacement of TPM OEE logic inside legacy MES/SCADA is often disruptive because of validation burden, regression risk, and limited downtime. Coexistence via new calculated fields or a data layer is usually lower risk.

How to avoid misuse and confusion

The main risk of keeping TPM OEE is not technical; it is misinterpretation:

• Do not mix series in one chart without clear labels. TPM and ISO 22400 OEE on the same trend line create false improvement or deterioration signals.
• Do not change definitions silently: If you switch a site, cell, or product line from TPM OEE to ISO 22400 OEE, treat it like a method change and mark the historical breakpoint.
• Clarify what goes into targets: If performance bonuses or corporate KPIs use OEE, lock down which definition is used and avoid changing it mid-cycle.

When you should not keep TPM OEE

There are cases where maintaining TPM OEE in parallel is more harmful than helpful:

• If TPM OEE is heavily customized by team, line, or product such that there is no single, coherent definition.
• If you are planning cross-site or cross-product benchmarking where ISO 22400 consistency is a requirement from corporate leadership or customers.
• If TPM OEE is already poorly trusted and you are using ISO 22400 adoption as a credibility reset.

In those cases, a carefully planned migration to ISO 22400, with clear cutover dates and preserved raw data, is often better than long-term coexistence.

Pragmatic migration pattern

A common, lower-risk pattern in regulated, mixed-vendor environments is:

1. Baseline: Document your current TPM OEE calculation and its data sources line by line.
2. Design ISO 22400 KPIs: Define OEE and related KPIs strictly per ISO 22400, based on the data you can reliably collect.
3. Run in parallel: Calculate both TPM OEE and ISO 22400 OEE from the same underlying events for a defined period and compare behavior.
4. Decide roles: Decide where TPM OEE remains (if at all) and where ISO 22400 becomes the single source of truth.
5. Harden and validate: Apply change control, update procedures, train users, and, if needed, perform formal validation/qualification of new KPI logic in MES/BI systems.

This approach allows you to keep TPM-style OEE where it is still useful, while gradually aligning strategic and cross-plant metrics to ISO 22400 without a high-risk, big-bang replacement.