Core takeaways
- Bad data is manufactured upstream by business processes and incentives, so IT alone cannot fix it.
- Quality changes when violations reach a council agenda with named owners, agreed thresholds, and binding decision rights.
- Start small: your ten most expensive recurring defects, an owner's name on each, and thresholds you are willing to be held to.
Every enterprise we meet has a data quality effort somewhere. It usually lives in IT, it usually has a dashboard, and it usually has a backlog of known issues that has not shrunk in a year. The dashboard is accurate. The backlog is honest. And nothing changes, because the people looking at the dashboard do not have the authority to change the behavior that creates the defects.
That is the tell. When quality is framed as a technical problem, it gets technical solutions: profiling tools, cleansing jobs, another reconciliation script. Useful, all of it, and none of it touches the root cause. Bad data is manufactured upstream, by processes and incentives that belong to the business. Which means the fix belongs to leadership.
Why IT cannot fix quality alone
Consider the most ordinary defect in any enterprise: the same supplier, customer, or part exists three times with three spellings across three systems. IT can detect the duplicate. IT can even merge it. But IT cannot decide which record is authoritative, because that is a business judgment about a business relationship. IT cannot stop the duplicate from being created again tomorrow, because the intake process that created it belongs to procurement or sales. And IT certainly cannot resolve the standoff when two departments each insist their version is correct.
Every one of those blockers is a decision, not a defect. Organizations that route decisions to a help desk get what a help desk produces: tickets. Organizations that route decisions to accountable leaders get resolutions. The difference between the two is the whole game.
What changes on a council agenda
The structural fix is to move quality from a backlog to an agenda. In the governance operating model we deploy, DG-OS™, that agenda belongs to a tiered council structure spanning enterprise, local, cross-domain, and intra-domain governance, with prescribed criteria for who can steward data. The specifics can flex to the organization. The non-negotiables are three.
First, measurement against thresholds the business agreed to, so a violation is a breach of a commitment rather than a matter of opinion. Second, named owners, individual people rather than departments, so every metric on the page has a face next to it. Third, decision rights, so when domains disagree, the council resolves the conflict and the resolution is binding. A council with those three properties changes behavior upstream, which is where quality is actually made.
Notice what happened to IT in this model: it moved from owner to instrument. Tooling like our DQE™ Data Quality Engine measures, monitors, and reports the violations. The council decides. That division of labor is what makes both sides effective.
Proof it works when leaders own it
This is not a theoretical preference. Our governance operating model drove a 99.4% reduction in data quality violations at a $40B aerospace and defense supplier, on data estates measured in hundreds of millions of records. At a $1.2B healthcare franchise organization, the same leadership-owned approach produced roughly $12M in annualized impact. At a construction firm, governance was the foundation under 5x revenue growth.
Different industries, same pattern: the inflection point was never a new tool. It was the meeting where a quality violation was read out with a name attached, and the room understood that the number was now somebody's to fix.
The leadership playbook
If you lead a function and suspect your data is quietly costing you, the playbook is short. Ask for the ten most expensive recurring data defects in your area, in business terms rather than system terms. For each one, ask who owns it, by name; if the answer is a team or a tool, you have found the problem. Set thresholds you are willing to be held to, put the measurement in front of a council that meets on a cadence, and give that council the standing to make its decisions stick.
None of that requires a transformation program to start. It requires a leader deciding that data quality is part of operational excellence, the same way safety and financial controls are. The organizations that make that decision stop treating quality as an IT metric and start treating it as a management discipline. Those are the ones whose AI investments, analytics, and audits get cheaper every quarter instead of more expensive.
DataOps builds the governed data foundation that makes AI trustworthy. If this topic is on your desk this quarter, start a conversation.
