Technical and maintenance · Module 02
Planned maintenance system (PMS) for ships
Components, criticality and jobs that fall due on a running hour or a calendar, with postponement that has to be justified.
ISM Code, clause 10
What it is for
The requirement, and the problem
A planned maintenance system earns its keep in two moments: the morning a chief engineer decides what the day is, and the morning an inspector asks why a job was not done. Both are questions about the same rows, and both go badly when the system treats a job as a task with a date rather than as work on a component with a reason.
Here the component comes first. It carries its criticality and the basis on which that criticality was assigned, its class reference where a society has one, and its place in the plant. Jobs hang off components, so a postponement is visibly a postponement of work on something, and the history of a component is a history rather than a filter over a task list.
How it works
Three steps, on board and ashore
- 1
Register the plant
A component tree with criticality and class references, and jobs on it with intervals in days, running hours or both.
- 2
Work the due list
Each department sees what falls due. A job is closed with notes for the next person, the time it took and its checklist.
- 3
Postpone only with a reason
A postponement needs a risk assessment, and critical or statutory work cannot be pushed past its own maximum.
Example with demo data
What it looks like
A working picture of the module with demo data from the Ocean Pioneer — the same ship you find in the demo.
Try the demo — no account, in your browser, with the PIN 1234.
- Maintenance overview: overdue, due, and what follow-up is outstanding
- Jobs — filter, plan, postpone, close, print the job list
In detail
What the module does
Criticality with its basis written down
Critical is not a colour somebody picked. The component records why it is critical — class requirement, statutory requirement, or the company’s own risk assessment — and that basis is what the rest of the rules read.
Running hours, calendar or whichever comes first — said, never assumed
A job falls due by the calendar, by a counter — running hours, starts, cycles — or by whichever comes first, and it says which. A counter is read on board or entered ashore, never back in time — running hours never faster than the clock — and its daily rate puts a running-hour job on the calendar. A job planned on a calendar is never quietly satisfied by a reading, which is the commonest way a maintenance record becomes untrue.
Zero tolerance where the law gives none
On critical or statutory work there is no grace window. The product refuses to save a plan whose own tolerance would let the work overrun its statutory maximum — the refusal is in the domain, not a warning on a screen somebody dismisses.
Postponement with a real risk assessment
Putting a job off asks what the consequence is, what compensating measure is in place and who accepted it. Nothing is postponed by clicking Later.
Time used, and an estimate from last time
Hours are recorded against the job when it is closed, so the next occurrence is proposed with an estimate drawn from what it actually took on this vessel, not a figure typed once in 2019.
The history belongs to the component
Open a pump and you see every job done on it, every service report, every part fitted and every note left for the next person — across crew changes and across years.
In the app
On the bridge, on deck and in the office
The same records on a phone in a machinery space and on a screen in the office — with no signal, and synchronised when the link returns.
- Components — the plant tree, criticality, documents and history
- Service reports and parts fitted, filed against the component
The decision
The engineer adds the component, not the vendor
A chief engineer who finds a component missing from the register can add it, give it a criticality with a basis, and hang a job on it — from the vessel, offline, at 03:00. The alternative, a change request to an office that is asleep, is how registers drift away from the plant they describe.
A component, a job or a counter added on board is the same kind of row as one brought in from the old system, so there is no second-class data and no reconciliation project later. Only the old system’s history is kept apart, as what it said: nobody signed it here, and nothing is planned from it.
Works with
One product, not nineteen
Purchasing
Requisition to receipt, on the shipowner’s own thresholds, where nobody approves their own commitment.
The shipowner’s own policyDefects and observations
One button to report a defect or a safety observation, from any screen, by anybody on board.
ISM Code, clause 9Consumption
Fuel, lube oil and fresh water as a ledger, so the balance is derived rather than typed.
Bunker delivery note
Put one vessel on it for two months
No card and no implementation project. A company adds its own vessel and its own people on its own afternoon — and if it is not for you, you stop, with your data exported first.