Can each plant have its own taxonomy if there is a corporate taxonomy?

Yes, but not as an independent replacement for the corporate taxonomy.

In most regulated, multi-plant environments, the practical model is a governed corporate core with plant-level extensions. That means corporate defines the shared terms, identifiers, and relationships needed for enterprise reporting, traceability, data exchange, and control. Each plant can then add local detail where the corporate model is too generic to reflect real equipment, processes, product mix, or legacy system constraints.

If each plant creates its own full taxonomy without governance, the usual result is not flexibility. It is conflicting master data, brittle integrations, unreliable rollups, and disputes over what metrics or records actually mean. In brownfield environments with mixed MES, ERP, PLM, QMS, historians, and spreadsheets, that problem compounds quickly because every interface has to compensate for semantic differences.

What usually works

• Corporate owns the canonical layer. This covers enterprise-critical objects and terms used across plants, such as product structures, quality states, event types, reason codes, traceability attributes, and reporting definitions.

• Plants can add local extensions. These may include local work centers, equipment groupings, process variants, routing distinctions, operator-facing labels, or site-specific reason codes, provided they map back to the corporate model.

• Mappings are explicit and maintained. Local terms should not remain informal aliases. They need controlled mappings to corporate definitions, with ownership, versioning, and change control.

• Exceptions are intentional. If a plant truly cannot conform because of qualified processes, validated workflows, or legacy platform limits, that should be documented as an exception, not treated as silent divergence.

Where the boundary should be

A plant should generally not be free to redefine corporate-critical concepts that affect cross-site controls or records. For example, if one site changes the meaning of a nonconformance status, material state, genealogy field, or completion event, enterprise reporting and evidence trails can become inconsistent.

A plant may need local taxonomy elements where operations genuinely differ, such as:

• different machine fleets or automation levels

• site-specific process steps

• legacy ERP or MES structures that cannot be changed without high validation effort

• regional language or operator usability needs

• program-specific classifications that are not relevant enterprise-wide

The key test is whether the local variation preserves traceability and can still be translated reliably into the corporate model.

Tradeoffs to expect

• More local flexibility improves adoption and operational fit, but increases governance overhead and mapping effort.

• More corporate standardization simplifies reporting and interoperability, but can fail if it ignores real plant differences or legacy constraints.

• Forcing total uniformity often looks efficient on paper but can create workarounds, shadow systems, and poor data quality.

• Allowing uncontrolled local variation reduces short-term friction but usually raises long-term integration cost and weakens semantic consistency.

There is no universal split that works everywhere. The right boundary depends on process commonality, data maturity, validation burden, and how much integration debt already exists.

Why full standardization by replacement often fails

If the implied answer is to replace local systems and force one taxonomy everywhere immediately, that is often unrealistic in regulated, long-lifecycle environments. Plants may be running qualified processes, validated records, long-lived equipment, and deeply embedded integrations. Replacing those stacks or changing taxonomy structures broadly can trigger significant retesting, change control effort, downtime risk, retraining, and data migration complexity.

That is why many organizations succeed with coexistence first: preserve local operational continuity, define a canonical corporate model, and manage mappings deliberately rather than assuming one-step harmonization will hold.

Practical rule

If a plant-specific term affects only local execution and can be mapped cleanly, a local extension is usually reasonable. If it affects enterprise metrics, audit evidence, traceability, data exchange, or quality status semantics, it should usually stay under corporate control.