In our recently published study, “The Implementation Integrity Gap,” our survey shows nearly 90% of implementations fail to deliver upon expected outcomes or cost savings targets. As an implementer of logistics technology for 30 years (my first TMS implementation started in 1996, still on mainframe ‘green-screen’ technology), one very consistent thread surfaces looking back – (reader note: the ‘em-dash’ is my own) logistics functional leadership consistently views implementation as an IT delivery task, instead of actively designing an operating model that delivers upon their own desired outcomes.
Shippers, specifically functional leadership, demand “Agility” in Supply Chains - yet fail to recognize their key role in designing a system and process that supports operational workflows, providing valid master and transactional data to systems AND end-users, and facilitating the outcomes they typically seek from their investment in transformation.
Yes, I’m talking specifically about systems integration – and I’m holding business leadership accountable. While IT (or the system integrator / software vendor) may ‘own’ the data map and technical development and deployment of integrations, functional leadership appears powerless and/or apathetic to the business logic and functional design decisions inherent within each integration object.
Integration is not simply a “handshake” between systems – it is the dynamic infrastructure of the automated business operating model. As an analogy: the logistics functional pillar represents the “brain,” the IT department is the “body,” and integration is the “nervous system” of the body. If your objective is to run a sub-3:00 marathon, all three of those things need to be tuned and work together in harmony for that to happen.
More directly, logistics functional leadership should be leading the functional design of systems integration. This is the optimal time within the implementation of a system to define how systems will talk with each other to enable business outcomes. This is also the period of the implementation that presents the business with the opportunity to hand over more of the delivery accountability to their IT partners – not before.
Some specific integration problem areas are very common in my experience. Some highlights:
1. Customer Order Date Logic – This is typically the single most critical integration object to get right, which has the highest correlation to a “cost savings” outcome. Designing the TMS-required “pickup window” and “delivery window” is the synthesis of usually a single ERP date, customer service policy, and inventory allocation and fulfillment. Most shippers have multiple customer channels, order types, product lead times, and pickup / delivery policies that impact the design. If your business case revolves around cost savings through order consolidation, focus your time and attention here!
2. Customer Order & Fulfillment Policy – Indeed, policies are a very important input into business integration logic. Consider a hypothetical policy of “orders received by 2pm ship same-day” and then ask, “Is that always the case?” It’s usually far more complicated than that. Couple that with carrier pickup cutoff times – and cutoff time changes – that can also differ between carriers. Digitization of policy and providing business-level controls over policy changes yield greater agility, at the expense of some up-front brainpower.
3. Purchase Order & PO Line-Item Creation Procedures – For inbound or primary network-centric shippers, PO and Line-Item level integration can be very complex. There is often a wide mix of order ‘fidelity’ depending on whether specific suppliers or commodities ship against blanket or discrete POs. Further complicating matters, many ERP systems and Purchasing procedures can be of significance to the integration design. Does Purchasing use a “fill or kill” policy for line-item cancellations? Or, do they retain PO header and update line-item quantities? Depending on the TMS, either can be a challenging integration to design.
The three examples above are complex yet are prevalent in nearly every TMS implementation. Business leadership that does not understand the functional design and design decisions that went into those integrations is rolling the dice, hoping their IT peers or the vendor asks the right questions. Design mistakes in any of those, plus others, can lead to not only a reduction in benefits realization but also create new opportunities for order fulfillment to fail.
Bottom line: Integration is an Operating Model problem that should be solved by the business and codified by IT, otherwise shippers are risking implementation ROI and a lack of agility in their supply chain.
Download the report for the complete findings and the JBF framework for closing the gap.
About the Author
Brad Forester is the Founder and Managing Partner of JBF Consulting, bringing more than 25 years of leadership experience in transportation strategy, logistics technology, and supply chain transformation.
A recognized industry expert, Brad has advised Fortune 500 companies and high-growth brands on complex global transportation initiatives, from network design and technology selection to implementation and value realization. His background spans senior roles in consulting, software, and shipper operations, giving him a uniquely balanced perspective on strategy and execution. Brad is a frequent industry speaker and thought leader on TMS, visibility, and logistics innovation.
FAQs
Nearly 90% of logistics technology implementations fail to deliver expected outcomes or cost savings because functional business leadership treats implementation as an IT delivery task rather than an operating model design challenge. When logistics leaders disengage from integration design decisions, critical business logic is left to IT or vendors who lack the functional context needed to drive ROI.
Systems integration is the dynamic infrastructure of an automated business operating model — not simply a technical handshake between systems. In a TMS implementation, integration connects business processes, master data, and transactional workflows. Logistics functional leadership should lead the functional design of integration, with IT codifying those decisions into technical development and deployment.
The three most common integration failure points in a TMS implementation are:
1. Customer Order Date Logic, which drives pickup and delivery windows and is most directly tied to cost savings through order consolidation
2. Customer Order and Fulfillment Policy, including same-day shipping rules and carrier cutoff times
3. Purchase Order and Line-Item Creation Procedures, which vary significantly by supplier type and ERP system
Poor integration design directly undermines supply chain agility by hardcoding flawed business logic into automated workflows. Without digitized, business-controlled policies embedded in integration design, companies lose the ability to respond quickly to changes in customer requirements, carrier rules, or fulfillment conditions — creating both a reduction in benefits realization and new risks of order fulfillment failure.
Business and logistics functional leadership should own the design of systems integration, with IT responsible for codifying and deploying those decisions. Integration is fundamentally an operating model problem, not a technical one. When business leaders delegate integration design entirely to IT or third-party vendors, they risk implementation ROI, reduced agility, and system designs that fail to reflect real-world operational complexity.
