Cleaning Up Asset Data Before It Sinks Your Planning Program

The schedule said "replace bearing on Pump 7." Simple enough — except there are three assets named Pump 7 across two areas, the part number on the work order is for a pump that was retired in 2019, and the bin location points to a shelf that's now full of filters.

Bad data produces fiction schedules. Every elegant planning artifact you build — the job plan, the ready backlog, the KPI dashboard — inherits the quality of the asset data underneath it. This is the unglamorous prerequisite nobody wants to talk about, and skipping it is why so many planning programs quietly fail. Here's a concrete, ordered way to fix it without drowning.

What bad data actually costs, traced through one job

The abstract claim that "bad data sinks planning" lands harder traced through a single job. Follow the Pump 7 work order from the opening all the way to the floor.

The planner goes to scope the bearing replacement and immediately hits the duplicate-asset problem: three things named Pump 7, and the work history is split across all three, so none of them shows a complete failure record. The planner guesses at the right one. Next, parts: the work order references a bearing part number that belongs to a pump retired in 2019, because the BOM was never updated when the asset was replaced. The planner either catches it — burning time chasing the right number — or doesn't, and a tech gets dispatched with the wrong part. Then the bin location points to a shelf now full of filters, so even the right part can't be staged without a hunt. The kit can't be built. The job can't be planned with confidence, so it gets scheduled as a rough guess or kicked back to reactive.

Every one of those failures is a data failure, not a planning-skill failure. A competent planner with rotten data produces rotten plans, slowly, while spending most of their time on archaeology instead of planning. Multiply that across a backlog and the planning program stalls — not because the discipline is wrong, but because the foundation under it is fiction. This is the concrete mechanism behind "clean data is the precondition," and it's why a new planner facing a messy register spends their first months cleaning instead of producing.

Why data is the foundation

Think of the dependency chain. A PM points at an asset. A job plan calls out parts. A schedule references both. A KPI aggregates the work history. If the asset register is wrong, every layer above it is wrong too — and the errors compound silently, because the system happily processes garbage without complaint.

This is also why software alone never fixes planning: a perfect CMMS sitting on rotten data is a fast way to generate confident nonsense. Clean data isn't a nice-to-have under a planning program. It is the program's foundation.

The asset hierarchy

Start with structure. A sound hierarchy organizes assets in nested levels — typically site → area → system → asset → component — so every piece of equipment has one unambiguous home and a functional location that means something.

The functional-location logic matters: it lets you track work and history against a location even when the physical asset gets swapped out, which is how you build meaningful failure history over time. Two failure modes to avoid: over-structuring (so many levels and components that nobody maintains it and data entry becomes a chore people skip) and under-structuring (everything dumped in a flat list, so "Pump 7" is genuinely ambiguous). Aim for the simplest hierarchy that makes every asset unique and every location meaningful.

Naming and numbering standards

Inside the hierarchy, you need conventions that scale. A consistent naming and numbering standard means a planner can find an asset, a tech can confirm they're at the right one, and a leader can roll data up across the operation. Decide the convention once, document it, and enforce it.

Build criticality ranking in as a data field while you're here — not a separate spreadsheet, an attribute on the asset itself. Criticality is the lever you'll use everywhere downstream: which assets get PMs, which get rigor, which get run-to-failure. Capturing it as data now pays off in every later decision. (Consistent naming and criticality become essential the moment you go multi-site, where five sites with five conventions can't be compared at all.)

The parts and materials master

Next, the parts master — usually the messiest data in the building. Three jobs:

De-dupe. The same bearing exists under four part numbers from three eras. Collapse them, or kitting becomes a guessing game.
Bin locations. Every stocked part needs a location, because "in stock" is useless to a planner staging a kit if nobody knows where it physically lives.
BOM-to-asset links. Connect parts to the assets that consume them, so planning a job auto-surfaces the right parts.

The payoff is direct: clean parts data is what makes kitting possible, and kitting is the single highest-leverage move in recovering wrench time.

The PM library

Now the PM library. The goal is to turn OEM intervals, failure history, and tribal knowledge into a sane, justified set of PMs — not to PM everything that moves. A bloated PM library is its own disease.

Crucially, not every asset needs a PM. Low-criticality, low-cost assets may be fine on run-to-failure. Building the library is the moment to ask, for each candidate PM, whether it actually prevents a failure that actually occurs — which is exactly the discipline of PM optimization. Don't import a vendor's maximal PM schedule wholesale; curate it.

A staged cleanup sequence

Here's the part that keeps this from being a year-long death march: don't boil the ocean. Go criticality-first.

Rank your assets by criticality (you captured this as a field above).
Clean the top 20% — the critical assets whose data errors actually hurt — completely: hierarchy, parts, PMs.
Get those into service driving real planning before you touch the long tail.
Work down the criticality list as capacity allows.

For legacy history, don't try to perfect it. Carry forward what's useful (failure records on critical assets), and don't agonize over cleaning ancient work orders on assets you've since retired. The goal is usable, not pristine.

This staged approach is also why a new in-house planner's ramp stretches when data is a mess — and why doing the critical 20% first lets planning start producing value in weeks instead of quarters.

How long the critical-20% pass actually takes

The fear that keeps teams from starting is that data cleanup is a year-long project that has to finish before any planning value appears. The criticality-first approach breaks that fear, and it helps to be concrete about scope.

You're not cleaning everything — you're cleaning the top 20% of assets by criticality, completely, before touching the rest. For a typical mid-market site, that's a few dozen to a couple hundred assets, not thousands. For each, the work is bounded: confirm it sits in the hierarchy once under one unambiguous name, link its real consumable parts with current part numbers and bin locations, and curate a justified PM or a deliberate run-to-failure decision. That's hours per asset on the messy ones, less on the clean ones — a matter of weeks of focused effort for the critical slice, not quarters.

The payoff arrives the moment that slice is done, because the critical 20% is exactly where data errors hurt most and where planning produces the most value. You start planning real work on your most important assets while the long tail is still untidy, and you work down the criticality list as capacity allows — the tail never blocks the value. This is the opposite of the boil-the-ocean cleanup that stalls programs: small, ordered, value-first, and structured so the work that matters most happens first and pays off immediately.

Keeping it clean

Data cleanup is not a one-time project; without governance it re-rots within a year. Establish:

Ownership — one role owns adds and changes to the asset register, so the conventions actually hold.
An audit cadence — a periodic check that the hierarchy, parts, and PMs still reflect reality.
Entry discipline — new assets get added to standard, not bolted on ad hoc, so the next acquisition or line addition doesn't reintroduce chaos.

Governance is boring and it's the difference between a clean foundation and another cleanup project in eighteen months.

The takeaway

A planning program is only as good as the asset data beneath it. Build a consistent hierarchy, a de-duplicated parts master with bin locations, and a curated PM library — and do it criticality-first, cleaning the top 20% before you touch the rest. Perfect data is a myth; usable data, governed so it stays usable, is the goal and the precondition for any real planning.

Find out where your data stands. Book a discovery and assessment →