Analytics is Integral to Optimization in JDA’s Transportation Management System

JDA’s transportation management system (TMS) product management team recently visited ARC to brief us on their product roadmap (JDA is an ARC client and Logistics Viewpoints sponsor). I also got a chance to see a product demo that highlighted those enhancements. Because I’m conducting research on supply chain analytics, the visit also gave me a chance to discuss the analytic capabilities of JDA’s TMS in more detail.

I was intrigued by:

• How advances in TMS usability are connected to the way analytics and user interfaces are blending together.
• How in-line analytics can enhance existing functionality (see “The Science Behind the Benchmarking of Lane Rates” for an example).
• How JDA’s analytics support both enhanced forms of optimization and plan enforcement.

Covering all three of these topics in today’s posting would take too long, so I will just focus on the last point, on how analytics and optimization are working more seamlessly together to improve outcomes.

Understanding how analytics data can impact an optimization run is difficult to visualize. Here is an example of how this works. For ocean shipments, many shippers negotiate discounts if they commit to providing that carrier a certain volume. There is a financial risk to the shipper if they do not honor their commitments. Imagine a shipper that has promised a third of their projected volume on a particular lane to three different carriers. Further, imagine that halfway through the year one carrier has received about half of the tenders on that lane. The optimization engine can take that data as an input, and automatically penalize that carrier in the optimization run, thus greatly increasing the chances that the other carriers will start receiving their fair share of the loads.

Analytics can also be used to examine to what extent the plans generated by the optimization engine are being honored in execution. One metric that can be used is “percent deviation from the original plan.” The plan may have called for tenders to certain carriers, but analytics show what proportion of time planners have not adhered to the original plan. A manager can use this metric and look at the costs the company has incurred from not honoring the original plan and which planners, covering which lanes and customers, were most apt to deviate from the plan.

Just because a planner is not using the carriers suggested by the planning engine does not necessarily mean the planner is at fault. This is where fault codes become useful. If there are exceptions on a lane, the person tendering that lane may be asked to provide a fault code. These fault codes can help to explain whether the fault was the shipper’s or the carrier’s.  Some examples of fault codes include: “tender exceeded the carrier’s capacity limits,” or “tender sent 24 hours before scheduled pickup date,” or “customer requested that a different carrier be used.”

The fault codes selected, in turn, can be turned into analytics that can be used to improve performance by a planner (reduction in maverick spend), a carrier (fewer tenders rejected), or the optimization engine (engine reconfigured to prevent tenders to a particular carrier when delivering to a particular customer destination). However, the use of fault codes is dependent upon making sure planners are trained on how to use them.

Managers must monitor the codes to ensure that they are used rigorously and consistently. A manager can create alerts to see whether planners are consistently using these fault codes. The manager can also drill down and see if users are just defaulting to a token response, or if they are actually selecting different fault codes.

Supply chain management software vendors increasingly seek to differentiate their offerings from their competitors based on the way analytics are used to support usability, functional enhancements, and optimization. JDA has certainly done a good job of using analytics to help differentiate its TMS solution.