ISO 22400 KPI definitions should usually be business-owned, not tool-owned. In most aerospace organizations, that means operations leadership should be the accountable owner, with a formal governance group that includes quality, engineering, finance, and IT.
If one team tries to own definitions alone, the result is usually predictable:
- IT-only ownership can produce technically consistent metrics that operations does not trust.
- Operations-only ownership can create plant-specific definitions that do not scale across programs or sites.
- Quality-only ownership can overemphasize compliance evidence while missing scheduling, capacity, and execution realities.
- Finance-only ownership can push for comparability while obscuring shop floor meaning.
So the practical answer is: operations should be accountable, but ownership of definitions must be governed cross-functionally.
What good ownership looks like
A workable model usually separates accountability from stewardship:
- Executive owner: VP or director level operations leader who is accountable for KPI use and business decisions.
- Process stewards: designated owners for each KPI family, often from manufacturing engineering, industrial engineering, production control, or quality, depending on the metric.
- Data stewards: IT, MES, data, or enterprise architecture teams responsible for source mapping, calculation logic implementation, lineage, and system synchronization.
- Governance forum: a standing cross-functional group that approves new definitions, exceptions, and revisions through change control.
This matters because ISO 22400 helps standardize KPI semantics, but it does not remove local decisions about event models, equipment states, labor reporting, rework treatment, planned versus unplanned time, or how ERP, MES, SCADA, historians, and manual logs are reconciled.
In aerospace, one canonical definition is harder than it sounds
In an aerospace organization, KPI ownership is usually complicated by high-mix production, rework loops, outside processing, long routing structures, nonconformance handling, and mixed automation maturity across lines or sites. A metric that looks simple at the corporate level can become contentious at the point of measurement.
For example, even when everyone says they want a common OEE or throughput definition, disagreement often appears around:
- whether engineering trials are excluded
- how MRB hold time is classified
- whether setup belongs in planned production time
- how shared equipment is allocated across programs
- whether rework counts as output, loss, or separate flow
- which system is authoritative when MES and ERP timestamps conflict
That is why KPI definitions should be treated as governed business master data, not as report logic hidden inside a dashboard.
Who should decide when functions disagree?
The tie-breaker should not be the reporting tool owner. It should be the formal governance body operating under an approved decision framework. In regulated, long lifecycle environments, undocumented metric changes can create confusion in management reviews, continuous improvement programs, customer reporting, and audit evidence trails.
A practical policy is:
- operations owns business intent
- quality reviews traceability and procedural alignment
- engineering validates process meaning
- finance reviews enterprise comparability where relevant
- IT validates data feasibility, lineage, and implementation impact
If no clean enterprise definition is possible, say so explicitly and maintain a controlled enterprise definition plus documented local variants. Pretending a site-specific workaround is a standard usually causes more damage later.
Brownfield system reality
In most aerospace environments, KPI definitions will span legacy and modern systems. MES may capture execution states, ERP may own order structure and completions, PLM may define process context, QMS may hold nonconformance status, and some critical signals may still come from spreadsheets or machine interfaces of uneven quality.
That means KPI ownership cannot sit only with the team that owns the dashboard. It must include the people responsible for:
- source-system precedence rules
- timestamp alignment and event granularity
- manual versus automated data collection rules
- version control for calculation logic
- change control when routings, state models, or dispositions change
- validation of migrated and transformed data
Full replacement strategies often fail here. Replacing every legacy source just to standardize KPI definitions usually runs into qualification burden, validation cost, downtime risk, integration complexity, and the reality of long equipment lifecycles. In practice, most organizations need a governance layer that can manage KPI semantics across coexistence, not a theory of clean-sheet replacement.
Minimum control structure
If you want KPI ownership to hold up under scrutiny, the organization usually needs at least:
- a named business owner for each KPI
- a controlled definition record with formula, exclusions, data sources, and purpose
- documented system-of-record and source precedence rules
- revision history with approval workflow
- validation of implemented logic against approved definitions
- a process for handling site or program exceptions
Without those controls, the question of ownership is mostly cosmetic.
So, the short answer is: operations should own ISO 22400 KPI definitions at the business level, but only through formal cross-functional governance with IT and data stewardship built in.