In my experience, everything in master data starts and ends with processes. Yet, so often I see organizations focusing on data quality as if it exists in isolation, running audits, building dashboards, and defining rules while the processes that generate and use that data remain flawed or misunderstood.

Data does not create value on its own. It only matters because of what people do with it: the decisions they take, the actions they execute, and the obligations they fulfill. When processes are broken, inconsistent, or misaligned, no amount of cleaning will fix the underlying problems. You can polish a tool, but if the process itself is flawed, the work will still be messy.

I have come to a simple rule: fix the process, and the data quality fixes itself. When you understand how data flows through the business, who touches it, and how it is used, you can design governance that actually works. You prevent errors, avoid duplication, and ensure completeness, not by chasing perfection in isolation, but by shaping the processes that create the data in the first place.

Master data is like the skeleton of the organization, but processes are the muscles and the heartbeat. Without strong processes, data quality initiatives are cosmetic. With them, data becomes reliable, actionable, and valuable.

Sequence Matters

Even if you understand the importance of processes but not, e.g., the dependencies of these, then you miss the point that the order in which you act is critical. Start with the wrong step, and you risk doing everything right—but in the wrong sequence. You end up identifying Critical Data Elements (CDEs) with no owners, building a data model with no governance, or implementing rules with no adaptiveness.

In short, it is like going to the toilet and doing everything right—but in the wrong sequence. You can follow every step perfectly, but if you start at the wrong end, the outcome is not pretty. Sequence is practical: first understand processes, then define ownership, then build governance, then refine the data. Skipping or shuffling these steps undermines all the effort that follows.

Process-driven ownership

As a Product Area Architect, my role is to clarify ownership boundaries, ensure accountability is embedded in processes, and make sure governance and supporting tools reinforce those responsibilities. Ownership is practical, tied to real work, not theoretical or symbolic.

The “owners” of master data are the people who are responsible for the processes that create, use, and maintain it. For example, the purchasing team owns vendor data because they interact with it every day and make decisions based on it. Finance uses it, but they don’t own it—they rely on the process owners to maintain it correctly.

Yet there is still a shared responsibility. Data quality is a shared outcome. While process owners are accountable, the broader organisation participates by using data correctly, following governance rules, and reporting issues.