One of the critical success factors of SaaS is the paradox of confidence.
As I've pointed out here before, SaaS (Software-as-a-Service) helps you to manage your Service-Oriented Cashflow. By shifting from fixed costs upfront to variable costs later, you may be getting a cashflow advantage even if you end up paying more in total.
Now here's the thing about confidence. Optimists prefer fixed costs because they expect to get economies of scale; pessimists prefer variable costs because they fear they might not. So in an economic downturn, it makes sense for pessimists to shift a lot of expenditure to Pay-As-You-Go.
Some analysts are comparing SaaS (Software-as-a-Service) with ASP (application service provision). Although ASP had some notable successes, it wasn't anything like as commercially successful as its champions hoped. However, in times of credit crunch and pessimism, the cashflow arguments may be much more telling this time around.
Now here's the second thing about confidence. Pay-As-You-Go may improve the cashflow for the service consumer, but it typically causes cashflow problems for the service provider. So maybe only the most confident service providers - with the best technology and the most confident investors - can afford to offer services on a Pay-As-You-Go basis.
And here's the third thing about confidence. The consumer needs to be confident that the service provider is going to stick around. That means financial stability as well as technical stability. Does this mean it's the big companies who are going to make all the money from SaaS?
Microsoft certainly hopes that "Customers will write us bigger checks". See comment by Ed Brill (IBM), via Esther Schindler. But Microsoft can probably afford to wait for the cheques to roll in. Smaller companies will somehow have to find a way to finesse the cashflow.
The biggest difference between modern, true SaaS and ASP-style, fake SaaS is the application.
ReplyDeleteTrue SaaS provides a Net-native application that was built to be delivered and consumed on the Internet. Fake SaaS is an old client/server application that end users were tired of owning and managing, so they outsourced the care and feeding of the app to a third party. Typically a legacy application served up by an ASP will have a bolt-on Web UI to make it remotely accessible.
End users should care about the distinction because if they didn't like their legacy application before and thought it was too expensive to own and a pain to administer, ASP (fake SaaS) is not going to fix these issues. It will probably be more expensive to own and the ASP just becomes another layer for the customer to fight through to make the application work for the business. Upgrade cycles don't go away and remain just as difficult, the ASP is now doing the work but the customer will still pay for it.
Legacy vendors care because they don't have an answer for modern SaaS. They are looking for a stop gap, loss leader to maintain their market share. They are taking their old technology, throwing it in an ASP-style datacenter somewhere, slapping subscription pricing on the it, and calling it SaaS. They are afraid of losing account control to true SaaS alternatives. Obviously, this isn't in the best interest of the customer and gives SaaS a bad name.
True SaaS vendors care because the legacy, ASP vendors are marginalizing the real benefits of SaaS by pushing a fake.
Service-now.com is a cash-flow positive, four-year old provider of an IT management SaaS application. Our annual recurring revenue is at about $20 million and we will be profitable this year. Obviously we've been growing very quickly. We've been able to accomplish what we have in short order because we offer true SaaS and leverage data center automation and virtualization to keep our operations effiecient.
In regards to cash flow, of course this would be a problem for ASPs. They are trying to force old technology to work on the Internet. They must bear the same burden of owning, maintaining and upgrading traditional applications. In the end, somebody has to pay for this and if the customer won't, the ASP will eat it. Big vendors may be able to sustain these losses for a time but the shell game will come to an end when customers realize there is a better, cheaper way.
Here are a couple of additional resources on this topic:
Slideshare - "SaaS vs. ASP in the ITSM market"
Blog post - The second death of ASP. Questions to ask your "SaaS" vendor
Rhett
Service-now.com
My argument was purely an economic one, not a technical one. Customers should never need to ask how it's done, merely what they are going to get and what it's going to cost. So I don't understand why you should be worried about inefficient competitors. If the "true" SaaS vendors can provide better value-for-money than the "fake" ones, then surely they will prevail in the market.
ReplyDeleteYour ability to finesse the economics of cashflow appears to depend on your sitting on top of a Pay-As-You-Go infrastructure. In other words, there is some stratification in the ecosystem, which perhaps deserves closer economic analysis.
The point I was making is that the current economic conditions make both ASP and SaaS more attractive to the companies at the top of the stack (your customers) and more challenging for the companies at the bottom of the stack (your suppliers). Maybe the economic effect is more or less neutral for the people in the middle such as yourselves. Perhaps you'd like to comment on this?
I agree. As long as customers are asking the right questions, they will easily determine the solution that makes the most economic sense.
ReplyDeleteI'd say the economics of the issue are tied directly to the technology. The ASP model imploded once because the technology was not ready to support the concept in an economically-viable way.
The new economy has created a SaaS gold rush with the unfortunate potential to leave many customers holding the bag.
In our case as a SaaS application vendor, our supplier essentially consists of data center processing that resides in the cloud. We can scale efficiently using data center automation technologies that weren't available a decade ago. Therefore, we can focus on application development and our customers ultimately benefit.
The ASP model is a heavier lift and requires expensive manual resources. The old-school ASPs couldn't absorb this cost. Like you say, maybe the big vendors today can absorb it. However, the consumers at the top of the ASP stack will feel the burden eventually if they aren't asking the right questions from the start.
Thanks for writing about this topic. It's good to see others thinking about it.