Skill Hub — DAMA / Data

Data Quality Root Cause Working Skill

Trace a data defect from symptom to entry point. Classify the root cause type. Produce a correction plan and a prevention control.

What this skill is for

This skill helps you stop treating data quality symptoms as root causes. It provides a repeatable method to trace a defect backward through systems, processes, and decisions until you find the point where bad data entered the lifecycle. The output is a classified root cause, a correction plan for affected records, and a prevention control that stops recurrence.

When to use this skill

A report shows incorrect values and someone says "the data is bad" without explaining why.
Orders are blocked because customer master data is incomplete, and the fix is always manual.
Duplicate records appear in a system and deduplication campaigns keep finding more.
An integration sends data to a target system, but the target rejects it or stores it incorrectly.
A data steward spends more than 20% of their time correcting the same type of defect.
An audit or incident review requires a documented root cause and prevention plan.

Real work situations

Example 1: Invoice blocked by missing tax number

Invoices for German customers fail because TaxNumber1 is empty. The symptom is in the billing document. The root cause is that the CRM integration creates customers without validating the tax number, and the SAP incompletion procedure does not block the customer until invoice time. The correction updates affected customers. The prevention adds validation at the CRM-to-SAP interface and strengthens the incompletion procedure.

Example 2: Duplicate vendors in procurement

Buyers create new vendor records because they cannot find existing ones. The symptom is duplicate payment runs. The root cause is a search help that requires exact name matching and a governance gap: no one reviews new vendor requests against existing records. The correction merges duplicates. The prevention adds a fuzzy search and a data steward approval step.

Example 3: Wrong material group in COGS report

The COGS report groups materials incorrectly. The symptom is wrong financial reporting. The root cause is a mapping table updated by IT six months ago without notifying Finance. The correction remaps historical transactions. The prevention adds a change notification workflow and a report validation step.

Example 4: IDoc failure in customer replication

Customer master changes fail to replicate to a downstream system. The symptom is an IDoc status 51. The root cause is a reference data mismatch: the target system does not recognize a new country code added in the source. The correction reprocesses with the correct mapping. The prevention adds reference data synchronization to the change process.

Inputs required

The exact symptom: field, value, record count, system, and business process affected.
Sample records showing the defect (anonymized if needed).
System landscape: where the data is created, transformed, stored, and consumed.
Data entry points: user interfaces, integrations, batch loads, API calls.
Validation rules that should have caught the defect (if any exist).
Ticket or incident history showing recurrence frequency (optional).
Stakeholders who can explain the business process and the data flow (optional but recommended).

Questions to ask

Which field is wrong, what is the wrong value, and what should it be?
When did the defect first appear, and has it happened before?
Where was this record created, and who or what created it?
What validation should have caught this, and why did it not?
Which business process fails when this field is wrong?
How many records are affected, and how many more could be affected?
Who corrected this last time, and what did they do?
Is the defect caused by a rule that does not exist, a rule that exists but is not enforced, or a rule that is wrong?

Working method

Document the symptom precisely. Record: data element, wrong value, expected value, system where observed, business process affected, number of records, and first occurrence date. Do not proceed with vague symptoms.
Identify the business impact. Quantify if possible: orders blocked, invoices delayed, reports wrong, compliance risk. If you cannot quantify, describe the business consequence in process terms.
Trace backward to the entry point. Follow the data from the symptom system to the system that created or last modified the record. Check integrations, batch jobs, user transactions, and API calls.
Classify the root cause type. Use one of: missing rule, unenforced rule, wrong rule, upstream data error, integration mapping error, reference data mismatch, user error without guardrail, system bug, unknown.
Identify the entry point detail. Name the exact system, transaction, interface, or user action where the defect entered. Include timestamp and user or process ID if available.
Assess scope. Determine how many records are affected now, how many could be affected in the future, and whether the defect is spreading to downstream systems.
Design the correction. Choose: manual correction, mass update with validation, reprocessing, mapping fix, or record merge. Define validation and approval steps.
Design the prevention control. Choose: add validation, strengthen workflow, fix mapping, synchronize reference data, add monitoring, or change the user interface. The prevention must address the root cause, not the symptom.
Assign ownership. Name who corrects, who validates, who implements the prevention, and who monitors.
Produce the Root Cause Analysis Note. Document symptom, classification, entry point, impact, correction, prevention, and owners. Use the template.
Validate with stakeholders. Confirm the root cause, correction approach, and prevention control with business and technical owners before execution.

Decision rules

If the defect recurs, the root cause is not the symptom; trace further upstream.
If only a few records are affected and the rule is clear, correct records through the governed process.
If many records are affected, prepare mass correction with validation and approval; never mass-update without a sample check.
If the root cause is "user error," look for the missing guardrail or validation that should have prevented it.
If the root cause is an integration mapping error, fix the mapping before correcting records, or the correction will be overwritten.
If the root cause is a reference data mismatch, synchronize reference data before reprocessing affected transactions.
If no validation rule exists for this data element, the root cause is "missing rule" even if the data looks obviously wrong.
If a rule exists but is bypassed by a specific path (API, batch, direct DB), the root cause is "unenforced rule."

Deliverables

Root Cause Analysis Note — classified root cause, entry point, impact, correction, and prevention. See Artifact Templates.
Remediation Backlog Item — if mass correction or prevention implementation is needed. See Artifact Templates.
Data Quality Rule — if a new or updated rule is required. See Artifact Templates.

Templates

Root Cause Classification Quick Reference

| Type | Definition | Typical Fix | Prevention |
|------|------------|-------------|------------|
| Missing rule | No validation or policy exists | Define rule | Add enforcement point |
| Unenforced rule | Rule exists but is bypassed | Close bypass | Strengthen enforcement |
| Wrong rule | Rule exists but allows bad data | Correct rule | Change validation logic |
| Upstream data error | Source system sends bad data | Fix source or add mapping | Source validation |
| Integration mapping error | Field mapped incorrectly | Correct mapping | Mapping test + monitoring |
| Reference data mismatch | Code values out of sync | Synchronize codes | Reference data governance |
| User error without guardrail | User entered wrong data | Correct records | Add UI validation or workflow |
| System bug | Software defect | Patch or workaround | Regression test |
| Unknown | Cannot determine root cause | Escalate | Add logging or monitoring |

Defect Trace Log (compact)

| Step | System | Field Value | Rule Checked? | Result | Next Step |
|------|--------|-------------|---------------|--------|-----------|
| 1 | Billing | TaxNumber1 = empty | Incompletion procedure | Failed at invoice, not at customer creation | Check CRM integration |
| 2 | CRM | TaxNumber1 = empty | CRM validation | None exists | Root cause: missing rule at CRM entry |

Quality checklist

The symptom is documented with exact field, value, system, and business process.
The root cause is classified into one of the defined types, not described as a narrative.
The entry point is named: specific system, transaction, interface, or user action.
The correction approach includes validation and approval steps.
The prevention control addresses the root cause, not the symptom.
All owners are named, not just roles.
The analysis has been validated with at least one business and one technical stakeholder.
If the root cause is unknown, there is a plan to add monitoring or logging to discover it.

Common mistakes

Mistake: Treating the symptom as the root cause. Consequence: The defect recurs because the upstream validation was never fixed.
Mistake: Mass-correcting records before fixing the source or mapping. Consequence: The next integration run reintroduces the same defect.
Mistake: Blaming "user error" without investigating why the system allowed it. Consequence: Users keep making the same mistake; morale drops; no systemic fix occurs.
Mistake: Skipping the scope assessment. Consequence: A "small" correction turns into a multi-system remediation when downstream impacts are discovered late.
Mistake: Proposing prevention controls that are not enforceable. Consequence: The prevention is ignored, and the defect recurs within the next project cycle.

Agent instructions

When using this skill, an AI agent must:

Demand precise symptoms. If the user says "data is bad," ask: which field, which records, which system, which business process, and what is the expected value? Do not proceed with vague input.
Trace backward systematically. Ask about the data lifecycle: creation, modification, integration, storage, consumption. Do not guess the entry point.
Classify the root cause. Use the classification table. If none fit, say "unknown" and propose monitoring.
Separate correction from prevention. Always produce both. A correction without prevention is incomplete. A prevention without correction leaves existing defects in place.
Produce artifacts, not explanations. Output a Root Cause Analysis Note and, if needed, a Remediation Backlog Item. Use the templates.
Link to Atlas diagnostics. If the defect involves SAP master data, link to SAP Master Data Duplicate Diagnostics, SAP Business Partner Replication Diagnostics, or SAP IDoc Status Diagnostics.
Handle missing information. If system logs or record samples are unavailable, produce a discovery checklist and ask the user to gather them before completing the analysis.

Related skills

Data Governance — when root causes reveal ownership or rule gaps.
Master Data Management — when defects are in master data domains.
Data Lineage — when the data path from source to symptom is unclear.
Root Cause Analysis — for broader operational root cause methods.

Related Atlas pages

Data Quality Controls — types of controls and where to apply them.
SAP Master Data Duplicate Diagnostics — finding and resolving duplicates.
SAP Business Partner Replication Diagnostics — tracing BP replication failures.
SAP IDoc Status Diagnostics — classifying IDoc failures.

Verification status and limitations

This skill is a public working interpretation of data quality root cause analysis. It is not official DAMA-DMBOK or Six Sigma documentation. It has been applied in SAP-centric support and project contexts but may need adaptation for real-time streaming, IoT, or unstructured data pipelines.

Limitations: This skill assumes you can access system logs, record samples, and stakeholders. It does not cover statistical process control, advanced data profiling, or automated anomaly detection. For large-scale automated root cause, specialized tooling is required.