News Article 30/03/2009

Usability in enterprise software
(By Mr. Dimitris Lyras, Managing Director Lyras Shipping, Advisor to the Board of Directors, Ulysses Systems)
Economic Outlook, February 2009, p.8-9

Performance support software in management is meant to increase each person’s awareness in a business to the extent needed for him or her to perform optimally and make optimum decisions. The kind of support we are discussing in the maritime industry ranges from decisions to enter a port in fog to planning a repair to buying spares.

We need the performance support aspect to justify the outlay (beyond compliance) and connect to the financial controller.

There is a huge benefit to useful performance support solutions, but the financial controllers who approve the software bills understandably have no easy way to measure value.

Financial controllers will readily accept outlays in management software areas that already exist and have easily quantifiable costs and benefits. An example of pre-existing outlays is software that oil companies expect tanker owners to have. But slowly, there is a realization that such “recommended” software is also meant to assist in management performance, and therefore, can be viewed as a management efficiency tool. However, few people in the industry are fully convinced that software in the maritime industry is an efficiency tool. The reason for their skepticism is usability as it is as difficult to measure usability as it is to measure performance support.

We all understand the difference in productivity of a good mobile phone or PDA from an awkward one, even without measuring the difference. We know the reason behind the difference and we know the feeling of frustration when our productivity slows. The difference is usability and it applies to every tool we use, from a hammer to a radar. However, software is the most complex tool we use, so usability can become the primary issue in software.
Usability is more or less critical depending on the purpose of the software. Accounting software has dedicated users who are used to data management. Ships have captains and chief engineers who are not used to it, and if they are, they are likely the wrong type of person for the job. Nobody can be good at everything. Shipboard staff have to manage people well, have to manage uncertainty well, they have to spend a large amount of time thinking about machinery and structures, they have a mobile environment, etc. Why should they also be data managers?
Captains and chief engineers have to view on board software as an effortless interaction with the outside world and with the ship’s information. A simple subconscious and continuous interaction focusing only on real business issues, not software handling issues. Otherwise there is too much thinking about software when they should be thinking about their main role in their enterprise.

Since their roles involve commercial discussions, operational discussions, technical discussions, purchasing, crewing, vetting, other audits, etc., the master and chief engineer have to have one interface that brings all this together.

The only way that this will work is for a software system to articulate around the same activities that the masters and chief engineers refer to in their own thinking.

It’s all about common sense navigation and good profiling of the processes in an enterprise. However, the common sense navigation is the hard part.

Here is an example.
A well-designed software system should know who you are: If you walked up to your fleet manager in the company and asked to discuss a technical defect about a malfunctioning hydrocarbon alarm, would you expect that person to converse with you taking into account your role in the company? You would, because knowledge of who you are and what you are likely to know as a professional is critical to intuitive discussion. Imagine if your colleague mistook you for a port state inspector instead of a colleague. Likewise, software has to present different variations of a process to people with different skills sets in the company.
Well-designed software should identify the context of the discussion: The first thing people do when talking is to quickly identify the object of their discussion. Badly designed software usually spends too much time asking you questions to determine the object or context of the discussion. The reason for the discussion has to come up as soon as the dialogue begins.
Why must software link related processes? Suppose that it turned out that the defect discussion was not about a malfunctioning instrument, but really about replacing the ten year old hydrocarbon alarm with an accurate instrument suitable for today’s emission standards. So we are switching from a defect discussion to a change management discussion but we are still talking about a hydrocarbon alarm and related emission instruments. Same system, different process. A lot of software would have you start over with a new process looking for the emission instruments again. Would you expect to go back to your desk and think about the management process involved in replacing the alarm and then go back and talk with your colleague? And then would you not be annoyed if you had to remind your colleague that you were talking about the hydrocarbon alarm and not the galley extractor fan or 900 other machinery components?
Must software be able to switch topics? If the discussion focused on the alarm panel and not the sensors, would you expect to go back to your desk and spend five minutes readjusting your thinking to recall your knowledge about the alarm panel instead of the sensors? A person could easily switch topics and maintain focus. Software must be able to do this as well.
Business use cases must reflect the way you do business: If we knew that we wanted to replace the existing alarm with a new instrument, we would be quite annoyed if our colleague jumped two steps asking us about the part number of the instrument we want to buy before we even know the maker. Neither would we be happy if our colleague insisted on knowing how many parts we wanted to order when the logical next step would be to work out a quick budget based on the commercial benefit and the oil company vetting angle.
Too many finely tailored transactions to choose from: Finally, would you be happy if it took you fifteen minutes of trial and error to arrive at a way to convince your colleague that you don’t want to discuss deck department defects, but that you want to discuss the boiler hydrocarbon alarm which is no different than the steam generator hydrocarbon alarm which he or she had understood was the discussion item? And further, that you also want to discuss TMSA and vetting observations, and that to find these you do not want to go through port state inspections. And finally, when you finish discussing these issues, you want the right people to know. Not everybody, but the right people. And you want them to know when it is appropriate, not when they are getting off a plane.
Usability is the ability to operate software subconsciously.
One of the most fundamental concepts in usability is the ability to operate software subconsciously while concentrating on the issue at hand. This concept is especially apparent when using a PDA because we often use a PDA when we are in the middle of a street trying to find an address written on an email or while talking to a taxi driver.
The concept of using subconscious scripts to simplify our lives is essential not just for using software but also for driving and, most of all for, managing difficult decisions.

So, if a software product can be navigated without conscious thought, it can be used in stressful circumstances without taking our attention away from the real world situation and without adding more stress and preoccupation.

What do we need to overcome the usability obstacle?

  • A step-by-step definition of human common sense.
  • A careful analysis of how much ergonomics effort you need and in which software features.
  • A system that articulates in the way that common sense articulates.

Ulysses Systems Approach
Ulysses’ unique Task Oriented Architecture provides software that is highly intuitive and makes information uniquely accessible to the user. Unlike existing software, which expects users to adapt their thinking to the navigational layout of the product, Ulysses software, using highly configurable Task Orientation, matches the navigational layout to the way each role/user thinks through a process. This increases the performance of users in every aspect of information handling. It saves valuable time for multi tasking employees, which is by far the most costly expenditure in software lifecycle costs, while offering ever increasing process control without the rigidity of conventional systems