Back to Blog
Data Quality

The Data Quality Maturity Model (+ Self-Assessment)

A data quality maturity model in five stages: unaware, reactive, measured, managed, optimised. How to place yourself honestly, what each stage should do next, and why you cannot skip stages.

Prakash Palani

The short answer. A data quality maturity model describes how organisations typically progress from reactive firefighting to managed, measured quality. A workable version has five stages: unaware, reactive, measured, managed and optimised. Its value is not the label you land on but the diagnosis: knowing which stage you are at tells you what the next sensible step is, rather than attempting a capability two stages ahead of where you stand.

Maturity models can be self-congratulatory nonsense or genuinely useful, depending on whether they change what you do next. This one is written for the second purpose. Here are the stages, how to place yourself honestly, and what each stage should do next.

The five stages

  1. Unaware. Data quality is not discussed as a topic. Problems are treated as isolated incidents. Nobody could say how complete or duplicated the core data is.
  2. Reactive. Quality problems are acknowledged and fixed when they cause pain. Clean-ups happen as projects, usually prompted by an incident or an upcoming system change. The same problems return.
  3. Measured. Quality is profiled and reported. The organisation knows its completeness, duplication and consistency, and can see whether they are improving. Fixing is still largely manual.
  4. Managed. Rules define the standard, ownership is assigned per domain, monitoring is continuous, and prevention at the point of entry reduces incoming errors. Quality is maintained rather than restored.
  5. Optimised. Quality is embedded in processes and automated where possible, standards evolve with the business, and data is trusted enough to support automation and analytics without parallel checking.

Placing yourself honestly

The useful question is not what stage you aspire to. It is what evidence you could produce today.

A quick self-assessment. Can you state your duplicate rate on customer or material master, from evidence rather than impression? If not, you are at stage two at best. Can you show whether completeness improved or declined over the last six months? If not, you are not yet measured. Does every core data domain have a named owner who decides what correct means? If not, you are not managed. Do teams maintain private spreadsheets because they do not trust the system of record? If so, that is a reliable signal you are earlier than you think. These questions are deliberately uncomfortable, because flattering self-placement is the main way maturity models waste time.

What each stage should do next

If you are here Do this next
Unaware Profile one high-impact domain. Visibility is the only thing that changes the conversation.
Reactive Establish a baseline and start measuring, so improvement becomes provable rather than claimed.
Measured Define rules and assign domain ownership, so standards become objective and someone is accountable.
Managed Shift effort from fixing to preventing, with validation at entry and continuous monitoring.
Optimised Extend coverage and keep standards current as the business changes.

You cannot skip stages

A common and expensive mistake is attempting a capability two stages beyond where you stand. Organisations at the reactive stage sometimes buy sophisticated governance tooling, then find it idle because nobody knows which data is worst or who owns it. Measurement has to precede management, because rules without a baseline are guesses about which problems matter, and ownership without evidence gives owners nothing to act on. The sequence is not bureaucratic; it reflects the fact that each stage supplies what the next one needs.

Migration tends to force the issue

An ERP migration is often what moves an organisation up a stage, because a new system holds data to a stricter standard than the old one and the gaps become unignorable. That is an opportunity worth using deliberately: the profiling done for migration readiness is exactly the measurement that stage three requires, and the domain ownership established to make migration decisions is exactly what stage four needs. Programmes that treat this as throwaway project work rebuild the same capability later. Those that keep it emerge from the migration a stage further on.

Maturity is usually uneven

A single organisational score is a simplification, and often a misleading one. In practice maturity varies by domain: finance data may be managed because audit requirements forced it, while supplier or product data sits at reactive because nothing has yet made it urgent. That unevenness is useful information rather than an inconvenience, because it shows where the gap between importance and attention is widest. Assessing by domain rather than organisation-wide also makes the next step more specific: you are not trying to move the company up a stage, you are trying to move one domain, which is a tractable piece of work.

The tooling trap

A recurring pattern worth naming: an organisation decides to take data quality seriously, buys a capable platform, and a year later it is used by two people for one report. The platform was not the problem. What was missing was the stage-appropriate groundwork, knowing which data matters most, who owns it and what good looks like for it. Tooling accelerates a practice that exists; it does not create one. Organisations that get value from their tooling generally did the uncomfortable diagnostic work first, which is exactly what a maturity assessment is for.

What progress actually looks like

Moving up a stage should be visible in evidence, not just in how the organisation describes itself. Going from reactive to measured means you can produce a baseline you could not produce before. Measured to managed means rules exist, owners are named, and monitoring runs without someone remembering to start it. Managed to optimised means prevention is reducing incoming errors and the trend line is improving without a clean-up project behind it. If a stage change cannot be demonstrated with an artefact, it has not happened yet, whatever the self-assessment says. That discipline is what keeps the model honest and stops it becoming a slide.

How deKorvai helps

deKorvai supports the move from reactive to managed, which is where most organisations are stuck. It profiles data automatically to establish the baseline that stage three depends on, applies configurable business and technical rules so standards become objective tests rather than opinions, and reports on real-time scorecards with trend insight so progress is visible. Continuous monitoring keeps quality watched rather than audited once, and lineage and a business glossary support the ownership and shared definitions that characterise stage four. The sequence the platform supports is the same sequence the model describes.

Key takeaways

  • Five stages: unaware, reactive, measured, managed, optimised.
  • Place yourself on evidence, not aspiration; the questions should feel uncomfortable.
  • You cannot skip stages, because each supplies what the next needs.
  • A migration can move you up one, if you keep what it forces you to build.

Frequently asked questions

What is a data quality maturity model?

It describes how organisations typically progress from reactive firefighting to managed, measured quality. A workable version has five stages: unaware, reactive, measured, managed and optimised. Its value is diagnostic, telling you what the next sensible step is.

How do I know what stage we are at?

Ask what evidence you could produce today. Can you state your duplicate rate from evidence? Can you show whether completeness improved over six months? Does each core domain have a named owner? Do teams keep private spreadsheets because they distrust the system?

Can you skip maturity stages?

Not usefully. Measurement has to precede management, because rules without a baseline are guesses about which problems matter, and ownership without evidence gives owners nothing to act on. Buying governance tooling while still reactive tends to leave it idle.

Does an ERP migration affect data quality maturity?

It often forces progress, because a new system validates more strictly and gaps become unignorable. The profiling done for migration readiness is the measurement stage three needs, and the ownership established for migration decisions is what stage four needs.

Ready to transform your data migration?

See how deKorvai can simplify your S/4HANA transformation program.

Book a Demo