News Article 19/08/2011

"Document Management for Maritime"

Digital Ship, August 2011, p. 22-23

A good document management system can help company employees, on land and at sea, to do their jobs more efficiently. However, the intricacies of the maritime industry require different technologies to those used in land-based companies, writes Dimitris Lyras, Lyras Shipping and Ulysses Systems

A document management (DM) system is not just a place to store documents that can be electronically reproduced at any location. This is only a small part of its value. The document management system manages forms. Forms are not only common documents you open from different locations, like websites or electronic books or plans that can be seen across continents.Forms are a combination of commonly accessible documents and e-mail – they have the characteristics of documents as well as the characteristics of e-mails. E-mails and similar concepts, like SMS messages, do not disturb people at the wrong time. They also allow collection of thought and precise responses.They allow working from a distance, they allow you to stay in touch while doing something else or being on a trip, while e-mail allows you to attach relevant information and much more. Also e-mail, like letters in the past, forces some discipline to explain situations more comprehensively; for example making reference to relevant information. It also helps people to provide a reasonable record of events without requiring the listener to take notes and then later add the relevant information, expending more time writing records of discussion. E-mail also helps by enriching one person’s work via the events he may not know are happening, or have happened but can help his current task.But e-mail is not structured and it’s hard to keep track of who said things that could be incriminating. It’s also hard to re-use useful e-mails because there is no indexing convention available without huge concerted effort. The oversupply of e-mails also makes it difficult to filter out the ones that matter to senior staff – they either get informed too often or too late. This is because the indexing convention is too difficult to apply.


Forms can help capture information from many participants, much like the minutes of a meeting, but can do so much more efficiently. A meeting requires interruption of working patterns and in meetings people often have to wait for others with different expertise to understand a viewpoint, otherwise unnecessary objections have to be endured which delay the progress of the meeting. To use forms to co-ordinate work a company is required workflows. This is just managed circulation of the form among participants to get everyone’s contribution. Without it people have to regularly look for the form in the computer to see if and how it has changed, and with hundreds of forms for each vessel this is not practical. Marine workflows and marine communications require more technology than land based workflows and land based communications. Considerable experience in communications is required to operate workflows with forms in the maritime field. Even on land when databases are separated the communication management needs a lot of experience.Continuous satellite communications can help but interruptions of service are frequent and re-synchronisation is far more complex than when a communication line is interrupted between land based locations. This is because packages may be delayed and arrive out of sequence when the system is reinstated. Also, with shipboard systems, unless very high standards of monitoring is maintained, system crashes can occur. And unless the resynchronisation is very advanced, using software purpose built for the marine industry, missing packages may cause serious problems – especially if there is data transfer and not just word transfer involved with the forms.

Not for maritime

In the maritime industry, in typical document management systems, we emulate about 300 processes with up to 6 users per ship. So for 20 ships we have 300 processes and about 100 users. What's more, a user like a master may be required to personally get involved with 30 of these workflow processes. In industries for which platforms like Opentext, Filenet and Sharepoint prevail there are often only 10 processes within these systems and perhaps hundreds of thousands of users, with one process per user being the norm. These platforms cover Business Process Management (BPM) document management, shared access portals and many related facilities. This is because the majority of processes are covered by specialised applications in most large enterprises, and not in a document management or BPM system. In the case of governement organization millions of users may access only one document/workflow process, say like tax returns. In short, the revenue is large but the processes are few. The need to be hugely scalable is a key point when allocating development funds. These systems address the needs of large companies. However, the need for a typical maritime user, like a ship's master, to learn 30 processes with multiple workflow stages each is rare to nonexistent because such processes are carried out in other specialised software. So what's the incentive for large document management companies to get involved with the subtleties of shipping and its multi-tasking users? One may ask, with the development budgets of large DM companies, why this would be a problem? To explain this we need to draw on the analogy of a senior bank manager and a junior bank clerk. The senior manager is unlikely to ever use the workflows or the document storage system in the bank. His real need is to manage exceptions to the process - in other words, problems. The junior clerk may be part of a workflow for, say, loan approval and may also use the archiving facilities for signed copies. So the software challenges are different for these two roles. A busy user with many things on his or her mind is not going to want to get immersed in a software process with a rigid path and the potential for unexpected reactions or requirements from the software - for example unexpected requests for details when they reside somewhere else in the system or another system. A customer configured workflow requires a path to be followed which is often not very flexible. Senior and multi tasking users have many responsibilities, so they have many processes to follow. Also they have a wide range of responsibilities so they only occasionally use each workflow. Occasional use means they can forget the navigational steps. Most importantly however, senior and multi tasking users, when using these workflows, are asked difficult questions and have to recall complex information. Retrieval of related information therefore becomes important.  For example, asking a chief engineer what the root cause of a sticking control air valve may be requires access to diagrams, and perhaps maintenance records, related machinery records, etc. Similarly if a master is asked to comment on the cause of a mooring non conformance they may require access to previous reports, comments on mooring lay-out, mooring system technical reports, etc. What is relevant and what is not is by no means the same across industries. It is very industry specific. In shipping we expect a master to manage 30 documentary processes through the system. For other officers it's between 10 and 25. The captain however is not a clerical worker and neither are the other officers. They have far more important responsibilities. Ashore, an insurance clerk needs to get involved in perhaps five processes, and clerical documentation may be all he or she gets involved with.


Let's look at an incident report, and how it would fit within the workflow process. Co-ordination is by far the highest value feature of an incident or unexpected event. Co-ordination could be defined as providing information at the time of need to people who are offering different skill sets to a process. For example, a leak of the hydraulic piping is first noticed by an able seaman, who reports it to the bosun, who reports to the chief officer, who then reports it to the master and chief engineer. The master needs to mention the defect to the shore staff because, although simple, it could repeat itself along the ship's deck if it's, say, an external pitting problem in the vicinity of the pipe joints. It may also involve procedural changes in the human processes in case hydraulic cargo valves fail to activate from the cargo control room, or in case the leaks occur at night when the deck is wet and cause pollution or a deck access hazard. Also the shore staff must make sure that, when the officers on board are repatriated, their reliefs are aware of the impending problem especially if it can't be repaired at the root cause immediately, for example by repairing all the pitted pipes joints at once. On shore the QA needs to approve changes to the human processes that will be modified to apply, for example, the use of the hydraulic system while leaks can spring up. The superintendent needs to get to the bottom of the cause, in case the root cause is a problem that can spread and is not isolated on this vessel - for example, poorly fitted or coated pipe couplings at the yard on a series of new vessels. Each participant has his or her own duties with respect to the 'workflow stages' involved. The QA may want to initially approve a set of temporary workaround processes (change management) and then monitor the processes monthly until the root cause is resolved, so as to change the valve operating processes and deck access processes to their status before the defect. The new building manager may want to know when the problem is diagnosed so as to activate the new-building guarantee claim process. The fleet manager may just need to monitor that the defects and related remedial action processes are closed in time and that the company learns from the defects.All these are different workflow stages that are of particular interest to each role. Multiply this by the number of occurrences on each ship and the number of ships and we are faced with a co-ordination challenge that is well worth addressing.


If this co-ordination challenge is not met it can lead to problems. People won't all learn from the occurrences of the incident, either at the time it is happening or in future, and the occurrences may not be resolved in time.  There will be a need to occupy point men to co-ordinate lots of the workflow stages that are unrelated to their own expertise - for example, the quality man-ager might need to get involved in recording experience on a technical level because the technical staff does not have the appropriate tools to manage lessons learnt from such a system, etc.It occupies a lot of the time of senior staff without necessarily getting them to focus on the real core of the problems that they really need to get involved with. This can also cause poor audit performance when auditors look into how problems are resolved. Co-ordination requires, for example, workflow configurations that relate more than one document to each workflow stage. In our example the oil leak is related to a temporary procedural change when pressing up the hydraulics. Each document in each workflow stage must reflect this and be adequately separated from unrelated items, otherwise people reading unrelated defects, for example, get confused and lose focus.Just as important is the need to merge closely related occurrences and processes in an intuitive fashion. Although this need for co-ordination is widespread in all industries, other industries have far more support staff to help managers keep track of the workflow stages. Not so in shipping. Relevance is industry specific, and each industry has its own relevance criteria. A defect related to an oil leak does not affect deck access in all industries or terminal vetting reports, nor new-buildings, nor cargo valves. So the company setting up the workflows must have a lot of experience in the industry, a lot of concern for keeping things clear and simple, and a very good software platform designed for this.

Systems for shipping

In conclusion, co-ordination using workflows requires deep domain expertise from the software provider and a platform designed for the job.Outside shipping there are different platforms for mapping processes, for sharing documents, for defect tracking root cause and risks etc. On board ships this approach is not feasible because of the separate systems requiring separate store and forward communications suitable for discontinuous communications in the maritime industry.Also, such systems need to all be used by some major users, such as the master. If systems are disjointed the users on board will use them to a minimum. Co-ordination in the maritime industry requires the combination of features from many different platforms used in other industries, all into one package.  In addition the senior staff involvement and marginal software support on board requires solutions much more tailored to the special needs of the industry. Whereas process management is today primarily the goal of document management and BPM in any industry, in ship-ping it is more about co-ordination. The difference is that co-ordination is seriously time critical.The main difference however is that a senior manager such as a master needs to co-ordinate 30 fairly complex processes through such a system, not just 'paper pushing' processes, and that is on top of his job as a senior manager and risk co-ordinator.If we take the analogy of a secretary to describe a productivity tool such as an electronic document management system, then this is like comparing the sophistication of the work of an office boy helping in the accounts department to the job of the secretary of a company or the secretary of a senior politician.
Since large DM companies do not generate much revenue from sales of systems to small and medium sized companies with multi tasking users, why should such systems be extensively developed by them? There may well be specialist software development partners for sectors with small to medium size companies, but how much convenience can they engineer into the system that does not have that convenience built in? The convenience needed in shipping covers things like knowing what stage in incident reporting requires looking at past cases of a similar problem, or what stage needs reference to current remedial action. You will also need to recognise what part of the current problem needs to be known in other processes that have yet to commence, what stage needs reference to a contributing concurrent problem, and what processes may need reference to the occurrence much later after it has been resolved.On top of this there is the need for technology development to integrate with other marine systems and to replicate documents across discontinuous communications. All of these things require specialised knowledge of the industry and the processes within - and these are the elements which will help to make the system a useful, efficient and successful tool for the shipping community.