Make business data reliability easier to navigate.
Explore business data reliability, with practical workflows, a working example and checks for common mistakes.
Explore the guide ↗Data Quality Workshop is a focused resource for data owners and analysts, exploring business data reliability through the work people actually need to perform. For this topic, the workflow is to define useful quality rules, inspect representative records, and fix causes at the source. This guide uses a data quality issue register to hold the decisions together and examines record identity, field completeness and correction ownership as distinct quality concerns.
The example involves an analyst finding different spellings for the same customer; it is an illustrative exercise for this subject, rather than a reported client result. A data quality rule should reflect the task that uses the field. Missing, inconsistent and duplicate information are different problems; fixing a report cannot correct the upstream process that keeps producing them.
Explore the essentials
TECHNOLOGY / 10 SECTIONSThe purpose of business data reliability
Start by describing the task that makes business data reliability relevant now. Use the situation of an analyst finding different spellings for the same customer to identify the practical question before choosing a method. A concern involving record identity may require different evidence from a concern involving field completeness.
Keep those questions visible in a data quality issue register, alongside the intended outcome. The scope of business data reliability becomes easier to discuss when an agreed requirement is clearly distinguished from an idea that still needs investigation. Before proceeding with business data reliability, decide whether the current state of correction ownership creates a dependency that needs another person's input.
Use a data quality issue register as a shared reference for this piece of business data reliability. The record is especially useful when data owners and analysts need to explain why a particular route was chosen. Connect the entry about record identity to the relevant evidence for business data reliability, rather than copying information without its source context.
Review a data quality issue register after a meaningful change; an abandoned reference can mislead the next person working on business data reliability.
Define useful quality rules
The first working stage is to define useful quality rules. In the example involving an analyst finding different spellings for the same customer, identify which input is needed before this action can produce a dependable result. Consider how questions about record identity affect the starting conditions for the action to define useful quality rules, including information that has not been confirmed.
Record the outcome in a data quality issue register and explain any limitation before asking somebody to inspect representative records. This creates a traceable starting point for business data reliability, making an incomplete input easier to recognise before it influences the rest of the work.
Inspect representative records
Continue by deciding how to inspect representative records under the agreed conditions. The handoff from the first stage of business data reliability should contain the information this action actually requires. Before you inspect representative records, inspect field completeness and identify any assumption that has become doubtful.
If the situation involving an analyst finding different spellings for the same customer reveals a different requirement, update a data quality issue register before expanding the work. A visible change decision keeps business data reliability coherent and helps the next participant understand whether the original scope still applies.
Fix causes at the source
The third stage is to fix causes at the source, bringing the current piece of business data reliability to an understandable state. Check correction ownership against the agreed purpose of business data reliability, not merely against a list of completed activities. Use a data quality issue register to identify follow-up responsibilities and relevant limits.
In the example of an analyst finding different spellings for the same customer, ask what the receiving person would need before relying on the output. Closing this stage of business data reliability clearly prevents an unfinished dependency from being mistaken for an accepted result.
Avoid cleaning reports while leaving the source process unchanged
06 / 10A specific failure pattern in business data reliability is cleaning reports while leaving the source process unchanged. It can create a gap between the appearance of progress and the actual outcome needed by data owners and analysts. Check whether record identity was understood before the action began and whether field completeness was examined by somebody with the relevant context.
Capture the correction in a data quality issue register, including its effect on correction ownership. The aim is to reduce the opportunity for cleaning reports while leaving the source process unchanged to recur, while keeping the process proportionate to the work.
Work through a realistic situation
Consider an analyst finding different spellings for the same customer as a small rehearsal of business data reliability. Write down the request and expected result, then identify who performs the action to define useful quality rules. Before moving to the instruction to inspect representative records, ask which information the next participant needs.
Use a data quality issue register to preserve any question the example exposes, especially where record identity is uncertain. Then decide how to fix causes at the source without hiding a concern about correction ownership.
The review criteria for this guide are record identity, field completeness and correction ownership. Examine each criterion separately in the context of business data reliability, because a positive finding in one area does not settle the other questions. For data owners and analysts, a useful review records what was examined and how the finding affects the next action.
Connect the evidence to a data quality issue register, including any limitation in the material available. In the situation involving an analyst finding different spellings for the same customer, identify which finding would prevent a responsible handover. This approach makes the review of business data reliability explainable, rather than treating an unexplained approval label as evidence that the task is ready.
Maintenance of business data reliability should respond to changes in the task, its inputs and its responsible people. Assign an owner to a data quality issue register and explain which events should trigger another review. A changed assumption about record identity may affect the earlier decision to define useful quality rules; a concern about correction ownership may require a new closing check.
Remove obsolete directions from a data quality issue register deliberately so that earlier versions do not compete with approved guidance. When field completeness changes, explain whether the instruction to inspect representative records needs different inputs or a revised decision.
Begin with one bounded task involving business data reliability rather than a complete redesign of the surrounding operation. Prepare a data quality issue register, work through the three actions and inspect the result using the criteria for record identity, field completeness and correction ownership. Ask someone from the intended audience of data owners and analysts to identify a point that still needs clarification.
Compare that observation with the example of an analyst finding different spellings for the same customer, then choose a specific change worth testing.