Knowing your ship and the people running it
Tanker Operator, June 2010, p.2
Imagine going on board a vessel on a typical superintendent visit. During your stay you need to make an assessment of the vessel and you have the relevant assessment forms to fill.
Joining the ship and making an external inspection of the machinery does not go deeply into how the ship is being run. A spreadsheet of rudimentary schedule of upcoming maintenance helps but is it enough? And how much of the machinery is in open display? For instance it is easy to assess ballast tank condition by entering a tank and deck condition by observation. But machinery?
There are of course, log-books and instruments yielding information; but how much of the machinery condition can be assessed by looking at these? Naturally an inspecting superintendent will have a spreadsheet for main overhauls showing when main machinery overhaul is due. But the ship has thousands of smaller items of machinery whose condition affects the management of the ship, its history, its ability to face external audits successfully, and can influence staff performance during operation etc. On the other hand, emails to and from the ship, with information about machinery and spares are hard to assemble and rarely cover any particular machine comprehensively. Calibration forms are useful but there are rarely more than 30 machinery components whose condition is covered by them and even there the condition is not described in full detail.
Therefore, there is fundamental need for a collaboration tool where the superintendent and the chief engineer discuss and exchange information about many hundreds of machinery components on a regular basis. This system prepares the superintendent who is about to inspect a ship by providing him/her with what he/she needs to know: what is due for maintenance, what experiences were gained in recent overhauls, what parts are typically used, what the status of spares deliveries is, what special know how is required for a successful overhaul etc. Without such a tool the visiting superintendent can do very little and the technical manager ashore will gain little benefit from the vessel inspection.
However, if the chief engineer does not find the collaboration tool a useful and comprehensive system, all he will use is a spreadsheet to communicate next due overhauls to the office. And that, plus a few calibration sheets is all that the superintendent has to rely on when assessing the condition of a ship. Is this enough?
A computer’s role
Imagine how valuable it is for a chief engineer, familiarising with a new vessel to find out in one go that there is a problem with the main engine manoeuvring system because a particular pneumatic slide valve is slow to change position; that the diesel generator sea water low flow alarm is out of commission; or that the shell and tube oil cooler has pitting on the tube ends and could cause a leak.
Computer software can be programmed to know when to give advice and in doing so it is a far better tool than people, because computers don’t forget. However, one of the prerequisites is that the software is used to a sufficient extent so that it can detect the instance requiring advice. The more computers are involved in the operation of vessels, the more they can contribute with just-in-time alerting and advice.
There are two ways of warning people efficiently - one is to provide the warning at a time when it is highly relevant, while the second is to warn them in the context of what they are about to do and while they are focused on the issue.
By organising a company-wide information system properly, it is possible to provide familiarisation and warnings at the correct instance to influence the critical issues to which operators pay attention.
To achieve this, the company must have a computerised information system that combines as many on board and ashore functions as possible in order to provide the user with information at the point of need. It’s no good having stacks of information that the user is not in the habit of referring to because, doing so is outside the user’s series of actions for the task at hand and will be ignored.
To efficiently assemble corporate memory and experience, the process of assembly must not be a separate task from the day-to-day duties of company personnel either on board or onshore; it must be a by-product of their work.
In any organisation, most situations leading to corporate memory and experience are in some way recorded during some process or instance. The next concern -one of design -is that after capturing the situation, for example the pitting on the tube ends mentioned previously, this information appears where it will matter most; at the time when the diesel generators performance and reliability needs to be assessed.
The quest to make the system convenient for the chief engineer is at the root of the success of any planned maintenance or purchasing system to be used on board. It follows that its success ashore is based on exactly this as well.
Task orientation means that any functionality in an application, any document, any folder, any content, or, in technical terms, any object, can be located by its relationship to a business function whose identity is totally familiar to the user. It means that all enterprise processes are broken down into tasks, which are identified together with their relevant contexts in relationship to the roles performing them, the users performing the roles and the business units to which the roles belong – hence the development of Ulysses’ Task Assistant software.