Who should own master data governance in an aerospace organization?

Master data governance in an aerospace organization should be owned by the business, with IT as an enabling and control partner. Engineering, quality, operations, supply chain, finance, and program leadership all depend on the same part, process, supplier, routing, inspection, and configuration data. If IT owns it alone, the organization usually gets clean systems with disputed definitions. If one business function owns it alone, the organization usually gets local optimization and downstream traceability problems.

Practical ownership model

The most workable model is usually an executive data governance council with named business data owners for major domains. IT should own the technical platforms, integration patterns, access controls, workflow tooling, and data quality monitoring. The business should own definitions, approval rules, lifecycle states, and the operational consequences of changing data.

Common domain ownership often looks like this, although the exact split depends on the organization:

• Engineering: item masters, engineering BOMs, configuration rules, design authority, effectivity, and technical data relationships.
• Manufacturing engineering or operations: routings, work centers, operation sequences, manufacturing BOMs, standard times, tooling relationships, and shop-floor execution attributes.
• Quality: inspection plans, characteristics, sampling rules, nonconformance codes, quality holds, approval evidence, and record retention requirements.
• Supply chain: supplier master data, approved supplier links, purchasing attributes, lead times, units of measure, and sourcing constraints.
• Finance or controlling: costing attributes, inventory valuation fields, cost centers, and financial reporting structures.
• IT: ERP, MES, PLM, QMS, integration middleware, identity controls, audit logging, data replication, and master data workflow implementation.

Why single-function ownership usually fails

Aerospace master data is not just administrative data. It drives build authorization, inspection requirements, material traceability, configuration control, supplier eligibility, cost collection, and customer reporting. A part number or routing change can affect MES execution, ERP planning, PLM configuration, QMS records, and maintenance history.

Because of that, ownership has to follow the process impact, not the system where the field happens to reside. ERP may hold the item master, but engineering may define the configuration meaning. MES may execute the routing, but manufacturing engineering may own the process sequence. QMS may store inspection evidence, but quality may own the control plan logic.

Brownfield reality matters

Most aerospace organizations do not have one clean system of record. They have long-lived ERP, PLM, MES, QMS, supplier portals, spreadsheets, and site-specific databases that were implemented at different times for different programs. Full replacement is often unrealistic because of qualification burden, validation cost, downtime risk, integration complexity, traceability obligations, change control, and long equipment and program lifecycles.

Governance should therefore define which system is authoritative for each data object and attribute, how changes are approved, how data is synchronized, and what happens when systems disagree. Without that level of detail, “system of record” language becomes political rather than operational.

Minimum controls that should be explicit

Aerospace organizations should avoid informal master data ownership. At a minimum, governance should define:

• named data owners and stewards by domain;
• approval workflows for creation, revision, obsolescence, and emergency changes;
• data quality rules and exception handling;
• audit trails for who changed what, when, why, and under which approval;
• integration ownership between PLM, ERP, MES, QMS, and related systems;
• validation expectations for changes that affect regulated or qualified processes;
• escalation paths when program, site, customer, or regulatory requirements conflict.

What leadership should not delegate

Leadership should not treat master data governance as a cleanup project or an IT ticket queue. It is an operating model decision. Poor governance can create planning errors, incorrect work instructions, wrong inspection requirements, duplicate part records, uncontrolled alternates, supplier mismatches, and weak traceability. These issues may not surface until a build, audit, escape investigation, or customer review exposes them.

Good governance does not guarantee audit outcomes or compliance. It does, however, make ownership, approvals, data lineage, and change history more defensible when the organization needs to explain how critical data is controlled.