Yes, you can keep using your existing OEE formula when you adopt ISO 22400, but you should treat it as a documented variant, not as “ISO 22400 OEE.” In regulated and multi-site environments, the key is clear definition, mapping, and governance.
What ISO 22400 actually requires
ISO 22400 defines standardized KPIs, including Overall Equipment Effectiveness (OEE) and its components, so that:
- Different systems (MES, SCADA, historians, BI tools) can exchange and compare metrics reliably.
- Sites and business units can interpret OEE consistently.
- Vendors have a common reference when describing KPIs.
It does not forbid you from using additional or alternative OEE-style metrics. It does mean that whenever you claim “ISO 22400 OEE” you are expected to follow the standard’s structure and definitions.
Practical coexistence: ISO 22400 + your legacy OEE
In most brownfield plants, you end up with both:
- Standard metric: OEE as defined by ISO 22400 (e.g., using the standard definitions of Availability, Performance, and Quality).
- Local/legacy metric: Your historical OEE formula, tuned to plant practices, existing downtime codes, or commercial agreements.
This coexistence is workable if you:
- Name them distinctly: For example, “OEE (ISO 22400)” and “OEE (Plant A legacy).” Avoid using the same label for different formulas.
- Document the formulas: Show exact equations, included/excluded time buckets, treatment of minor stops, scrap, rework, and planned vs unplanned downtime.
- Define usage rules: For example, ISO OEE for corporate dashboards and cross-site comparison; legacy OEE for local productivity targets or contractual KPIs.
- Control them under change management: Treat KPI logic like any other validated configuration: versioned, reviewed, and approved.
Key caveats in regulated environments
Using your own OEE formula while referencing ISO 22400 introduces several risks if not managed explicitly:
- Traceability and auditability: Auditors and customers may ask how KPIs are calculated. You need clear documentation showing which reports use ISO 22400 definitions and which use local variants, with effective dates and system configurations.
- Validation and qualification: If OEE feeds into validated processes (e.g., capacity models that influence batch release, resource qualification, or maintenance intervals), any change in formula or interpretation may require revalidation or impact assessment.
- Conflicting decisions: Different formulas can yield different improvement priorities. Explicitly decide which metric drives which process (S&OP, capex, shift-level continuous improvement, vendor performance, etc.).
- Data integration complexity: If some systems output ISO 22400 OEE and others use the legacy definition, you can easily double count or miscompare unless your integration layer tags and transforms metrics correctly.
How to introduce ISO 22400 without breaking existing KPIs
To minimize disruption in brownfield environments with long-lived assets and legacy MES/ERP stacks:
- Baseline current practice: Capture your existing OEE formula, including how availability, performance, and quality are operationally defined and which data sources are used.
- Map to ISO 22400: Identify where your definitions align or differ from ISO 22400 (for example, how you classify changeover, preventive maintenance, and microstops).
- Decide on your reference metric: Choose whether ISO 22400 becomes the reference at enterprise level, while legacy OEE remains a local, supplemental metric.
- Implement dual reporting during transition: For a period, compute and show both metrics so stakeholders can understand differences and adjust targets.
- Update procedures and training: Revise SOPs, work instructions, and training material to reflect which OEE definition is used where.
- Govern changes under formal control: Manage formula and configuration changes with the same discipline as other system configuration in regulated environments.
Why full replacement of your legacy OEE often fails
Completely replacing a long-standing OEE formula with the ISO 22400 variant can be difficult, particularly in aerospace, pharma, and similar regulated sectors, because:
- Historical comparability: KPIs tied to bonuses, contracts, and long-term trend charts are based on legacy OEE; switching formulas breaks continuity or forces complex back-calculations.
- System and integration debt: Legacy OEE logic is often embedded in MES customizations, historian queries, spreadsheets, and reports. Replacing it touches many validated and business-critical components.
- Downtime and qualification risk: Changing KPI logic in core systems can trigger requalification, regression testing, and deployment risk. Plants often cannot afford the downtime to rework everything at once.
- Local optimization: Some local formulas are tuned to specific constraints (e.g., campaign production, high-mix low-volume, or shared resources). A strict ISO implementation may be less intuitive to local teams.
For these reasons, many organizations adopt ISO 22400 as the common reference layer for cross-site comparison and external communication, while maintaining legacy OEE formulas for local operations where justified and well documented.
Summary
- You can keep your own OEE formula after adopting ISO 22400.
- You should not label a non-standard formula as “ISO 22400 OEE.” Treat it as a documented variant.
- In regulated, brownfield environments, success depends on clear naming, explicit mapping, change control, and careful integration across systems.
