Lesson 4 of 6
Data quality rules and evaluation
11 min
Listen to this lesson
Governed processes protect new and changed records. But most records already exist, and their quality changes as the business changes. Data quality management in MDG measures the quality of active data against defined rules, shows scores over time, and drives remediation. It is the natural home for the rules a migration team wrote: sap-dmg-203 recommends that migration rules live on after cutover as checks in data entry, in governance and in reporting.
The quality cycle
- Define qualityAgree rules with data owners from real process needs, prioritized by impact
- Enter qualityApply rules at every entry point: single changes, mass changes, loads, projects
- Monitor qualityEvaluate active data regularly; track scores by rule, category and dimension
- Improve qualityCorrect data, fix the entry process that let errors in, refine the rules
Rules and their lifecycle
Rules are kept in one repository. Each rule has a name and ID, the checked field and base table, a description of the business reason and scope, and contacts such as the rule owner, the implementation expert and the data owner. Rules move through statuses that control whether they are used.
The logic of a rule is built in BRFplus. A scope expression decides whether a record is in scope; out-of-scope records get no outcome. A condition expression returns OK or not OK for records in scope. The base table sets the level of evaluation: for products, MARA gives one outcome per product, and MARC gives one per plant. Before approval, the simulation function tests active and inactive rule versions against selected data, which is the cheapest test you will ever run on a rule.
| Rule (Contoso) | Scope | Condition | Base level |
|---|---|---|---|
| Customer tax number present | Customers in company code 1910 | Tax number (RFC) filled and valid format | Business partner |
| Supplier has purchasing data | Suppliers with company code 1710 data | Purchasing organization 1710 view exists | Supplier |
| Payment terms allowed | Customers in sales area 1910 / 10 / 00 | Payment terms in the allowed list (for example 0004, not legacy CR30) | Customer sales area |
| Product has a production version | Products with MRP type PD in plant 1710 | At least one valid production version | Product plant (MARC) |
Illustrative Contoso rules, several carried over from the Wave 2 migration.
Where rules are used
Each usage can be enabled or disabled independently, with its own authorization. This matters for rollout. A new rule is often first used only for evaluation, to see how many existing records fail, before it is switched on for change requests where it would block users. Evaluation results are shown in the evaluation results apps, and SAP offers a Data Quality Dashboard in SAP Analytics Cloud with scores by category, dimension and rule and drill-down to failing records.
Remediation that sticks
Correcting failing records is the visible part of remediation; fixing the cause is the part that keeps the score up. For every rule that fails repeatedly, ask where the bad values come from and close that door. Typical causes at Contoso were an old upload program used by sales operations, a missing default in a request type, and an integration that wrote customers outside MDG.
- Correct the records: single change requests for a few, mass processing for many, or export to a file for correction and re-import.
- Find the entry point: who created or changed the failing records, through which app, interface or program.
- Close it: switch the rule on in change requests, add a derivation that sets the right value, or route the interface through MDG.
- Watch the trend: the rule owner reviews the score after each evaluation and reports it to the data owner.
What goes wrong in testing
- Rules tested only with failing data. A rule that fails everything looks like a working rule. Test in-scope passing, in-scope failing and out-of-scope records.
- Wrong base table. A plant-level rule built on MARA reports one outcome per product and hides the plant that fails. The base table is fixed after the first usage is prepared, so check it early.
- Enforcing before cleaning. Switching a rule on for change requests while thousands of records fail blocks every change to those records.
- Scores without owners. A dashboard nobody acts on is decoration; each rule needs an owner who follows its trend.
What would you do?
Lucía asks Hannah to enforce the "customer tax number present" rule for all change requests from tomorrow. The first evaluation shows 410 failing Monterrey customers. What should Hannah propose?
- Data quality management evaluates active data against rules and tracks scores.
- Rules have owners and statuses; only approved rules are evaluated.
- BRFplus scope and condition expressions plus a base table define each rule.
- One rule can serve evaluation, change requests and consolidation; switch usages on deliberately.
Check your understanding · not graded
Lesson check
1. What does the scope expression of a data quality rule decide?
2. Which rule status allows a rule to be used in evaluation?
3. Why might a new rule be switched on for evaluation before change requests?
4. A plant-level product rule should use which base table?