91�鶹��Ʒ

A CMMS requirements specification is not paperwork. It is the single document that decides whether the vendor responses you get back can be compared at all. When it is vague, every vendor answers a different question, quotations vary by a factor of three with no way of knowing why, and the owner ends up choosing on gut feel. When it is precise, price differences become readable and the technical dead ends surface before signature rather than six months into service.

This guide is for fleets that have already made the decision in principle: the spreadsheet has run out of road and a maritime CMMS is going in. What remains is writing the document you will send to vendors. Each section below sets out why it matters, the mistake people make, and requirement wording you can lift straight into your own specification, replacing the values in square brackets with your own.

Scope: the section that distorts everything downstream

Scope is the first section of the document and the only one every vendor reads end to end, because it drives the price. A badly framed scope does not produce a quotation that is a few per cent out. It produces a quotation that means nothing.

Put on paper: the number of vessels and their types, the flags involved, how users split between ship and shore, the technical organisation (one superintendent for the whole fleet, or a manager per vessel), and where you expect to be in three years. A six-vessel operator heading for fourteen should not be renegotiating its licence at the first acquisition.

The usual mistake

Counting vessels and forgetting users. A ferry with four engineer officers, a chief officer and a three-person shore technical team is not the same licence load as a 24-metre netter with a skipper and one engineer. The second trap is failing to state whether double crewing counts as one user or two. That is the line that pushes the budget off course at the first crew change.

Requirement wording

• SCO-01 — "The solution shall cover [N] vessels at go-live, with the capacity to extend to [N+X] vessels over the contract term without architectural rework or data migration. The tenderer shall state the pricing applied to adding a vessel mid-contract."
• SCO-02 — "The vessels in scope are: [type, length, flag, trading area, crew complement] for each. The tenderer shall state whether the solution requires a separate configuration per flag."
• SCO-03 — "The organisation comprises [N] seagoing users and [N] shore users. The tenderer shall state whether pricing is based on named accounts, concurrent sessions or vessels, and how rotating crews are treated."

Offline working: never write "must work offline"

"The software must work offline" is the most useless sentence in a maritime CMMS specification. Every vendor will answer yes. Some mean a full on-board application, some mean a read-only cache, and some mean a form that queues and loses the entry if the app is closed.

The way to write it is to specify three things separately: what must be viewable without connectivity, what must be creatable or editable without connectivity, and what happens on resynchronisation. The third point is what genuinely separates products. Two engineers, one on board and one ashore, edit the same job plan while the vessel is out of coverage. What does the system keep, what does it flag, and to whom?

The usual mistake

Accepting thirty seconds in flight mode as proof. Offline behaviour is judged over a voyage, not over a demo. Ask explicitly for the maximum time the application can run disconnected and the volume of data held locally.

Requirement wording

• OFF-01 — "With no connectivity whatsoever, a seagoing user shall be able to: browse the complete equipment hierarchy for the vessel and its attached documents, view the maintenance plan for the next [90] days, raise and close a work order, enter a counter reading, report a defect with a photograph, and check on-board spare parts stock."
• OFF-02 — "The application shall operate disconnected for at least [N] days with no loss of entered data. The tenderer shall state the volume of data replicated locally and the behaviour of the application if device storage is exhausted."
• OFF-03 — "On resynchronisation the system shall detect concurrent edits to the same object, retain both versions and raise the conflict to a nominated role for resolution. Silent overwriting of a shipboard entry by a shore entry shall be treated as non-compliant."
• OFF-04 — "The tenderer shall describe the synchronisation protocol, the bandwidth consumed by a typical daily synchronisation, and whether synchronisation is viable over a low-bandwidth satellite link."

The equipment register: depth, sisterships, migrating what you already have

The register is the foundation. Everything else — maintenance plan, history, spares, costs — hangs off it. Too flat a hierarchy and you will never know whether the recurring failure sits in the turbocharger or the charge air cooler. Too deep and nobody fills it in.

Three things matter. Hierarchy depth: vessel, system, equipment, sub-assembly, replaceable component, with the ability to go down to serial-numbered items. Sistership replication: on a fleet of identical ferries, rebuilding the register vessel by vessel is weeks of work and guarantees divergence. And migration of existing data, which is almost always underestimated.

The usual mistake

Writing "migration of existing data" without saying what format that data is in. Yours sits in a forty-tab workbook, a scanned PDF of the yard's machinery list, and the head of a chief engineer who retires in the spring. Those three sources are not migrated the same way and do not cost the same. Say which ones you will hand over, and in what form.

Requirement wording

• EQP-01 — "The register shall support a hierarchy of at least [5] levels (vessel, system, equipment, sub-assembly, component), with free attributes at each level and the ability to attach a serial number, a manufacturer and documentation to any node."
• EQP-02 — "The solution shall allow the register and maintenance plan of one vessel to be copied to a sistership, then allow vessel-specific deviations to be managed without breaking the link to the fleet template."
• EQP-03 — "Migration covers the following sources: [spreadsheets, yard machinery lists, extract from the current tool, maker documentation]. The tenderer shall state the import formats accepted, the volume that can be processed, the number of trial loads included, and whether data cleansing is performed by the vendor or the client."

Maintenance plan and triggers: where generic tools fall over

This is the section that separates a maritime CMMS from a tool designed for a fixed site ashore. Elsewhere, preventive maintenance is almost always calendar-based. On board it is mixed: the main engine overhauls on running hours, safety equipment on date, injectors on a combination of both, and some items on measured condition. If your specification does not describe that mix, you will buy a diary.

The point that catches products out is combined triggers. "Every 500 hours or every 12 months, whichever falls first, with the counter reset on completion" is an ordinary rule at sea and impossible to express in many tools. Ask for a demonstration on exactly that case. The second point is tolerance: a 500-hour job done at 512 hours alongside is not an overdue task, it is completion inside the accepted window, and the system has to record it as such.

On building the plan itself, our four-step guide to a preventive maintenance plan covers what has to exist before any software is opened.

Requirement wording

• PMS-01 — "The solution shall support calendar, running-hours, cycle and condition-threshold triggers, and their logical combination (AND / OR) on a single task, with automatic counter reset when the job is closed."
• PMS-02 — "Each task shall carry a configurable tolerance expressed in days and/or running hours. A job completed within tolerance shall not be counted as overdue in reporting."
• PMS-03 — "A job plan shall hold as a minimum: the detailed steps, the associated parts and consumables, the estimated duration, the qualification required, the applicable safety precautions and the reference documents."
• PMS-04 — "Deferral of a due date shall be recorded with author, date, reason and new due date, and shall require approval by an authorised role beyond [N] days of deferral."

Compliance: ISM, class, certificates and Port State Control

This is the section non-maritime vendors dispose of with one generic sentence about "regulatory compliance". It deserves to be the most detailed part of your document, because it is where the difference lies between a convenient tool and one that keeps a deficiency off your report.

Four blocks to cover. The records required under the ISM Code: the safety management system requires evidence that the vessel and its equipment are maintained, and that evidence has to be producible at audit. Critical equipment under chapter 10.3 of the Code, for which specific measures and periodic testing are expected: the system must let you flag those items and treat them differently from the rest. The class-approved planned maintenance system, if your fleet falls under one, with its own reporting and traceability constraints. And certificates, vessel and crew, with expiry alerting. Our articles on ISM Code compliance supported by a CMMS and on class-approved planned maintenance systems go into each of these.

The usual mistake

Requiring only that "data shall be retained". A Port State Control inspector does not ask for data, he asks for a file, on a screen, in a few minutes, usually in English. Specify production of the document, not just storage of the records.

Requirement wording

• CMP-01 — "The solution shall allow equipment to be identified as critical under chapter 10.3 of the ISM Code, allow specific tasks and periodic tests to be attached to those items, and produce a list of that equipment with the status of its due dates at any given date."
• CMP-02 — "The system shall produce, in under [5] minutes and without vendor involvement, an exportable PDF file covering a given item or system: the full maintenance history over [period], parts replaced, personnel involved and attached documents. The file shall be available in English and [second language]."
• CMP-03 — "The solution shall manage vessel and crew certificates with issue date, expiry date, inspection window, attachment and configurable alerts at [90 / 60 / 30] days, addressed to separate ship and shore recipients."
• CMP-04 — "The tenderer shall state whether the solution is already in use within a class-approved planned maintenance scheme, and with which societies."

Stock and purchasing: start from the part-to-equipment link

A CMMS that manages stock without tying it to equipment is no better than an inventory list. The only question that matters on board is which parts go with this machine, and which of them do I actually have. Everything else follows from that.

The second maritime-specific point is location. A part can be in the ship's store, in a compartment on board, in the shore depot, or in transit to the next port of call. Those four situations are different and a single-site stock model does not represent them. Our article on MRO inventory management and critical spare part stockouts develops the threshold logic in detail.

The usual mistake

Forgetting the mandatory spares required by class or flag. They are not managed like consumables: they must be flagged as mandatory, their consumption must raise a tracked replenishment, and their absence must be visible before the survey rather than during it.

Requirement wording

• STK-01 — "Each stock item shall be attachable to one or more items in the equipment register, with maker reference, internal reference and physical location. From an equipment record, the user shall reach the list of compatible parts and their availability by storage location directly."
• STK-02 — "The solution shall manage alert thresholds per item and per storage location, distinguish on-board from shore stock, and allow an item to be flagged as a mandatory spare under class or flag requirements."
• STK-03 — "Closing a work order shall automatically decrement the stock of parts consumed and, where applicable, raise a replenishment request linked to the equipment and vessel concerned."
• STK-04 — "The purchasing cycle shall cover: requisition, [N]-level approval routing with value thresholds, supplier enquiry, order, partial or full receipt, and invoice matching."

Users, roles and audit trail: the crew-change problem

On board, shared accounts become the norm whenever nobody has specified otherwise. One workstation in the engine control room, one login taped to the screen, and the entire history becomes useless — for audit and for failure analysis alike. The specification has to close that door from the start.

The maritime-specific issue is the crew change. A second engineer joining for six weeks should inherit a role, not an account. The system must allow rights to be granted and withdrawn in seconds, without deleting the outgoing user's history, and without an account staying live six months after they signed off.

Requirement wording

• USR-01 — "Every user shall have a named account. Rights shall be granted by role (chief engineer, second engineer, master, superintendent, purchaser, read-only auditor) and adjustable vessel by vessel."
• USR-02 — "Every creation, modification or deletion of a record shall be time-stamped and attributed to an identified user. The audit trail shall be tamper-proof: no permanent deletion shall be possible from the interface, including by an administrator."
• USR-03 — "Closing a job shall be capable of requiring approval by a role other than the person who carried out the work, with electronic signature or recorded approval, configurable by task type."
• USR-04 — "The solution shall allow an account to be disabled immediately on sign-off without loss of the attached history, and the role to be taken over by the relieving user."

Data: ownership, export, exit and hosting

This section belongs in the specification, not in the termination letter. Once the contract is signed your negotiating position is gone. Several years of fleet maintenance history is a substantial technical asset, and on the day you decide to change tools the only thing that will matter is what the contract says.

Four points. Ownership of the data, stated unambiguously in the client's favour. Export format, which must be structured and usable rather than a PDF running to thousands of pages. Exit at end of contract, with a deadline and a defined scope. And hosting, with the physical location of the servers and the backup arrangements.

Requirement wording

• DAT-01 — "The client remains the owner of all data entered, imported or generated, including attached documents and audit logs. The contract shall grant the vendor no right to use that data for any purpose other than delivering the service."
• DAT-02 — "The client shall be able to trigger, at any time and at no additional cost, a complete export of its data in a structured and documented format, accompanied by a data dictionary and including attached files."
• DAT-03 — "At the end of the contract, for whatever reason, the vendor shall provide the full export within [30] days and certify deletion of the data after a retention period of [90] days."
• DAT-04 — "The tenderer shall state the physical location of the data, backup frequency, retention period, restoration procedure and the restoration time following an incident."

Integration: ERP, finance, payroll and shipboard systems

Integration is where unpleasant surprises cost the most, because it never shows up in a demonstration. Two families to treat separately.

On the management side: ERP, accounting, payroll. What moves between them is orders, receipts, invoices, cost centres per vessel and sometimes labour time. State the direction of each flow and its frequency. On the shipboard side: automation, alarm and monitoring systems, data gateways. Pulling running hours automatically off an NMEA 2000 bus removes the most ordinary source of error in a maintenance plan: the counter reading that was forgotten or copied out wrong.

The usual mistake

Settling for "API available". Ask for the public API documentation, the call limits, the authentication method, and whether access is included in the subscription or charged as an extra. An API priced per connector changes the economics of the project.

Requirement wording

• INT-01 — "The solution shall expose a documented API accessible to the client, supporting as a minimum read access to equipment, work orders, stock movements and orders. The tenderer shall provide the link to the public documentation and state the call quotas."
• INT-02 — "The tenderer shall describe integrations already delivered with [name of ERP or accounting system] and state, for each, whether it is a maintained standard connector or bespoke development, together with its cost."
• INT-03 — "The solution shall support automatic population of running-hour counters from shipboard systems, or failing that by scheduled file import."

Rollout, training and support: the section written too fast

The software rarely costs as much as the time it takes to get it running. This section has to answer three plain questions: who migrates the data, who trains the users, and who answers when something jams at three in the morning European time because the vessel is off Singapore.

The most commonly overlooked point is the support time zone. Support "during office hours" from a single country does not cover a worldwide fleet: for an operator trading in South East Asia, a 09:00 to 18:00 European window falls in the middle of the night on board, which is precisely when the watch needs an answer. Write the hours in UTC, not as "business hours".

Requirement wording

• SUP-01 — "The tenderer shall state the split of data migration work between vendor and client, the number of implementation days included, and the unit cost of additional days."
• SUP-02 — "Training shall cover seagoing and shore profiles separately, in English and [second language], and shall include a means of training a newly joined crew member without involving the vendor. The tenderer shall state the format (on site, remote, written material, video) and the duration."
• SUP-03 — "Support shall be reachable from [HH:MM] to [HH:MM] UTC, [N] days per week, via [channels]. The tenderer shall commit to a first-response time of [N] hours and a time to engage on blocking incidents of [N] hours, measured in calendar hours and not in business hours."
• SUP-04 — "The tenderer shall describe the procedure that applies when a vessel reports a fault while out of network coverage."

How to structure the document, section by section

A CMMS specification runs to fifteen or thirty pages. Beyond that nobody reads it in full and the answers get vague. This is the structure that lets you evaluate responses without losing the thread.

Separate mandatory from desirable

Every requirement should carry a level: mandatory (a negative answer eliminates the tenderer), important (scored and weighted), desirable (used to separate equal scores). Without that distinction every vendor answers yes to everything and you have nothing left to compare. Three or four knock-out requirements is enough; beyond that you will have no candidates left.

Number every requirement

Codes such as SCO-01 or OFF-03, used throughout this article, are not decoration. They let you demand a response requirement by requirement, in order, with a coverage level and a comment against each. A vendor who replies with a brochure instead of a line-by-line table has already told you something about the rest of the relationship.

Weighting the criteria and evaluating the responses

Weightings are set before responses arrive, and shared with tenderers. That is what stops anyone adjusting the weights afterwards to make the preferred vendor win. The split below is a starting point, to be adjusted to the fleet: a deep-sea fishing company will raise the weight on offline working, a ferry operator that on compliance and availability.

Score on a short scale

Four levels are enough and stop half-marks creeping in: 0 not covered, 1 partially covered or covered by a workaround, 2 covered as standard, 3 covered as standard and demonstrated on your own data. Level 3 is only awarded after a demonstration against a script you wrote yourself. For example: raise a work order offline against an auxiliary engine, consume two parts against it, resynchronise, then produce the equipment history file.

Score cost separately

Do not bury price inside the functional grid. Ask for a full five-year cost: subscription, implementation, data migration, initial and refresher training, options, cost of adding a vessel, cost of adding a user. That is the only way to compare a low-subscription, high-implementation offer against one built the other way round. Our analysis of the true cost of a spreadsheet against a maritime CMMS gives the reasoning framework for building that total.

Where this step sits in your project

The specification is the second of three stages in a CMMS project, and it achieves little if the other two are skipped.

Before: compare what is on the market and understand what genuinely separates a maritime CMMS from a generic one. If that is where you are, start with our 32-criteria grid for choosing maritime CMMS software. It tells you what to look at before writing anything.

After: roll out. Once the vendor is chosen, the project is won or lost on data migration, crew buy-in and the first weeks of real use. Our maritime CMMS implementation checklist picks up the thread from signature onwards.

One last piece of method: have a chief engineer read the document before you send it. He is the one who will enter the data every day, and that read-through is what removes the theoretical requirements nobody will ever use. If you want to test your draft specification against real cases from fishing fleets, ferries, pilot boats or service vessels, get in touch.

Once the requirements document is written, selection and rollout follow a path we set out step by step in the complete maritime CMMS guide.