Master Data Management

The problem is old and unglamorous: the same customer exists in the CRM, the billing system, the support desk and three acquired platforms, with different identifiers, different spellings and partly contradictory attributes. Every cross-system question — total exposure to this customer, consolidated spend, which entities are related — is unanswerable without resolving that.

The hard technical core is entity resolution: deciding that these records refer to the same real-world thing, using deterministic rules where identifiers exist and probabilistic matching where they do not. Probabilistic matching has two error modes with very different consequences — over-merging combines two real customers, which is a privacy incident and can expose one person's data to another; under-merging leaves duplicates, which is merely inefficient. The threshold is a risk decision, not a tuning parameter, and it should be set with that framing.

Three implementation styles: a registry that maps identifiers without moving data, the least invasive; a consolidation hub that builds golden records for analytics only; and a centralised model where the hub becomes the system of record and sources subscribe, which is the most valuable and the most disruptive.

The reason MDM programmes fail is almost never the matching engine. It is that they are run as technology projects when the actual work is agreeing ownership and survivorship rules — which system wins when two disagree — across business units that have never had to agree before.