Earlier this year, I wrote a piece highlighting the expanding footprint of transportation management systems (TMS)—i.e., how software vendors are transforming TMS from a fragmented collection of applications to a unified platform where users across the enterprise and value chain can execute role-specific processes via configurable user interfaces, workflows, and web services. Yesterday, I participated in a webcast sponsored by RedPrairie (an ARC client) on this very topic (you can register to watch the webcast here). As I prepared for this webcast, and as I continue to work on our annual TMS market study, I realized that our definition of TMS is missing a critical component.
Here’s the definition we’ve been using for several years:
Transportation Management Systems are software solutions that facilitate the procurement of transportation services; the short-term planning and optimization of transportation activities, assets, and resources; and the execution of transportation plans. They address all modes of transportation, including Ocean, Air, Rail, Full Truckload, Less-than-Truckload, Parcel, and Private Fleet. In addition to managing the physical flow of goods, they also manage the flow of transportation-related information, documents, and money. TMS also include performance management and collaboration capabilities.
Seems very comprehensive, doesn’t it? In fact, I always make the point that no vendor fully meets this definition today, although the gap continues to narrow each year. So, what’s missing?
Network connectivity.
Transportation processes (tendering, booking, track and trace, appointment scheduling, freight payment, etc.) are inherently network-centric, involving the exchange of information between carriers, logistics service providers, suppliers, and other external trading partners. Therefore, traditional, internally-deployed TMS solutions require companies to establish and maintain connectivity (via EDI, web portals, and other means) with an ever-changing set of trading partners. This is among the most labor-intensive and time-consuming aspects of a TMS implementation; connectivity is also something that many companies fail to consider when evaluating TMS solutions.
As I’ve written many times before (see “More Questions About Software-as-a-Service”), one of the benefits of software-as-a-service (SaaS) TMS solutions is that they come with a built-in carrier and trading partner network. With SaaS TMS, most (if not all) of a company’s carriers and trading partners might already be on the network. Although network connectivity is not exactly “plug and play” in a SaaS environment, the on-boarding process is, nonetheless, greatly accelerated. The net result is faster time-to-value.
The importance of network connectivity in TMS was underscored earlier this month when Oracle (an ARC client) and E2open announced a partnership (“Oracle and E2open Simplify Logistics Connectivity”). Derek Gittoes, Vice President, Logistics Product Strategy for Oracle, says the following in the press release: “Customers have been asking us for a simplified way to establish electronic connectivity between Oracle Transportation Management and their transportation trading partners. By combining leading connectivity and transportation management capabilities, ELN gives Oracle Transportation Management customers a compelling alternative to help reduce their integration timeframes and costs.”
Customers have been asking us…that’s the key phrase in Derek’s quote.
So, if you’re in the market for a TMS, you should also ask about network connectivity and include it in your evaluation process. In particular, calculate the time, cost, and resources required to enable and manage, on an ongoing basis, a connectivity network in-house versus using a SaaS solution or a partnership offering like Oracle-E2open. If you do this analysis, I’m willing to bet the latter options become much more attractive than tackling connectivity yourself.
What do you think?
Adrian, I agree and feel that it’s also the most overlooked when a customer purchases and implements a new TMS. During a TMS implementation customers typically are concerned with time/budget considerations as well as how to roll out the TMS either geographically or functionally throughout their organization. It is only later on that they realize that they have to work with vendors (VANS, typically) that understand Order to Cash and Procure to Pay cycles but not the sort of B2B relationships that are contained in a complex supply chain. Also, they don’t understand the complexity in on-boarding each carrier individually. In my career before I was a consultant with G-Log I worked for an ocean carrier and was in charge of on-boarding EDI programs with customers. Carriers have limited resources, staff and time to implement customer initiatives. Those customer programs are in competition for resources with the company’s own IT programs. This makes the time line to implement/on-board carriers a longer exercise than customers would ordinarily like.
That said, SaaS solutions should not be considered a panacea. What constitutes 70-80% of a carrier community for one customer is not going to necessarily translate into the same percentage of compliance for another. Also, the data requirements will differ from one customer to another. What will benefit the customer is the fact that the B2B enabler (SaaS, VAN, etc.) will know and understand the API’s for the technology meaning that 1/2 of the translation will be built using a canonical model reducing the overall cost and making the on-boarding process slightly faster.
Excellent piece and thank you for letting me comment.