Well, it’s official – HR technology integration is a must. Your legacy systems just aren’t enough anymore, and working between multiple platforms is likely affecting performance from one department to the next.
Integrating HR technology with your legacy systems could fix so many issues. Plus, you’ll experience more time and money saved, fewer mistakes, improved security, better reporting – the list goes on.
But the process is a huge undertaking, so when taking the leap, you want to make sure things run as smoothly as possible.
Incorporating a high-functioning HR tech solution means nothing if you don’t get the service and support you need to make it work. When researching and choosing a vendor or provider, follow these tips and ask a few key questions to help make your integration a success.
Explore the benefits of integration
First and foremost, we live in a society that expects things to not only happen fast, but instantaneously. Instant messaging, automatic debit, video on demand – you name it.
So, it’s practically assumed that your systems should be able to easily communicate with each other.
Yet, with disparate legacy systems, communication isn’t always so instantaneous or easy. And with each system serving so many purposes and housing so much information, it can be hard to start over.
The quick solution would be to simply enhance your legacy systems, right?
Well, yes and no.
Let’s say your goal is to be able to take a 3,000-employee company, run payroll for every single employee and finish the process in less than 10 minutes. You could enhance your legacy system to accomplish this goal, but the process would be extremely difficult and expensive.
Instead of adding this capability to your legacy system, you can get a new system, integrate it with your legacy system and enjoy a lot more functionality for less money (and fewer hassles).
Understanding the different types of integration
When integrating your legacy systems with HR technology, you can choose a file-based batch integration or a public application programming interface (API) integration. Both allow system integration, but the process is different for each.
File-based batch integration: Many companies use file-based batch integration. This means, a file is created then transferred to another system. That system will import the file and integrate all necessary changes associated with that file.
File-based batch integration is great if your company needs simple, infrequent changes. Plus, it can be implemented quickly, and a high level of technical expertise isn’t required.
There are two integration modes for these files. The first mode is called “full enforce” and the second mode is called “change only.”
- Full-enforce example – Let’s assume you have 2,000 employees. If the file is in full-enforce mode, every time you send the system this file, you will send records for all 2,000 employees as of the time the file was sent. Generally, these files are very large. Each time they’re sent, every bit of employee data has to be included, resulting in longer processing times.
- Change-only example – The change-only file-based batch integration method literally tells the system to only send the changes.
For instance, Lisa gets a promotion. When transferring files, the system will only include her file in the transfer when it shows a change – in this case, her promotion.
Yet, let’s say Bob doesn’t get a promotion and there’s no change in his information. In change-only mode, the system knows not to include Bob’s information when processing data.
As a result, the processing times are much faster in change-only mode, as opposed to full-enforce mode. If it were in full-enforce mode, the system would have processed Bob’s information anyway, making the process a lot longer.
Public API integration: A public application programming interface includes services and mapping capabilities that allow external systems to integrate well with each other. This is ideal for real-time integrations often required by larger businesses, or for any business that wants changes implemented immediately.
In a public API, it’s clearly spelled out how a company can send and receive data, such as employee demographic information, basic pay, etc. Typically, using an API is the best way to integrate systems without running into a lot of the issues.
So, it’s very important for anyone who’s even thinking about integrating systems to know that both sides have some mapping capabilities on top of the public API.
For instance, say you’re using a human capital management (HCM) solution that helps you classify employees, and the full-time classification value is “F” in that system. When processing this record in your system, the employee record classification includes the word “full-time” spelled out completely.
If your system includes a public API, and it receives this “F” from the HCM, it can be mapped to “full-time.” This mapping ability eliminates the need to make any changes to the HCM in order for it to integrate with your system.
Questions to ask when integrating HR technology
When researching and interviewing vendors, it’s essential you determine their technical capabilities as well as the level of service you can expect.
Integrating systems can bring a host of challenges, and you want to be sure the vendor you choose understands and is equipped to meet your company’s specific needs. Asking these specific questions is key.
What type of integration do you support?
Does the vendor support real-time public API-based integration or file-based batch integration? It’s okay for vendors to say they support both or a mix of them. But if they support only full-enforce and file-based, this is a problem since it may lead to processing delays.
How do you secure my data at rest and during transit?
Whether the data is in transit, meaning it’s being transferred from one point to another, over the wire, on the Internet or on the network, you want to be sure the channel it’s moving within is secure and encrypted. The same goes for data at rest, which means the information is simply not moving.
You want your vendor to ensure the content in the file is encrypted so no one can read the file. This is especially important if your integration includes employee information or payroll. These types of files usually contain protected health information, personal identification information and other sensitive data.
That’s why it’s crucial vendors support encryption at rest and during transit.
What are you doing to make sure all my data is secure?
Integration can sometimes lead to less secure information when data moves through various pipelines. The more integration you have to do, and the more data that has to be shared, the more you put your company’s data at risk.
If a vendor cannot explain the full details on how they’re securing integration end points (meaning, where your data ends up), you should be alarmed. All the integration end points must be secured for data at rest and data in transit.
Also, based on the type of integration end point, data can get lost. If vendors don’t take the measures to set up good hosts and good technology, you could have a big issue.
What is the service level agreement regarding processing my data?
It’s common for vendors to say they support real-time processing, but it can often take them a little while to process data. Knowing your service level agreement will allow you to plan effectively.
Make sure your agreement highlights a few key factors, such as:
- Availability – Know the amount of time integration services are accessible to the customer.
- Performance – Get defined metrics around processing of batch information and real-time requests.
- Supportability – Understand the metrics around the time it takes to respond to an issue and general acceptable tolerances for resolution times.
For example, let’s say Michelle has a percentage of her income direct-deposited into a joint account with her boyfriend. At some point, there’s a dispute and Michelle no longer wants that percentage going into their joint account. She submits a request to have 100 percent of her money deposited into her account only, and she submits this change before payroll hits.
If there’s a delay and that money still ends up being deposited into the joint account with her boyfriend, Michelle could potentially take legal action against your company. She could tell a judge she submitted her change to her company, it didn’t happen and her boyfriend received money he shouldn’t have.
This is why you need a very good understanding of the service level agreement, so you can plan for it and communicate it to your team. This way, if the service level agreement spelled out the fact that changes can take a few days, Michelle would have known it was possible her change may not have taken effect in time for payroll.
What will my user interface look like?
While the backend of integration is essential for success, don’t forget the importance of the user interface (UI). You don’t want to have a system where you log in and see a difference in look and feel when you navigate through.
Different systems need to be integrated at a UI level, which will involve sharing stylesheets, etc., appropriately. You want to make sure these kinds of components are accessible and can be shared easily.
Warning signs an HR technology platform won’t integrate well
The vendor tells you they will integrate you directly to their database
For example, you have a pipeline going through your foundation. And now you have a vendor telling you they will connect another extension to that pipeline within your foundation. That’s a very difficult task. And if something goes wrong, it’s extremely expensive to fix.
Also, as a company, you’re bound to change your database multiple times. Whenever that happens, the integration will face lots of issues.
The best thing to hear in this case would be the vendor suggesting they have some form of public API that they have developed for the purposes of integration.
The vendor forces you to use their system values
Let’s say you’re running a regular payroll and your only option is for the pay code to be an “R” value. This means you don’t have a choice to do some sort of mapping.
With a public API, there are capabilities you can build on top of that to allow you to map values and get the systems to talk to each other without massively changing one or the other system. So again, when vendors force you to use a specific value, they’re causing some changes to be done on the system you have today — and that can get pretty expensive.
This may not seem clear initially, but as you “peel the onion,” it can become apparent how costly these things can be. You don’t want to get stuck between two vendors, with one saying they can only take certain values and the other vendor saying they can’t change their system to accommodate the value.
It’s a good idea whenever you’re even considering integration that both systems have some mapping capabilities.
The vendor only supports full-enforce file-based batch integration
If a vendor only supports full-enforce, that means there will be some amount of processing delay. For example, you are running payroll and you have a payroll integration file. It’s a very large file and your direct deposit is tomorrow.
If your processing fails, for whatever reason, reprocessing is also as time-consuming as processing. In a bad system glitch, there’s a likelihood you may miss your direct deposit if you didn’t time these files correctly.
The change-only option is much faster because the system is not processing unnecessary things. Ideally speaking, there are times you’ll need full-enforce and there are times you’ll need change-only. So if a vendor tells you they support some kind of file-based batch integration, it’s a good idea to get support for both.
The vendor oversells the simplicity of the integration
There are usually some extremely basic options available if you just need to load a file within only a few fields. But if you have frequent processes, an oversimplified integration process is not going to meet your needs.
Remember, if you’re really diving into a true integration, nothing is just “point and click.” There’s going to be some effort involved, and it all depends on what you invest.
How to decide which systems to integrate first
For starters, make a priority list and outline the sensitivity of the situation. For example, you may not tackle your performance system first, but if your HR and payroll or time and attendance systems are clunky, you’ll probably want to put those at the top of the list. Then integrate some of the other systems later.
What you don’t want to do is try and integrate too many systems at one time. Because the more you integrate, the more things can go wrong.
Imagine having to know service level agreements for 10 integrations as opposed to two integrations. What’s easier?
Set expectations to minimize surprises
At the end of the day, lots of teams will need to understand and work together when dealing with an integration. The purpose is to benefit your employees and have them understand what they can expect.
To ward off issues before-hand, dive deep into understanding the service level agreement. These agreements help you significantly in the planning stages. Early on, you’ll be able to figure out things like, “Which teams need to work together? Who needs to do step one? When do we do step two?”
In addition, when you understand the service level agreement, you’ll know ahead of time about important factors, such as whether or not changes will be made in real time. This way, you can be far more agile in how you deploy your team, versus being surprised later when finding out processing can take two days to complete.
Want more tips and best practices on HR technology? Download our free e-book: HR technology: How to choose the right platform for your business.