Guest Blogger, Michael Sadowski writes:
Adrian Gonzalez of Talking Logistics recently asked the question: Why are companies replacing their legacy TMS? We’ve definitely seen increasing momentum in the SaaS TMS market in the past few months, with shippers who have legacy TMS systems in place actively working to replace these systems with SaaS solutions. So, OK Adrian, I’m going to take a swing that this question and share some reasons why I think this much-anticipated shift is really starting to accelerate.
1) Money for Nothing – I was a CIO for several years, and there’s nothing CIOs hate more than maintenance payments to legacy software vendors. In a sense, this is money for nothing. Sure, CIOs know they need their vendor to keep paying some staff to keep the solution alive. But often times companies with a legacy TMS don’t install the new versions as they come out. It’s too expensive to bring back the consultants and migrate to the new version, test it, retrain users, etc. So you have all these companies paying 16-20% of their original license fees for maintenance every year, arguably for nothing. Let’s say you spent $500K to license the original solution. Hmmm…at 20% software maintenance, that’s $100K annually you could put towards a fresh, up-to-date SaaS solution; and we haven’t even considered the cost of maintaining servers, storage, and disaster recovery for the old TMS! By contrast, all these things are included in the monthly subscription with a SaaS TMS provider.
2) Generational Change – Peoples’ expectations have changed. The current and emerging generation of logistics managers and executives expect their user experience to be like Amazon, not some old school, client server application, or a green screen AS/400 application (yes, there are still a few of these out there). If your new generation staff encounters your old generation technology, expect the leaders among them to agitate for change. If change is not forthcoming they may depart in favor of some more forward-thinking organizations.
3) Consolidating Legacy TMS Market – In many cases, legacy TMS companies have been acquired. The new owners may have vague product plans which may (or likely may not) involve the legacy system you’ve invested in. The software developers who built those products are probably gone, and the new owner might not be investing to keep the product vital, and moving forward. If that’s the case, why not consider SaaS vendors who field a modern product that’s continually moving forward?
4) Brittleness of Old Solutions – Legacy TMS solutions were often implemented by consultants and company staff who may have moved on. Unfortunately, these solutions don’t evolve with changing supply chains. You acquired a new division? How are you going to get them running on your legacy TMS? And meanwhile, top management is eyeing freight savings as one of the synergies of the acquisition.
You want to make major changes to your carrier base in order to realize those savings? Hmmm. The guy who knew how to set that up in the TMS quit.
You have some new ideas for optimization? Hmmm, that sounds like a big consulting project with your legacy TMS vendor or a consultant.
Supply chains change. But has your legacy TMS evolved? Chances are it’s frozen in time, circa the year it was first implemented.
5) Getting Tired of Waiting for Your ERP Vendor’s Solution – The major ERP vendors were slow to create (or acquire) strong TMS solutions. But worse, deploying an ERP solution is a huge project and is often not the priority for your company’s ERP team. So many companies have still not deployed their ERP vendor’s TMS. With the availability of good SaaS TMS options, and the relative speed of implementing these, we’re seeing more logistics and supply-chain teams take charge of the situation and implement a SaaS TMS, without waiting for their ERP vendors’ solutions.
Michael Sadowski is a consultant on logistics and supply-chain IT issues to 3PLs, shippers, and software companies. He’s also CEO of Cayugasoft Technologies (www.cayugasoft.com), a software development firm. Previously he was a CIO in the 3PL industry (where he led numerous TMS software development projects), and an executive in a TMS company.