Ulysses Systems Overcoming Software Complexity · • ERP platforms like Navision or Axapta? •...

Ulysses Systems Overcoming Software Complexity

© 2010 Ulysses Systems (UK) Ltd. www.ulysses-systems.com

What do we mean by software Complexity?


We will review 3 areas in this presentation: •Conflicting Platforms

•Upgrading Software

•Fitness for Use in Shipping


Conflicting Platforms What are the conflicting platforms? • Versions of Windows (Servers and Workstations)

• Version of Communications providers and data limit settings

• Virtual Machines

• Remote Access

• Database Servers

• MS Office Version, PDF Version

• Printer Drivers

• Unreliable Networks

• Unreliable Internet Access

• Virus Checkers

• Imagine how many settings you need to understand and design your software around them?


Upgrades of Non Functional Features Platforms System Providers like Microsoft inevitably force us and the

clients to upgrade to newer version of their software. For example we have to keep pace with Anything we use from Microsoft because their support of platforms is designed for land based use. They will not support old versions of longer for shipping companies

• ERP platforms like Navision or Axapta?

• Operating System Upgrades

• Virtual Machines Updates

• Upgrades from 32 bit to 64 bit Systems.

• New Versions of Email Systems and Communications Systems

• Database Servers changing from SQL 2000 to SQL 2008

• MS Office Version, PDF Versions


UPGRADES cont. Non-Functional Features Cont. • Patches that can provide quick fixes to problems and Upgrades as a whole

need to be managed within one version of the source code..

• One Version of the source code why?

• Simple Mathematics

30 developers with 1 source code version will provide 30 man/years worth of features every year per client.

60 developers with 300 versions of the source code will provide only 0.2 years of features per client.

• After a while (3 years is my guess) it is virtually impossible to keep up if you do not have one source code.

• The result is that software becomes a service where making improvements is a process is fraught with problems. Other things to also consider:

• Conflicts with Client Configurations and Customizations

• Reliance on the skills of a Person making the Upgrade.


UPGRADES cont. Non Functional Features Cont. • As a result after a while it is virtually impossible to keep up.

• You need to ask your versions what version of the software do your clients have? If they have different versions that you have to think about their ability to upgrade and how will your software improve over the years. Is your maintenance fee going down the drain.

• Other important considerations during the upgrade are:

• What about the ships? It is impossible to upgrade 50 ships at the same time. During the upgrade period some ships will be in the older version of the software will the system still function if some ships have a different version to the office?

• Workflow changes

• Database schema changes

• Communications provider changes

• Different version of the database software on board

• New features in the office not available on the ships like attachments.


UPGRADES cont. Functional Features • Functional features are the features that make the ERP system work

for the users. There are many reasons why features are added in regular intervals.

• Improved performance

• Better integration between PMS and Document management

• Better Integration between Crewing and document management.

• Integration of the risk management module with the other applications especially document management

• KPI reports

• New features forced upon us by regulatory bodies

• Many small add-hoc features to improve already available functions


Fitness for use in Shipping Most large software companies do not care about

the shipping sector. It is too small for them and most applications such as purchasing, asset management, personnel software and document management are not designed to be used by high salaried people in any industry other than shipping.


Perceptions about shipping • The perception that the maritime industry is

behind in the use of software is misguided

• Shipping is a high risk reward business so the right software is not the same as in other industries

• Have you tried selling software to commodity traders? Not likely to be impressed by common industry software.

• Shipping like commodities is a business where risk management is important, clerical office processes are less important.


Perceptions about Mariners • The perception that mariners are less skilled than personnel in a

factory is disrespectful and has been put forward many times unfortunately.

• Mariners are Multi Tasking

• Complaining that they will not report information to the office is an excuse used to cover usability issues.

• Just like saying that simple software is only for reporting from the ship that also covers communications and usability issues

• Practically all useful information comes is sourced form the ship.

• Extracting it in a way that is also useful to the mariner and using it to coordinate ship and shore processes is what software in this industry is for.

• This is the reason why our industry is extremely demanding in software usability


Often Software

designers think this is a

captain

I


In reality the captain is

more like this


and we don’t want to turn him into a clerk


• Technical Software advances pale in importance compared to fitness for use onboard.

• Technology is not the driving force in shipping software it will never be.

• Many banks use software designed 40years ago. The reason is similar to shipping. Functional integrity is more important than technology.

• One way reporting is not easy software it is a workaround for communications and workflow problems dressed as a usability feature

Technical Software Advances


• Software engineering staff in the maritime business has to have low turnover.

• Applications cover allot of processes and the revenue from the market is low.

• So the applications are very complex and the number of people available to build them is less than in software that can be sold to many industries.

• So turnover of staff is extremely disruptive.

• For example bringing in a software engineer from the banking sector will be very disruptive in the beginning even if he is better at newer technologies as he will have to both adjust to the new business he is in, but also to the code his predecessors had written. In a sense this is a lot like the importance of crew retention in TMSA

Turnover of software engineers is a problem


The main knowledge required to build software in shipping is knowledge of what is needed and in what priority.

• You can have deep shipping knowledge but not know the limitations of software design.

• You need someone that has been in shipping software for many years.

• Only by making mistakes you learn just think back to the conflicting platforms and upgrades.

• For example who will tell you that labeling spares as critical is wrong?

• Who will tell you that the purchasing process is a prioritization issue that is very different from procurement ashore.

• Who will tell you that asset valuation in maintenance systems is useless in shipping.

• Who will tell you that condition monitoring is advisory aid to the Chief Engineer not an expert system.

Importance of Prioritising Features


For example purchasing in shipping is a goal prioritization problem. Which goal comes first, price, quality, timely arrival, cost of transport, efficient inventory, port delivery costs, machinery continuity? Every purchase has a different goal prioritization and the items are delivered to different places and delivery timing affects transport distance, transport conditions, rule compliance etc.

Improvements in business processes from other industries are not necessarily transferrable to shipping.


In the manufacturing industry millions are spend on supply chain management for example getting seats fitted in cars just in time. In manufacturing all the decisions can be built into the software design. But this software will not help in shipping where the problem is different. Applying manufacturing processes to ships procurement is ludicrous. Same applies to customer relationships. No CRM system will help you get your ship chartered more efficiently.

Improvements in business processes from other industries are not transferrable to shipping.


Usability is NOT a matter of opinion or user satisfaction. It is a science that is related first to the accuracy with which the software emulates real world shipping processes. In other word how good and how mature are the use cases. Then it is related to knowledge management and artificial intelligence. Without the necessary academic knowledge, you CANNOT design software especially in shipping that has such intense usability requirements and process variations.

Usability and Shipping


Usability

Bank clerks performs the majority of their job via a software system 10 hours a day. They are bound to learn how to use it. In shipping mariners and especially senior officers use some functions regularly and other functions once very year. Their work reflects the work of 5 departments ashore. In which industry does a senior manager use applications reflecting 5 departments? No enterprise software designer has ever been required to create software to be as usable as it has to be in shipping. And its totally doable, but it is rarely done.

The Average Shipping ERP uses more than 1000 functions. Do the tools for your company provided by your software look like this?


Your Software Should Provide to you Your Tools in Intuitive Tool Kits Fit for the Task At Hand:


Carpenter Tool Belt

Laminate Flooring Tool Kit

Watch Repair Tool Kit

Garage Tool Storage Box

Thank You!


Ulysses Systems Overcoming Software Complexity · • ERP platforms like Navision or Axapta? •...

Documents

Transcript of Ulysses Systems Overcoming Software Complexity · • ERP platforms like Navision or Axapta? •...