Most organizations treat data quality management as a technical discipline. When customer records are incomplete or duplicated, the request goes to IT: clean it up, deduplicate it, build a rule.
The request sounds reasonable. It is also the reason the problem never goes away.
Take a common case. KYC files sit pending because compliance cannot confirm which of three records is the actual customer. Rebate calculations cannot close because the same client exists under three names. The data team is asked to fix it. They write matching rules, merge what they can, and report a cleaner dataset. Three months later the duplicates are back, because the onboarding process that created them was never touched.
Your data team cannot fix data that was never collected.
Why the IT-first approach fails
Downstream cleansing works on what exists. It cannot recover a tax identifier that was never requested at onboarding, or a legal entity name that was typed differently by two account managers because neither had a reference list to check against.
Those gaps are not technical defects. They are decisions, or absences of decisions, made in a business process. A field was optional when it should have been mandatory. Two teams were allowed to maintain separate versions because nobody was accountable for the shared one. An approval step exists in the procedure document but not in anyone’s actual week.
Technology cannot repair a broken business process. It can only scale it. Automate a flawed onboarding flow and you produce flawed records faster.
Data quality is decided at the point of capture
The moment a record is created is the only moment its quality is cheap to control. Ask for the missing field then, and it costs a few seconds. Try to reconstruct it two years later, across three systems and a migration, and it costs a project.
This is why serious data quality management focuses on capture before it focuses on cleansing. The question is not “how do we clean this?” but “why was it allowed in like this, and who decided that?”
The second question usually has no answer. That absence is the real finding.
What data quality management actually requires
Danette McGilvray’s Ten Steps to Quality Data and Trusted Information remains the most practical reference for this work, and its structure makes the point better than any principle. The ten steps group into three phases: assessment, awareness, and action.
Most teams skip straight to action. That is the mistake.
Assessment starts with the business need (step 1) and the information environment (step 2), then assesses the data itself (step 3). Nothing here is technical yet. It is about understanding which decisions depend on this data, who creates it, and where it flows.
Awareness is the step almost everyone underinvests in: assess the business impact (step 4). Put a cost on the problem in terms the business already uses; delayed contracts, pending KYC files, rebates that cannot close, hours of reconciliation. This is the moment business users move from “the data team should fix that” to “this is costing us, and we own part of the fix.” Without it, you will not get the commitment needed to change how data is captured. With it, the business asks you to move faster.
Only then does action begin: root causes (step 5), improvement plans (step 6), and the controls that follow. And step 10 runs throughout: communicate, manage, and engage people. Data quality management is a change program with a technical component, not the other way around.
Where to start
Pick a business problem, not a data problem. “Customer master data is inconsistent” will not get funded. “Rebate calculations cannot close because the same client exists three times” will, because someone already loses sleep over it. This is the same discipline that makes data governance work: start from a costed business problem, and let the structure form around the fix.
Assess the business impact before proposing anything. Quantify what the problem costs, in the dimensions the business reports on. This is what turns a data initiative into something the business asks for. Skip it and you are selling a fix nobody has agreed they need.
Design preventive controls before corrective ones. McGilvray separates the two deliberately: prevent future errors (step 7) and correct current errors (step 8). Teams reach for correction first because the backlog is visible and cleaning it feels like progress. But correction without prevention is a quarterly ritual. Make the field mandatory, put the duplicate check at the front door, add the reference lookup at capture. Then clean the backlog. Otherwise you will be cleaning it again in three months, and the business will have stopped believing the numbers.
0 Comments