The most important reason to go with a cloud solution is that is has a better total cost of ownership (TCO). These savings are driven by faster implementations, easier upgrades, better system longevity, and lower IT costs. Traditionally these advantages applied to public clouds, increasingly they now apply to private cloud solutions as well.

So what is the difference between a public and a private cloud? A public cloud solution is a piece of software code used by multiple customers. Google Maps would be an example.  It is the same code that many users from many companies are using. A private cloud solution is a solution that is hosted but one in which each customer has their own version of the software.

A public cloud system is a true commercial-off-the-shelf (COTS) solutions. Over the years many on premise solutions have claimed to be COTS. But historically, even companies that have implemented vanilla versions of the “off-the-shelf” supply chain software will talk about only having 10 or 12 or 15 customizations. With a public cloud none are necessary.

The transportation management system (TMS) market has had public cloud solutions offered by C.H. Robinson TMC, LeanLogistics, MercuryGate, and Transplace for several years. These were true COTS solutions.

In theory, an on premise solution could be put in with no customization. I’ve just never seen it. While customization is also possible with private cloud solutions, there is also a real trend toward foregoing any customizations with these solutions, particularly among small and medium sized (SMBs). Recently I’ve seen presentations by, and talked to, companies that have implemented private supply chain cloud solutions with NO customizations. This is a new development.

I am a very big believer in software that is truly off-the-shelf. Over the years I’ve talked to many logistics or IT executives who thought their operations were unique, and therefore they needed some degree of customization. Other companies felt that they should customize the software to fit the way they conducted business rather than changing processes to fit the configuration workflow. Both are mistakes.

When implementations have dragged on and on, were buggy, and delivered less than the promised results, customization was often a core contributor. Even companies that have had fairly successful implementations, when they finally get around to doing the first upgrade, admit that many of those customizations were a mistake. They subsequently spent time and money to eliminate customizations they initially thought their company just had to have.

In other cases, companies have chosen not to upgrade because of the long and costly upgrade process that would result from their customizations. The warehouse management system (WMS) market provides a perfect example of this. Historically, companies who had customized their WMS software would support the software for some years, even as newer versions of the software with better functionality was introduced. Eventually, the companies decided it was too painful to support the “legacy” software anymore. When they looked at the price of an upgrade, they discovered it would cost as much as a new software license and implementation. At this point, most companies ended up looking at WMS solutions from all the leading suppliers, and often selected a solution from a supplier they had not done business with before.

Because cloud upgrades are so much easier, it is likely companies will retain their existing cloud solutions for longer than they would with traditional solutions. That means users will also continue to have access to new features and functions.

With public cloud solutions, and some private cloud solutions as well, if companies want to continue to use the system, upgrades are mandatory. Users report that many security patches and bug fixes are invisible, a mini-upgrade occurs that users never notice. Larger upgrades may occur once or twice a year. This does require some planning and effort, but much less than would be the case for traditional on premise software. In short, a true COTs cloud solution forces companies to do what is inherently good for themselves.

The lack of customization does not mean that the cloud solution can’t be tailored to a particular company’s operations. They can. Modern enterprise software configuration engines are a marvel. It is even possible to have one instance of modern software manage operations at different facilities, divisions, and regions, with quite different processes.

There are also savings from a cloud solution in the IT department. Companies don’t have to spend money on new servers, or spend money on IT professionals to manage them.

Customization has long been the bane of the enterprise software industry. Fortunately, supply chain and IT professionals increasingly understand that customization should be avoided at all costs.

I recently talked to Fred Erb, the Director of Transportation at SPSCI. SPSCI, a mid-sized company, is a distributor and value added processor of steel products. Their company recently went through an Oracle Transportation Management Cloud implementation. This is a private cloud solution. In many ways, that conversation perfectly encapsulated many of the points I’ve made in this article.

SPSCI began their journey to a transportation management system (TMS) implementation in 2014. One of their divisions had a dedicated fleet and was performing satisfactorily, but the other divisions were struggling with managing their carrier networks. There was a driver shortage and flatbed capacity was tight, especially during produce season when they competed with agribusiness for trucks. Mr. Erb was tasked by the President on how to better manage transportation and make deliveries in a timely manner.

SPSCI looked at several software vendors. The company examined the possibility of a managed transportation service arrangement in which their dedicated carrier would manage all their transportation planning and execution processes. This Third Party Logistics firm used an on premise version of Oracle Transportation Management (OTM). SPSCI particularly liked the OTM user interface.

“Ultimately it came down to whether transportation should be a core competence,” Mr. Erb said. “As a distributor, we decided it should be.”

Once they decided to implement Oracle Transportation Management, they needed to decide how to implement it. Would they go cloud or on premise?  As a midsized company, their IT resources are tight. The IT group encouraged them to first look for the best solution,

but was also completely supportive of a cloud based service if it fully met the business’s needs. They decided they wanted to get a TMS up and running without burdening their IT group.

“Cloud was also more cost effective,” Mr. Erb said.

There was absolutely no customization, “that is great.” From a resource perspective, Mr. Erb, an IT analyst, and a transportation analyst were the primary internal resources that worked on this project.

Despite the fact that the different divisions were using the same instance of the software, the software was configured to meet each division’s distinctive needs. According to Mr. Erb, “One division groups orders together so we configured it to bring in the grouping information so the transportation person could create the shipments off of the order groupings. Another division runs more like a manufacturing facility and needed the ability to create shipments off of orders that were not produced at the time they needed to arrange transportation, so we gave them the ability to assign several orders to a shipment, exceeding shipping weights, but then updating the shipments when we produced actuals in our ERP system. OTM was very flexible in adapting to our business requirements.”

Also, “having one instance (of the software) is nice.” The company’s ERP system is utilized differently across each division, so information is re-ported differently. By having one platform for TMS, one division’s data is the same as another division’s data. “From a reporting perspective,” Mr. Erb reports, “that is a real advantage.”

“If cloud was not an option, I’m not sure this project would have happened.” It would have been difficult to free up the necessary internal re-sources, and the business case would have been a much “tougher sale.” Oracle’s cloud solution was “perfect timing.”