Asset ManagementMining

Rebuilding asset hierarchies and maintenance master data

Every planning, costing and reliability decision stands on the asset register underneath it. Why hierarchies get rebuilt, how to choose a taxonomy, and how to do it without losing history.

Aerial view of terraced benches in an open pit mine
Trusted data

one hierarchy that matches the plant

Less rework

work orders coded right the first time

Real insight

history clean enough for reliability analysis

The challenge

Asset registers commonly grow through acquisitions, brownfield projects, vendor imports and local workarounds, with equipment sitting at inconsistent levels, duplicates and orphans accumulating, and functional locations that no longer match the plant that was actually built.

The information this creates is disjointed and hard to trust. Work gets coded against the wrong asset, history cannot support reliability analysis, spares cannot be found and maintenance cost will not roll up by system. Planners, reliability engineers and supervisors require a register that reflects the plant, and governance that keeps it that way.

When it's time to act

The signs we commonly see when this initiative is due.

  • Planners find three versions of the same pump and trust none of them.
  • Work orders coded to whatever level was easiest, so history will not aggregate.
  • Spares bought on express freight while the same item sits in the store under another number.
  • Maintenance cost that will not roll up by system when the budget review asks for it.
  • Reliability analysis abandoned because the failure data cannot be grouped.

How we deliver it

  1. Audit

    Quantify hierarchy depth, duplicates, orphans and coding quality against a defined data standard.

  2. Taxonomy design

    Agree hierarchy levels and equipment classes on a taxonomy that suits the operation, whether that is ISO 14224, an internal standard or a blend.

  3. Cleanse

    Rule-based cleansing, de-duplication and enrichment of equipment records and attributes.

  4. Governance

    Data ownership, change control and quality rules so the rebuild does not decay.

  5. Migrate

    Staged migration with validation, then training for planners and supervisors.

Our approach

  • Understand the issues first-hand with the planners, supervisors and reliability engineers who work around them daily, so the rebuild targets what actually breaks rather than what looks untidy.
  • Audit the existing register and measure it: duplicates, orphans, attribute completeness and coding accuracy, benchmarked against your own data standard and, where relevant, published taxonomies. That gives a maturity baseline you can defend at the next budget cycle.
  • Design the target hierarchy so failure data aggregates cleanly from maintainable item up to plant. Where a client has an internal standard we work to it; where they do not, a published taxonomy such as ISO 14224 gives a well tested starting point.
  • Cleanse and enrich records with rule-based checks, keeping an auditable trail from old to new. Data quality references such as ISO 8000 are useful for framing the rules, and are applied where they add value rather than by default.
  • Establish data governance: named owners, a change process for new equipment, and quality rules checked by the system rather than by goodwill.
  • Migrate in stages with reconciliation at each step, then train planners so day-one habits match the new structure.

Tools and methods

ISO 14224 or internal taxonomiesSAP PM, Pronto Xi, IBM MaximoSQL Server data profilingRule-based data cleansingPower BI data quality reportingData governance framework

The value it creates

  • Planning, scheduling and spares all get faster and more accurate when the register matches the physical plant.
  • Failure history aggregates cleanly at every taxonomy level, which is the precondition for defensible reliability engineering and strategy work.
  • Maintenance cost rolls up accurately by system, and every later initiative, from condition monitoring to analytics, starts from a foundation that holds.

What changes

A register shaped by acquisitions and imports

One hierarchy that matches the plant as built

Duplicates, orphans and free-text coding

Rule-checked records with named data owners

History spread across inconsistent levels

Failure data that aggregates cleanly from item to plant

Clean-ups that decay within two years

Governance that keeps the register matching the plant

Where these initiatives fail

The failure modes we design against.

  • Cleansing without governance, which rebuilds the register and then watches it decay again.
  • Designing the taxonomy in isolation from the planners who will code against it every day.
  • Migrating everything instead of what the operation actually maintains.
  • Treating the rebuild as an IT project when the hard decisions are maintenance decisions.

Common questions

Do we have to adopt ISO 14224?

No. What matters is one consistent taxonomy that lets failure data aggregate cleanly. Where an internal standard exists we work to it; where one does not, a published taxonomy such as ISO 14224 is a well tested starting point rather than a requirement.

Will we lose maintenance history in the rebuild?

No. The cleanse keeps an auditable trail from every old record to its new home, and migration runs in stages with reconciliation at each step, so history stays attached to the right equipment.

How long does a rebuild take?

It scales with the size and state of the register, which is why the audit comes first: measuring duplicates, orphans and completeness up front sizes the work honestly before anything is committed.

Key terms

Plain-language definitions from our glossary for the concepts this page leans on.

Standards and further reading

Reference points we draw on where they suit the work. We also work to client internal standards and established site practice.

Further reading

Articles and calculators on the methods behind this work.

Related projects

Facing a similar challenge?

Tell us what you are working through and we will bring the right mix of engineering, data and hands-on experience.

Contact us