What’s Next in Transportation Management Systems (TMS)?

In a recent blog posting, Jordan Kass at CH Robinson (a Logistics Viewpoints sponsor) highlights a key finding from ARC’s Transportation Management Systems (TMS) market study: the growing adoption of managed transportation services.

We first highlighted this trend several years ago, and multiple times since (see “Time-to-Value: Developing a SaaS Equivalent for 3PLs” and “Buying Supply Chain Outcomes, Not Software”). You can read those postings for more details, but in a nutshell, managed transportation services couples a software-as-a-service (SaaS) TMS with a team of transportation experts who manage daily planning and execution activities (among other things) on behalf of a shipper.

Now that managed transportation services is more broadly adopted, Kass asks a basic question: What’s next in TMS?

Here are some of my ideas and predictions, some of them already evident, others perhaps a bit more “pie in the sky” in nature.

TMS will continue to expand beyond trucking and domestic transportation. The ability to plan and execute inbound and outbound shipments across all modes (truckload, LTL, private fleet, parcel, ocean, air, and rail) and across borders using a single solution is still not fully possible. But software vendors continue to pursue this goal, and they are getting closer every year. Not all companies need or want a “holistic TMS” but that’s a separate discussion. For related commentary, see “The Expanding Footprint of TMS

TMS goes global. This trend is related to the one above. As the TMS market continues to expand beyond North America and Western Europe, software vendors will have to configure their solutions to meet the local requirements of different countries. While there will be some common threads between them, a TMS in Africa, for example, will look and operate differently than one in Russia.

TMS-as-a-(Self)-Service. The basic idea here — which I first wrote about in 2009 in “An App Store for Logistics Software” and again in “Software-as-a-(Self)-Service” — is a transportation app that small shippers can buy and deploy very quickly and easily. Imagine an app store where a transportation manager could browse through various applications (e.g., an appointment scheduling app, a widget for financial settlement), buy them online using a credit card, download them, run some quick installation wizards, and off they go.

TMS add social media capabilities. Transportation involves “communities” of carriers, shippers, 3PLs, and other parties. It also involves the communication of status messages and the sharing of documents. The opportunity exists to transform the user interface and experience of a TMS by adding capabilities similar to Facebook and Google + (think of creating “Circles” of your carriers, suppliers, customers, and even other shippers), Twitter (to send short status messages), and Dropbox (for sharing invoices and carrier credential documents).

Siri for TMS. Voice recognition is already used in the warehouse, why not in transportation management? Instead of manually conducting searches and executing tasks, why not speak them? “Show me all uncovered loads” and up come the results on the screen. “Will any of my private fleet trucks be near an inbound pickup location on Thursday?” “How am I doing on my carrier commitments this week?” You get the idea.

I have other predictions related to transportation forecasting, business intelligence, connectivity, mobile and telematics, and other topics, but I am out of time and space. However, read the postings below to get an idea of what I’m thinking about in those areas:

Now it’s your turn. What do you think is next in TMS?

Comments

  1. Adrian – Thanks for the mention in this post. I agree with your insights, particularly on the “TMS goes global” comment. In our experience, it is imperative that TMS providers be able to provide a single global TMS platform, while balancing the local requirements of each region. These include the obvious local requirements such as currency and language. Or, these local requirements might mean the difference between deploying the TMS solution to include managed services in one region, while another region might require the TMS without a managed services component.