The world of Cloud means more integrations, not less.
Cloud HR is a world of big data and open technology, which means new opportunities to connect more solutions, and to create better and further reaching processes that impact our employees. It’s not about starters, movers and leavers—it’s about having a one-stop-shop where your people can manage different aspects of their lives.
Integration of data and processes is an opportunity to achieve the very best for your employees when it comes managing, developing and engaging with your staff. However, pulling all the data and applications together is a challenging undertaking. Many of us have been led to believe that it’s just a matter of ‘plug and play,’ but don’t be fooled! When implementing a new HR system, there are several integration requirements that you need to be aware of before starting.
Why should integration requirements be defined early?
The increase in integration opportunities is one reason why you should define requirements in advance of your cloud HR implementation, but there are a few more reasons.
1 - Time
Integrations are often red on the RAG status due to dependencies on resources that are outside of the control of the main project team. Interfaces will often be delivered by external 3rd parties or an internal IT team which may already be stretched. If these resources are not engaged before the project starts, it is unlikely the implementation team will be able to deliver to the timescales of the project.
2 - Change in roles
New interfaces often mean manual work gets removed. But somebody may be doing that manual work today, in which case they have just had a portion of their role removed. This needs to be covered off before the design phase of an HR project, as you do not want a key stakeholder supporting the design phase, only to find out during a workshop that an interface has removed a chunk of their existing work.
3 - Design decisions
Knowing some of the key limitations of other systems may influence design decisions. It is better to know these limitations (e.g. data formats) before the design phase starts, so you can mitigate the risk of key interfaces not working. Some systems have ‘non-negotiable’ data formats, and knowing these early will save headaches down the line.
Examples of cloud HR integration requirements
Example 1: Payroll
One of the biggest headaches in the cloud HR integration space must surely be payroll. In many companies, HR data is held in one system, and pay is processed in another. This is because payroll requirements can be very specific with many variations of codes and calculations that may not work well in the HR system, especially when an organisation operates on a global scale.
Another reason for this separation could be that businesses have decided to outsource their payroll operations to a 3rd party vendor and therefore do not need payroll functionality in-house. Yet another possibility may be that payroll is owned by Finance, and their system of choice is different from the HR system of choice. Whatever the reason for having separate payroll and HR systems is, it is imperative that you know how each system is going to talk to each other before you start your HR project.
Some fundamental decisions to make upfront (in this example):
What is the boundary between the data you hold in HR and the data you want to hold in payroll?
If HR is the master and payroll the slave, will you disable edit function from local payrolls?
Do you want to hold all the information that forms part of a contract of employment (base salary, bonus eligibility, pension information, benefits, etc.) in HR? If so, is this true of all geographies or the larger regions only?
Do you need data to come back from payroll and into HR? If so, what data and how often?
How / where will the employee view compensation information, be that salary, bonus or other elements of total compensation?
Example 2: Business intelligence
Another good example where defining cloud HR integration requirements proves necessary is integrations to business intelligence. What often causes delay and frustration with BI is not the sending of physical data to the BI tool, nor the building of the report. The hard part is agreeing definitions. For example, absence. If you have employees on different T’s and C’s, it may be that the definition of a working day is defined differently for each; therefore, a half day will also be different. Agreeing upfront some core definitions will help with any interface work, as it means everyone is working to the same meanings and understanding.
Example 3: Employee ID’s
A final watch out… the format of employee ID’s! This is a classic ‘non-negotiable’ in many systems, be they payroll, expenses, travel or benefits. Your pre-cloud implementation activities should include a mapping of all the systems you are linking with and documentation of the Employee ID’s. This way, you will know at the start if you have a major issues and need to make changes.
Good luck defining your cloud HR integration requirements!
By Helen Thiel. For more information about reporting, insight, or implementing Cloud HR technology, please get touch.
Comments