My Cloud TMS Failed Because…

Are you a logistics/transportation leader who believes that Software as a Service business process automation tools (like cloud TMS, YMS, WMS, ERP, AP/AR and others) have a higher rate of failed implementations than the on-premise alternatives? If so, your fears surrounding SaaS are not based in reality. Rather, they’re likely the product of a challenge common among companies embarking on automation initiatives. Read on to learn why it isn’t SaaS to blame, but more likely, its you (or your fly-by-night cloud TMS provider).


The Wall Street Journal reports SaaS or “cloud” software is gaining significant adoption among smaller to mid-sized businesses. While larger organizations have been using cloud solutions to positive ends for some time, the smaller concerns are just now embracing the inherent benefits. Yet, as one particularly salient commenter pointed out, “For an established organization, if their information systems are a mess (which they very likely are), moving things to the Cloud just means you’re going to have a mess in two places.” He’s right, and his comment underscores one of the core challenges facing vendors of cloud TMS : addressing change management challenges for new customers during implementation.

Look, we understand. Nobody enjoys having their flaws called out. Yet, when a cloud TMS solution provider like transportation management system maker UltraShipTMS begins a new implementation, they perform a deep discovery process aimed at identifying the customer’s existing business processes in preparation for automation. When peeling back the curtains reveals poorly thought-through, broken, inefficient or otherwise-less-than-optimal processes, a delicate discussion must ensue. Explaining to a new customer that significant changes must be made to existing practices causes friction. It can even delay the speedy implementation schedule promised by the provider during the sales process. This is why unscrupulous providers frequently find it easier to avoid this difficult discussion (and the work required to mitigate the busted processes) altogether.

The resolution to this dysfunctional pattern requires honesty on the part of the two key stakeholders.  Cloud TMS Providers and Cloud TMS Customers Alike Must…


As such some SaaS solution providers opt instead to implement their software in spite of the known issues with the underlying processes, collect their fee and then quickly move on to the next client. It always comes as a surprise to the customer when their new solution (which was supposed to be the remedy to their business pains) fails to live up to its promise. The customer arrives at the logical (if erroneous) assumption that the SaaS model is to blame. After all, if they’d implemented an on-premise solution (and dedicated the significant internal resources to the task of managing it) they’d have far greater control of their own destiny. Instead, with the implementation team long gone, the customer is stuck with a solution doesn’t perform as promised.

The resolution to this dysfunctional pattern requires honesty on the part of the two key stakeholders.

SaaS solution providers must: be ethical and speak frankly with their customers when they uncover troubling business process issues during implementation – even if it means pushing out go-live dates and expending more time and resources to help the client truly prepare for automation.

SaaS TMS customers must: realize that no software – SaaS, on-premise or otherwise – will paper over whatever deficiencies exist within their operations. Then they must commit to doing some uncomfortable introspection during discovery and resolve to take whatever steps are required to prepare for implementation before implementation can proceed.

If all parties are doing the right thing, it is a lock that the SaaS solution deployed will not only be successful, but it will fully deliver on its promise of low-cost, low-maintenance and bottom line results.

Leave a Reply

Your email address will not be published. Required fields are marked *