Importance of Parallel Payroll processing

Payroll – heart of an HCM Implementation

No one likes to see that their paycheck has been totally messed up after a new SAP HCM system has been rolled out in their company.

The other parts – the nice portal, the self-service, the workflows, etc. – are good but getting it right on payroll is a must. More importantly, it is absolutely vital to compare simulated paychecks from the “To-Be” futuristic system with the current “Legacy” system as part of the integration testing cycles. When this has to be done for a large, complex HR system with hundreds of interfaces going in and out of the legacy applications, the testing has to be strategized and thought-through well in advance. IT and Business need to work very closely in defining the testing approach months ahead so proper preparation can be made.

In this document, I will discuss about how Parallel Payroll Testing should be approached for large enterprises with a complicated legacy HR system planning to transition over to a new SAP HCM system irrespective of whether the new system is on-premise or in the ethereal world of cloud computing.

When to perform the Parallel Payroll Testing

1. Unit Testing: Individual components need to be unit tested within the logical boundary
   • Workforce Administration
   • Payroll
   • Time Management (internal or external)
   • Front-ends – portals, custom screens, etc.
   • Nice areas like Pensions, etc.

1. System Integration Testing: End-to-end business scenarios from Hire to Retire

1. Performance and Stress Testing: Volume testing with at least equal to or more than production load at high concurrency

1. User Acceptance Testing: Business executes end to end scenarios with controlled data – IT supports

1. e. Parallel Payroll Testing

1. Production Validation / Smoke Testing: On night of deployment

(see Test Flow Diagram for overall flow)

More on Systems Integration testing

This section describes the testing strategy for integrated applications. In this phase, all the systems will be integrated with each other, considered as a single big system and test the end to end process or data flows between different applications involved. Integrated applications testing will include different test phases – Systems Integration Testing, Performance Testing, User acceptance Testing and Parallel Payroll Testing.  The Cutover Testing should be a check point to test production environment readiness along with its required components before going live. Listed below are the different test phases applicable to these applications.  This testing cannot be started until the Unit testing and System testing phases are successfully completed and all major issues or defect are successfully fixed and tested.

Systems integration testing should be performed in a controlled QA environment where Master Data has been pre-loaded as provided by the HR business leads. The objective of the systems integration testing is to verify the end-to-end process integration between SAP cores HCM (WFA & Payroll & Portal) along with all external systems.

1. A. Test Cycles

• First cycle: This will follow incremental integration approach, the modules in which all the customer specific customizations and configurations are completed and the modules have successfully completed unit testing and system testing will be integrated with each other and the external applications and tested as a single system. End to end testing will be performed, testing of all business scenarios without any security roles associated in this cycle to check how the system is behaving without security and raising defects.

• Second cycle: End-to-end testing will be performed where external systems are also linked to the core HCM system. For example, Hire a new employee in SAP HR à check whether employee details are updated in different systems like Payroll, Time Management, Clock systems, etc. Another example might be hours swiped from external clocks, [employee IN time and OUT time] à check if these hours were passed to the Time Calculation module for calculating work and non-work hours, whether calculated hours were sent to Payroll system for pay calculations etc.) All business scenarios are tested with all associated security roles and the corresponding defects are identified and recorded. This cycle will follow big bang approach; all the modules in scope of the project should be integrated and tested as a single system. Defects, if any, will be raised and tracked till closure.

• Third cycle: Testing will ensure that all high and medium priority defects identified in the previous cycles are fixed and that critical business scenarios are tested with security roles associated. This cycle will also ensure that all the externally integrated applications work flawlessly when integrated with the core SAP HCM modules. All the defects identified need to be fixed, retested and closed for successful completion of SIT. This cycle will be tested with all security roles are switched on.

1. B.      External applications

• Systems integration test inventory should be developed based on the business test scenarios and external system dependency.

• The project testing team should execute the system test inventory. All high and medium severity defects will be fixed, retested, regression tested, and closed. In situations where there are test cases that cannot be tested, appropriate reasons will be provided and the test cases will be marked as deferred/not tested.

• Systems integration test phase is dependent on external systems. Hence, the project testing team will not be able to progress with this phase of testing if the external systems are not ready by this time.

• All defects identified need to be fixed, retested and closed for successful completion of SIT.

1. C.      Fundamentals

• Business owners should provide the business test scenarios.

• A systems integration test inventory will be developed based on the business test scenarios and reviewed by the business owners.

• The project test team will execute the systems integration test inventory and identify defects, if any, during testing. All high and medium priority defects will be fixed, retested, regression tested, and closed. In situations where there are test cases that cannot be tested, appropriate reasons will be provided and the test cases will be marked as deferred/not tested.

• The systems integration test phase is dependent on external systems. Hence, all external systems should be ready before SIT is initiated.

• The project test team will validate whether all business processes applications and components meet both functional and operational requirements, as specified in the requirements and design documents.

• SIT will ensure that the inbound and outbound data flow between different systems (HR – PY, HR – external Time Management system, HR – Interface Systems such as Clocks, employment verification, etc.) is suitably implemented.

• Test inventory should be prepared every functional component defined by scenarios. 

Parallel Payroll Runs – Approach

Parallel Payroll Testing is used to determine that the results of SAP Payroll and the legacy applications are same. This testing required for two applications, i.e. Legacy + external applications and SAP Payroll + external applications – to compare one to one results on both systems. 

• The QA environment should be refreshed and loaded with latest production data for this testing.

• Run a simulation run to check whether the master data has been loaded correctly, test for roadblocks, and resolve them before the actual parallel run scheduled.

• Obtain the YTD converted data from the legacy system, do the sanity check, fix any data issues.

• SAP system should be loaded with transactional data from the legacy system for all active employees and inactive employees who had latest termination and sanity check should be performed.

• Execute different payroll frequencies (Weekly / Semi-Monthly / Monthly) using the payroll transactional data on the actual dates of pay cycles
• Verify master data and payroll YTD conversion
• Compare the results of SAP payroll with legacy system
• Resolve the exceptions and perform root cause analysis
• Get an agreement with a project and service delivery / operations team if the exceptions are correct, and get the sign-off
• Fix the discrepancies if any with SAP payroll system
• Re-run the next parallel run

• Compare payroll results on SAP Payroll and WPR systems for
• Build-to-Gross: compute gross pay/earnings
• Gross-to-Net: compute taxes, benefits, pensions, other earnings, and deductions.
• Post-Payroll Activities: generate Payroll/Finance files, Operational/ Statutory and Tax reports, Tax deposits/Returns, Electronic bank transfers, and so on
• Compare the above results against the legacy results
• Compare the pension and benefit calculations against the legacy system
• Year-end reports (W2) should comprise the same details
• Tax withholding calculations will be done going forward
• In case of deviations that cannot be justified, governance for checking the results against external tools (e.g.www.paycheckcity.com) can be used for further analysis and resolution.

• Minimize parallel payroll exceptions between SAP Payroll and legacy system with consecutive parallel runs until the exceptions reach a predefined target or until all known differences have been identified

• The high level test approach for Parallel testing is given in the table below

Parallel Payroll Runs – Nuances