One of the biggest limitations preventing companies with an in-house HCM system (e.g. Oracle, PeopleSoft, SAP, Lawson) from moving to a SaaS HCM system is customizations. Many companies have made significant customizations to their HR system and are not willing to let go of these customizations. I don’t want to get into a discussion of why so many companies customize their in-house systems. That will have to be another blog post.
SaaS applications built from the ground up to handle customizations as configurations would rock.
Application development technology has matured to the point of being able to create a rich User Interface experience that would allow the client to easily make modifications to the UI to suit their needs. HR and to a lesser extent Talent Management applications have been around for decades and we now have a pretty good idea of what companies are looking for in HCM systems. Business Rules need to be extracted where possible from the underlying code and elevated to a place in the application where the customer can modify the Business Rules as a configuration step and not as a customization request.
Similarly the User Interface needs to be a separate layer with a similar capability to easily add/remove or move a field on a page as a configuration step and not as a customization request.
An uber configurable HR SaaS Application has the potential for convincing a larger number of companies to give SaaS a second look.
{ 3 comments… read them below or add one }
Michael,
I love the line “SaaS applications built from the ground up to handle customizations as configurations would rock.”
We have a debate in the office about what you view as “configurable” within the application. Is it the reporting, the data sharing to other applications, other, both, none of the above? Can you take this one line and expand upon it?
Thanks
Chuck Gillespie
twitter: crgillespie
chuck@dealerflow.com
I’m happy to clarify Chuck.
In today’s on-premise HCM systems, you usually have to apply customizations if you want the application to behave differently than delivered by the vendor. If want to add/delete/move a field from a page you have to customize the code surrounding that page. If you want to add/delete/modify business logic, you typically have to change the source code of the application. Modifying workflow rules (more often than not) also require changing the application source code. Creating new interfaces are another area that usually requires writing new code.
SaaS Vendors do not usually offer the customer the ability to make code changes by themselves and frown on making code changes on behalf of the customer. However, many customers often find themselves unable to move to a SaaS application when a FIT/GAP analysis shows too many gaps with the SaaS application and the inability to customize the SaaS application to meet the customer’s needs.
So, what if the SaaS application was built from the ground up with the ability (built-in) to the application to allow the customer to make changes to the application to meet their unique business needs without those changes affecting the actual source code or underlying business logic of the application? What if you could navigate to a configuration page in the application and add/delete/move a field from a page, add/delete/modify business logic or workflow rules? What if you could create new interfaces without having to pay for the SaaS vendor to create them for you?
I would think this type of configurable (instead of customizable) SaaS application would appeal to many many businesses.
Thanks Michael. I was hoping that is what you meant. All the best.
Chuck