Most people who work with SAP systems are familiar with the testing model necessary to get an enterprise-wide business system up and running. Units of functionality are tested in isolation, and then grouped together by business transactions as functional tests. A string of transactions are run together to test an end-to-end business scenario, and business scenarios are tested with their links to interfaces and external systems as integration tests. Other test phases, for example, user-acceptance testing and stress testing, may also be incorporated. Most ERP modules, however, don’t have a test phase in which direct comparisons are made to the legacy system that is being replaced (Figure 1). This is because the functionality differs so much in terms of scope, process, method, and data that comparisons between the SAP system and the legacy system are impractical.

Figure 1

Typical ERP testing hierarchy

Figurer 2

Payroll testing hierarchy

Consequently the parallel run is an essential part of any payroll implementation. It promotes confidence in the design and configuration of the new payroll system and is usually a key input into the go/no-go decision. Depending on the design and method of the parallel payroll process additional benefits may include:

• Validation of the data migration
• Verification of the full payroll life cycle
• Provision of real data for integration within SAP (e.g., FI/CO) and third-party systems
• Validation of payslips, bank transfer files, and payroll reports
• Opportunities for training the payroll department

The rest of this article gives more detail about how to design a successful parallel run and the key areas of focus.

Parallel Run Steps

It is good practice to carry out parallel runs over multiple payroll periods. It is rarely possible to identify and resolve all configuration and data migration issues in one go; there are normally enough changes to warrant successive parallel runs on fresh data sets. So in general parallel runs will be carried out for two or three different payroll periods.

The basic steps for carrying out a parallel run for one payroll period are shown in Figure 3.

Figure 3

One payroll period’s parallel run steps

Steps 3 to 7 in this sequence are repeated until the success criteria have been met.

Choosing the Parallel Run Periods

A typical payroll month is a good candidate for a parallel run; any month with an annual or periodic business activity which adds complexity is less suitable. For example if a back-dated pay award occurs in July then ideally you wouldn’t want to choose this as your first parallel run month. Things to look out for are:

• Company shutdowns and advance pay runs
• Pay awards (any annual pay increases/pay scale changes, especially if these involve back-dated changes)
• Any significant organization change or mass employee contractual changes

It’s not a case of avoiding these because the payroll system can’t cope, since these items should be tested independently elsewhere. It is simply a recognition that it’s worth minimizing situations that increase the difficulty of the parallel runs without improving the quality. Indeed once suitable parallel run periods have been identified you should also look out for items that aren’t incorporated during the selected period (e.g., bonus runs, public holidays, company days, and share awards). You can then modify the periods chosen or supplement the parallel runs with additional test cases in user-acceptance or integration testing.

Loading Data for Parallel Runs

Parallel runs are normally carried out off-line during periods that have already been paid on the legacy system in order to fit in with the project timelines. For example, a parallel run on April data may take place in August because this is the start of the parallel run phase. A snapshot of HR and payroll data is taken from the legacy payroll system and migrated to the SAP system. Let’s consider two different approaches to how this can be done:

• Full automatic load: All employee HR and payroll data is extracted at the point in time immediately before payroll is run on the legacy system (the payroll run date). This data is loaded into the SAP system using LSMW, batch input session, or any other automated upload method. No manual data entry is required; however, changes to payroll data which took place over the course of the payroll period may be missed. For example, an employee who has a salary increase at some point in the parallel run month may be loaded with either their original or their increased salary only, depending on whether the change is effective from before or after the date used for extraction. An employee who left the company partway through a month may be missed since they were not active at the point the extracts were run. Consequently some additional method is required to pick up relevant transactional changes that took place during the payroll period.
• Dual data entry: All basic employee data is extracted and loaded at the start of the payroll period. Any transactional data (e.g., changes to pay and deductions, tax codes, and new hires) is loaded manually into SAP via direct entry of information by the payroll department. There is a dual entry of data — all data input on the legacy system is mirrored on the SAP system. Although this can be labor intensive, this mechanism captures the most errors as both the system and some SAP processes and transactions are tested. Practical methods of ensuring that data is entered equivalently on both systems must be devised.
• Hybrid or mixed approaches are also possible

Other key factors to consider are the technical capabilities of the legacy system, and whether the IT or payroll team have the technical ability and resources to extract this data. It’s also worth pointing out that many payroll systems do not have the ability to take snapshots retrospectively — they are only able to produce a valid set of live data at the date of extraction. If this is the case then, if possible, take a full copy of the legacy payroll database for each parallel run and store it until required. If it’s not possible to store a copy of the legacy payroll database then the data must be extracted (e.g., into a set of spreadsheets) at the time the payroll was run on the legacy system. The exact choice depends on the technical capabilities of the legacy system, cost, and legacy payroll resource availability. The potential pitfall with the second option is that if any legacy extract is missed, lost, becomes corrupted, or is later discovered to be defective then it may be impossible to recreate that data on the SAP system, which may jeopardize the parallel run.

Employee Populations

The employee population that is tested in each phase of the parallel run needs to be determined. It’s possible to parallel run all employees, to choose a subset of employees randomly, to choose a subset according to business scenario (e.g., employees in specific employee or pay-scale groupings, or on maternity or sick leave), or to choose any combination of these three. There isn’t any single right method and the exact choice depends on the size of the payroll population and how homogenous (or payroll similar) they are. The employee population chosen should be sufficiently large to give confidence that all potential issues have been discovered. The resources, technical skills, and time available also have a bearing.

From the point of view of the SAP system, the guiding principle here is to identify and resolve all configuration issues as early as possible. If a partial employee population is chosen, then focus on the weakest areas of the payroll. These may include part-period factoring for new hires; leavers and employees with unpaid absences; employees who have multiple cost centers, basic pay, and/or planned working time changes (known as wpbp splits) in the month; and statutory absence processing (e.g, .parental-leave pay). The workshops, requirements gathering, and configuration phases should have established where potential areas of difficulty lie. The worst situation to be in is where the most complicated and intractable technical issues are discovered right at the end of the testing phase, as fixing these may cause unintentional errors in functionality that has previously been working.

Planning the Parallel Runs

Once the payroll periods have been chosen, further planning is carried out to identify key dates and dependencies, such as relevant cut-offs, pay dates, and interface runs. This should be done jointly with the payroll department, as normally only they will understand the complete flow of payroll data and any accompanying quirks or irregularities.

Table 1 shows a high-level parallel run plan. This outlines the payroll periods that are being compared, the employee population tested, and any additional testing in each phase. The plan shows that as the parallel run progresses, more functionality such as posting payroll costs to FICO, interfaces to third-party systems, production of bank transfer files, and reporting is also tested. In this example, based on the UK tax year which starts in April, no cumulative values are required for the first parallel run, but these are required for the two following parallel runs.

Table 1

High-level parallel run plan

Setting Successful Exit Criteria

Successful exit criteria must be established and agreed to before the parallel run starts (Table 2). The comparison between the SAP system results and the legacy payroll results is normally carried out across a range of wage types (e.g., gross pay elements, deductions, taxes and social insurance) to ensure that all payroll calculations are correct. However, for success criteria it is normally sufficient to focus on employee net pay as this figure needs to be communicated across the business where only a headline figure may be appreciated. A match on net pay is defined as:

1) Both systems have the same net pay (or a difference within tolerance)

2) The SAP system is correct; the legacy system paid incorrectly.

3) An explainable variance (i.e., a difference due to different calculation methods)

Table 2

Example of exit criteria for a three-month parallel run

The acceptable tolerance also needs to be established and agreed upon with the client (such as rounding issues and possible currency conversion issues).

The type of issues to be resolved in each parallel run also varies; see Figure 4, below:

Figure 4

Relative proportion of errors resolved in each parallel run

Parallel Run 1 typically highlights multiple data migration errors. Invalid field values, dates, format, or signs may still be present, or other more serious problems may only become apparent when data is processed through the payroll schema. There will also be a substantial number of configuration errors requiring changes to schemas, rules, wage types, and other payroll configuration. It’s also likely that whatever method is used to compare the SAP system results and the legacy payroll results will contain some mapping errors, and an amount of recalibration will be required here. Typically the rate of increase of matching employees will be high as there are likely to be a number of simple configuration fixes that should correct a large number of employees. At the end of this parallel run, around 85 percent of employee should match on net pay.

Parallel Run 2 should start with a high percentage match as there should be minimal data migration errors remaining. Most of the time should be spent resolving configuration issues with payroll.

By parallel Run 3, data migration and mapping errors should have been eliminated and there should be minimal configuration errors remaining. While most companies would like to exactly match net pay for 100 percent of all employees, this is generally not achievable due to data entry and time constraints. Often the final percent consists of heavily corrected and adjusted employee pay records that would match if sufficient time were spent; however, on balance it is not worth spending this time as no useful additional payroll testing actually results. In the example case shown in Table 2, an exit criterion of 99 percent has been agreed upon.

Communication Plan

It is important to have a communication plan for parallel runs to ensure that the process proceeds as smoothly as possible. Some key points at which the parallel run should be raised are:

• During bid and project preparation: The importance of the process should be stressed so that the required client resources can be costed and facilitated
• Kick-off meetings: Should explain parallel testing concept, the time frame, training schedules, and participant responsibilities
• Parallel run testing meetings: To recap and review tasks and responsibilities before and during the parallel run phase

The communication plan (and planning in general) should adequately cover the fact that parallel runs generally cause a large spike in the workload for everyone involved. It can be difficult to resource within the payroll department as often there are not enough employees to simultaneously run the (real) legacy payroll and work on the parallel run. Sometimes this leads to working long days, nights, or weekends. If this is unavoidable it can be partly mitigated by giving as much advance warning as possible.

The communication plan should also be used to calibrate expectations. It can be useful to clarify that the parallel run tests the payroll configuration (e.g., schemas, rules, wage types, and payroll functions) and not necessarily the entire set of HR and payroll processes or end-to-end integration. Occasionally a misconception arises that everything will be picked up in the parallel run, whereas the truth is that, depending on the method of data migration and the workarounds chosen, it is possible that the parallel run has bypassed a whole set of fundamentals required at go-live. Examples are:

• End-to-end HR and payroll processes are not tested (e.g., employees are uploaded to individual infotypes by LSMW, not by using the hiring action)
• User training and skills are not tested as data is uploaded using LSMW, not manually
• End-to-end integration with interfaces and third-party systems are not tested since these may not be live at the time the parallel run is carried out
• SAP user roles and authorizations are not tested as all data is loaded by a single LSMW data migration user

In fact all these areas need to be covered by separate testing streams and verified in their own right.

This misunderstanding can present itself at the end of a successful set of parallel runs. The client and even project managers can take away the message that the system works without understanding the nuances of exactly what has and hasn’t been tested. This may lead to unrealistic ideas about the volume and nature of faults expected during and after go-live and consequently the appropriate level of support required.

If the parallel runs have not gone well, in some cases the clients or project managers may propose continuing to run both systems in parallel after go-live. The idea is that this would provide a safety net for the SAP payroll system, since it would be possible to revert to the legacy system if required. This is normally a bad idea for the following reasons:

• If there is a real risk the new payroll system could underperform, then it may not be ready to go live anyway
• It is practically impossible to ensure that identical dual entry of data will take place on both systems over an extended period of time
• The HR/payroll team data entry is doubled at a time of already high workload
• All SAP system training, change management, and communications become diluted
• It signifies a lack of confidence and undermines the new system
• Even if there are significant payroll issues, it is often advantageous to resolve these issues quickly

Owen McGivney

Owen McGivney is a senior consultant at iProCon Ltd., part of the iProCon group, based in London, England. He has worked on implementing SAP HR and payroll systems since 1998. Owen has delivered UK, Irish, and multi-national payroll solutions for a wide range of private- and public-sector clients. He has a special interest in combining ABAP programming with configuration to create innovative and effective solutions.

You may contact the author at o.mcgivney@iprocon.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.