Let us walk through a typical end-to-end process for exchange of goods, highlight the opportunities for collaboration and understand whether these opportunities are being seized. And if not, what are the reasons for this not happening

Scenario:  A Buyer needs something, and he has ordered this ‘something’ from a Seller. So, the Seller here is also the Shipper- the consignor of goods. He needs to send some stuff to the buyer- the Consignee. He uses some Service provider who will pick up the goods from the origin and get it across to the destination. Maybe, there’s a halt somewhere along the way in this journey. The Service provider will figure out how many vehicles and which vehicles to use.  The flow is illustrated below.

Now, let us look at all the opportunities that exist for communication (and collaboration) in this scenario.

Before even the process of physical movement of goods begins, here are a set of interactions that can happen:

BuyerSellerBuyer needs to raise a Purchase Order indicating his need to buy 1. Buyer calls via phone
2. Buyer sends information via email/ WhatsApp
3. Buyer logs in to a ‘portal’ provided by the seller to raise this P.O
4. Buyer and seller systems talk via EDI and Buyer sends Seller an EDI850
5. Buyer’s ERP interfaces with Seller’s ERP (possibly with API calls)
SellerBuyerBuyer needs an acknowledgement that Seller has received the Purchase Order1. Seller confirms PO details on phone
2. Seller sends acknowledgment via email/WhatsApp
3. Sellers ‘Portal’ accepts the order
4. Seller sends EDI855 acknowledging the PO
5. Seller’s system sends an acknowledgment signal via interface

Let us understand the ramifications of each of the 5 scenarios listed under ‘Possibilities’:

Scenario 1(phone): There is no systemic record of the conversation having taken place and the transaction requires a high degree of trust in order to fructify.

Scenario 2 (email): There is a digital record of the conversation, but there is no systemic linkage to the buyer’s or seller’s ERP systems which need to record these purchase/sale details. Additional manual effort is required in order to seed this information into such systems.

Scenario 3 (Portal): There is a digital record of this conversation, but this is only on the Sellers system. Also, would a buyer be willing to log on to a Sellers portal? Consider the fact that such a buyer might be interacting with multiple sellers. And also, the fact that the buyer still has to put in additional effort to capture this information in his own system. This can however work if the balance of power is heavily in favor of the seller.

Scenarios 4 (EDI) and 5 (API based interfaces): These are examples of conversations between relevant systems. Such conversations will ensure that there is a digital record of the conversations. Also, there is a possibility for downstream actions at either end to be driven automatically by the system. (For e.g. the Seller’s ERP could auto-trigger replenishment orders to a contract manufacture for the material to be sold to the buyer!). What this means is that more entities (other than the buyer and seller) can also be pulled in towards collaborating in the supply chain.

Taking this shipment scenario forward, once the products ordered are ready to be shipped, it is obvious that the Logistics Service Provider needs to be pulled into the collaboration game.  A typical flow could include the following:

  1. Shipper reaches out to a bunch of possible service providers to ask if they can fulfill this shipment. (This is an indent or a procurement request to procure the shipment service).
  2. The list of possible service providers who have been reached out to, respond to the shipper with a ‘Yes’ or a ‘No’.  If ‘Yes’, they also typically provide a quotation and payment terms for the Service.
  3. From among the responses, the Shipper will select a suitable service provider based on various possible factors- cost of service, quality as understood based on their past experiences with this provider, speed of service etc.
  4. The Shipper will now formally engage the selected Service provider to effect this movement.

It is fairly easy to see that steps a., b. and d. require conversations between distinct business entities.  You can imagine the conversations happening through any of the 5 scenarios listed in the table above.

Now, start to add in the other players who usually come into the mix: The diagram below is illustrative of such a network.

Clearly, the number of conversations that need to happen among all these entities is quite substantial.

Also, understand that every player in this ecosystem is not even remotely at comparable levels of technological maturity. Some players will have mature systems with the ability to build API based communication, while others will rely on the old-faithful xls.

Now factor in the overheads imposed by things going wrong in the field- vehicle breakdowns, traffic delays, regulatory hold-ups, consignment getting damaged etc., you will appreciate that collaboration is clearly non-trivial, and very often will be sub-optimal.

This is one of the big problems that we must attempt to solve in order to unlock significant value in Transportation and Logistics!