My February column on virtual computing and 21 CFR Part 11 compliance brought a slew of questions, comments, and interesting discussions from readers (a copy of the article, "Virtualization and Validation," is available here on the Pharmaceutical Processing site or in the article library on my website). In the discussions and questions, one theme repeatedly came up:deciding on computer software you access over the internet rather than buying and installing software directly on your computer. Software you access over the internet is known as "hosted" software or "software-as-a-service" (SaaS) because it is hosted (installed and maintained) by someone else and then given to you as a service.
Commonplace out in the broader marketplace, especially among small to midsized businesses, software-as-a-service is not widely used in the biopharmaceutical or medical device industries; as a result, the ins and outs of SaaS and selecting a SaaS vendor are not well known. After a number of inquiries for advice from readers, I decided to contact a friend of more than twenty years, Alex DeBlois, who now lives out in the Seattle, Washington area. Alex is a former SaaS supplier executive (he’s now with a company called Seven Simple Machines, www.7simplemachines.com), and so Alex was free to speak with candor about the pros and cons of SaaS in the biopharmaceutical arena.
Doing Business with a Software-as-a-Service Supplier
The first point Alex made is that in any business, certain departments are more receptive than others when it comes to accessing business software over the internet: "Sales and Marketing is number one, followed – in no particular order – by Finance and Personnel departments, customer service, and order intake or supply chain entry. Most shipping and receiving groups already use software-as-a-service when they access the web portals of the post office, UPS, FedEx, and other shipping services."
If you are debating about SaaS for your company, your Sales and Marketing force may be a natural fit to pilot the service. Sales and Marketing teams often embrace SaaS due to five benefits:
• World-wide availability of the software as long as an internet connection is nearby
• State-of-the-art technology allows much easier usability (according to Alex, "Usability is a key make or break feature, so SaaS vendors will compete on who’s software is easier to use")
• Shorter times between upgrades and fixes
• A tight focus on specific functionality ("When you get SaaS, you are only paying for the functions you need, not the other 80% of the functions in most software that you never use")
• Ease of integration with other systems like order entry, billing, shipment tracking and so on.
Downsides to software-as-a-service tend to vary by vendor. Vendors often offer varying degrees of usage of their software based on whether a person is connected to the internet at that moment or plans to do so later in the day (for instance, a sales representative out in the field could input all the order data, then simply upload it via an internet connection at home). If non-internet usage is a concern at your company, then a key consideration in selecting a SaaS vendor will be the degree of functionality allowed away from the internet.
There are three areas within biopharmaceutical companies that Alex suggested may not be good candidates for software-as-a-service adoption: new product development (including preclinical and clinical), manufacturing, and quality or regulatory operations.
Over the years, I’ve learned that quality and regulatory affairs departments tend to be conservative when it comes to anything new (a colleague of mine tells a wonderful story of how his company was about to purchase what everyone felt was the perfect computer system to manage their chemical compounds and inventory, but as they were running through the final specifications, the vendor happened to mention the phrase "uses cutting-edge technology" when the regulatory affairs vice-president was in the room and presto, the deal was off). While that is a bit extreme, I have seen the conservatism play out in the following manner: when something new is broached, quality and regulatory personnel look to the regulations for guidance. Unfortunately, as I pointed out in my speech at the National Institutes of Health in late April, the regulations tend to be more than a decade behind the realities of technology today, and as a result, the regulations are silent on questions involving current technology capabilities. Regulatory silence is then interpreted as "no" (e.g., better to be safe than sorry). How much – or even whether – this hamstrings the adoption of innovation in pharmaceutical firms is beyond the scope of this article, other than to point out that many technology directors have run into a brick wall trying to get quality and regulatory professionals onboard with software-as-a-service.
Manufacturing operations are also not a good candidate for software-as-a-service. Depending on internet connectivity for running manufacturing equipment and monitoring technology is not something that most firms want to risk. The cost of manufacturing downtime is very easy to measure and can quickly outweigh any initial software-as-a-service cost savings.
This should not preclude you from at least looking at options when it comes to SaaS and your manufacturing environment. As process analytical technology (PAT) evolves and grows in adoption, many companies that operate in lower margins (such as contract manufacturers) will simply not be able to afford the resources to implement and maintain all the technology on site; some level of software-as-a-service is inevitable. If you have a pilot plant operation, this may be a good fit to explore options.
Finally, in terms of software-as-a-service adoption in your preclinical and clinical operations, the key concerns will have to do with security – specifically around developing intellectual property and clinical patient privacy. Ironically, these risks already exist and are regularly taken advantage of today (every other week seems to bring some story of privacy loss or intellectual property loss in the news), so whether such risks are much greater simply by accessing software over the internet is questionable. Assuming you already have a set of robust intellectual property security policies and controls in place (for examples, see my recorded seminar, Preventing Intellectual Property Theft by Contractors and Partners), the next step would be to examine SaaS vendors with customers beholden to the HIPAA regulations. I also suggest you consider SaaS vendors who have security personnel either familiar with the Information Systems Audit and Control Association (ISACA), or whom have been certified by ISACA.
Building the Business Case for Software-as-a-Service
Beyond tackling the above objections, building the business case for SaaS adoption somewhere in your organization requires an analysis of the financial aspects or total cost of ownership. Alex was kind enough to identify several financial considerations to make sure you address (before your chief financial officer asks about them):
"First, SaaS is an expense as opposed to a capital investment, so the dollars usually come out of the operating budget. This also means that a company does not get the benefit of depreciation over 4-5 years versus a stand-alone, installed product. However, this can be more than made up for when you factor in the zero to very low infrastructure and maintenance costs over those years. Given that such a large percentage of any computer department’s budget is strictly for maintenance, the savings can be substantial."
Any business case will also need to address backup capabilities (e.g., disaster recovery), customer support, vendor viability, and the qualification of the vendor under your quality system. From the standpoint of vendor viability, while most of us might be inclined to go with the three "big boys" that dominate the market (IBM, Hewlett Packard, and Computer Associates), two things may give you pause:
• Cost – large firms such as these three do not make significant profits from servicing small to midsized companies; their cost structures tend to be aligned toward potential customers with revenues in the billions of dollars.
• Service – assuming you go ahead with a potential contract with a big SaaS vendor in the six figures or less range, be very skeptical about the service promised; I’ve written extensively (for instance, see my article Cost-Effective IT Outsourcing) on the naivety of expecting top tier service from a supplier who counts your business as a small fraction of their overall revenues.
Service and support ultimately boil down to your service level agreement or quality agreement, and the teeth you’ve put into the contract. Attendees of my talks on supplier quality management know my own personal experience have given me a philosophy of "no real teeth means no real contract." You can see examples of contractual teeth and quality systems controls in my seminar, Managing Supplier Risk – FDA Expectations, which you can download from my website).
To tackle backups, as I pointed out in "Validation and Virtualization" and in the interview I did on the subject for GxP Lifeline (you can download a copy of the interview from the article library on my website), the best approach is to define your needs, ensure those needs are in line with industry baseline expectations, and then put that into your service level agreement or quality agreement.
Qualification of a SaaS supplier is a large topic, and the how-to’s are beyond the scope of this article. However, two resources for any audit you plan to conduct of a software-as-a-service supplier may be helpful: Carnegie Mellon’s Capability Maturity Model® Integration (www.sei.cmu.edu/cmmi) and the TickITplus schema (www.tickitplus.org). Both of these models are designed to assess the maturity and quality controls of a software development and service organization. There is also a third option – but one that is relatively new – and that’s to see if the SaaS vendor is certified in ISO 20000: IT Service Management.
Final Thoughts
Software-as-a-service is not for everyone. I would like to think this article has given you some good insights on where you may best be able to adopt SaaS in your organization for the most value and least risk. I welcome your feedback and questions, as well as any suggestions for future topics to address.
Are you ready?
About the AuthorJohn Avellanet is the founder of the FDA regulatory intelligence and lean quality systems compliance program for executives and business owners, SmarterCompliance™. He is the author of more than 100 articles, a co-author of the book Best Practices in Biotechnology Business Development, and a frequent speaker with FDA officials.He can be directly reached through his independent advisory firm, Cerulean Associates LLC, on the web at www.ceruleanllc.com.
