Because I have the fortune or misfortune? To work in technology I sometimes forget that not everyone understands the latest jargon or the benefits that new technology can bring. Particularly in the recruitment space my clients tend to have their skills focused around people not technology but for any recruitment manager the reliance on HR technology seems to be increasing as every year goes by. With this in mind I wanted to post about a software delivery method called ‘Software as a Service’ or SaaS. This is intended to be a ‘Dummies’ guide to SaaS in e-recruitment so apologies to those that already understand it, however to me there seems to be a few interpretations out there as to what it actually is.
So a bit of history first will allow the concept of SaaS to be more easily understood. Traditional HR technology such as the big old ERP solutions, SAP, Oracle etc tended to be (and still tend to be) delivered to the organisation by a local install of the software, local meaning on servers physically located at the clients premises, this ‘on premise’ offering is a pricy method. You have to pay for the software, then you have to pay for technology to host it (computers and big boxes with flashing lights) you then pay to have the solution implemented and then tend to pay ongoing ‘services’ fees, you then have to pay for staff to manage to deployment from a technical point of view (i.e. IT bods) and before you know it your looking at a cost with lots of zeros on the end of it (and I mean a lot). Some software companies saw an emergence of a newer option for delivery (in conjunction with the development of the internet) suggesting that it may be possible to deliver these types of systems over the internet rather than via an internal network, after all the internet is really just millions of smaller networks knitted together.
The advantages of this started to become apparent to the software organisation when they realised that because they were investing in and maintaining the technology required to deliver the service they could provide it at a much reduced cost, effectively splitting up the charges for the hosting and maintenance between their clients. There were other advantages too, they could rectify problems or bugs more efficiently because they could access the systems more readily (i.e. without going onsite) They could manage product development more effectively and financially it made more sense, clients were paying for these services on a monthly basis meaning that forecasting and budgeting was more reliable. This delivery method was known as ‘on demand’ or ‘ASP’ (application service provider), this type of delivery played a major part in the development of web 2.0 (more on that another time)
But this solution / service option wasn’t without its draw backs. Many organisations were running slow internet connections so the applications had to be streamlined with less content to load quicker. Many organisations didn’t give their employees full access to the web so either exceptions had to be made or other options had to be considered. Perhaps the biggest draw back was security (or perceived draw back) the thought of organisations data flying all over the world filled some companies with dread.
This really was the time that the e-recruitment vendors started marketing their solutions. It made sense to marry up the ability to apply via a companies website with a back office system to manage the process. It was a process that hadn’t really been accommodated up to this point, but with this type of delivery method and cost structure I became an easier decision to implement.
But there was and still is one big difference between whats now known as SaaS and what ‘on demand’ is. The ‘On Demand’ model still allowed for the client to introduce a list of customisations that hey wanted to apply to the solution. Generally a supplier would take the list, create a quote and charge the client for the work, which of course is fair. However this kind of went against the easier to manage finance model as lumps of cash were being injected in to the vendors cash flow at various points (not a bad thing you might say). The issue came when these organisations tried to support these implementations. So lets imagine I’m a vendor and I have 5 clients, each client has a system with bespoke functionality or customisations. When any of those organisations call up for support or to request a change on the system the support team have to review the setup, check the version they are operating on and gather additional information, the answer to a specific question could quite easily be different between each client. The process would then be to send the change request, update, edit etc through a ‘help ticket’ type system generally for a developer to pick up and make the changes to the source code. Now imagine I don’t have 5 clients I have 50 or 100 or 500 just think about how you would need to scale that support function and that development function and the knock on effect it has on product development and other areas of the vendors organisation.
This formed one of the main reasons for the creation of SaaS. Clever companies realised that in-order to be able to stay true to the ability to provide a service through the internet they had to be able to manage the ‘service’ side more effectively. The even’ cleverer’ companies realised that the only way they could do this would be to create a system that could meet the requirements of the client through configuration and on a single source code (unlike the ASP and On demand vendors that branch the source code). This would mean that their support teams would know what the basis of the system was and would instantly have a view of how the system had been configured. Knock on effect being a much faster resolution to change requests (Even live changes over the phone) a better customer service experience and a more predictable cost model, scalable based on number of clients rather than on clients specific requirements. It also means that system development is more streamlined, allowing new features and functions to be rolled out over the entire client base.
So there are benefits for both the client and for the vendor, I have outlined them below:
- Reduced Monthly Fees
- Superior customer support
- Development of new features delivered at no cost
- Easier budget management – Fixed monthly cost, no costly development projects
- Quicker issue and change resolution
- Quicker and more cost effective implementation
- Better training
- Increased user adoption (due to training)
- Best Practice advice from client base
- Better level of system security
- A more reliable speed and delivery
- Easier to manage support
- Streamlined and speedy development
- Better financial and budget management
- Expandable model
- Better client retention
So thats really the background of where, why and how SaaS has developed. So why does it lend itself so well to recruitment? Well its a case of looking at process. Some of you may know one of the most successful SaaS vendors is called Salesforce.com who provide a sales process automation solution. In the same way as recruitment, sales process is pretty similar across organisations, with a beginning middle and end. Recruitment is similar, create a vacancy, review candidates, hire candidate(s) etc and although there are probably different internal stages the main process is the same in most organisations. This is the reason why a SaaS based solution works so well for recruitment, the core of the process exists in the system and the other elements can easily be configured to meet the specifics of the organisations nuances.
And thats it! Once again a target of doing a one page summary has spilled into 3 pages, but hopefully the content is worthwhile.