Data Quality Is a Governance Problem in a Technical Costume

Organisations that invest in analytics eventually run into data quality, and the response is almost always to give the problem to a technical team.

They build validation, cleansing routines and monitoring. Quality improves for a while and then decays, because the source of the defects was never technical.

Bad data is created by people doing their jobs

Trace a data quality defect to its origin and you usually find a person entering information under time pressure, into a field whose purpose they do not know, for the benefit of a downstream process they never see.

They are not careless. They are optimising for their actual objective, which is completing the task in front of them. A validation rule that blocks them produces a workaround, not better data.

Nobody owns the definition

The recurring pattern is that no single person is accountable for what a given field means. Sales has one understanding of customer status, finance another, operations a third.

Cleansing routines cannot resolve this because there is no correct answer to converge on. The prerequisite is agreement, and agreement is a governance activity.

Fix the point of capture

Downstream cleansing treats symptoms indefinitely. The durable fix is at the point of entry, and it is usually about design rather than enforcement.

Reduce the number of fields. Explain what each one is for, in the interface, where the person can see it. Where a value can be derived rather than entered, derive it. Every field you remove is a category of defect eliminated permanently.

Measure quality where it hurts

Generic completeness metrics tell you very little. What matters is quality in the specific fields that feed specific decisions.

Pick the three decisions that depend most heavily on data and measure the quality of only those inputs. That produces a short list somebody can actually act on, and it connects the effort to a consequence people care about.

Give each critical field an owner

The single most effective intervention we know is also the least technical. Take the fields that matter, and assign each one a named business owner responsible for its definition and its quality.

Not the technology team, which does not control how the field is populated. The function whose process creates it. Once that accountability exists, most of the remaining work is straightforward, and the improvements stop decaying the moment the project team leaves.