SAP SRM, another brick from the wall

In the time it has taken SAP to fail to deliver its much-needed release, a rival SaaS product has gone through two release cycles. Vendors like SAP are boxed into a long-term strategy that hands all the initiative to a new generation of web-native competitors.
Written by Phil Wainewright, Contributor

The contrast could not be more stark between yesterday's launch of Coupa's Amazon-hosted SaaS e-procurement system and SAP's decision on Friday to cancel the upcoming release of its spend management product. Another beneficiary of SAP's misfortune is SaaS vendor Ketera, which earlier this month added a new supplier management application to its spend management suite.

Ketera's recent product launch history makes a telling comparison to SAP's woes with the canceled SRM 6.0. In the time it has taken SAP to fail to deliver its much-needed release, Ketera's rival product has gone through two release cycles, gaining a completely new user interface and extending it into a major new area of functionality. I wrote about Ketera's consumerist makeover to its user interface last year — a release that brought Amazon.com-like ease of use to the process of raising a purchase order. This is the exact opposite of what SAP's customers are now stuck with for two more years, as spend management expert Jason Busch explains on his blog:

"SRM 6.0 was to address many of the weaknesses of 5.0 which included a kludgy UI, a challenging interface that made it hard to search and find POs, a cumbersome process to define filters, and workflow which forced users to go through multiple clicks to launch actions (I once heard it referred to as the 'anti'-one-click-Amazon)."

Busch provides another unflattering comparison in his coverage of Coupa's launch:

"... comparing SAP SRM 5.0 to Coupa is like doing a side-by-side with a green screen mainframe application next to a client/server one."

Busch has speculated that the reason for SAP's ignominious withdrawal of its release is overengineering. The curse of established enterprise software vendors, of course, is that the more sophisticated their solutions become, the more complex they have to make them if they are to persuade customers to upgrade. SAP will argue (and probably believes, too) that upstart SaaS vendors like Coupa and Ketera won't make serious headway into their customer base because their products lack all the enterprise-class credentials that its own software delivers. It will worry far more about having opened up a weak flank where its arch-rival Oracle will be able to attack it.

In the case of Coupa, SAP might well point to its reliance on the Amazon EC2 platform as a weakness. I cited the lack of an SLA over a year ago as an impediment to Amazon.com's business market aspirations. Amazon Web Services has now published a service level agreement (SLA), which perhaps will allay concerns expressed after some users experienced outages last month (hat-tip for that nugget to Alessandro Perilli's virtualisation.info blog). The new SLA guarantees just 99.9% uptime, which Larry Dignan suggests is hardly enterprise-class.

But on the other hand, how many enterprise data centers in SAP's customer base manage to stay up for all but three quarters of an hour each month? I suspect most are achieving much lower levels of availability. Once you take into account planned downtime, backup windows and the like, the average is probably closer to 99% (around seven hours' downtime a month) for all but the largest enterprises. For those who insist on better than Amazon's 99.9% — and willing to pay a premium for it — I'm sure it won't be long before Amazon starts offering higher SLAs at a price.

In my view, all of this provides a vivid illustration of Clayton Christensen's Innovator's Dilemma at work. SAP is struggling to sustain innovation at a fast enough rate to compete with a new generation of vendors who are using the disruptive innovation of cloud-based SaaS technologies to deliver a new generation of business automation software. Incumbent vendors like SAP will always try and argue that the disruptive innovations aren't robust or sophisticated enough, but that very argument boxes them into a corner where they have no choice but to deliver ever more complex solutions that, as we reach the end game, are destined to simply collapse under their own weight.

I think this tension gives us an answer to a question Om Malik posed during the keynote discussion that opened the Future of Web Apps show in London earlier this month: "Where are the enterprise widgets?" Dion Hinchcliffe last week posted another of his tremendous essays with some answers to a related question, listing The 10 top challenges facing enterprise mashups. You can sum up Dion's list of challenges in a single overriding statement: they're not mature enough to meet enterprise expectations.

This of course is a self-fulfilling statement. Until enterprises start adopting these technologies, they'll never have a chance of becoming sufficiently mature. No technology — least of all the truly disruptive ones — emerges fully formed. But are the established vendors seizing the opportunity to get out in the vanguard of harnessing the emerging potential? Far from it. They themselves are challenge #9 on Dion's list: "commercial software vendors have been slow to provide explicit support for an enterprise mashup friendly environment." Like SAP with its SRM 6.0 product, they're trapped in a mentality where they can't adopt emerging technologies because they aren't mature enough yet. So they leave it to others to innovate with those technologies. As a short-term strategy it looks eminently defensible. But as a long-term strategy it's outright capitulation, handing control of fundamental innovative technologies to a new generation of competitors.

Editorial standards