News Article 04/12/2007

Lessons learned - Implementing a PMS (Digital Ship, December 2007, p. 18)

Exmar Shipmanagement knew that it needed a new planned maintenance system, but problems with previous software installations meant that a new approach was necessary. Digital Ship spoke to René Jungbluth, technical director with Exmar, about the company’s approach to this PMS project

When Exmar Shipmanagement of Belgium decided that it needed a new planned maintenance system to help manage its fleet of gas and chemical tankers and to organise its systems in line with the requirements of
TMSA (Tanker Management Self Assessment), it had a list of different factors that would be key in choosing the most suitable system.
The wish list that the company had come up with was a result of a number of lessons that Exmar had learnt over the course of implementing a range of varied software systems during the previous five years, according to René Jungbluth, technical director with Exmar Shipmanagement.
"In 2000 we bought an ISM software as a package," he told us. "It has been operational, stable, and satisfactory."
"For crew management software, we first made a contract in 1999 in preparation
for the Euro, because we wanted to link crew management to the wage calculations.
We never managed to implement that as a single package, but we ultimately managed to link the two software packages and it's in operation in the office, though not on the vessels yet."
"For our accounting software, we started in 2001, and looked at a Belgian based integrated software, but found it wasn't fit for shipping. In 2003 we took another package and started experimenting. That was a shipping-based package, but we found that we couldn't adapt it to the Belgian accounting rules. So that failed."
Mr Jungbluth continued: "In 2005 we bought a local accounting software and integrated it with our PMS (planned maintenance system) and purchasing software. We're now stable and operating satisfactorily."
"For the planned maintenance system, we had an in-house PMS that had been developed since 1995 and was a stable, stand-alone package. We had an integrated PMS and purchasing module, but keeping the software up to date was time consuming and costly."
It was decided that a new PMS software package was required, but Exmar was anxious not to repeat the same mistakes it had encountered with some of its previous installations. "We had different problems with all of these things," said Mr Jungbluth. "First of all the configuration of these packages, we could say that some of them were incomplete designs, meaning they were maybe went into production prematurely. Some of them were difficult to adapt to the workflow of our company."
"Then the implementation of software would always brings resistance from the users. Any change, anywhere, you will meet resistance, though when they try it and work on it you can gain acceptance. It's something that has to be looked at because some people are capable of delaying your projects."
 

Coupled with these logistical problems Mr Jungbluth also found that the installations could prove to be technically challenging. "Installation is difficult as the vessels are moving targets, and in the beginning we had problems with satcoms," he told us. "Five or six years ago high-speed transmission technology was not as good as it is today, it's
moved on a lot and is quite good now."
"Upgrading and debugging by the software companies is also usually slow - upgrades come out late and you have the installation problems all over again. And financially, some of these projects have proven to be a bottomless pit, that's the only way I can describe it. Modifications, reprogramming, consultancy - it's really very costly."
To analyse these problems, and to try and prevent repeats as far as possible when implementing the new PMS system, Mr Jungbluth and his team tried to isolate the root causes of these problems.
"We started to look at 'why'," he said. "We've heard a lot of arguments - is it the software designers, who don't understand what their clients want? Are we dealing with aggressive, ambitious sales and marketing?"
"Is it our IT department, are they not qualified for these things? Are we getting too far ahead, trying to get the latest technology rather than using proven systems? Maybe there's a lack of understanding from the management. Does the management give enough guidance when they start these projects?"
"These are some of the general issues that have come up in our company, and these things have now come into our criteria for choosing software."

Planned maintenance systems
As part of the process of developing this list of criteria for the system, Exmar proceeded to do a thorough examination of its existing PMS, to find the specific areas where improvements were required. Properly analysing the existing systems was enough to convince the company that a new solution was necessary.
"We had a computerised system in place, that had been developed in-house with a Sybase database, and it recorded maintenance tasks and running hours, listed the equipment and spares on board," Mr Jungbluth explained.
"But it was incomplete. Our data was not well protected, we still had to develop a security module. The reporting module still had to be developed. And a lot of new customer requirements came on the market, TMSA being the biggest one. So we decided that we had to have a new maintenance system."
"We thought 'we have to be able to do comparisons across the fleet, we have to be able to measure things - we still have a lot of work to do on this system, why don't we go and buy professional software?'.
To avoid the problems of the previous software implementations Mr Jungbluth and his department made a list of the functions and capabilities that were prerequisites before considering any of the software packages on offer.
"We set off on this project, and there were a number of criteria we had in mind," he said.
"First, we said that it has to be off-theshelf software, because it will give you protected databases. And they'll only need upgrading when Mr Bill Gates decides to do something else."
"We also needed a flexible structure, in the sense that we have to be able to make certain modifications specific to the workflow of the company. Thirdly, we wanted easy deployment of the system - in installation, replication, and intervention in the office. Some systems are absolutely terrible in that respect."
"We wanted importing and exporting facilities, an open structure, and to allow for interaction with other software. If we have PMS with purchasing, of course we want this system to talk to the accounting system, and vice versa."
Mr Jungbluth and his team also placed great importance on the services that the vendor would be able to provide on a continuous basis after the installation was completed, and having a training programme that would allow the system to be operational in a relatively short time.
"We wanted software with simple and quick operation, which would allow for simple and quick training," he told us.
"When we started this wasn't the highest priority, but in the end it became very important when we realised how many people we'd have to train."
"We wanted continuous technical support from the vendor. This has been the biggest cost factor in some of our other projects, the availability of the vendor and the cost of consultancy in these matters."
"And finally we wanted it to be cost effective during development, implementation and operation. So we were looking for a fixed price contract with limited extra programming costs, or at least a programming cost that was defined in hours, before we agreed, and to have low communication replication costs."

Choices
With a clear idea in mind of the software and services that were required, Mr Jungbluth began to consult with a number of software vendors to find out how they could meet the particular needs of his company.
"We looked at four or five software makers, and we tested them out," he said.
"We started in September 2003, and decided in October 2004 to go with Ulysses systems for the Planned Maintenance and Purchasing. The ISM module we have is a separate software, it works well so we continued with that. In January 2005 we migrated the first vessel and had it in operation."
"What pulled us over the line? The software we bought was task oriented, so when someone is in front of a screen their own functions, as an officer or whatever, are clearly indicated. You don't have to go and look for them."
"It was also quite flexible, we could plug in other software. We have some people in the office with software knowledge that can easily plug stuff in and out of this system. It also was good on the ease of use and support from the vendor."
Once the choice had been made the more painful business of installation followed, and Exmar decided it would need to dedicate a significant amount of resources to the project to make sure it was successful. The implementation plan was also heavily influenced by TMSA requirements.
"We decided to implement this system in a different way to what we'd done with our previous software," said Mr Jungbluth. "TMSA said that if you had a major change in the company you should have a management of change procedure, and look at your risk as to what will happen if I do this."
"We said 'ok, let's do that'. We're not really used to that in shipping, well, we weren't in 2003, but we tried it out."
"We had several brainstorming sessions in the office and came up with an implementation group. We had a particular procedure for setting up the database and the data entry, for the installation of the hardware of software, and for the training.
Then the implementation group would report directly to the technical director."
"The group was a separate entity, it was a full time job, people couldn't really combine being in the group with their day to day duties. They did all of the planning, and coordinated with Ulysses on the creation of the databases."
One of the key factors in helping the project to progress, from Mr Jungbluth's point of view, was communication with internal company stakeholders about the project.
"One important thing they did was inform personnel and management about the progress and planning of the implementation," he said.
"This is something that will go on before you have your 25 ships in operation that will take a year or a year and a half. You have to keep telling the people what you're doing, because they'll lose interest. It was promised in 2003, and if it's now 2005 and we've got nothing up and running, you'll need to keep them informed about what's been going on."
Once the project was completed Exmar then had to put together a training programme that would get the crews and shore based staff up to speed quickly, so the software could perform the tasks for which it was purchased. The results so far have been pleasing, said Mr Jungbluth.
"Training was something we were concerned about," he told us. "As gas carriers, we are in port anywhere from 12 to 18 hours, and it's difficult to do training when the ship is in port."
"It's expensive to send people out, ship by ship, to do the training. So we said we'd do the initial training ashore. One day sessions were found to be enough to be ready to use the systems."
"Training today is still done ashore, but we've now reached a stage where there are a sufficient number of people on board that know and use the system that they can train each other."
With the system properly implemented, and crews competent in its use, Exmar has already seen a number of advantages that have increased the efficiency of operations.
"We now have improved communication with the vessels, and better documentation and reporting," said Mr Jungbluth.
"The way of reporting is standardised and is much easier to check."
"It's also easier to see where they are and if they're compliant, we can see the planned maintenance stages virtually every day. We can see breakdowns every day as they come through, so we don't have to wait for a long time to get messages from the ship."
Future Mr Jungbluth says that the success of this project has motivated the company to look at further improvements in its systems, and he believes that the maritime software market is continuing to offer interesting options to shipping companies that want to increase the efficiency of their IT systems.
"I think that the number of software packages will further increase," he said.
"Maybe there will be dedicated software in specific fields, perhaps from smaller companies. There are a number of things we have in mind that we'll either incorporate in the existing software, or 'plug in' to the system."
"We're looking at software for standardized drydock specifications, for root cause analysis, risk assessment, e-commerce maybe. The question will be if we are going for integrated software or open structures."
"A few years ago everyone was talking about an integrated system, but I have the impression that we are moving towards open systems, to a platform where you can plug in more specialised units as long as they have the same language to communicate with."
As software systems improve the imperative will be on shipping companies to make smarter decisions as to what type of systems they need and what type of systems, and vendors, can meet those conditions.
"I think the choice of software will become more important for companies," said Mr Jungbluth.
"It's a customer requirement that you make use of it and you show that it's audited and checked so it becomes more public. The process of choosing software has to become embedded in the company structure, decided by the company management in a reasoned way."
"Owners are losing faith in IT and in the sector to some extent. It's through our own mistakes and through the poor performance of some of the software companies.
Owners will eventually, I think, choose companies with a good reputation and a good performance track record. Maybe the software companies need to more often show how good their track record is."
From Exmar's point of view, the PMS project has definitely offered some lessons that Mr Jungbluth hopes will benefit the company in the future when the time comes for the next system implementation.
"Introducing new software in the company is a major change in the operation of your company," he said. "I would recommend that you apply the management of change procedures. I would recommend that you work out the consequences, and assess the risks to the organisation from the start."
"Continuous and active management involvement is an absolute must if you want success for your software projects.
It's not only a question of initiating it, and then walk away to the golf course."
"Start it, follow it up, see how they are progressing, how much money they are spending. See if we are on track, how we keep it on track, what additional resources we need. You need continuous involvement if you want this to succeed. The changes are too big. It's too important to leave it all to IT people alone.