TMS implementation: sequencing a transport system rollout

Scope: pick the flow, not the feature list

The productive way to scope is by transport flow, one mode, one region, one business unit, taken end to end from order receipt through planning, execution, status and settlement. A vertical slice exposes every interface and every data dependency early, while a horizontal approach that configures planning for all regions before touching settlement discovers integration problems at the worst moment. It also gives the programme a genuine operational reference site, which is worth more in the next rollout than any documentation.

Data readiness is the schedule driver

Three data sets have to be right before anything works: locations with usable addressing and operating constraints, carriers with contacts and capability, and tariffs with surcharges and validity. Each usually exists in fragments across spreadsheets, the finance system and individual memory. Consolidating them is not a technical task and cannot be delegated to the implementation partner, since only the business can say which of two conflicting addresses is correct. Programmes that start this work at design time rather than at build finish materially earlier.

Carrier onboarding is the critical path

Each carrier connection needs commercial agreement, technical mapping, testing and a period of parallel operation, and it moves at the carrier's pace. Sequencing carriers by volume, starting the largest as soon as the message specification is stable, and accepting portal or email working for a long tail is a realistic pattern. Treating onboarding as a post-go-live activity is the most common planning error, because a transport system without connected carriers gives planners more work than the process it replaced.

Settlement cutover deserves its own plan

At the switch, shipments will be in flight, accruals will be open, and invoices will arrive referencing both the old process and the new. Decide in advance which system rates shipments despatched before the cutover, how open accruals are transferred or run down, how disputes on legacy shipments are handled, and for how long the old system stays available for query. Finance should agree this in writing, because unresolved freight liability at a period end escalates quickly and can overshadow an otherwise successful operational go-live.

Planners adopt or they route around

The people whose work changes most are planners and dispatchers who currently succeed using judgement and relationships. If the system produces plans they consider worse than their own, they will override it and the expected benefit disappears while the cost remains. Involving them in constraint definition, showing why a plan was produced, and measuring override reasons rather than override counts turns resistance into configuration feedback. Any measurable benefit case should be built on the flows they agree the system plans well.

Frequently asked questions

Should transport go live before or after a warehouse system change?

Separate them. Both touch despatch, and running two cutovers together removes the ability to diagnose which change caused a problem. Where sequencing is forced, the system that owns despatch confirmation usually goes first.

How much configuration should be site-specific?

As little as the operation genuinely requires. Every local variant persists through testing and every upgrade, so distinguishing a physical or regulatory necessity from an inherited habit is worth doing explicitly during design.

What is the most reliable early warning of trouble?

Master data tasks slipping without an owner, and carrier onboarding that has not started by the time build finishes. Both are visible months before go-live and both are routinely reported as amber while the plan still assumes the original date.