Software as a Service (SaaS) is a distribution model in which applications are hosted by a vendor and made available to customers over a network.  Both hardware and software are owned by the provider and maintained at its datacenter.  In a true SaaS model, both are also shared by all clients, although user data is divided.  In addition, all customers are on the same version and instance of the application.  The software is typically leased, although it is sometimes licensed as if it was being bought. 

Over the past few years, a critical mass of adopters, better usability, enhancements to GUIs have all driven organizations both large and small to adopt the SaaS model.  Coincidentally, a number of large, well-established enterprise application giants have built up substantial SaaS businesses in recent years to compete with younger upstarts.

The four greatest value propositions driving SaaS adoption amongst HR technology buyers are:

1. Faster time-to-value through configurable applications.

2. Mitigated risk through minimal upfront costs and pay-as-you-go procurement.

3. Less reliance on support from internal IT departments that are too busy to help.

4. Economies of scale like any outsourcing model.

However, in order to realize these, you must first contractually agree with your SaaS providers on the particulars of how these opportunities will be realized.  I have learned from working with many clients that there are things to watch out for when engaging a SaaS provider.  Moreover, many have told me that they include written stipulations in their contracts to protect their interests such as:

1. Application Support.  Most companies get service level agreements (SLAs) on support related to the application running properly as well its availability, including response times, and notifications of outages and how soon after a failure you must be notified.

2. Agreement on what an active user is.  This is not unlike contracts related to behind-the-firewall implementations.  However, reports should be generated more efficiently given that this is how the SaaS provider runs its business.

3. Security.  Typically these requirements (e.g., intrusion tests, SAS 70 Type 2 Certificate) are covered pre-contract during the evaluation period.

4. Data back-up and recovery.  Similar to security bullet above.

5. Data ownership.  Ensure that your provider will enable you to easily migrate your data should you decide to move to a competitor or bring the solution in-question in-house.  SLAs related to data migration in such events are not uncommon.

6. Ownership of source code.  This may be covered through an escrow account.  Even financially sound companies get shut down from time-to-time.  And you never know when someone is going to win a patent infringement suit against your SaaS provider.

7. Integration non-SaaS systems.  Requirements related to frequency, data mapping, and file format are the biggest gotchas.

8. Growth.  Include and define provisions (i.e., milestones) for growth that will allow you to lower your average cost-per-user.

9. Training and Certification of Support Staff.  While ‘major release' is not a term often uttered by a SaaS provider, some are more significant than others.  We have seen clients require that all support personnel assigned to them be trained and certified on the latest version.

I have learned about these points through lessons learned by clients and service providers.  However, I know this list isn't exhaustive.  I'm curious as to what pearls of wisdom my KI colleagues can share based on their experience.  And I'm even more curious to hear from those of you who have been involved in a constructing or negotiating SaaS contract.  KI does not provide consulting related to either of these areas. 

It was late on the evening of the 24th of December. Our children had gone to bed and my wife and I had pulled all the gifts out of the closet and began the task of putting things together. I drew the short straw and landed the elaborate train set that boasted over 100 pieces boldly on the outside of the packaging. How bad could it be I thought? Well, over an hour later when I had finished putting it together with no less than 3 extra pieces and no logical place for them to go, I knew what the warning "some assembly required" was really telling me.

As I shake off the after effects of what seems like a week long holiday celebration and prepare myself for the New Year, I can only think how this story has similar meaning to those of you contemplating a Talent Management technology initiative. Just like the instructions on the package warned that some assembly would be required to make that train set work, so must you adequately plan to implement your Talent Management software. As much as hosted solutions and software as a service give you a great platform from which to build, it doesn't do it itself. There is no magic box that, once turned on, will solve all your organizational ills. Talent Management software initiatives take work. They take planning and careful execution that if done right, will provide much traction with the talent in your organization. Knowledge Infusion has long advocated that technology initiatives are really 40% about the people, 40% about the process, and only 20% about the technology that enables the rest of it to work.

As you approach the New Year and begin to plan your Talent Management technology initiatives for 2008, take care to spend the time up front to really think about the people it will impact and the process you will have them go through. As great as the technology has become, it won't do the change management for you. Remember, some assembly is required to make your Talent Management technology initiative work.