Shipping Information: 2 simple steps to unleash the future
At the end of last year I attended a roundtable discussion on the potential for AI [Artificial Intelligence] in Shipping. There is a pervasive excitement amongst the digitally-aware that shipping is on the cusp of Something. This is somewhat constrained by a bafflement amongst the digitally-savvy at how such a high-stakes industry can still be inefficient, its information [data] fragmented, of poor quality, and hoarded to no particular end.
The excitement is not misplaced: these issues are very simple to resolve if there is some cross-industry dialogue, and then Enterprise is released to use some basic building blocks. I would state once again that these building blocks are achievable in 2 steps: recognise and organise the information that flows between us, and then commercialise it. “Shipping” – big place – will become data-enabled, and perhaps we will then see practical uses emerge for AI and Big Data.
Step 1: Recognise and Organise the repeated transactions.
Content, not technology.
All of us who work in shipping are familiar with the screenfuls of identical emails coming in by the hour, whichever our specialities. Open cargoes in region X, list of MR tankers coming open next week, Noon Reports, engine hours and lubes, Modern Handy available in Y, MRV, Advanced Manifest submissions, outstanding invoices due to Supplier Z, Hazardous Cargo lists, Bs/L, Hire invoices, D/As, Laytime calculation…different day, same…stuff.
How come it was in someone’s software, they sent it to my email, and now I need to retype it into my software – in 2019?! What’s worse, once I retype it, likely it will be different from what was in their software.
The answer is prosaic: it is often not in the interest of the maker of either software to make it ‘talk’ to the other. They want everyone to have their own software. In many other cases, the information is used across different areas of speciality, that use entirely different processes and systems; e.g. commercial, technical, port agents, emissions reporting, flag state LRIT, all want a version of the ship’s position information for different ends. With the increase of Compliance requirements, the volume will grow exponentially.
The solution is just as prosaic: it would cost only time and effort to agree a standard content and convention – but not technology – for these highly repetitive transactions. This is done most efficiently by the people that send and receive the information, rather than the makers of any particular technology – as any serious business analyst will tell us!
The reason to define convention on Content but not technology is because innovation can be released to roam freely as technology develops. If the Content definition is technology-agnostic, the implementation on tomorrow’s technology is a matter for those working on that particular technology. For example, we agree that once we say “CODE X”, then YES means affirmative, NO means negative, END means, err, end. The same format can then be used whether sending this information by telex, plain email, a .CSV file, XML or a JSON web call – that is a matter for the technician of each to deal with.
The meeting between two shipping persons – not their IT – would then go like, “so, we use Super Marine Soft; what package do you guys use?” “Oh, we use Super Sea Soft, but it does CODE X calls same as yours. I’ll just get our IT to give yours the I.P. address and set up access!” “Amazing – so, time for lunch?”
The conversation on Convention happened decades ago with the Container industry, in relation to the cargo bayplans: since the 90s a company can choose the software package that best fits its particular needs, and know that it can send and receive the plans to any counterparty’s software with no manual input. Lets face it, the Internet itself exists because there was a broad conversation with no strings attached; the conversation was about Convention, by which to allow ‘whatever’ to be transacted.
More recently, it has become commonplace for makers of modern software packages to make public a “digital socket” facing the internet – an external Application Programming Interface, API. An entirely different software – if it has the pre-agreed security credentials – can come along through the internet and ‘plug in’ its “digital plug”, and give, take, update and process information directly. Of course the alternative to using the API is to use the GUI: a person sitting at the screen and keyboard, retyping what came as a PDF attachment!
In 2015, a discussion on this subject was initiated within a forum of the Baltic Exchange in London, the first Smarter Solutions conference. There was broad agreement that this was low-hanging fruit and should be reaped. However the subsequent ownership process took the momentum out of that initiative.
https://www.icthusmarine.com/call-for-info-standards-in-shipping
In November 2018, the FT carried the news that five of the largest Container lines had stepped out to do just that – create an association with the prime objective of agreeing technology-agnostic standards for information, even as they are clear in the pursuit of blockchain technology. This is the opportunity for the broader industry to join the fresh momentum on this old subject – including those who mislead themselves in thinking they have much lower volume of information, e.g. tankers, bulkers, offshore.
https://www.ft.com/content/e699fa06-e81a-11e8-8a85-04b8afea6ea3
Step 2: Commercialise the information.
Revenue attracts efficiency; conversely Cost purges inefficiency.
So there is the information that we have to send and receive, then there is all that other information that we just…store. As secretly as possible. Research says, as does our anecdotal experience, that the huge majority of this information is not put to any use. *
* e.g. 60 to 73% according to Forrester, Jan 2016
The news is, if you have a years’ information on a fleet of say 50 ships, there is likely a data scientist out there that would love to trawl it even if he/she didn’t know what ships it referred to. Or be able to interrogate ‘anonimised’ data on demand; say, the cylinder head temperatures in condition X, or tonnage loaded in port calls to region Y - through this API thing.
This dormant information could be ‘commercialised’ in two forms: find someone that wants to subscribe to access; or, better still, someone who will combine your information with others’ and then in return, tell you what you don’t know. That is the springboard of AI. What most tech companies don’t know is which information contains commercial advantage for you or me, and is thus sensitive. So that kind of information needs to be made available to others on the basis I’ll tell you This, but not linked to That.
The next meeting between the two shipping persons – not their IT – about a more complex issue than the previous, would go like, “so the information goes direct from our system to yours now, but neither of us has the Average of X for the month...” "Ah, but Big Fat Container Co could sell us that for a fee, our software could query theirs using CODE X - I'll talk to them". “Amazing – so, time for lunch?”
This ‘shipping-related information marketplace’ would be enabled, and rapidly shift up gears, if the means of conveying such information were subject to some minimal conventions as advocated above. The AI and Big Data buzzwords which, alas, for shipping are still just buzzwords, could start to take shape on our long-range radar.