Doug Hadden, VP Products
Executives at Salesforce.com have been claiming that they will grow their firm to be larger than SAP. They’re “taking on” SAP. This makes perfect sense in the “dog-eats-dog” ERP world. (More specifically, the “ERP-eats-ERP world.) It’s true that legacy enterprise software firms a playing “Whac-A-Mole” with innovative growing companies through persistent acquisitions. The HP strategy to split the company shows the perils of scaling companies to dinosaur size.
What’s the rationale to be larger than SAP? Does Salesforce want SAP’s scale problems? Why get into a game following SAP’s rules?
Sabotaging Scale through Expansion
This might be counter-intuitive to some: the more lines of business & the more vertical markets with more deployment options combined with more acquisitions SABOTAGES economies of scale. There’s a notion that Salesforce can learn from the mistakes of the past to “do it better.” But, Salesforce isn’t doing it much differently than SAP:
- SAP held off on large acquisitions until recently, minimizing integration & multiple platform support until quite recently. Salesforce has been on a buying streak
- SAP expanded in multiple vertical markets (26 or so) resulting in difficulties meeting out-of-the-box functionality in many of those markets when the original code was designed for different industries – yet Salesforce sees this as good approach – Salesforce has contained the pig of code customization so far, but can this be maintained should the company leap into multiple verticals
- SAP has so many UI platforms on the web (the old version, ByDesign, SAPGUI5, Fiori, Lumira, Personas) to confuse users – while Salesforce is throwing functionality like content management and collaboration into forms-based web client (that starting to look like a ransom note) with a completely different Salesforce1 mobile client (don’t get me wrong, I like the mobile client especially for Chatter)
- Salesforce has opened the platform for 3rd parties, something that took some time with SAP – this sounds like a great way to scale, by using partners, but it also leaves lots of orphan modules and code floating around that can break with an upgrade
- SAP has implemented more clever ways for customer lock-in – not a good thing for customers, but a way to keep customers paying for maintenance by providing adequate support
Here’s the thing about scale in software development: a single modern platform without legacy code, built on proven open-source middleware requires orders of magnitude fewer product managers and developers to deliver solutions to customers than the alternative of multiple legacy platforms. This is an advantage that we’ve witnessed since making what seemed like a risk decision in late 2006 to redevelop our software as pure web.
The Alternative: Better
This obsession with size seems to be testosterone-driven. You can just imagine the boardroom discussions in San Francisco about “playing hardball”, putting on a “full court press”, and other sports analogies about competition.
Salesforce is plenty large enough today to give customers confidence. So what if Salesforce is not large enough to sponsor the Formula 1, Wimbledon or America’s Cup champion?
There’s a reason why we run our support, business development, marketing and sales organizations on Salesforce rather than SAP, Oracle or Microsoft. It’s better for us.
Salesforce should obsess about better: better value, lower costs, increased productivity, reduced environmental footprint. They do some of this today by helping non-profits. Hiring “old school” ERP types is not going to help Salesforce eek out new “success factors.” Salesforce needs to out-innovate SAP. That means dedicating engineers to develop the new-new, not focused on integrating the old-old and maintaining legacy code bases. And, the not lose sight of the social mandate