5 Steps to a Hassle-Free TMS Software Integration

The time has come to implement a transportation management system (TMS). You’ve prioritized TMS capabilities, analyzed vendors, and sat through several system demos. Finally, everyone has come to an agreement and selected a TMS provider. Now what? 

Next comes the implementation phase of the TMS, which frequently involves integration. For most companies, the integration component consists of integrating with external carrier partners to transmit load tenders, receive tracking messages, and retrieve invoices. But the “heavy lift” with integration usually involves the interaction between your company’s internal systems and the TMS software. 

By following these five steps I’ve outlined for a TMS integration below, you can make what normally is a heavy lift into light work!

1. Assemble the Project Team

This sounds simple, but sometimes, it can be the most challenging part of the process. It can be tricky to gather each Business Process Owner (BPO) into a room or on a call to get their input. 

Involving all key stakeholders from the get-go is essential. Each BPO can help assemble a complete picture of how the TMS software will support each business unit. It also ensures you identify any potential integration touchpoints between systems that may add value to your transportation process. These stakeholders typically will include the following groups:

Upper Management

The most successful TMS integrations include someone that serves as a project sponsor. They emphasize the importance of the project, ensure all engage in discussions, and serve as final decision-makers in prioritizing integration processes.

Logistics

If your organization has a formal logistics department, they must be in the kick-off meetings. If there’s no formal logistics department, then identify those team members that have the most working knowledge of your transportation processes.

Warehouse

Those in the warehouse can communicate any specifics about shipping the product. This may include how orders are communicated to them, what documents are needed to support the shipment, and which systems they interact with (such as a warehouse management system – WMS) to notate information like planned vs. actual shipment details.

Customer Service

When integrating your internal systems with the TMS, the customer service team is usually the best resource to describe their order entry process in your company’s order management system (OMS). Having a thorough understanding of this process ensures all relevant fields needed to create a shipment is captured. Additionally, any nuances surrounding the order entry process must be discussed regarding various order types (sales orders, purchase orders, transfers, etc.).

Accounting/Finance

A big chunk of time saved with a transportation management system is the audit and reconciliation of freight invoices. If the TMS integrates with your company’s OMS or account software, you can drastically reduce the time it takes to process an invoice. Your accounting team will need to share their input on topics like GL coding rules, tolerance limits for auto-approval of invoices, or the application of required vendor codes. All this will help guide the data requirements that support an AP integration of the TMS software.

IT/Development/TMS Support

Any integration discussions need to include your technical folks. These may consist of your internal resources but can include external vendors or third-party resources that support the processes. Most TMS providers should be able to provide an integration support team. This can consist of a solutions architect, a technical account manager, and a sales support resource. They are vital to understanding the full capabilities and limitations of the TMS software from both an end-user perspective and integration capability standpoint.

2. Map Out Current vs. Future State

Current State

Now, the real work towards a successful TMS integration begins. 

You’ll first want to map out your existing supply chain processes. These could be part of the “order-to-cash” cycle, the manufacturing cycle, or a replenishment cycle. Really, anywhere in your processes you transport things from point A to point B. The key processes for a TMS integration generally happen between an order being entered (which might go into an OMS) and the payment of a carrier’s freight invoice. 

From an integration standpoint, most of your time will be spent on this order entry process. Why? Because most of the data that will be transmitted to your TMS is from the shipment import process. 

On the surface it sounds easy. You just need pickup and delivery addresses, item details, target dates, and maybe a couple of other fields sent to the TMS to create a shipment…right? But it’s not always that simple. 

Every shipper has different nuances when entering this information into their OMS. Also, not all order types get entered in the same way. Some data may live in other tables or a completely different system altogether. Fields may be used differently from one order type to the next, and the data may not be accurate (such as stored items, weights, and dimensions). 

This in-depth process mapping discussion with your assembled project team will help bring these things to the surface. It will also help identify any other potential “touchpoints” that need to occur between systems to make your future transportation management processes more efficient.

Future State

Once you’ve mapped out your current state, you can begin working on what you want your future state to look like. 

Your future state will guide the scope of work, answering the question, “What do we want our transportation process to look like once the TMS is integrated?” Generally, as you discuss your current state, the answer to this question naturally comes into focus. 

With all the notes and takeaways of your current state discussions, your TMS support team should provide most of the input of your anticipated future state. A key output should be a depiction via a process swimlane diagram. This will describe any interaction points between the TMS and your internal systems. The most common integration processes that we see when going through a TMS implementation are:

Shipment Import

Importing order details from your OMS into the TMS to create a shipment. This includes required fields, such as:

• ship-from/ship-to names,
•  pickup and delivery addresses, 
• item details, 
• expected ship and delivery dates, 
• and required accessorial services.

Load Return

The “load return” contains data associated with the load in the TMS that would be beneficial to capture, particularly from a customer service or customer invoicing standpoint. This includes:

• the selected carrier, 
• selected freight rate, 
• transit days, 
• tracking numbers, 
• and load status messages such as pickup or delivery dates/times. 

Shipped Data Import

After the carrier is loaded at the shipping facility, clients often request that the load be updated in the TMS with the resulting shipped date/time, shipped quantities, and loaded weight. This can be useful when generating detailed item reporting in the TMS. This data system of record (SOR) is usually in your WMS but can also live in your OMS.

AP Return

The “AP return” contains approved AP details as freight invoices are audited and approved for payment in your TMS. This includes values such as; 

• the invoice number, 
• invoice date, 
• vendor ID, 
• settlement total, 
• GL codes, 
• and other reference data. 

Clients often consume this data in their accounting software., Most companies use their OMS and accounting systems within the same application.

3. Compile Integration Requirements

It’s time to start getting into the nuts and bolts of the integration processes that your project team has identified. 

The first decision point is whether you will take an “all or nothing” or a phased approach to the TMS integration. The “all or nothing” approach means you’ve decided not to go live with the TMS until all integration processes are ready for deployment. Some companies may have no choice but to take an all or nothing approach. Perhaps they have a deadline to sunset an existing application, limited project support resources, or they feel that buy-in to the new process may be at risk if everything isn’t completed before going live.

I like to recommend that companies take a phased approach to TMS integration when possible. Typically, integrating a TMS takes up most of the time to the overall project. Taking a phased approach significantly reduces that timeline. With a phased approach, users spend a few weeks or months working in the TMS. With that time, they usually have a better idea of which integration processes should take priority in later phases. 

Regardless of which approach you decide to take, it’s important to ask the question, “Will this save us time and add value to our transportation process?” It seems obvious that a company wouldn’t move forward with a TMS integration project unless it adds value. Still, at Trinity, we’ve seen many instances where a company spends time and effort integrating systems only to say later, “We don’t rely on that process to manage our workflow” or “I forgot that we had this process in place.” A phased approach helps prevent that from happening.

Transmitting the Data

Once you’ve identified which integration processes will move forward, you’ll need to determine how the data will be transmitted between systems. The most common methods are via file transfer (using an SFTP or AS2 connection) or using an API. 

File transfer can include .xml, .csv, .json, or EDI X12 formats. Some companies even have their own custom-built formats as well. 

Transmitting data via an API may involve connecting to your TMS’s API to send or retrieve data. Your TMS provider could also be able to connect to your company’s own internal API. Regardless of which method you choose, I like to recommend following the path of least resistance. 

In other words, what existing processes do you already have in place that you can piggyback on to accomplish your stated end goal? For example, if you’re already receiving an EDI 850 (purchase order) from your suppliers, you may also be able to use this same file to send shipment details to your TMS. 

Your BPOs, TMS solution architect, and internal technical resources should be able to decide the best approach.

The EDI vs. API Debate

If you were to Google “EDI vs. API” you may get mixed opinions on the value of each approach in a TMS integration. Some commentators may go so far to say that EDI (X12) is “dead” and APIs are the best option for transmitting data. Others will say that EDI has been around forever and it’s not going away anytime soon. 

The truth is that both approaches have value when integrating TMS software. Now, I don’t want to get too far into the weeds explaining the downsides and advantages of each method. There are plenty of resources online if you’re curious. But I do want to outline a few questions you can ask to help find the best approach for your business:

• What type of data transmission methods do we already have in place? Can we reuse any of these to integrate with the TMS?
• If we have any methods currently in place, how flexible are they? If we need more data down the road, can modifications be made easily?
• What is the volume of the data being transmitted? Will we need to send large volumes of data? Or can we send and receive a select handful of fields?
• What is our requirement on the timing of the data? Is it vital that it gets sent/received as quickly as possible, or can there be a delay of a few minutes (or even a few hours)?
• Does the TMS provider have a preferred method for sending and receiving data that allows us to go-live faster?

The answers to these questions will help guide which approach to take toward your TMS integration. 

4. Prep for Go-Live

Testing

Once the integration requirements and initial development work are done, it’s time to prepare to go live. 

A significant component of this preparation involves thorough testing of any integration processes. Any technical resources involved in the project will need input from the BPOs to help devise a good test plan. Answering some of the questions below will help your team develop a plan for testing.

• What is the approximate volume of records we need to test before we feel the TMS integration is working as expected?
• What are the different order types that we need to test? Are there any nuances specific to our business that we need to account for? 
• Who needs to provide the final sign-off to confirm that everything is working as it should?
• Based on what we uncovered in our current and future state discussions, are we accounting for every possible scenario?

Process testing can be a balancing act. You don’t want to get too bogged down with testing that it delays the implementation of the TMS software, but you also want to make sure that go-live doesn’t end up being a disaster. Maintaining an engaged project team and openly communicating with all resources can help you figure out where that “sweet spot” lies.

Hypercare Plan

In addition to a test plan, you’ll also need a plan for hypercare. “Hypercare” refers to the period after the go-live where project team members must maintain heightened attention towards the process. These are some of the things you’ll need to consider in the hypercare phase of the TMS integration.

• The methods of contact should something go wrong. Who needs to be contacted for a particular issue? 
• What will the communication process entail if an issue arises or if changes need to be made?
• How will issues, requests, or bugs will be triaged?
• What is the process for collecting feedback from BPOs and end-users?

Internal and External Communications

Planning for communication with your internal stakeholders and external partners for the go-live is essential. 

Any internal users affected will need to understand how their day-to-day workflows may be impacted. Have a resource that’s ready should anyone not be receptive to the change or have a lack of understanding. This person can help by providing further training or support to ensure a successful adoption of the TMS. 

Your decision to implement TMS software should also be communicated to your external partners. This can include your vendors, carriers, and customers. They should understand any expectations you have prior to final implementation of the TMS, particularly if it impacts the collection of data needed to support any integration touchpoints. Ensure they know your expected TMS go-live date and provide any training as needed to support a smooth rollout.

5. Time to Flip the Switch!

Congratulations! You’ve finally reached the exciting part – flipping the ON switch to your new transportation management system. With your new TMS fully integrated, get ready to see your transportation processes become more efficient and streamlined. Expect improved visibility, better data insights, and enhanced coordination across your supply chain. This implementation means less manual work, fewer errors, and more time to focus on strategic tasks. 

Welcome to a new era of logistics management, where everything runs smoother, faster, and smarter. Your logistics operations just got a whole lot more exciting! 

DISCOVER TRINITY’S TMS SERVICES

ABOUT THE AUTHOR

Chris McAvoy

Director of Managed Services

With 22 years of experience at Trinity Logistics, Chris McAvoy has grown from a Logistics Specialist to his current role as Director of Managed Transportation. Along the way, he’s honed his expertise in various positions, including National Accounts Manager, Pricing Manager, and Solutions Architect.

Chris holds several certifications including Certified Transportations Broker (CTB), Certified Supply Chain Professional (CSCP), and Project Management Professional (PMP).

In his role, he leads system integration projects, onboards new Managed Transportation clients, and drives supply chain improvement initiatives. Chris thrives on working closely with customers, uncovering innovative solutions to elevate their logistics operations.