Maritime CMMS vs generic CMMS: what actually differs

The question comes up in nearly every fleet digitalisation project: does vessel maintenance really need dedicated software, or can the owner simply use the generic CMMS the group already runs in its shore workshops? It is a fair question. The licence is often cheaper, the IT department already knows the product, the contract is already signed, and on paper a pump is a pump.

The answer is not a matter of opinion. It comes down to a set of constraints that do not exist ashore, and that industrial CMMS vendors never had any reason to solve. This article works through them one by one, with the technical reasoning behind each, and ends with an honest decision grid: there are cases where the generic tool is the right call.

A ship is a mobile, self-contained site

This is the founding difference, and almost everything else follows from it. A shore workshop is a fixed point with permanent network. A ship is a mobile unit that must stay operational with no link to the office for days or weeks at a time.

Offline is not a convenience feature

The chief engineer who opens a crankcase at three in the morning mid-passage has to read the job plan, enter readings, close the work order and raise a spare parts request. With no network. If the tool shows a blank page, it will not be used: the engine room goes back to the notebook, and the owner has paid a licence fee for a paper log.

A maritime CMMS therefore runs on a local database on board. The application writes first to the ship, into a complete and self-sufficient database, then synchronises. A pure cloud CMMS does the opposite: it writes to a remote server and shows on board only what the network is willing to return. That is architecture, not configuration. You do not make an application work offline by ticking a box.

Synchronisation has to survive a satellite link

On board, bandwidth is shared between operations, navigation, safety and crew welfare. A satellite link is billed by volume, latency is high, and dropouts are normal rather than exceptional. That imposes three things on the software:

• differential synchronisation that sends only what has changed, never the whole database;
• a queue that resumes where it stopped when the link drops mid-transfer, with no duplicates and no losses;
• separate handling of heavy attachments, photographs and documents, which can be compressed, deferred or held until the next port call.

It also needs a clear conflict rule. When ship and office both edit the same work order during a period of no connectivity, which one wins? A maritime CMMS answers that by design, usually in favour of the shipboard record for anything relating to execution. A generic CMMS never asks the question, because in its model two versions of the truth cannot coexist.

This is also what decides whether the tool is used at all. A mobile work order is worth nothing in the engine room unless it functions without a network.

The asset hierarchy is not the same shape

An industrial CMMS organises assets as site, workshop, line, machine. A maritime CMMS organises them as fleet, vessel, system, equipment, sub-assembly, component. The difference is structural, not cosmetic.

The vessel is a structural level, not a label

Everything hangs off the vessel: certificates, crew, flag, stock, budget, port calls. In a generic tool the vessel becomes a simple site or location field. The result is that you cannot cleanly isolate the maintenance of a vessel that has been sold, cannot transfer equipment from one vessel to another while keeping its history, and cannot produce a compliance position per vessel.

Sister vessels demand a shared equipment register

A fleet of sister vessels carries the same main engines, the same generators, the same separators, often the same winches. The maintenance plan should be written once, deployed across every vessel concerned, then updated in a single operation when the maker revises an interval or when operational feedback forces a change.

Each vessel then keeps its own deviations: a re-engining, a winch replaced with a different model, equipment added after a survey. The tool has to handle that pairing of fleet template and local variant. A generic CMMS will have you create equipment one item at a time, on each vessel, with no link between them. Six months later the same alternator carries five different descriptions.

Without a shared register, no figure is comparable

The question a superintendent actually cares about is this: does this type of starting air compressor fail more often on this vessel than on the others? That can only be answered if equipment across the fleet shares the same code, the same category and the same definition of failure. It is the precondition for any meaningful reliability measurement, MTBF, MTTR and backlog included. A register built vessel by vessel produces numbers, not indicators. How the software structures the equipment register determines what you will be able to analyse three years from now.

Triggers are running hours, cycles and condition, not dates

A classic industrial CMMS triggers on the calendar, sometimes on a single meter. On board, the calendar is the least relevant trigger of all.

• Running hours: main engine, auxiliaries, generators, compressors, bow thruster. A vessel on deep-sea passage and a vessel alongside do not wear their machinery at the same rate.
• Cycles: generator starts, winch or windlass cycles, bow door and ramp operations on a ferry, survival craft launches.
• Distance run: it drives shaft line wear and hull fouling, and therefore fuel consumption.
• Measured condition: lubricating oil analysis, vibration readings, differential pressure across a filter, exhaust temperature per cylinder, anode wastage.

Readings and forecasting

Two mechanisms are almost always missing from generic tools. The first is the reading itself. On board, many counters are read by hand, watch by watch, and the software has to accept that entry, validate it, flag an implausible value, and also be able to pick a value up automatically where a data gateway exists, feeding genuine condition-based maintenance rather than a date reminder.

The second is forecasting. Knowing an overhaul falls due at 12,000 hours is useless without knowing when those 12,000 hours will be reached. The CMMS has to extrapolate from actual utilisation to answer the only question that matters in operation: does this job fall due before or after the next docking window? That is the reasoning that lets a technical manager group work into a planned off-hire instead of absorbing an unplanned one. Software that handles multiple meters and projects them thinks in terms of vessel availability. Software that handles dates thinks in terms of a diary.

Compliance is structural, not an optional module

This is the sharpest break of all. In shore industry, compliance is one use of the CMMS among several. On board it is the reason part of the system exists, and it is audited.

What the ISM Code requires of a maintenance system

Chapter 10 of the ISM Code requires that the ship and its equipment be maintained in accordance with established procedures, that inspections be held at appropriate intervals, and that records be kept. Paragraph 10.3 requires the identification of equipment and technical systems whose sudden operational failure may result in hazardous situations. Those critical items need a distinct status in the software: specific testing, standby arrangements, priority treatment when they run overdue.

Chapter 9 requires non-conformities, accidents and hazardous occurrences to be reported and analysed. That means a non-conformity object linked to the equipment, with corrective action, owner, due date and verification of effectiveness. A generic CMMS can handle a quality incident; it cannot produce the chain from non-conformity to corrective action to management review that an ISM auditor expects to see. Our article on the ISM Code and the CMMS sets out that mechanism in detail.

The class-approved planned maintenance system

Where the owner opts for an approved planned maintenance system, the classification society approves the plan and verifies its execution. Intervals become binding, records must be signed by the chief engineer, and certain jobs carried out under the scheme replace class surveys. Software that was never designed for this will not produce the documentation expected at the annual audit. See our article on the class-approved planned maintenance system.

Ship certificates and crew certificates

A vessel carries dozens of certificates: class, statutory, flag, insurance, safety equipment, each with validity dates, intermediate survey windows and possible extensions. The crew carry their own: STCW certificates of competency, medical fitness, specific training, MLC 2006 obligations. No generic CMMS knows these objects exist. They have to be built from scratch, with their expiry rules, their alerts and their attachment to a vessel or a person. In a maritime tool they are native, on both the ship certificate side and the crew certificate side.

Getting through a Port State Control inspection

During an inspection the PSC officer asks for evidence, and asks for it immediately: the maintenance history of one specific item, proof of the last test of a piece of safety equipment, the list of overdue critical jobs, the status of open non-conformities. A system that produces those outputs in a few clicks changes the tone of the inspection. A spreadsheet or a generic CMMS forces reconstruction, and it is the visible improvisation that draws further attention. Our article on avoiding a Port State Control detention lists the outputs worth preparing.

Crew rotate, so knowledge has to stay on board

In a shore workshop the same team works the same machinery for years. On board, people join, leave and move between vessels. The chief engineer who knew the separator's quirks will be gone in six weeks.

The consequence is simple: knowledge has to be written down. It lives in job plans, which set out the method, the tools, the isolations, the parts required and the expected measured values, and in the intervention records, which state what was actually done and found. A maritime tool pushes crews towards that discipline. A generic tool tolerates it but does not create it.

Rotation has a second, often underestimated consequence: permissions change. A second engineer promoted to chief must inherit the approvals attached to the rank, not to the name. Certifications follow the individual and gate access to specific work: high-voltage intervention, hot work, enclosed space entry. A maritime CMMS handles shipboard roles and checks the relevant certification at the moment a task is assigned. A generic tool handles stable named accounts, which means manually reassigning dozens of tasks at every crew change.

Spare parts logistics run on port calls, not on lead times

Nobody takes delivery of a spare part at sea. It is obvious, and it has deep consequences for how the software must handle procurement.

The real chain is long: need identified on board, approval by the office, supplier enquiry, order, delivery not to the ship but to a port of call, with a ship agent to receive, a freight forwarder to move it and a customs formality to clear. A part shipped as ship's spares in transit is not declared like an ordinary import. A package that reaches the right port the day after the vessel sailed is not a delivered package; it is a package to be reshipped, often at more cost than the part itself.

The CMMS therefore has to carry information a generic tool never anticipated: the target port, the date and duration of the call, the agent, weight and dimensions, customs documents, and tracking through to physical receipt on board. Above all it has to reason backwards: starting from the maintenance due date, working back through order and transit lead times, what is the last useful port? That is the logic described in our article on spare parts management at sea, and it is what separates marine procurement from workshop procurement, where the delivery address is a constant.

Some stock cannot be optimised away

An industrial CMMS optimises inventory: turnover, holding cost, calculated reorder points, clear out what is not moving. On board, part of the inventory sits entirely outside that reasoning.

Some spares are mandated by the classification society or the flag administration, by type and by quantity. SOLAS safety equipment has to be present, valid and in date: distress signals, lifejackets, breathing apparatus cylinders, liferaft replacement items. A turnover analysis would classify these as dead stock and propose writing them off. Writing them off means taking a deficiency at the next inspection.

The software therefore has to distinguish two kinds of stock: operational stock, which is optimised, and regulatory stock, which is monitored and renewed before expiry with no economic trade-off. It also has to raise the alert early enough before the useful port call, because replenishment depends on the trading pattern. This is one of the points developed in our article on MRO inventory and critical spare part stockouts.

Multi-vessel and multi-flag operation

An owner does not run isolated ships, but a fleet. He wants consolidated backlog, maintenance cost per vessel and per system, comparison between comparable units, a twelve-month view of class due dates. That requires genuine consolidation, and therefore the shared register described above.

But consolidation must not flatten local rules. Every flag has its own requirements: mandatory documents, intervals, the language of records, reporting formats, rules on retaining crew data. A vessel under one flag and a vessel under another in the same fleet do not produce the same paperwork. The software has to apply a rule per vessel while aggregating at fleet level.

There is also segregation to consider. An owner managing vessels on behalf of third parties, or a technical manager with several principals, has to guarantee that a user sees only their own vessels. That is a first-class function in a maritime fleet tool and an afterthought in a generic one.

Side by side: what each constraint demands

Where a generic CMMS is genuinely better

Fairness requires saying it plainly: on its own ground, an industrial CMMS is often better than a maritime one. It was built for that ground, and it has been built for longer.

• The shore workshop: the owner's store, the repair base, central stock, handling equipment and buildings. A maritime CMMS is rarely comfortable there.
• Supplier master data and structured procurement: framework agreements, tendering, catalogues, complex approval workflows, accounting integration.
• Cost accounting: detailed allocation, fixed assets, depreciation, internal recharging, native integration with the group ERP.
• Corporate document management and interfaces with HR systems where these are already in place.

The right split is therefore not one tool against the other, but each in its place: generic CMMS ashore, maritime CMMS on board, with an interface between the two. What remains is to define ownership. In practice the maritime tool owns the vessel's technical register, the maintenance plans, the meters, the records and the certificates. The corporate tool keeps ownership of supplier master data, spend commitment and accounting allocation. The interface then carries requisitions, orders, receipts and consolidated cost. That is a project, but a bounded one, and very different from rebuilding a maintenance discipline inside a tool that was never designed for it.

The cost question nobody prices properly

Comparing two licence fees tells you nothing. What has to be compared is the cost of reaching the same result.

Adapting a generic tool to marine use is paid for in three stages. First, configuration: creating the missing objects, certificates, critical status, fleet hierarchy, stock categories, reading screens. That is configuration work, quotable and achievable.

Second, custom development, for everything configuration cannot deliver: offline operation, the synchronisation engine, multi-meter due date forecasting, port call logic in procurement, regulatory reporting. These are structural developments, not screens.

Third, and this is the line item systematically left out of the initial comparison, maintaining that customisation. Every vendor release means checking, and sometimes rebuilding, whatever was developed outside the standard product. Every regulatory change is at your expense. Every new vessel, every new flag, every reorganisation reopens the work.

The decisive point is that last one. With a maritime vendor, the change forced by a new regulatory requirement is developed once and delivered to every customer. With customisation, you pay for it alone. The reasoning mirrors what we set out about spreadsheets in our article on the true cost of running maintenance on Excel: what is free to buy is paid for in hours.

Decision grid: when a generic CMMS is enough

There are situations where taking the group's tool is the right decision. This grid gives the markers.

Where to go next

If this comparison has settled the question of principle, two further reads follow in the natural order of a project.

The first is our complete guide to maritime CMMS: it sets out the functional scope, the modules, the roles on board and ashore, and how the software fits into a shipping company's organisation. That is the overview, worth reading once the decision in principle has been taken.

The second comes into play when comparing actual offers: our 32-criteria framework for choosing maritime CMMS software. It turns the requirements described here into verifiable questions to put to a vendor during a demonstration, from offline behaviour to the production of regulatory reports.

One last recommendation, whichever candidate you shortlist: run the demonstration with the network switched off. Ask to open a work order, enter a meter reading, attach a photograph and close the job with no connection, then restore the link and watch what comes through. Five minutes of that test separate the tools designed for shipboard use from the ones that merely claim it.