News Article 20/02/2007 A

Software helps in TMSA by making management of information easier (Elnabi, Feb2007,p.32-34)

20/02/2007 - ELNABI, Issue 398, Feb 2007, p.32-34

TMSA is a long document with a couple of hundred paragraphs describing essentially how a company should behave if it is to be trusted with oil major cargoes. It is a voluntary regime so that those companies making a greater effort are more adequately rewarded. Whether they are actually rewarded depends on waiting time for cargoes which fortunately has not been with us since the market last made its great rise.
For software producer the Items below are the key requirements of TMSA. At this level of generalization there is no difference between TMSA and any good management practice. For the software producer the challenge is to achieve maximum time saving in achieving awareness, with minimum user preoccupation in system understanding and system management. System preoccupation obstructs focus on the business issues.
Notice that there is no mention judgment and evaluation. This is a human activity for which systems can help only in collecting the right information at the right time for the appropriate judgment to be applied while minimizing system preoccupation. There is no doubt we need good judgment in the industry however the software supplier can only provide the information management side, not the human element.

TMSA at a Glance

-Risk identification (TMSA Elements 7, 9, 11); Risks identification will require being prompt and well communicated. This requires timely management of observations. Risk evaluation requires identifying standard process risk and superimposing combinations of observations and defects that can increase risk. In the future this will become a focus on more and more fine-grained items that today we may ignore. Awareness of development of any item that could affect risk will be the challenge.

- Co-ordination of action (TMSA Elements 1A, 7, 9 and 11); Clear evidence of due process to evaluate and remedy the risk. In the future every observation will be expected to be linked to actions throughout the enterprise.

- Process transparency (TMSA 1B, 4, 7, 9, 11 and 12); Clear relationship between detection and final improvement to the process in order to eliminate the risk. In the future there will be an expectation of consolidated views of the entire set of risk detection and mitigation processes, indexed by the action to be taken by each stakeholder. Clear and accessible status transparency on hundreds of fine grained issues from observations to change management to any business process employed in the remedial action.

- Guidance (TMSA Elements 1B, 3, 9, 12); Effective means to communicate procedures, change of process and enact change of perception. In the future, the way that change of process is communicated to stakeholders will be tested for effectiveness. In other words training and procedural change will be tested for final user awareness.

- Process improvement (TMSA Elements 1B, 7, 12); Design and implementation of improved processes by learning from internal and external experiences. In the future the expectation will be for the design of process to incorporate a consolidated view of experience whenever someone consults the system before doing a task.

Some misunderstanding with regard to TMSA:
TMSA has become Synonymous with KPI's. KPI's are synonymous with statistics and software; But there are as yet almost no numerical KPI's required by TMSA: There are only 4 numerical key performance indicators in TMSA and these come in two categories: Maintenance, Chapter 4, and Personnel Retention Chapter 3. These constitute 4 paragraphs out of a total of between 100 and 200 paragraphs of requirements in 12 chapters.

The KPI's mentioned in TMSA are simply requirements for procedures and the implementation of these.
The KPI's are satisfied by writing the appropriate procedure which is easy, and then implementing the new procedure which is thousands of times more difficult.
Unfortunately software cannot directly help you implement these procedures. It can of course do so indirectly.

There are also misconceptions about the change management aspects of TMSA. TMSA, if implemented conscientiously, is in itself a huge change management challenge. However there is little in the change management chapter that discusses any more than normal changeover practices long established in shipping with some emphasis on training and risk management.
Risk management in itself is the primary preoccupation in any industry involving high financial and environmental risk. This without doubt is a primary focus of TMSA.

Therefore software helps in TMSA by making management of information easier. Any enterprise requires information to help in risk or opportunity annunciation, decision making, co-ordination of decisions, the proof of diligence to stakeholders, follow-up etc. This is primarily what TMSA is about.


- Systems onboard must present important information to the user when it is relevant to the task at hand, at the time of need: The distribution of important corporate information must be as close to automatic as possible. It is critical that all relevant information is provided to the user at the appropriate time, with minimal requirements for circulation by the end user. Rather than simply alert a user when a message is received, operating systems must present the information to a user when it is relevant to the task at hand. It is a mistake to assume that a user will know where to find the appropriate information, or even that he is aware of its existence in the first place. Our experience tells us that people are not likely to rummage through records without knowing if there is anything there of value to the current activity. In this regard, critical corporate information is often overlooked because it is difficult to find or unknown to the user.

What should a system offer?
« help people on board to better prepare themselves for the performance of critical operations where sub-optimal procedural variations are most costly.

« significantly reduce incidents related to organizational and informational deficiencies within the company.

« provide a more cost-efficient and comprehensive risk-management system.

« promote and accelerate the integration of new policies and procedures, ensuring greater internal compliance as well as an easier and more cost-effective transition.

« save costs by releasing employees from superfluous administrative duties and paperwork, in order to devote more time and energy to optimising spending and operational efficiency.

The annual license cost of most maritime software modules is the equivalent of 1 to 4 man-days of salary per year of a senior officer or shore based a superintendent.
Most software related processes vary tremendously in the consumption of time and effort from user to user, ship to ship and software vendor to software vendor. Efforts to reduce these are the primary reason for performance support in software design. For example, reporting maintenance on a tanker in accordance with TMSA could take from 100 to 400 man-hours per year. A difference of 150 man-hours per year is close to 20 man-days. That becomes double when you add more modules and have the chief engineer turning into a clerk. So saving man-days should be high on the priority list.

Imagine how the defects/non conformance to the closeout process newly described by TMSA can be done conveniently, given the risk analysis requirements.
Surely, some careful design plus support of the users in this cycle of reports will make a fundamental difference in time and in preoccupation.