Functional Location Design in CMMS: The Hierarchy Mistakes That Damage Maintenance Data

The most expensive CMMS configuration mistake is often not choosing the wrong software.

It is designing the wrong maintenance hierarchy.

I have seen plants spend months comparing systems, cleaning data, preparing integrations, and planning user training. Then the functional location structure is decided in a few workshops without enough input from the people who will actually use it.

The result usually appears after go-live.

Technicians cannot find the correct equipment position. Planners raise work orders against different objects for the same problem. Preventive maintenance is attached inconsistently. Costs cannot be rolled up by system. Reports look complete but cannot be trusted.

Eventually, someone proposes rebuilding the hierarchy.

By that time, thousands of work orders, inspections, preventive maintenance schedules, meter readings, costs, and failure records may already depend on it.

A functional location hierarchy should not be designed to impress the implementation team. It should help technicians find the right position, help planners organize work, help supervisors control maintenance, and help management understand where time and money are being spent.

This guide explains how to design functional locations that remain practical for years, including thermal power plant examples, migration guidance, naming rules, and configuration mistakes to avoid.

What is a functional location?

A functional location is a stable maintenance position within a plant where work is planned, executed, recorded, and reported.

The key word is stable.

The functional location usually remains even when the equipment installed there changes.

Consider a boiler feed pump position in a thermal power plant:

Plant
└── Unit 1
    └── Feedwater System
        └── Boiler Feed Pump 1

Today, a specific pump, motor, and coupling may be installed at that position.

Five years later, the pump may be replaced. The motor may be replaced earlier. The coupling may be changed several times.

The position remains Boiler Feed Pump 1.

That stable position is the functional location.

It allows the plant to preserve position-based information such as:

• Work-order history
• Downtime
• Preventive maintenance
• Inspection results
• Failure patterns
• Maintenance cost
• Spare-parts usage
• Reliability improvements

A functional location is therefore not merely a folder in the CMMS. It is a long-term maintenance reference point.

Functional location vs asset

This is the distinction that causes the most confusion.

A functional location answers:

Where does the maintenance responsibility exist?

An asset answers:

What physical equipment is installed there?

For example:

Functional Location
Unit 1 / Feedwater System / Boiler Feed Pump 1

Installed Assets
- Boiler Feed Pump
- Pump Motor
- Coupling

The pump may have a manufacturer, model, serial number, purchase date, warranty, and replacement history.

The functional location represents the operating position in the plant.

Why both are useful

Suppose the original pump fails repeatedly and is eventually replaced.

If maintenance history exists only against the old pump asset, the plant may lose visibility into the full history of that operating position.

With a functional location, the team can still ask:

• How many failures occurred at Boiler Feed Pump 1?
• How much downtime has this position caused?
• Did reliability improve after the pump was replaced?
• Is the problem connected to alignment, foundation, piping strain, or operation rather than the pump itself?

The asset tells you what happened to a specific piece of equipment.

The functional location helps you understand what happened at the position over time.

A well-designed asset management system should support both views without forcing users to choose one or duplicate the same history unnecessarily.

Why functional locations matter

The purpose of a functional location hierarchy is not to make the plant look organized inside the software.

It should improve maintenance execution and reporting.

A practical hierarchy helps teams:

• Find the correct maintenance position quickly
• Raise work orders consistently
• Assign preventive maintenance at the correct level
• Preserve history when equipment is replaced
• Compare similar systems
• Roll up costs by plant, unit, system, or area
• Track downtime by functional responsibility
• Review repeat failures
• Organize inspections and meter readings
• Support shutdown and turnaround planning

For example, a plant manager may not want to review the maintenance cost of every individual motor.

The more useful questions may be:

• Which production unit consumes the highest maintenance cost?
• Which system creates the most downtime?
• Which process area has the largest backlog?
• Which boiler or turbine system has the lowest PM compliance?
• Which common utility is affecting multiple units?

A good hierarchy makes these questions easier to answer.

What a functional location should represent

A functional location should represent something stable enough to justify long-term history and reporting.

Typical examples include:

• Plant
• Production unit
• Process area
• System
• Subsystem
• Production line
• Utility system
• Equipment position
• Maintainable station

The hierarchy should normally follow how the plant operates and how maintenance is managed.

It should not automatically follow:

• The current organization chart
• The engineering drawing structure
• The procurement category
• The equipment manufacturer
• The department that currently owns the asset

Departments and reporting lines may change.

The physical and functional process usually remains more stable.

When to create a functional location

Create a functional location when the position has independent maintenance value.

A useful decision test is to ask:

1. Will work orders be raised against this position?
2. Does this position need its own maintenance history?
3. Will equipment be replaced while the position remains?
4. Will costs or downtime be reported here?
5. Will preventive maintenance, inspections, or meter readings belong here?
6. Does this level help technicians find the correct work area?
7. Does this level support planning or reliability analysis?

If several answers are yes, a functional location is likely justified.

Good candidates

Examples include:

• Boiler System
• Turbine Generator System
• Cooling Water System
• Boiler Feed Pump 1
• Compressor Station A
• Packaging Line 3
• Paint Booth 2
• Chilled Water Plant
• Effluent Treatment Plant
• Main Electrical Substation

Positions that may need careful judgement

Some positions may or may not justify a functional location depending on the plant:

• Individual valves
• Instruments
• Small motors
• Gearboxes
• Rooms
• Distribution panels
• Portable equipment

The decision should depend on maintenance value, not object size.

A small safety-critical valve may need independent history.

A large but easily replaceable item may not need a separate functional location if the asset record is sufficient.

When not to create a functional location

Do not create a functional location simply because the CMMS allows it.

Avoid creating one for:

• Every bolt
• Every bearing
• Every small component
• Every temporary item
• Every instrument tag without independent maintenance value
• Every room
• Every drawing reference
• Every project structure
• Items that do not need separate history or reporting
• Duplicate positions already represented elsewhere

The most common overconfiguration mistake is trying to model the complete plant.

A CMMS is not a P&ID, CAD model, or digital twin.

It is a maintenance management system.

The hierarchy should include enough detail to support maintenance without reproducing every engineering object.

Design the hierarchy before opening the CMMS

The best hierarchy workshops begin outside the software.

Start with the maintenance questions the plant must answer.

Examples:

• Where will technicians search for work?
• Where should work orders be raised?
• At what level should costs be reviewed?
• Which systems need independent PM compliance?
• Which positions will retain history after equipment replacement?
• How should shutdown work be grouped?
• How will operations describe the plant?
• Which levels are shared across multiple production units?

Only after these questions are clear should the team create the structure in the CMMS.

Software-first workshops often produce a hierarchy based on available fields and screens rather than maintenance needs.

Keep the hierarchy as simple as possible

Most plants do not need ten or twelve levels.

Four to six meaningful levels are often sufficient.

For example:

Plant
└── Unit
    └── System
        └── Subsystem
            └── Maintainable Position

Some plants need fewer levels.

Some large process plants need more.

The correct number is the minimum required to support navigation, work execution, history, and reporting.

A practical test

Ask a technician to locate a known equipment position.

If it requires opening many levels, interpreting several codes, or choosing between similar branches, the hierarchy is too difficult.

A technician should be able to find a common equipment position in seconds, not minutes.

Thermal power plant hierarchy example

A thermal power plant benefits from a functional or process-system hierarchy because maintenance work is strongly connected to the generating unit and plant system.

A practical top-level structure may look like this:

Thermal Power Plant
├── Unit 1
├── Unit 2
└── Common Systems

Within Unit 1:

Unit 1
├── Boiler System
├── Turbine Generator System
├── Feedwater System
├── Condensate System
├── Cooling Water System
├── Electrical System
└── Control and Instrumentation

Within the Boiler System:

Boiler System
├── Pressure Parts
├── Coal Milling System
├── Combustion Air System
├── Flue Gas System
├── Soot Blowing System
└── Boiler Drain and Vent System

Within the Combustion Air System:

Combustion Air System
├── FD Fan A
├── FD Fan B
├── PA Fan A
├── PA Fan B
├── Air Preheater A
└── Air Preheater B

The assets installed at FD Fan A may include:

• Fan assembly
• Motor
• Coupling
• Bearing housings
• Actuator
• Vibration sensors

The functional location provides the stable operating position.

The assets provide the specific equipment details.

Common systems

Thermal power plants also need a clear structure for systems shared across units.

Examples include:

• Coal Handling Plant
• Ash Handling Plant
• Water Treatment Plant
• Cooling Towers
• Fire Water System
• Compressed Air System
• Switchyard
• Workshop
• Common Electrical Distribution

Avoid placing shared systems under one generating unit simply because that unit was commissioned first.

The hierarchy should reflect the real plant relationship.

Manufacturing plant example

A discrete manufacturing plant may need a different structure.

For example:

Manufacturing Plant
├── Production
│   ├── Line 1
│   ├── Line 2
│   └── Packaging
├── Utilities
│   ├── Compressed Air
│   ├── Chilled Water
│   └── Electrical Distribution
└── Facilities
    ├── HVAC
    ├── Fire Protection
    └── Building Services

Within Line 1:

Line 1
├── Material Feeding
├── Forming
├── Heat Treatment
├── Inspection
└── Packing

The principle remains the same.

The hierarchy should follow the maintenance and operating logic of the plant.

A power plant should not be forced into the same structure as an automotive assembly line.

Anti-configuration: what not to do

The strongest functional location designs are often created by avoiding predictable mistakes.

Do not model the complete P&ID

Engineering drawings contain more detail than maintenance teams need for daily work management.

Copying every line, valve, instrument, and component into the functional location hierarchy creates an enormous structure that becomes difficult to search and maintain.

Use the P&ID to understand the system.

Do not reproduce it blindly inside the CMMS.

Do not create hierarchy levels because the software supports them

Some CMMS products allow many levels.

That does not mean every level should be used.

Each level should answer a maintenance question.

If a level does not improve navigation, responsibility, history, planning, or reporting, remove it.

Do not mix different hierarchy logics randomly

A branch should not suddenly switch between:

• Geography
• Department
• Process system
• Equipment type
• Project structure

For example, this is confusing:

Plant
└── Mechanical Department
    └── Unit 1
        └── Motors
            └── Boiler Feed Pump

The structure mixes department, unit, equipment type, and process position.

A clearer structure is:

Plant
└── Unit 1
    └── Feedwater System
        └── Boiler Feed Pump 1
            └── Motor

Choose one primary organizing logic and apply it consistently.

Do not design around the organization chart

Departments change.

Maintenance responsibilities are reassigned.

Contractors change.

The plant process usually remains.

Use department, team, owner, or discipline as attributes rather than building the entire hierarchy around the current organization chart.

Do not duplicate the asset and functional location without a reason

Avoid creating identical objects that users cannot distinguish.

For example:

Functional Location: Boiler Feed Pump 1
Asset: Boiler Feed Pump 1

This may be valid when the functional location represents the position and the asset represents the installed pump.

But the purpose must be clear.

Use additional attributes such as manufacturer, model, serial number, and asset code to distinguish the installed equipment.

If users cannot explain the difference, the configuration will create duplicate work history.

Do not create empty hierarchy levels

Avoid levels such as:

Plant
└── Area
    └── Section
        └── Subsection
            └── Equipment Group
                └── Equipment

when some levels exist only to make the structure appear complete.

Empty or meaningless levels add clicks without adding value.

Do not create a “Miscellaneous” branch too early

A large “Miscellaneous Equipment” branch usually means the hierarchy has not been designed around real plant functions.

Temporary use during data cleansing may be acceptable.

Permanent use hides responsibility and makes reporting less useful.

Do not aim for a perfect model

The hierarchy should be correct enough to support maintenance and stable enough to survive future changes.

Trying to represent every exception often produces complexity that harms the majority of users.

Design for the common maintenance workflow.

Handle rare exceptions through attributes, asset relationships, or controlled notes rather than additional hierarchy branches.

Naming conventions

Names should be understandable to technicians, planners, operations, and management.

Good names are:

• Clear
• Consistent
• Searchable
• Familiar to plant users
• Stable over time

Examples:

Unit 1
Boiler System
ID Fan A
Boiler Feed Pump 1
Coal Mill 3
Main Electrical Substation

Avoid vague names such as:

Other Equipment
General Area
Miscellaneous System
Mechanical Assets
Section A
Unknown Location

Also avoid excessive abbreviations unless they are already standard across the plant.

A technician should not need a codebook to identify a common equipment position.

Numbering strategy

Functional location codes should be stable, unique, and practical.

There are two common approaches.

Intelligent codes

The code contains hierarchy meaning.

Example:

TPP-U01-BLR-FDG-IDF-A

Advantages:

• Users may understand the position from the code
• Useful in drawings and labels
• Can support sorting

Risks:

• Codes become long
• Renaming becomes difficult
• Plant changes may make the code inaccurate
• Users may interpret abbreviations differently

Sequential codes

The code is a unique number without embedded meaning.

Example:

FL-004582

Advantages:

• Stable
• Simple to generate
• Easy to maintain
• Plant changes do not require renumbering

Risks:

• The code alone tells the user nothing
• Good names and search are essential

Practical recommendation

Use codes that are stable and short.

Do not force the full hierarchy into the code.

The name and hierarchy should explain the position.

The code should provide unique identification.

Assigning preventive maintenance

Preventive maintenance can be assigned to either the functional location or the installed asset.

Assign it to the functional location when the maintenance requirement belongs to the position regardless of which equipment is installed.

Examples:

• Inspect Boiler Feed Pump 1 every month
• Test the fire water pump station weekly
• Inspect the electrical room quarterly
• Clean the conveyor transfer point every two weeks

Assign it to the asset when the maintenance requirement is specific to the equipment itself.

Examples:

• OEM service based on a specific model
• Warranty inspection
• Maintenance based on equipment serial number
• Asset-specific runtime task
• Component-specific overhaul

A preventive maintenance system should support both approaches without duplicating schedules.

Work orders and history

The work-order strategy should be consistent.

For position-related problems, raise the work order against the functional location and identify the affected asset where relevant.

Examples:

• Repeated misalignment at Boiler Feed Pump 1
• Leakage around a fixed process position
• Foundation problem
• Access or guarding issue
• System-level inspection

For asset-specific work, identify the installed asset clearly.

Examples:

• Replace motor bearing
• Repair a specific gearbox
• Record failure against a serialised pump
• Complete warranty work

A structured work order management system should preserve both the position and asset relationship.

This prevents history from being fragmented when equipment moves or is replaced.

Cost and downtime reporting

Before approving the hierarchy, decide where management expects costs and downtime to roll up.

Typical levels include:

• Plant
• Unit
• Area
• System
• Subsystem
• Maintainable position
• Asset

For example, a thermal power plant may want to compare:

• Unit 1 vs Unit 2 maintenance cost
• Boiler vs Turbine Generator cost
• Coal Handling vs Ash Handling downtime
• ID Fan A vs ID Fan B repeat failures
• Common utilities affecting multiple units

An analytics and reporting system can only provide useful roll-ups when the hierarchy and work-order discipline are consistent.

Do not create hierarchy levels only for reports that nobody regularly reviews.

Greenfield implementation

For a new plant or a new CMMS implementation, start with a controlled pilot.

Select one representative area or system.

Test:

• Navigation
• Work-order creation
• Preventive maintenance assignment
• Inspection assignment
• Cost roll-up
• Mobile usability
• Search
• Asset replacement
• Reporting

Ask technicians and supervisors to use the structure before mass migration.

A hierarchy that looks logical in a workshop may still be difficult in the field.

Migrating from SAP PM or another CMMS

Do not copy the existing hierarchy blindly.

Legacy systems may contain:

• Duplicate branches
• Obsolete equipment positions
• Empty levels
• Temporary project structures
• Old naming conventions
• Department-based structures
• Inconsistent abbreviations
• Historical mistakes
• Objects created only for reporting

Migration is an opportunity to simplify.

Before import:

1. Remove duplicates
2. Identify obsolete positions
3. Standardize names
4. Validate parent-child relationships
5. Decide which history must be preserved
6. Map old codes to new codes
7. Review PM assignments
8. Review open work orders
9. Validate with maintenance and operations
10. Test reporting before go-live

Do not allow the implementation team to make these decisions alone.

The people who plan, supervise, and execute maintenance should validate the structure.

Questions to ask before creating a functional location

Use these questions during design workshops:

• Does this position remain when equipment changes?
• Will work orders be raised here?
• Does it need independent maintenance history?
• Will PMs, inspections, or meters belong here?
• Will costs or downtime be reviewed here?
• Does it help users locate the work?
• Is it stable enough to remain for years?
• Is it already represented by another object?
• Will technicians understand the name?
• Does this level add maintenance value?

If the team cannot explain why the functional location is needed, do not create it yet.

Functional location design checklist

Structure

• [ ] Define the primary hierarchy logic
• [ ] Keep the hierarchy as shallow as practical
• [ ] Separate plant, unit, system, subsystem, and position clearly
• [ ] Identify common systems separately
• [ ] Remove empty levels
• [ ] Avoid duplicate branches
• [ ] Avoid permanent miscellaneous groups

Functional location vs asset

• [ ] Define when to use a functional location
• [ ] Define when to use an asset
• [ ] Define how installed assets relate to positions
• [ ] Define how asset replacement will be recorded
• [ ] Define how moved assets will be handled
• [ ] Prevent duplicate work history

Naming and codes

• [ ] Use clear names
• [ ] Standardize abbreviations
• [ ] Keep codes stable
• [ ] Avoid embedding temporary ownership in codes
• [ ] Avoid overly long intelligent codes
• [ ] Confirm names work on mobile screens
• [ ] Confirm users can search using familiar terms

Maintenance processes

• [ ] Decide where work orders will be raised
• [ ] Decide where preventive maintenance will be assigned
• [ ] Decide where inspections will be assigned
• [ ] Decide where meters will be assigned
• [ ] Define cost roll-up requirements
• [ ] Define downtime roll-up requirements
• [ ] Define reporting levels
• [ ] Test asset replacement history

Migration

• [ ] Remove obsolete positions
• [ ] Remove duplicates
• [ ] Review empty levels
• [ ] Standardize names
• [ ] Map legacy codes
• [ ] Validate PM assignments
• [ ] Validate open work orders
• [ ] Preserve required history
• [ ] Review with maintenance supervisors
• [ ] Review with operations
• [ ] Test before mass import

Usability

• [ ] Ask technicians to locate common equipment
• [ ] Test search
• [ ] Test mobile navigation
• [ ] Test work-order creation
• [ ] Test reporting
• [ ] Confirm the hierarchy can support future expansion
• [ ] Freeze the approved structure before go-live

Final thoughts

The best functional location hierarchy is rarely the most detailed one.

It is the one technicians can navigate, planners can schedule against, supervisors can control, and reliability teams can analyse years later.

A good hierarchy remains stable when equipment changes, departments are reorganized, and the plant expands.

It supports maintenance without forcing users to understand a complex data model.

Remember these principles:

• A functional location represents a stable maintenance position
• An asset represents the specific equipment installed there
• Do not model the complete plant drawing
• Keep the hierarchy as simple as possible
• Design around maintenance and process logic
• Use attributes instead of unnecessary hierarchy levels
• Validate the structure with field users
• Clean legacy structures before migration

If users need extensive training just to find the correct position, the hierarchy is serving the software instead of the maintenance team.