Getting My SaaSy On: Upgrades

In a previous post I wrote about designing a new compensation product for a Software-as-a-Service (SaaS) software solution but I didn't explain what SaaS is or why it has business relevance.

SaaS is basically a delivery model of business software that lets people use software over the Internet without installing it. A fair whack of the business value of SaaS can be illustrated by talking about software upgrades and what it means not to need them any more.

I spent several years as a global project manager leading on-premise HCM implementations.

On-premise means the vendor sends you the software on a set of disks and it's your problem to get it installed, get your data into it, manage your technical architecture, etc.

Customers could change the product to meet their business requirements and a large part of the implementation involved designing their 'ideal' business processes, building new transactions, workflow and business logic, and creating myriad reports and interfaces to external systems.

The average implementation took about a year and a half and right about then the vendor would release a new version of the product and the fun would start over because now you had two versions.

The process of merging the two software versions is called an 'upgrade'. Here's how it works:

Let' say the vendor delivers a new process that you like better than your current process. If you decide to adopt the vendor process, you may need to back out the changes you made to the old version during the initial implemetation. Or selectively back out some changes but keep others.

Or you may decide to keep your process. Fine, but now you have to make sure you don't apply the new process from the vendor and overwrite your own.

In other words, you have to compare the two systems field by field, line of code by line of code, page by page... ... and that's just the analysis part. You also have to implement your intended changes, which requires great documentation, an alert technical team and a back up environment, in case you run the wrong script.

Then you have to TEST the application. Of course, the vendor tested the new version but you're no longer on that version because you changed it. You have to make sure the changes you made still support your business requirements before the extremely tense moment when you cut over to production.

(Not to be a killjoy but depending on how long that all took, the vendor may be releasing a new version right about now.)

With a SaaS solution you don't need to do any of this for two reasons:

1. You don't customize SaaS solutions, you configure them, which means you change processes by adding data rather than changing the structure of the application. Since all customers are on the same version, the same update process works for everyone.
2. SaaS solutions are hosted, which means the vendor manages the software and technical infrastructure for the customer. SaaS vendors apply the changes needed for the new version centrally without disrupting customer business.

Aside from the obvious cost savings associated with supporting a single version of software and sharing technical resourses, SaaS customers save big time by avoiding the upgrade treadmill.

Pretty SaaSy, huh?

'No more upgrades' is just one of the many benefits of SaaS solutions. If you want more information about how SaaS solutions create business value feel free to check out this white paper on 'Real SaaS' I co-authored with a colleague.