CMMS Software: Data Model, Integration, Build vs Buy

CMMS software runs the maintenance side of a physical operation: the assets a team is responsible for, the work done to keep them running, the preventive jobs due before something breaks, and the spare parts each repair consumes. A maintenance team that runs from memory and clipboards loses the asset history, misses the schedule, and discovers a failure when the line stops. A CMMS keeps the one record that prevents all three.

This article is for the team deciding how to run maintenance in a plant, fleet, or facility, not for the vendor shortlist. It works through the parts the category pages skip: the data model that ties assets, work orders, schedules, and parts together; how a CMMS generates preventive work on time and on usage; where it integrates with ERP and the machines on the floor; and the KPIs it computes as formulas over that model. The thread through all of it is the engineering, the structure that decides whether a system fits how you maintain.

The short version

• CMMS (computerized maintenance management system) is the software a maintenance team uses to track assets, schedule preventive work, run work orders, and manage the spare parts repairs consume.
• The whole system rests on five linked entities, an asset registry, the work order at the center, work requests, PM definitions, and meters, with cost and downtime rolling up the asset hierarchy.
• A CMMS schedules preventive maintenance on two kinds of trigger, time-based (fixed or floating calendar dates) and meter-based (run hours, cycles, or mileage), and many jobs fire on whichever comes first.
• A CMMS runs maintenance execution, while EAM widens the scope to the full asset lifecycle and predictive maintenance is the condition trigger that tells the CMMS when to generate work.
• Integration carries most of the value: ERP over REST APIs for parts and cost, the shop floor over OPC-UA for automatic meter readings, and IoT sensors over MQTT for condition-triggered work orders.
• Buying an off-the-shelf CMMS fits standard maintenance, while a custom build wins for a nonstandard asset hierarchy, deep ERP or MES integration, or a white-label product, with cost typically from about $25K to past $500K.

What CMMS software is, and what the acronym means

A CMMS is the system that knows every asset a maintenance team owns, everything done to each one, and everything still due, so the work runs from a single trustworthy record instead of someone's recollection. CMMS stands for computerized maintenance management system, and the expansion is literal: it is the computerized version of the maintenance log, the PM calendar, and the parts cage a plant once kept on paper. The acronym predates the cloud and has stuck since, because the function is stable even as the technology moved from a back-office server to a phone in a technician's hand.

What a CMMS is for is narrower than the feature lists suggest. It captures asset history so a recurring fault is visible rather than rediscovered each time. It enforces a preventive schedule so service happens before failure. It routes unplanned work, the breakdown reported at 2 a.m., into the same record as the planned. And it tracks the parts and labor each job consumes, so maintenance has a cost and a paper trail. Strip the screens away and a CMMS is a small set of linked records, which is exactly where its design has to be right.

The data model behind CMMS software

Everything a CMMS does rests on a handful of linked entities. Vendors sell modules and screens; the durable view is the data model underneath, because that structure decides whether a system can represent your operation at all. Five entities carry the weight.

The asset registry holds the equipment a team maintains, but its defining feature is the hierarchy. Assets nest in a parent-child tree, typically site, then building or production line, then system, then the individual machine, down to the replaceable component. That tree matters because cost, failure history, and downtime roll up it: a component's repairs accrue against the machine, the machine's against the line, so a manager sees which line bleeds the most maintenance hours, not just which bolt was replaced.

The work order is the central entity, the record everything else links to. A single work order points at the asset, the technician or crew assigned, the parts consumed, the labor booked, the cost incurred, and the status it sits in. It is the transactional heart of a CMMS the way a sales order is the heart of order software. The work request feeds it: a lightweight report, often raised by an operator, that says something is wrong, and a planner converts the real ones into work orders, keeping the noise of every reported issue out of the planned-work record.

The PM definition is a template, not an event: it describes a recurring preventive job, its task list, the parts it needs, and the trigger that schedules it, and the system generates a work order from that template each time the trigger fires. The meter is the reading that drives usage-based triggers and feeds condition logic: run hours, cycles, mileage, temperature, recorded against an asset over time.

Work orders: reactive, corrective, and preventive

If the work order is the central entity, its type and its lifecycle are where maintenance strategy shows up in the data, and the mix between the types is the clearest signal of whether an operation is in control of its equipment or chasing it.

Reactive work, also called breakdown or emergency maintenance, is run-to-failure: the asset stops, and the work order is raised to fix it after the fact. It is the most expensive mode, because failure picks the timing and an unplanned stop drags collateral cost with it. Corrective work addresses a known defect before it becomes a failure, a worn bearing spotted on inspection and scheduled for replacement, planned rather than panicked. Preventive work is the scheduled, recurring maintenance generated from PM definitions to stop failures arising at all. A healthy operation shifts its mix away from reactive toward preventive and corrective over time, and because every job is a typed record, that shift is measurable rather than felt.

The lifecycle is a state machine every work order moves through, and modeling it explicitly is what makes the record trustworthy. A typical flow runs requested, approved and planned (a planner adds tasks, parts, and an assignee), scheduled, in progress, on hold (waiting for a part or access), completed, and closed after review. Each transition stamps who and when, which later lets the system compute how long work waited versus how long it took. For some assets a state is a legal control: OSHA's Control of Hazardous Energy standard, the lockout-tagout rule at 29 CFR 1910.147, requires energy isolation before servicing certain equipment, and a CMMS encodes that as a mandatory procedure gating the in-progress state, so safety is part of the record rather than a hope.

How CMMS software schedules preventive maintenance

Preventive maintenance is the reason most teams buy a CMMS, and how the system decides when a PM is due is what separates a real tool from a shared calendar. A PM definition fires on a trigger, and there are two fundamentally different kinds, with a third combining them.

Time-based triggers fire on the calendar, and they split in a way that matters more than it first looks. A fixed schedule fires on set dates regardless of when the last one was done: the first of every month, come what may. A floating schedule calculates the next due date from the last completion, so a PM done five days late pushes the next one five days out. Fixed suits calendar-bound obligations like a regulatory inspection; floating suits service spaced by elapsed time since the work happened, and confusing the two either nags about jobs already done or lets intervals silently stretch.

Meter-based triggers fire on usage instead of time. The CMMS reads a meter, run hours, cycles, mileage, and generates the work order when the reading crosses a defined interval, for example a service every 250 operating hours. This is essential for assets whose wear tracks use rather than the calendar: a generator run twice a year and one run continuously should not be serviced on the same monthly tick. Meter triggers depend on readings arriving, by manual entry or, far better, automatically from the machine, which is where integration enters. Many real PMs are combined, firing on whichever threshold arrives first. The engineering challenge is the generation logic: creating the right work order, with the right tasks and parts, exactly once per trigger, without duplicating or skipping, across thousands of definitions.

MRO spare-parts inventory in a CMMS

A work order that calls for a part it cannot get is just a delayed breakdown, which is why a CMMS carries a spare-parts store, the MRO (maintenance, repair, and operations) inventory that repairs consume. It is a real inventory subsystem, but it lives inside the maintenance model and connects to it through the work order.

The link is consumption. When parts are issued to a work order, the CMMS deducts them from the storeroom and books their cost to that job, so a repair's true cost includes its materials and an asset's history shows what it has eaten in parts. Each part carries a stock level, a reorder point, and a storeroom location, and when stock falls below the reorder point the system flags a replenishment; PM definitions can reserve the parts a scheduled job will need, so the kit is on the shelf when the technician arrives. The mechanics of valuation, reorder policy, and stock accuracy are the same discipline we cover in manufacturing inventory software; the MRO store applies it to spares, with the defining twist that demand is driven by work orders, not sales. Get the parts-to-work-order link right and maintenance cost becomes real; leave it out and the CMMS tracks labor while the larger spend stays invisible.

CMMS vs EAM, and CMMS vs predictive maintenance

Two boundary questions decide how far a CMMS reaches, and both are about scope rather than rivalry, keeping a team from buying the wrong category.

CMMS versus EAM is a question of breadth across the asset lifecycle. A CMMS runs maintenance: assets, work orders, PMs, parts. Enterprise asset management widens the frame to the whole life of an asset, adding capital planning, asset financials and depreciation, procurement and contract management, and multi-site portfolio views. The cleanest way to see it is in the data model: EAM extends the asset record with financial and lifecycle attributes a pure CMMS keeps thin, and adds entities, contracts, capital projects, depreciation schedules, that maintenance execution has no slot for. The international reference is ISO 55000, the asset-management standard family that frames managing assets across their lifecycle to deliver value, EAM's remit more than a CMMS's, and that relationship feeds our manufacturing ERP breakdown. Many teams start with a CMMS for execution and grow toward EAM as capital and finance become the question, which is why the categories increasingly blur into one product.

CMMS versus predictive maintenance is a question of execution versus trigger, and the two are partners, not alternatives. Predictive maintenance reads sensor and machine data to estimate when an asset will fail, so the fix lands just before the failure does; NIST frames this condition-based approach through monitoring, diagnostics, and prognostics for manufacturing. The CMMS acts on that estimate: it receives the condition signal or threshold breach, generates the work order, and tracks the labor, parts, and cost of the repair. Predictive maintenance decides when work is needed; the CMMS schedules, dispatches, and closes it. We cover the prediction layer in predictive maintenance software; the point here is the handoff, the condition trigger that becomes a CMMS work order, not the machine learning behind it.

Integrating CMMS software with ERP, IoT, and the shop floor

A CMMS that stands alone is a better clipboard; wired into the systems around it, it becomes the place maintenance, cost, and machine condition meet, and that integration is the strongest reason to build rather than settle. Three connections carry most of the value, each crossing a real boundary with its own protocol.

The first runs to ERP, for parts, purchasing, and cost. A spare's purchase often has to happen in the ERP that owns procurement and the ledger, so the two exchange part masters, purchase orders, receipts, and the maintenance cost that posts back to finance, a structured exchange usually over REST APIs that keeps the spares store and the books reconciled rather than maintained twice. The second runs down to the shop floor and SCADA/PLC systems that already watch the machines. The controllers holding equipment to setpoints also count runtime, cycles, and states, and reading those values, commonly over OPC-UA, lets the CMMS populate meter readings automatically instead of by clipboard, which is what makes meter-based PMs trustworthy. The execution side of that boundary is the subject of what an MES does.

The third, and the one that turns a CMMS from records into prevention, is IoT condition telemetry. Sensors on an asset stream vibration, temperature, or pressure, often over a lightweight protocol like MQTT, into a layer that evaluates them against thresholds or a predictive model. When a reading breaches its limit, the layer raises a condition trigger, and the CMMS turns it into an auto-generated work order with the asset, a task list, and reserved parts attached, so a planned, parts-ready job exists before a human noticed anything. The engineering is in the mapping, machine tag to asset to meter to PM, and in making the generation idempotent so a flapping sensor does not spawn a hundred work orders.

The maintenance KPIs CMMS software computes

The payoff of a clean data model is measurement: because every work order, asset, and downtime event is a typed record, a CMMS can compute maintenance performance as formulas rather than guesses. The canonical definitions come from SMRP, the Society for Maintenance and Reliability Professionals, whose metrics are the non-vendor standard, and each KPI is a calculation over entities the model already stores.

MTBF, mean time between failures, is operating time divided by the number of failures, and it measures reliability: how long an asset runs before it breaks. MTTR, mean time to repair, is total repair time divided by the number of repairs, measuring maintainability: how fast the team restores a failed asset. The two combine into availability, which SMRP expresses as MTBF divided by the sum of MTBF and MTTR, the share of time an asset is ready to run. That figure is exactly the input the OEE calculation consumes as its availability component, which is why we derive OEE there. PM compliance, the leading indicator of the set, is preventive jobs completed on time divided by the number scheduled, and it predicts the others: skip PMs and MTBF falls, reactive work climbs, availability drops. Each formula is only as honest as the timestamps and links behind it, the whole argument for getting the data model right before chasing a dashboard.

Build, configure, or buy CMMS software

With the model, scheduling, integration, and KPIs in view, the decision is which parts to buy, configure, and build, and the honest framework starts from one question: how standard is your maintenance? The parts that look like every other operation's are well served by a package; the parts that are yours alone are where a package fights you.

Buying or configuring an off-the-shelf CMMS is the right default for the common ground. If your asset hierarchy, work-order flow, and PM logic resemble the industry norm, a mature product gives you years of accumulated functionality, a maintained roadmap, and the mobile, offline-first field app field execution requires, since a technician at a remote pump has no signal and the work order has to work anyway. Stay close to standard, because every customization is a thing you re-test forever. Building custom wins for the differentiators: a nonstandard asset hierarchy no package models, deep integration into a specific ERP or MES, embedding maintenance inside a product you already ship, or a white-label CMMS you offer to your own customers. When the list of workarounds becomes the implementation, you are already paying for custom software without owning it.

On cost, the practical range runs from roughly $25K for a focused maintenance layer or a tightly configured deployment, up past $500K for a multi-site platform with deep ERP and IoT integration and a custom mobile app. The number is moved most by site count, the depth of integration to ERP and the shop floor, and whether condition-triggered auto-generation is in scope. The pattern most teams land on is hybrid: keep a standard CMMS for execution and build the integration and analytics layers around it, the shape of work we do in our custom software development and product development practices. AirpartChain anchors aircraft-part and asset records to a tamper-evident ledger, the same asset-record problem a CMMS solves from the maintenance side; HaulBreeze, our own supply-chain platform, and the Conveya transportation-management rebuild are both layers engineered around existing systems of record. Idealogic does not sell a packaged CMMS; we build the asset, work-order, and integration layers that make maintenance software fit an operation that does not run like the template.