Why TMS implementations fail (and the failure is rarely the software)

Ask a carrier about the transport system they stopped using and the answer is usually one line: it did not fit the way we work. It is a comfortable sentence, because it puts the fault outside the building — in the software, or in the vendor who sold it. Sometimes that is fair. More often the product was adequate and something else went wrong, and the something else is common enough to have a shape.

Four patterns account for most of the wreckage. None of them is technical, and all four are cheaper to prevent than to survive.

1. The data goes in dirty

Every operation carries a customer list that has grown for a decade without anyone being paid to tend it. Three spellings of the same consignee. Addresses that are really a driver’s memory of which gate to use. Price agreements that live in a folder of emails rather than in any system. Nobody minds, because the people who use the list know what it means.

A migration does not clean any of that. It copies it, faster than anyone can read it, and drops it into a system where the ambiguity is suddenly visible to everybody — including a planner who does not know which of the three consignees is the real one. From the inside, that reads as the new system is wrong.

The antidote is not a data-quality project. It is a slice. Clean the customers you have invoiced in the last twelve months, the addresses on the last few hundred bookings, and the price sheets you actually quote from. The tail — the customer you served twice in 2019 — can arrive later, or never. Deduplicate on the fields the new system will match on, not the ones that look untidy to a human.

Do the count before committing to anything: export the customer list, sort it by name, and see how many near-duplicates you have. An afternoon spent that way predicts the project better than any demo.

2. Nobody’s name is on it

“The management team is driving it” means it is nobody’s. So does an owner who has the title but not the hours: the dispatcher who is going to configure the system between dispatching days will configure it in the evenings, badly, for about three weeks.

An implementation owner needs three things, and the third is the one that gets skipped. Protected hours in the working week. Authority to decide — which fields are mandatory, whose spreadsheet stops being authoritative, what happens when two departments want different workflows. And enough proximity to the work to feel it going wrong; someone who plans, dispatches or bills is a better owner than someone who only reports on it.

The vendor cannot be that person, and neither can a consultant, for the same reason: they leave. A project owned entirely by IT tends to launch technically correct and operationally unused.

3. Everything changes on Monday

Big-bang cutovers are tempting because parallel running feels like paying twice, and a little like admitting you might fail. So a date is set, the old system goes off on the Friday, and every unknown in the project arrives at once — on the day the operation is busiest and least able to absorb it.

The worse part is what a big bang throws away: the old system still being warm. A rollback that means restoring a backup is not a rollback anyone will choose at 07:00 on a Monday with trucks waiting.

The cheaper shape is a slice with a real edge — one depot, one customer, one recurring lane — run end to end for a fortnight. End to end is the part people cut. A pilot that stops at planning has tested the enjoyable half; the half that finds problems is proof of delivery, the invoice, and whether accounting recognises what came out of it. Then widen. Two weeks of double entry on one lane costs less than a month of an operation running on adrenaline and group chats.

4. The old process, wearing new screens

Every operation has workarounds that exist because the previous tools could not do something: the whiteboard beside the desk, the group chat that is really a dispatch queue, the spreadsheet nobody admits to maintaining. In an implementation these get faithfully re-created, because that is how we do it — and the result is new software configured to reproduce the limitations of the old software.

The question worth asking of every step is what it is for. A surprising number of answers turn out to be “because the last system could not do X”. Some are real controls and must survive. The point is to find out which, while somebody is still being paid to look.

This is also where good systems get switched off. A system doing its job refuses things: a tour that breaks driving-hours limits, a load that must not travel with the load already aboard, a vehicle whose roadworthiness date has lapsed. In week one those refusals feel like friction, and there is always pressure to disable them until things settle down. Disable enough of them and you have bought a more expensive way to run the operation you already had. The refusals are the product.

Where the vendor shares the blame

Plenty of implementations fail on the supplier’s side of the line, and most of the warning signs are visible before the contract is signed:

• The demo runs on rehearsed data. A demo on your lanes, your customers and your pricing tells you something. A polished dataset tells you the sales engineer prepared well.
• “Configurable” doing a lot of work. Sometimes it means a setting. Sometimes it means not built yet, and you are being sold a roadmap at the price of a product. Ask which, and ask for the answer in writing.
• A fixed scope billed by the hour. Ask what happens when the estimate is wrong before you find out what happens when the estimate is wrong.
• Training as a single day at go-live, before anyone has real work in the system and real questions to ask. The second session, a month in, is the one that changes how people use it.
• No documented way out. If nobody can tell you how your data leaves, in what format and at what cost, ask again until someone does.

The tell that it is going sideways

Watch for spreadsheets reappearing beside the new system. It is the earliest honest signal you will get, and it is never laziness: the people doing the work have found a gap and routed around it. Ask them what the gap is within a week of noticing and they will describe it precisely. Wait a quarter and the spreadsheet is the system again, with a software bill attached.

Where navichain fits, and where it does not

None of the four patterns is something a vendor can sell you out of. We cannot clean your customer list, name your implementation owner, or choose your cutover date — and a supplier who claims otherwise is describing a service, not a product.

What we can do is remove the obstacles that sit on our side of the line. Every feature is on every plan, so there is no phase-two upgrade waiting to be approved halfway through the project. Billing is monthly with no lock-in, so a project running slowly is not a sunk cost anyone has to defend. And the free plan runs a single vehicle with the whole platform on it — enough to put one real lane through a real week, from booking to driver app to proof of delivery to invoice, before anybody signs anything.

If you are still at the choosing stage, our checklist for choosing a TMS is the set of questions we would ask in your position. The platform page and pricing are the rest of the answer.