Software-as-a-service (SaaS) vendors love to brag about their technology. But let's talk for a minute about something they're usually less eager to discuss: their financial viability.
I hear rumblings occasionally about a shakeout in the SaaS market. As a rule, this question boils down to four big issues:
Customer acquisition costs. SaaS vendors have to spend a lot of money to acquire new customers. Last year, according to industry-watcher Bob Warfield, Salesforce.com Inc. spent 54 cents on sales and marketing for each dollar of revenue it brought in. A competitor, SuccessFactors, spent 56 cents for each dollar of revenue. It's a fair and necessary investment -- both companies enjoy impressive growth rates -- but it's one that not every SaaS vendor can sustain over time.
Venture funding. Most SaaS startups rely on venture capital firms for their funding. Sometimes that works out, other times it doesn't. Either way, doing business with a venture-funded SaaS vendor involves a very different level of risk than dealing with a publicly funded company (like SalesForce) or a traditional enterprise software vendor with a SaaS offering.
Short-term versus long-term thinking. If a SaaS vendor is under intense pressure to boost its short-term revenue, a lot of unpleasant things can happen. Consider the consequences, for example, if a vendor skimps on its disaster recovery infrastructure in order to shore up a sagging bottom line.
Competitive pressure. Some SaaS market categories just look too crowded for their own good. In the BI space, for example, you've got at least a half dozen SaaS vendors fighting to differentiate themselves -- and at least two others, Blink Logic and LucidEra, dropped off the map last year.
For enterprises considering SaaS solutions, all of this puts a very different spin on the process of picking a vendor. To put it bluntly, this is a market where focusing on the best technology is a losing proposition. Instead, focus first on the vendor's long-term viability, and then pay attention to its technical merits.
This doesn't mean sticking with only profitable SaaS vendors. That's a too-cautious approach in a market where the most successful companies -- as I pointed out above -- are spending a ton on customer acquisition in return for outstanding growth rates. But you do need to ask whether a vendor's "growth strategy" is really a sustainable strategy or just a gussied-up shell game.
Some SaaS vendors simply won't pass the smell test when you open the books on their funding sources, balance sheets, and growth. Others won't let you get close enough to smell anything. Either way, there are quite a few SaaS startups that won't be around for the long haul.
And your enterprise definitely doesn't want to be anywhere near the losers when their day of reckoning arrives.
Related news: Verizon is the latest 300-pound gorilla to get into the enterprise cloud storage market. I don't know exactly how many vendors are at this party now, but it's a crowd.
This is turning into a commodity service even before the demand really starts to ramp up. I'm not sure how the smaller vendors are going to compete -- especially the ones building their whole business around cloud storage, and ESPECIALLY any that are still relying on VC funding.
I think it's up to the customer. I suppose the SaaS vendor could be more up front about the planning and training requirements for a successful deployment (as opposed to a fast, cheap one), but in the end it's up to the customer to understand what is required for a successful roll out of any enterprise system and to not cut corners just because the distribution model makes it possible to do so.
Ah, then what I should be stressing is that it's nearly impossible to over-stress how pervasive is the problem of enterprises expecting software all by itself to solve process problems, training problems, and general organizational messes. When you hand an organization subject to that folly a tool that purports to be full of instant answers to the hard questions, it's a good bet they'll go for it. SaaS can actually make the problem worse by taking the people who are supposed to ask the critical questions about technology out of the picture (IT, the project office, release management, etc.)
I guess I wasn't clear. I was citing one of the library goals SuccessFactors provides in the event that one's organization doesn't provide sufficient guidance to let an employee or manager define personal goals.
I had a buddy look this up. The actual suggestion from the SuccessFactors application is "Increase code production rate to (fill in the blank) lines of code per (unit of time) by (date)". [Notice that they're not even hip enough to use the almost-but-not-quite-as-problematic alternative of counting function points.]
I should add that not all the library goals are quite so nonsensical. Still, they share the common problems of any one-size-fits-all template. Moreover, the overall effect of SF's metrics-based approach appears to limit performance evaluations to those things that are easy to measure, an approach that only succeeds if you care more about the process than the result.
It was a specialty CRM... with the big players and generalist CRM services available, they had to spend a ton on customer acquisition. I'm not sure how they are doing today but I know that the # of employees in the organizaiton nearly cut themselves in half at one point. Their differentiation and selling point was their SaaS only model and the big problem was that the rest of the market caught up with them.
Fascinating. Although I would argue that your example isn't the best one in the world: Any organization, at any level, that treats lines of code written as a job performance metric is already completely screwed. It doesn't matter if they're using SaaS, on-premise software, or two paper cups and a bit of string, they're still suffering from a terminal case of stupidity.
I should explain that. In another life, I had a brief tip-of-the-garbage heap encounter with the SuccessFactors performance management product. Obviously, it didn't impress me, although I suppose that it is possible that, given a perfectly-planned and executed deployment, it might be of some value. (That's about as enthusiastic as I could ever get an HR function, so you can consider that a big concession). On the other hand, the structure of the SF product very much enables and, in fact, facilitates poorly planned and executed deployments, so I'll argue that my observations are valid..
The problem starts with a weakness common to many in SaaS offerings--by eliminating the need for a capital investment, or for infrastructure changes, or for extensive IT support, SaaS applications can enable business groups to bypass many of the control steps that have evolved around IT projects: requirements analysis, solution analysis, release management, provision of funds and time for customization and training, etc. Instead, HR can respond to a mandate to improve the organization's performance management by signing a contract with SuccessFactors and roll out the new system almost overnight. With no training budget, executives, managers and employees are all on their own to figure out how to use the system effectively.
The training issue would normally cause obvious bleeding, but SuccessFactors hides it by providing tools like a goal that generates performance goals based on an individual's job function. These are the software equivalent of those old "101 Business Letter" books--at best, generic to the point of being meaningless, and to anyone familiar with the job function, they're good for a laugh but that's about all. Still, they sound good (and measurable) to someone who is not familiar with the job, and thus the low quality of the starting data is obfuscated. (For instance, the program might suggest that a developer pledge to, Increase the number of lines of code I write by 30%. [Not an exact quote--but I think I've captured the flavor]. This is a clear invitation to replace good software design with copy-and-paste coding, and I'd probably fire any developer who named it as one of his/her goals, but a C-level who has been out of the trenches for too long might consider it a highly admirable target).
Long story short: in my limited experience, SF gives management the metrics it asked for without any indication that they're based on garbage. That's not exactly a prescription for success in my book.
You make a good point about overcrowding in the SaaS market; Even though competition is always a good thing for those of us on the buying end, when it's so densely packed you can't see what's what, that can be unhealthy for the market in the long run.
And I can't help but feel that with more and more acronym-based business models emerging every year, and some of them being possible for any upstart to get a foot in, we're only creating fodder for this type of situation. I think that a lot of these types of markets are going to stay hectic like this for years until internet and processor speeds stop doubling every other year.
The blogs and comments posted on EnterpriseEfficiency.com do not reflect the views of TechWeb, EnterpriseEfficiency.com, or its sponsors. EnterpriseEfficiency.com, TechWeb, and its sponsors do not assume responsibility for any comments, claims, or opinions made by authors and bloggers. They are no substitute for your own research and should not be relied upon for trading or any other purpose.
Enterprise Efficiency is looking for engaged readers to moderate the message boards on this site. Engage in high-IQ conversations with IT industry leaders; earn kudos and perks. Interested? E-mail: [email protected]
Dell's Efficiency Modeling Tool The major problem facing the CIO is how to measure the effectiveness of the IT department. Learn how Dell’s Efficiency Modeling Tool gives the CIO two clear, powerful numbers: Efficiency Quotient and Impact Quotient. These numbers can be transforma¬tive not only to the department, but to the entire enterprise. Read the full report
Now that TGen has broken new ground in genomic research by using Dell's storage, cloud, and high-performance computing solutions, the company discusses what will come next for it and for personalized medicine.
The Translational Genomics Research Institute wanted to save lives, but its efforts were hobbled by immense computing challenges related to collecting, processing, sharing, and storing enormous amounts of data.
Office and personal productivity tools come in a first-class and coach flavor set, but what makes the difference is primarily little things that most users won't encounter. What's the big issue in using something other than Office, and can you get around it?
We really don't want an "Internet of Everything" but even building an Internet of Everythinguseful means setting some ground rules to insure there's value in the process and that costs and risks are minimized.
Google's Chrome OS has a lot of potential value and a lot of recent press, but it still needs something to make it more than a thin client. It needs cloud integration, it needs extended APIs via web services, and it needs to suck it up and support a hard drive.
On a recent African trip I saw examples of the value of the cloud in developing nations, for educational and community development programs. We could build on this, but not only in developing economies, because these same programs are often under-supported even in first-world countries.
VMware's debate with Cisco on SDN might finally create a fusion between an SDN view that's all about software and another that's all about network equipment. That would be good for every enterprise considering the cloud and SDN.
Wearing a bulky, oversized watch is good training for the next phase in wristwatches: the Internet-enabled, connected watch. Why the smartphone-tethered connected watch makes sense, plus Ivan demos an entirely new concept for the "smart watch."
Cloud storage costs are determined primarily by the rate at which files are changed and the possibility of concurrent access/update. If you can structure your storage use to optimize these factors you can cut costs, perhaps to zero.
The Internet has evolved into a machine for drumming up a chorus of "Happy Birthday" messages, from family, friends, friends of friends who you added on Facebook, random people that you circled on G+, and increasingly, automated bots. Enough already.