A new communications pipeline?

A new communications pipeline?

A new communications pipeline?

A new communications pipeline?

A new communications pipeline?
A new communications pipeline?
  • slideshow
  • slideshow
  • slideshow
Tracking
Search field
Number
Online support
(+84) 38729686

A new communications pipeline?

A new communications pipeline?

EDI has dominated the freight sector’s communications for decades, but the industry’s systems may soon have a whole new way of talking.

   It goes some way toward explaining how behind the times the transportation industry can be when you consider that electronic data interchange is considered by many to be advanced technology.
   EDI is the de facto means of communications between systems in most modes. For some, it’s a goal to even get to the point where actions like shipping instructions or a load tender are transmitted via EDI.
   But is there a better way?
   To answer that question, one would do well to look to the IT industry at large, where something called application programming interfaces, or API, are the standard way that systems “talk” to one another.
   “It’s not an alternative to EDI, it’s the standard outside of the transportation sector,” said Wally Ibrahim, chief technology officer of the Chicago-based API platform Project 44.
   Ibrahim came to transportation from a technology background, including a stint with Oracle.
   “I just assumed everyone was using web services (APIs) in transportation,” he said. “They said, ‘nope.’ And I said, ‘why not?’”
   To which Jason Roberts, a co-founder of the transportation management system Freightview, has an answer.
   “For the early adopters of EDI, there was lots of legacy code,” Roberts said. “EDI is not very nimble or flexible, but when it’s in place, it runs. That said, it doesn’t make any sense to make any new developments on EDI.”
   Both Ibrahim’s and Roberts’ companies are at the forefront of a movement to transition the transportation industry from EDI to web services API. For them, the equation is simple: EDI is a limited and rigid means by which to exchange data in a world where data is becoming as important as the actual cargo it accompanies.
   “EDI wasn’t designed for the Internet as it looks like now,” Ibrahim said. “It was designed three or four decades ago. At the time, real-time communications wasn’t possible. APIs don’t define what you can talk about. You can exchange data about scheduling, address information, rates, or postal code validation, unlike EDI, where the codes tell you exactly what you can do.”
   Ibrahim made a simple metaphorical comparison.
   “EDI is one way,” he said. “It’s like a fax. I don’t know if you’ve read it, whether you’re going to read it, or whether you’re going to get back to me. API is like a conversation—there’s a real-time back and forth. The nice thing about web services API is they open up whole new ways of doing business. I believe API is to [business-to-business] what the web browser is to [business-to-consumer]. It’s been happening in the e-commerce world for a long time. Taking orders, order management, tracking. There’s a precedent for it.”
   So again, why isn’t everyone using APIs?
   The main stumbling block is that it takes two to tango. If one company, say a shipper, wants to set up an API between its transportation management system (TMS) and its carriers, it generally needs to go to each of those carriers and establish that interface one-by-one. It can be onerous for both sides. Imagine a shipper that uses 15 different trucking companies and five ocean carriers. Now imagine a carrier being asked by its hundreds of customers to set up an API with each one.  
   Project 44’s model is actually quite simple to understand (if not fairly complex to actually execute). It’s a hub-and-spoke platform where carriers’ separate APIs are routed through Project 44 and delivered to a shipper’s TMS in a standard format. What’s more, when a certain carrier’s API is set up through Project 44 for a certain shipper, it becomes available to any other shipper that uses Project 44.
   “If you have five carriers, you need five pipes,” Ibrahim said. “That’s where we come in. You have to do that integration work to each carrier, and you have to maintain it separately. There’s a lot lower maintenance and less work over time than EDI, but it’s still work that has to be done again and again over time.”
   There’s also the thorny issue of EDI, and the way many in the transportation industry cling to it. EDI is so pervasive in the ocean freight industry that it seems incomprehensible that it could actually be displaced, but Ibrahim’s company has designs on doing just that.
   “Think of it like a contract,” he said. “If you send this data, I will send you this back. You send me a tracking number, I will send you a shipment status. Then later, I might add on a time stamp. You can grow and make it support your business any way you need. Now you’re not locked into a model designed in the ‘70s when data was handled differently than it’s handled now.”
   Part of what excites the folks pushing for broader use of APIs is that it addresses areas that EDI is not equipped to handle, like rates.
   “I had been intrigued with the concept of API for a couple years,” said Josh Craig, president and chief operating officer of Chino, Calif.-based truckload and less-than-truckload consolidator Sunset Pacific Transportation.
   Craig began working with Project 44 on developing a quicker and more dynamic way to disseminate rates.
   “It used to be you’d pick up a phone to get a rate,” he said. “Or you’d fax a rate form and they’d fax the quote back to you. Even email blasts seemed efficient at first.”
   Using an API eliminates the analog nature of pushing rates out.
   “[Travel website] Expedia to me is the best way to think about how it works,” Craig said. “You put in the to-and-from, dates, constraints, and you get dynamic pricing. That to me is what the API intermediary platform does.”
   Craig said this increased responsiveness has resulted in Sunset being able to change its pricing in real-time to meet the market.
   “With traditional LTL pricing, you agree on it and the discount and that’s the pricing for the year,” he said, noting that Sunset’s partners have to be “somewhat technologically sophisticated.”
   “They have to have a TMS that pulls in the pricing,” Craig said. “But most medium to large companies should have that capability, or IT expertise.”
   Freightview’s Roberts said much the same. Freightview was acquired in late 2014 by third party logistics services provider C.H. Robinson as part of its deal to purchase the freight brokerage Freightquote. Freightview was incubated within Freightquote and now stands as a separate brand under the C.H. Robinson umbrella that targets infrequent or small shippers with a simple-to-use, inexpensive TMS that aggregates their LTL rates and prepares shipping documents.
   The magic behind the system is that Freightview eschewed EDI and has established APIs with an extensive catalog of LTL carriers and brokers to provide users with a simple way to compare rates and transit times for a given lane.
   The company targets shippers with five to 25 loads per day, the type of shipper that would have previously been searching for contract rates by going to each of their carriers’ websites separately. It’s also the type of shipper for whom a more robust TMS is too expensive and likely too much system.
   Freightview is able to attract the LTL carriers to establish APIs, Robert said.
   “If you don’t have APIs, you’re seen as behind the times, and shippers will start to question your other technology,” he said.
   He acknowledged, however, that in the LTL world, APIs are really limited to only rating and scheduling at present.
   Ibrahim is evangelizing the idea that APIs can be so much more for the transportation industry.
   “The nice thing is you don’t have to get rid of EDI,” he said. “As it gains traction, you try to push people to web services because you can set it up to communicate any services you want. There is no EDI for asking someone for a rate quote. As you start to grow, you add other web services in place of what EDI does.”
   He also said web services are a lot easier to implement than EDI (conversely, though, part of the reason that EDI is so entrenched is that it takes most companies a long time to get up and running on it and so they’re loathe to ditch it).
   “Most IT professionals have never worked with EDI, but they all know what APIs are,” Ibrahim said.
   On a theoretical business basis, Ibrahim touted the ability of APIs to let companies with capacity (for example, carriers) better sell to transactional customers while maintaining proper relationships with bigger customers.
   “Carriers need to be aware that the more quickly you can send someone a quote, the better the chance you have of getting that business,” he said. “They need more dynamic pricing capability.
   “Look at airlines, or baseball stadiums, or metros,” he added. “They all have capacity they need to sell. The traditional sales model still needs to happen, but you don’t need to have a conversation about every shipment. Some shipments are too small to even have a conversation about, yet you still have to do these manual things. The costs to manage that shipment go way down when you can price dynamically.”
   Ibrahim’s implication is API empowers that dynamic pricing in a way EDI literally can’t. For one, Freightview offers a user the ability to not only tap into its contract rates with LTL carriers, but also check real-time spot market pricing from across the market.
   Craig said Sunset’s use of Project 44’s platform has enabled it to build a rate quote engine on its website for transactional customers.
   APIs are more than about rates though. They can theoretically replace all of what EDI does. Take the parcel integrators. When you order something from an online retailer and track the shipment status until it reaches your door, you have been accessing information pulled from the parcel company’s backend system to its website by APIs.
   That same scenario could be replicated in a container-tracking environment provided each of the sources of data was patched in via APIs to the aggregator of that data. That largely is not happening yet.
   The key here is that EDI was constructed, as Ibrahim noted, in a time before the Internet, when companies needed to transact electronic data about orders, payment, and shipping status with their supply chain partners.
   The Internet has changed the way systems converse, though, and the transportation industry has largely failed to adapt. Let’s be clear—API integrations are not necessarily easy. But neither is constructing EDI integrations (a few years back, one major retailer somewhat infamously had a 48-page implementation guide solely governing purchase order by EDI).
   Craig said Sunset spends about $10,000 a month with its existing TMS provider, because the provider charges a flat rate per character every time the company sets up an EDI feed with a customer.
   “The time it takes to set up customers with API, it’s only on the customer end and it takes a fraction of the time and cost,” he said. “Technology is evolving. Anything you’re using today is probably going to be obsolete.”
   APIs aren’t anything “new.” As Ibrahim also mentioned, these interfaces have been around a long time, just not within the context of transportation.
   The question now is whether we might see a wholesale migration of information being sent via EDI to API pipelines being set up between carriers and their networks of customers. Much depends on how these networks are oriented.
   Project 44’s concept is to go to the carriers and build the APIs with them, and allow a shipper to use any TMS to plug into its platform and get all those APIs in a single format. Sort of like the U.N.-style translation headphones.
   Freightview’s model is built somewhat similarly, though it is the TMS itself, and not purely an integration platform.
   Will other providers in the transportation industry follow suit? Who will drive it? Will shippers demand such real-time, open-ended systems connections with their carriers and logistics services providers? Will carriers and 3PLs see value in the dynamic possibilities inherent in using APIs to communicate with customers? Will the industry ever tire of EDI and its rigid structure?
   The questions are numerous, but Ibrahim is sure the change is coming, and that his won’t be the only company to facilitate that evolution.
   “If you look around at what’s happening, you’re going to see more API web services used in and out of transportation,” he said. “There will be more hub-and-spoke model companies like us developing. The transportation world is catching up on it. A year ago, people had never heard of it. They weren’t even interested. Now API is one of those technology terms that in the last few months has become a hot topic. People are coming up to us talking about it.”

This article was published in the October 2015 issue of American Shipper.

Other news

2016 Copyright © Ghtrans. All rights reserved. Design by nina.vn
backtop