How to Structure a PMS Equipment Hierarchy for a Superyacht

You inherit a vessel. You open the PMS. Under "Engine Room" there is a flat list of 400 items. Main engines, generators, purifiers, pumps, valves, filters, sensors — all at the same level, in no particular order. You need to find the port main engine HT coolant pump. Good luck.

This is not a hypothetical. We see it on a regular basis. And it is almost always the result of one thing: nobody thought about the equipment hierarchy before they started entering data.

The hierarchy is the single most important structural decision in any PMS database. Get it right and the database is intuitive, scalable, and useful. Get it wrong and every task, spare part, and report built on top of it inherits the problem.

This article covers how to structure an equipment hierarchy properly — from the top level down to the component level — with practical examples, common mistakes to avoid, and guidance on when to use industry-standard coding versus a custom approach.

Why hierarchy matters

An equipment hierarchy is not just an organisational chart for your machinery. It determines:

• -How quickly crew can find equipment — can the second engineer locate the starboard generator jacket water thermostat in under 30 seconds?
• -How meaningful your reports are — can you pull a report showing all outstanding maintenance on the HVAC system, including every sub-system and component within it?
• -How well your database scales — when new equipment is added during a refit, is there an obvious place for it in the structure?
• -How portable your data is — if you migrate to a different PMS platform, does the hierarchy translate cleanly?

A flat list gives you none of this. A well-structured hierarchy gives you all of it.

The hierarchy is the skeleton. Everything else — maintenance tasks, spare parts, documentation links — hangs off it. If the skeleton is malformed, every layer built on top of it will be compromised.

The recommended structure

After building databases across a range of vessel sizes and types, the structure that works best for superyachts follows five levels:

Level 1: Vessel
  Level 2: System
    Level 3: Sub-system
      Level 4: Equipment
        Level 5: Component

Here is what that looks like in practice for a propulsion system:

MY VESSEL NAME
  Propulsion
    Main Engine No.1 (Port)
      Fuel System
        Fuel Injection Pump
        Fuel Filter (Primary)
        Fuel Filter (Secondary)
      Cooling System (HT)
        Coolant Pump (HT)
        Thermostat
        Expansion Tank
      Cooling System (LT)
        Coolant Pump (LT)
        Charge Air Cooler
      Lubrication System
        Lube Oil Pump
        Lube Oil Filter
        Lube Oil Cooler
    Main Engine No.2 (Starboard)
      [same sub-structure]
    Gearbox No.1 (Port)
    Gearbox No.2 (Starboard)
    Shaft Line (Port)
    Shaft Line (Starboard)

And for an electrical system:

MY VESSEL NAME
  Electrical Power
    Generator No.1
      Diesel Engine
        Fuel System
        Cooling System
        Lubrication System
      Alternator
      Control Panel
    Generator No.2
      [same sub-structure]
    Emergency Generator
    Main Switchboard
    Shore Power Connection

Notice the pattern: every level gets progressively more specific. System tells you the broad functional area. Sub-system narrows it down to a specific unit or assembly. Equipment identifies the individual machine. Component identifies the serviceable part within it.

This is not arbitrary. This structure mirrors how shipyards document their builds, how manufacturers organise their manuals, and how engineers think about systems when they are troubleshooting.

SFI Group System coding

The SFI Group System is the most widely used classification standard for organising ship systems and equipment. Originally developed for commercial shipping, it provides a standardised numerical coding structure that maps to virtually every system on a vessel.

The structure uses a three-digit coding system:

Main Group (1 digit):   6 — Machinery Main Components
Group (2 digits):       61 — Diesel Engines, Main
Sub-group (3 digits):   612 — Fuel Oil System, Main Engine

For a superyacht, the main groups you will use most often include:

1 — Ship General
2 — Hull
3 — Equipment for Cargo (rarely used on yachts)
4 — Ship Equipment
5 — Equipment for Crew and Passengers
6 — Machinery Main Components
7 — Systems for Machinery Main Components
8 — Ship Common Systems

The strength of SFI coding is universality. If you use SFI-based coding, any marine engineer who has worked on properly documented vessels will immediately understand the structure. "6xx" means main machinery. "7xx" means systems serving main machinery. A surveyor reviewing your database can follow the logic without needing a guide.

When to use SFI-style coding

SFI works well when:

• -The vessel is classed and the classification society expects structured coding
• -The management company manages multiple vessels and wants consistency across the fleet
• -The vessel is large enough (roughly 45m+) that the number of equipment entries justifies formal coding
• -You want the database to be immediately readable by any experienced marine engineer

When a custom structure works better

SFI was designed for commercial ships. Superyachts have systems that do not fit neatly into the standard SFI groups — AV and entertainment systems, guest amenity equipment, complex interior lighting control, specialised tender-handling gear.

For smaller yachts (under 45m) or vessels with highly customised systems, a simplified custom structure that follows the same hierarchical principles but uses plain-language groupings often works better. The important thing is not whether you use SFI numbers — it is whether your hierarchy is logical, consistent, and follows a clear system-to-component structure.

We often use a hybrid approach: SFI-based coding for the core marine systems (propulsion, electrical, auxiliary, safety) and custom groupings for yacht-specific systems (AV, interior, deck equipment, guest areas). This gives you the universality of SFI where it matters and the flexibility of custom groupings where SFI is a poor fit.

Common mistakes

Flat lists

The most common problem. Every piece of equipment sits at the same level with no parent-child relationships. The database is effectively a spreadsheet with 500 rows and no structure.

Why this happens: someone started entering equipment and just kept adding items without thinking about how they relate to each other. It is fast to create, but useless to work with.

The fix is not to add codes to a flat list. The fix is to rebuild the hierarchy from scratch with proper nesting. A flat list with SFI codes bolted on is still a flat list — it just has numbers in front of each item.

Grouping by department

BAD:
  Engineering
    Main Engine Port
    Main Engine Starboard
    Generators
    Air Conditioning
    Watermaker
  Deck
    Windlasses
    Capstans
    Crane
    Tender Davit
  Interior
    Galley Equipment
    Laundry Equipment

This reflects who maintains the equipment, not what the equipment is or how it relates to other equipment. The air conditioning system has components in the engine room, throughout the accommodation, and on deck — splitting it across departments makes no sense from a maintenance perspective.

A maintenance database should be organised by system, not by department. Department responsibility can be assigned as a property of each task or equipment entry — it should not drive the hierarchy structure.

Inconsistent depth

Some branches of the hierarchy go five levels deep. Others stop at two. Main engines have detailed sub-system breakdowns, but the HVAC system is a single entry called "Air Conditioning" with 40 tasks hung directly off it.

This creates two problems. First, reporting is unreliable — you cannot compare maintenance burden across systems when they are documented at different levels of detail. Second, it signals that some systems were built carefully and others were rushed or skipped.

The target depth should be consistent across all major systems. Not every piece of equipment needs component-level entries, but every system should be broken down to at least the equipment level.

Mixing equipment and tasks in the hierarchy

We have seen databases where the hierarchy contains entries like:

BAD:
  Main Engine No.1
    Change Oil
    Replace Fuel Filters
    Check Belt Tension

Those are tasks, not equipment. They should not be hierarchy entries. The hierarchy should contain only equipment. Tasks are a separate layer that links to equipment — they are not children of equipment in the tree structure.

This mistake usually comes from engineers who are used to thinking in terms of "what do I need to do" rather than "what equipment do I have." Both perspectives are valid, but the hierarchy must represent the equipment, not the work.

Naming conventions at each level

Consistent naming is as important as consistent structure. Here are the conventions that work:

System level (Level 2)

Use clear, standard system names. No abbreviations, no codes in the display name.

GOOD: Propulsion, Electrical Power, Freshwater Systems, Fire Safety, Navigation
BAD: Prop, Elec, FW, FF, Nav

Sub-system level (Level 3)

Include the specific unit identifier. Use "No.1" / "No.2" not "#1" / "#2". Include port/starboard where relevant.

GOOD: Main Engine No.1 (Port), Generator No.2 (Starboard)
BAD: ME1, Gen #2, Main Engine Port Side

Equipment level (Level 4)

Use the functional name, not the manufacturer name. The manufacturer and model go in the equipment record, not the hierarchy name.

GOOD: Seawater Cooling Pump
BAD: Caterpillar 3512 SW Pump, Pump (the one near the bulkhead)

Component level (Level 5)

Identify the specific serviceable part.

GOOD: Impeller, Mechanical Seal, Drive Belt
BAD: Parts, Bits that wear out

One rule applies across all levels: decide on a convention and apply it without exception. "Generator No.1" everywhere, or "Generator 1" everywhere — either is fine, but mixing them within the same database undermines trust in the data.

Handling shared equipment

This is one of the trickiest structural questions: where do you put equipment that serves multiple systems?

Generators are the classic example. A generator serves the entire vessel's electrical system, but it is also a diesel engine with its own fuel, cooling, and lubrication sub-systems. Does it go under Electrical Power or under Machinery?

Heat exchangers are another example. A central seawater cooling system might serve the main engines, generators, HVAC, and hydraulic systems. Where does the seawater pump live?

There are two workable approaches:

Primary system assignment

Place the equipment under its primary functional system and note the cross-system relationships in the equipment record. The generators sit under Electrical Power because their primary function is generating electricity. The central seawater cooling system sits under Auxiliary Systems because it serves multiple consumers.

This is the approach we use most often. It keeps the hierarchy clean — every piece of equipment appears once, in one place. Cross-references are handled through documentation, not through the tree structure.

Dedicated shared systems group

Create a specific system group for equipment that genuinely serves multiple systems equally:

Auxiliary Systems
  Central Cooling
    Seawater Pump No.1
    Seawater Pump No.2
    Central Heat Exchanger
  Compressed Air
    Air Compressor No.1
    Air Compressor No.2
    Air Dryer
    Air Receiver

This works well for utility systems that do not have a natural home elsewhere. Compressed air serves engines, deck equipment, and pneumatic controls — assigning it to any one of those systems would be arbitrary.

The one thing you must never do is list the same equipment in multiple places. Duplicate entries in the hierarchy mean duplicate tasks, conflicting maintenance records, and confusion about which entry is the "real" one. One piece of equipment, one hierarchy entry, one location.

Putting it together

Here is a simplified top-level hierarchy for a typical 50-metre motor yacht, showing the system and sub-system levels:

MY VESSEL NAME
  Propulsion
    Main Engine No.1 (Port)
    Main Engine No.2 (Starboard)
    Gearbox No.1 (Port)
    Gearbox No.2 (Starboard)
    Shaft Lines and Propellers
  Electrical Power
    Generator No.1
    Generator No.2
    Emergency Generator
    Main Switchboard
    Emergency Switchboard
    Shore Power
  Auxiliary Systems
    Central Cooling
    Compressed Air
    Fuel Transfer and Treatment
    Bilge and Ballast
    Sewage Treatment
    Hydraulic Power Pack
  HVAC
    Chiller No.1
    Chiller No.2
    Air Handling Units
    Fan Coil Units
  Freshwater Systems
    Watermaker
    Freshwater Pumps and Treatment
    Hot Water System (Calorifiers)
  Fire Safety
    Fire Detection System
    Fire Suppression (Engine Room)
    Fire Suppression (Fixed)
    Fire Pumps
    Portable Extinguishers
  Safety Equipment
    Liferafts
    Rescue Boat
    Personal Safety Equipment
    Pyrotechnics
  Navigation and Communication
    Radar
    GPS and Chartplotters
    VHF and GMDSS
    AIS
    Autopilot
  Deck Equipment
    Anchor Windlass (Port)
    Anchor Windlass (Starboard)
    Capstans
    Crane
    Tender and Launching System
    Passerelle
  Interior and Hotel
    Galley Equipment
    Laundry Equipment
    Lighting Control
    AV and Entertainment

Below this, each sub-system entry would expand into individual equipment items, and those would expand into components where relevant. A 50-metre yacht built to this structure typically has 500 to 700 equipment entries at the equipment level, with component-level entries adding another 200 to 400 for critical machinery.

Practical advice

A few things we have learned that do not fit neatly into the categories above:

Lock the hierarchy before you start entering tasks. The biggest waste of time is restructuring a hierarchy after hundreds of tasks have already been linked. Get the structure agreed — ideally with the Chief Engineer reviewing it — before any maintenance data goes in.

Keep the top level manageable. Ten to twelve system groups at Level 2 is about right for most yachts. More than fifteen and the top level becomes unwieldy. Fewer than eight and you are probably lumping unrelated systems together.

Use the builder's documentation as your starting point. The shipyard's equipment schedule and system descriptions are written by the people who designed and built the vessel. They reflect the actual architecture better than any generic template.

Plan for refits. Equipment will be added, replaced, and removed over the vessel's life. A good hierarchy has enough structure that new equipment has an obvious home, without being so rigid that additions require restructuring entire branches.

Think like the engineer searching for something at 2am. If the stabiliser hydraulic pump is making a noise and the second engineer needs to find its maintenance history and spare parts, can they get there in three clicks? If not, the hierarchy needs work.

Where this fits in a database build

The hierarchy is the first thing we build in any project. Before a single maintenance task is created, the entire equipment structure is established, reviewed, and locked. This is covered in detail in our [process](/process) — the hierarchy review is one of the key crew milestones.

If you are looking at your current database and recognising some of the problems described here — flat lists, inconsistent depth, equipment you cannot find — it may be worth a fresh look at how the data is structured. Sometimes the right answer is not more tasks or better spare parts data. Sometimes the right answer is fixing the skeleton that everything else depends on.

You can read more about the characteristics of a well-built database in our article on [what makes a good PMS database](/blog/what-makes-good-pms-database-superyacht), or explore our [services](/services) to understand how we approach database builds from the ground up.