CMMS for Oil, Gas and Energy

Ask a maintenance planner on a refinery and a planner in a commercial tower what their system needs to do, and you get two answers that barely overlap. The tower needs work orders, planned tasks, a helpdesk and a decent mobile app. The refinery needs all of that, plus a defensible record that every safety-critical element was inspected on the interval its performance standard demands, plus permit and isolation control woven into the execution path, plus a turnaround plan that locks scope months in advance, plus a spares strategy built around lead times measured in quarters. That gap is why so many oil and gas maintenance software selections go badly: the shortlist was drawn up as if this were a facilities problem.

The message up front: in this sector the system of record is judged less on how efficiently it dispatches work and more on how well it produces evidence. Asset intensity, lifecycle costing, linear assets and regulatory reporting usually push you toward EAM rather than a lightweight CMMS. But not always, and the honest test is not the size of the company, it is whether you carry safety-critical elements with formal performance standards, linear assets, and turnarounds. If you do, buy for the evidence trail. If you do not, a good CMMS may be entirely sufficient and far cheaper to run.

1. Why this sector is genuinely different

Before arguing about products, be precise about what makes maintenance in oil, gas and energy structurally different. Five things account for most of the divergence.

• Consequence asymmetry. Elsewhere the worst case of a missed task is downtime or cost. Here it is loss of containment, fire, explosion or environmental release. That changes how tasks are justified, how deferrals are approved, and how long records must be kept.
• Asset intensity. The capital tied up per square metre is extreme, and the assets are highly engineered, long-lived and individually significant. You cannot treat them as interchangeable line items.
• Linear and networked assets. Pipelines, flowlines, cables and subsea umbilicals are not point assets. They are continuous objects whose condition varies along their length, and they must be modelled that way or the condition data becomes meaningless.
• Documentation as deliverable. Much of what the maintenance organisation produces is not work, it is evidence: inspection reports, test certificates, calibration records, integrity assessments, deviation approvals. A system that cannot retain and retrieve that evidence has failed at its primary job.
• The turnaround. Almost everything about planning in a process plant orbits a periodic major shutdown. Facilities maintenance has no equivalent event with that gravitational pull.

None of this means the fundamentals change. Work orders are still work orders, a bad asset hierarchy is still fatal, and failure coding discipline still decides whether your history is worth anything; the fundamentals I have written about for manufacturing plants apply here too. What changes is the weight placed on evidence, safety control and long-horizon planning.

2. CMMS or EAM: making the call for this sector

The CMMS and EAM distinction is often presented as a marketing boundary, and sometimes it is. But there is a real functional difference, and in this sector it usually decides the answer. A CMMS manages maintenance execution: assets, planned tasks, work orders, technicians, parts, history. An EAM manages the asset across its whole life: capital planning, lifecycle cost, integrity assessment, linear assets, and the finance integration that lets you talk about total cost of ownership rather than this month's spend. I have written the general version of this argument in the EAM explainer and the CMMS versus EAM comparison. Here is the sector-specific version.

Read that as a screening tool, not a verdict. If you carry a formal safety-critical element regime, linear assets, or a turnaround cycle, plan for EAM class capability, whether IBM Maximo, SAP PM, Hexagon EAM, Infor EAM or equivalent. If you carry none of the three, a well-implemented CMMS such as eMaint, Fiix, Limble, MaintainX or UpKeep will likely serve you better than a half-configured enterprise suite, and will be running in a quarter of the time. If you are still forming a view of the category itself, start with the CMMS buyer's introduction.

3. Safety-critical elements and performance standards

This is the concept that most distinguishes a high-hazard maintenance regime, and the one most often mangled during system implementation. In many regimes, operators of major hazard facilities are expected to identify the equipment whose failure could cause or substantially worsen a major accident, and to define for each one what it must do, how well, and how that will be assured. The naming varies by jurisdiction: safety-critical element, safety critical equipment, safety and environmentally critical element, independent protection layer. The principle is consistent even where the terminology and the legal basis are not.

A performance standard for such an element expresses what it must achieve in terms that can be verified. Practitioners often summarise this with the functionality, availability, reliability and survivability framing: what the barrier does, how much of the time it must be available, how dependable it must be when called upon, and what conditions it must keep working through. The maintenance regime then has one job: demonstrate that the element continues to meet its standard. Concretely, for the system of record:

• The register must be identifiable. Safety-critical elements need to be a queryable classification on the asset record, not a comment in a description field. You will be asked for the list, its assurance status and its open deviations, and you should be able to produce it in minutes.
• Tasks must trace to the standard. When someone asks why a test exists at that interval, the answer should be in the system, not in an engineer's memory.
• Deferral must be controlled differently. Deferring a routine filter change is an operational decision. Deferring a barrier test is a risk decision needing a documented assessment, compensating measures and an authorised approver. The system should make those two paths different, and should not let the second happen quietly.
• Test results must be values, not ticks. A gas detector test recording "pass" is weaker evidence than one recording response time and alarm concentration. Trendable values let you see a barrier degrading before it fails a test outright.
• Failures must be visible as barrier failures. A valve that fails to close on test is not a maintenance statistic, it is a barrier impairment, and the impairment should have a clock on it.

The pattern that works, in the teams I have worked with, is to treat the register as a controlled document owned by a technical authority, with the maintenance system as its execution and evidence layer rather than its owner. When the register lives only inside the CMMS and anyone with asset-edit rights can change a classification, the assurance story becomes hard to defend. Note too that criticality for ordinary reliability and criticality for major accident potential are related but not the same axis, which is worth reading alongside the general asset criticality classification approach.

4. Permit to work and isolation as a system function, not a bolt-on

On a process plant, a work order is not an instruction to start work. It is an instruction to start the process of becoming allowed to work. Between the planner releasing the job and a spanner touching metal sit permit issue, isolation, proving dead or depressurised, gas testing, toolbox talk and often a simultaneous-operations check. If those steps live outside the maintenance system, three things happen reliably. The schedule becomes fiction, because the system thinks a job is ready when the permit queue says it is not. The evidence trail fragments, because reconstructing who was allowed to do what on a given day becomes an archaeology exercise across two systems. And isolation conflicts go undetected, because nothing holds a single picture of what is currently isolated and which jobs depend on it.

What good looks like:

• Permit demand is planned, not discovered. The planner knows at scheduling time which jobs need which permit types, and the schedule treats permit-desk capacity as a real constraint. Permit throughput is very often the true bottleneck on a plant, not labour.
• Isolation plans are reusable objects attached to the asset. The isolation for a given pump should be authored once, reviewed and reused, not redrawn by whoever is on shift. Reuse is also what makes complex isolations auditable.
• The work order cannot be executed without the permit state. Not merely a warning. If the permit is not live, the job is not workable, and the technician's view of the day should say so.
• One live picture of current isolations, including long-standing ones, which have a way of becoming permanent if nobody is periodically forced to justify them.
• Close-out reinstates deliberately. Job complete does not mean plant restored. Isolation removal, override reinstatement and barrier return to service are distinct recorded steps, and a barrier left overridden after work is a classic contributor to serious incidents.

Two architectures work: a maintenance platform with native permit and isolation capability, or a specialist permit system integrated tightly enough that the two behave as one. What does not work is a spreadsheet permit register alongside a CMMS that knows nothing about it. The mechanics are in the permit to work and CMMS integration guide.

5. Risk-based inspection and its relationship to preventive maintenance

Static equipment, vessels, columns, exchangers, piping and tankage, degrades primarily through corrosion, erosion and cracking, and its inspection regime is usually set by an integrity discipline rather than by maintenance planning. Risk-based inspection is the established method: assess likelihood of failure from the active damage mechanisms and the consequence of failure, combine them into a risk ranking, and set inspection scope, technique and interval by risk rather than a uniform calendar. The reference literature sits largely with API and, for pressure equipment codes more broadly, ASME , and the applicable codes and their legal standing vary by jurisdiction.

The thing for a maintenance system owner to understand is the division of labour. Risk-based inspection is an assessment activity that produces a plan. Preventive maintenance is an execution regime that delivers one. Different disciplines, usually different teams, frequently different software. The failure mode I see most often is trying to make the CMMS the RBI engine, or letting the RBI tool schedule and dispatch work. Neither is designed for the other's job. The pattern that works:

• The integrity tool holds damage mechanisms, corrosion rates, thickness measurement locations, remaining life and risk ranking. It is the authority on what should be inspected, when and how.
• The maintenance system holds the inspection as schedulable work with a location, resource, permit requirement and completion record. It is the authority on whether the inspection happened.
• The interface runs both ways. Plan out to maintenance, results and measurements back to integrity to update remaining life and re-rank risk. A one-way interface degrades into two divergent truths within a year.
• Rotating and electrical equipment stays on a reliability-driven regime instead, which is where reliability-centred maintenance, industrial preventive maintenance and predictive techniques belong.

A caution on intervals: a risk-based regime can legitimately extend an inspection interval, but only for as long as the assumptions behind it hold. If the feedstock changes, the duty changes, or a corrosion rate proves higher than assumed, the basis of the extension has changed. The maintenance system's contribution is ensuring the inspections the extended plan still calls for happen on time, because a risk-based plan with poor execution compliance is worse than a conservative calendar plan executed properly.

6. Turnarounds and shutdowns: the dominant planning event

For a process facility, the turnaround is the largest single maintenance undertaking in the cycle. Large amounts of work can only be done when the plant is down and depressurised, so it accumulates against the next window, and that accumulation is precisely why scope control is the central skill. The phase structure below is the shape I would advise, with the caveat that durations depend entirely on the size and complexity of the event. Treat the timing column as relative ordering rather than prescription.

Two things there matter more than the rest. The gate column: a phase without a gate is a phase that leaks. And phase four.

A note on tooling: do not expect the CMMS or EAM to be your turnaround scheduler. The maintenance system should own the scope register, work orders, materials reservations, permit requirements and execution records. Detailed critical-path scheduling belongs in a project planning tool, linked so that field progress is visible on the schedule. Trying to run a large turnaround critical path inside a maintenance module usually ends with the real schedule living in a spreadsheet on the turnaround manager's laptop, which is the outcome you were trying to avoid.

7. Remote and offshore sites: connectivity and logistics

A great deal of the sector's work happens where the network is poor and the supply chain is long: offshore platforms, remote gathering stations, desert wellpads, pipeline pump stations, island terminals. All impose constraints a system designed for an urban campus will not survive. On connectivity, the requirement is not "mobile app" but genuine offline capability, and the difference is substantial:

• Offline must include creation, not just viewing. A technician needs to raise a defect, complete a task, record readings, attach photographs and consume parts with no network, then synchronise later. Many products offer offline read and online write, which is not the same thing.
• Conflict resolution has to be predictable, and the rule has to be understood by users rather than only by developers.
• Sync payloads have to suit the link. A constrained satellite connection will not enjoy full-fidelity photograph sync. Compression, deferred attachment upload and selective data scoping all matter.
• Test it on the real link, not the office wifi. The most consistent disappointment here comes from products demonstrated in ideal conditions and deployed onto a shared satellite connection.

On logistics, the consequences are less about features and more about how you plan. Where a part reaches site by supply vessel on a fixed schedule, or by helicopter with a weight limit, the material availability date is a hard planning input rather than a formality. Job packs must be complete before mobilisation, because a missing gasket on an unmanned wellpad is not a trip to the stores, it is a lost visit. Campaign maintenance, batching work by location so a visit accomplishes as much as possible, becomes the dominant scheduling pattern, so the system needs to group work by geography and access window rather than purely by trade or priority.

8. Contractor-heavy workforces and competence records

In much of this sector the majority of hands-on maintenance is performed by contractors, sometimes by several layers of them. That changes what the maintenance system has to control.

• Competence must be verifiable at the point of work. Confined space entry, working at height, hot work, high voltage switching, rigging and specialist welding all carry qualification requirements. Hold the certification against the person, with expiry dates, and block assignment to a task requiring a lapsed qualification. A certificate in a folder in the contractor's office is not a control.
• Authorisations are a distinct layer. Site-specific authorisations such as permit acceptance or isolation authority are granted by the facility, not the employer, and they lapse. Track them separately from trade qualifications.
• Work records must survive the contract. If job records, measurements and as-found conditions live in the contractor's system, you lose your asset history at every retender. Make the record location a contractual requirement.
• Scale of access is a real design problem. A turnaround can bring hundreds of temporary users onto the system for a few weeks. Named enterprise licences and slow onboarding make this painful, and the workaround, shared logins or a supervisor entering everyone's work, destroys the record. Ask vendors specifically about short-duration bulk access.
• Measure quality, not just completion. Performance measured only on tasks closed on time rewards paperwork. Rework rate, defect identification and completeness of as-found recording tell you far more.

9. Spares for long-lead rotating equipment

Spares strategy here is dominated by a category that barely exists elsewhere: expensive, slow-moving, long-lead insurance items for critical equipment. A compressor rotor, a turbine hot-section set, a specialist pump bare shaft, a custom exchanger bundle. Lead times run to many months, the items are frequently non-interchangeable between apparently similar machines, and the cost of not having one is production loss on an entirely different scale from the carrying cost.

Standard inventory optimisation, built around demand history and reorder points, does not help, because demand history for an insurance spare is usually zero and the economics are driven by consequence rather than consumption. What I would advise instead:

• Decide insurance spares as a documented risk decision. The holding is justified by consequence of unavailability against lead time and carrying cost. Record that reasoning, because in a cost-cutting cycle an undocumented expensive spare with no movement history is exactly what gets written off, and then needed.
• Bind spares to specific assets, not generic descriptions. "Rotor, centrifugal compressor" is not a usable stock record. Machine-specific identification and a clear statement of which tags a part fits are what prevent the discovery, mid-outage, that the spare does not fit.
• Manage preservation as maintained work. Stored rotating assemblies need shaft rotation, nitrogen blanketing, humidity control and periodic inspection. Raise PMs against stored items: a spare that has sat unmaintained for a decade is not a spare, it is an unknown.
• Repairable rotables need a cycle, not a stock level. Remove, repair, receive, certify, return to store. Tracking where a unit physically is and what its certification state is matters more than a quantity on hand.
• Reserve against the turnaround, early. Long-lead materials should be ordered against frozen scope and reserved so routine work cannot consume them in the interim. That discipline is a common weak point.

The broader mechanics of stores, reorder policy and MRO data quality are covered in the spare parts and MRO inventory guide. The point specific to this sector is that a meaningful share of your inventory value will sit in items the standard model tells you not to hold.

10. Integration with historians and control systems

A process plant is already instrumented far beyond anything a facilities operation has. Pressures, temperatures, flows, vibration, running hours and alarm records are already collected by the control system and stored in a process historian. That is an enormous maintenance data asset, and in most operations I have seen it is underused because it is not connected to the maintenance system. The integrations worth building, roughly in order of value for effort:

• Runtime and cycle counts driving meter-based maintenance. The simplest and usually the highest return. Scheduling on actual running hours and starts rather than an assumed calendar equivalent often reveals over-maintenance of standby equipment and under-maintenance of duty equipment.
• Condition thresholds generating work. A sustained exceedance, not a momentary spike, raising a defect automatically. The hard engineering is the filtering: an integration that raises a work order on every transient will be switched off within a month.
• Process data attached to work orders for diagnosis. The recent trend for the relevant tags should be reachable from the job. Cheap, and disproportionately useful for root cause work.
• Performance and degradation monitoring. Calculated indicators such as exchanger fouling, compressor efficiency drift or pump curve deviation feeding cleaning and overhaul decisions rather than fixed intervals.
• Maintenance state back to operations. The less common direction, and often valuable: making it visible in the control room that an item is under maintenance, isolated, or has a protective function overridden.

Architecturally, the governing constraint is that this crosses an operational technology boundary. Control systems are safety and availability critical, and the network segmentation around them exists for good reason; ISA publishes the zone and conduit model most operators build to. The pattern that gets approved is read-only, one-directional data egress from the historian through a controlled interface, with no path allowing the maintenance system to influence control. Anything resembling write access into the process domain will rightly be refused, and expect that conversation to be the long pole rather than the software work. I have written up the patterns in the SCADA historian integration guide and the SCADA to EAM integration guide.

11. The cost of getting this wrong, honestly

This is the section I would want a sponsor to read. In most sectors a weak maintenance system produces inefficiency: duplicated effort, poor visibility, bad decisions at the margin. In a high-hazard environment the failure modes are different in kind.

• You lose the ability to demonstrate assurance. The work may have been done competently and the plant may be perfectly safe, but if the records are incomplete or unretrievable you cannot show it, and after an incident undemonstrable assurance tends to be treated much like absent assurance. This is the most common way a technically adequate maintenance organisation gets into difficulty.
• Barrier degradation accumulates invisibly. An overdue test here, a deferred inspection there, an override left in place, a detector isolated and not reinstated: each defensible alone. What matters is the aggregate at a point in time, and a system that cannot show it is hiding your actual risk position from you.
• Deferrals become the operating norm. Deferral without a hard approval path and a visible count is how a compliant regime becomes a non-compliant one over three or four years, with no single decision anyone would point to as wrong.
• The turnaround overruns. An extended outage on a producing facility is expensive in a way that dwarfs the entire maintenance systems budget.
• Asset history is lost at contract boundaries. Years of as-found conditions and repair detail, gone because records lived with a contractor. You notice when you need to justify a life extension or diagnose a recurring failure.
• Data quality erodes trust, then usage. Once planners stop believing the backlog, they build private spreadsheets, and the system of record becomes a reporting shell with the real information outside it. That is the end state of most failed implementations and it is hard to reverse.

The pattern behind all of these is the same: documentation and evidence dominate. Not because paperwork is intrinsically valuable, but because the maintenance organisation's product is a demonstrably safe and available plant, and demonstrability is half of that. A system chosen for slick dispatch and weak on evidence retention is the wrong trade here, even though it is the right trade in plenty of other industries.

The idea to walk away with

In oil, gas and energy, the maintenance system of record is an evidence system that happens to dispatch work. That inversion is the whole insight. It is why asset intensity, lifecycle costing, linear assets and regulatory reporting usually push toward EAM class capability, and why the functions that decide success are the ones that look like overhead from outside: a safety-critical element register with traceable performance standards, permit and isolation control inside the work lifecycle, a two-way risk-based inspection interface, scope freeze discipline, genuine offline working, enforced competence, and a spares strategy that holds items the standard model says not to hold.

The honest counterweight: a CMMS is still right for some operations here. A single site with no formal safety-critical regime, no linear assets and no turnaround cycle does not need an enterprise suite, and buying one will cost years and deliver a worse-configured system than a good CMMS implemented properly. The mistake is not choosing CMMS. It is choosing either without first testing which of the three sector conditions you actually carry.

Final thoughts

The implementations in this sector that went well, in my experience, were not the ones with the most capable software. They were the ones where the maintenance organisation could answer, on any given morning, which barriers were impaired and for how long, which assurance tasks were overdue and who authorised that, and what the turnaround scope was and whether it was frozen. The software enabled those answers; it did not substitute for the discipline that produces them.

So take one practical action from this: try to produce those three answers from your current system today, without a spreadsheet and without asking an engineer who happens to know. How hard that is will tell you more than any vendor demonstration. And whatever you conclude about the system, confirm your actual obligations with your own regulator and technical authorities, because the regimes vary far more than any article can usefully generalise.

Related reading: CMMS vs EAM: when you outgrow a CMMS, EAM explained, Permit to work and CMMS integration, SCADA historian integration, Spare parts and MRO inventory, CMMS for manufacturing plants.