Despite the fact that global economics is still in turmoil, according to Eurostat data, shipping volumes of global supply chains are slowly growing. For instance, the gross weight of the goods passing through the main EU port has increased by 1.2% in the first quarter of 2022 compared with the same quarter of 2021. Although this growth is partially driven by the recovery of maritime transport that plummeted due to COVID-19 restrictions, it is a solid indicator that the industry might return to a (new) normal at some point.
Still, such an unclear situation challenges global shippers with forecasting short-term and long-term B2C and B2B demand. Large shippers and manufacturers have started to insource their logistics and supply chain processes to be more agile and flexible in reacting to changing market demand. This has introduced a need for the shippers to establish direct connectivity with the cargo carriers, like ocean shipping lines, to make the data flows as automated and flexible as possible. Business-wise this makes total sense, but technically, this approach brings along some challenges.
This article discusses different integration and connectivity issues shippers may face while insourcing their logistics process from freight forwarders. Also, it outlines information on how to address those challenges in a cost-efficient way.
The challenges
Since 80% of the global cargo is moved by sea in containers, let’s look at ocean shipping and FCL (full container load) freight more closely to understand these technical integration challenges.
Shippers and freight forwarders handle their physical movement of ocean cargo in a Transport Management System (TMS) where cargo bookings are created and managed. TMS is typically also the centralized point for a shipper to track the movement of the cargo, namely ocean containers. Shippers must try to exclude manual phases in the process as far as possible to make the booking and tracking processes efficient. To do this, TMS needs to be integrated with the ocean carriers booking and track & trace interfaces, either directly or via an integration provider.
From a TMS side, integrations are made easy since most support modern APIs making their side of the technical integration easy to implement. On the other hand, ocean carriers still rely heavily on legacy EDI infrastructures (EDIFACT or ANSI X12) and AS2 or SFTP connectivity for data exchange. This introduces a technological challenge; how to bridge the gap between modern APIs and EDI?
To make the integration slightly easier, Digital Container Shipping Association (DCSA) has published track and trace (T&T) standards for the global container shipping industry, and the first carriers have implemented their own partial APIs based on the standard. However, for the booking processes, the DCSA standard is still to come, and without exception, carriers still rely on legacy technology and EDI message formats. In addition, DCSA T&T implementation has also proven to be challenging for many carriers, and as far as I know, no carrier still implements the DCSA T&T standard in its entirety. This may mean that once DSCA has published the 1st version of the booking standard, it will probably take several years for top carriers to implement it and able to publish the respective API endpoints. Thus, EDI will still be there for some time as the prevailing way to integrate bookings with the ocean carriers.
Now, let’s look at the booking process in terms of EDI interchanges.
To secure a booking with an ocean carrier to transfer one or multiple containers from a port of origin to a port destination, the shipper and ocean carrier need to exchange the following message types in the following order:
- Booking request, used by the shipper to request a shipment for one or more containers on a specific voyage
- Booking confirmation, to confirm the booking request along with cut-off information details
- Shipping instructions, sent by the shipper to provide further information on the cargo, and, for example, how it is packaged, etc.
- Manifest, sent by the carrier
- Bill of lading, from the carrier to the shipper – this is often a picture of the document in binary format
- Ocean status events, from the point when containers are transported to the port of origin to the point when they leave the port of destinations
That makes at least 6 message types a shipper should master in terms of technical setup and business content. To make things more challenging, each carrier has its own interpretation of these EDI messages, so you may need to multiply the number of message types by the number of carriers to understand the work required.
Typically, support for these processes and messages has been implemented by the shipper’s TMS system integrator (SI). SI has also been required to set up the needed connectivity with the chosen ocean carriers. This has meant that shipper needs to kick off large IT projects with timelines counted in several months or even years.
To tackle the challenge of being forced to build these integrations always from scratch, many TMS systems are standardizing their APIs to make it faster and easier to establish integrations from their side. Standardized TMS APIs will make it easier for SI to set up required carrier integrations, but they are not the silver bullet that solves all your integration problems. You still need to find a way to connect the worlds of API and EDI, including the data format conversions and adaptations to different protocols. Also, as no two APIs are alike, even if the carriers provide their own APIs, you still need to integrate them to work together.
Common mistakes shippers and TMS SIs make while establishing integration and tips to avoid those
Below, some tips will hopefully help you avoid the most typical mistakes shippers and SIs encounter when they integrate their TMS with ocean carriers.
- Use an experienced integration provider (IP) who, first and foremost, is familiar with the ocean logistics and booking processes, not just the technology but also the business processes, standards, and terminology used within the domain. This will make the setup process far more efficient, and IP can also help you navigate through the different phases of the onboarding process, including, among others, letters of authorization; CUCC, and other code mappings; pre- and acceptance testing as well as production deployments and hyper-care which typically follows afterwards.
- Ensure that the IP’s data integration solution is flexible to support your TMS system API integration. This way, you avoid the situation where your TMS SI needs to establish connectivity with the integration service and carry out the required data conversions and mappings – let the integration specialist take care of the adaptations.
- Prefer IP who already has existing connectivity with your ocean carriers and experience working with the carriers’ IT teams or who can quickly onboard new carrier connections as the need arises.
- This might be self-evident, but lean towards cloud-based integration services that are automatically scalable to handle the message volumes as your business grows. Scalability means here not just technical scalability but commercial scalability as well. Too often, because of the rigid integration service pricing model, shippers see that their costs skyrockets as their booking and track & tracing message volumes increase because of boosting business.
Hopefully, this article will help you avoid the mistakes mentioned above and tackle all the connectivity challenges the most effectively. If you need a reliable integration partner who would support you in this endeavor, look no further. Youredi is the leading provider of fully managed data integration services and solutions for logistics and the global supply chain. Whether you need to establish integrations with ocean carriers or those operating in other modalities such as air, road, or rail, Youredi is the answer!
Book a call with one of our integration experts to learn more about Youredi and how we can help you.
