Integrated Capstone — Customer Data Quality Crisis
Scenario
A company launches a customer analytics platform. Profiling shows duplicate customers, missing emails, invalid state codes, and inconsistent status definitions. The warehouse loads on time, but the source customer master is frequently stale. Business units disagree about which defects matter most. A vendor supplies address data with no formal quality commitments. Operations cleanses records nightly, but defects recur. Executives receive a defect-count spreadsheet with no thresholds or business-impact context.
Chapter 13 response framework
1. Purpose / criticality
Identify consumer uses and business drivers. Rank CDEs/risks rather than treating every defect equally.
2. Dimensions
- duplicate customers → Uniqueness;
- missing email → Completeness;
- invalid state → Validity (possibly consistency/integrity depending facts);
- stale customer master → Currency;
- conflicting status definitions → Consistency plus Metadata/Governance context.
3. Requirements
Define approved business/DQ rules and purpose-specific acceptance thresholds.
4. Assessment
Use profiling and deeper analysis to establish baseline. Validate findings with Stewards/SMEs.
5. Prioritization
Use business impact, regulatory/customer/reputational risk, criticality, cost/benefit, and feasibility—not raw defect volume.
6. Root cause / prevention
Fix source-master process, definitions, entry/process/system controls, and integration points. Nightly cleansing alone is not a mature answer.
7. Supplier boundary
Create a DQ SLA covering data, rules/measures, thresholds, notification, remediation, and escalation.
8. Operations
Manage rules, monitor conformance, run issue workflow, track SLA performance, and preserve DQ Metadata.
9. Governance
Use Data Governance to resolve ownership/priority conflicts and ensure DQ evidence produces action.
10. Reporting
Replace raw defect count as the only view with scorecards, trends, SLA/issue status, and business effects of improvements.
Changed fact
If contractual/technical constraints prevent source changes and controlled midstream standardization is cheaper, reliable, and accepted, ongoing correction may be a legitimate operating control. That does not remove the need for rules, monitoring, SLA, lineage, issue history, or Governance.
Final answer pattern
PURPOSE → CRITICALITY → DIMENSION → RULE/THRESHOLD → ASSESS → PRIORITIZE → RCA/PREVENT → OPERATE/SLA → GOVERN → REPORT/IMPROVE
Source: Chapter 13, pp. 424–470.