Data governance, without the framework talk

DAMA calls it the exercise of authority and control over the management of data assets, which is precise and lands badly in a meeting. What it means day to day is deciding who decides: who owns a definition, who approves access, who is accountable when a number turns out to be wrong. Policies, roles and rules are how those decisions get written down so they still hold six months after the meeting.

Governance decides, management builds. Governance sets the strategy, the policies and the decision rights: who owns the customer definition, who approves access, what quality level is good enough. Data management is the technical work that carries those decisions out across architecture, integration and security. You need both. One without the other is either a policy nobody implements or a platform nobody agrees on.

Data literacy is your teams being able to read a number, question it and act on it. It is the difference between a dashboard people cite and a dashboard people trust. And it is usually a vocabulary problem rather than a numeracy one: people are rarely bad at reading a chart, they are unsure whether "active customer" means the same thing on your slide as it does in their report.

Rather than govern the whole enterprise at once, you pick one use case that already hurts, such as the customer domain or the board report, and you govern it end to end: owner named, definitions agreed, quality measured, access controlled. You get something working in weeks instead of a framework document in months, and your sponsor gets a result they can see.

The data owner is a business leader who can actually change things: authority and budget over a domain such as Customer or Finance, and the consequence when a call goes wrong. The data steward is the person who does the work, maintaining definitions, chasing quality issues, applying business rules and answering what a field means. An owner without a steward is accountability with no capacity; a steward without an owner is work with no mandate.

In three places, and you can usually count all three. Cost: the hours your people spend cleaning data, reconciling reports and rebuilding numbers nobody trusts. Revenue: the analytics and AI models you can act on because what feeds them is dependable. Risk: the fines, breaches and audit findings you did not have. If you want a figure to open the conversation with, put your own rework hours into the cost of bad data calculator on this site.

No. Tools help; they do not decide anything. You can start with what you already own: a spreadsheet for the glossary, a RACI for the roles, a written rule for classification and access. Buy the platform once you know what you want it to do, because a catalog full of definitions nobody has agreed on is an expensive list of table names.

Almost every AI problem I get called into turns out to be a data problem: nobody can say where the training data came from, who approved its use, whether it holds personal records, or why the model answered the way it did. Governance is what answers those questions, through lineage, classification, access control and retention. That is why the organizations that governed their data first are the ones whose AI work survives contact with a regulator.

A diagnostic plus a first governed use case usually runs 8 to 12 weeks: a few weeks to see clearly where it hurts, the rest to fix one thing end to end. What you have at the end is not a finished program. It is a working example and a plan the organization believes, which is what you need before taking on the next domain.