Fundamentals of a Successful Transportation Management System

The Differentiating Requirement

While it may seem trivial and unexciting, the functional requirement represents the fundamental building block for any successful transportation management system (TMS) selection and implementation.

Requirements are critical to ensure the shipper has found the most optimal vendor-partner, and they are also foundational to nearly the entire implementation process.

This article highlights the most frequent “traps” we see shippers falling into during the project phase that arguably has the most impact on implementation success – the Vendor Selection stage.

Sophisticated shippers capture and prioritize business requirements as a key input into their TMS vendor selection process.

Unfortunately, most shippers rely too heavily on 3rd party industry analysis that can’t identify the specific functional requirements that can enable them to more precisely down-select one or more TMS software vendors.

At JBF, we call these “differentiating requirements,” and they are essential to the proper fit, selection, and implementation of supply chain execution systems.

The problem with “differentiating requirements” is they often require an implementation-level understanding of how two or more different TMS will solve this problem.

A shipper cannot easily understand how multiple TMS platforms will interpret or “solve” requirements through features and functions, and therefore won’t be able to characterize a requirement as “differentiating” to their solution.

Further, shippers that rely upon consulting firms specializing in a single vendor platform will also tend to struggle identifying these unique requirements, as their implementation expertise is largely focused on that single vendor’s capabilities – and not the other TMS vendors you might invite to your RFP.

Detecting the Aliens

Consider the extra-terrestrial life forms from the “Men In Black” movie franchise. Only the pros in the black suits knew these aliens existed and were the select few people that could spot the aliens running amuck on planet Earth.

In order for a shipper to understand “fit for requirement,” they must also understand something about how the TMS vendor “solves” this requirement through features and functions.

It is through the relative understanding of multiple vendor’s technology feature-functionality that we can isolate the “Differentiating Requirements” (Aliens) from the normal, everyday requirements (Humans, essentially).

Through knowing how multiple vendors will treat or react to specific requirements – we are then able to help shippers select TMS and other logistics technology that “fit more like gloves, and less like mittens,” as JBF Partner Mike Mulqueen likes to say.

Failure Points

If we expand this visualization, we can also highlight where we see many possible selection failure points.

To be sure, both shipper requirements and the magnitude of TMS vendors’ feature-set are constant sources of complexity in making these decisions. Both parties- shippers and software vendors - contribute to the quagmire that comes from a poorly selected system.

In our experience, the following scenarios are the most common:

Common Scenario #1 analogy works for situations where the shipper relies upon advisory either from a ‘biased’ source like a Systems Integrator that has an exclusive (and often financially biased) relationship with a software vendor, or advisory from industry analyst firms that rank vendor capabilities and vision against other vendors.

In both cases, the “advisor” only sees part of the equation necessary to more precisely “fit” a shipper to their ideal set of vendor capabilities.

Common Scenario #2 – The Vendor Bloat trap is another common selection mismatch, where the shipper selects a TMS that supports all the shippers’ requirements, but there are a large number of dormant features that the shipper will never utilize.

In some situations, the application “bloat” are features that require configuration to deactivate, causing additional work and complexity during implementation.

Additionally, many shippers will struggle with these systems long-term, as there is often a perception at the user-level of the system being “overly complicated” to implement and use.

Common Scenario #3 – Perhaps the most frustrating vendor selection failure of all is the ‘Unknown Requirements’ scenario.

Here, the shipper has invested little to no time in understanding their own business requirements, capturing and prioritizing these requirements, and then communicating these to the vendors prior to selection. Amazingly, we still see this approach quite often – and strongly believe this leads to a higher probability of implementation failure.

 When asked about this approach, shippers will often comment that it’s “too difficult and time consuming to capture all these requirements.”

Other shippers will say “we used the requirements given to us by ‘Vendor C’ in our RFP,” which is sometimes even more difficult to overcome when it’s time to design an integrated system.

 

Prioritize Requirements

The key thing for shippers, or any software buyer, to understand: The first step in any implementation is discovery leading to capture and prioritize requirements!

Without requirements, we have no clue what we’re designing, how to prioritize the build, or how to validate the end solution is complete when compared against what the shipper was hoping to achieve.

Going one step further, identifying ‘differentiating requirements’ prior to vendor selection is critical to the shipper if they want to avoid some of the most costly and disruptive implementation failure points.

This is a clear case of ‘pay me now, or pay me later,’ coupled with the new reality that by skipping over the requirements due-diligence prior to selecting the TMS vendor – you have introduced a great deal of risk to the implementation of the software.

The Buyer Mindset

If we were to remove the complications of software for analogy purposes, people as “buyers” intuitively build their own set of requirements prior to major purchasing decisions.

When you bought your first home, did you consider things like location, number of bedrooms & bathrooms, garage size (more is better!), and overall aesthetics?

I’m sure you did!

These requirements define the “wants and needs” prior to a purchase that is often difficult to change after the transaction (Reader - I’ve learned it’s very hard to expand a garage).

Key Takeaways

The effort you put into the up-front requirements capture and prioritization prior to vendor selection will pay huge dividends for you in the implementation and steady-state phases.

Soliciting expertise from objective, vendor-neutral advisors with implementation experience can also help to remove risk by ensuring a higher-probability fit within matching shipper requirements to vendor feature sets.

To be sure, this step will take time and may slow down your purchase of the TMS – but it is far better to execute this step prior to selection instead of realizing you have a great deal more customization to do (and at what cost?) during the implementation.