Thinking of adopting a cloud-based solution? That might be a very good idea but it also means making a significant commitment to a web-hosted solution provider, and a scenario where switching away will get more costly with every passing year. In the second of a two-part interview, Wayne Kakuda, CIO of logistics consultancy, TPS Logistics, explains how this dynamic can work, and why CIOs should enter into such relationships carefully.
The Enterprisers Project (TEP): These days, moving to new technologies often means moving to the cloud, possibly replacing on-premises technology with a Software-as-a-Service version of the new technology. What particular challenges does this pose? And what are some ways to deal with them?
Kakuda: The advent of the cloud is excellent. It allows organizations to buy a set of processors, storage units or RAM and start setting up as many servers as they want. In the old days when you had to buy a physical server that came in a box and was stored on a rack, it limited how you were able to string them together. So having a cloud, whether public or private, has a lot of advantages.
As you move to off-premise solutions, there are two notions. You can have private clouds where you get the benefit of the cloud but it's your environment, or you can have more of a SaaS model with a public cloud where you're essentially buying a subscription. I try to think about what buying into that subscription as part of a SaaS model means. From day one, whether you realize it or not, you are making a commitment to that SaaS provider, and that's a relationship that shouldn't be taken lightly. As you engage and embark on this relationship, putting more data into the software SaaS solution, your switching costs increase. And that cost increases dramatically as the years go by. As the switching costs continue to rise, the person providing the SaaS solution begins to have more pricing power over you. That trade-off between switching costs and pricing power is something that CIOs need to consider and weigh heavily on the front end to determine if a SaaS model is the right solution for their needs.
This is something that we've experienced first-hand at TPS Logistics. We've seen other products that may have features we like or are appealing for the work we do, but having that legacy already built up within another solution makes us think twice about switching. If we were to leave our current SaaS provider, we would either need to move all of our information over or just say that we don't care about it. Obviously, we do care about that information, and the switching costs to move all of that data have impeded our decisions on using other products. Those costs are real, and knowing where that switching cost is on your radar screen is important from day one — so it's imperative to make that decision with eyes wide open.
TEP: Another decision that can create ongoing cost is customization. There are often efficiencies to be gained by moving to a standardized version of a product, as opposed to customizing it to fit your work processes. How do you determine when customization is warranted and when a standard version should be used?
Kakuda: This goes back to the value proposition generated by the technology. Using all standardized products in your core areas will at best make you as good as the next person. It won't provide you with the economic value your organization is looking for regarding getting above average shareholder returns in your business operations.
It sounds easier to do than it is, but CIOs need to understand the value creation of their company and the role technology plays in enhancing it. Then you can leverage highly customized solutions in situations that have high-value creation and deploy standardized products where they have little to no impact.
TEP: Any advice you'd offer CIOs about minimizing the impact of introducing new systems?
Kakuda: It comes down to thinking clearly about what benefit you're trying to drive for your organization. We've implemented new technologies at TPS Logistics without changing the user interface at all, but the changes we did make to the business logic layer ultimately enriched the user experience without users even knowing a change had occurred.
I like to tell people to be surgical about how you implement a technology. Not every update or new solution needs to be revolutionary. And if it is, you had better be confident that the revolution is worth the disruption.
Be sure to read Part One: Guidance for improving user adoption of new technologies.
