EN NO

Modules · 02

Planned maintenance

Components, criticality and jobs that fall due on a running hour or a calendar, with postponement that has to be justified.

What it is for

The requirement

ISM Code 10.3 — FOR-2014-09-05-1191The company shall identify equipment and technical systems the sudden operational failure of which may result in hazardous situations, and provide for specific measures to promote their reliability. Criticality is therefore a property of the component, recorded with the reason it was assigned.

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.

The maintenance overview listing overdue and upcoming jobs with their components and criticality.
Pl. 01Maintenance: what is overdue, what falls due, what is waiting on follow-up.

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 or calendar, never both by accident. A job has exactly one interval and it is explicit. A job planned on a calendar cannot silently be satisfied by a running-hour 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.

Screens

What it adds to the app

  • Maintenance overview: overdue, due, and what follow-up is outstanding
  • Jobs — filter, plan, postpone, close, print the job list
  • 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.

Everything added on board is the same kind of row as everything imported, so there is no second-class data and no reconciliation project later.