One platform, three systems: Why TMS, WMS, and workforce tech get bought separately (and shouldn't)

Walk into almost any enterprise logistics RFP process, and it always plays out in roughly the same way. First, the transportation evaluation team narrows down their choices for the best TMS. Then, warehouse logistics gets its own RFP for a WMS to run in the newly leased warehouse that the CEO just approved in a separate meeting. And finally, the system to manage the workforce (onboarding and identity verification, to name a few aspects to pay them) is bought by HR or ops as a 4th or 5th priority, often years after the two other systems have been implemented and are running as standalone systems.

These costs are often not even listed out in detail and thus can easily be forgotten in subsequent years of the company’s budget. And in the meantime, a lot of damage can be done that is then compounded before anyone even realizes what has happened.

Why the "buy three separately" pattern persists

The logic behind separate procurement isn't irrational on its face. Most executives believe it is ideal to pick the best-of-breed TMS, WMS, and workforce management systems and integrate them to form a whole that is greater than the sum of its parts, outperforming single unified platforms that may only manage to deliver mediocre results for all functions. For years, the advice has been to go for best-of-breed and then integrate. What used to be called a unified platform was, for years, a big, bloated, generic system that did everything only just well.

To be clear, for years best-of-breed procurement of various systems has operated under the assumption that system integration is a solved problem and therefore can be a line item in the budget for a year, and then you are done with it forever. In reality, each best-of-breed system (in this case a TMS, a WMS, and a workforce management system) is an independently written system with its own API and data model, etc. Therefore, in addition to the various updates, patches, and bug fixes that each system will go through from time to time, there is a cost to the other systems to maintain integration with that updated system. And, of course, there is always the possibility that one or more of the best systems will be replaced by an even better system. A recent analysis of how companies are spending their money on logistics technology came up with an interesting term to describe the costs of the individual systems minus the costs of the gaps between them: “fragmentation debt." Just as with technical debt, the cost of the fragmentation debt is hidden and therefore grows quietly and suddenly until it can no longer be ignored.

What the integration tax actually looks like day to day

The first is reconciliation labor, where someone has to compare the delivery status from the TMS with the up-to-date inventory numbers from the WMS. Drivers’ shift logs in workforce tools have to be compared with the trip data recorded in the TMS. The labor involved in this type of work is often ‘absorbed’ in the roles of ops and finance personnel and thus underestimated. But the root cause needs to be addressed in order to eliminate this cost.

Furthermore, even more subtle but very expensive failures will occur, i.e., reconciliation labor will be spent to confirm delivery status updates that were previously unknown in the TMS and corresponding updates in the WMS. These confirmations also form the basis of corresponding updates in the spreadsheets that are used to attempt to reconcile the data between the three systems and between the TMS and the WMS.

A third and fundamental problem with non-integrated systems is that they cannot support real-time coordination. As mentioned earlier, the route optimization in a TMS does not work if the system does not have up-to-date information on whether the destination warehouse can receive the shipment on time. In the same way, a workforce system does not know whether a driver has been assigned to a new trip in the TMS.

Therefore, the driver will be rostered for a shift that no longer exists. This is the kind of problem that independent research on warehouse technology adoption identifies as a major problem in terms of warehouse inefficiencies. The root cause of these problems is identified to be the use of fragmented system architectures and inconsistent workflows between sites, leading to low levels of responsiveness and high costs. This is the kind of problem that occurs when the systems that support a chain of decisions do not share the data on which those decisions are based.

Why this gets worse, not better, over time

As each of the three systems (TMS, WMS, and workforce platform) is constantly evolving, each update to a system creates a host of integration problems for the other two systems. For example, the API for a TMS’s incoming requests may have recently gone through a version update by the vendor of the TMS system. The changes to how certain SKU-level data is represented at the API level for a WMS system could also pose significant problems for systems attempting to integrate with the updated WMS system. And lastly, an acquisition of a company providing a certain workforce platform could cause that system to be remigrated to a completely new set of physical and virtual infrastructure in a matter of months, as was the case with the recently acquired platform.

Poor system integration is cited in broader research as one of the main reasons for the failure of digital transformation to meet expectations. The poor integration of systems does not necessarily mean that the individual systems have been poorly designed. The problems with integrating systems are structural in nature and stem from the attempt to run an enterprise as a single architecture, using systems that were not designed to be part of a single architecture.

What "unified" should actually mean

Instead of buying and maintaining three separate systems, a monolithic legacy system is not the better design for “unified” in a shallower function but in a broader scope of functions. This is the opposite design principle to best-of-breed thinking. The better design for “unified” is that of a modular platform that has been developed as a single architecture from the start. As connected modules within a single intelligent ecosystem, the TMS, WMS, and workforce management functions can be offered and deployed independently or in combination, without the need for custom-made integration to interact with each other.

Libera’s platform architecture is based around three connected modules: transportation, warehousing, and the workforce. These modules form part of a single intelligent ecosystem as opposed to three separate products that have been cobbled together after the fact. For example, the status of a shipment in Libera’s transport management system is the same data that is used in the warehouse management system to plan the receiving of inbound shipments. The same data is also used by the Workforce Ecosystem Technology to schedule the correct driver for a particular trip. Customers can deploy any of the modules as a first step and continue to add others as required. This preserves the flexibility that best-of-breed solutions promised and avoids the fragmentation debt of separate solutions that were never designed to work together.

Three Systems, One Bad Morning

Consider what happens on an ordinary disruption day under both models.

Three separate systems: It's 6 AM, and a delivery associate calls in sick. The workforce module has noted the absence of this delivery associate; however, the absence has not been notified to TMS. Thus, the trip assigned to this sick delivery associate is still "staffed," and when the ops lead cross-checks between the workforce module and TMS, he/she finds out the reason for the delay of the expected pickup time of the trip assigned to this delivery associate. Although the absence of this delivery associate will be notified to WMS by the Ops Lead, the WMS has no visibility on staffing changes made on the TMS side. Thus, WMS finds out the delay of the expected pickup time of the trip when the truck fails to arrive on time. By that time, the dock slot assigned for the expected pickup time of the trip would have been assigned to other shipments for sure. Thus, the expected pickup time of the trip is now delayed by 90 minutes.

One connected platform: The same delivery associate calls in sick. In this case, the workforce module automatically finds a replacement for the sick associate. The TMS immediately recognizes the change in staffing for the assigned trip and reassigns the trip to the newly assigned driver. The warehouse module immediately recognizes the updated trip time and makes the required changes to the dock schedule. All changes are automatically processed without anyone having to cross-check between systems.

Nothing had changed to the basic circumstances of the disruption occurring on the two days. However, between the two days, the systems had changed from all of them showing the one ‘true’ situation to each system now showing a completely separate ‘picture’ of reality. Thus, each system had to be cross-referenced with the others by someone before any action could be taken.

The Real Question for Anyone Evaluating a Point Solution

There are many shippers in the process of evaluating TMS, WMS, and workforce management solutions that are offered by separate vendors. While there are many strong solutions available for each of these functions, the key question for any shipper evaluating these solutions today is what happens the day after one of the three vendors releases an update that causes a change in how data is exposed by the system.

At its core, the main difference between point solutions and a unified platform is the architecture. This architecture is what ties three critical systems together and supports an operation as it grows and changes. The best individual feature of the best vendor does not matter here. What matters is the architecture. And, as is the case with a lot of technical debt, the architecture of a unified platform for TMS, WMS, and workforce tools generates significant fragmentation debt, which can be put off for a long time but will end up being very expensive to fix. Unlike most technical debt, however, this debt does not get to be a single bill that can be paid at a later date. Instead, it acts as a permanent tax on every decision that must be made that crosses the boundary of systems that were never meant to be one.