There are many common questions about features and functionality to ask when evaluating HRMS applications, but...
there are also questions that may not be obvious at first glance. Asking these less obvious questions can help ensure you meet local privacy laws and internal policies, can help protect you from unexpected costs and can validate that an HRMS system can be implemented within your preferred time frame.
Consider asking the following questions when choosing between HRMS vendors.
Where will the data be stored?
An important question to ask is where the data will be stored. This can help you remain compliant with local laws and internal policies.
For example, privacy laws may restrict where data can be stored. Also, in certain countries, it is easier for law enforcement to access employee data without informing companies.
Finally, each organization may have policies on handling and storing employee data that must be considered before procuring software.
When can the implementation begin?
Before signing a contract, it is important to ask when the project will kick off. While a vendor may not be able to give an exact date, it should be able to provide an approximate time frame. This is important for a few reasons.
First, you will want to make sure you are ready for the implementation. You may have to assemble a team and ensure they are available. You may also have tasks to perform before the project starts, such as reviewing and updating policies and processes and cleaning data. Additionally, other projects that are underway may compete for resources. Many organizations do not effectively scope out the time and resources needed to carry out projects.
Second, the vendor could have a large backlog of implementations, which can lead to long delays before starting your project. It is reasonable to expect a delay of a month or two between signing a contract and starting a project, as the vendor's employees will likely have to complete existing work before being assigned to your project. However, some vendors have eight to 10-month delays that might eliminate them from consideration if, for example, you are using an application that will no longer be supported in six months.
Who determines when upgrades are applied to your HRMS environment?
With cloud-based software, the vendor often controls all the updates to the codebase. This simplifies the process for the vendor and makes it easier to support the application, as all of the vendor's customers use one codebase.
The downside is that the software updates may take place at critical times in your internal cycle when you don't want to introduce risks. If the vendor performs all the updates, make sure there is a published schedule for the next six to 12 months so you can build your own schedule around them.
Was the application built internally or by acquisition?
Applications built from the ground up should have a consistent look and feel, one security model, and one central database. This can not only help employees learn how to use the application, but it can also make the system easier to administer. For example, it's less likely you will need to interface between applications; the forms used to configure and maintain the system will probably be more consistent; and, with one database, reporting across modules may be easier.
When the application is built via acquisitions, there may be multiple databases that require integration to keep information consistent across modules. Also, the look and feel will almost certainly be different between modules, as will the security model, the administration forms and the help system. While not a showstopper on its own, this is something to consider.
Does the contract include a test environment, and does it cost money to sync it to production?
Having a test environment in which you can experiment with changes without affecting the live system is very important. HRMS vendors will often update the test environment before updating the production system, which offers you the opportunity to confirm the update hasn't broken any existing functions and to review the new features you may want to implement.
Another question to ask is how you sync the test environment with production data. Over time, the test environment will become out of date, and to truly test a major change before moving it to production, you will want to ensure the two environments are similar.
When evaluating HRMS vendors, ask if they offer a test environment, what the process is for updating it with production data and any associated costs.
Where is the implementation team located, and will that affect work hours?
Many HRMS vendors have employees around the world working in remote offices or from home. This isn't of great concern on its own, but you should understand the technology they will use to communicate with you if they are remote, and you should know their standard hours of work. At a minimum, you want sufficient overlap in your daily working hours to hold regular and ad hoc meetings without having to adjust your work hours.
Is there an additional charge to access vendor training?
Many HRMS vendors require you to pay for access to their training sites, which may include instruction manuals and training videos. However, not all vendors charge for this. Some realize that for you to be successful, you need to learn how to use the system and be able to train others.
While free training material is ideal, it should be secondary to your other requirements, as it is often inexpensive and may not even be necessary within a year.
What are the technical support processes and response times?
Technical support is your lifeline shortly after go-live when the implementation team moves onto its next customer. It's important to ask questions about the support you will receive post-implementation, such as hours of operation, expected response and update times, and options for logging and updating support tickets.
You may also want to ask if the vendor has a customer portal that allows customers to interact with one another. In some cases, such a portal can get you a quicker response than logging a ticket with technical support.
Failing to account for these requirements early on can lead to significant challenges.