No owner digitalises maintenance because it is modern. They do it because, at a particular moment, the way they were tracking their ships stopped holding together. This article is about that decision — the one taken at group level, not the one taken on board a single vessel. The step-by-step mechanics of a rollout are covered elsewhere. Here we look at what an owner actually expects from digitalisation, what it changes between ship and shore, how to hold one data standard across a mixed fleet, and how to tell whether it worked.
The distinction is not academic. A single-ship project is judged when the rollout ends: the system is live or it is not. A fleet project is judged two or three years later, on whether the owner can compare vessels, defend the technical budget and stop depending on what a handful of people happen to remember. Almost every decision that determines that outcome is taken before the first work order is ever raised.
Why Owners Decide to Digitalise
The Triggers You Actually See
In practice, the decision almost always follows a dated event. An internal ISM audit that raises a finding on maintenance of critical equipment and on the evidence of testing. A Port State Control inspection that records a documentary deficiency even though the work had been done. The departure of a chief engineer who was the sole holder of the history of two main engines and three generators. A drydocking whose work list was closed three weeks before the ship entered the dock, with the cost overrun that follows. Or, more prosaically, the arrival of the fourth or fifth ship — the point beyond which spreadsheet tracking stops being a saving and becomes a risk, as set out in our analysis of the true cost of running maintenance on spreadsheets.
These triggers have one thing in common: none of them is technical. It is not breakdowns that push an owner to digitalise, it is the organisational consequences of breakdowns. An owner running three ships can absorb improvisation, because one person still holds the whole picture. An owner running fifteen cannot: improvisation does not scale, and nobody holds the whole picture any more.
What the Question Is Not
The question is not how to replace the ship's binder with a screen. It is: what does the owner need in order to arbitrate between vessels? Deciding whether to overhaul the injectors on ship A this year or push it a season, whether to commit to a major overhaul on ship B or wait for ship C's drydocking, means being able to compare. Comparing means both ships describe their equipment and their work the same way. That is where digitalisation earns its place: it is not a shipboard tool, it is a fleet tool.
It is also why the choice of system turns on owner-level criteria rather than on how pretty the interface is. Our selection framework for marine CMMS software works through those criteria in detail. The short version: software that works perfectly on one ship and badly across a fleet is not a fleet solution.
What the Fleet Gains, Ship by Ship and Group Wide
The expected benefit is not the same depending on where you stand. A chief engineer and a technical director are not looking for the same thing in the same system. Confusing the two is the most common reason projects disappoint: the owner buys a management tool, the ship receives a data-entry tool, and nobody is satisfied.
| Level | What digitalisation delivers | How you see it |
|---|---|---|
| On board | The day's work is known without negotiation, equipment documentation is available at the job, a crew change no longer loses information | Less time spent hunting for a drawing or a part number; handover between chief engineers without a catch-up meeting |
| Per vessel | Continuous history for each item of equipment, time-stamped evidence of completion, on-board stock known before the port call | A class survey or an inspection is prepared from existing records, not reconstructed from memory |
| Group wide | Comparability between ships, consolidated technical budget, informed arbitration on major work, corporate memory independent of individuals | The technical director can answer "which ship costs most and why" without ringing five people |
The Most Underrated Benefit: Memory
In a shipping company, knowledge of the vessels sits with individuals. A second engineer knows that the port-side cooler on number two generator has been fouling faster since a change of lube oil supplier. That information exists nowhere. It leaves with him. Digitalisation does not create that knowledge, but it makes it transferable — and it is often the one benefit owners mention unprompted three years after the rollout.
Step 1: Frame the Decision at Fleet Level
Define the Scope Before Choosing the System
A fleet project is framed by subtraction. Anything not decided at the outset will be decided by default, ship by ship, and will produce exactly the inconsistency you set out to remove. Three questions are enough to frame it: which ships are in scope and in what order, which data is migrated and which is abandoned, and who ashore has the authority to settle a disagreement between two vessels.
That last question is the most important and the most often dodged. If the fleet data standard has no named owner, there is no fleet data standard: there are as many standards as there are ships.
What Has to Be Settled at Group Level
- Equipment coding and the depth of the hierarchy
- The criticality scale and its definition — the same one for a trawler and for a ferry
- The counter units used (running hours, days, cycles) and who reads them
- The level of detail expected in a job report
- How statutory obligations are attached to the maintenance plan
On that last point, if the fleet includes ships whose maintenance programme is approved by the classification society, the framing has to take in the constraints of that regime. They are set out in our article on the class-approved planned maintenance system. A fleet standard designed without them will have to be redone, and reworking a hierarchy mid-rollout costs more than the framing it was meant to shortcut.
Step 2: One Data Standard Across Different Ships
This is the hard part. A fleet of twenty ships rarely contains twenty comparable ships: an owner may run deep-sea fishing vessels, a passenger ship, two workboats and a pilot launch at the same time. The equipment does not share makes, intervals or obligations. Trying to standardise everything produces a structure nobody uses; standardising nothing produces twenty databases sitting side by side.
Standardise the Structure, Not the Content
The rule that works is simple: impose the structure, leave the content to the ship. Two vessels must describe a separator the same way, at the same level of the hierarchy, with the same criticality and the same wording. The actual maintenance interval for that separator, on the other hand, comes from the manufacturer, the duty cycle and the classification society — not from a company rule.
| Element | Decided group wide | Left to the ship |
|---|---|---|
| Equipment hierarchy | Number of levels, equipment families, naming rules | The equipment actually fitted on board |
| Criticality | The scale and its definition | Where a given item sits, argued by the ship |
| Job plans | The format of the job plan and its mandatory sections | The tasks and intervals taken from manufacturers' manuals |
| Spares and store | Coding, units, default reorder thresholds | The critical spares held on board and where they are stowed |
| Job reports | What is always required (reading, photograph, part fitted) | The technical detail of the job |
The Job Plan Format Is the Real Consistency Tool
A fleet becomes comparable the day two equivalent jobs on two ships produce two reports that read the same way. That comes from an imposed job plan format, with mandatory sections and explicit acceptance criteria. The work is described in detail in our article on job plans and work quality standards. It is the highest-return investment in the whole project, and the one most often skipped.
Mixed Fleets: Three Common Set-Ups
Holding a single data standard is not equally difficult in every fleet. Three set-ups come up repeatedly, and each calls for a different answer.
A Fleet of Sisterships
Several ships built to the same design, with the same machinery. This is the easiest case: the hierarchy replicates almost as it stands and the job plans copy across. The trap lies elsewhere — the ships have drifted apart over the years, a generator was replaced on one, a winch modified on another. Replicating without verifying produces a database that is tidy and wrong. Replicate the structure, then have each ship validate the actual inventory line by line before go-live.
A Fleet in the Same Trade but of Different Ages
Fishing or workboat units doing the same job, some twenty-five years old and some three. The equipment families are common, the technology is not: mechanical counters on one side, a PLC and a data bus on the other. The shared standard holds at the level of families and criticality; what differs is how readings are collected. Better to accept two collection methods than to impose pointless manual entry on the modern ship, or an impossible automation on the old one.
A Fleet of Different Trades
A mixed operation with a passenger ship, two coasters and a workboat. Direct ship-to-ship comparison means little here: trading patterns, statutory obligations and engine-room manning have nothing in common. The shared standard narrows to vocabulary, the criticality scale and the report format. Consolidation then happens by equipment family rather than by ship: you compare auxiliary engines with auxiliary engines, not the ferry with the coaster.
Step 3: Phasing the Rollout Without Blocking Trading
No owner can roll a CMMS out across twenty ships at once. Not because of the software, but because the scarce resource is not IT: it is the ship's time and the technical department's time. A rollout is therefore planned like a campaign, in waves and around windows.
Choosing the Pilot Ship
The pilot ship should be neither the newest nor the most troublesome. The newest gives a result that is too easy and does not transfer. The most troublesome makes the system carry the weight of problems that are not its own. The right pilot is a representative vessel with a chief engineer who has time served in the company and a personal interest in making it work.
Waves and Windows
A realistic pace depends on the trade. A ship on short rotations offers frequent but brief windows. A deep-sea fishing vessel offers few windows, but long ones. A drydocking is a good window for equipment inventory and a poor one for training, because everyone is occupied elsewhere.
| Wave | Content | Preferred window |
|---|---|---|
| Pilot (one ship) | Full hierarchy, main job plans, critical spares, crew training | Normal trading, not a drydocking |
| Wave 1 (same ship type) | Replication of the validated standard, per-ship adjustments | Long port calls, crew changes |
| Wave 2 (different types) | Extension of the standard to equipment families not yet covered | Drydocking for equipment capture, trading for training |
| Wave 3 (one-off units, ships near end of life) | Reduced scope, focused on compliance and critical equipment | As opportunity allows |
How Much History to Migrate
The temptation is to migrate everything. It is a classic fleet-level mistake, because data migration consumes the technical department's time at exactly the moment it is needed elsewhere. A workable principle: migrate the data that drives a future decision — counters, last major job per critical item, live statutory due dates, actual stock. Archive the rest as it stands and let history rebuild itself through use. Our marine CMMS implementation checklist takes that sequence phase by phase for a single ship.
What a Wave Really Costs
The most common planning error is to count configuration time and forget collection time. Reading nameplates, opening store lockers, tracking down the manual for equipment fitted fifteen years ago: that work happens on board, done by people who already have a watch to keep. On a medium-sized vessel it is measured in engineer-days, not hours. The only honest way to estimate it is to measure it on the pilot ship, extrapolate to comparable vessels, and revise after the first wave — because the first estimate will be wrong.
Step 4: Proving It Worked
A fleet project you do not measure is a project you will not be able to defend at the next budget. The difficulty is that owners rarely measure the state they started from: with no baseline, improvement gets narrated instead of demonstrated. So the first useful measurement is taken before the rollout, on the pilot ship, with whatever means are to hand.
The Indicators, and What They Really Say
| Indicator | What it measures | The trap |
|---|---|---|
| Planned maintenance completion rate | Execution discipline and how realistic the plan is | A rate close to 100% usually signals an under-scoped plan, not an exemplary fleet |
| Backlog in labour hours | Work waiting, and therefore how honest the planning is | A zero backlog generally means the ship is not declaring its deferrals |
| Share of corrective work in total labour hours | The real balance between unplanned and planned work | Falls automatically if small jobs stop being recorded |
| Time from defect report to closure | How well the ship-shore-purchasing chain flows | Depends as much on port logistics as on maintenance |
| Findings raised at audit or inspection | The quality of documentary evidence | Small sample: read it across several years and several ships |
How these indicators are built, and in particular how MTBF and MTTR are calculated on marine equipment, is covered in our article on maritime maintenance KPIs. One point is worth making straight away: across a fleet, the absolute value of an indicator matters less than the spread between comparable ships. The spread is what triggers a useful question, and it is the spread you should track over time rather than the fleet average, which describes no real vessel.
The Financial Case Comes Later
Expecting an immediate saving from the rollout is poor arithmetic. In year one, digitalisation reveals spending that already existed but was not visible: the technical budget appears to rise when in fact it has simply become legible. The serious comparison happens in the second budget cycle, on items that can be reconstructed — parts consumption per item of equipment, contracted work costs, drydocking cost drift.
What Changes Between Ship and Shore
Data Entry Moves Down, Decisions Move Up
Before, the ship carried out the work and reported by message; the office reconstructed the picture. Afterwards, the ship records at source and the office sees it continuously. The shift is real: the chief engineer becomes the producer of the data that will be used to arbitrate his own budget. That is a change of standing, and it should be stated as such. Presenting a CMMS as a simple tracking tool, when it makes shipboard work permanently visible from ashore, produces a legitimate resistance that no amount of training will undo.
The Micro-Management Risk
The price of visibility is the temptation to intervene. A superintendent who sees an overdue work order the same day and telephones the ship will destroy confidence in the system within weeks: the ship learns to declare only what does not trigger a phone call. The rule that protects the project is to state explicitly how often shore looks and at what thresholds it reacts. That point, along with the other CMMS rollout mistakes made on board, decides the fate of a deployment far more often than the choice of software.
Roles That Need Naming
- The chief engineer: accountable for the truthfulness of the ship's data, not just for entering it
- The superintendent or technical director: owner of the fleet data standard and arbiter of differences between ships
- The designated person ashore, in the sense of the ISM Code applied to vessel maintenance: guarantor of the link between the maintenance plan and the safety management system
- The purchaser or storekeeper: without them, the inventory side of the project stays theoretical
What a CMMS Will Not Fix
An honest project states its limits. A CMMS does not create time on board: if the engine-room complement is already stretched, it moves the constraint rather than lifting it. It does not make bad data reliable: a rushed hierarchy produces wrong indicators with a good-looking presentation. It does not replace competence: knowing that a bearing is running hot does not tell you why. And it does not remove the connectivity constraint, even if a properly built offline mode makes it liveable on ships that spend weeks outside coverage.
Finally, it does not align a mixed fleet by itself. Consistency across twenty ships is human work, continuous, and it degrades the moment it stops having an owner. A company that rolls the system out without naming that owner will find itself, two years later, back in the situation it wanted to leave — with a database instead of spreadsheets.
From Fleet Strategy to Rollout
Once the fleet decision is taken and the data standard framed, the work changes nature: it becomes a project, with phases, deliverables and decision points. Two resources pick up where this article stops. Our marine CMMS implementation checklist sets out the chronology of a rollout, from data preparation to go-live on board. The article on the most frequent rollout mistakes describes the failure modes we see and how to spot them early.
On the software side, multi-vessel management — consolidated indicators, a shared data standard, comparison between units — relies on specific functions, set out on our fleet management page. If you want to test your own situation against comparable rollouts, our team can be reached through the contact page.
Each of these four stages is developed at greater length in the complete maritime CMMS guide.
.png){kind=small}
