In workforce management, it pays to be careful what you test for, as you may not like what you find.
There are few unsettling moments in projects quite like discovering unexpected issues during testing. When an organisation is automating its payroll calculation, such as the automation of employee pay rules, one of the biggest challenges is to ensure that employee pay and rewards are not impacted when the new system is implemented.
Get the pay wrong and the potential impacts could be disastrous. But what if the pay was wrong in the first place? If your parallel testing delivers a different result to the manual interpretation – and moreover the automation – how do you know which is actually correct?
There are a number of steps that are needed to ensure a successful payroll transformation. One critical step is to plan and conduct a parallel pay run phase to compare the payroll outputs between the old system and the new systems or solutions to ensure there is uniformity.
What is a Payroll Parallel Run?
A payroll parallel run (PPR) is a risk mitigation approach using live data that is extracted from the old system and processed in the new system. The end results from both (e.g. timesheets, pay units and payslips etc) are then compared from both systems to check for a match or for discrepancies.
Testing the Payroll in Parallel: What Steps Need to be Taken?
PPR will only be of value to any business if it compares apples with apples and the primary objectives of the payroll parallel run are clear. We explore below some of the critical steps that warrant careful consideration:
Are you comparing identical pay periods?
It may seem obvious, but it’s vital to ensure that the same pay period is tested in both the old and the new systems. They do not need to be run at the same time, so long as other contributing factors such as historical data and employee pay rules are consistent/identical in both systems. Ideally, to achieve maximum benefit with optimal effort, we recommend that clients conduct the parallel pay run in the new solution within a couple of weeks after finalisation of the production pay run.
Are you comparing the correct data profiles?
It’s a fairly common mistake: when a payroll parallel team doesn’t compare payroll results with consideration of the quality of the data used or hasn’t ensured that all data components (such as historical data, time data, configuration, tables, data mapping etc) are correctly replicated and checked prior to the commencement of a parallel run. One of the major challenges in any large payroll transformation project is keeping data quality and data integrity in sync during the PPR.
The components that go into the calculation of payroll results are not limited to payroll data. Instead, they might include employee person data, historical data (leave balance, ADO etc.) time entry, system data, mapping tables and employee pay rule status and it is critical to have identical data in both systems for comparison.
Are you comparing the results in the correct environment?
One of the myths that the non-production environment, i.e. the technical test environment, is a replica (or apples-to-apples) of the production environment and, as such, will be a walk in the park to carry out the parallel pay run phase. It is not an apples-to-apples comparison if the environment selected for using PPR doesn’t have the exact version of systems or interfaces as the test environment.
Managing the defects you find
It’s very possible that the parallel pay run will open a can of worms on existing broken processes, illegal practices (knowingly or unknowingly) and data quality issues. Usually, these issues are highly sensitive and known to management. The PPR will not only highlight inadequate processes and practices, but can also have the factual information to be able to quantify them in consequential ways.
For that reason, it is essential for a payroll transformation program to prepare a communication and resolution plan for unwanted – or unexpected – findings that result from the PPR.
The Dilemma of Discovery: Where to From Here?
Here is a scenario we’ve seen happen: You’ve taken the time to ensure your parallel test is appropriate but face a serious dilemma: the results show that some staff have been underpaid and some overpaid. You’ve checked and rechecked and have a high degree of confidence in the results. Where to from here?
Much as we’d like to say it ain’t so, this is a scenario that will happen. Why? Because people interpret things differently. Just think about how people respond to emails. The author’s intent and the recipient’s interpretation can be often misaligned. In payroll, automation removes the personal element and produces a consistent approach.
Focus on Benefits Realisation, not Rectification
In our experience, the discovery of over or underpayment isn’t the time to make business decisions about how to treat the issue nor is the discovery of sub-optimal practices that may be revealed during testing. For a successful outcome, policies need to be crafted from the start and engagement with the appropriate stakeholders pursued.
If not, the project may pause or stop dead in its tracks whilst management and others duke it out over policies, which may cause the project to lose momentum and result in time and cost overruns and a delayed benefits realisation.
Want to find out more about managing WFM testing within your workforce? Read our previous articles on WFM or contact our team on 02 9098 6300 to discuss your requirements.