By Nikki Baird, Brian Kilcourse, Paula Rosenblum, and Steve Rowen
5/13/2008
RSR was seriously challenged to write this article, because we couldn’t figure out how to do it without seeming biased. We’ve done business with many of the new generation of retail application software roll-ups, and in the interest of full disclosure, one is SAP. We prefer not to write about vendors so that we can maintain our clients’ trust – but we do write about big vendors and their direction, because they simply have so much impact they can’t be ignored.
With that as backdrop, the entire team at RSR is very positive about SAP in retail. Yes, it’s true we’ve just come back from Sapphire and seen things in the best possible light, but we have other reasons to feel this way. We’ll tell you exactly why, but you’ll have to indulge us for just a minute.
Let’s spend that minute talking about switching costs. Switching costs are the costs a customer incurs to switch suppliers, according to the pithy definition supplied by Wikipedia. These can be all kinds of costs – hard, soft, emotional, you name it. Retailers incur the highest switching costs changing merchandising and Point of Sale applications. If you want a retailer to change out those two applications, the apps they currently have had better be so old, so brittle or so unscalable that the retailer almost has no choice but to abandon them.
There are two ways to overcome switching costs. Either the cost of maintaining the existing application becomes so high that the switching costs become irrelevant, or the competitor can try to reduce the switching costs or enhance the value it provides to the point that the switching costs can become justified. Both forces are at play today in the competitive relationship between SAP and its competitors.
SAP has clearly committed to a strategy of Services Oriented Architecture. It committed so strongly to this goal that it actually throttled back on heavily promoting some acquisitions to more rapidly integrate those acquisitions with the SOA strategy. While the work isn’t done, the fruits of that investment are becoming very clear: instead of “upgrades,” the vendor now has “enhancement packs” that can be implemented with little to no impact on the underlying application. Custom-developed projects done for one customer can be provided to other customers – because it’s all SOA-based. The architecture is clean, and it creates a huge amount of flexibility both in the value provided to the customer and in the speed it takes to roll out new features and functions. It also breaks apart what was once a monolithic application and makes it something that you can implement piece by piece – though there are reasons not to do that, and we’ll get back to those in just a minute.
Companies that have built their application portfolios through an acquisition strategy start from a scarier place architecturally. Customers using that acquired software are often left with an upgrade path that sounds a lot more like “reimplementation” than “migration.”
Racing to keep up with functionality, which adds to product complexity can prevent getting the architectural house in order. This is true even if that functionality is world class, best of breed almost the whole way. In fact, our soon-to-be-published benchmark study, Business Application Delivery in Retail tells this same story. Retailers have tangled infrastructures because they needed functionality fast and didn’t have the time to make it tidy.
Vendors who have built their portfolios the same way have the same problem, and that creates the switching cost dilemma their customers now face. For example, Oracle’s customers owning Retek v10 or lower have an “upgrade path” that is going to be very expensive for them – pretty much a rip and replace. To be fair, this is in large part driven by the extensive customization they requested in the first place.
The world doesn’t stand still and switching costs aren’t as high as they used to be. First, the gap between what SAP offers and “world class” when it comes to merchandising is getting narrower every day. And customers who do decide to commit despite the gap find that SAP’s clean architecture makes it easy for them to add what is missing with minimal fuss. SAP’s commitment to infrastructure first enables its current flexibility.
So if you’re a retailer, and you’re looking at migration costs that are about as much as a brand new implementation, why not throw that open and evaluate your options? Your choices are interesting. You could buy pure functionality again, or you could invest it in functionality that is almost there but will run your business on an architecture that promises more flexibility.
That said, we have one caveat about the SAP way. Although you can implement SAP piece-by-piece these days, you have to recognize it’s a commitment to the SAP strategy. The retailers with the best success stories – Wawa comes to mind – are the ones that threw away their attachment to “the way we’ve always done it” and committed themselves to a business process and cultural transformation that rode right alongside the technology transformation.
Getting retailers to understand that it’s not the minutiae of a business process that drives differentiation, but the strategy and how you execute it, may be SAP’s last big challenge in the North American market to overcome on its way to ascendance in retail IT.
| 
