How to Fix Fragmented Data Across Departments Without a Two-Year Programme

Finance says you have 400 active customers. Sales says 520. Operations says 460. Every quarter somebody spends three days reconciling the three numbers by hand, produces a fourth number, and everyone agrees to use that one until next quarter, when it happens again.

At some point IT proposes the fix: a master-data management programme, eighteen months, a budget that looks large next to a problem that costs you three days a quarter. You decline, reasonably. And nothing changes, so the three days a quarter continue, along with the decisions nobody quite trusts and the reports that need a caveat.

The assumption buried in that exchange is that the programme is the only serious option, and that declining it means living with the problem. It is not, and it does not. Fragmented data is more often a sequencing problem than a scale problem, and sequencing problems are solved by doing one thing at a time.

What follows is a method we use for exactly this, which we call the entity-first method. Four moves, applied to one business entity at a time, each producing something an operator can see inside a quarter. The last section covers the cases where it genuinely does not apply and the full programme is the right answer.

Why master-data programmes lose their sponsor

These programmes rarely fail because the people running them are wrong about the technical work. They fail because of the shape of the payoff curve.

Cost begins in month one. Value arrives at the end. In between sits a long stretch where the honest answer to “what has it delivered” is a set of artefacts: a canonical data model, a taxonomy, a governance charter, a stewardship RACI. Each is legitimate work. None of them is something a COO can point at in an operating review.

Three things follow from that gap.

It outlives its sponsor’s attention. Eighteen months is longer than most executives stay pointed at any single initiative, and sometimes longer than they stay in the role. The person who approved it on a business case is rarely the person asked to defend its budget in the fourth quarter.

It accumulates opposition faster than wins. A programme that touches every department asks all of them to change at once, which means every department has a reason to object and none of them has yet received a benefit. Opposition compounds early; goodwill arrives late.

It becomes “the data project”. Once an initiative has a name but no visible output, it stops being a business change and becomes a line item people route around. By month twelve the question in the room is no longer how to finish it but how to wind it down without anyone looking bad.

None of this is an argument that master data does not matter. It is an argument about order. The same work, sequenced differently, survives contact with an organisation. That is what the rest of this is.

Pick the entity that costs you most, first

An entity is a thing your business keeps records about: customer, product, supplier, site, employee, order. Fragmentation means two or more systems hold a version and the versions disagree.

The instinct is to start with the entity in the worst state. Resist it. Start with the one whose fragmentation costs the most, which is frequently not the same thing. A badly fragmented entity nobody makes decisions about is an untidiness. A mildly fragmented entity sitting under your pricing decisions is expensive.

Cost is measurable in about a week, and an operations team can do it without IT. Over one month, count three things:

• Reconciliation hours. How long do people spend manually aligning this entity across systems, including the spreadsheet work nobody calls a reconciliation.
• Delayed decisions. How often does a decision wait on someone producing an agreed number.
• Escaped errors. How many times did a customer, supplier or regulator see something wrong because two systems disagreed.

Then pick one. Exactly one.

The discipline that makes this method work is not in the picking. It is in refusing the second. The moment two entities run in parallel you have rebuilt a small programme, with the same sponsor-attention problem, and you will finish neither.

Agreeing a definition before building a pipeline

The technical work of connecting systems is the straightforward part. The definition is where this stalls, and it stalls because everyone assumes it has already been settled.

Ask three departments what a customer is. Finance means the entity that gets billed, which might be a parent company covering nine subsidiaries. Sales means the organisation an opportunity belongs to, which is probably one of those subsidiaries. Support means whoever raised the ticket, which is a person. Each answer is correct for the question that department is actually asking.

So the goal is not to find the right definition and declare the others wrong. That attempt is why these conversations end badly. The goal is one agreed definition, plus a written mapping for each department’s variant, so nobody loses the view they run their week on.

Three things to write down, in a document people can find:

• The definition itself, in a sentence, in business language rather than schema terms.
• What it excludes, which is where the real disagreement surfaces. Prospects, inactive accounts, internal test records, subsidiaries: these are the arguments, and leaving them implicit guarantees they return.
• The mapping, showing how each department’s existing view derives from the agreed definition.

Do this before any pipeline is built. A pipeline constructed ahead of the definition silently encodes whichever department was in the room when it was specified, and it puts the disagreement into production where it is far more expensive to resolve. Getting the sequence right here is also what makes the downstream engineering straightforward, a point covered more fully in our piece on scalable data pipelines.

One owning system per entity, and what that means politically

The rule is simple to state. One system owns the entity. Every other system subscribes to it and does not edit it locally.

Stating it is easy. What makes this the hardest of the four moves is that it is a political decision wearing technical clothing, and both sides lose something real.

The owning team takes on a burden. Their data quality stops being their own concern and becomes everybody’s. Their change process slows down, because changes now ripple. They acquire stakeholders they did not ask for.

The subscribing teams lose autonomy. They can no longer fix a wrong record in their own system on a Tuesday afternoon. They have to raise it with someone else and wait. For a team under operational pressure that is a genuine degradation, and treating it as a trivial adjustment is how you lose their cooperation for the rest of the work.

Name both costs out loud. The version of this conversation that fails is the one where the losses are presented as non-issues, because the people absorbing them know better and will conclude you either do not understand their job or are not being straight with them.

A rule that resolves most arguments: the owning system is the one where the entity is created, not the one holding the cleanest data today. Data quality is a current state and it changes. Creation is a process fact and it is stable. If customers are created in the CRM and enriched in the ERP, the CRM owns the customer even if the ERP currently has better addresses.

This decision is also one only you can make. The reason data ownership sits unresolved for years in most organisations is that it cannot be settled at the level where the disagreement lives. Two department heads with equal standing will not resolve it between themselves, and they should not be expected to. An operations leader deciding it and absorbing the objection is not an overreach; it is the only available mechanism.

Reconciling visibly so trust rebuilds

Suppose you do all of the above. The definition is agreed, the owning system is named, the pipeline works. People will continue using their own numbers.

They are not being obstructive. They stopped trusting the shared number for a reason, usually several reasons accumulated over years, and an announcement that it is fixed now does not reverse that. Trust was lost through evidence and it returns the same way.

So publish a reconciliation. Weekly, one page, visible to everyone involved:

• The variance, as a count and a percentage, between the owning system and each subscriber.
• The top mismatches, named specifically, not summarised as a category.
• Who is resolving them, and what the number was last week.

Expect the first one to look bad. That is the point, and it is worth saying so in advance, because a leader who publishes a poor first number and does not flinch is making a more persuasive argument than any assurance would. A variance you can see is better than a variance you have been arguing about, because it has a trend.

What changes behaviour is the trend. When the gap closes for six consecutive weeks, people begin using the shared number without being asked, because it has become the number that is demonstrably converging rather than the one they were told to use. That is also the moment the entity is finished and you can start the next one.

When you genuinely do need the big programme

This method is not universally correct, and pretending otherwise would waste your time. Five conditions where sequencing one entity at a time will not get traction:

1. Regulatory reporting requiring lineage across the whole estate. If you must evidence where every figure originated, entity-by-entity leaves gaps for a long time, and the gap itself is the exposure.
2. Post-merger integration. Two complete overlapping estates is not fragmentation, it is duplication at every level simultaneously, and it needs a programme.
3. An entity nobody has a claim to own. If no candidate system creates it, the owning-system rule has nothing to resolve and you need to design something new.
4. More than roughly six entities broken at once, with interlocking dependencies. Past that point the sequencing overhead exceeds the benefit, and fixing one entity keeps requiring another.
5. No data team at all. If the real task is building a capability rather than repairing an entity, you are doing organisational design, which is a different piece of work.

If two or more of these describe your situation, the sequenced approach will stall and a proper data strategy and roadmap engagement is the honest answer. The point of the entity-first method is not that programmes are always wrong. It is that most organisations reach for one when they have a sequencing problem, and pay programme prices for it.

Also read

• BI done right: a decision framework for business intelligence at mid-market scale
• Why scalable data pipelines are the backbone of modern enterprises
• Nine reasons enterprise transformation programs stall

The bottom line

The three numbers in the opening are not a technology failure. They are an unresolved decision about what a customer is and who owns the record, left open long enough that everyone built a workaround.

You can resolve that one entity at a time, visibly, inside a quarter, without a programme and without asking the whole organisation to change at once. Pick the entity that costs you most. Agree the definition before anyone builds anything. Name one owning system and say plainly what it costs both sides. Publish the reconciliation and let the trend do the persuading.

Then do the next one. The organisations that get this right are rarely the ones that ran the largest programme. They are the ones that finished something.