Large shippers are investing heavily in transportation and supply chain transformation. SAP TM deployments, Oracle Transportation Management programs, Blue Yonder implementations, ERP modernization, cloud migrations, and major system integration projects are all designed to create more scalable, connected, and efficient operating environments. These initiatives are important and, in many cases, necessary to support the future needs of complex global supply chains.
But large technology programs are rarely simple. They involve multiple systems, business units, partners, integrations, testing cycles, migration phases, and organizational dependencies. Even with a clearly defined target architecture, it can take significant time before the new operating model is fully deployed and its expected value is realized.
Research into large technology programs supports the scale of this challenge. McKinsey has reported that major IT initiatives across industries frequently exceed their original budgets or schedules and can underdeliver against expected business objectives and benefits. While this research is not specific to transportation management systems, many of the same complexities, including changing requirements, integration dependencies, governance, testing, migration, and user adoption, also apply to large TMS and supply chain transformation programs.
For logistics operations, however, the pressure is immediate. Goods still need to move, bookings and confirmations must be handled, operational data exchanged, and shipments monitored across carrier networks.
This raises an important question for companies undergoing transformation: what happens when the future-state architecture is still months or years away, but the operational problem exists today?
The answer does not necessarily have to be “wait.” In many cases, companies can address a specific freight execution problem now by introducing a modern, ready-to-use solution around their existing environment. This can help save time, reduce operational effort and cost, avoid unnecessary custom integration work, and start delivering value before the broader transformation is complete. Even if introduced initially as an interim solution, the business benefits can be immediate.
The Transformation Timeline and the Operational Timeline Are Not the Same
One of the challenges of large enterprise programs is that the transformation timeline can gradually begin to dictate the timeline for operational improvements around it. A logistics team may already know exactly what it wants to automate, whether that is ocean booking, carrier onboarding, freight execution, tracking, or another process, but the requirement becomes part of the wider implementation roadmap rather than something that can be solved independently.
The answer may be that the capability will arrive in a later phase, after the new TMS goes live, or once a particular integration workstream has been completed. In the meantime, logistics teams may continue to rely on portals, emails, spreadsheets, legacy integrations, and manual processes that they already know could be improved.
The cost of waiting is not only measured in project time. Every additional month of manual bookings, spreadsheet-based processes, repetitive data entry, fragmented carrier communication, or avoidable operational work creates its own cost for the business.
This does not necessarily mean that the transformation program is badly planned or badly managed. Large transformations and day-to-day operational requirements simply operate on very different timescales. A global TMS implementation must consider long-term architecture, governance, security, migration, process harmonization, and many other factors, while an operations team may need to solve a specific booking or execution problem today.
The question is whether these two timelines must always remain tightly coupled.
Enterprise transformation programs also naturally involve substantial consulting and system integration work. These partners play an important role in helping companies design, deploy, migrate, integrate, test, and adopt new platforms. There is also a commercial dimension to consider. Depending on the engagement, implementation work may be delivered through fixed-price, outcome-based, time-and-materials, or hybrid commercial models. Under a time-and-materials structure, customers generally pay for the actual time and resources used during the implementation.
Different commercial models therefore create different distributions of risk and incentives around implementation effort and time-to-value. This does not mean that system integrators intentionally prolong projects, but the commercial dynamic can differ from that of a provider whose success depends on getting a focused capability live quickly.
For a shipper, this creates another option: rather than launching another major transformation project, the immediate need may simply be to make one part of freight execution work better now.
What If You Solved the Operational Problem First?
Consider a company that is halfway through a major TMS, ERP, or cloud transformation. The future-state architecture may be entirely appropriate, but a particular logistics process still requires improvement. Ocean booking may remain highly manual, carrier onboarding may be taking too long, or one business unit may need to automate freight execution well before the wider transformation reaches that part of the organization.
The traditional approach would be to place that requirement into the transformation roadmap and wait until the relevant phase is reached. A different approach is to separate the operational problem from the wider transformation program and ask a much narrower question: can we make this specific process work better now, without disrupting the strategic roadmap?
This is increasingly possible because the logistics technology landscape has changed significantly. Modern cloud-based platforms, reusable connectivity layers, APIs, standardized interfaces, and AI-enabled applications enable companies to introduce capabilities around their existing enterprise systems rather than designing and building everything as part of a single large implementation.
The question therefore begins to shift from “How do we build this capability?” to “Which parts already exist, and how quickly can we assemble them around the environment we already have?”
For the customer, this changes both the economics and the timeline. Instead of funding another long design-and-build workstream, the company can deploy proven capabilities faster, reduce manual work, lower implementation effort and operational cost, and start seeing value sooner.
Not every capability needs to be pulled forward. Core transportation planning, master data, governance, and other processes that belong naturally in the future TMS can remain on the transformation roadmap. But focused execution activities such as rate management, booking, carrier communication, selected visibility workflows, and freight audit can often be addressed independently around the existing environment. The objective is not to recreate the future TMS early, but to solve the operational gaps that are creating cost and manual work today.
Can AI-Based LogTech Eliminate the Need for Major Freight Execution Transformation Projects?
Artificial intelligence adds another dimension to this shift, but its value is not simply about making everything faster. The more important change is that modern AI can reduce much of the repetitive operational work surrounding freight execution, from interpreting and normalizing information to comparing options, checking bookings, identifying discrepancies, monitoring events, and supporting decisions.
Importantly, this is no longer only a future concept. Ship Angel is a good example of an AI-native logistics platform that is already available today and can be introduced around an existing technology environment rather than requiring a company to launch another major transformation program first. Ship Angel describes its platform as modular, with individual capabilities that can work independently or together, including rate management, booking and execution, spot procurement, invoice auditing, purchase-order management, and visibility.
In practice, this can create a lightweight execution layer alongside the transformation program: rates can be managed, booking decisions supported by AI, bookings executed with carriers, and invoices checked without waiting for the corresponding TMS workstreams to be completed. Its MADDY agentic AI layer extends across these workflows. Rather than functioning simply as a conversational assistant, MADDY is designed to work with operational context such as rates, contracts, shipment information, booking history, and carrier performance. It can support booking decisions, identify risks and discrepancies, recommend alternatives, monitor execution, and assist with freight audit and other operational tasks.
For shippers, this means a defined operational requirement can be addressed without waiting for a new TMS, ERP migration, or wider transformation to finish. Ship Angel's modular architecture allows individual capabilities to be introduced around the systems already in place and expanded if the initial use case proves valuable. Implementation speed is only part of the equation. Combining relatively rapid deployment with AI-supported execution can reduce both the time needed to introduce a capability and the repetitive operational effort required once it is running.
Shippers can therefore begin with a specific process, prove its value in the existing environment, and decide how broadly to expand it, allowing modernization to start producing returns while the strategic transformation continues in parallel.
The Other Half of the Equation
Execution technology alone does not solve the whole problem. Freight execution depends on communication with carriers and logistics service providers operating across APIs, EDI, file-based interfaces, proprietary formats, industry standards, and different interpretations of those standards. This is often where an otherwise straightforward automation project becomes more complicated.
Modern connectivity providers can reduce this complexity by introducing a reusable layer between the customer's systems and the external logistics ecosystem. Coneksion's approach, through its technology-agnostic integration platform and RAPIDS Common Carrier Layer, is based on harmonizing differences between carrier systems, interfaces, message formats, and operational workflows so that each new relationship does not have to become another completely independent point-to-point integration project.
The principle is relatively simple: where a carrier connection, data model, transformation, or workflow already exists, reuse it rather than rebuilding the same capability for every new customer environment.
This creates an important combination: Ship Angel can provide the operational execution capabilities, while Coneksion provides the reusable connectivity required to reach carriers and logistics service providers. Together, the two layers can address a defined operational problem around the systems the customer already has, reducing manual work, delays, integration effort, and project overhead without recreating an entire future-state architecture.
Start With a Working Process, Not Another Roadmap
This is where a Quick POC (Proof of Concept/Pilot) becomes particularly relevant. Rather than beginning with a lengthy design process and major implementation commitment, a shipper can test a real freight execution workflow with selected lanes, carriers, or a specific business unit, run actual data through the process, and evaluate the results under real operational conditions.
Rather than relying primarily on a future-state promise, the provider is expected to demonstrate a working outcome. Can the carrier connection be established? Can the booking workflow operate? Can manual work be reduced? Can the capability coexist with the customer's current environment? These questions can be answered through practical execution rather than through architecture diagrams alone.
If the POC proves valuable, the organization can then decide whether the capability should remain focused, scale across more carriers or business units, or become part of the longer-term technology architecture.
Independent Does Not Necessarily Mean Temporary
It may be tempting to describe this capability as simply an interim solution that fills the gap until the new TMS goes live. In many cases, however, that may underestimate its longer-term value.
Even where the original intention is genuinely temporary, a solution that can be deployed quickly and generate measurable savings or operational improvements during a multi-year transformation may justify the deployment in its own right.
Carrier connectivity is a good example. An organization may change its TMS, modernize its ERP, or migrate applications to the cloud, but it will continue to communicate with carriers and logistics service providers.
A reusable connectivity layer therefore solves a problem that exists independently of the TMS transformation itself. When the new TMS eventually goes live, existing carrier connections, data flows, and execution capabilities do not necessarily need to be rebuilt. They can be connected into the new environment, continue as independent services, or be retired where the new platform takes over. The operational value created during the transformation does not automatically disappear at go-live.
Creating More Optionality Around the Core TMS
A modular approach gives logistics organizations greater flexibility around the core TMS. Adding another carrier, testing an AI-enabled workflow, or addressing a new execution requirement does not necessarily need to become another major TMS workstream.
The strategic TMS can remain the backbone for governance, master data, and core transportation processes, while ready-to-use execution and connectivity capabilities evolve around it as business needs change. This creates greater optionality in how and where new operational capabilities are introduced.
This also creates financial flexibility. Companies can avoid turning every new requirement into another major integration or consulting project and focus transformation resources where they are genuinely needed.
Enterprise systems can evolve at enterprise speed, while operational capabilities evolve at business speed.
Want to see how this works in practice?
Join Ship Angel and Coneksion for the “Automating Freight Execution Before Your TMS Goes Live” webinar to explore how shippers can automate selected freight execution processes, connect carriers, and start realizing value while the wider TMS transformation continues.
Register for the webinar>>
Your Transformation Can Continue While Freight Execution Improves
None of this is an argument against major TMS platforms, system integrators, consultants, or large enterprise transformation programs. These initiatives remain essential for many organizations, but they do not have to determine the pace of every operational improvement.
Ready-to-use execution platforms, reusable connectivity, and AI-enabled automation now allow companies to address selected freight execution processes around their existing environment, test their value, and expand from there while the wider transformation continues.
This means the business does not have to choose between long-term transformation and short-term operational improvement. It can continue its strategic roadmap while reducing manual effort, avoiding unnecessary integration work, saving time and cost, and deploying more modern ways of working today.
Your future TMS may still be under development, but your freight operation is already running. Improving it now can create tangible operational benefits long before the larger transformation is complete.
