The context
A DMS is only as good as its master data: distributors, shops, products, salesmen, geographies and price lists. On my last rollout I prepared and reconciled master data for two markets before deployment.
Most of that work is checking for the same kinds of problems again and again. This concept automates those checks, so people deal only with the rows that need fixing.
The problem
Data problems are found late, when they are most expensive to fix:
- Master data arrives in different spreadsheet formats.
- Thousands of rows are checked by eye.
- Duplicates, missing tax IDs and wrong mappings show up in testing or after go-live.
- Every reload means retesting.
What I did
- Listed the checks I ran by hand while preparing master data for my rollout.
- Designed standard templates and automated readiness checks.
- Defined which problems block a load and which only raise a warning.
- Wrote the check rules as a sample for a build team.
The process, before and after
Each column is a team or system. Numbered badges point to where time is lost today, and how the design saves it.
Scroll sideways to see the whole diagram →
- 1Thousands of shop, product and price rows are checked by eye.
- 2Duplicates, missing tax IDs and wrong mappings surface in testing, or after go-live.
Scroll sideways to see the whole diagram →
- 1One template per data type, with required fields and allowed values.
- 2Checks catch duplicates, missing tax IDs, invalid geographies and missing prices.
- 3Distributors fix only the flagged rows, which are checked again.
What changed, step by step
| Step | Before | After |
|---|---|---|
| Data format | Different sheets from each distributor | One template per data type |
| Checking | By eye | Automated checks on every file |
| Problems found | In testing or after go-live | Before loading |
| Fixes | Whole file sent again | Only flagged rows fixed |
The approach
- 1One template per data typeFixed columns, required fields and allowed values for each data type.
- 2Check every file automaticallyReadiness checks run on every upload and list every problem found.
- 3Send back only what's wrongFlagged rows go back to the distributor with the reason, so they fix just those rows.
- 4Separate blockers from warningsA missing tax ID blocks a load. A missing phone number only raises a warning.
- 5Approve, then loadThe data team approves each file before it is loaded into the DMS.
Sample work: readiness check rules
| Check | Data type | Example problem | Action |
|---|---|---|---|
| Duplicate | Shop | Same shop listed twice with different spellings | Block: merge before loading |
| Missing tax ID | Distributor | Tax registration number is blank | Block: needed for invoicing |
| Invalid geography | Shop | Town is not in the agreed geography list | Block: fix the mapping |
| Missing price | Product | No price for the shop's channel | Block: add the price |
| Missing phone | Salesman | No mobile number | Warn: needed for the app |
Illustrative rules written for this portfolio.
Expected outcomes
- Fewer data defects in UAT and after go-live.
- Distributors fix only what's wrong, not whole files.
- Faster, more predictable data loads before each go-live.
- A reusable checklist for the next market.
Design principles
- Agree the template before collecting any data.
- Separate blockers from warnings, or everything becomes urgent.
- Master data needs a business owner, not just an IT one.
Concept case study written during my 2026 sabbatical. It is not a deployed client solution. Examples are generic.
Next case study · CS-01Rolling out one DMS across two markets in a year