Cloud Computing - Selection Process for SaaS - How Different from On-Premise?

Much has been written about the pros and cons of cloud SaaS (Software-as-a-Service) compared to traditional “on-premise” computing. SaaS covers the likes of accounting, customer relationship management (CRM), Facebook and a multitude of other business and consumer applications.

Here’s our own summary of the benefits and risks of SaaS.

But relatively little has been written about how the process for selection of business software has changed with the availability of SAAS. How much has the process changed?

I’ve been involved in selection projects for many years from three perspectives:

• Leading projects in industry
• In a sales role in a reseller of accounting and business software (so I know the tricks of the trade!)
• In consultancy with PWC and Camwells advising clients

Many of these selections have been of mid-range systems, but also corporate systems and simple systems for small businesses. Some selections are now just for SaaS, some just for on-premise (where cloud provision is not adequate in one way or another), and some with an open mind as to the final solution. So ideally a methodology is needed that caters for selecting a SaaS and/or an on-premise solution.

Camwells has a selection process that does indeed cater for both.

Nonetheless every now and again it’s worth taking a look at what others are doing to see if the process can be improved, and now is the time to do so!

Firstly it’s worth looking at the software industry’s view on the process. BASDA (the Business Application Software Developers’ Association) is the clearest representative body in the UK. It updated its recommended procurement process in a booklet in 2007. Even though this is only 3 years old, there is no mention of either “cloud”, “SaaS” or equivalent concepts (I’ve been using SaaS ten years since early 2000).

Nonetheless the booklet sets out a basic process which includes two key aspects:

1. The replacement of the bulky "Invitation to Tender" with a shortened “Request for Information” (RFI). I prefer to call it a “Request for Proposal” (RFP), to emphasise that a commercial proposal is expected in response to the requirements.
2. Bringing forward the detailed product testing to the evaluation phase prior to purchase rather than after the system has been installed.

The second point actually makes their process adaptable to the selection of cloud SaaS systems. Another body representing UK software developers, Intellect, makes some key points in the implementation process section of their white paper “The business case for Software as a Service”:

1. Many SaaS products have a free-of-charge evaluation period, or a few users can be set up at minimal cost before any major commitment is made
2. Conversely not all on-premise software vendors will allow a free or low cost on-site evaluation, as software (and possibly hardware) needs to be installed on client’s premises to even do a small (“boardroom”) pilot. On-site installation is not needed with SaaS (assuming you have internet-enabled PCs), which also means saving time to start the evaluation
3. If the risk of failure is low, especially with smaller systems, a SaaS service can be used straight away
4. If the SaaS trial is unsatisfactory, it is quicker and cheaper to stop any further work with that supplier and consider other options
5. But Intellect also mentions that tasks such as evaluation of larger systems, data loading, user training etc are similar to on-premise

Other SaaS publications I’ve collected tend to focus on the pros and cons of SaaS, not on the selection process. Google searches across the globe didn’t identify much new and useful either.

So here is a quick summary of the Camwells selection process, and how it can flex for SaaS. The focus is on mid-range solutions, but the same basic process is equally valid for small and corporate systems.

This process is broadly consistent with BASDA’s process, but with a number of practical differences. For example, we’ve found that client management prefer to discuss and collectively sign off an internally-focused “User Requirements Specification” (URS). This is in a suitable format to be tweaked into the “Request for Proposal” (RFP) sent to suppliers, or can form the basis for evaluation of SaaS offerings.

The key steps are as follows:

.	STEP	FLEXING FOR SaaS
1	Project Initiation (Steering Committee etc)	No difference for SaaS
2	User Requirements Specification (Background, Objectives & Benefits, Scope & Interaction, Key/Special Requirements)	No difference for SaaS
3	Supplier Long List	No difference for SaaS
4	Request For Proposal (RFP)	Free/Lo-cost trials instead? Dependent on complexity, may still require supplier assistance
5	Assess Supplier Proposals	If send out RFP
6	Supplier Short List Demos	Useful in all but simplest cases to have supplier involved to bring system to life and help configure pilot
7	Supplier Finalist(s) Demo(s) if required
8	Preferred Supplier Assessment	Different issues
9	Enter into Contract	Different content of contract, probably non-negotiable

I’ll look at the key differences in the implementation process next week.

Cloud SaaS providers tend to market their systems as being more intuitive, easier to use and quicker to implement than on-premise systems. As explained above, there is truth in respect of timescales. But “ease of use” is worth taking with a pinch of salt - it really depends how well the system is written, and whether functionality has been limited. As with on-premise software, the key to the selection process is to see through the gloss and to ask the important questions to ensure the offering and supplier fits your needs, before you have committed your business and your reputation.

In conclusion

Selecting SaaS and on-premise software should follow the same basic process, though SaaS systems can be quicker in certain respects. The service nature of SaaS means different issues to consider, and a final contract that’s significantly different. Whether SaaS or on-premise, the key is to start with a professional "User Requirements Specification" that clearly sets out objectives, used both for selection and then for implementation.

If you would like to know what is involved in each stage, such as how to prepare for demos and evaluation, do contact me on +44(0)1628 632914, or by email at challisc @ camwells.co.uk (please remove gaps first). I look forward to talking to you.

Or do feel free to leave a comment ...

.