When we talk about data quality, we default to a snapshot mindset: pull a sample, run some checks, score the dataset, move on. It is a useful habit, but it treats data quality as a property of a table rather than as the outcome of everything that happened before that table existed. Quality that holds up over time has to be measured where it is actually made: inside the processes that create, transform and move data.

This shift, from checking data to measuring process, changes what we look at, when we look, and what we do with what we find. Below, we set out why the process view matters, what to measure, and how to build it into the way we work rather than bolting it on afterwards.

---

What We Mean by a “Process Perspective”

A process perspective on data quality means we assess quality at each step of the journey a piece of data takes, from capture, through transformation, integration and consumption, rather than only at the point where someone finally queries or reports on it. Every step is an opportunity to introduce an error, and every step is also an opportunity to catch one.

Think of a customer record that starts life in a sign-up form, gets enriched by a third-party address lookup, is deduplicated during a nightly batch job, and finally lands in a reporting warehouse. If we only check quality at the warehouse, we can see that something is wrong, perhaps a spike in missing postcodes, but we cannot see where it went wrong or why. If we measure quality at each stage instead, we can trace the defect back to its source: was it the form validation, the lookup service or the deduplication logic?

There is a second axis worth adding to this picture: a process perspective on data quality is not just about the data a process creates, but also about the data a process needs in order to run. The first looks forward, at whether the record a process hands off is complete, valid and consistent for whoever consumes it next. The second looks inward, at whether the process itself has what it needs, on the attributes it actually depends on, to execute at all. A process can be a clean producer of data and still stall if the inputs it depends on are missing, just as it can run on well-populated inputs and still hand off an inconsistent result.

This inward-looking view earns its keep in a clean-up scenario. Rather than asking the general question of whether “the data” is good, it lets us ask a specific one: which records should we rectify, on which attributes, so that a given process performs better? It also lets us narrow down to where in the process a failure actually originates, and who is introducing it, turning a vague quality complaint into an accountable one. Those are narrower questions than a blanket clean-up effort, and they are usually the ones worth answering first.

That specificity matters because poor data quality is rarely a diffuse, collective failing. The cause is usually narrow, and it can often be traced to a specific point of entry, a particular field, screen or step where the same kind of error keeps getting introduced.

That said, it is tempting to read a specific point of entry as a specific person, but formal root-cause practice in MDM programmes deliberately avoids that leap, and for good reason. Critical data quality (CDQ) frameworks and DQ scorecards look at fields and processes rather than individuals, because pinning a defect on a person is both harder to act on and usually wrong once we dig past the surface. Tracing an issue to a specific entry point still has diagnostic value, but the fix belongs to the field or process that let the error through, not to whoever happened to be entering data that day.

There is a simple test for this: watch the defect rate on a given field as the people entering data rotate. If the cause really were one careless individual, retraining or replacing that person should fix it. In practice, the same defect keeps reappearing across different individuals over time, and the rate on that field typically stays flat regardless of who is at the keyboard, which is strong evidence that the cause lives in the process, not the person.

Picture forty people entering purchasing data, with thirty-five of them mis-keying the same field. The problem is not thirty-five careless people; it is a form with no validation, no mandatory-field logic, or a screen layout that makes the field easy to skip. This is the pattern MDM governance workshops run into again and again: the question “who is entering bad data” almost always traces back to “why does the system let them.”

Data stewardship structures exist for the same reason. MDM programmes invest in domain owners, stewardship councils and governance boards: organisational machinery nobody would build if the fix were simply telling Dave to be more careful. The whole discipline rests on the premise that quality is a property of process design, incentives and system constraints, not individual diligence.

Why Point-in-Time Checks Fall Short

Point-in-time checks answer a narrow question: is the data good right now? They tell us nothing about whether it will still be good next week, or why it degraded in the first place. A few limitations stand out when we rely on them alone.

• They are reactive: by the time a quality issue shows up in a dashboard or report, it has already influenced decisions, customer communications or downstream models.
• They obscure root cause: a quality score on a final table tells us something is wrong, not which upstream process caused it, so we fight the same fire again and again.
• They miss process drift: a source system update that alters a field format can change a process’s behaviour long before the effect surfaces in the data we check.
• They do not scale with complexity: the more layered a pipeline becomes, with more systems, transformations and hand-offs, the more a single end-point check has to cover, until it can no longer catch everything that goes wrong.

A Worked Example: SAP Material Master

Take the SAP Material Master. In S/4HANA, it is organised into around 18 standard views, though not every material uses all of them:

• Basic Data 1 & 2 – general descriptive data (base unit, material group, weight, etc.)
• Classification – characteristics/classes for search and grouping
• Sales: Sales Org Data 1 & 2
• Sales: General/Plant Data
• Foreign Trade Export/Import
• Sales Text
• Purchasing
• Foreign Trade Import
• Purchase Order Text
• MRP 1–4 (often counted as four separate views)
• Forecasting
• Work Scheduling
• Production Resources/Tools
• General Plant Data / Storage 1 & 2
• Warehouse Management 1 & 2
• Quality Management
• Accounting 1 & 2
• Costing 1 & 2

Users only key in what is immediately relevant to the process they are working in, plus whatever has been made mandatory. So, a hazardous material gets its hazard classification attributes filled in, while a material that is never handled as hazardous simply never gets those fields touched. Sparseness like this is not an error; it is the process working as intended.

To make that concrete: the field that carries the hazard classification is MARA-STOFF (the Hazardous Material Number), sitting in the Basic Data view, which links the material to a hazardous substance record in Environment, Health and Safety (EHS). From there, the classification touches several other views: the transportation group and dangerous goods indicator on Sales/Plant Data, the UN number, hazard class and packing group on the EHS or Dangerous Goods view where Product Compliance is active, and storage restrictions by hazard class in Warehouse Management. Sales documents also draw on it to trigger dangerous goods checks and shipping documents such as safety data sheets and labels.

Crucially, the Material Master itself only holds the link. The actual classification and compliance data lives in separate EHS/Product Compliance tables (RCGSTOFF, DGTID/DGTCLASS, CBGLOBALSUBSTANCE), and standard Material Master OData services will not return it. A completeness check run only against the Material Master will see a populated STOFF field and call the record done, without ever confirming that the hazard data behind it actually exists. The field that looks complete is often only a pointer; the data it points to has to be measured on its own terms.

Measure completeness across the material master as a whole and the score looks poor; narrow the view to the attributes “usually” used and it stays poor, because usage still varies by material type and process. Measure it from the perspective of a specific process instead, say procurement or hazardous goods handling, looking only at the attributes that process depends on, and the picture changes: those fields are filled in to a high degree, because the people entering the data needed them to do their job.

That is the process view in practice: a blanket completeness score tells us the data looks sparse; asking “complete for what?” tells us whether it is fit for purpose.

What to Measure at Each Process Stage

A process-level measurement approach follows the data through its lifecycle, asking a different question at each stage.

Capture

At the point of entry, we measure completeness (are required fields populated?), validity (does the value conform to the expected format or range?) and timeliness (was the record captured within the expected window?).

Transformation

During transformation, we measure consistency (do outputs match the logic we expect, and do row counts and aggregates reconcile before and after?) and the rate of records dropped, quarantined or defaulted by the transformation logic.

Integration

Where data from multiple sources is joined or merged, we measure duplication rates, referential integrity (do keys resolve correctly across systems?) and conflict rates, where the same entity carries contradictory values from different sources.

Consumption

At the point of use, we measure fitness for purpose: does the data still answer the question the consumer needs answered, and has anything been lost or distorted in the hand-off to a report, model or downstream application?

Building Measurement into the Process, Not Around It

Knowing what to measure only helps if the measurement is embedded in how we work. A few practices make the difference between a process view that lives in a slide deck and one that actually changes outcomes.

• Instrument the pipeline, not just the destination: add lightweight checks at each hand-off point, source extraction, transformation job, integration step, instead of relying on one check at the warehouse or reporting layer.
• Assign ownership by stage, not just by dataset: when a check fails, it should be obvious which team owns that stage, so the issue reaches the right people without an investigation.
• Track trends, not just thresholds: a metric drifting steadily in one direction, even while still within tolerance, tells us more than any single pass or fail result.
• Feed findings back upstream: a defect caught at the integration stage is a signal to fix the process that introduced it, not just something to clean up downstream.
• Review the metrics themselves: as processes change, the checks that mattered a year ago may no longer be the right ones.

Trending deserves particular emphasis here. We rarely move data quality from bad to good in a single step; improvement is incremental, and the only way to see whether it is actually happening is to watch the trend rather than a single reading. That trend has to carry resolution down to the process level, not just the dataset as a whole. An aggregate quality score can drift upward while one process quietly gets worse, and a process-level trend is the only view that would catch it.

Closing Thoughts

Data quality is not something that happens to a dataset once it lands in a table; it is the cumulative result of every process it passed through to get there. Measure quality at each stage of that journey, not only at the destination, and we catch issues closer to their source, understand why they happened, and build the kind of durable trust in our data that a one-off score never can.

The organisations that get the most value from their data are rarely the ones with the most sophisticated dashboards. They are the ones that have learned to watch their processes as closely as they watch their outcomes.