Demystifying SAP payroll parallel testing

Parallel testing is a popular and effective methodology for simulating production processes and transactions in a very controlled manner to determine whether systems are working well before a new approach goes “live.” It is generally used for systems that handle large volumes of real-time transactions, and, therefore, SAP Payroll Parallel Testing is a very useful and effective application of the methodology.

In such cases, testers use past pay period data for which a legacy production payroll run has already been executed to run the test. The SAP test payroll is simulated for the same period in order to replicate production results. There does not, however, have to be an exact match between results as long as the differences between the legacy and new SAP payroll results can be explained appropriately.

Demystifying SAP Payroll Parallel Testing

Because it is perhaps the most complex of parallel testing processes, SAP Payroll Parallel Testing (PPT) often is subjected to a number of myths and misconceptions. Just to set the record straight, following are a few such inaccurate perceptions about this important process:

 PPT is NOT…

• Running two systems in parallel for the current period
• Matching the total number of line items in the remuneration statements of the selected employees between legacy and SAP systems
• Believing the legacy payroll system calculation is always accurate as it is the production system today and that legacy payroll results must be completely matched by the SAP payroll system
• Accepting that the PPT methodology is used to identify and resolve defects only in a payroll system.
  

Just as in SAP HCM, SAP PPT implementations conduct Unit Tests, String Tests, and Integration Tests to validate systems build around business processes. But specifically for payroll, there is an additional test – the parallel test – to weigh-in legacy production payroll results and to compare with SAP payroll results—for matches or differences. The components that go into the calculation of payroll results are not limited to payroll data. Instead, they might include employee master data, time entry, earnings and deductions, YTD results, etc. In order to produce good payroll results, all the input components need to be error-free as well. If not, defects found through SAP PPT will not necessarily be specific to the payroll system alone.

Scheduling is a major challenge

The biggest challenge faced by SAP PPT is a tight schedule. This is accentuated when, as often happens, the strategy and tools are developed too close to execution and there is a lack of dedicated resources in terms of technology, people, and logistics. Moreover, SAP PPT is often conducted without a solid analysis framework, which only leads to confusion and insufficient analysis. In addition, inadequate reporting can cause anxiety and confusion among important stakeholders in the SAP PPT process.

To mitigate these challenges, we recommend that SAP PPT preparation begin early in the build phase and that there is a open discussion, prioritization, and documentation of the strategy, primary objectives (such as validation of HR configuration, validation of payroll RICEWF, ensuring it passes stress tests, identifying and resolving defects), and secondary objectives (such as finance, accounts payable and third-party posting), and communications with important stakeholders.

Since testing results are only as good as the data being tested, the periods to be simulated need to be carefully chosen. Month-end, and critical periods for the given industry (such as a storm scenario for a utility company) should be included. A comfortable number of cycles to cover the various possibilities for unique payroll scenarios should be agreed.

The next question becomes: what percentage of the employee population should be taken for the payroll parallel test? Since using 100 percentage of the employee base is not always realistic, parallel testing requires use of an effective representative sample of employee data. In addition to a well-rounded sample of employee types and levels, you will want to have a good sample for testing specific scenarios, as well as FLSA calculation, and calculation of payroll results before and after military leave, etc.

What type of testing tool to use?

Another very important step in preparing for SAP PPT is to identify the testing tool that will be used. There are mainly two types of payroll comparison tools that can be used to automate the comparison between the legacy system and the SAP system. The first type is ABAP-based payroll compare tools, which are developed to run directly on your SAP system, and database tools. While ABAP tools are very powerful for payroll compare during upgrade type projects, our experience indicates that database tools are more flexible, user-friendly, and can more easily enable 100 percent-population comparisons for new implementations. Deloitte has used our experience, knowledge and skills to develop a SQL Server- based tool that has enabled us to help multiple clients in their efforts to quickly and efficiently execute payroll parallel tests. No matter what type of tool is used, it is very important that the tool be identified, developed (if necessary), and tested prior to your parallel testing cycle.

Since it is not possible to analyze every single employee for every single wage type individually; it is important to strategize how to stagger analysis over the period of parallel testing. Threshold limit and tolerance levels are important items to discuss with the stakeholders.

Before beginning SAP PPT, it’s important to meet entrance criteria, which contribute directly to minimizing defects:

• All relevant clients should have been built and should be operational. Additionally, payroll-specific roles should be finalized.
• The execution client should be stable. A disaster-recovery plan should be in place for the execution client.
• Data cleanliness steps should be executed and audited.
• All relevant HR master data should be converted and audited successfully.
• All data maintenance activities should be completed and the documented procedure repeatable for each cycle.
• Time data and YTD data translations should be executed and audited successfully. Wage type limits for YTD data should be audited successfully during the translation process.
• Physical testing locations should be allocated and readied with infrastructure requirements. Additionally, teams should be formed, communicated, and ready to perform their testing roles.

Defining the phases of SAP PPT

There are four phases in SAP PPT, within which there are two types of approaches: Phase I, which is one-time SAP client-building and historical master data conversion; and Phase 2-4, which are repeated for each payroll cycle.  These are described in detail below.

Phase 1: Technical Build and HR Historical Master Data Conversion
From the perspective of risk management and testing efficiency, it is more effective to get three dedicated clients within the QA box. The first golden client (GC1) is built with all necessary configuration and FI & AP master data such as Cost Centers, GL accounts etc. The second golden (GC2) client has the HR historical Master Data and YTD results in addition to the FI & AP data. The executable client can be built from GC2 very quickly without wasting time and involving FI & AP teams. Similarly, GC2 can quickly be recovered from GC1. The third client (GC3) is the executable client. One specific conversion strategy to be kept in mind is that not all HR Master Data needs to be converted as they do not contribute in payroll processing.

Phase 2: Pay per Period Conversion
Often, testers forget to baseline the converted HR master data.  This can result in an incorrect payroll calculation.
Something else to keep in mind for this phase is that there is no need to test the process of time data entry from ESS to time infotypes, as you are executing a payroll parallel test and not performing an integration test. Consequently, loading time data directly into infotype 2001 & 2002, etc., would suffice.

Phase 3: Processing
Time evaluation and payroll run are processed for a predetermined payroll period. Background processing is ideal to also perform a stress test. There should be agreed upon threshold limits and tolerance levels to measure the outputs from this phase.

Phase 4: Analysis and Reporting
Analysis should not be done ad hoc, instead it should follow the following conceptual framework – analyze gross, analyze pre-tax deductions, analyze tax deductions, and analyze other deductions. It is important to follow this framework instead of spending a lot of time analyzing every bucket for all employees – if the gross doesn’t match, then the base for pre-tax deductions will most likely not match, neither will taxes, nor will the net. It is important to document exact matches, known differences, acceptable differences, and unacceptable differences in this phase.

Just as it’s important to meet entrance criteria, it is important to meet exit criteria as testing comes to an end:

• All exact matches are documented
• Explanations for known differences are documented and signed off on
• Cycle-specific acceptable differences are documented and signed off on
• Defects that were created for unacceptable differences have either been resolved or have a clearly laid out plan to get resolved and are signed off on as work in progress
• Previous cycles were signed off on

The exit criteria are absolutely critical for the project team to demonstrate why the testing cycle should be signed-off. These criteria also are subject to the threshold limit and tolerance level measuring. Since it is not practical to analyze every possible wage type for every employee in the test scope, adhering to the threshold limit and tolerance level will help get the test cycle signed off.

Business process owners find it clear and logical to sign-off on a test cycle when the expectation on the cycle results are realistic and achieved as stated. Explicit exit criteria help us address this.

Remember, a 100 percent match is not the objective. Exit criteria can help measure the results and provide an understanding of differences that you would face.

Summary

In closing, be proactive about starting payroll parallel strategy discussions and documentation early on in the desired timeframe for the testing. Be sure to discuss and agree test objectives, as well as scope, and then manage expectations around them. The quality of the prediction of a company’s future payroll is highly dependent on the quality of the representative test population used. As testing progresses, discuss and finalize test periods and capture legacy data in a timely fashion. Always be aware that test results are only as good as the data quality put in to the capturing, extracting, mapping, translating, and loading of the SAP system. And don’t analyze test results in an ad hoc manner; instead, always use the conceptual framework and strictly adhere to the entrance and exit criteria

Related Content:
Overview: DC HCM Newsletter: Summer 2009
Overview: Human Capital
Alliances: SAP

This publication contains general information only and is based on the experiences and research of Deloitte practitioners. Deloitte is not, by means of this publication, rendering business, financial, investment, or other professional advice or services. This publication is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor. Deloitte, its affiliates, and related entities shall not be responsible for any loss sustained by any person who relies on this publication.

As used in this document, “Deloitte” means Deloitte Consulting LLP, a subsidiary of Deloitte LLP.  Please see www.deloitte.com/us/about for a detailed description of the legal structure of Deloitte LLP and its subsidiaries.