News Article 29/04/2008

Better methods for filing reports are needed (MEC: April/May 2008, page 14)

An effective software-based reporting methodology should eliminate unnecessary paperwork while allowing an operator to demonstrate competence, argues Mr. Dimitri Lyras

Reports fundamentally exist to announce an event to the right people and to track the resolution of a problem. But despite this simple purpose, it is unexpectedly difficult to design an effective reporting system. Imagine, for example, that an internal audit is due next week and that several issues need resolving on each ship. At the same time, there are telltale signs of other possible problems, but none of these have been formally reported.

Maybe fuel has leaked from a weld in the main engine service tank. The report says the tank has leaked for over eight months but it has not been specifically raised as a safety hazard. What is the root cause? What is the remedy? More to the point, why is it still outstanding?

An engine stoppage has never been reported, but the engine and deck log mentions it, and there is a major purchase order associated with it. A risk or root cause analysis was probably carried out when the problem first arose, but there is no evidence of such in any formal report.

Measures are often taken on an ad-hoc basis to mitigate risk and evidence sometimes remains in the form of a lengthy email dialogue, but the specific remedial actions are not consistently recorded. Furthermore, once one problem has been solved another might need attending to, so the defects or other non-conformances of the original are forgotten about and thus never properly documented.

Clearly a key reason that so many problems go unreported is that writing everything down seems like extra work that only delays the remedial process and appears to produces no tangible benefits. The end result is that reports often fail to keep up with events.

There is also the question of how reporting should be carried out in emergency that requires immediate corporate co-ordination. No matter how urgent a report is, even one that requires immediate action, no guarantee exists that it will reach the correct people in time. An engine stoppage report, for example, may not reach the operations and technical manager until the next day.

Furthermore, the discussions needed to arrive at a good plan of action often occur over the phone or in an e-mail. Trying to document every correspondence in a report is impractical because it will slow down the discussion; however the risk mitigation measures discussed in meetings or through e-mail dialogues would benefit from previous experiences or knowledge held elsewhere in an organisation. Each problem is therefore dealt with in isolation without any systematic reference to what went on previously; also there is no guarantee that any of the lessons learned in resolving the situation at hand will then be recorded in a way that allows them to be accessed in the future.

An additional challenge is that some of discussions may involve root cause investigations and solutions that participants would prefer are kept off a report and definitely not chronicled in an official record.

Therefore an effective reporting system should be designed to allow efficient co-ordination and quick resolution of problems as they occur. It should ensure that the correct people are involved and that efforts made to resolving the problem are recorded in a transparent manner. It should provide a database of past experience – both as a way of preventing past problems from occurring again and as resource for solving a new but similar situations. Furthermore, the system interface should enable the database to be added to as people work – not as a separate task creating more work.

Initial reports need to be simple and easy to complete. Completing them should not require any more than a 30-second narrative specifying the processes that will fail immediately if some resolution is not found. Deck officers and engineers, are normally too busy to spend more than a very short time writing, indexing, and sending the report.

It is important that discussions linked to the report focus on the processes that are at risk and processes that seem to be the immediate or root cause of a problem. For example, it is more important to know that a missing manufacturer’s circular resulted in a million dollar loss, than to know that a manufacturer’s circular was missing because of an office rearrangement. It is more important to record that an injury was caused by a poorly planned lifting process rather than record which body part injured.

Discussions and their conclusions should be separable. Discussions need to be informal and flexible to achieve coordinated thinking, and the participants should not have to be worried that every word will be recorded. It is only the conclusion that is needed for demonstrating competence and for the gathering of corporate experience.

Remedial action will inevitably take place as soon as the responsible parties begin to act, and the reporting system should not impede this process. However, it should make the process transparent to other stakeholders. All remedial actions should be linked to the report and authorised participants should be able to view ongoing discussions and the remedial actions at any time.

In conclusion, information extracted for co-ordination purposes should be a byproduct of what the stakeholders perceive as their primary work. Any extra work to inform others is bureaucracy. Software reporting systems should make information easily accessible at the right time and to the right people.