Purpose
The CMMS Technical Build Guide is the reference document for standing up a CMMS from scratch or rebuilding one after a data migration. It covers the structural decisions — plant hierarchy, functional locations, equipment, BOMs, task lists, PM plans and work requests — that make the difference between a system people trust and a data graveyard.
Scope
- Any CMMS platform (SAP PM, Maximo, Ellipse, Pronto, Mainpac, Fiix, Limble)
- Greenfield builds, brownfield rebuilds and post-acquisition data migrations
- Configuration decisions that must be locked before master data load
- Governance rules to keep the build clean for the next 10 years
Key Terms
| Term | Meaning |
|---|---|
| Functional Location (FLOC) | The role an asset plays in the process — position-based, not equipment-based. Survives replacements. |
| Equipment | The physical serialised asset. Moves between functional locations over its life. |
| Object Type | Template classifier used to standardise attributes, task lists and BOMs across similar assets. |
| Task List | Reusable set of steps executed as part of a PM or corrective work order. |
| PM Plan | Schedule that generates work orders from a task list at defined intervals or counter readings. |
| Work Request | Defect report / observation that becomes the source record for corrective work. |
Sections
- 01
Plant hierarchy & functional locations
IntentDesign a stable position-based hierarchy the site can grow into.
Actions- Adopt ISO 14224 as the reference model for FLOC levels (Plant → Area → Unit → System → Sub-system → Component).
- Never number functional locations sequentially — use meaningful codes tied to the plant designation (P&ID tag, line number).
- Cap the hierarchy at 6–8 levels; deeper trees make reporting impossible.
- Reserve one FLOC per replaceable component even if it's not currently tracked — it is far cheaper to leave a spare node than to restructure later.
What Good Looks Like- Lock the hierarchy standard, catalogues and Object Types before loading a single record.
What Bad Looks Like- Sequential FLOC numbering that has no relationship to the plant — reporting is impossible.
- 02
Equipment master
IntentAttach the serialised asset to the position without losing history when it moves.
Actions- One equipment record per serial number. Movements between FLOCs are transactions, not new records.
- Mandatory attributes: manufacturer, model, serial, in-service date, criticality, cost centre.
- Class + Characteristics (or the CMMS equivalent) captures the technical spec used by reliability analysis.
- Retire equipment through a controlled status, never by deletion.
What Good Looks Like- Assign a named Data Steward from day one; the system decays without one.
- Automate master data health reports and publish them monthly.
What Bad Looks Like- Deleting equipment instead of retiring — history vanishes.
- 03
Object types & templates
IntentStandardise similar assets so master data effort scales.
Actions- Define an Object Type for every asset family (centrifugal pump, conveyor drive, DC motor, HV switch, etc.).
- Each Object Type carries the standard task list references, spare BOM template, and characteristic set.
- New equipment inherits from its Object Type on creation — no free-text spec fields.
- Follow the JBI Object Type Component Naming rules for a naming standard that survives audits (see linked guide).
What Good Looks Like- Lock the hierarchy standard, catalogues and Object Types before loading a single record.
- Assign a named Data Steward from day one; the system decays without one.
- Automate master data health reports and publish them monthly.
What Bad Looks Like- Sequential FLOC numbering that has no relationship to the plant — reporting is impossible.
- Free-text everything on the work request — reliability analysis becomes fiction.
- 04
Bills of Materials (BOM)
IntentLink the right spares to the right position so planners can pack a job in minutes.
Actions- Functional Location BOMs for items shared by everything at that position (belts, filters, bearings).
- Equipment BOMs for items unique to the serialised unit (rotor, stator, gearbox).
- Use the Material / Spare Code Description standard so identical parts are not duplicated across sites.
- Purge zero-usage lines at least annually.
What Good Looks Like- Lock the hierarchy standard, catalogues and Object Types before loading a single record.
- Build one line of the process end-to-end before scaling — prove the model works.
What Bad Looks Like- Copying task lists across PM plans instead of linking — one change requires editing dozens of records.
- 05
Task lists & PM strategy
IntentBuild reusable, RCM-anchored task lists that PM plans point to.
Actions- Every task list carries an owner, revision, effective date and RCM justification.
- Numbering follows the CMMS Task List Numbering standard (see linked guide).
- One task list can be linked from many PM plans; never copy-paste steps.
- Task list interval and PM plan interval are decoupled — the plan schedules; the list defines the work.
What Good Looks Like- Build one line of the process end-to-end before scaling — prove the model works.
- Version-control task lists like code — every change is reviewed and dated.
What Bad Looks Like- Copying task lists across PM plans instead of linking — one change requires editing dozens of records.
- No governance forum — the build is pristine on day one and unrecognisable in twelve months.
- 06
Work Requests & work orders
IntentMake the defect-to-work-order path frictionless and defensible.
Actions- Enforce controlled catalogues on damage code, cause code, activity code — no free text.
- Every work request links to a functional location, not free text.
- Work order types are a controlled list (Corrective, Preventive, Predictive, Improvement, Modification).
- Status workflow gates: Created → Approved → Planned → Scheduled → In-Progress → Complete → Closed.
What Good Looks Like- Build one line of the process end-to-end before scaling — prove the model works.
What Bad Looks Like- Free-text everything on the work request — reliability analysis becomes fiction.
- 07
Reporting, KPIs & governance
IntentGive leadership a reliable read on the health of the master data and the maintenance program.
Actions- Standard KPI pack: schedule compliance, PM compliance, reactive %, MTBF, MTTR, backlog age.
- Master data health dashboards: orphan equipment, unlinked BOMs, expired task lists, work requests without FLOC.
- Quarterly master data audit run by a nominated Data Steward.
- Change control: any structural change (new Object Type, hierarchy shift, catalogue change) requires a signed data change request.
What Good Looks Like- Automate master data health reports and publish them monthly.
What Bad Looks Like- Sequential FLOC numbering that has no relationship to the plant — reporting is impossible.
- No governance forum — the build is pristine on day one and unrecognisable in twelve months.
Best Practices
- Lock the hierarchy standard, catalogues and Object Types before loading a single record.
- Build one line of the process end-to-end before scaling — prove the model works.
- Assign a named Data Steward from day one; the system decays without one.
- Version-control task lists like code — every change is reviewed and dated.
- Automate master data health reports and publish them monthly.
Common Pitfalls
- Sequential FLOC numbering that has no relationship to the plant — reporting is impossible.
- Free-text everything on the work request — reliability analysis becomes fiction.
- Copying task lists across PM plans instead of linking — one change requires editing dozens of records.
- Deleting equipment instead of retiring — history vanishes.
- No governance forum — the build is pristine on day one and unrecognisable in twelve months.
Related Templates
- Functional Location BOM template
- Material / Spare Code Description template
- Task List template