Maximo's asset data model is more layered than most implementation teams expect, particularly those coming from simpler CMMS platforms or from a background of managing assets in spreadsheets. There are three distinct objects that together define your asset hierarchy: Locations, Assets, and Classifications. They each play a specific role. Locations and Assets can both hold PM schedules and work order history. Spare parts lists, however, sit on Assets only. The way these objects interact matters as well, because design-time misunderstandings tend to produce structural problems that get progressively harder to unwind.
This article covers how each object works, how they relate to each other, and what the practical consequences are of getting the model wrong before you load a single record. It assumes you're in an active Maximo implementation, evaluating an existing instance, or designing the data architecture for a new one. It does not cover Maximo administration basics.
All terminology is Maximo-specific: LOCATION, ASSET, CLASSSTRUCTURE, SITEID. Readers familiar with SAP PM or AMOS will find structural parallels, but the object names and relationships differ.
The Three Objects You're Actually Working With
Locations: The Fixed Positions
In Maximo, a Location represents a fixed position in your facility, plant, vessel, or network. It's a place where something can be installed, and it doesn't move. If you pull the pump out of its base and send it to the workshop, the Location remains. If you install a replacement pump, it goes into the same Location.
Locations are managed in the Locations application and sit within a Location Hierarchy, which is a parent-child structure that mirrors your spatial or functional layout. A typical industrial hierarchy runs:
SITE (SITEID)
└── Plant / Vessel
└── Area / System
└── Functional Location (the installation point)
The Functional Location at the bottom of that chain is where a physical asset gets installed. It carries:
- A location type. The standard types are OPERATING, NON-PRODUCTION, HOLDING, REPAIR, SALVAGE, VENDOR, COURIER, and LABOR, plus STOREROOM (created via the Storerooms application). Most field installation points are OPERATING
- One or more Systems (hierarchical or network), configured through the Associate Systems action and used to model redundant or interconnected systems
- Its own work order and PM history, distinct from the history on the physical asset installed there. A work order raised against a Location stays on the Location regardless of which Asset was installed there at the time, which is why rotating-equipment best practice is to raise WOs against the Location rather than the swapped Asset
Locations are the backbone of your hierarchy in any implementation where equipment is rotated, swapped, or tracked through overhaul. If your plant runs rotating spares, things like spare pumps, spare motors, or interchangeable heat exchanger bundles, and you want to know both the history at a position and the history of a specific physical unit, you need Locations.
If your plant never swaps equipment between positions and you have no requirement to track work history by physical unit independently of its installation point, you can operate without a full Location hierarchy. That is the exception, not the rule.
Assets: The Physical Items
An Asset in Maximo is the physical item: the actual pump, motor, valve, or vessel. It has a serial number, a manufacturer, a model, an installation date. It moves. You can install it at a Location, remove it, send it to a repair Location, and reinstall it somewhere else. Its work history follows it wherever it goes.
Assets also form a hierarchy, called the parent-child Asset hierarchy, which is separate from the Location hierarchy. A centrifugal pump package Asset can have child Assets such as the driver, the gearbox, and the instrumentation attached to it:
PUMP-001 (Centrifugal Pump Package)
├── PUMP-001-MOT (Electric Motor Driver)
├── PUMP-001-GBX (Gearbox)
├── PUMP-001-VIB-DE (Vibration Probe, Drive End)
├── PUMP-001-VIB-NDE (Vibration Probe, Non-Drive End)
└── PUMP-001-PT (Discharge Pressure Transmitter)
Each of those is a serialised, individually maintainable item with its own service history, its own PM schedule, and potentially its own spare parts list. The motor in particular is a textbook child Asset: it has a serial number, a nameplate, and a maintenance regime that's independent of the pump body it currently drives.
What you should not model as child Assets are the wear parts and consumables that sit on the pump itself. Mechanical seals, bearings, impellers, gaskets, and o-rings are spare parts, not Assets. They live on the parent pump's Spare Parts tab, identified by their Item Master records, and they're consumed against work orders rather than tracked as serialised units. Modelling these as child Assets is one of the most common Maximo design errors, and it produces an asset register cluttered with thousands of "assets" that are really just stocked items.
Spare parts in Maximo sit on the Asset record specifically, on the Spare Parts tab. They can be added manually, populated automatically via the "Add as Spare Part?" flag on item issue, or applied in bulk via an Item Assembly Structure (IAS). Locations do not carry their own spare parts list, so when you're deciding what to model as an Asset versus a Location, the need to track spares against a record is one of the deciding factors.
A useful test: if the item has a serial number, a manufacturer's nameplate, and you'd track its individual service history through overhaul, it's an Asset. If it's a stocked, replaceable item identified by a part number and consumed against a work order, it's a spare part on the parent Asset.
The parent-child Asset hierarchy and the Location hierarchy are independent structures connected by the Asset's current location. The pump Asset (PUMP-001) sits at Location (P-101-A) via the LOCATION field on the Asset record. The two trees are different shapes, and the connection between them is a field reference, not a structural merge.
Classifications: What Type of Thing It Is
The third object is the Classification, specifically the CLASSSTRUCTURE that governs what attributes an asset of a given type carries.
A Maximo classification for a centrifugal pump might include the following attributes:
| Attribute | Type | Example Value |
|---|---|---|
| PUMP_TYPE | ALN | Centrifugal |
| IMPELLER_DIA_MM | NUMERIC | 320 |
| SEAL_TYPE | ALN | Mechanical, Single |
| RATED_FLOW_M3H | NUMERIC | 450 |
| RATED_HEAD_M | NUMERIC | 85 |
| DRIVER_TYPE | ALN | Electric Motor |
| CASING_MAT | ALN | Duplex SS |
The classification doesn't control where the asset sits in the hierarchy. It describes what the asset is, independently of where it's installed. That means you can query across the entire asset register for all centrifugal pumps with a rated flow above 400 m³/h, regardless of which site, area, or system they're in.
Classifications are defined in the Classifications application and can be applied to Assets, Locations, Items, and Work Orders. Attributes flagged "Use in Specifications?" appear on the Specifications tab of the relevant record. A CLASSSTRUCTURE can be hierarchical itself, for example ROTATING EQUIPMENT > PUMP > CENTRIFUGAL PUMP > BETWEEN BEARINGS. That lets you classify records at whatever resolution your failure analysis strategy requires.
The common mistake: loading asset records with no classification, intending to add it later. Retrospective classification is significantly harder than building it into the load process, particularly if you're using classification attributes as a basis for PM task filtering or spare parts grouping. Classification isn't a cosmetic layer. It's a query and analysis infrastructure layer. Design it before you build the hierarchy, not after.
The PM Attachment Decision: Where It Lives Matters
This is the most consequential design decision in a Maximo hierarchy build, and many teams either make it inconsistently or don't make it explicitly at all.
In Maximo, a Preventive Maintenance (PM) record can be attached to either:
- A Location, in which case the PM follows the position regardless of which physical asset is currently installed there
- An Asset, in which case the PM follows the physical item regardless of where it's currently installed
Both are valid and both serve real maintenance scenarios. The problem arises when a team hasn't made a deliberate decision and ends up with PMs attached to Locations in some areas and Assets in others, with no documented rationale.
PM on Location: When to Use It
Attach PMs to Locations when:
- The maintenance task is position-dependent, i.e. it's about maintaining the function at that point in the system, not the specific physical unit
- Equipment at that position rotates frequently, and you want a replacement unit to inherit the PM schedule automatically on installation
- You're running time-based PMs tied to operational context. For example, a pump in a cooling water circuit that runs continuously, where the PM interval relates to operational hours at that position rather than the history of the specific pump body
Example: an HVAC supply fan in a marine engine room. The fan is regularly swapped during drydock. The PM for filter cleaning and bearing lubrication follows the position, so whichever fan is installed at that point gets the schedule. When the fan is removed, the position's PM schedule persists and is inherited by the replacement.
PM on Asset: When to Use It
Attach PMs to Assets when:
- The maintenance task is unit-dependent. It relates to the specific physical item's condition, history, or age
- The asset is tracked through overhaul, and its PM schedule needs to reflect actual service history, not the history at a fixed position
- You're running condition-based or meter-driven PMs tied to the asset's own runtime or cycle count, rather than the position's
Example: a gas turbine with a borescope inspection interval based on fired hours. The fired-hours meter sits on the Asset record, not the Location. The PM has to be attached to the Asset so the meter-based trigger follows the unit through removal, overhaul, reinstallation, and any position changes.
The Mixed Approach, and Why It Needs a Policy Document
Most implementations end up with a hybrid, some PMs on Locations and some on Assets, because no single rule covers every equipment type. That's fine. What's not fine is a hybrid with no policy document.
The policy document should specify, for each major equipment category in your hierarchy:
- Is the PM attached to Location or Asset?
- If Asset, does the PM schedule reset on reinstallation, or carry forward?
- How are meter readings handled at the Location level vs. Asset level?
- What happens to the PM schedule when an asset is moved to a Repair Location?
Without this document, the decision defaults to whoever is doing the data entry, and you end up with a database where the behaviour is inconsistent and unpredictable.
The CLASSSTRUCTURE in Practice: An ISO 14224-Aligned Example
For an offshore or process plant implementation using ISO 14224 as the classification framework, a Maximo CLASSSTRUCTURE for rotating equipment might look like this:
ROTATING EQUIPMENT
└── PUMP
└── CENTRIFUGAL PUMP
├── BETWEEN BEARINGS, SINGLE STAGE
├── BETWEEN BEARINGS, MULTISTAGE
├── OVERHUNG, SINGLE STAGE
└── OVERHUNG, MULTISTAGE
Each leaf node in this classification tree carries the full attribute set for that equipment type, including the ISO 14224-specified attributes for failure data collection (functional failure, failure mode, failure cause, detection method). The classification hierarchy mirrors the ISO 14224 equipment taxonomy in Annex A, which means failure data collected in Maximo is directly comparable to industry benchmark data.
What this gives you in practice:
- Consistent attribute capture across every pump in the register, with no free-text fields where one technician writes "mech seal leak" and another writes "seal failure external"
- Queryable failure history. You can run a query for all mechanical seal failures across every centrifugal pump on the site in the last three years and get a structured dataset, not a text search
- PM task filtering. You can generate a PM task list for all overhung single-stage centrifugal pumps as a classification query, rather than maintaining a manual list of pump IDs
This is the practical difference between classification as a taxonomy exercise and classification as a maintenance engineering tool. The structure of the CLASSSTRUCTURE determines what questions you can answer from the data.
Loading Sequence: Why Order Matters
When loading a Maximo hierarchy from source data, whether from an engineering data pack, an existing legacy CMMS, or a green-field build, the load sequence is not optional. Maximo's business object layer rejects records whose parent reference doesn't resolve, so a child record can't be saved against a parent that hasn't been created yet. Bulk loaders like MxLoader and the Maximo Integration Framework don't pre-validate the file. Validation happens server-side at sync, which means a wrong-order load typically surfaces as a batch of failed rows rather than a clean upfront warning.
The correct load sequence:
- CLASSSTRUCTURE. Build the full classification hierarchy before any asset records reference it
- Location Hierarchy. Load top-down: Site first, then each level below, never orphaning a child before its parent exists
- Asset records. Load with parent Asset and installed Location references only after both hierarchies are in place
- Specifications. Populate classification attributes against Asset records (these can be loaded with Asset records if the import tool supports it, but CLASSSTRUCTURE must pre-exist)
- PM records. Attach to Location or Asset records as per the policy document. PM records cannot reference asset or location records that don't exist
- Spare parts lists. Items (stocked parts) must exist in the Item Master before they can be added to an Asset's Spare Parts tab, either manually or by applying an Item Assembly Structure (IAS)
Loading in the wrong sequence, typically Asset records before the Location hierarchy or PM records before the Asset records, produces either load failures or orphaned records. Both require correction passes that are expensive at scale.
The specific problem with spreadsheet-based staging: a flat spreadsheet can list parent-child relationships, but it can't model them. If Location P-101-A is the parent of Asset PUMP-001, and P-101-A is in row 847 of a 12,000-row spreadsheet, there's no visual or structural check that confirms the parent exists before the child is loaded. Errors in the load sequence surface post-import, often as a set of records with null parent references that have to be identified, corrected, and reloaded. At that point, any PM records or work orders that have already been created against the orphaned records need to be manually reassigned.
Five Implementation Decisions to Make Before You Build
These are the decisions that need to be made explicitly, by the implementation team and the reliability lead together, before a single record is created in the Maximo hierarchy. Leaving them to default or to individual data entry judgement is how you build a hierarchy that needs restructuring in year two.
1. How many hierarchy levels, and what does each represent? Define your levels by name and purpose before you start. "Site > Plant > System > Functional Location > Asset > Component" is six levels. Is that the right depth for your asset base? Too shallow and you can't attach PMs at the right granularity. Too deep and the hierarchy becomes unmaintainable, and work orders get raised against the wrong level.
2. What is the naming convention for each object type?
Location IDs, Asset numbers, and Classification codes each need a naming pattern, defined in advance and enforced at creation. A Location ID format of [SITEID]-[AREA]-[SYSTEM]-[SEQ] means every Location ID is self-describing. A format of "whatever the data entry person thought was reasonable" means a database that can't be reliably queried by ID range or prefix.
3. At what hierarchy level does the PM attach, and is that consistent across equipment families? Covered in detail above. This decision needs to be in writing before any PM records are created.
4. Which equipment categories will have component-level Asset records? Not every asset needs child records. A fixed structural member doesn't need a bearing and a seal as child assets. A major rotating machine does. Define the categories, typically by ISO 14224 equipment class, that will have component-level records, and which will be managed as single Asset records.
5. What is the Classification structure, and who owns it?
The CLASSSTRUCTURE hierarchy needs an owner: someone responsible for adding new classification nodes, maintaining the attribute list, and ensuring that new asset records are classified before they go live. Without an owner, the classification drifts into inconsistency within months of go-live.
AssetStage is a visual staging workspace for Maximo and SAP PM implementation teams, built to model, validate, and bulk-correct hierarchy data before production load. If you're in a Maximo hierarchy build and working from spreadsheets, get in touch or start with our free resources.