Data governance in manufacturing is the set of rules, roles, and standards that decide who owns each piece of plant data, what it means, who can use it, and where it came from. It is the unglamorous prerequisite for trustworthy reporting, analytics, and AI, the difference between a number people act on and a number people argue about.
Nobody buys software to "do data governance," which is exactly why so few plants have it. It shows up instead as symptoms: two departments bringing two different OEE numbers to the same meeting, a tag named TT_402 that only one retired engineer could decode, a dashboard everyone quietly distrusts. Governance is the discipline that makes those symptoms go away. This is a practical map of what it covers and how to start, written for plants that already have more data than they can trust.
What does data governance actually cover?
Five things, and they reinforce each other. Ownership answers who is accountable for a given data set. Definitions and naming standards answer what each term and tag means, so "downtime" or "good count" means one thing plant-wide. Quality answers whether the data is accurate, complete, and timely. Access and security answer who is allowed to see and change it. Lineage answers where a number came from and what happened to it on the way. Drop any one and the others weaken: perfect definitions with no owner drift out of date; clean data with no lineage still cannot be trusted, because no one can show their work.
Why is manufacturing data especially hard to govern?
Because a plant is two worlds that grew up apart. On one side is OT operational technology: PLCs SCADA historians, thousands of machine tags named by whoever wired the panel, often decades ago. On the other side is IT the ERP, MES, and quality systems, with their own schemas and their own naming. Neither was designed to hand data to the other, so the most valuable questions live in the seam between them, where no one owns the answer. That is the same root cause behind data silos and governance is the organizational half of the fix.
Three things make it harder still. Tag naming in OT is often ad hoc and undocumented, so the same physical quantity is called three different things on three lines. Legacy systems predate any standard and cannot be renamed without downtime. And the people who know what the old tags mean are retiring, taking the definitions with them, the tribal knowledge problem in its purest form. Governance is how a plant writes those definitions down before they walk out the door.
Data quality itself is not one thing but several, and naming them helps a plant see where it is weak. Is the data accurate does the recorded value match reality? Is it complete are half the downtime events missing because they were never logged? Is it timely does it arrive fast enough to act on, or is it a day old? Is it consistent does the same event read the same way across systems? A dashboard can look flawless while failing every one of these, because a chart drawn from bad numbers is just as smooth as one drawn from good ones. Quality is the pillar people most often assume they have and most often do not.
Who owns the data? Governance, stewardship, and ownership
These three roles get muddled, and the distinction is practical. In the widely used framing from the data-management profession, governance sets the rules, stewardship enforces and implements them day to day, and ownership holds accountability and direction for a specific data domain. A plant does not need a bureaucracy to have these roles, it needs them named. The failure mode is diffusion: when everyone is vaguely responsible for data quality, no one is, and the definitions rot.
| Role | What it does | On a plant floor |
|---|---|---|
| Governance | Sets the rules and standards | Decides the naming convention and access policy |
| Ownership | Holds accountability for a domain | The production manager owns OEE data for their area |
| Stewardship | Enforces the rules in practice | Keeps the tag dictionary and definitions current |
What is data lineage, and why does it matter?
Data lineage is the documented path a number takes from its source to the screen: which sensor or system it started in, what calculations and joins transformed it, and where it ended up. Lineage is what lets someone answer "where did this OEE figure come from?" without a forensic investigation. Without it, every disputed number becomes an argument that cannot be settled, because no one can trace it. With it, trust becomes checkable. Lineage is closely related to traceability on the product side, both are about being able to follow something backward through every step it took.
How do you start governing plant data?
Governance fails when it starts as a committee and a hundred-page policy. It works when it starts small and concrete, on the data people already fight about.
- Inventory the sources. List where operational data actually lives, machines, historian, ERP, MES, quality system, spreadsheets, paper, before trying to govern any of it.
- Pick one painful metric. Start with the number people argue about most, often OEE or downtime, and govern that end to end rather than boiling the ocean.
- Write the definition down. Agree exactly how that metric is calculated and what each input means, and publish it so the definition lives outside anyone's head.
- Name an owner and a steward. Assign one person accountable for the domain and one who keeps its definitions and tags current.
- Set access rules. Decide who can see and change the data, applying least privilege so the wrong hands cannot alter the record of truth.
- Trace and monitor. Document the lineage from source to report and watch a few quality checks, completeness, timeliness, so drift is caught early.
One caution specific to the plant floor: access rules for operational data are not just an IT concern, they are a safety one. The governing principle in industrial systems is that data flows up and commands stay down, analytics and reporting should read from the control layer through segmented, read-mostly connections, never with write access to the machines. Governing access well means a report can pull a signal without any path existing for a spreadsheet macro or a curious query to change a setpoint. Get that boundary right once and every later analytics and AI effort inherits it. Get it wrong and governance becomes a liability instead of a safeguard.
By the Numbers
Data governance is a mature discipline with an established body of knowledge. DAMA International the professional association behind the Data Management Body of Knowledge (DAMA-DMBOK), defines governance as the exercise of authority and control over the management of data assets, and formalizes the ownership, stewardship, quality, and lineage roles above. On the accuracy side, every trustworthy measurement ultimately rests on calibration traceable to national metrology standards maintained by NIST. And the business case is visible in adoption data: manufacturers collect far more data than they act on, with integration and trust, not sensing, as the recurring barrier (U.S. Census Business Trends and Outlook Survey). Where Harmony fits: Harmony connects machines, ERP/MES/quality systems, and paperwork into one real-time operational layer with a shared model of the operation, computes true OEE from source signals rather than estimates, and keeps a consistent definition of the numbers people act on. See what a manufacturing operating system is or how CLS unified its floor.
Why is governance the prerequisite for AI?
Because AI inherits the quality of the data underneath it, and amplifies it. Feed a model ungoverned data, undefined terms, no owner, no lineage, and it will produce confident answers built on numbers no one can verify, which is worse than no answer at all. Conversational analytics only works when the model is grounded in defined, governed data; agentic AI that takes action needs that grounding even more, because a wrong number can now trigger a wrong action. The same is true of where the data is stored: choosing between a data lake and a data warehouse is partly a governance decision about how much structure to impose and when. Governance is not the exciting part of an AI project. It is the part that decides whether the exciting part works. For the analytics that sit on top, see manufacturing analytics.