Data quality governance: roles, controls and correction

Management challenge

Data quality after ERP, BI and AI go-live is a recurring management process: owners detect errors, correct source records and verify how corrections reach dependent reports and plans.

When the problem becomes visible

• The same object has different identifiers
• Reports require repeated manual cleaning
• Corrections do not propagate to dependent systems
• No role owns the meaning of a data field

How to design the solution

This approach keeps the discussion focused on management control rather than only on system functions.

• Define critical data objects
• Assign semantic and quality owners
• Set measurable quality rules
• Create a correction and revalidation workflow

Common mistakes

The most common mistakes appear when a team trades architecture quality for launch speed.

These mistakes may be hidden during a demonstration but become visible in production operation.

• Treat quality as a one-off migration task
• Correct only the report instead of the source
• Measure errors without assigning action

Key takeaways

• Quality is managed at the source.
• A rule needs an owner and response.
• Corrections must propagate through dependencies.
• Regular monitoring keeps data usable.

The decision in two paragraphs

Data work starts with a model: objects, identifiers, master data, sources, quality rules and correction owners. Integration transports a record; it does not make that record unambiguous or trustworthy by itself. For this task, the initial evidence is “errors are corrected only manually”, and the decision boundary concerns measures and thresholds.

The practical focus is data lineage, quality, accountability and management use. A decision is ready for approval when the object, owner, baseline, permitted action and outcome evidence are explicit; the reference object in this article is master data and classifications.

Applied analysis: Data quality governance: roles, controls and correction

“Data quality governance: roles, controls and correction” becomes manageable once one end-to-end scenario is selected. It starts with measures and thresholds, passes through an accountable decision and ends with evidence for master data and classifications.

Use “errors are corrected only manually” as the scenario input and “define checks and corrections” as the testable response. Preserve the source, time and data version in the record.

Review the risk “one data mart without shared meaning” before expanding scope. If the control fails in the first cycle, postpone scaling and refine the data, authority or decision boundary.

• Working object: Measures and thresholds.
• Diagnostic signal: Errors are corrected only manually.
• Response action: Define checks and corrections.
• Controlled risk: One data mart without shared meaning.

What belongs in scope

Describe the boundary through object records rather than system names. For measures and thresholds, record meaning, identifier, source, quality owner and update event; for errors, corrections and the quality log, also document the relationship rule.

Test the link between measures and thresholds and errors, corrections and the quality log using an end-to-end example. The team performs “identify key objects”, traces transformations and identifies where a discrepancy arises, who corrects it and which dependent outputs are recalculated.

• Subject area 1: Master data and classifications. Verification basis: system of record, owner authority and the signal “a dashboard does not lead to action”.
• Record 2. Object: Sources and transformations. Required details: identifier, lineage, quality rule and update event. Signal: Errors are corrected only manually.
• Control record 3. Object: Data marts and semantic models. Observable signal: One measure has multiple values. Accountability: semantic owner and quality owner.

Record lineage

Describe data exchange as a contract between owners. For errors, corrections and the quality log, specify the triggering event, system of record, mandatory fields, pre-transfer control and the recipient's response to an error.

Choose the transport mechanism after frequency and resilience requirements are known. Check “errors are corrected only manually” on both sides of the interface to distinguish a source error from transformation, delivery or loading failure.

• Object 5: Errors, corrections and the quality log. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Master data changes without an owner.
• Boundary 4. Object: Measures and thresholds. Define the source, frequency, permitted transformations and response to “users cannot see where a number came from”.
• Control record 3. Object: Data marts and semantic models. Observable signal: One measure has multiple values. Accountability: semantic owner and quality owner.

The decision point to resolve

The article addresses “Data quality governance: roles, controls and correction”. The adjacent management issue is roles, controls and correction. The two may share data or participants while differing in decision horizon, role authority and architecture boundary, so they are documented as separate entries in the decision map.

A signal–risk–action chain defines the subject-specific focus. Here the signal is “users cannot see where a number came from”, the material risk is “one data mart without shared meaning”, and the testable action is “identify key objects”. This chain turns a broad term into a concrete decision.

• Decision 1: object — master data and classifications; signal — a dashboard does not lead to action; action — define checks and corrections.
• Decision 2: object — sources and transformations; signal — errors are corrected only manually; action — maintain lineage and versions.
• Decision 3: object — data marts and semantic models; signal — one measure has multiple values; action — identify key objects.

Quality and correction rules

For errors, corrections and the quality log, the sequence begins with “define checks and corrections”. The owner of the next step reviews its output; an incomplete result is returned with a specific issue concerning data, a rule, authority or an architecture dependency.

Maintain an assumptions log for errors, corrections and the quality log. Each entry states its basis, owner, review date and the event after which it must be confirmed, changed or closed.

• At position 1, the action is “identify key objects”; its result is measures and thresholds.
• Stage 2: assign systems of record. The working artefact describes errors, corrections and the quality log.
• Stage gate 3 connects the action “align identifiers and master data” with the result “master data and classifications”.
• 4. Action: define checks and corrections; verifiable result: sources and transformations.

Starting situation and evidence

The work starts with an observable situation, not with interface selection. The diagnostic signal for this article is: errors are corrected only manually. It should be supported by a real example such as a document, data sample, decision record or registered variance.

The first scope is limited to one object and one decision. Changing every process, master-data set and system at once obscures causality. For the signal “users cannot see where a number came from”, a representative boundary is a period, business unit or transaction class where the situation can be tested again.

• Management signal 1: One measure has multiple values. Use condition: a link to an actual example and to measures and thresholds.
• Diagnosis records “users cannot see where a number came from”, its recurrence and its impact on errors, corrections and the quality log.
• Observation 3: Master data changes without an owner. Required fields: frequency, source and consequence for master data and classifications.

Process and data owners

For master data and classifications, the role model determines more than screen access. In the action “define checks and corrections”, it identifies who changes a rule, authorises an exception, accepts risk and confirms the outcome. The accountability matrix is tied to decisions and artefacts rather than abstract departmental participation.

A business–IT disagreement is resolved by the decision owner using agreed evidence. The architect does not replace the business owner, and the project manager does not define the meaning of a measure. For master data and classifications, this separation is especially important because of the risk “self-service without a metric catalogue”.

• Role: Business owner. Decision object: measures and thresholds; verified step: maintain lineage and versions.
• Architect decides within errors, corrections and the quality log; the basis is prepared through “identify key objects”.
• For master data and classifications, the assigned role is Data owner; its control duty is to assign systems of record.
• Project manager: authority is linked to sources and transformations, and participation is tied to “align identifiers and master data”.

Baseline and actual outcome

Verification of master data and classifications starts with the baseline. The sample, period, calculation rule, known exceptions and interpretation owner are preserved. After the change, the same scenario is repeated under comparable conditions; a new method or data population is documented as a separate version.

A functioning feature is not yet acceptance evidence. A user must receive the signal “errors are corrected only manually” from the agreed source, understand its lineage, make an authorised decision, execute the action through the working environment and observe confirmed actuals for measures and thresholds.

• Control record 1: Master data and classifications; data version, calculation rule, expected change and actual outcome. Signal: One measure has multiple values.
• Criterion 2 uses sources and transformations; the result is compared with the baseline using one method. Signal: Users cannot see where a number came from.
• Criterion 3: Data marts and semantic models; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: Master data changes without an owner.
• Criterion 4. Object: Measures and thresholds. Test fields: baseline, target change, source and owner. Signal: A dashboard does not lead to action.

Assumptions, stop signals and rollback

For the risk “one data mart without shared meaning”, define an observable condition and control decision. The record also includes the owner, response time, execution evidence and rollback rule if the control fails.

An assumption concerning errors, corrections and the quality log remains valid only until its review event. If the source, scope or accountable role changes, update the decision boundary and repeat the affected test.

• For the risk “one data mart without shared meaning”, assign the action “define checks and corrections” and evidence “master data and classifications” in advance.
• Risk review starts with the condition “measuring quality without a correction process”. The decision uses the action “maintain lineage and versions” and data about sources and transformations.
• Risk record 3. Condition: Self-service without a metric catalogue. Control action: Identify key objects. Evidence source: Data marts and semantic models.
• Risk: Treating an anomaly as a proven fact. Control: assign systems of record. Evidence: measures and thresholds.

Initial working cycle

The first session examines one real case involving measures and thresholds. Participants bring a source document or sample, data-flow diagram, current procedure and an example of “errors are corrected only manually”.

The session ends with a decision on the next format rather than a wish list. Assign an owner and due date to “define checks and corrections”; assign an additional test or stop condition to the risk “self-service without a metric catalogue”.

• At position 1, the action is “identify key objects”; its result is measures and thresholds.
• Stage 2: assign systems of record. The working artefact describes errors, corrections and the quality log.
• Criterion 4. Object: Measures and thresholds. Test fields: baseline, target change, source and owner. Signal: A dashboard does not lead to action.
• 5. Acceptance object: errors, corrections and the quality log; compare the baseline sample, expected change and confirmed actuals. Test signal: Errors are corrected only manually.