Ship Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the equipment hierarchy get scoped as assets and tasks?

The first design most software teams draw for maintenance is an asset with tasks attached. It is the pattern every facilities maintenance product uses and it is wrong for a ship by roughly two levels.

A vessel has systems, systems have equipment, equipment has components, and jobs attach at different levels depending on what the job is. A liner renewal belongs to a component. A performance check belongs to the equipment. A survey item may belong to the system. Flatten that into assets and tasks and you lose the ability to say that a critical component was overhauled while the equipment around it was not, which is exactly the question an inspector asks.

The other half of the scope failure is the job library. Sister vessels share most of a maintenance regime and differ in specific places, because equipment was substituted during construction or modified since. A design that copies the library per vessel means a correction has to be applied ten times and will be applied to seven.

The fix is to insist on the model before the features. Vessel, system, equipment, component, job, with jobs attaching at the correct level, and a shared library with per vessel variation recorded as a documented deviation rather than a fork. Ask a prospective developer to draw it. A team that draws assets and tasks has built a facilities tool and has not met a main engine.

What goes wrong when you migrate the job library and equipment register?

Migration is almost always the largest single line item in a ship management build, and it is the one most often underestimated because it looks like moving records. It is not. The job library and equipment register hold years of accumulated engineering knowledge about your specific vessels: intervals that were adjusted after a failure, jobs added following a class recommendation, local notes about which valve is actually the one that matters.

The failure mode is a bulk load that technically succeeds. Jobs arrive with their intervals but not their history, so due dates recalculate from the migration date and half the fleet appears simultaneously overdue on day one. Running hours come across as a single current figure rather than a series, so nothing can be checked against it. Chief engineers open the new tool, see a list that does not match what they know about their own machinery, and quietly keep using their own spreadsheet.

The fix is a phased migration with a parallel run. Start with a single vessel class, migrate that class only, and run the incumbent system alongside for a full quarter so discrepancies surface while there is a fallback. Migrate history, not just current state, especially running hours as a series and completed job records with their evidence. Have a superintendent and a chief engineer review the migrated library for one vessel line by line before the rest follow. Budget this as its own workstream with its own schedule.

Why do ship to shore synchronisation and accounting integrations break after launch?

A vessel goes dark. Modern satellite services have improved bandwidth substantially, but connectivity still drops, and while it is down the crew must retain full functionality. When the link returns, the same maintenance job may have been updated onboard and ashore. What happens next is the single most important engineering decision in the system and it is usually specified as a bullet point.

Last write wins is the default that gets chosen by accident, and it silently discards work. A chief engineer records a completed overhaul with a measured clearance during a six hour outage, a superintendent edits the same job ashore to adjust the interval, and one of those two disappears with no trace. The crew notices, loses confidence, and starts keeping a parallel record, which is the outcome the whole project was meant to prevent.

Accounting integration fails differently and more slowly. A purchase order raised against a vessel budget line posts to a finance system that reorganises its cost codes at year end, and the mapping quietly stops matching.

The fix on sync is a named rule per field with an audit entry, so a conflict is resolved deterministically and both versions remain visible. The fix on accounting is to reconcile totals back to the finance system on a schedule rather than trusting the mapping, and to treat a cost code change as an event that requires a mapping review rather than something the integration should absorb.

What happens when class survey planning and certificate windows are not covered?

This is the gap that most first releases defer and it is where the avoidable money sits. Class survey regimes define windows rather than dates, and credit is given when work is completed and attended or reported correctly. Statutory certificates carry their own windows with anniversary and range rules. Flag requirements sit on top and differ.

The typical management is a spreadsheet of expiry dates with conditional formatting. That handles expiry and completely misses the planning question, which is which items can be attended at a port the vessel is already calling at with a surveyor available, and which are heading for a dedicated attendance that forces a deviation. Operators who plan on expiry dates alone routinely pay for several separate attendances a year that could have been credited during a scheduled call.

The fix is to model survey items with their windows, their credit conditions and their attendance requirements, then plan them against the vessel's actual trading pattern and the next dry dock. The output that matters is a twelve month forward view telling the superintendent which items can be closed opportunistically and which need booking now.

Should you build custom or configure what you already own?

If you manage fewer than about five vessels of similar type, do not build. SERTICA or Hanseaticsoft Cloud Fleet Manager configured properly will cover planned maintenance and procurement, and your superintendent can hold the fleet picture in their head. Money at that scale belongs in the vessels.

For managers of roughly ten to thirty vessels the answer we give most often is to keep the planned maintenance system and build the management layer on top. The onboard planned maintenance functionality in ABS Nautical Systems, BASSnet, DNV ShipManager, Cloud Fleet Manager and SERTICA represents years of maritime engineering that is not worth rewriting. What is worth building is the shore layer: readiness scoring, survey planning against trading pattern, owner specific budget reporting and requisition to delivery port coordination. That layer reads from the incumbent and lands at the lower half of the first release band.

Build fully when you manage a diverse fleet for multiple owners with genuinely different reporting requirements, when your incumbent is so heavily customised that upgrades are projects in themselves, or when the shore reporting everyone relies on is already a set of Excel files built from exports. That last condition is the clearest signal there is, because the spreadsheets are a specification and somebody is already maintaining them at considerable cost.

How do hidden costs get into the quote?

A first release covering planned maintenance with evidence capture, a defect register, requisition to purchase order and reliable ship to shore replication runs $110,000 to $250,000 across 16 to 24 weeks for a fleet of about ten vessels, in our delivery experience. Adding survey and certificate planning, dry dock specification, budget against actual with multiple reporting structures, readiness scoring and crew handover takes it to $300,000 to $750,000 across 9 to 18 months. The overruns come from four places.

Vessel type variety matters far more than vessel count, because each type carries its own equipment hierarchy and job library, so a fleet of twenty across two classes is cheaper than twelve across six. Migration is the second and is usually the largest single item, as described above. Onboard deployment is the third: installing and supporting software across crews in different time zones with variable connectivity is a real operational cost that never appears in a software estimate. The fourth is genuine offline capability with deterministic conflict resolution, which is engineering rather than a sync library and should be priced as such.

What separates a build that works from one that fails here?

One page that answers a single question: would this vessel pass an inspection tomorrow. Readiness is a function of overdue critical maintenance, open defects on equipment covered by the safety management code, certificate and survey status, drill and training records, spares held for critical equipment and the last internal audit. Every one of those exists somewhere and no packaged module assembles them, so a superintendent covering eight vessels relies on relationships with chief engineers.

The builds that work compute readiness continuously from a weighted rule set your own technical management owns, and let anyone open a component of the score and see the underlying items. The output is not a traffic light for a slide. It is a ranked list of the five things standing between this vessel and a clean inspection, each with an owner and a date. Operators who have this stop being surprised, and being surprised is the expensive part.

The second separator is evidence proportionate to criticality. A completed job on critical equipment should carry a photograph or a measured value rather than a tick, readings should record their source and time with divergence from expected hours flagged rather than accepted, and a postponement should be a request with a reason, an approver and an expiry. It is that a chief engineer who postpones a job for a good reason should be able to prove the reason existed, because six months later during an audit the good reason is the only thing standing between the vessel and a finding.

Then settle ownership in writing before kickoff. You should own the repository, the cloud accounts, the job library and all equipment data. At Digital Heroes the client owns both code and data from the first commit, and any developer treating your maintenance library as their platform content is a risk to the fleet.