Best Practices for Validation of a Software as a Service (SaaS) Customer Relationship Management (CRM) Solution - Part 2

Part 2: Best Practices for the Validation of a SaaS Application

Written by Gregg Mauriello - Validation Manager, QPharma

In Part 1, I gave an overview of what Cloud Computing and SaaS are, and I promised more information in the coming months. Part 2 is here, and now I can discuss the best practices for the validation of a SaaS application.   I will look at the methodology for the validation of a SaaS CRM Application and compare it to the conventional methodology for the validation of a CRM Application. 

Since all customers utilize the same instance of a SaaS application, the core functionality of the application can be validated just once.  Also, the vendor may perform a baseline configuration of the application to meet best practices for a CRM application.  This baseline would also be validated just once.  The customer validation, therefore, can be limited to the customer-specific configuration of the application that deviates from the pre-validated baseline.   The validation of the core application and baseline configuration will follow the conventional methodology for validation, including installation and operational qualification.  The vendor must develop business requirements and functional specifications against which to test including the definition of the baseline configuration.  Note: The focus of validation testing will be on functionality of the system with regulatory impact.

Deliverables:

• The Vendor Validation Plan will document the process, activities, and deliverables required for the validation of the core application and baseline configuration. 
• An Installation Qualification will be developed to document all core software and hardware required for the application. Note: The vendor IQ will not address the field device used for the sales force as this will vary greatly by customer. 
• An Operational Qualification will be developed to test the functionality of the core application and baseline configuration. 
• A Performance Qualification will not be developed as the system will not be utilized in a production environment until it is deployed for a particular customer. 
• All validation activities will be summarized in a Validation Summary Report and a Release Memo will be generated, which will document that the application has been validated and is ready for customer configuration and implementation.

All customers utilizing the application will be able to leverage the validation of the core system and baseline configuration, allowing for a lean validation to be performed by the customer.  It is recommended that the customer perform a vendor audit of the core configuration validation package to determine two factors:  

A) If the validation documentation is in line with their internal quality processes and 

B) How much validation of their specific configuration will be required.  

The vendor will also provide a service level agreement which will define the vendor’s role in maintenance and the administration of the system and data.  All procedures that are performed by the vendor, such as backup and recovery, change management (for code and infrastructure), disaster recovery, physical and logical security, system administration, and training, will be documented by the vendor.

Still interested in hearing more? I will be presenting information on this subject during an interactive workshop, at IVT’s 16th Annual Validation Week on October 26th (Session 4 on Day 2!).  The workshop will be presented along with my colleague, Elise Miner.

If you are not attending Val Week, stay tuned for Part III, where I will discuss customer responsibilities in the validation of a SaaS CRM system.