Maritime
IBM Maximo for maritime: vessels, ports and terminals
Maximo Application Suite for maritime estates: vessels and shore-side infrastructure managed in one platform, aligned to class-society survey regimes and real operational maintenance windows.
One defect, five beats
A purifier coupling cracks mid-crossing
What the crew do, and what reaches the equipment record at each beat.
-
03:20, at sea
The second engineer finds the crack and makes the unit safe.
Written Finding, meter reading and photograph recorded against the purifier, offline.
-
Next sync
The queue clears in the order it was captured. Nothing aboard waited on connectivity.
Written The record attaches to the equipment rather than to an inbox, under ownership rules set before go-live.
-
Crew change
The incoming engineer opens the equipment history before taking over the watch.
Written Nothing new. The reading and the working theory are already there.
-
Sister vessel, six months on
The same failure appears, and the superintendent takes it to the class surveyor.
Written A repeat, because both events carry the same classification and failure code.
-
Dry dock
The coupling is in the specification the yard prices rather than in the growth work found once the vessel is out of the water.
Written Deferred work carried its own history from the day it was raised.
Nothing in that sequence needs better engineers. It needs capture once, at the equipment, and a decision taken in advance about who owns each field across the gangway.
Who keeps score
Class, flag and port state read the same record differently
Maritime oversight is layered, and each layer asks a different question of one maintenance history.
| Ref | Scorekeeper | Asks for | Will not accept |
|---|---|---|---|
| MT1 | The classification society: Lloyd’s Register, DNV, ABS, Bureau Veritas or the society the vessel is classed with | Survey items completed inside their windows, with the work, the findings and the close-out evidenced against the item surveyed. | A survey marked complete with no work record behind it. A continuous survey arrangement depends on the trail. |
| MT2 | The flag administration, or a recognised organisation acting for it, auditing the safety management system under the ISM Code | Inspections at appropriate intervals, non-conformities reported with corrective action, and the maintenance regime demonstrably inside the safety management system. | A documented planned maintenance system the crew do not use. An audit establishes that in the engine room, not in the manual. |
| MT3 | Port state control inspectors, coordinated under arrangements such as the Paris Memorandum of Understanding | Immediate on-board evidence that safety-critical equipment is maintained and that defects are being managed. | Evidence that has to be requested from ashore. If it cannot be produced aboard during the inspection it does not count. |
| MT4 | Flag and port states, enforcing the SOLAS and MARPOL conventions | Maintenance and testing of life-saving, fire-fighting and pollution-prevention equipment, recorded against the specific item. | A vessel-level record. The inspection belongs to the extinguisher, the boat or the separator. |
| MT5 | The flag administration, following IMO guidance on cyber risk in safety management systems | Cyber risk to the systems supporting the safety management system identified, assessed and managed. | Shared generic logins aboard. An action that cannot be attributed to a person is not a controlled action. |
| MT6 | The harbour authority, against the Port Marine Safety Code, with Department for Transport oversight | A documented risk-based approach to marine safety, with the condition of marine infrastructure maintained and evidenced. | Condition assessment held only as a consultant report. It has to land on the asset record to drive work. |
Codes MT1 to MT6 are stable, so a superintendent or bid writer can cite one by reference.
In conversation with Milos
Milos Jakovljevic
Head of Architecture · 12+ years in software architecture and EAM
Milos on the decisions taken before the first vessel is loaded
- What makes a maritime estate an architecture question?
-
Most of the asset base is somewhere else and it is moving. The superintendent is accountable for equipment they last saw four ports ago, maintained by a crew that has rotated twice since. Everything difficult follows from that: which side owns a field, when the two sides reconcile, and what happens when they disagree.
- Why IBM Maximo rather than an onboard planned maintenance system?
-
The vessels are not the whole estate. Terminals, quays, cranes and workshops draw on the same capital budget and the same technical function. An onboard system does the ship well and stops at the gangway. Maximo holds vessel, terminal and shore infrastructure in one register without bending any of the three, so the fleet view and the finance view look at the same objects.
- What do you settle before anything is built on top of it?
-
Ownership across the gangway. For every attribute both sides care about, one side owns it and the other reads it, and conflict resolution is deterministic and written down. A sync after a crossing then has a defined outcome instead of a negotiated one. Left late, that decision gets taken by whoever writes the interface.
- What does an upgrade look like on a fleet?
-
We took a UK ferry operator from Maximo 7.6 to MAS 9.0 in seven months, including cloud migration, integration retest and inventory rework. What sets that timeline is the integration inventory and the environments rather than the version gap, which is why we engineer both to be operated rather than delivered.
Milos owns the architecture of every MaxIron Maximo and MAS deployment, including how upgrade paths are engineered.
The gangway
One owner per field, published before build
MAR-GANGWAY-01
Where vessel and shore both care about an attribute, one side writes it and the other reads it. The frequency column is the honest part: a queued field is accurate ashore as of the last sync.
| Field | Source | Target | Frequency | Owner |
|---|---|---|---|---|
| ASSET.CLASSSTRUCTUREID | Shore technical | Vessel | On change | Technical superintendent |
| PM.NEXTDATE | Shore survey register | Vessel | On change | Superintendent with class surveyor |
| WORKLOG + DOCLINKS | Vessel | Shore | Queued, next sync | Chief engineer |
| MEASUREMENT.MEASUREMENTVALUE | Vessel | Shore | Queued, next sync | Chief engineer |
| MATUSETRANS | Vessel storeroom | Shore inventory | Queued, next sync | Second engineer |
| PR.STATUS | Vessel | Fleet purchasing | Queued, both ways | Fleet purchasing |
Boundaries
Four boundaries on a maritime engagement
The fleet view moves at the speed of the sync
Offline capture makes the vessel workable. Ashore, a superintendent sees the position of a job aboard as of the last sync, and the design states that in writing before go-live.
The chief engineer keeps the decision on the night
No routine is raised into a window in which it cannot physically be done, so the tie-up list is achievable and carries its history. What runs tonight stays the engineer’s call.
Certification is settled between you, your flag and your class society
Maximo holds the planned maintenance regime and the evidence behind it. Whether the safety management system satisfies your flag administration is decided in that conversation, and we prepare the evidence for it.
Vessel and shore convergence is phased across releases
Standardising item masters and storerooms across a fleet touches purchasing habits built over decades, some of them specific to a route or a yard. We phase it and publish the sequence.
Where this ran
The shape of one maritime upgrade
- Upgrade
- Maximo 7.6 to MAS 9.0 in seven months
- In one register
- Vessels, terminals and shore infrastructure
- Onboard capture
- Offline and queued
A UK ferry operator, on time and on budget, including cloud migration, integration retest and inventory rework.
What sets an upgrade timeline is the integration inventory and the environments rather than the version gap crossed.
What this needed from the client
- A named owner for every field that crosses the gangway, agreed before build.
- Chief engineers available to review the tie-up window against the PM list.
- The survey and continuity register, in whatever form it exists today.
Maximo for maritime, questions we are asked
- Can one Maximo carry a vessel fleet and the shore-side estate?
- Yes. Vessel, terminal and shore infrastructure each get a hierarchy an engineer in that domain recognises, inside one register that rolls up for finance. The design work is in the storeroom structure, because vessel stock and port warehouse stock behave differently, and in the ownership rules for fields both sides care about.
- How do you handle class society survey cycles and flag state inspection?
- Survey types, intervals and continuity windows are modelled as work rather than as reminders, so a window approaching its limit appears where the superintendent is already looking. The same records answer flag state audit and port state control, which is what the ISM Code means by a planned maintenance system inside the safety management system.
- What does Maximo do on a vessel with intermittent bandwidth?
- Capture is offline and queued, and nothing aboard blocks on connectivity. Field ownership is decided before go-live so a merge after a crossing has one defined outcome. Bandwidth is treated as a shared operational resource rather than an assumption, which is why the fleet view is stated as accurate to the last sync.
Bring your last dry-dock specification and one overnight tie-up.
The specification shows how much scope was discovered rather than planned. The tie-up list shows whether the maintenance schedule fits the operation it belongs to. Between them they show most of what we need to know about the estate.
Bring this to the first call
- The last dry-dock specification, with the growth work marked
- The PM list generated for one overnight tie-up, as it was issued
- The survey and continuity register, wherever it lives today
- The vessel-side stock list for one critical rotating equipment package