Enterprise Thinking - Home
Implementing Enterprise SaaS: If it’s Easy, it’s Because You’re Not Trying
MAR 04, 2015 11:01 AM
A+ A A-
Back in the early stages of the SaaS market, so many months ago, it seemed obvious that the SaaS market would one day undergo a major transformation as the easy wins based on taking on-premise capabilities and flipping them to the cloud – pretty much the business model of Salesforce.com in the early days– gave way to an era of greater complexity and value. At one time it was the value-added cloud capabilities of business networks and the like that were supposed to lead the SaaS world to the promised land by using the cloud to conduct business in ways that simply hadn’t  been possible in the on-premise world. 
Wrong. So far, anyway. 
But while we wait for the business network opportunity to reveal itself at scale – a bet that SAP in particular has made in the last few years with acquisitions like Ariba, Concur, SuccessFactors, hybris, Fieldglass, and other cloud properties – a new SaaS complexity  is emerging, and its advent has begun to reconfigure how SaaS is implemented in the enterprise. And with that reconfiguration has come the demise of one of the most sacred tenets of the SaaS world: simplicity. 
What has become obvious is that enterprise-class SaaS as a strategic implementation option is more and more dependent on the ability of the vendor and implementer to integrate SaaS services with the on-premise world. That integration isn’t just a nice-to-have afterthought, it’s becoming the core of the business case for implementing enterprise SaaS, and that business case is making SaaS a much more complex undertaking than it was in the glory days at the turn of the century. 
The easiest way to tell that the game is afoot is to track how the global SI crowd, the ones that made cost and complexity the watchwords of on-premise implementations, are now showing up at the SaaS feeding trough, talking about business transformation, value-added services, and pretty much anything else that will replace the easy body-shop dollars that SaaS is definitively killing off. 
Not that this is necessarily a bad sign – there are many competent practitioners of the implementation arts who possess the mental fortitude to do well by the new SaaS implementation imperative. But for the most part the global SI crowd comes to SaaS table with their on-premise methodologies – pitched like the devil in order to get the business, and then honored mostly in the breach when it comes to the actual project – and are finding that their methodologies more of an anchor than a sail. 
The smarter SaaS vendor execs are sanguine about how well these on-prem SIs will do: I was told in no uncertain terms at a recent SuccessFactors analyst event that savvy customers are turning more and more to the boutique SIs, who, as one exec told me, “are unencumbered by their on-premise methodologies.” (For those who haven’t tracked the relationship between methodologies and long-term project value, on-prem methodologies are like teaching to the test – you might actually end up with a smart kid when you’re done, but your odds may be even better that you’ll end up with high-scoring fool.)
The other way you can tell that complexity and SaaS are now synonymous is the growing quantity of deals gone bad. SuccessFactors has spent a tidy seven-figure sum of late remediating troubled implementations, and to be fair, the offending SIs have run the gamut from boutiques to the global SIs. 
SuccessFactors is hardly alone in this regard, as evidenced by the increasingly universal requirement for vendor  audits of SaaS implementations done by third parties, even the biggest and baddest of the global SIs. While SuccessFactors is relatively new to this, Workday has required these audits for some time. 
The mandatory vendor audit is a significant departure from the status quo ante of the on-premise world, where vendors, like a couple of shocked parents at their first hearing in front a juvenile court judge, would one day rudely awaken in mid-project to find out that they are the first to be blamed and the last to know. The revelation that what should have been a poster child implementation had become a den of iniquity that had been hiding in plain sight all this time has strained the mental fortitude of enterprise software vendors since the dawn of time.
The fact that it took the combined incompetence of the SI, the customer, and, often the overselling vendor sales rep, to create another major or minor catastrophe offers scant comfort. 
Been there, lived with that. What’s different about on-premise vs cloud catastrophes is that, in the former, the vendor’s profit margin on the license sale remains largely intact. There may be a hit on the services side – post-hoc remediation services are expensive – and the brand takes a beating, and the customer is pissed, but that sacred license margin is still there to boast about when the quarter is done. 
Bad implementations in the cloud have a very different impact on the vendor’s margins. A bad implementation, no matter who is to blame, still has to be run in the vendor’s data center, and supported by the vendor’s support staff. Meeting the data center’s service level agreements for a poorly implemented SaaS app means more effort and support costs. These brittle implementations are more likely to break at upgrade time, and in general letting them into the data center threatens to kill off the recurring revenue margin that the whole SaaS industry is built on. 
This problem becomes even more acute when the cloud implementation has significant integrations, which as I stated above, is more and more the case. Hence SaaS vendors like SuccessFactors and Workday are not only requiring their own teams audit the implementation, but they’re also requiring the customer to pay for the audit. 
This is definitely a move in the right direction – customers have a degree of culpability and responsibility that has been traditionally papered over in the rush to judge the vendor and let the SI get off scot-free (unless the failure ends up in court, and then the lawyers labor hard to ensure that the allegations of blame are fairly and equitably distributed among all three parties, and the devil take the hindmost.) 
What’s the final evidence of complexity from the world of SaaS implementations? Salesforce.com’s rather convoluted usage limits for API calls. What’s easy to understand is that high-end customers running Enterprise Edition or Professional Edition (“with API access enabled”), have a limit of 1 million API calls in a 24-hour period. That’s a boatload of integration and complexity. 
What’s also easy to understand is that Salesforce.com is working hard to make sure customers don’t use more API calls than they pay for, as in this little note in the fine print from Salesforce.com’s API usage limit guide: When an organization exceeds a limit, all users in the organization may be temporarily blocked from making additional calls. Calls will be blocked until usage for the preceding 24 hours drops below the limit. 
Take that, API user deadbeats. 
What this new cloud complexity means is that cost savings in SaaS, like the famous peace dividend that was promised following the end of the cold war, may turn out to be more mythological than real. The requirement for integration and the maintenance of those integrations will very likely keep services revenues for SaaS chugging away for quite some time. 
And don’t think that going all SaaS will solve the problem – silos of SaaS functionality can be even more complex to integrate, and keep integrated, than an on-prem/SaaS hybrid environment. SaaS vendors treat frequent upgrades as a virtue (which always sounds so good on paper, until something changes that you didn’t want changed). So imagine, like one relatively small company I know, having a cloud backoffice consisting of 80 cloud apps. Each one upgrades on its own schedule, with little or no awareness of what the other 79 are up to. The company in question was actually considering getting a DNA graft and moving a ton of functionality to a single on-premise ERP system. That is until a severed horse’s head appeared under the sheets in the CIO’s bed one morning.
(Metaphorically speaking, of course.) 
It’s clear now that we’re waking up from a cloud cost-savings binge that was a little too good to be true. True, lots of the grunt work that went into implementations is gone, and good riddance too. But expecting that the end of the low-hanging fruit of the implementation business would mean that less money would be spent on services overall is a bit of a pipedream. Implementing enterprise SaaS is hard – even if you’re doing payroll in the cloud, by the time you “configure” your SaaS payroll to take into account the many countries and currencies you do business in, the different pay structures and pay grades in your company, union work rules, the deductions, and on and on, you’re not really configuring, you’re implementing. 
SAP knows, they did this themselves, using SuccessFactors to replace a sprawling, global HR mess with 100s of redundant processes and disparate, unintegrated systems spread all over the world with a single, unified SaaS system. You don’t just configure a system that size and then flip a switch. 
And if you want to tie that into your finance system, your HR and talent management system, throw in some succession planning, add your contingent labor to the equation, tie talent management into maintenance and service scheduling  – well, you just did a big fat, complex implementation. With all the attendant costs and risk. 
So if you’re doing enterprise SaaS because you want your IT life to be more simple, think again. The game is rigged against simplicity, and always has been, for the simple reason that business is complex, and always has been. To paraphrase President Eisenhower’s famous admonition to the nation as he left Washington politics for good: when  it comes to enterprise SaaS, beware the implementation complexity complex. 
For good measure, Ike also said “If you want a friend in Washington, get a dog.” I’ll work that aphorism into my next post. Promise. 
[%= name %]
[%= createDate %]
[%= comment %]
Share this:
Please login to enter a comment: