What The Experts Say
About making software work better for real shipping processes
What do the Experts Say About Making software work better for real shipping processes?
At the Digital Ship Webinar, February 20 ‘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 a treat, where both speakers entertained us with thought-provoking ideas.
To give you an idea we have gathered the points that stood out most for us. However, to form your own opinion on the speakers’ positions and their answers during the Q&A session press here.
Dimitris Lyras
Dimitris Lyras explained that is would be simple to make software work better for real shipping processes.
First, he described the existing shipping software paradigms stating that they are either based on a template or on transactions. However, a defect occurring on a vessel is more than a 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. Accordingly, 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 template.
For example, it asks officers if they have performed a compliance step. And if they have done so, they can tick it off. And since con-conformance 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.”
Subsequently, software of this sort cannot give forewarnings.
Therefore, we can venture to say that shipping processes, ship managers are involved in, are not adequately persisted in software. And something has to be done so that software does persist business processes and goals.
Furthermore 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 you are designing does, by showing the architectural design, relationships and attributes. What is the difference between a UML static diagram and a dynamic process map? The difference is that real process persistence is about processes in the real world not the ones we remembered to include in the software.
Persisting business processes, therefore, is different and dynamic, and this, UML cannot do. “For this, you need to have a framework that describes the real processes. And not to block the persistence of the real-world processes that affect the software you are building.”
Unlike building construction, processes in software development are far more numerous and interlinked and mostly not visible as they are in construction. So, a diagram of what you are building which would be useful in construction is not enough in software development. You need a diagram of all the processes that could affect your software.
Samuel Jones
Samuel Jones, 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 said that a rule-based excel can far exceed the potential of a software application! And what does this tell us?
Firstly, it tells us that experts in company departments know more about their processes than the software application the company uses. Because the designers of large ERP shipping systems are not maritime professionals
It also tells us that potentially these experts can help build a better application than the one they are using.
So, there is expertise and untapped knowledge that companies could profit from to buy software more suited to their needs. That is, an in-house pool of experts, which can save the company huge consultancy fees in customizing software, poorly suited to the domain.
Storytelling and Chat GPT
And what about storytelling using Chat GPT?
Sam brought our attention to the importance putting together various data to tell a coherent story. This would mean putting together shipping stories that resonate with ship managers who are solving problems. But generative AI, like Chat GPT, despite going through reams of data in seconds, cannot do this.
For example, Chat GPT can play a supportive role in searching data repositories. However, without integration tools that make these searches relevant to real world processes and goals, this support will be crucially limited.
Because Chat GPT, having no expertise coming from experience and situational awareness, is the opposite of an in-house expert. Furthermore, based on its clearly delineated knowledge that it doesn’t understand, can a machine offer a solution that must apply a huge fleet of VLCCs?
Hype
Dimitris responded, saying that silicon valley innovations that are attracting a lot of hype. And that shipping people deal with too many demands to invest in innovations but without the information about how they work.
“Shipping people must run a fleet. The software discussion must therefore be at the level of how things work in the real world.”
Market software design goals
Is it impossible to market the software design goals of the shipping industry?
Sam enthusiastically proposed that it should not. Isn’t making software work better for real shipping processes worth getting in front of a wide audience?
“Aren’t there ways, he asked, to make it fun for young people to get involved?
We need forums to fill the gap between domain experts and technical experts.
Explain what computerization does and what it leaves out.
We need to solicit interest of domain and technical experts at the early stage of designing new features.
So that technical experts can ask domain experts “are we covering what you need?”
Sam expressed the frustration of email in three words: “I hate email”. How many of us submerged in our work tasks don’t feel the same way? How can an email arrive without disrupting our flow and actually contribute to the process we are dealing with?
Dimitris agreed that email is not the best way to enunciate problems. But he thought that ‘ideas capture’ from email is important. This would mean an ability to extract ideas from emails. Where email could be an application that would help perform a task through having captured task-relevant ideas.
Last words
Our last words on the great webinar meeting between Dimitris Lyras and Sam Jones is to recommend the full You Tube webinar recording. And if you have questions the speakers will be happy to respond directly by email. They will also be happy to receive your ideas on how to market ‘making software work better for real shipping processes:
Dimitris Lyras, Director of Paralos Maritime Corporation (dlyras@ulysses-systems.com)
Samuel Jones, Head of application management at TORM (sajo@torm.com)
Finally, we are 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.
