What are the five data-quality dimensions?

Completeness (required values present), validity (values in the allowed range or format), conformity (values match the target's lists and structures), consistency (values agree across fields, objects and systems), uniqueness (no duplicates). A scorecard shows each per object; the readiness score rolls them up.

The business owner of the object, in the source system. In a data-quality project the data is corrected at source, never in the tool, then re-validated; the scorecard updates. Only in a migration project may a correction be made in the workbench when that is the faster path.

How is the score different from an SAP-side check?

SAP checks whether it will accept a record at load time. The readiness score runs weeks earlier, on the rules your business defines — including cross-object and policy rules SAP does not know — and is readable by a steering committee, not only by a developer.

What is a good score?

The threshold is set per programme: a cleansing target such as 95% valid records per object before data sign-off is common. The score matters less than its trend and the list of top offending rules behind it.

Data quality before SAP go-live: the readiness score

A data readiness score is a single, weekly-published measure per site and programme — the share of records that pass the validation rules the business has agreed on — built from five data-quality dimensions (completeness, validity, conformity, consistency, uniqueness) applied per SAP object. It replaces fragmented Excel trackers with one answer to 'are we ready?', tells business owners exactly what to fix (in the source system), and shows the trend since the baseline.

Updated 3 November 2026 · Visehub

The problem the score solves

Close to go-live, leadership asks one question: are we ready? The true answer is usually fragmented across Excel files, SharePoint trackers, workstream calls and status decks. Each country keeps its own list of known issues. Nobody can say how ready the vendor master is, so the go-live date is a feeling.

A readiness score replaces the trackers with one measured number per site and per programme, published every week, with the trend since the baseline and the top reasons it is not higher.

How it is built

Rules per object. Every object in scope — vendor, customer, material, open items, cost centres — gets a library of validation rules: format, list-of-values, conditional, custom, aggregate. Each rule has a severity, a scope (which sites, which programme), documentation in plain words and a named owner. The rules are code — versioned, tested in a sandbox, run on every record of every extract — not a checklist.

Five dimensions per object. Results roll up into a scorecard: completeness, validity, conformity, consistency, uniqueness. The scorecard says where quality is weak; the rules say why.

One score per site and programme. The share of records passing the agreed rules, with the cleansing target (e.g. 95% valid before data sign-off), the delta versus last week and the next milestone. This is the number the steering committee gets.

Top offending rules. The rules with the most errors, their six-week trend and the owner next to each one — so the effort goes where it moves the number.

Who does what

Business data owners work a correction queue: errors by object and rule, with the reason in plain words. They fix the records in the source system — in a data-quality project, always at source, never in the tool — and the object is re-validated. Programme managers send the weekly summary: who improved, what regressed, what is due. Architects maintain the rule library. Nobody manages a spreadsheet.

What it looks like in production

Our longest-standing customer, a global brewing group, has run vise DMW as the readiness gate in front of every SAP rollout wave since 2017, with BODS doing the load. An energy-infrastructure operator chose the same approach in a public data-quality tender, ahead of two global DQ vendors, without a migration attached. The same scorecard also underpins test data readiness: checking that the data every end-to-end test needs exists and is consistent before the cycle starts.

Start

A 30-day proof of concept on one object produces the first scorecard, the top offending rules and a correction process you can keep.

Frequently asked

What are the five data-quality dimensions?: Completeness (required values present), validity (values in the allowed range or format), conformity (values match the target's lists and structures), consistency (values agree across fields, objects and systems), uniqueness (no duplicates). A scorecard shows each per object; the readiness score rolls them up.
Who fixes the data?: The business owner of the object, in the source system. In a data-quality project the data is corrected at source, never in the tool, then re-validated; the scorecard updates. Only in a migration project may a correction be made in the workbench when that is the faster path.
How is the score different from an SAP-side check?: SAP checks whether it will accept a record at load time. The readiness score runs weeks earlier, on the rules your business defines — including cross-object and policy rules SAP does not know — and is readable by a steering committee, not only by a developer.
What is a good score?: The threshold is set per programme: a cleansing target such as 95% valid records per object before data sign-off is common. The score matters less than its trend and the list of top offending rules behind it.