Data Governance Solutions for Manufacturers: What Actually Works When You Have 5 ERPs and No Data Team

By: David Giraldo, Principal Fabric Analytics Consultant at Simple BI Last updated: Aug, 24, 2026

Data governance for manufacturing BI is the set of decisions, not tools, that determine who owns each metric’s definition, which system counts as the record when ERPs disagree, and who is accountable for keeping that definition accurate. For a manufacturer running multiple ERPs with no dedicated data team, it has to work as a lightweight discipline, not a department.

That definition matters because most of what gets sold as a “data governance solution” is built for a company that already has a Chief Data Officer, a governance council, and a budget line for a catalog tool. Most mid-market manufacturers have none of those things. What they have is a finance analyst who reconciles inventory numbers by hand every month, an ERP from the original business, a second ERP from an acquisition eight years ago that nobody migrated off, a third system a plant added on its own because corporate IT never told them not to, and a Power BI workspace where three departments each built their own version of “on-time delivery.” This guide is written for that manufacturer, not the enterprise one.

What Data Governance Actually Means for a Manufacturer

Strip away the vendor language and data governance for manufacturing BI comes down to three questions, answered once and enforced everywhere:

1. Who decides what “scrap rate,” “on-time delivery,” or “inventory turns” actually means, in numbers, not in a mission statement?
2. When two ERPs report different values for the same metric, which one is the system of record?
3. Who is on the hook when the certified definition drifts out of sync with reality, and how do they find out?

Everything else, the tools, the catalogs, the RACI charts, is implementation detail. A manufacturer that answers those three questions for its ten most important metrics has more functioning data governance than one that has bought a data catalog platform and never named a single accountable owner.

This is also where governance and reporting problems overlap. We covered the reporting side of this in our 3-layer framework for eliminating dashboard chaos in manufacturing: the governance decision is Layer 1 of that framework, and it is the layer that makes the other two possible. You cannot tier your reporting or decommission old dashboards until you have decided which version of each number is the real one.

The Real Cost of Skipping It

Poor data quality costs organizations at least 12.9 million dollars a year on average, according to Gartner research. That figure is not manufacturing-specific, and it includes companies far larger than most mid-market plants, but the mechanism behind it is exactly what shows up on a shop floor with ungoverned ERPs: every reconciliation meeting, every re-pulled report, every decision delayed because two departments trust different numbers is a direct line item against that cost.

Governance has also become the thing data leaders say is actually blocking them. In Atlan’s 2024 survey of more than 600 data leaders, conducted at the Gartner Data & Analytics Summit, over 65 percent named data governance their main focus for the year, ahead of AI initiatives and general data quality work. That is a notable reversal: for years, governance was the unglamorous item nobody prioritized until it caused a visible failure. It is now the thing data leaders identify as the prerequisite for everything else they are being asked to do, including AI.

For a manufacturer specifically, the cost shows up in a narrower, more concrete way than a market-wide average. It shows up as a plant manager pulling scrap rate from the MES, finance pulling it from the ERP’s cost accounting module, and continuous improvement pulling it from a spreadsheet a supervisor maintains by hand, all three disagreeing, and nobody able to say with confidence which one reflects what actually happened on the line last shift.

Why “5 ERPs and No Data Team” Is the Default Setup, Not the Exception

Manufacturing companies are the single largest buyer of ERP software: they made up 47 percent of companies actively shopping for a new ERP system in recent industry surveys, according to NetSuite’s ERP statistics roundup. Manufacturers do not run one ERP because they choose to; they run several because growth in this industry almost never happens on a single, clean system.

A typical path looks like this: a company starts on one ERP at its original plant. It acquires a competitor that was running a different ERP, and migrating that plant fully is expensive and disruptive enough that leadership decides to “deal with it later.” A third plant, opened or acquired more recently, picks its own system because corporate IT does not have the bandwidth to enforce a standard, and the plant needs to be operational now. A legacy MES or a homegrown Access database survives underneath one of these ERPs because nobody has had the time or budget to retire it. Multiply that by a decade of normal manufacturing growth, and five systems reporting on the same business is not a worst-case scenario. It is closer to average.

Layer onto the fact that most mid-market manufacturers do not have a dedicated data team. IT is staffed to keep plants running, not to build a governance function. Analytics work gets done by whoever is good at Excel in finance or operations, on top of their actual job. When people talk about “data governance solutions” as something you buy and install, they are describing a world that assumes a governance function already exists to operate the tool. That is precisely the assumption that does not hold for most manufacturers, and it is why so many governance initiatives stall: the tool gets purchased, and there is nobody available to run it.

A Governance Framework That Works Without a Dedicated Data Team

The following sequence is deliberately scoped to what a manufacturer can execute with the people already on staff, not a governance department it does not have.

1. Pick your ten metrics, not all of them. Do not attempt to govern every field in every ERP. Start with the ten numbers that actually drive decisions: revenue, OEE, scrap rate, on-time delivery, inventory turns, downtime, and whatever four or five are specific to your plant. Governing everything at once is how governance initiatives die before they ship anything.
   
2. Name one accountable owner per metric, a person, not a department. “Finance owns revenue” is not an answer. “Maria in FP&A owns the definition of revenue and is the one who approves any change to it” is an answer. If the owner leaves, the role transfers explicitly. It never sits vacant.
   
3. Decide the system of record per metric, not per ERP. You are not choosing one ERP to be the source of truth for everything, that decision is rarely realistic across five systems. You are deciding, metric by metric, which system’s version counts when there is a conflict. Inventory might come from the newest ERP; downtime might come from the MES; revenue might come from consolidated finance reporting regardless of which plant ERP originated it.
   
4. Build one semantic layer that maps every ERP’s version to the canonical definition. This is the technical piece, and it is smaller than it sounds. It does not mean migrating ERPs or building a data warehouse from scratch before you can start. It means building a single certified data model, in Power BI or Microsoft Fabric, where every plant’s raw data is mapped, transformed, and reconciled into one governed measure, regardless of which ERP the raw numbers originated in.
   
5. Certify it. Do not just document it. A definition written in a shared document that nobody is required to reference is not governance, it is decoration. The definition has to live inside the tool people actually use to pull the number, structurally enforced, not just written down somewhere a policy PDF gets forgotten.
   
6. Give it teeth. No new report gets built on a competing, uncertified version of a governed metric. This is a rule, not a suggestion, and it is the single most common place lightweight governance efforts fail: someone builds a “quick” dashboard outside the certified model because it is faster, and eighteen months later that quick dashboard is the thing three departments are arguing about in a Tuesday meeting.
   
7. Revisit quarterly. New plants get acquired, ERPs get added or retired, product lines change. A governance decision made once and never revisited degrades at the same rate the business changes underneath it.
   

None of this requires a Chief Data Officer, a governance council, or a data catalog platform. It requires one working session per metric with the people who already understand where the numbers live, and a semantic model that enforces the decision instead of just recording it.

The distinction that matters is scope, not effort. A lightweight governance approach and a full enterprise program answer the same three questions, they just do it at very different scale:

	Lightweight Governance (what a 5-ERP, no-data-team manufacturer needs)	Enterprise Governance Program (what it doesn’t need yet)
Scope	10 to 15 metrics that actually drive decisions	Every field across every system
Ownership	One named person per metric, existing staff	A governance council or Chief Data Officer
Enforcement	A certified semantic model in Power BI or Fabric	A dedicated data catalog or governance platform
Documentation	Definitions live inside the certified model itself	A separate policy document and change-management process
Cadence	Quarterly review of the same 10 to 15 metrics	Continuous, formal governance operations

Most manufacturers in this situation don’t need to build the right-hand column at all. They need the left-hand column done consistently for the metrics that actually cause reconciliation meetings.

Data Governance Maturity: Where Most Manufacturers with This Setup Actually Land

Most maturity models, including the widely referenced DAMA DMBoK and Gartner frameworks, describe five levels. Knowing where you actually sit is more useful than the label itself, because it tells you which of the seven steps above to run first.

Maturity Level	What It Looks Like	Typical for a 5-ERP, No-Data-Team Manufacturer
1. Initial / Ad Hoc	Uncoordinated, undocumented, reactive; each department defines metrics its own way	Very common starting point. No named metric owners, no certified model.
2. Developing	Some awareness of the problem, informal ownership in a few areas, no enforcement	Where most manufacturers land after a first attempt at governance stalls
3. Defined	Formal policies and named owners exist and are consistent across most of the business	Achievable within a few months by working through the framework above metric by metric
4. Managed	Governance is measured, consistently applied, and enforced structurally across the organization	Realistic goal for a manufacturer that has built and certified its semantic layer
5. Optimized	Governance is continuously improved and tied directly to business strategy	Typically requires a maturing data function, not a prerequisite for getting real value out of governance

The answer for most manufacturers in this situation is that they are sitting at Level 1 or 2, and that is not a failure, it is the expected starting point for a company that grew by acquisition without a parallel investment in a data function. The goal is not to leap to Level 5. It is to move deliberately from Level 1 or 2 to a solid Level 3, which is where the real reduction in reconciliation meetings and conflicting numbers actually happens.

What This Looks Like in Power BI and Microsoft Fabric

The framework above maps directly onto tooling most manufacturers running Power BI already have access to, without adding a new governance platform to the budget.

Microsoft Fabric’s OneLake is the practical answer to reconciling five ERPs without migrating any of them first. Each ERP’s data lands in OneLake through its own connector or dataflow, and the semantic model sits on top, mapping every source system’s version of a metric to the single certified definition. Nobody has to wait for an ERP consolidation project that may never happen. The governance decision gets implemented at the semantic layer, not at the source systems.

Power BI’s endorsement system is the enforcement mechanism for step five above. Move each certified metric’s semantic model to Certified status, restrict who can apply that label to a small, accountable group of reviewers, and require every new report connecting to that metric to reference the certified model rather than importing raw ERP data again. Promoted status is available for departmental work still being validated; unendorsed content stays exactly that, unendorsed, and is not a source anyone should treat as authoritative.

Row-level security applied at the semantic model layer, rather than duplicated across five separate reports pulling from five separate ERPs, is what makes the governed model actually usable across an organization with different access needs at the plant, regional, and executive level, without maintaining five parallel security setups.

None of this requires buying a dedicated data governance platform before you start. It requires using the certification and modeling capabilities already inside the Microsoft stack most manufacturers are already paying for.

Common Mistakes Manufacturers Make with Data Governance

Waiting for a data hire before starting. Governance does not require a Chief Data Officer to begin. It requires naming an owner for one metric and starting there. Manufacturers who wait for the “right” hire before starting often wait years, while the number of conflicting metric versions keeps growing.

Writing a policy nobody is required to follow. A metric dictionary that lives in a document nobody opens is not governance, it is decoration. It has to be enforced through the certified model and access controls, not through a policy people are expected to remember on their own.

Trying to govern everything at once. Attempting to define and certify every field across five ERPs before shipping anything is how governance initiatives stall indefinitely. Start with ten metrics. Expand from there once the first ten are working.

Treating ERP consolidation as a prerequisite. You do not need to be on one ERP to govern effectively. The semantic layer reconciles across systems; it does not require them to be the same system first.

Choosing a governance tool before making the ownership decision. A data catalog or governance platform without a named, accountable owner per metric is an expensive way to document a problem you have not actually solved. Make the ownership and system-of-record decisions first. The tooling question comes second, and for many mid-market manufacturers, the tooling already sitting inside their Power BI and Fabric licenses is sufficient.

Frequently Asked Questions

What is data governance for manufacturing BI?

Data governance for manufacturing BI is the set of decisions that determine who owns the definition of each metric, which system counts as the record when ERPs disagree, and who is accountable when that definition drifts. It is a governance decision enforced through a certified semantic model, not a policy document or a piece of software on its own.

What are the best data governance solutions for a manufacturer running multiple ERP systems?

The most effective approach for a manufacturer with multiple ERPs is not a single governance platform but a certified semantic layer, built in Power BI or Microsoft Fabric, that maps every ERP’s version of a metric to one governed definition. This lets a manufacturer reconcile across five systems without consolidating them into one first, and without needing a dedicated governance platform purchase.

How do you set up data governance without a dedicated data team?

Start with your ten most important metrics, name one accountable person, not a department, as the owner of each, decide which system counts as the record for that metric, and build a certified semantic model that enforces the definition structurally. This can be run by existing finance, operations, and IT staff working through the metrics one at a time, without hiring a Chief Data Officer or standing up a formal governance function first.

How much does poor data governance actually cost a manufacturer?

Poor data quality costs organizations at least 12.9 million dollars a year on average, according to Gartner research, though the figure varies enormously by company size. For most mid-market manufacturers, the more visible cost is time: hours spent every week reconciling conflicting numbers across ERPs instead of acting on them, and decisions delayed while departments argue about whose figure is correct.

What data governance maturity level are most manufacturers actually at?

Most mid-market manufacturers running multiple ERPs without a dedicated data team sit at Level 1 (Initial/Ad Hoc) or Level 2 (Developing) on the standard five-level maturity models used by DAMA and Gartner. That is the expected starting point for a company that grew through acquisition without a parallel investment in a data function, not a sign of failure. The realistic near-term goal is reaching a solid Level 3 (Defined), not jumping straight to Level 5.

Do I need a Chief Data Officer or a dedicated data team to do data governance?

No. A named metric owner, a decided system of record per metric, and a certified semantic model that enforces those decisions can be run by existing finance, operations, and IT staff. A dedicated data function becomes valuable as governance scope expands past the initial ten to fifteen metrics, but it is not a prerequisite for getting started or for seeing a real reduction in conflicting numbers.