When developing a SaaS ERP RFP, business must be mindful of involving IT, just like procuring on-premise applications.
SaaS purchases still require Fit/Gap analysis, process diagramming and
“People think, ’Oh, it’s in the cloud. We don’t need to have our IT guys involved,’” said Scott Priestly, president and founder of Lionshare Software, a consulting firm that aids in ERP selection and projects. “A sales manager with 10 guys on his staff takes his credit card and signs up for Salesforce.com for 10 users and doesn’t give any thought to aligning with process.”
But there are some key differences between developing SaaS and on-premise RFPs. With SaaS RFPs, it’s crucial to pay attention to the service delivery capabilities of the vendor and its financial viability and to ask some pointed infrastructure questions.
Vendor viability more critical with SaaS
First, customers may need to ask questions that will enable them to determine the financial viability of the vendor -- given high-profile closures like LucidEra, a SaaS BI vendor that shut down last year.
Customers should also ask for as many references as possible, including the names of companies that may have terminated contracts, to try to get a better understanding of what’s working and what’s not, according to Jeff Kaplan, managing director of ThinkStrategies.
“This still is an embryonic marketplace,” Kaplan said. “You’re trying to minimize those threats.”
Clients should know about their vendor’s potential profitability, who the investors are, and how great the dedication to SaaS is, said Forrester Research’s Liz Herbert.
Ask questions in the RFP about revenue, she said, and ask about the number of clients in order to learn how dependent they are on key clients, versus having a broader appeal.
Go beyond the boilerplate SLA
With SaaS, organizations also need to focus on the service level agreement. Kaplan said it is important to understand how the service is delivered; how it will be properly integrated into the legacy system; how the vendor assures availability, response time, performance and security; and what kinds of escalation clauses are in place when things break. Customers will also want to include provisions on how often they can review performance metrics.
“The biggest mistake,” he said, “is forgetting that this is a service relationship -- as opposed to the product procurement process.”
Most SaaS includes the support, but some small vendors may limit the available hours, or the types of support that clients can receive, such as limiting it to email support, Herbert said. Many outsource support, and those technicians may be trained across many applications, not just that particular vendor.
In turn, the SaaS provider automatically patches many problems, Kaplan said. But customers need to know what the approach will be to a serious issue, how clients will be notified and the approach to server downtime.
SaaS buyers should ask how frequent the upgrades are, how the organization will be notified and what the flexibility is to sandbox them, Herbert said. Customers also need to get information on when software updates and upgrades will be rolled out, so that they don’t disrupt operations.
Most importantly, customers need to know the clauses that allow termination of a contract and what happens with the data in that event, Kaplan said.
Questions about infrastructure are also key. Because the organization is giving up so much control of the application, it’s crucial to know where it is physically hosted and details about physical backup redundancies, Herbert said.
Above all, don’t be too rigid and too stuck on the old way of doing things.
Some companies won’t sign an agreement if the uptime guarantee isn’t more than 99.5% or because of security concerns. Companies often hold third parties to standards their own IT departments can’t meet.
“They have this pie-in-the-sky vision of how a third party should be,” Herbert said. “Often, what the SaaS provider is offering is still better than what they’re doing internally.”