Lesson 1 — Purpose, Function, Goals & Principles
Data Quality means fit for purpose
A useful short definition is the degree to which relevant quality dimensions meet requirements for a defined consumer purpose.
That makes quality contextual. A customer-address set that is 96% complete may satisfy a marketing use requiring 95% but fail a regulatory use requiring 99.9%. The data did not change; the purpose and threshold did.
Exam rule: never treat a score as meaningful without asking, “Compared with what requirement for what use?”
DQ Management is a function, not a cleanup project
A cleanup project can have a start and finish. Data Quality Management cannot, because rules, systems, consumers, suppliers, thresholds, and business processes keep changing. Mature DQ therefore includes ongoing standards, monitoring, issue management, communication, training, remediation, and improvement.
Projects can exist inside the function. The function survives after the project ends.
Four business drivers
- stakeholder/customer experience and reputation;
- organizational effectiveness;
- reduced risk and cost from poor data;
- efficiency and productivity.
Four goals
- Govern data so it is fit for defined purposes.
- Establish lifecycle controls and standards that protect quality.
- Measure, monitor, and report quality levels.
- Improve the processes and systems that create or damage data.
Cleansing alone is not a goal; it is one corrective technique.
Eight principles
- Criticality — focus on the data whose failure matters most.
- Standards-driven — express stakeholder needs as measurable expectations.
- Objective measurement and transparency — measure consistently and expose method/results to the people judging fitness.
- Prevention — stop defects from being created or propagated.
- Root-cause remediation — remove why the defect occurs.
- Embedded in business processes — process owners are responsible for quality their processes produce.
- Systematically enforced — system/process controls implement requirements consistently.
- Connected to service levels — quality expectations must link to response/remediation commitments where important.
Deciding examples
- Monthly script repeatedly repairs the same bad postal code → correction, not prevention.
- UI validation stops invalid codes entering → prevention.
- Manager optimizes call speed while ignoring required fields → failure to embed/oversee quality in the process.
- Supplier defect has a threshold but no response deadline → service-level connection is incomplete.
Source: pp. 424–428.