Logistics Viewpoints

A complete analysis of logistics trends, technologies, and services

A Senior Leader’s Take on TMS Implementations

Transportation Management Systems | By •

TMS implementationsOne of the major trends driving TMS implementations is the technology’s proven ROI. Primarily, a TMS can save companies money by lowering their freight spend. An ARC survey on the ROI of TMS found that respondents indicated freight savings of approximately 8 percent with the use of a TMS application, a 2 percent improvement from the last time ARC surveyed TMS users. Of these savings, 60 percent of users indicated that less than 10 percent of the net savings were absorbed by the TMS. These freight savings can be attributed to simulation and network design, load consolidation and lower cost mode selections, and multi-stop route optimization.

The one area that needs improvement when it comes to ROI is the implementation timeframe. The good news is that according to ARC’s research, only 9 percent of respondents indicated that their TMS implementation project timelines slipped and the software was not fully functional at the project deadline. Additionally, 39 percent indicated that timelines were met for the bulk of the features, but not all promised functionality, and 24 percent said timelines slipped but following go-live, it was fully functional. That leaves only 27 percent of respondents that indicated timelines were met and the software was fully functional at go-live. This is an area that can make or break IT budgets, and certainly gets shippers thinking about alter-native routes to take.

In order to keep implementations on schedule and on budget, developing a baseline of KPIs and a communication schedule are critical. I recently spoke with two senior leaders of TMS companies, Dan Sedore, Vice President of Services at 3Gtms, and Mark Picarello, COO at Pierbridge, about their experiences and guidelines for TMS implementations. The conversation is below.

Chris Cunnane (CC): How long is your typical implementation timeframe?

Dan Sedore (DS): We’ve recently modified our delivery approach and methodology to implement projects in phases to enable clients to be live and recognizing benefits and achieving ROI sooner.  Given this, the implementation timeline is tightly aligned with the Project’s scope, success factors, and client goals, and client resources.  We have successfully reduced our implementation timelines within the past few months.  We’ve completed the initial project phase in as little as 4 weeks and large complex projects spread out over 18 months.  The average go-live is approximately 4 to 6 months.

Mark Picarello: Our software can be deployed on premise or accessed from the cloud.  Our experience is that there’s no such thing as a “typical” implementation because one of the reasons customers buy from us or from one of our VARs is that the system is flexible, with tools to change workflows and integrations.  Our cloud-based apps can be implemented in less than an hour, while an on-premise deployment could take weeks depending on the complexity of customer requirements.

CC: What percentage of implementations stay on schedule and on budget?

DS: Our goal going forward is 100% on time, in budget.  This is achievable with strong Project management and managing scope change.  Project factors causing delays and budget overruns are primarily influenced by tasks not being completed on time due to resource commitment, scope creep, and being too optimistic in the delivery effort.  Our methodology of clearly defining and getting alignment on scope, requirements, and design early in the project as well as delivering in manageable phases, reduces the risk of budget overruns, run away scope, and project team fatigue.

MP: It depends on the level of complexity.  If you were to categorize projects as small, medium, and large, the small ones seldom stray from standard implementation processes. Medium implementations generally have mixed freight and parcel, multiple locations, multiple workflows, and more involved integration to one or more systems. But these also mostly stay on schedule. Large implementations have complexity and their ability to stay on a timeline is directly related to a customer’s ability to articulate requirements upfront and also the number of change requests mid-project.

CC: Do you have a global template? And how do you track the progress of the implementation?

DS: We have a Project Implementation Methodology and a Phased rollout approach. Our project templates have milestones for signoff at key milestones, such as integration design, configuration design, workflow design. We track progress and budget based on tasks and deliverables, their associated due dates, and assigned budget/hours via our project management tool.  The Project Management Platform provides transparency and collaboration of the entire project team, client, and 3GTMS

MP: We follow a project “blueprint,” which represents best practices in terms of scoping, design, implementation, and testing. These practices do not change by region, although requirements can change by region and by the type of carriers we onboard (some carriers have advanced IT, some less so). Our project blueprint framework includes milestones to measure and track progress.  We tend to group them around activities including location setup, carrier onboarding, and systems integration.

CC: What is the most important thing to keep an implementation on track?

DS: Strong project management combined with open, honest, accurate, and timely communication. During launch/kickoff, from the 3G side we have a project manager, implementation leader, VP of services, and the Sales lead who was involved in the sales process. From customer side we like to have project sponsor/stakeholder, representative from each key area (IT, Finance, Operations), and their designated Super User(s).  We discuss expectations, goals, success criteria, project plan, change management, and resource needs.

MP: Clear and consistent communication throughout the project life cycle. For proper project management, communication is key. We outline clear requirements, deliverables, dependencies, and follow up.

Getting Creative with your TMS: Two of the Latest Capabilities

Guest Commentary | By •

continuous pool optimizationTo a lot of people, the word “creativity” doesn’t come to mind when they hear about transportation or logistics. Maybe some of us in the industry don’t even think of ourselves as the “creative type.” If that’s the case, I think we sell ourselves short. Every day, logistics planners have to be immensely creative in how they move freight with a seemingly endless number of changing constraints.

To be creative, however, you need technology that supports flexibility for handling your operations in the best way for your organization and customers. Although transportation management system (TMS) vendors can’t build software that addresses every possibility a logistics planner might come across, the goal of the TMS should be to support your work with a level of flexibility that enables creativity.

We’re seeing a lot of change and new offerings in the TMS market today, including two of the most recent and innovative approaches: A new capability called continuous pool optimization (CPO) and the enhanced ability of rating systems to better handle real-world complexities.

Continuous pool optimization

Sometimes being creative means waiting to take action until you better understand your options, rather than deciding to act and getting locked onto a certain path – even as new information is introduced into the freight equation.

This is the riddle that continuous pool optimization (CPO) addresses. It allows for a pre-determined or dynamic routing of orders through a consolidation network. Routes can be split in to a consolidation point and out of the consolidation point independent of each other. These inbound and outbound movements can also be independently managed, letting the optimization out of the consolidation point be delayed until the user has a better understanding of the freight accumulated at that consolidation point.

By enabling this creativity and flexibility – even when all of the factors aren’t yet known – CPO lets you maximize freight savings through optimization while still adhering to pickup and delivery constraints. This is relevant in situations where pickup windows are tight but delivery windows are more flexible. Logistics planners can provide complete deliveries in a single shipment, even when product may be sourced from multiple locations. Customers get better service, and a company could potentially eliminate the need for warehouses or distribution centers in their supply chain.

Continuous pool optimization helps planners embrace those unknown, future options and to be patient, change plans, and get creative with routes.

Rating

In the old days, a TMS needed simplification. Transportation execution practices grew out of a need to simplify and streamline the process because it was really complicated to figure out the best carrier and mode.

In the attempt to create apples-to-apples comparisons, however, we started overlooking the fact that not all carriers are created equal. They all have strengths and weaknesses; they have good lanes and bad lanes; or they want more of some type of freight and less of others, for instance. By striving to simplify the selection process, we’ve boxed in carriers too much.

The latest TMS rating engines don’t need old-school simplification. When asked to rate a shipment, they can compare carriers across all factors, like neutral versus carrier tariff, FAK versus class rating, or blanket versus specific.

The ability of a TMS to handle more complexity is good for the carriers too, because now they have the flexibility to give you better rates. Depending on your needs and constraints, you could use either the carrier’s rate base or neutral tariff, or work with the carrier to improve operations rather than just cherry-picking lanes. And with big industry changes like TL contract rates increasing by eye-popping amounts or the ELD mandate, you’re going to need a TMS that gives you the flexibility to manage carriers and rates creatively.

Think differently

Look hard at your transportation practices. Are they flexible? Can you be creative with them? Or are you forced to simplify for the sake of your TMS? Every organization is going to have drastically different business models, and you are the expert of your business. Sophisticated rating engines and continuous pool optimization can help you create a better business model by delivering the power and programming to do the hard work, plus give you the freedom and flexibility to work with more options and uncover more savings.

JP Wiggins is co-founder and vice president of logistics at 3Gtms, a global provider of Tier 1 transportation management software. There, he manages channels and partnerships. Previously, JP was co-founder and senior vice president of logistics for Global Logistics Technologies (G-Log); co-founder and vice president of product management at dx/dt; and vice president of logistics at Weseley Software.

Why Experience is Necessary When Building a Great TMS

Guest Commentary | By •

My previous two posts focused on the importance of constraints in TMS algorithms and the issues around executing the routing algorithm’s recommendations in a dynamic, real-world environment. These are two very challenging issues that a TMS must be able to address. Customer’s requirements are complex and unless you have spent years in the transportation industry and have built a TMS before, it is very difficult to anticipate these needs in the original design. But, if designed correctly, a TMS should be able to support these needs – accurately, quickly, and intuitively.

  1. Accurately – Transportation is the point at which a company touches the outside world. Deliveries need to be on time and products need to be handled properly. When transportation decisions are not accurate, orders are often damaged or delayed, and money is wasted.
  2. Quickly – Transportation decisions typically need to be made and executed within hours and transportation professionals don’t have the luxury of analyzing data for days or weeks to decide how they will move freight.
  3. Intuitively – Transportation professionals want a TMS to figure out how to move their freight and do so with very little human intervention. For this to happen, a TMS must possess very sophisticated components that can quickly determine what to do while considering many complex variables that carry with them a lot of uncertainty.

There has been quite a bit of discussion in the industry lately about another key attribute of a great TMS, which is usability. As I read a recent post by Adrian Gonzalez discussing how Excel is the most popular TMS, I began to ponder why this is true. The point that resonated most with me was how intuitive Excel is and how comfortable most people are using it. Similarly to Excel, I believe that a great TMS needs to be intuitive. As an extension of your business, your TMS should provide you with familiar screens and data that you are accustomed to seeing and not add layers of complexity to the daily work flows already in place.

Additionally, we have been hearing about the importance of a single platform. In fact, I read a related article not too long ago and I could not agree more that the most common mistake relates to the algorithm being added as an afterthought.  A good TMS (much less a great TMS) should not have its routing algorithm on a separate platform. The algorithm should not use different data as inputs.  It should not require data to be moved to a different environment.  And it should not be written and supported by a third party; the algorithm must be an integral part of the execution platform.

Why is this so important?

I have been doing this for more than 20 years and I’ve never quite been able to come up with a quick and easy explanation for why this is so important but, hopefully, as you continue to read this, the importance of a single platform will become clearer. In my opinion, the major issue is that the inputs to the algorithm are constantly changing, so the data used can be stale by the time the model is done. We don’t have the luxury of “stopping the world” while we run the model and execute its recommendations. Some of the data changes (even seemingly small changes) can drive major routing changes and potentially be very expensive if not handled correctly. We need many decision support tools to address the countless types of changes that occur throughout the day and not expect that one large algorithm will produce a magical plan that can be executed as expected. These algorithms and their single platform must be able to support any type of operation as companies change the way they receive, fulfill, and ship orders over time. Here are a few examples that may resonate with you:

  1. A shipper receives orders throughout the day that are expected to ship that same day: new orders, newly released orders, newly manufactured orders.  This shipper might have to send loads to the warehouse throughout the day. The warehouse needs to pick them constantly and carriers come in throughout the day. At no point during the day are all the orders that will ship known and not yet shipped. Orders might come in at 2 PM to ship by 5 PM after 100 orders have already gone out the door. These new orders need to be routed. Some might go direct LTL or TL, others might be put together to form new multi-stop loads. Still others might be combined with LTLs or TLs that have not yet shipped to save money. The same algorithm that routes only fresh orders cannot handle this scenario; it must be solved by a different algorithm, but one that is part of the single platform that knows which TLs and LTLs can be changed.
  2. In the above (and other) scenario(s), a shipper might release routings to the warehouse throughout the day. Some TLs and LTLs go earlier in the day – when they are set – while others go later as appointments are being scheduled or carriers are searched for or sometimes on the expectation that additional orders might come in to fill out a truck. Here, the single platform driven by the TMS must be able to control not only the execution of the moves, but also the “releasing” of the moves. Only parts of the algorithm’s recommendation are released at a time. This can be very hard to handle if they are on separate systems.
  3. Most algorithms that are on separate platforms cannot share data with the TMS. This creates a real challenge as the algorithms need enormous amounts of data including appointments, hours of service, unloading times by location, special handling requirements by product, etc. Some systems are forced to keep two sets of supporting files for the same data elements. At best, these are hard to keep in synch and therefore could make a system barely usable.
  4. Most changes to a multi-stop load require at least part of the algorithm to be rerun. If the appointment for the first stop on a load is moved from 9 AM to 7 AM, can this load still get to the first stop on time? How does that affect the times for the rest of the stops on the loads? When one considers that the change could involve switching the order of stops or adding a new stop, it’s clear that these are serious algorithms to run, which would be very challenging indeed if the algorithm were not part of the TMS.

The other day, I reflected on all these issues and it suddenly hit me…a great TMS must be designed by someone (or ideally, a team) that has done it successfully before, preferably more than once. A novice could never know enough to consider most of these issues in the beginning, which is when they have to be designed correctly. Even someone who has designed a TMS once before, who would know some of the issues involved, would still get many things wrong. It’s only after trying many different solutions that one can really get it right.

Over 20 years ago, when the first generation of TMSs were created, the industry had two classes of product – algorithmic products that handled complex routing and rating products that did simple routing and payment. The market dictated the need to merge these two classes of products, which required new products to be written from scratch, as the data models of the earlier products could not support the new market requirements. About 10 years later, history repeated itself and it was obvious that the industry needed a much more flexible and functional, feature-rich system to handle more modes and more geographies. Once again it became necessary for new products to be written – from scratch – driven by the limitations of the earlier data models.

Fast forward to today, where we see countless companies with unique and challenging transportation environments, but that don’t require all the flexibility of the top second-generation TMSs, and thus can’t justify the costs of one. The only way the industry is going to change is to create products that are as sophisticated as the top second-generation TMSs, but much less complicated to set up and use. This would require changing the way a TMS uses its data model and advanced designs created by highly experienced TMS specialists who can create the needed features, while protecting users from unnecessary complexity.  This new, third  generation  of TMSs will provide the needed single platform and multi-algorithm capabilities, but without all the “bells and whistles” of the top second-gen TMSs to appeal to a wider array of shippers across many different industries.  Only then will we replace Excel as the tool of choice for TMS.

Mitch Weseley is the CEO of 3Gtms. With 30 years in the industry, Mitch is widely regarded as the “father of the TMS industry” having created six successful companies in the technology and logistics industry, including Weseley Software and G-Log.

Guest Commentary: The Tougher Challenge for a TMS is Execution

Guest Commentary | By •

As a follow-up to my previous commentary, which focused on setting the playing field for transportation routing algorithms and the fact that these are not really “optimizations” but heuristic algorithms, as well as the fact that modeling the constraints is at least as important as getting a lower cost, I want to now shift the focus to the tougher challenge for a transportation management system (TMS) – execution of the recommendations.

The tougher challenge that we face in this industry is trying to route (via algorithms) freight in an environment where the data are constantly changing. This is particularly important for companies that are building multi-stop loads and using pool distribution. These routings create “dependencies” where the routing of one order is dependent on many others.

For example, consider a shipper with a warehouse in Memphis shipping to the northeast. He might have one large order that’s half a truck going to upstate NY along with a dozen small orders going to a pool point in PA. Just as the algorithm recommends this route the big customer in NY calls and adds several items to the order. Suddenly most of the freight going to PA won’t fit. Their routings will have to change even though nothing about the orders has changed. This is dependent routing. If all of the orders were shipping as LTLs or single stop truck loads this would be a minor issue, but in our case, life just got a lot tougher.

The situation described above is exacerbated by the fundamental challenge that algorithms are basically batch processes and essentially run on static data. However, in our industry, the data are not stagnant — they are changing throughout the process. Additionally, much of the information can’t be known until after the algorithm makes its recommendation and the process of load tendering begins.

There are too many dynamic components in this process to list but below are several of the more important ones that are worth thinking about throughout this discussion.

  1. Order Changes – Most companies strive to allow order changes into the process as late as possible. These changes typically come from an ERP and can occur after an order is picked or even staged.

  2. Warehouse Changes – The WMS/TMS integration is particularly challenging. There can be stock outs and in some environments orders can fail QA. In other situations (particularly with mixed product pallets or cartons) the cube and/or pallet count from the ERP might be incorrect. In other cases weight could possibly change. Therein lies the proverbial chicken and egg scenario. The warehouse really can’t pick an order until they know when it will be shipped. On the other hand, order quantities aren’t solid until after it is picked so the algorithm is using data that may not be accurate.

  3. Carrier Availability – Until a load is tendered and a carrier accepts it the rate that the load will run under is uncertain. Therefore one of the most important data elements driving the algorithm can’t be known until well after the algorithm is completed. There are related issues around the availability of specific equipment in some situations and in others there may be a problem getting any equipment given today’s driver shortages. Again, all of these key inputs to the algorithm aren’t known until well after the algorithm is finished.

  4. Appointment Scheduling – This is another chicken and egg situation. If we go back to our Memphis shipper, he might have two orders going to the northeast. Both orders have delivery windows set for only Thursday. However, when the destinations are contacted for appointments the first stop is booked up for Thursday and wants a Friday delivery but the second stop still needs to be delivered on Thursday. Again, this load can’t run as created by the algorithm.

  5. Need to Tender Some Loads Before all Orders are in – Most shippers face a driver and general truck load shortage. Therefore, many shippers want to start tendering loads as early as possible. To reference the Memphis shipper again, he might have an order that is almost a full truck placed late Monday, to ship on Tuesday. He could tender this load as soon as he sees it to get a good carrier and rate. However, if he waits until late Tuesday morning he might find a great order to throw in the back of the truck and have it ride for free.

  6. Real Time Flow – I like to view this process as one where orders are flowing like objects on a river. The orders get created, they go through a process and then they ship. This process sometimes feels like the orders are being shot at with changes such as those described above. Those shots may change the course, but somehow they still need to come out in one piece and routed correctly.

It’s clear that a TMS should not simply send a lot of data to an external algorithm a few times a day and expect to create much value for the customer. In fact, a TMS needs to be built as an execution system to manage the process described above that accesses different routing algorithms, at different points in the process to help make decisions that are too large and too complex to be made manually. The very idea of using a third party algorithm or having an algorithm as a separate module where data is just thrown to it en masse is fundamentally flawed and fated for failure. History shows many companies that have taken this approach and not one has created the quality products that this market needs.

Given that these issues are complex, hard to solve, and expensive when done wrong, one might ask, Is the view worth the climb? Is it worth dealing with all of these challenges when one can just ship the freight direct on single stop truck loads and LTL?

First of all, the potential savings are enormous. I’ve worked with clients that have cut 10-20 percent off of their freight spend. Most companies are willing to put up with a lot to save that much money. Secondly, these issues don’t occur very often so they can be dealt with fairly easily if one has the right tools. However, if these issues are not dealt with correctly all of the savings can disappear or freight could be delivered late or broken. Third, multi-stop routing should improve customer service with faster and more reliable deliveries and less OS&D. So the answer is yes, it is most definitely worth the climb if one has the right tools.

This is an extraordinarily difficult problem to try and solve, and the problems will continue to get more interesting over time as we are more creative with the options we have to ship freight and the requirements are more stringent on how customers want orders delivered. The industry is in need of a solution that will focus on and address issues such as:

  1. Heuristic algorithms to solve problems that can’t be truly “optimized.”

  2. Solving these issues subject to countless constraints that are very hard to model and can’t be violated without serious repercussions.

  3. The realization that algorithms must run on data that is constantly changing.

  4. There are several “chicken and egg” scenarios where decisions need to be tweaked or changed dramatically because of information that could not be known when the algorithms were initially run.

  5. Recommendations must be acted on immediately as orders must be picked (sometimes within minutes) and trucks need to be loaded immediately thereafter.

We have better connectivity tools to provide better quality data faster and we have more powerful hardware to write more complicated solutions. Therefore, there are significant opportunities to revisit how we are currently solving today’s problems – creating brand new, next generation solutions that can change our industry entirely.

Mitch Weseley is the CEO of 3Gtms. With 30 years in the industry, Mitch is widely regarded as the “father of the TMS industry” having created six successful companies in the technology and logistics industry, including Weseley Software and G-Log.

Continuous Moves (Part 2)

Transportation | By •

Last week, I discussed continuous moves in networks where they could be planned with a high degree of certainty. But there is another form of continuous moves — a more ad hoc, opportunistic type of move — that can be very difficult to operationalize. There are several reasons for this.

First, when a carrier commits to a lane rate, the rate is based on the carrier balancing its network. A shipper is often getting an advantageous rate on a lane because that lane is providing the carrier backhauls from other clients. Kevin McCarthy, Director of Consulting at C.H. Robinson, pointed to research showing how efficient carrier networks already are. The Stephens Index shows that for trips of 600 miles by large public carriers, the average deadhead is only 66 miles. Now imagine a continuous move on a 600-mile trip that requires a deadhead of 20 miles. Decreasing empty miles from 66 to 46 is just not that significant. Carriers often do not see the small savings opportunity as being worth the added billing complexity or risks associated with these moves.

Further, almost all carriers have been burned in procurement engagements where a shipper has negotiated continuous move discounts, and promised a certain number of moves that help the carrier balance its network, and then not delivered on their promises.

Shippers may have every intention of using continuous moves, but find them difficult to execute for a variety of reasons. Poor loading and unloading execution at docks can cause continuous moves to fall apart. A carrier may show up, drop a load, and then be forced to wait to load the next shipment. Detention fines then eat up any savings associated with the continuous moves. Because of this, Fab Brasca, VP of Global Logistics at JDA Software, suggests that shippers build a dashboard to track facilities that have poor dock execution and thus give planners the visibility to not book continuous moves through problematic facilities.

If a continuous move involves the receiving and shipping dock at the shipper’s warehouse, they at least have some degree of control over the trailer load and unload process. Mark pointed out that in this instance, shippers need to ensure the continuous move loads get priority. If a continuous move involves deadheading to a supplier, and the supplier loading the truck in a timely manner, that is obviously harder to execute. In that situation, trailer drop and swap programs work far better.

Another problem with ad hoc continuous moves is that shippers lack visibility to a carrier’s driver Hours of Service (HOS) and scheduling preferences. If the string moves begins and ends with their loads, which would be common for longer strings of continuous moves, the shipper can use their TMS to ensure HOS constraints are honored. But the shipper won’t know, for example, that a particular driver has a “get home” request. And carriers, in this tight driver market, want to keep good drivers happy.

Because of these complexities, longer continuous moves that involve stringing several loads together, or a continuous move that is tendered several days prior to execution, or continuous moves involving deadheads (rather than A-B and then B-A) can all be more difficult to execute. Ken Wood, the EVP of Product Management at Descartes, says these problems result in planners constantly having to unwind these moves. This extra works means that they are often unwilling to even attempt executing these types of moves.

Dave Belter, General Manager of Transportation Management at Ryder Systems, says it is these types of operational issues that require extra effort be put in up front. A logistics executive really needs to talk to the carrier, planners, internal and supplier dock teams, and make sure everybody is on board, before commitments are made to carriers and rates are put in the system.

Everyone agreed, continuous moves, particularly of the ad hoc variety, are pretty rare. In fact, Matt Menner, a Sr. Vice President at Transplace, was but one of my sources that said there were more good examples of continuous moves in the late 80s and early 90s then there are today. Customers are ordering smaller quantities on a more regular basis and consequently forecasting transportation moves is much more difficult.

In conclusion, JP Wiggins, the VP of Logistics at 3Gtms, was one of several TMS vendors that saw ad hoc style continuous moves as a sales feature that potential customers ask for in Requests for Proposals but then never get around to executing. I started with the premise that this type of functionality is a good example of a feature that unnecessarily bloats a RFP and causes some potential customers to buy a bigger and more expensive solution than they really need. That is mainly what I heard.

(Note: C.H. Robinson, Descartes, JDA Software, Ryder, Transplace, and 3Gtms are Logistics Viewpoints sponsors).

Guest Commentary: Time for a New Class of Freight Rating

Guest Commentary | By •

“I want to know the real, total cost of my shipments before I make them.” Over the years, we have talked to a lot of shippers and logistics companies who are in the “rating gap.” These shippers don’t need a full TMS, which includes sophisticated planning and execution, but clearly require a highly-functional contract management system or service to determine their expected real total freight cost.

What is the Gap?
Here is a diagram of where and why the rating gap exists. This “Gap” has been very difficult to bridge because complex rating is so difficult that only a TMS with sophisticated rating capabilities can deliver solid “total costs” estimates.

LTL Rating Suite GAP (Source: 3Gtms)
LTL Rating Suite GAP (Source: 3Gtms)

To get correct cost or up-charged sell rates, you can start with basic rating, but you’ll have to know a lot more. You also have to take into account some basic pricing parameters, such as:

  • Type of freight cost – rate base, pallet, mileage, cube, area, flat rate, etc.
  • Client routing requirements
  • Geographic limitations
  • Direct or Interline Service
  • Accessorial charges
  • Client Requested Accessorial charges (i.e. Liftgate, Residential Delivery)
  • Automatically Added Accessorial Charges (i.e. Fuel Surcharge, High Cost Delivery Areas)

Here are common reasons why you need the real total costs:

  • Properly accrue your shipment costs for accounting reasons (i.e. reporting or Sarbanes-Oxley compliance).
  • Provide your customers with accurate shipping choices in the sales process.
  • Manage markups to your customers.
  • Make sure you are not going to lose money on free shipping offers to customers.
  • Provide vendors with a simple web portal to determine correct mode and carrier.

Why does the Gap Exist?
The major issue is that LTL shipments are really hard to correctly rate. Too many shippers are relying on base rates (e.g., YRC 2013) to get a good approximation. This rarely yields anything close, and the difference between expected charges (based on base rate) and actual total charges is usually 20 to 200 percent off. It’s so difficult that a whole industry exists to audit freight bills from carriers because so many are significantly different from the expected charges.

In addition, many TMS solutions lack sophisticated rating capabilities. Also, TMS vendors are not really incentivized to decouple their rating engine and contract management system from the TMS, which forces some shippers to buy more than what they need just to get rating capabilities.

Should I Care About the Gap?
Yes, a valid question because complex issues take time to consider. But here are two examples of what happens inside the Gap, beyond the base rate:

2000 lbs., Atlanta to New York City, 3 pallets:
Base rate: $ 375.96
Real cost: $ 740.26

2000 lbs., Atlanta to New York City, 4 pallets:
Base rate: $ 376.96
Real cost: $ 1,213.26

I won’t get into the details for above, but if interested, I have placed these examples on our website.

In Closing:  Some Numbers
ERP and TMS systems do not have a good track record in regard to contract management technology. In fact, a survey in American Shipper (Transportation Procurement Benchmark Study 2013) shows 60 percent of small/medium shippers are using manual/spreadsheet for contract management and only 4 percent of these shippers are using the contract management module of their TMS.

The fact that less than 40 percent of shippers even use a TMS is also related to this gap. I believe there are plenty of shippers who either have not found a suitable TMS or don’t want to buy a full system just to do comprehensive rating. A sharper point is that most TMS technology is not capable of such rating, or else more than 4 percent of shippers would be utilizing their TMS’ contract management module.

Do you see this gap in the industry? I’d love to hear your comments and input.

Geoff Comrie is Vice President of Business Development at 3Gtms. Geoff founded Transite Technology in 2002, and led the company from inception until the merger with 3Gtms in early 2013. Over the years, Comrie has attained a recognized level of expertise on LTL rating, and is a frequent speaker and discussion contributor on this topic. He has twenty years of experience in technology sales and management, with companies such as Pansophic and Siemens. Geoff is a graduate of Western Illinois University with a bachelor’s degree in computer science.

Copyright © 2020 Logistics Viewpoints, ARC Advisory Group. All rights reserved • Design by

Archives