Update Sep 2009

Proper information management helps to avoid inconsistencies during inspections.

A typical vetting inspection
A vetting inspector goes on board a vessel and asks for the bridge and engine room alarm log printouts for the last 2 days of the voyage just ended. He looks at them and makes the following enquiries: there is an alarm at 00.30 indicating low SW pressure in auxiliary diesel engines. Who attended the alarm, how long was he attending it, where is it mentioned in his work rest periods, why did the alarm occur, what has since been done to assess risk of losing SW cooling pressure on all 3 generators causing the ship to be immobilised?
He then looks at the ships log and notices that the ship stopped a half hour after leaving the port of Rotterdam and again a month earlier just after leaving port. He asks for the reason and the master replies it was a main engine issue. But nothing is reported in the engine log as a reason. He asks for a defect report but there is none. He asks for the master’s report on considerations made before stopping the vessel within the shipping channel. Again no report! Obviously both the master and chief engineer put considerable thought into the risk aspects of stopping the vessel and the actual problem at hand. However nothing was reported except the stoppage itself. Is this what they want? Is this what the head office wants? Probably no one wants this.

Why is reporting inconsistent today?
So what is the likely reason for not reporting?
People are not clear about what constitutes quality management. Some feel that the less discussed in writing the better. Others feel that whenever they do discuss something in writing they end up answering never ending lists of questions as if they are statisticians.
In many accidents and near accident reports, there are questions about the particular hazard, whether it is fire, injury, containment etc. Rather more relevant is what process has failed and which one is about to fail. These are the questions someone responsible will either want to be helped with or at least want other people to know about.
Have we imported into the shipping industry risk and root cause or even just accident reporting systems totally unsuited to the user on board?

Those that feel no reporting is better have the massive burden of eliminating all traces of events that could exist even in places like purchase orders. Nothing could be a greater waste of time than trying to eliminate information to avoid audit inconsistencies. This is especially the case with today’s modern vessels, high maintenance standards, and high machinery reliability.

The system has to be useful to the person initiating a report
If there is a simple answer here, it is that reporting has to help the person reporting. If a defect is to be reported, the reporting process needs to help solve the immediate problem or its potential knock on effects. If it does not, what’s the incentive for reporting it? Whereas, if the chief engineer reports a defect and immediately can see what similar behaviour has been experienced by his predecessor, we are off to a good start. If the superintendent can easily see the entire story behind a defect, including what spares have been ordered to rectify it and past reports of repairs, he might actually find the system useful.
So practicality and common sense need to be the cornerstone of any management system. There is no room for badly conceived examples from other industries with different personnel, different risks, different risk mitigation measures and above all different process details.

If a management system is designed with a view to please auditors it may succeed once or twice but it soon becomes sidelined by the people who actually need it to report and primarily used by those who face the auditors.

Worse still, an auditor’s job is to find the inconsistencies. How many inconsistencies would you expect in a system that involves all your vessels but is not significantly helping them do their job so that no one uses it as an everyday operational aid? Can you be sure your officers and superintendents are looking at your system as closely as an auditor? If not, what value does a system that creates liability but offers no day to day benefit, have for you?

Incident reports
Most accident, incident or even defect reports we have seen, have far too many questions. Furthermore, the primary question, if the report is going to be of any use to the initial on board officer who is reporting, has to do with resolution. If this officer needs help to solve the problem or wishes to inform others so that they can be prepared in case the problem escalates, the questions are simple “What is the immediate effect of the problem and how can it escalate”?
We have seen very few systems with such simple questions. There are various reasons for this. One is that the form used assumes that there is only one opportunity to bring a sweeping amount of questions and selections of possible answers to the attention of the person reporting. As if electronic forms are somehow like paper forms and need to be stapled together to say the whole story! Stringing several constituent parts of a report together is a key design issue where the challenge is to get each piece of the report completed by someone who gets some benefit from reporting. For example, the on board officer is not the one who should be concerned about what categories the problem is filed against for future audits or for KPI while office managers are. So the electronic system needs to allow companies to design their own forms, but also to split them up so that the right person is answering the right question. For example, if the problem has a known cause, further root cause analysis is not usually a responsibility of the on board officers. It is the responsibility of the company that “owns” the management system and the ships’ hardware. It is the company that has the highest stake-holding in arriving at a conclusion about root cause so as to avoid repeated occurrence.
All in all an electronic system that has proper routing and workflows can extract the right information from the right stakeholder at the right time. This enhances the right kind of reporting that achieves essential co-ordination and makes external audits much less prone to expose inconsistencies.

Task Assistant® aims in minimizing bureaucracy
Ulysses has built an enterprise model within its Task Assistant® software which accurately profiles the shipping industry in its working environment, anticipating data exchanges and staff interactions sufficiently in order to deliver information at the point of need.

The system, designed to be intuitive enough to minimise bureaucracy, has been tried for twelve years by customers demanding its flexible adjustment to the analysis they have done of their business processes while retaining usability and configurational ease.

Task Assistant® separates what the user needs now from what the user needs later, while bringing together information from different sources. The user finds information indexed against his current activity and the particular context defining this activity, which could be, time, geographical location, a machine component etc. Without the user initiating a search, it will do the job of digging into the entire system to find what is relevant for this task, this voyage, this port, this cargo, this pump or any other area of focus characteristic to the marine business.
Having first proven its suitability to generalising the important indices of any data or content management process, we now consider the model ready to step up to the challenge of managing co-ordination at an enterprise level without additional bureaucracy.

Conclusion
Reporting as a by-product of people’s primary work. Reporting has the main function of alerting stakeholders of their impending need to attend. This is a primary co-ordination issue. It should strictly be a by-product of what officers and managers perceive as their primary work. Any extra work is bureaucracy.

Involving people at the right moment in a process is a test for a system’s intuitive design because information, if it is truly to assist in co-ordination, needs to be delivered to the correct person, neither too early or too late but exactly when he needs to be involved in a process. For example, the fleet manager needs to be informed about the low SW pressure on a vessel at a certain moment only after the quality and technical departments have been informed and the master and chief engineer have started dealing with it and only if higher level processes for which the fleet manager is responsible are likely to be affected.