IDMS vs CMMS: different jobs, one thread

What does a CMMS actually own?

A CMMS owns the work. Work orders, preventive maintenance plans, labor and crafts, parts and stores, downtime and cost history, backlog and the weekly schedule all live there. Its record of truth is the work order and everything charged against it.

Equipment exists in a CMMS as the thing work is charged to. The equipment master is tuned for cost rollups, functional locations and craft planning. That is the right design for maintenance. It is not designed to hold sixty condition monitoring locations on one vessel with fifteen years of readings each.

• Work orders and preventive maintenance plans
• Labor, crafts, crews and hours
• Parts, stores and purchasing
• Downtime and cost history by asset
• Backlog, priority and the schedule

What does an IDMS own?

An IDMS owns the inspection record. That means the equipment register at inspection granularity: vessels, piping circuits, CMLs, tanks, relief devices. It means the readings and their full history, the corrosion rates computed from them, remaining life, the next inspection date, the findings, the recommendations, and the evidence behind all of it.

Its record of truth is the reading and the calculation that turns readings into a date. To make that calculation defensible it has to carry design data: minimum thickness, MAWP, design code, material and the retest rules. It has to answer an auditor's question five years later, so provenance and history matter more here than they do in a maintenance system.

• Equipment register at CML granularity
• Thickness and other readings with method, date and gauge
• Corrosion rate, remaining life and interval with the code shown
• Findings, recommendations and the repair that closed them
• Inspection plans, RBI results and the reasoning behind them
• Evidence: photos, reports, radiographs and gauge data

Why not put inspection data in the CMMS?

It is tempting because the CMMS is already there and the equipment list is already in it. The trouble shows up at the CML level. A vessel with sixty CMLs, each with a decade of readings, and a rate calculation that depends on which readings were taken by which method, is not a work order. Custom fields can hold a number. They do not hold the calculation, the code basis, the retest logic or the audit chain an inspector must defend under API 510, API 570 or OSHA PSM.

Schedules are the second problem. CMMS preventive maintenance triggers are time or meter based. Inspection intervals are computed from corrosion rate and remaining life, and they change every time a new reading lands. Driving that from a PM plan means someone edits the plan by hand after every inspection, which is the exact toil an IDMS exists to remove. The usual outcome is a number in a CMMS field, the real work in a spreadsheet beside it, and two versions of the truth.

Why not run work orders from the IDMS?

The reverse mistake costs just as much. An IDMS that tries to be a CMMS ends up with a second parts list, a second crew roster and a second cost ledger that finance will not accept. Work execution belongs where planners, schedulers and stores already work.

When an inspection produces a recommendation that needs work, whether a repair, a replacement or an insulation strip to check for CUI, the IDMS should raise a request that becomes a work order in the CMMS, carry the work order number back onto the finding, and close the loop when the work completes. It should not try to schedule the crane.

How should an IDMS and a CMMS connect?

Three things make the connection hold. First, shared equipment identity: the same tag means the same physical asset in both systems, with one side declared the master for the equipment list and the other subscribing to it. Second, a defined handoff: finding to work request to work order to completion, with identifiers traveling in both directions. Third, an open API on both sides, documented well enough that your own team or integrator can build and maintain the link without a vendor project every time a field changes.

On the inspection side, intelliSPEC publishes its record through an OpenAPI 3.0 specification with 514 documented endpoints and tenant-scoped API keys, which is the shape a CMMS link needs: readable equipment identity, findings and recommendations, and a place to write work order references back.

• One equipment master, one subscriber, never two masters
• The tag is the join key, not the description
• A recommendation creates a work request, not a free-text email
• The work order number is written back onto the finding
• Completion date and as-found condition return to the IDMS
• Both APIs documented in OpenAPI or equivalent, with keys you control

What should you ask each vendor?

Ask the CMMS vendor whether equipment can be exported and synced by tag with a stable identifier, whether a work request can be created through the API with a reference to an external finding, and whether completion can be read back the same way. Ask the IDMS vendor whether equipment identity can be mastered elsewhere, whether a finding can carry an external work order number, whether the API is versioned and documented, and what happens when a tag is renamed on one side.

Neither answer should involve a bespoke project. If it does, the price of that project belongs in the evaluation, and so does the price of repeating it after every upgrade.