Decoding the World of SaaS for HCM

SaaS ( Software as a Service) as a concept originated sometime in 1999 when organizations first allowed hosted services to be adopted. Since then this concept has grown leaps and bounds. I would like to investigate here, from a SaaS vendor perspective and customer perspective whats the reason for this hype and how real is the result of this,

First from a vendor perspective.
The key characteristics of SaaS software, according to IDC,
1. network-based access to, and management of, commercially available software
2. activities that are managed from central locations rather than at each customer's site, enabling customers to access applications remotely via the Web
3. application delivery that typically is cloHCMser to a one-to-many model (single instance, multi-tenant architecture) than to a one-to-one model, including architecture, pricing, partnering, and management characteristics
4. centralized feature updating, which obviates the need for downloadable patches and upgrades.
SaaS applications are generally priced on a per-user basis, sometimes with a relatively small minimum number of users and often with additional fees for extra bandwidth and storage. SaaS revenue streams to the vendor are therefore lower initially than traditional software license fees, but are also recurring, and therefore viewed as more predictable, much like maintenance fees for licensed software.

SaaS implementation can happen at the following four levels.
Level 1 - Ad-Hoc/Custom: At the first level of maturity, each customer has its own customized version of the hosted application and runs its own instance of the application on the host's servers. Migrating a traditional non-networked or client-server application to this level of SaaS typically requires the least development effort and reduces operating costs by consolidating server hardware and administration.
Level 2 - Configurable: The second maturity level provides greater program flexibility through configurable metadata, so that many customers can use separate instances of the same application code. This allows the vendor to meet the different needs of each customer through detailed configuration options, while simplifying maintenance and updating of a common code base.
Level 3 - Configurable, Multi-Tenant-Efficient: The third maturity level adds multi-tenancy to the second level, so that a single program instance serves all customers. This approach enables more efficient use of server resources without any apparent difference to the end user, but ultimately is limited in its scalability.
Level 4 - Scalable, Configurable, Multi-Tenant-Efficient: At the fourth and final SaaS maturity level, scalability is added through a multitier architecture supporting a load-balanced farm of identical application instances, running on a variable number of servers. The system's capacity can be increased or decreased to match demand by adding or removing servers, without the need for any further alteration of application software architecture.

From a customer perspective now
SaaS is based upon the assumption that the services provided are commonplace and well defined, hence economies of scale and balancing of supply and demand becomes possible. This assumption holds true for those areas of IT that are ubiquitous, a cost of doing business and commodity-like. SaaS is therefore not suitable for innovative or highly specialized niche systems, though SaaS may be used to provide one or more components in such systems.

However there are lots of areas which need to be addressed, which need to be sorted out.
1. SLA Definition and articulation - SLA's need to be in sync with the customer business objectives. SLA should be tangible, measurable and defined.

2. Identification of the right system - Right system is scalable, web based and easily configurable.

3. Identification of the right service provider - Localized support, quality of resources.

4. Definition of a roadmap - Roadmap for adopting the solution. Phased interms of solution footprint, phases.

With this in place, organizations can look at adopting solutions that not only free them from the transaction burden of managing the solution.
Over the next few blogposts, I would also be covering other business models and their viability.