4 definitions to understand before producing an HRMS RFP
Like any other specialist group, HRMS vendors have their own language and jargon, and otherwise familiar words may have unfamiliar (or certainly more narrow) meanings, depending on the context. From the point of view of preparing your HRMS RFP, it’s worth being aware of the basic vocabulary so that if you use any of these words in the document then at least you’re doing so knowing what the interpretation might or will be.
You might talk about how many people in your organisation will be using the HRMS, but “user” can have a variable meaning to vendors. This is a critical point because often the licensing cost of the system is linked to the number of users and you at least want to be dealing in the same figures when it comes to cost.
Recommended reading: HRMS selection survival guide - 7 steps to success
Different levels of “user” can be: someone with permission to log in and access (and update) their own personal data (quite possibly, every employee); or someone able to both access and manipulate the system’s data (e.g. managers, although there will different levels of access within this, such as team, department, corporate/strategic); or someone with specialist access (such as HR administrators); or someone with system access, able to tweak and amend functionality (e.g. members of your in-house IT team)… And what about having some generic “user” accounts for access to non-personal functions that you can recycle as your contingent workforce turns over? As you can see, “User” is not a one-size-fits-all term.
It’s important to give vendors an idea of your planned timescale for implementation in your HRMS RFP and the tendency is to focus on the go-live date. But what is that, exactly? Surely it’s the day you switch the system on? But what if you’re planning a staged implementation, with just 10-20% of your workforce given access initially, and the full workforce not online for another few months? Which date is “go-live”? understanding this definition is especially important if “go-live” ends up linked to the date you start paying the vendor.
“HRMS vendors have their own language and jargon, and otherwise familiar words may have unfamiliar (or certainly more narrow) meanings”
The cloud is increasingly prevalent as a platform to store your HR data, rapidly outpacing the traditional on-premises installation with its extensive hardware requirements and maintenance headaches. You may wish to specify a hosting preference in your HRMS RFP, but in that case you need to bear in mind that with off-premises hosting, the exact whereabouts of your data (geographically speaking) can be a little vague. It’s a popular model for vendors to rent data storage space in an independent data center which could be anywhere in the world. If you’re likely to go this route, at least lay out in your RFP requirements the need to know who will have your data and that they have the necessary recommended security certifications.
Finally, you may want to stipulate a standard for uptime in the RFP (it will certainly feature in the service level agreement you negotiate with your chosen vendor) but what exactly does ‘uptime’ mean? Does it include scheduled maintenance? Does it meet with your needs in terms of providing access to your HR data? What compensation do you expect if the vendor (or the data center) fails to meet the agreed uptime standard?
Can you find a suitable HRMS without relying on RFPs?
HRMS RFPs are cumbersome and time-consuming. Here are some alternative approaches to try
How detailed should my HRMS requirements checklist be?
How to draw up an HRMS requirements checklist with just the right amount of detail for good vendo...
What to look for in a standout HRMS RFP response
Creating a good HRMS RFP is one thing, but how do you recognize good vendor responses?