MDM · Master Data Management
Master Data Management
What is MDM?
- Managing the single source of truth for reference data shared across systems
- Handle it separately from transaction data
- The rules for creating and changing records matter more than the technology
The first thing that changes at a company that takes on MDM is the feel of its meetings. The 30 minutes once spent arguing "which system is the source?" whenever numbers differed are gone, and the debate shifts from the numbers to the decisions. Technically, the work is merging records scattered across systems into one master record and linking the rest beneath it. For the organization, though, it is closer to building a process for agreeing on which values count as the company’s official answer. That is why more than half of this work happens not in the database but in the meeting room.
Master data should be handled separately from reference data. Reference data is values taken as is from external standards, such as country or currency codes. Master data covers things only your company can define, such as vendors, products and employees. There is also more than one way to run it: a registry style that leaves existing systems alone and manages only the links between them, a hub style that keeps the golden record in a separate hub and pushes it out to each system, and a centralized style that designates one ERP as the source. For mid-sized companies, using the ERP as the source is the most realistic.
Success hinges on whether you have defined your metrics. Tracking just three each month is enough to manage it: the number of suspected duplicates, the rate of missing required fields such as business registration number, and how long a new registration request takes to process. Make an exact match on business registration number your top-priority matching rule, and send records with similar company names or addresses to a second-tier candidate list for manual review. Pushing the automatic merge rate too high leads to mistakes where a head office and its branches, or separate legal entities, get merged into one record.
The most common mistake in practice is treating MDM as a "one-time big cleanup." Even if you install a solution and clean up duplicates, unless you also fix registration permissions and naming rules, a rushed salesperson will create a new code again, and within six months things are back where they started. An even riskier misconception is resolving duplicates by deleting them. If you delete the code of a closed vendor, the past tax invoices and vouchers issued under that code lose their reference, and closing figures no longer add up. Duplicates should be linked to a master code and marked with a status value, not deleted, and the merge history must be kept so it can be reversed.
Jaryong KooMarketing PhD and leading authority on AI, data analytics, and personal branding
Seungtae ParkAX practitioner who builds AI business development and marketing automation tools and teaches from that hands-on experienceAs companies added more systems, the same entity increasingly ended up registered differently in each one, and in the 2000s the approach of managing reference data in one place took shape. Through the spread of ERP and CRM and a wave of data integration projects, it became a core area of data governance.
This is a hypothetical case of Company A, an industrial parts distributor with 240 employees and annual revenue of KRW 180 billion (≈ US$134,670,100). Customer records scattered across its ERP, CRM and logistics systems totaled 31,000, yet it was suspected that only about 10,000 were actual trading entities. Every month-end, two receivables staff spent two days reconciling them in Excel.
- At a management meeting, the finance team lead raised the problem: "Receivables for the same vendor were split across three places, and we sent a collection notice to a vendor that had already paid." The meeting concluded that the vendor master should be fixed first.
- When the IT team downloaded 31,000 vendor records from three systems and ran a first-pass match on exact business registration numbers, the actual number of legal entities came down to 10,800, leaving 2,300 suspected duplicates for review.
- The 4,100 records missing business registration numbers were filled in over three weeks by two assistant managers on the sales support team, using National Tax Service lookups. The 620 that could not be verified were not deleted but kept with a 'pending verification' status.
- So that past vouchers would not break during the merge, they chose to link old codes to the master code instead of deleting them, and set a team rule: "No deletions. Only change the status."
- Once permission to register new vendors was limited to three sales support staff and saving was blocked without a business registration number, registration requests were handled in about 4 hours on average.
- Six months later, suspected duplicates fell from 2,300 to 90, and the two days spent on month-end receivables reconciliation shrank to half a day, freeing one staff member to move to credit review.