Transportation management systems (TMSs) are linchpins of the freight forwarding business. They manage the transports and are thus connected to almost every operational process. The longer they are in use, the greater their potential for problems.
The big question: can this proven software still adequately support new customer requirements? After all, the logistics market is changing at a breakneck pace. Margins have been low for a long time; value-added services are increasingly in demand. That means a TMS should do the following:
Software that fails to do these things will quickly reach the limits of its abilities. Companies then face with the choice of doing more and more tasks manually (which reduces margins) or modernising their IT.
The TMS is the beating heart of every freight forwarding company – it sets the pace. No wonder many logistics professionals are reluctant to replace TMSs. You can prepare for a switchover but have to make a clean break. It makes no economic sense to use the old and new systems side by side. This is why almost all TMSs are swapped out on a fixed date – which management and staff view as either the start of the future or open heart surgery. Sometimes as both. Risk management involves carefully weighing the consequences of continuing to use the existing system or switching to a new solution. What opportunities should be seized? And what is best way of going about it?
You don't have to discard a proven TMS just because you've had it for a certain number of years. Many software vendors have opened their sophisticated solutions to new interfaces. These connections let systems leverage many modern technologies such as event sourcing platforms, microservices, and function as a service (FaaS). They provide the freedom to gradually modernise individual processes. Best-of-breed solutions should be used in each application area. Organisations already using a TMS should carefully assess whether to take the risk of changing systems. After all, new is not necessarily better. If another TMS covers the required application areas by default, it often imposes restrictions on more advanced features. In some cases, the new TMS may even use additional services for this purpose.
One clear case for system change is a company whose TMS was implemented by an IT manager who has since retired. Almost all of these IT managers knew the application in exquisite detail, configured many of the processes themselves and clearly understood the IT environment in its entirety. If you want to make changes in this situation, you first have to understand the underlying process structure. This is often a hopeless endeavour without comprehensive written documentation. Continuity then poses a much higher operating risk. After all, who can accurately predict how long they can continue to compete with the same business model and service offering?
Freight forwarders facing the prospect of a system change have to do their homework first. They should identify the processes they need to automate so that their margins will not be entirely consumed by manual effort. They need to clarify whether they are even in a position to implement new processes and how involved that will be. Not to mention the all-important question of whether their TMS can be extended later on. If the answers to all these questions are positive, they often have to drill down to the details to decide whether to change systems entirely or gradually modernise what they have.
Can you use your IT system to tap additional potential and meet new customer requirements?
Add a comment