Master Data Management for Assets: Building a Golden Record

Most master data management (MDM) writing is about customers and products. Deduplicate the customer, pick the best address, one golden record per person. The method transfers cleanly to physical assets, but nobody explains it that way, so asset teams end up reinventing it badly. This is how I build a golden record for a pump, a chiller, or an air handling unit, and the survivorship rules that decide which system wins for each field.

What the asset golden record is

A golden record is the single, trusted version of one asset, assembled from every system that holds a piece of the truth. No single source has all of it, and several sources disagree. The golden record is the reconciled result that everyone downstream reads from.

For a physical asset I define the record around a fixed set of attributes. These are the fields that decide whether maintenance, finance, and reporting are all talking about the same piece of equipment:

• Identity: a stable internal asset number that never changes, independent of any source system key
• Taxonomy class: what kind of thing this is, from a controlled classification (chiller, AHU, pump), not free text
• Criticality: the operational importance rating that drives maintenance priority
• Parent: the asset it hangs off, so the hierarchy holds together
• Location: site, building, floor, room, or functional position
• Manufacturer, model, serial: the nameplate identity of the physical unit
• Install date: when it went into service, which anchors age and lifecycle
• Warranty: the coverage end date and terms
• Cost centre: who pays for it, which ties the asset to finance

Two of these lean on their own bodies of work. Getting the parent right is a whole discipline in itself, which I cover in asset hierarchy design. Criticality deserves its own rating method rather than a gut number, which I walk through in asset criticality classification. The golden record consumes both as attributes; it does not try to reinvent them.

Survivorship rules: which source wins

Survivorship is the heart of MDM. When three systems each hold a value for the same field, survivorship decides which one becomes the golden value. The naive approach is "most recently updated wins," and it is wrong for assets, because the system that updates most often is rarely the system that is most correct.

Instead I rank sources per attribute. The rule is trust based, not recency based: the manufacturer and serial come off the nameplate captured at construction handover, the cost centre is owned by ERP, the maintenance-facing fields are owned by the CMMS. A source only wins for the fields it is genuinely authoritative on.

Attributes against candidate sources, with trust ranking:

The abbreviations: ERP is the finance and procurement system, CMMS is the maintenance system, BMS is the building management system, GIS is the spatial system, and construction handover is the commissioning data pack the contractor delivers at the end of a build. Notice that no single system wins across the board. That is the whole idea. Write this table down for your own estate before you write a line of matching logic, because it is the contract every downstream report depends on.

A worked matching and merge example

Survivorship tells you which field wins once you know two records are the same asset. Matching is the harder problem: deciding that they are the same asset in the first place. Here is a real pattern I see constantly.

Three sites each commission an identical chiller and each enters it into the CMMS in their own style. You end up with three records that a human recognises as one model but a database sees as three unrelated rows:

Same physical model, three spellings of the manufacturer, three formats of the model, one serial mistyped (a trailing 5 read as S), one serial missing entirely. This is normal, not exceptional. My match logic runs in tiers:

• Rule 1, serial exact: if two records share a normalised serial exactly, they are the same unit. Confidence is high, auto-merge. Here Site A and Site B nearly match but the S/5 typo defeats an exact test, so they do not auto-merge on this rule.
• Rule 2, manufacturer plus model fuzzy: normalise both (uppercase, strip spaces and punctuation, apply a manufacturer synonym list so "Carrier Corp" and "Carier" both resolve to "Carrier") then fuzzy compare. All three rows collapse to Carrier / 30XA1002. This is a strong candidate, but manufacturer plus model identifies a model, not a unit, so it cannot auto-merge on its own.
• Rule 3, location proximity: if fuzzy model matches and the two records sit in different buildings, they are almost certainly different physical units of the same model. If they sit in the same functional position, they are probably the same unit entered twice.

Combining the rules: Site A and Site B are in different buildings, so they are two real chillers of the same model, kept separate but linked to one shared model definition. Site C has no serial and a fuzzy-only match, so it drops into the stewardship queue for a human to confirm whether it is a genuine third unit or a duplicate of A or B.

Why full automation is a trap

The temptation is always to push the match confidence threshold down until the queue is empty and declare victory. On asset data this fails, and it fails quietly, which is worse.

Serial numbers are mistyped constantly, because they are captured by hand in plant rooms with poor light and gloves on. A single character wrong turns an exact match into a miss, or worse, a false match against a different unit. Manufacturer names have a dozen spellings each: Carrier, Carrier Corp, Carrier Corporation, Carier, CARRIER, and the local reseller's name typed in by mistake. Model formats vary by whoever entered them. Fuzzy logic can absorb a lot of this, but the moment you tune it aggressive enough to catch every real duplicate, it also starts merging distinct units, and a wrong merge is far harder to unpick than a missed one.

The operating model: steward, time, metric

MDM is not a project you finish, it is a function you run. The technology is the easy half. The operating model is what keeps the golden record golden after go-live, and it comes down to three questions.

Who is the data steward?

A named person, not a committee and not "the system." For asset data the right steward usually sits in maintenance or asset management, someone who understands equipment well enough to tell a genuine third chiller from a duplicate, and who has the standing to ask a site to fix its entries. This is a role, not a job title; often it is 20 to 30 percent of one experienced person's week rather than a dedicated hire.

How much time does it take?

During the initial cleanse the queue is large and it can be a full-time effort for a few weeks. Once the backlog clears, steady state on a mid-size estate is typically a few hours a week: clearing the ambiguous matches the rules could not settle, and spot-checking new records at handover. If it is taking a whole week every week after go-live, the match rules are tuned too loose and are flooding the queue.

How do you prove value?

With one metric tracked over time: the duplicate rate, the percentage of active asset records the matching engine flags as suspected duplicates. Baseline it before you start, then plot it monthly. A programme that is working shows a sharp drop during the cleanse and then a low, flat line as new duplicates get caught at entry instead of accumulating. That single trend line is the clearest evidence to a sponsor that the stewardship spend is buying something real. It is also the leading indicator I watch when scoping the cost of a wider platform, which I break down in what an operational data platform costs.

Where the standards fit

None of this is invented from scratch. The discipline of survivorship, stewardship, and golden records is documented formally, and it is worth reading the canonical sources rather than a vendor's interpretation of them.

• The DAMA International DMBOK is the reference framework for data management, and its MDM and data quality chapters are what I map asset work onto.
• ISO 8000 is the data quality standard that gives you defensible definitions of accuracy and completeness to hold sources against.

Conclusion

Master data management for assets is the same discipline as MDM for customers, pointed at pumps instead of people. Define the golden record around a fixed set of attributes, decide per field which source is allowed to win, match in tiers from serial to fuzzy model to location, and route the ambiguous cases to a named steward instead of pretending automation can resolve them. Track the duplicate rate over time and you will have both a clean asset register and the evidence to prove it was worth the effort.