How can we document semantic choices so they are clear to all plants?

Start with a controlled semantic standard that is shared across plants and tied to system behavior, not just a slide deck or glossary page.

In practice, the most reliable approach is to maintain a semantic decision register or business glossary with change control. For each semantic choice, document the term or metric, the exact definition, why it was chosen, where it is used, the system of record, allowed values, calculation logic if applicable, known exclusions, and who approves changes. If plants are allowed local variants, make those variants explicit rather than pretending one definition fits every process.

To make semantic choices clear across plants, capture at least these elements:

• Business meaning: what the term represents in operations, quality, maintenance, planning, or reporting.
• System meaning: where it is stored, which field or object carries it, and which application is authoritative.
• Usage context: where the term applies and where it does not.
• Allowed values and state transitions: especially for statuses, dispositions, work order states, nonconformance states, and equipment events.
• Calculation logic: for KPIs, including time basis, exclusions, rounding, unit conventions, and treatment of rework, scrap, hold, and downtime categories.
• Plant-specific exceptions: if a site uses a legacy code set or a qualified process that cannot change quickly.
• Traceability: version, approval date, owner, and link to related work instructions, master data standards, and interface mappings.

A simple naming standard is not enough. Most semantic confusion comes from differences in process intent, local code sets, historical reporting practices, and interface mappings between MES, ERP, PLM, QMS, historians, and spreadsheets. If those mappings are not documented, plants will use the same word for different meanings or different words for the same meaning.

What usually works better than a single global rewrite

In brownfield environments, a full semantic reset across every plant and system is often unrealistic. Legacy applications, validated workflows, qualified equipment, and downstream reports limit how much can change at once. A better pattern is to define an enterprise canonical meaning where possible, then map plant-specific terms to it with controlled aliases, transformation rules, and documented exceptions.

That coexistence model matters because full replacement or forced standardization often fails when plants have long equipment lifecycles, validated interfaces, and limited downtime windows. The burden is not just technical. It includes change control, retraining, report remediation, historical data comparability, and evidence that the new semantics do not break traceability.

How to make the documentation usable

If the documentation is hard to find or disconnected from daily work, people will ignore it. Make semantic definitions visible in the systems and artifacts people already use:

• data dictionaries for integrations and reporting layers
• field help and code descriptions in MES, QMS, and ERP screens
• approval-controlled reference documents for shared KPIs and statuses
• training materials for planners, supervisors, quality, and analysts
• interface specifications that show source-to-target mappings and transformation rules
• release notes when a definition, code, or calculation changes

It also helps to separate enterprise-standard terms from local implementation notes. That reduces confusion between the intended meaning and the way one site currently enters or derives the data.

Governance is the real control point

Cross-plant clarity depends less on the document format and more on governance. Assign ownership for semantic approval, define who can request changes, require impact assessment before changing a term or KPI, and track affected interfaces, reports, procedures, and training records. Without that discipline, definitions drift even if the original documentation was good.

Be explicit about failure modes:

• different plants using the same status with different exit criteria
• ERP and MES sharing a label but not the same business rule
• reporting teams recreating metrics with undocumented logic
• local spreadsheet workarounds becoming de facto standards
• master data changes made without updating interfaces or training

If you want all plants to interpret semantics the same way, documentation must be versioned, approved, and linked to implementation artifacts. Otherwise it becomes advisory only.

The short answer is yes: document semantic choices in a governed, version-controlled structure that connects business definitions to actual system fields, workflows, calculations, and exceptions. If you do not connect the semantics to ownership, mappings, and change control, they will not stay clear across plants for long.