If rail is a key part of your transportation plan, how can you be sure your TMS effectively supports rail’s unique requirements?
Most tier 1 transportation management systems (TMS) are built around providing visibility to and optimization for full truckload and less-than-truckload (LTL) modes, primarily into and out of a Retail or Consumer Packaged Goods DC network. But for manufacturers who ship using both rail and truckload, a key issue lies in whether they are able to achieve the same benefits by using a TMS built for truckload modes in their rail operations.
In fact, the fundamental workflows that a TMS must support—Planning, Execution, Visibility and Audits—are areas that are often woefully lacking in features with a typical truckload-based TMS, which tends to view rail as a hybrid truck. What’s even more rare is a comprehensive TMS that can support the advanced business requirements of both truckload and rail carriers with varying degrees of operation complexity.
Any “rail-friendly” TMS must effectively support all four of those core workflows. Let’s take a closer look at Planning and Tendering, as an example.
Preparing a rail shipment relies on the base data (or data source) to take carrier route codes, rail junctions and transfers into account when planning routes. A truckload-based TMS would lack the ability to calculate distances and fuel surcharges for actual distances—estimates based on road miles or straight-line distances can vary significantly from the longer and more circuitous routes required by rail. For example, shipping goods from Atlanta to Tampa may cover 400 truck miles, but using rail the trip could be closer to 800 miles. The tendering process must accommodate both initial short-haul lanes and/or booking via long-haul rail carrier. This relationship among short- and long-haul rail carriers is often completely lacking in truckload-based TMS. Real-time data access is critical when monitoring rail Rule 11 rates in order to minimize the manual effort in maintaining this data. Accurate, rail-specific information in the 404 tender message creates a data flow (including junctions and hazmat information) not accounted for in truckload-based TMS solutions.
You can find similar deficiencies across the other process workflows, as I highlight in Four Reasons Why Your Truckload-based TMS Won’t Cut It for Rail (click to download). Simply put, if rail is a key part of your transportation plan, make sure that the TMS solutions you evaluate can support rail’s unique requirements. In spite of the challenges rail presents, a robust multi-modal TMS solution can successfully and efficiently incorporate rail, offering users the power to build the most efficient inbound and outbound shipments possible.
Ashok Kumar is a senior principal business analyst in Research and Development for the TMS solution at Manhattan Associates. He has more than 13 years of experience designing and implementing ERP and logistics-focused supply chain solutions. He holds a bachelor’s degree in Mechanical engineering from the Jiwaji University, Gwalior, India and a PG certification in Logistics and Supply Chain Management from XLRI, Jamshedpur, India.