The first part of this blog series described the opportunity for software as a service (SaaS) or on-demand enterprise applications, especially in the current difficult economic milieu. But before any vendor can embark on delivering a SaaS offering, it must understand several misconceptions about SaaS.
Part two then analyzed the first two of the top five SaaS assumptions that Gartner recently outlined in its research.
More SaaS Facts and Fiction
The third assumption is that SaaS is priced as a utility model, which is almost always false. Although the claim is that companies are only charged for what and how much software they actually use, for most SaaS deployments, a company must commit to a predetermined contract, independent of actual usage.
If any company really wants utility pricing, then it should demand that the SaaS vendor charge, e.g., per each sales quotation, order, or shopping cart checkout (in case of using an on-demand sales configurator) or per individual case (in case of using an on-demand case management software). However, to be fair to vendors, it is interesting to note how many customers are still afraid of using this pricing model per se.
Namely, many companies are overly optimistic (if not delusional) about their future success, and they believe that they will grow rapidly. Thus, the assumed (unrealistically high) volume of transactions will make the utility pricing model prohibitively expensive. Even in today’s shrinking economy, not many companies realize that their sales transactions will dwindle and that they could even save by using a utility-priced model.
I bet that most on-demand customer relationship management (CRM) clients would opt to pay, e.g., US$70 per user per month instead of being charged US$1 per each created account, contact, and opportunity. If one added all new accounts, contacts, and leads that a user creates in month, I am pretty much sure that in most environments these figures would not amount to 70 bucks, at least not in this economy. Thus, even some decent SaaS vendors will then say “Fine, since you insist on a SaaS contract, this is our price per user per month, please tell us for how many users and for how many years would you like the contract signed?”
Assumption number four is that SaaS does not integrate well with on-premises software applications or data sources. This too is false, since there are two primary methods of integrating SaaS offerings with on-premises applications or data sources. The first is batch synchronization, while the second is real-time integration using Web services.
Gartner points out another way to combine the two above integration methods into an event-driven programming manner. This creates Web service triggers that are based on events occurring in the SaaS service. And yet another method involves integrating SaaS applications at the user-interface (UI) level through mashups (or hybrid Web applications).
Finally, Gartner’s fifth in its top five false assumptions is that SaaS applications cater only to basic functional requirements. As said in Part II, SaaS applications are highly configurable at the metadata level, with many customization capabilities coming inherently from within an application platform as a service (PaaS).
In the next parts of this blog series I will talk about some good examples in which complete custom applications have been built using a commercially available PaaS. However, Gartner warns that some gaps might remain for truly complex, end-to-end processes that require deep workflow or business process management (BPM) capabilities.
The Myth of SaaS Users’ Size
I could also add a sixth myth, which is that only small and medium enterprises (SMEs) are a good fit for SaaS. Indeed, many traditional larger on-premises software vendors still believe that only little customers use SaaS, which comes as a good excuse for their SaaS laggardness.
But successful SaaS players have a plethora of large enterprises as customers, even for mission-critical applications. Think of Salesforce.com, which recently celebrated its first 10 years, and which sells its namesake CRM solution Enterprise Edition to large banks, brokers, technology companies, healthcare, professional services, and so on. Companies with even 50,000 and 75,000 user implementations are Salesforce.com CRM customers.
Even relative newcomer Workday is already selling its human resource management system (HRMS) and other parts of enterprise resource planning (ERP) to firms with 20,000 or more employees. Not to mention Automatic Data Processing (ADP), which has always sold its SaaS HR/Payroll product to firms of every size (we just didn’t know what to call it in the decades before the advent of the SaaS acronym).
In fact, customer size will not matter, whereas the independent software vendors’ (ISVs’) product and reputation will when it comes to success in the SaaS arena. Large enterprises and midmarket customers need ever more support and higher quality of service (including service level guarantees). In turn, ISVs will have to deal with more sophisticated business partners for SaaS design, implementation, customization, and to provide a bulletproof infrastructure.
Aleks Ivanovic, chief executive officer (CEO) and founder of the SaaS vendor Webcom Inc., believes that the traditional software channels play a much smaller role in SaaS because there are no hardware pull-through sales, while software implementations have thus far been generally shorter, smoother, simpler, and therefore less attractive to system integrators (SI’s) and consultants. However, as the SaaS vendors’ solutions mature and evolve, there will be more and more room for partners because the projects are going to get more complex as a result of the following two major trends:
SaaS Opportunity Does Not Guarantee Success
Thus, while many see a large and growing market for SaaS applications (whereby even the currently sluggish economy will likely bolster and accelerate the on-demand market) and the opportunity for aspiring SaaS vendors is right now is far from being an easy endeavor. Namely, developing SaaS solutions successfully involves a “helluva lot more” than simply putting an application on the Web. SaaS is a completely different ball game than the traditional on-premise one, and just rewriting an old on-premise application will not work.
I concur with Amy D. Wohl’s assertions in her recent blog post:
“Note that offering a SaaS version of your application that is less than the real thing will not work, particularly if you are the standard bearer in a big market segment. The customers will find it less than satisfactory and a new SaaS startup will find your mistake their lynch pin to guarantee their market success. SaaS customers, thanks to the web, know the alternatives and want the real thing. We can’t count on marketing in little curtained cubicles to less-than-knowledgeable customers any more.”
When asked about the rewrite issue, David Dobrin, president and founder of B2B Analysts Inc. said:
“It’s really complicated, but the simple answer is that there is no way. You get no edge when you rewrite your product for SaaS, and you run into enormous business model problems. Suddenly, you have three times the up-front costs and the time you have to wait before you make money on your product is doubled.
Repeat: there is no edge. The last thing you want to do is build the same product on the web, since you want to exploit web capabilities. So you have no edge there. Your customers are already trained to buy on-premise, so they see no point in buying from you. Your entire organization has got on-premise DNA, which in this context, is pretty much as incurable and deadly as HIV. If you’ve got the money and the cloud bug, start over.”
But even for those who get the drift and want to start from scratch, unfortunately there is no magic bullet yet, just a long and painful learning curve. The good-old (and daunting) “Build vs. Buy” cost analyses apply at every step, from deciding on the solution’s expertise (functional footprint), architecture, plumbing tools, hosting mode, platforms, etc.
Even when all these decisions have been made and the SaaS product is delivered, then come the serious preparation tasks for technical operations of a SaaS business, such as quality testing of software, management of the product’s release cycles (i.e., how to manage maintenance windows, upgrades, and new functionality without affecting customers), performance (uptime) monitoring of the Internet hosting service infrastructure, reliability, replication and recovery, compliance and auditing, contract management, customer service, and so forth. Most of these operational issues are naturally quite different than in the on-premise software arena.
Key SaaS Technical Considerations
But let me backtrack first to the very beginning (a new SaaS product’s initial idea) and postulate the necessary decision-making steps thereafter. I recently attended an excellent Webcast sponsored by OpSource, a leading provider of Web operations solutions (managed hosting with value-add SaaS plumbing components) for SaaS companies. The presentation on the key technical considerations for SaaS aspirants came from Scio Consulting International. Scio is a SaaS-enablement professional place that offers SaaS business and technical consulting, SaaS product development services, and SaaS infrastructure management and operations.
First of all, an appropriate SaaS feature set must be aligned with the future SaaS company’s vision and strategy, and all that with the Web-based mindset. Namely, the future SaaS vendor has to answer whether there is already an existing on-premise version of the application, and who the target customer for the SaaS application would be (i.e., would it be the same as for on-premise or it is a new target segment?).
Also, what is the purpose of creating a brand new SaaS solution? Is it an opportunity to enter new markets, to expand the current reach, or a way for the vendor to stop losing clients? The vendor’s executives should hereby also consider how the product would handle and provide business analytics (and metrics) as well as mobile devices.
Once the functional footprint (scope) is decided upon, the company has to identify gaps within its in-house skill sets and define how to fill them. One should differentiate here between the skills for product building and operating.
The first group of skills entails product management, Web architecture design and development, Rich Internet Application (RIA) user interface (UI) design, infrastructure architecture, and Web testing. The operating skills focus on Web-based marketing and sales, infrastructure management, Web application management and performance monitoring, and Web-based customer service and technical support.
Part IIb of this blog series will continue with more major technical considerations before any vendor can embark onto delivering a SaaS offering. In the meantime, your comments and feedback with regard to the opinions and assertions expressed thus far are welcome.
If you are applications users, how important are the abovementioned considerations in your software selections? For both users and vendors, what are your SaaS experiences (both in using and delivering a solution)?
You are only looking at one application CRM in a Saas mode but whether you like it or not major ERP i.e SAP, Oracle companies have all invested heavily into the Cloud Computing concept Saas is but oone of three delivery methods for cloud computing. The reason why cloud computing is taken hold is a lower Total Cost Of Ownership,no capital expense for software , no front end investment of IT resources. SaaS is but one part of the equation.
Cloud computing is dramatically changing the ERP landscape for the SMB market. Epicor, Syspro, SAP Netsuite and others are already offering SaaS.
There is the pure SaaS, where tailoring is just to pop-in the constants for company name, etc,, and then there is the mish-mash SaaS, where SaaS in the clouds is being hosted, and the customisation is developed on a front end server.
Netsuit (http://blogs.zdnet.com/BTL/?p=8515) is finding that smbs are trading out their existing systems because the Netsuite pricing is cheap. Especially when you look at the number of services that are being replaced.
It would cost $100 million to solve the multinational and multi-subsidiary management and consolidation issue if you implemented SAP on a global scale. Nowhere near that expense with dropping legacy ERP for SaaS.
Switching ERP systems is a big deal, but the price point and functionality is compelling.”
The US government (http://csrc.nist.gov/groups/SNS/cloud-computing/index.html) has a true definition for Cloud Computing, and SaaS is only part of it.
In summary, as current trends continue, the premise is that software will go the way of the beta vs the vcr alternative. The on-premise model are represented by “beta” and the vcr by SaaS.
Its True the SMB market/SMEs requires economical solutions.
Adopting to SaaS model will not be a big deal. the DATA need to be prepared for suiting the model will only take two weeks or less. The Indian ERP vendors keenly concentrating on this SaaS model.
Valgen introduces eSas by August 30 2008 [http://blog.technologyevaluation.com/blog/2009/05/18/to-saas-or-not-is-that-a-question-%E2%80%93-saasy-discussions-part-iia/#comments See Financial Chronicle]
It is most suitable model for SMEs
for more details please visit [http://www.valgeninc.com/saas-erp.html www.valgeninc.com]
yes its true
very valuable discussion, I find, and it highlights nicely, that there aren’t simple answers when you talk Enterprise Class Platforms in the Cloud.
Despite all the challenges, this is an extremly exciting topic and it would be great, if more people would be willing to open up their minds and discuss this from an objective point of view.
I feel, there is not only space for vendors and a new breed of professionals (those composing Business Solutions, based on Cloud Architectures), but as well a universe of new opportunities to create very different Business Models.
General Manager, EMEA
SAP Business ByDesign
Definitions of SaaS vary widely across the industry with the lines blurred between Application Service Provider (ASP), on-demand, Web 2.0 and Service Oriented Architecture (SOA). Quite simply, SaaS is a model of software delivery where the software company provides maintenance, daily technical operation and support for the software for their client.