In November 2021, Federal Maritime Commission (FMC) Chairman Daniel Maffei appointed Commissioner Carl Bentzel to spearhead the FMC Maritime Data Information initiative to focus “on identifying data constraints that impede the flow of ocean cargo and add to supply chain inefficiencies” and aimed “to establish data standards and best practices for data access and transmission.”
After months of weekly Zoom meetings, the group is reconvening June 1, 2022 with a “report-out” in the afternoon.
Below is our take on how to move forward:
Broadly speaking, the picture emerging from the FMC Maritime Data Initiative testimonies is encouraging.
Encouraging because there is no reinventing of the wheel or momentous re-thinking here. Participants across the supply chain already consume and communicate a large amount of data to their partners. Which means there’s the general capability, willingness and expectation of a participant to receive, record, store, and transmit data.
Encouraging, too, because participants’ assessments of data gaps and challenges were also largely aligned:
- Accuracy – two different participants signal different conditions (carrier may indicate a container is available for pick-up, but the terminal does not).
- Timeliness – when, finally, the systems get reconciled and the product is released, one might now be up against the last free day, without an appointment or an available trucker.
- Subject to change – ERD (earliest return date) could be changed at the last minute, terminals opt (on the day of the appointment) to not accept specific empties of a given container type.
- Siloed / lack of standards – communications are specific to a pair of parties rather than open. There are service providers bridging those gaps, but there isn’t a universal terminal availability API where customers can poll any terminal. More fundamentally, substantive core data (e.g., port/terminals, vessel/voyage nomenclature) is not standard.
The first three result in the available data not yielding the correct behaviors at the correct times – typically resulting in incremental costs falling onto the beneficial cargo owner (BCO) in the form of demurrage expenses at the port, additional transportation expenses, and more.
The final item has two implications: incremental costs to the BCO (and each participant) for each integration; the relationship-specific nature of integrations and lack of overall data standards combine to create a lack of a data-driven big picture view.
With all this in mind, the need for the National Ports Information System, originally put forward in July 2016 by Commissioner Dye, is clear. The key for success is clarity on the essential needs and avoiding over-reach.
From an essential needs point of view:
- Add records (accretive) only – importantly including not only the status or milestone (e.g., earliest delivery receipt date) but also record when the data is communicated so one can inquire the question what the status of “X” was at a given date / time.
- Attribute information to the sender – meaning the person using the information needs to know it came from the necessary party (or necessary parties).
- Finally, provide a ‘real-time’ means for data suppliers to deliver data into the system and the capability for real-time delivery of that information via different channels (e.g., web-site, text, API, etc.) for data users to poll or receive data.
The scope can easily over-reach. In order for the NPIS to be successful, it’s important to keep focus on the space where there is both near unanimous agreement and where objections can easily be batted away:
- Focus on a confined set of players, namely ocean carriers, terminals, rail operators, and US Customs. Exclude truckers, warehouses and BCOs initially (too broad a constituency), but encourage engagement over time through mutually beneficial use-cases. For example, the picture could be refined if the warehouse communicated when a container is scheduled to be unloaded or has been unloaded and trucker’s arrival at the gate/line would be helpful as well.
- Broadly, include events at the vessel/shipment/container level between vessel arrival to container empty return (for imports) and starting with setting ERD through to full container delivery and vessel departure (for exports).
Note I am deliberately excluding the last free day on container demurrage at the pier or container per diem off-terminal. Those are commercial matters between BCOs, VOCCs, and LSPs.
- Reference fields for the shipment – against which the events would be recorded – should include carrier, vessel/voyage, ship from / ship to, US port terminal, point of delivery (or pick up for exports), and shipment reference (Bill of Lading or booking number) going down to the container number. Many of these references – carrier, vessel/voyage, US port/terminal, would need to be standardized – incorporating PIERS and CBP.
A private blockchain would be suitable and is on-trend – with distributed ledgers promoting additional visibility – although other structures could be used.
If the above seems non-controversial… it should. The perspective on the picture varied according to constituents presenting, but the big picture presented among the webinars’ participants was largely consistent.
There are several considerations that came up during testimony that warrant further examination.
01. Incorporation of other transport modes
The Federal Maritime Commission is focused on ocean but the fundamental rules on visibility, planning, etc. should extend to “inland ports.” Commissioner Bentzel brought this matter up recently, suggesting that the FMC expand its oversight to “include matters involving rail demurrage on containers moving via a through bill of lading.” And, theoretically, this principle should be applied to an inland container depot if moved as a through bill of lading (relevant if carriers are using inland points as a relief valve).
From the viewpoint of macro freight flow data, Air movements should also be more easily incorporated – not about the milestones but more about general flows of freight into the US given that freight – regardless of mode – puts a load onto the domestic network that’s worth understanding / aligning.
02. Who bears the price of failure to uphold commitments?
One stark element of the recent supply chain impacts was that the costs were borne by BCOs. An ERD was changed? Trucker passed costs to the BCO. An empty container of a given type no longer accepted at a terminal? Trucker passed costs to the BCO (as well as chassis expenses and per diem – or the costs / burden to negotiate them).
This is a complicated conversation requiring nuance, but there is a legitimate question when the supply chain service providers should be held accountable to a specific commitment without reasonable notice.
To be clear, I’m not discussing adherence to general Service Level Agreement (SLA) type commitments. SLAs are performance expectations (e.g., 98.5% on time in full) and there are exceptions. I am also mindful that the margins in logistics generally do not allow for absorbing expenses – hence the industry-wide reflexive cost-pushing to the BCOs. I’m speaking specifically in cases where a specific commitment was made, for example, an appointment is made to return the empty container at point A – and changed without reasonable minimum notice. That is where someone other than the BCO should bear the expense of non-fulfilling the commitment
03. Idiosyncrasies of information demand vs information supply
There was a healthy amount of discussion about the relative merits of APIs vs EDI during the testimonies, notably describing the former as more real time and, therefore, superior.
Allow me to complicate matters a bit.
Firstly, we need to differentiate between information supply and demand. To use the example of container events at the terminal, the terminal operator represents supply; downstream consumers of that data – a designated trucker waiting to make an appointment – reflect demand. Information supply must be real time. No real doubt there. Information demand related to basic supply chain execution should be driven by what is needed to trigger a decision or an act. This will vary, however, by where you are in the chain, your specific operating circumstances and to the person. For example:
- A company awaiting word on container availability to make a drayage appointment will be more sensitive to real-time information than someone tracking vessel movement and understanding it may be 8 hours behind schedule.
- Others may need to make operating decisions in advance – e.g., if labor needs to be planned out / committed to several days before the container actually arrives.
- If things are on-schedule / plan, some people may want daily updates if it’s a high visibility project and may otherwise be good with a weekly update.
The list clearly isn’t exhaustive. But you get the idea.
Additionally, properly consuming information involves context which inevitably means additional data elements like purchase order information, in-store dates, or other factors to enable the decision. So the key becomes how easy is it to link the milestones into a company’s ERP/workflow software to make decisions.
Finally, information demand for planning or assessment purposes can be less real-time on one hand (capturing some average view over a sustained period and exceptions) but incorporate real time red flags if available.
