What The Experts Say
About making software work better for real shipping processes
What do the Experts Say about making software work for the Maritime cluster? At the Digital Ship Webinar, February 20 2024, ‘Making software work better for real shipping processes’, Karl Jeffery’s guests were Dimitris Lyras, director of Paralos Maritime and also founder of Ulysses Systems and Samuel Jones, head of application management with TORM. The webinar was successful, entertaining and thought-provoking.
To give you an idea we have put together a report of the points that stood out most. The webinar started with short presentation by Dimitris Lyras and Sam Jones respectively. The webinar concluded with Questions and Answers with both speakers engaging with the audience and each other. However, to form you own opinion on the speakers’ positions and their answers during the Q&A session you can see the full webinar on YouTube.
Dimitris Lyras
Dimitris Lyras explained that it would be simple to “make software work better for real shipping processes”. First, he described the existing shipping software paradigms stating that they are based on a common design template used in a transaction. However, a defect occurring on a vessel is far more than a workflow transaction. Actually, it is an enterprise problem with a risk aspect and knock-on effects.
“If we are to address this in our software development, it will not be that hard.” Since designing software that includes knock-on effects and which supports companies by indicating potential problems, is fairly simple. At this point, Dimitris, showed us on paper how easily a domain expert can visualize this on paper. And in terms of new development, “it does not constitute a great shift in software building”.
Software for non-conformances
Software for non-conformances follows a form and workflow template.
For example, it may ask officers if they have performed a compliance step. And if they have done so, they can tick it off. And since non-conformance form templates have a closing date, companies can get warnings about a due or overdue date.
“All that’s fine; but this doesn’t tell you if the non-conformance will or will not happen again. Because the software does not know the situations around navigation and software cannot read a form and understand the particular situation at hand.”
Subsequently, software of this sort cannot give forewarnings.
Therefore, we can venture to say that shipping processes, in which ship managers are involved do not widely persist in software. So, something has to be done so that software does persist business processes and goals. And the software must render graphically so that viewers, who have a stake in the risk mitigation, understand easily.
UML
Unified Modelling Language (UML) uses static diagrams to describe what software does by showing the architectural design, relationships and attributes. And it is still the only prevailing schematic framework used in software design.
The difference between a UML static diagram and a dynamic process map
How can one better understand the difference between a UML static diagram and a dynamic process map? A fair analogy is the difference between a website site schematic for building a website and the subject matter the website covers, which the website owner communicates to the designers. A significant difference! Persisting business processes, therefore, differs from UML by being dynamic and rich in interlinking. And this, UML, which is a static diagram cannot do.
“For this, you need to have a framework that describes the real processes. And not to stop before defining the processes in the software you are building.” In other words, the design must not exclude the real world process interactions and interconnections.
Samuel Jones
Sam, as head of application management with TORM, has been deeply involved in assessing existing software systems and in the design of new ones. As a result, his initial statement of how shipping software falls short of the actual enterprise needs carries a lot of weight. He also teased the audience by saying that a rule-based excel can be extended so as to far exceed the potential of a software application! And what does this tell us?
– It tells us that potentially these expert company employees can build a better application that the one they are using. This says a lot about Big Vendor applications. Namely, that they cannot rise to the needs of the maritime enterprise.
– It also tells us that there is huge untapped knowledge inside each company. In fact, it constitutes an in-house knowledge base, which can save the company huge consultancy fees in customizing software poorly suited to the domain.
– It also ensures that companies gain and progress with software better suited to company needs
Storytelling and Chat GPT
And what about storytelling using Chat GPT UI?
Chat GPT stands on the opposite of the in-house experts we mentioned. That is, it has no expertise coming from experience and no situational awareness. Therefore,based on its clearly delineated knowledge that it doesn’t understand, can a machine offer a solution that applies to a huge fleet of VLCCs?
Silicon valley innovations
Dimitris responded, saying that silicon valley innovations are attracting a lot of promo and hype. As a result, shipping people deal with too many demands to invest in technology innovations. Yet, without adequate information about how the innovations work to help the shipping company. Even more crucial, however, and another way of saying the same thing, is not having the information about how certain innovations will not work in shipping. This, then, is an area and an important service that Shipping IT experts can fulfil.
“Shipping people must run a fleet. The software discussion must therefore be at the level of how things work in the real world.” So, the software discussion must be at the level of whether new software is capable of facilitating the way things work in the real world.
Widely communicating software design goals
Both speakers feel that widely communicating the shipping industry’s software design goals is important.
In fact Sam suggested organising a forum with industry experts to discuss how software design in the marine industry can better meet real shipping industry needs. To which Dimitri agreed.
The aims of such a forum would be to:
– Make it fun and attractive for young people to get involved
– To fill the gap between domain experts and technology experts.
– To explain what computerization does and what it leaves out.
– To solicit the interest of domain and technical experts at the early stage of designing new features. So that the technical experts can ask the domain experts “are we covering what you need?”
Sam expressed the frustration of email in three words: “I hate email”. Dimitris agreed that it is not the best way to annunciate problems and process statuses. But he thought that ‘ideas capture’ is important. This would mean an ability to extract important company processes from emails. Where email could be an application that could help perform a task through having captured process and task-relevant information.
Email as an application
Email as an application points to an application that helps perform a task through having captured process and task-relevant information.
Final words
Our final words on the great webinar meeting between Dimitris Lyras and Sam Jones is to recommend the full You Tube webinar recording.
And are indeed grateful to Digital Ship for the dedication and passion in organizing webinars and conferences on shipping and vessel performance. And for giving the maritime sector a voice and opportunities to catch experts talking about software working better for the industry.
