Process family
Data quality and master data processes: rules, defects and shared records
Five templates for keeping shared data fit for use: quality rules and monitoring, one defect from report to closure, master records from request to retirement, the business glossary and the catalog entry they all reference.
Data quality and master data are the two disciplines that decide whether a number can be trusted and whether two records are the same customer. This family groups the five templates that run them: a rules-and-monitoring process, a defect process for one issue, a master data process for shared entities, and the glossary and catalog that give every rule and record a defined meaning.
The five depend on each other in a fixed order. Data quality management is the standing process: a consumer raises an objective, the steward and owner agree rules and tolerances, engineering implements the controls and monitoring reports breaches. When one breach matters, it leaves that loop and becomes a case in data quality issue management: impact assessed, use contained, cause confirmed, correction accepted by owner and consumer, and closed with a preventive follow-up. Each rule names a field whose meaning comes from the glossary term and catalog entry, which is why both are listed here.
Master data management handles the records several systems share: customers, suppliers, products, sites. Its central decision is the match result. Every create or change request is checked against existing records before a domain owner approves it, MDM operations publish the identifier and reconcile distribution, and retirement waits until nothing downstream still depends on the record. A duplicate master is where the two templates meet: a duplicate found in a quality check is contained in the issue process and resolved through a master data change, so the correction lands at source rather than in one report.
The typical failures are structural. Rules get written without a tolerance, so every score is a breach and none is actioned; an issue is corrected in the report but not at source, so it returns; and a master record is retired while an application still reads it. Each template puts a named decision in front of that step, asking whether the tolerances were approved, whether owner and consumer accept the correction, whether the master record is safe to retire. The authority those decisions rest on is set in data governance, and the pipelines that move the data between systems are in data engineering and migration.
Templates in this family
- Data quality management process flowchart — Data quality management process template for prioritizing critical data, defining measurable rules, monitoring results and sustaining preventive improvements over time.
- Data quality issue management process flowchart — Data quality issue management template for reporting one defect, assessing impact, containing use, confirming cause, remediating data and closing with evidence.
- Master data management process flowchart — Master data management process template for validating requests, matching records, approving changes, publishing identifiers, maintaining attributes and retiring records.
- Business glossary process flowchart (proposal to published term) — Business glossary process template for proposing terms, drafting definitions, resolving duplicates, steward and owner approval, catalog publication, review, revision and retirement.
- Data catalog process flowchart (register to certify) — Data catalog process template for registering an asset, enriching metadata, assigning stewardship, validating user context, certifying status and maintaining the record.