Most companies do not go looking for enterprise data management services because they woke up interested in data governance. They go looking because two reports disagree, because the same customer exists four times in three systems, or because a migration is coming and nobody trusts what is in the old database. The problem is real. The proposals that come back are often vague.
This is a plain guide to what should be in scope, what the first three months should look like, and how to tell a serious provider from one selling a licence.
What enterprise data management services actually cover
Enterprise data management is the whole working life of your business data: where it enters, how it is validated, who owns it, how it moves between systems, how long you keep it, and what you can safely report from it. Master data management is one part of that, covering the core records such as customers, products, vendors and locations. We set out the distinction in EDM vs MDM, and the broader picture in what enterprise data management means in practice.
A provider selling you "EDM" should be able to say, in one page, which of the following they are doing and which they are not.
The eight things a provider should deliver
1. A data audit you can read
Before anyone designs anything, someone has to open the systems and count. How many customer records, how many duplicates, how many rows with a missing country, how many products with two part numbers. A good audit is a short document with numbers in it, not a slide about data maturity. If a provider quotes without doing this, they are guessing, and you will pay for the guess later as a change request.
2. A golden record definition
For every core record type you need one agreed answer to a simple question: when two systems disagree, which one wins, and on which field? Sales might own the contact details while finance owns the billing name. Written down, this takes an afternoon. Left unwritten, it becomes six months of argument.
3. Rules at the point of entry
Cleaning data once is housekeeping. Stopping it from getting dirty again is the project. That means validation in the forms and imports themselves: required fields, format checks, duplicate detection at the moment of saving, and controlled dropdown lists instead of free text where a list will do. Any provider who plans a big cleanup without changing how records are created is selling you the same job again in two years.
4. Migration and cleansing with a rollback
Migration is where these projects go wrong publicly. You need a mapping document, a dry run against a copy, a reconciliation count on both sides, and a way back if the numbers do not match. Our data migration checklist covers the steps we run on every project, including the ones people skip.
5. An integration layer, not a set of exports
If your CRM, accounting system and website each hold their own copy of a customer, something has to keep them in step. That is usually an API layer or a scheduled sync with conflict rules and an error log a human actually reads. Spreadsheet exports passed between teams are not integration; they are a delay with a filename.
6. Ownership and access that match your org chart
Governance sounds heavy for a company of forty people, and the enterprise version of it is. The useful version is short: who may create a record, who may approve a change to a price or a credit limit, who may delete, and who gets told when any of that happens. Role-based permissions and an audit trail deliver most of the value of a governance programme without the committee.
7. Reporting people trust
The test of the whole exercise is whether a manager can open a dashboard on Monday and act on it without checking the number against their own spreadsheet. That means agreed definitions for the handful of measures that matter, calculated in one place, with the source visible.
8. Support after go-live
Data systems drift. New products, new territories, a new finance package. Ask what happens in month four: who monitors the sync errors, how quickly a broken import is fixed, and what a change costs. A maintenance plan with named hours is a better sign than an open-ended promise of support.
What the first 90 days should look like
A realistic first phase is narrow and finishes. Something like this:
Weeks 1 to 3: audit of the systems in scope, interviews with the people who create and use the records, a written findings document with counts.
Weeks 4 to 6: golden record design for one record type, usually customers or products. Validation rules agreed. Integration points listed.
Weeks 7 to 11: build, dry-run migration against a copy, reconciliation, corrections, user testing with the actual team.
Week 12: go-live for that record type, with the old system readable but read-only for a defined period.
One record type, done properly, beats a platform that covers everything and is trusted by nobody. Widen once the first one is stable.
How the work is priced
Three models are common, and the right one depends on how well you can describe the job today.
Fixed price suits a defined phase, such as the 90 days above. You approve a scope and a number. Changes are quoted separately. This is the safest way to buy a first phase, and it is how we quote most EDM work.
Time and materials suits discovery work where the answer genuinely is not known yet, such as an audit of a messy estate. Cap it and keep it short.
Dedicated team suits ongoing product work after the first phases, where priorities shift monthly.
Whatever the model, ask every vendor the same question in writing: does the price include testing, data migration, deployment, documentation and training? The cheap quote is usually not cheaper, it is smaller.
Questions to ask before you sign
- Show me two systems you have built that handle the record types I have. Can I speak to one of those clients?
- Who writes the code, and will I meet them?
- What is your rollback plan if migration reconciliation fails?
- Do we own the source code, the designs and the data outright once paid?
- If we are in the UK or EU, what data processing agreement and transfer clauses apply?
- What does the handover pack contain, and who holds the hosting accounts?
- What is the cost of a typical change in year two?
The answers matter less than whether they come quickly and specifically. A provider who has done this before will not need a week to answer any of them.
Mistakes that cost the most
Buying a platform before agreeing the rules. Software does not decide which system wins a field dispute. People do, and then the software enforces it.
Cleaning without fixing entry. Covered above, and still the most common way money disappears.
Migrating everything. Ten years of dead records slow every query and hide the data you need. Archive rather than migrate, and say so in the plan.
Choosing an enterprise suite for a mid-sized business. Large suites are designed for organisations with a data office. For a company of twenty to three hundred people, a tailored platform built around your actual records is normally faster to adopt, cheaper to own and easier to change.
Where to start
Pick the record type that causes the most arguments. Count the damage: duplicates, hours spent reconciling, decisions delayed. Then scope one phase against that number. If the phase cannot pay for itself inside two years on that evidence alone, it is the wrong first phase.
We build enterprise data management platforms for companies in the UK, Europe, the USA and Asia, starting with a short discovery phase and a fixed quote, so the number you approve is the number you pay. If you want a second opinion on a proposal already on your desk, send it over.