Maintenance Management Systems: Core Modules Explained

When a vendor demos a maintenance management system they show you a work order screen, a calendar and a dashboard, and the whole thing looks like a single coherent application. It is not. Underneath, a computerized maintenance management system is a set of loosely coupled modules with hard dependencies between them, and the sequence in which you configure them decides how much rework you do later. If you are scoping, configuring or inheriting a CMMS, the useful mental model is not the demo screen. It is the module map: what each part is for, what it needs from the parts before it, and what happens when it is switched on half-configured. That map is what this guide gives you. If you are still at the stage of working out what the category is, start with the complete buyer's introduction to CMMS and come back here for the anatomy.

The message up front: almost every module in a computerized maintenance management software package can be reconfigured later except four, and those four are the asset hierarchy, the work order lifecycle states, the failure code structure, and the storeroom and unit-of-measure setup. Those carry history. Once a year of transactions has been written against them, changing them means either losing the history or migrating it, and both are expensive. Spend your scoping effort disproportionately on those four and you can afford to be pragmatic about the rest.

1. The module map, and why order matters

A maintenance management system has a dependency graph, not a feature list. Some modules are foundations: nothing above them works until they are populated. Others are consumers: they read from the foundations and add little of their own. Understanding which is which tells you where to spend configuration effort.

The pattern I would hold to on any implementation: you cannot configure downward. If the asset hierarchy is unfinished, every PM schedule built on it is provisional. If crafts are undefined, labour reporting is fiction. If the failure code structure is a placeholder, a year of corrective work orders closes against nothing useful and the reliability analysis you were promised in the business case is simply not available when you go looking for it.

2. The module table: what each one needs and what you cannot undo

This is the reference table. Read the last column as the scoping question you must answer before configuration starts, because that is the column that costs money when you get it wrong.

3. Asset register and hierarchy: the module everything else inherits from

The asset register is where a maintenance management system either becomes useful or becomes a work order logbook. Its job is to hold every maintainable object, positioned in a structure that lets you roll cost and failure data up from a valve to a system to a building to a site.

What it needs: a location tree that reflects physical and functional reality, asset tags that are unique and stable, nameplate data, install and warranty dates, a parent link, a cost centre and a classification. The classification is the quiet workhorse: it is what lets you say "all centrifugal pumps" and apply a job plan, a criticality model or a spares policy to the class rather than one record at a time.

The irreversible decision: how many levels deep the hierarchy goes, and whether locations and assets are separate trees or one merged tree. Separate trees, the approach IBM Maximo and Hexagon EAM both favour, let you replace an asset without losing the location's history. A merged tree is simpler to explain and harder to live with, because when a chiller is swapped you either lose the room's ten-year cost record or you carry a dead asset forever. Get the depth and separation right up front. The detail of doing that well is its own subject, covered in asset hierarchy design for CAFM and EAM, and the governance around keeping it clean sits in master data management for assets.

The failure mode: a flat register. Five thousand assets, no parents, no classes. The system works fine for logging jobs and is useless for every question anyone will eventually ask: what does this building cost, which asset class fails most, where is the maintenance spend concentrated. I have seen this outcome more often than any other single configuration error, and it is always the result of migrating a spreadsheet instead of designing a structure.

4. Criticality: the module that makes differentiation possible

Criticality is a small module with large leverage. It scores each asset by consequence of failure, and that score is then the input to PM frequency, response priority, spares stocking and capital replacement ranking. Without it, everything in the system is treated as equally important, which in practice means everything is treated as equally unimportant.

What it needs: an agreed set of consequence dimensions (safety, statutory or regulatory exposure, operational impact, cost of failure, redundancy), a scoring scale, and a score per asset. Scoring is a workshop exercise with operations, not a data-entry exercise.

The irreversible decision: the scoring model. Changing dimensions or weightings after the estate is scored means rescoring the estate. Get the model agreed and signed off before the first score is entered. The mechanics of building a defensible model are in asset criticality classification.

The failure mode: criticality set by copying the vendor's demo values or by asking each engineer to rate their own assets, which reliably produces an estate where sixty percent of assets are "critical". A criticality distribution with no shape carries no information and drives no differentiation.

5. Work order management and lifecycle states

The work order module is the transaction heart of a computerized maintenance management system. Everything else exists either to feed it or to report on it. What it actually does is hold a record through a lifecycle: requested, approved, planned, scheduled, in progress, on hold, complete, closed, cancelled.

What it needs: the asset or location, the work type, a priority, a requester, target and actual dates, labour and part transactions, and a closing record.

The irreversible decision: the state set, and which states stop the clock. Every KPI, every SLA measurement and every backlog report is defined in terms of states. Add a state two years in and you have a reporting discontinuity. Too few states and you cannot distinguish "waiting for parts" from "waiting for access" from "nobody has picked it up", which are three completely different management problems that look identical in a system with only open and closed.

The failure mode: a lifecycle with an approval state nobody has the authority to clear, so the real process moves to phone calls and the system records only the aftermath. Once users learn that the workflow is theatre, data quality collapses everywhere else too.

6. Work types and failure codes: the classification pair

These two modules are the difference between a system that stores work and a system that explains it. Work type says what kind of work this was. Failure codes say what was wrong and what was done about it.

Work types. Keep the list short and orthogonal: corrective, preventive, statutory or compliance, service request, project or capital, and possibly condition-based. Each type carries rules, whether it needs approval, whether a permit is mandatory, whether failure reporting is required at close. The decision that bites is the list itself, because splitting a type later breaks year-on-year comparison across the split. The reasoning behind a well-shaped list is in work order types in a CMMS.

Failure codes. The structure that survives contact with technicians is Problem, Cause, Action, scoped per asset class so a pump shows pump failures and a door shows door failures. What it needs is a curated code set per class and a mandatory capture point at work order close for corrective work only. The irreversible part is the structure and depth: restructure and your historic failure data stops being comparable, which destroys exactly the multi-year trend the codes existed to produce. The full treatment is in failure codes: problem, cause, action.

The failure mode for both is the same: a global code list of two hundred entries, unscoped, with "Other" at the top of the dropdown. Three months later "Other" is eighty percent of your failure history and the reliability analysis in the business case is not achievable with the data you have collected.

7. PM, job plans and task lists

Job plans hold the procedure. PM schedules decide when it runs. They are usually described as one module and they behave as two, so it is worth separating them when scoping.

Job plans need: ordered tasks written as instructions rather than titles, the craft and estimated hours per task, the parts and tools required, the safety requirements, and revision control so you know which version a technician actually executed.

PM schedules need: a trigger basis (calendar, meter, or condition), a frequency, a lead time for generation, seasonal windows where relevant, and the link to the job plan.

The irreversible decisions are two. First, whether job plans are written per asset or per asset class. Class-level plans applied through classification are how a 20,000-asset estate stays maintainable with a few hundred plans; asset-level plans are how you end up with 12,000 near-identical plans and no practical way to update a procedure. Second, whether the next due date is calculated from the target date or the actual completion date. Fixed scheduling holds the calendar and shows genuine slippage; floating scheduling resets from completion and drifts. Both are defensible; mixing them across an estate is not, and switching later rewrites every due date you have. The design framework for the PM programme itself is in preventive maintenance plans and programmes.

The failure mode: task lists imported from the O&M manuals verbatim, producing plans with ninety steps that a technician signs off wholesale in forty seconds. Over-specified PM is not more compliant than under-specified PM, it just produces more convincing paperwork for work that was not done.

8. Scheduling, forecasting, labour and crafts

Scheduling is where work meets capacity. The module takes approved work with durations and craft requirements and places it against available people and calendars, then forecasts forward so you can see next quarter's PM load before it arrives. Almost nothing here is irreversible, which is exactly why it should be configured late. Teams that configure the scheduling board in week two and the asset hierarchy in week ten produce a beautiful planning screen with nothing worth planning.

Labour and crafts feed it. The module holds person records, craft and skill codes, rates, shift calendars and the in-house versus contractor distinction, and it captures actual hours through timesheets or work order labour transactions. The decision that hardens is the craft code structure and whether rates live on the person or the craft, because both flow into a cost history you will later be asked to explain.

The failure mode: estimated durations left at a default of one hour across the whole job plan library. Every capacity forecast the system produces is then arithmetic on a fiction, and planners quietly revert to a spreadsheet. Once that happens the scheduling module is dead weight you are still paying licence for.

9. Stores, spares and MRO inventory

The inventory module is where the most expensive irreversible decisions in the whole system live, because stock transacts financially from day one.

What it needs: an item master with genuinely deduplicated part numbers, a unit of issue per item, a storeroom and bin structure, reorder points and safety stock, a costing method, and the item-to-asset link that tells a planner which parts fit which equipment.

The irreversible decisions: unit of measure and costing method. If an item is set up as "box" and a technician issues one meaning one seal, the balance and the valuation are both wrong, and correcting it after twelve months of issues is a reconciliation exercise with an auditor in the room. Costing method (weighted average, FIFO or standard) is a finance decision that is effectively frozen once transactions exist. Get both agreed with finance before the first receipt. The operational side of this module is covered in spare parts and MRO inventory in a CMMS.

The failure mode: duplicate item records. The same bearing under four part numbers, four reorder points and four sets of stock, so the system reports adequate cover while the storeman knows there is none. Deduplicating an item master after go-live is among the least popular projects I have seen anyone sponsor.

10. Purchasing, vendors and the ERP boundary

The purchasing module handles requisitions, purchase orders, receipts and, sometimes, invoice matching for parts and contracted services. It is the module most likely to be half-owned by another system.

What it needs: a vendor master, item-to-vendor links with lead times and prices, approval limits by role and value, tax and currency setup, and receipt tolerance rules.

The irreversible decision: where the purchase order is created. If finance owns the PO in SAP, Oracle or Dynamics, the CMMS raises a requisition and receives against a PO it does not own, and you need a live integration for PO status, receipt and cost posting. If the CMMS owns it, finance needs the postings pushed the other way. Both models work. Changing your mind eighteen months in is an integration rebuild plus a reconciliation of everything already transacted. The patterns for this boundary are in CMMS integration with ERP.

11. Permits, safety, documents and drawings

Permits and safety connect the work order to the control-of-work regime: permit to work, isolation and lock-out records, risk assessments, method statements and authorised signatories. What it needs is a permit type list, hazard and isolation registers, signatory roles mapped to real authority, and validity windows.

The irreversible part is less technical than cultural: whether the permit is a hard gate that prevents the work order moving to execution, or an advisory attachment. Configuring it as a hard gate at go-live is straightforward. Hardening it after two years of advisory use means telling a workforce that the shortcut they have been using is now blocked, which is change management rather than configuration. The integration detail is in permit to work integration with a CMMS, and the underlying safety-lifecycle expectations are set out by bodies such as OSHA and, for fire and life-safety assets, NFPA .

Documents and drawings attach manuals, schematics, wiring diagrams, test certificates and photos to assets, job plans and work orders. It needs a file store with sensible size limits, document types, revision fields, and a link model. The decision that hardens is whether a document attaches to the asset class or the individual asset: class-level attachment means one manual serves four hundred identical fan coil units, asset-level means four hundred copies of the same PDF and no way to update them together.

The failure mode here is a document module used as a dumping ground, with no types, no revisions and three versions of the same schematic, so technicians stop trusting it and carry their own copies. An untrusted document store is worse than none, because it looks like compliance.

12. Meters, condition data, contracts and SLAs

Meters and condition data record readings and act on them: running hours, cycles, kWh, pressure, vibration amplitude. The module needs meter definitions with units, a reading source (manual, mobile, or integrated from BMS or SCADA), rollover rules for meters that reset, and threshold or rate-of-change rules that generate work.

The irreversible decision: units, and whether readings are cumulative or incremental. A fleet where some assets record total hours and others record hours since last service will produce usage-based PM that fires at the wrong time for half the estate, and a reading history you cannot retrospectively normalise because you no longer know which convention each entry used.

Contracts and SLAs hold the service agreements and measure performance against response and resolution targets. It needs contract records with coverage scope, a priority-to-target matrix, calendar rules (do targets run on a Friday in the Gulf, or overnight?), and a defined list of legitimate clock-pause reasons.

The irreversible decision is the pause logic. When a job is waiting on client access or a spare part on a twelve-week lead time, does the SLA clock stop? Whatever you decide, decide it before the first month is measured, because retrospectively recalculating response times to a new rule is not something anyone will accept as a performance report.

13. Mobile execution, reporting and RBAC

Mobile is the module that determines whether your data is captured at the job or typed up afterwards from memory, and that single distinction drives most of the quality of everything else. It needs a device strategy, offline sync with a real conflict rule, screens reduced to what a technician on a ladder can use, and scannable asset labels.

The irreversible decision is the labelling scheme. Tag format, barcode versus QR versus RFID, and placement convention become physical facts across your estate. Relabelling is a field campaign. The practical detail is in mobile CMMS and field-ready maintenance apps.

Reporting and KPIs is the only module with no irreversible decision and the only one that will expose every shortcut taken elsewhere. It needs clean state, type, failure, date and cost data, and a small set of measures that someone is accountable for. A reporting module that cannot produce PM compliance, backlog by age, corrective-to-preventive ratio and cost per asset is not the reporting module's fault; the data was not captured. A sensible starting measure set is in the facility management KPI framework.

Security and RBAC controls who sees and does what, by role, by site, by cost centre. The irreversible decision is role-based versus per-user permissions. Per-user grants are quicker on day one and unauditable by month twelve, and unpicking several hundred individual grants into coherent roles is manual work nobody budgets. Design the roles first, even if there are only six. The approach is in RBAC design for CAFM systems.

14. The modules people skip and regret

Across scoping exercises the same modules get deferred to "phase two", and phase two rarely arrives. These are the ones where deferral genuinely costs:

• Failure codes. Deferred more often than any other module, because it feels like reporting rather than operations. Every month it is deferred is a month of corrective history with no diagnostic content, and that history cannot be reconstructed. This is the single most costly deferral in the category.
• Criticality. Skipped because it needs workshops with operations rather than configuration in the system. Without it, PM frequencies and response targets are undifferentiated and the whole programme is either over-maintaining cheap assets or under-maintaining important ones.
• Meters. Deferred because manual reading looks like effort. Result: every PM on rotating and mobile plant is calendar-based, so low-use assets are serviced too often and high-use assets too rarely.
• Mobile. Cut for budget in the first phase, which means paper job cards and retyped data. The quality cost lands on every other module and is usually larger than the licence saved.
• Document links at class level. Nobody thinks about it during configuration, so documents get attached per asset by whoever is uploading, and there is no clean path back.
• RBAC. Deferred as "we trust everyone" and it is true, until the first audit or the first accidental mass-update of asset records.

15. The modules people buy and never use

The mirror image, and the part vendors will not volunteer. These modules appear in almost every licence bundle and sit idle in most implementations:

The pattern in that right-hand column is worth noting: in almost every case the missing precondition is not money or software, it is data discipline or an organisational decision. That is why buying a larger module set does not accelerate maturity, and why the difference between platforms at the top of the market and the lighter tools matters less than most buyers assume at the point of purchase. Where the category boundaries actually lie is set out in CAFM vs CMMS vs EAM vs IWMS.

16. A scoping sequence you can lift

If you are about to configure a maintenance management system, this is the order I would hold to, and the reason each step sits where it does:

• 1. Location and asset hierarchy design. On paper, signed off, before anything is loaded. Decide levels and whether location and asset are separate.
• 2. Classification structure. Asset classes drive job plans, failure codes, spares policy and criticality. Design it with step 1.
• 3. Criticality model. Dimensions and weightings agreed with operations, then score.
• 4. Work order states and work types. Draw the lifecycle on a whiteboard and test it against five real stalled jobs.
• 5. Failure code sets per class. Short lists, no "Other" at the top, mandatory on corrective close only.
• 6. Crafts, rates and calendars. Needed before any duration estimate means anything.
• 7. Job plans at class level, then PM schedules. Decide fixed versus floating due dates once, estate-wide.
• 8. Item master, UOM and costing method. With finance in the room. Deduplicate before loading, not after.
• 9. Roles and RBAC. Six to ten roles beat two hundred user grants.
• 10. Permits, documents, meters. Decide hard gate or advisory, class or asset attachment, cumulative or incremental readings.
• 11. Mobile and labelling. Label scheme fixed before the field campaign starts.
• 12. Scheduling, SLAs and reporting. Last, because they consume everything above and change cheaply.

The test of this sequence is that steps one to five cost almost nothing in software terms and consume most of the calendar, while steps eleven and twelve look like the product in the demo. Implementations that invert the order produce a system that demos well in month three and is abandoned by month eighteen.

The idea to walk away with

A maintenance management system is not a product with features, it is sixteen modules with a dependency order and four decisions that carry history. The asset hierarchy, the work order state set, the failure code structure and the storeroom unit-of-measure and costing setup are the four that you cannot cheaply revisit, because a year of transactions will have been written against them. Everything else, including the modules that look most impressive in a demo, can be reconfigured in an afternoon once the foundation is right.

Which means the practical advice for anyone scoping a computerized maintenance management system is uncomfortable but simple: spend your scarce configuration attention on the four boring modules, defer the exciting ones without guilt, and refuse to switch on a module whose preconditions you cannot yet satisfy. A small system with a sound hierarchy, honest states, real failure codes and a clean item master will outperform a fully licensed platform sitting on a flat asset list every single time.

Final thoughts

The module-by-module view is most useful at two moments: when you are writing the scope for an implementation, and when you have inherited a system that is not delivering and need to work out which layer is broken. In the second case the diagnosis usually runs downward. The reporting is untrustworthy because the failure codes are empty; the failure codes are empty because they were never scoped per class; they were never scoped per class because the classification structure was skipped when the register was migrated from a spreadsheet. Three layers down from the complaint you find the actual cause, and it is nearly always in the foundation layer.

That is also the encouraging part. Foundation problems are fixable without buying anything. Redesigning a hierarchy, curating failure codes, deduplicating an item master and defining six honest roles are unglamorous projects with no licence cost and a larger effect on outcomes than any module you could add. If you only take one thing from this walkthrough, take the dependency direction: configure upward, never downward, and let the impressive modules wait their turn.

Related reading: What is a CMMS: a complete buyer's introduction, Asset hierarchy design for CAFM and EAM, Work order types in a CMMS, Failure codes: problem, cause, action, Spare parts and MRO inventory in a CMMS, RBAC design for CAFM systems.