Suppliers and customers can consume ISO 22400-based reports, but it only works reliably when the metrics, data structures, and delivery mechanisms are clearly agreed, documented, and controlled. ISO 22400 standardizes KPI concepts, not the exact files, dashboards, or APIs used between companies.
1. Align on definitions before sharing anything
Before focusing on tools or formats, both sides need a shared understanding of what is behind each KPI:
- Which ISO 22400 KPIs are in scope (for example, OEE, availability, performance, quality rate, NPT categories).
- Exact calculation logic, start/stop rules, and time-bucket definitions (shift, day, week).
- Equipment and scope boundaries (cells, lines, value streams, specific part families).
- Data sources used (MES, SCADA, historian, manual entry) and known gaps or approximations.
Document these as part of a data contract or KPI specification and keep them under revision control. Without this, suppliers and customers will interpret the same label (for example “OEE”) differently and comparisons will be misleading.
2. Choose practical consumption formats
There is no single ISO 22400-compliant file format. In brownfield environments, consumption typically looks like one or more of the following, depending on integration maturity and risk tolerance:
- Static reports
- PDF exports of dashboards for regular supplier/customer review meetings.
- Locked Excel or CSV snapshots with clear column headers referencing ISO 22400 terms.
- Good when integration budgets are limited or change control is strict.
- Structured data feeds
- CSV, JSON, or XML files posted to an SFTP location or secure object storage.
- Each file follows an agreed schema: KPI identifier, time window, equipment/entity, value, units, and quality flags.
- Works well when partners can automate ingestion but want to avoid tight coupling to internal MES/ERP.
- APIs
- REST or GraphQL APIs that expose ISO 22400 KPI endpoints (for example
/kpi/oee, /kpi/availability-losses).
- Requires mature IT on both sides, stable authentication, rate limits, and versioning policies.
- Higher initial integration and validation costs, but better for near-real-time visibility.
- Shared portals or dashboards
- Supplier or customer portals with role-based access to KPI dashboards.
- ISO 22400 alignment is documented in the portal, but consumers interact visually rather than ingesting raw data.
- Limits direct data integration burdens but can create manual reporting work if data must be rekeyed downstream.
The choice depends heavily on security constraints, existing IT stacks, and how often the data needs to be refreshed.
3. Map KPIs from legacy systems to ISO 22400
Most plants do not store data natively as “ISO 22400 KPIs.” Instead, you build them from existing systems:
- MES provides production counts, states, and downtime codes.
- SCADA or historians provide machine state and sensor data.
- ERP provides order context, product hierarchy, and calendar definitions.
- QMS or inspection systems provide scrap, rework, and defect data.
To expose ISO 22400-based reports externally, you usually need a mapping layer:
- Define how each raw field maps to an ISO 22400 input (for example, which downtime codes count as “planned” vs “unplanned”).
- Implement transformation and aggregation logic in a data warehouse, KPI service, or reporting layer.
- Validate the mapping with sample periods before sharing with suppliers/customers.
In regulated environments, treat this mapping like any other critical calculation logic: documented, reviewed, and under change control.
4. Handle versions, validation, and change control
Consuming ISO 22400-based reports across organizational boundaries introduces traceability and validation requirements:
- Versioned KPI specifications
- Assign versions to KPI calculation specs and data schemas.
- Expose the version in every file, API response, or dashboard (for example
kpi_definition_version=2.1).
- Data quality and validation
- Run sanity checks and reconciliation against internal reports before publishing to external parties.
- Flag estimates, missing data, or partial coverage explicitly instead of silently interpolating.
- Document known caveats per dataset (for example “includes Lines 1–3 only” or “excludes manual test stations”).
- Change control
- Manage changes to KPI logic or source systems via formal change requests.
- Notify suppliers/customers ahead of breaking changes and run parallel reports where feasible during transition.
Without this, suppliers and customers will see step-changes in KPIs that are driven by definition changes, not actual performance.
5. Address security and IP protection
ISO 22400 does not address security or confidentiality directly. In aerospace and defense contexts, you also need to consider:
- What level of aggregation is acceptable so that detailed routing, cycle times, or product mix are not fully exposed.
- Whether ITAR, export controls, or contractual restrictions apply to any of the data.
- How authentication, authorization, and logging are handled for portals and APIs.
- Data retention and deletion policies for shared reports.
In many cases, it is safer to share aggregated KPIs (for example line-level weekly OEE and downtime categories) rather than raw event or part-level data.
6. Typical supplier/customer use cases
Once the above foundations are in place, suppliers and customers can consume ISO 22400-based reports to:
- Compare performance across shared programs or part families on a common KPI basis.
- Identify chronic capacity or availability constraints affecting on-time delivery.
- Measure impact of joint improvement projects using consistent definitions.
- Support S&OP and materials planning discussions with traceable performance data.
These uses are effective only if the KPI logic is stable and the shared data is trusted. Otherwise, debate shifts from problem-solving to arguing about whose numbers are “right.”
7. Why full system replacement is rarely needed for ISO 22400 reporting
Exposing ISO 22400-based reports to external parties does not require replacing MES, ERP, or historians with a single new platform. Full replacement strategies usually struggle in regulated, long-lifecycle environments because:
- Re-validating every interface and calculation is costly and time-consuming.
- Downtime for cutover is often unacceptable, especially on shared or bottleneck assets.
- Legacy machines and custom integrations are hard to replicate in a new stack without regressions.
- Audit trails and historical KPI comparability can be disrupted by abrupt system changes.
A more practical pattern is to leave existing systems in place, implement a KPI layer that calculates ISO 22400 metrics from their data, and expose that layer externally via the most appropriate consumption method (files, APIs, or portals).
8. Practical starting steps
For organizations early in ISO 22400 adoption, a realistic path to supplier/customer consumption is:
- Select a small set of high-value KPIs (for example OEE and a handful of loss categories) and define them per ISO 22400.
- Build a manual or semi-automated export from your current reporting stack, including versioned KPI documentation.
- Pilot consumption with one supplier or one customer on a static-format basis (PDF or CSV) to de-risk definitions and expectations.
- Once stable, consider automating data delivery or exposing APIs, but keep KPI definitions under formal change control.
This incremental approach respects brownfield constraints, avoids unnecessary platform replacement, and still lets suppliers and customers consume ISO 22400-based reports in a traceable and trustworthy way.
