A practical ROI framework for Web3 in logistics

Start with the exchange, not the ledger

A useful Web3 business case begins with a coordination problem between organizations. A carrier, warehouse and customer may each maintain a different version of an event. Establish which record matters, who creates it, who needs to trust it and what happens when participants disagree.

A shared ledger is one possible architecture. Compare it with a conventional integration or a jointly managed database. If one trusted operator can maintain the record and resolve disputes, distributing control may add work without solving an additional problem. The proposal needs to explain the governance benefit as clearly as the technical design.

• Technical context: NIST Blockchain Technology Overview

A common event language comes before the architecture

GS1’s EPCIS standard defines a shared way to describe supply-chain events, including the object involved, time, location and business context. Its companion Core Business Vocabulary supplies common meanings for event values. This addresses a different design question from where the records are stored.

• GS1: EPCIS and Core Business Vocabulary

Our implication for a delivery-confirmation pilot: agree what “received” means, which shipment it refers to, who recorded it and how a correction is represented before comparing ledger architectures. A common event definition is a prerequisite for reconciliation; distributing inconsistent records will not make them agree.

A three-layer investment framework

Separate the value of improving a process from the value of growing a network and the possibility of a longer-term strategic advantage. These layers have different dependencies and should not be added together as though every benefit were already secured.

Layer 1: make operational value auditable

Choose one document exchange and map the current work from creation to acceptance. Record active handling time separately from time spent waiting. Count exceptions and identify their causes: missing data, inconsistent identifiers, unclear responsibility or conflicting evidence.

For an illustrative delivery-confirmation pilot, compare the cost of reconciling a delivery record before and after the change. Include the people checking exceptions, the integrations keeping records synchronized and the support needed when a participant is offline. Faster database writes are not the same as a faster business process.

• Use the same workflow boundary for the baseline and the pilot.
• Separate reduced effort from capacity that has actually been redeployed.
• Avoid counting the same reduction once as staff savings and again as lower processing cost.

Layer 2: test whether the network works

A demonstration with one organization cannot establish the value of a multi-party network. Identify the participants needed for the exchange, their incentives to contribute and the work they must do to join. Participation should mean useful transactions, not a logo on a partnership slide.

Agree who can admit a participant, correct an erroneous record, change the rules and leave the network. Define what happens to access and historical information when a relationship ends. These decisions belong in the investment case because they influence onboarding effort and ongoing support.

• Track the share of relevant exchanges completed through the network.
• Record why participants continue to use parallel processes.
• Treat promised participation as an assumption until demonstrated.

What TradeLens teaches about the network assumption

In November 2022, Maersk and IBM announced that they would discontinue TradeLens. Maersk stated that the platform was technically viable but had not secured the industry collaboration and commercial viability needed to continue as an independent business.

• Maersk: decision to discontinue TradeLens, 29 November 2022

This is evidence about one platform, not a verdict on every shared-ledger design. Our investment lesson is to test participant commitment as carefully as technical feasibility. A working exchange still needs parties willing to supply records, change their processes and fund its operation. Put those commitments and their failure conditions in the business case.

Layer 3: keep strategic value separate

Traceability or shared evidence may matter to a customer or partner, but a proposed advantage needs validation. Ask which purchasing, financing or assurance decision would change because of the new capability. Record the evidence and the cost of delivering it.

Keep speculative benefits in a separate scenario. A stronger audit trail does not automatically establish legal compliance, and transparency does not automatically improve retention. Test the claim with the people making the relevant decision before treating it as a forecast.

Build the decision pack

The investment review should make uncertainty visible. Present a base case using benefits that can be measured in the bounded workflow, then show how results change with participation, support cost and exception rates.

• Define the workflow, owner and participating organizations.
• Compare viable architectures and their governance implications.
• Record implementation, integration, training and recurring costs.
• Agree the pilot measures and conditions for stopping or expanding.
• Review the result with participants before extending the scope.

The next step is a small, credible exchange with an agreed baseline. Expand when its operational usefulness and participation model have been demonstrated. The technology should earn its place in the business process.

About this edition

Based on the original Bridges perspective by Mohamed Elnahas. This revised edition is prepared by Bridges Editorial. The three-layer framework is editorial analysis; the TradeLens example and EPCIS context are attributed to primary sources. Original publication date and URL are retained.

• Mohamed Elnahas, Founder & CEO