Lâm Văn PhongReliability · EAM · AI Agent
Contact

EAM · Data · Lâm Văn Phong

EAM data readiness: what should you check first?

A new EAM platform will not repair a fragmented asset register, work orders without useful failure codes, or duplicate spare parts by itself. Data readiness should be judged against the maintenance decisions that the data must support.

01

Start with decisions, not a field inventory

Choose two or three decisions to improve: identify bad actors, revise a PM program, or plan spares for critical equipment. Trace each decision back to records, fields, data creators and update points. A field can be 100% complete and still be a low priority if nobody uses it to decide anything.

02

Asset hierarchy and identity

Check Site → Location → Asset → Component relationships, naming rules, installed positions and replacement history. The same pump may have three names in the historian, CMMS and spreadsheets. Maintain a mapping with an owner, rules for renaming and an exception log; avoid joining records on free-text equipment names.

03

Work orders and failure data

Sample closed work orders. Can an engineer understand the symptom? Is the asset correct? Does the failure code describe a mechanism, or just say “other”? Are start and finish times reliable? Separate the work request, temporary response and root-cause action. Otherwise MTBF, repeat-failure and asset-cost reports may mislead.

04

PM, job plans and MRO

Check whether each PM addresses a failure mode, has a trigger, a job plan, people, parts and a completion criterion. For MRO, review units of measure, manufacturer, part number, technical equivalence and duplicate records. Process rules and master data need to change together.

05

Run a measurable pilot

Choose one asset class at one site. Establish a baseline for correctly linked work orders, usable failure codes, PMs with job plans and duplicate parts. Assign a data owner, improve entry rules, then measure again after one work cycle. Scale only when the operating team uses the cleaned data.

06

Score data quality by decision impact

Field population is not the same as usable information. Assess completeness (a value exists), validity (it follows an approved format and list), consistency (it matches across systems), and fitness for use (it supports the intended decision). For example, work orders may have 95% failure-code completion, yet an 80% use of “Other” will do little for bad-actor analysis. Sample by asset class, record age, and work type; a site-wide average can hide weak areas.

Set acceptance thresholds for each use case and disclose the denominator. PM optimization depends on Asset–PM–Job Plan–failure-mode links. Spare planning depends more on Asset BOMs, Item Master, lead times, and issues from stores. A readiness assessment should show gaps by use case and asset class with an action owner. A single composite score is rarely a useful work plan.

07

Design a crosswalk and migration rules

Before migration, map old identifiers to target Locations, Assets, Items, and failure codes. Each mapping needs a source, target, confidence level, approver, and exception status. Resolve one-to-many and many-to-one relationships with process knowledge: two asset IDs may represent separate installed positions, or one unit that was renamed. Similar text alone is not grounds for an automatic merge.

Trial the conversion on difficult cases: removed assets, replacements, open work orders, obsolete parts, and inactive PMs. Reconcile record counts, parent–child relationships, transaction history, and rejected records. Version the mapping and retain a rollback plan. UAT should involve planners, maintenance engineers, stores, and IT reviewing the transactions and reports they actually use.

08

Make data ownership part of operations

A cleansing exercise will decay unless record creation changes. Define who requests a new Asset, approves hierarchy changes, owns the failure taxonomy, edits the Item Master, and synchronizes changes to other systems. Entry forms should validate required fields by asset class while allowing documented exceptions; forcing users to enter fictitious values makes the data appear clean but less trustworthy.

After the pilot, monitor errors that can be fixed at source: work orders without an Asset, “Other” failure codes, PMs without job plans, items missing technical attributes, and newly created duplicates. Every metric needs an owner and a correction route. Handover should include governance rules, an exception backlog, and a review cadence, not merely a clean snapshot on cutover day.

09

Illustrative example: assess a pump group

Suppose a pilot covers 40 pumps at one site. The team gathers 12 months of work orders, PM records, Asset BOMs, and historian tags. First, it confirms that installed positions have unique Asset IDs and can be mapped to operating tags. It then samples closed work orders for correct Assets, symptoms, failure codes, and downtime. Engineers reclassify “Other” only where the original evidence supports it; uncertain cases remain marked as such. The deliverable is more than a completeness score: it includes a data-gap register, ID crosswalk, new entry rules, and a list of PMs and Items requiring correction. The scale decision depends on whether planners and reliability engineers can use the data for a traceable PM or spare-planning decision.

Implementation checklist

  • Use cases and decisions requiring data
  • Asset hierarchy and source mapping
  • Engineer-reviewed sample of closed work orders
  • Owned rules for failure codes, PM and MRO
  • Baseline, target and criteria for scaling

Practice framework by Lâm Văn Phong. Check the standards, rules and current data applicable to each project before use.