February 2, 2006

SAP On-Demand — some key points

Here are some of my quick thoughts on SAP’s CRM On-Demand announcement:

1. One of the biggest barriers to SaaS (Software as a Service) growth in my opinion has been the question of data integration. Some of my data is at a service provider. Some is inhouse. How do I integrate it? How do I analyze it? SAP has provided a very good but still partial answer to those concerns by ensuring that its hosted and onsite versions of an app have the same APIs.

2. I say “partial” only because I’m having trouble envisioning many scenarios in which a customer would really want to have some of its data inhouse, some outsourced. It seems like the main benefit would almost always be as a transition strategy.

3. That said, sales automation can be one of the exceptions. The distributed computing problem for serving sales offices around the world may be much greater than that for the rest of one’s apps, so outsourcing that aspect of network management is not totally ridiculous.

4. Anyhow, this was obviously the way the software industry was headed. Indeed, it’s the way a lot of the industry did business until the first half of the 1980s. There were timeshared and onsite versions of the same products, in many cases. That strategy only died out completely when DBMS replaced file managers as the standard underpinnings to packaged apps, and that didn’t happen until the rise of relational DBMS in the second half of the 1980s.

5. I’m sure there will be issues with functionality, pricing, service responsiveness, and similar aspects of nimbleness. There’s no guarantee that SAP will establish and commit to a viable sales model for this service; it may always remain an afterthought. Even so, it could be enough to slow the penetration of Salesforce.com et al. into large enterprises.

6. To succeed in a big way, SAP has to establish a separate sales force, with a separate marketing budget. It also has to cross-commission between packaged product and SaaS sales. Those sound like slightly contradictory strategies, so there’s no assurance they’ll do both. Mark Benioff doesn’t have to panic quite yet.

7. The other non-trivial organizational problem SAP needs to solve is having one product development organization serve two sales force/marketing group masters. The closest thing they’ve done in the past to that is with NetWeaver, which is both a key technology for other SAP products and an important product in its own right. Their answer has been impressive fundamental engineering, but perhaps less “sizzle” on the surface of the product than it needs for maximum success. E.g., the BI products are significantly held back by their UIs, and serious attempts to fix that in my opinion just started last year — no offense intended to those hard-working people who might suspect I’m implicitly calling them “unserious” with that judgment.

Bottom line: Like most cases in which a huge and hugely successful company invades the core market of a rival, this effort will need to be judged several years and releases down the road. And the most important deciding factor will be whether or not there’s ongoing commitment to succeed in this new market, on a level comparable to the commitment with which the company pursues its much large core businesses. SAP has already shown such a commitment once this century, in NetWeaver. It’s too early to tell whether they’ll do so a second time, in SaaS.

Comments

Leave a Reply




Feed including blog about enterprise technology strategy and public policy Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.