Software-as-a-service is growing at a healthy clip, from global revenue of $12.3 billion in 2011 to projected revenue of $14.5 billion this year, according to Gartner. Strong growth will continue through at least 2015, when Gartner expects worldwide revenue to reach $22.1 billion.
Purchasing SaaS is different than procuring traditional on-premise software. Organizations that want to maximize the value they derive from SaaS should be aware of potential purchasing pitfalls and how to avoid them. Because SaaS is still relatively new, many organizations lack procurement and contract negotiation expertise, wrote Constellation Research CEO Ray Wang in a blog post. In addition, while SaaS contracts are less complex than those for on-premise software, they are generally not as simple as buyers may assume.
Enterprise Apps Today asked Wang and two other experts, Bruce Guptill, head of research for Saugatuck Technology, and Jeff Kaplan, managing principal of THINKStrategies, a firm that hosts the Cloud Computing Showplace, for SaaS purchasing and contract negotiating tips.
Ask for upward and downward mobility. As Wang notes, many SaaS deployments start with a small number of users in a departmental setting. Buyers should plan for additional usage by negotiating upfront for discounts when users are added, It’s also important to consider what might happen if usage scales down, by negotiating the ability to reduce usage without suffering big penalties.
Assess your SaaS support options. While SaaS contracts automatically include maintenance and updates, a benefit played up by vendors, customers aren’t required to buy support -- and should wait until they better understand their support needs. Wang suggests not signing up for the highest level support option, as it can always be added later if desired.
Adopt SaaS incrementally. Related to Wang’s tip, Kaplan advises adopting SaaS applications incrementally to test their functional capabilities and the vendor’s support capabilities. It’s also a good idea to take advantage of any free trials offered by a vendor to get a sense of how an app will suit your needs before signing on the dotted line.
Remember no SaaS exists in a vacuum. A SaaS app will likely need to integrate with other SaaS and/or on-premise applications. Kaplan recommends ensuring SaaS apps include “strong and pervasive” APIs and are supported by third-party integration connectors and system integrators.
SLAs are narrower in scope than MSAs and focus more on service delivery-related issues such as availability/uptime, reliability and customer support-related provisions. Guptill stresses carefully reading both and making sure there is no unnecessary overlap or even potential conflict between the two.
Focus on SaaS terms and conditions that matter most. SLAs should clearly address performance standards that are critical to users’ needs, Guptill points out. As an example, he says SLAs should include a standard related to transaction performance, which typically specifies how daily average transaction completion speeds will be measured and reported. Other essential issues could include those related to scalability, security and data rights.
If an MSA omits these issues or does not adequately address key requirements such as how data is transferred at the end of a contract, the purchaser should seek to have provisions included in an SLA, Guptill says.
Ann All is the editor of Enterprise Apps Today. Follow Enterprise Apps Today on Twitter @EntApps2Day.