Sometimes an existing SAP ERP HCM payroll system has to be reimplemented in another SAP system as part of a business merger or reorganization. Because the source and target payroll systems are both based on SAP applications, project owners and planners may assume that this switch will be an easy swap-over or, at the very least, that it will be more straightforward than a brand-new implementation. In reality, however, it can be much more complex to build into an existing system than a greenfield project as a number of additional challenges and constraints can be presented.

A recent project I was involved with clearly demonstrated this. My client, a large company, purchased a small business unit within a large UK energy utility company. This acquisition involved the transfer of a small group of highly specialized employees to the new company. As both companies had large mature SAP ERP HCM systems for administering HR and payroll in place, the view was that the payroll functionality easily could be replicated in the new system. I was part of the team tasked with implementing the SAP ERP HCM and payroll functionality with the new system based on a lift-and-shift approach. Here’s what happened.

The Business View of the Project’s Complexity

I wasn’t present at the initial meetings in which details of the buyout were negotiated between the old and new parent companies. However, judging by the project-planning decisions already made, it appeared that insufficient focus was paid to any potential technical challenges and process issues around transferring the employees. The perception seems to have been that transferring to a new employer and payroll system would be easy because (1) both companies were already using SAP systems and (2) there weren’t very many employees who were being transferred.

Some examples of the decisions made illustrating this mind-set were:

• The project timelines that were set were very challenging, and to meet them, some of the testing phases (e.g., user-acceptance testing and parallel run) were overlapped. This decision achieved the aim of telescoping the project plan, but at the cost of “baking in” the assumption that no serious technical issues would be discovered. As a result, the possibility that rework and retesting might be required was not factored in.
• The two companies decided that formal workshops were not required because the payroll and business rules for the new system could be found in existing documentation combined with directed follow-up with the current payroll team where necessary. This decision increased the risk that requirements for the new payroll system could be missed or misinterpreted.
• The transfer date chosen did not coincide with the start of a payroll period. Because these dates were not aligned, the two companies needed to devise a finance recharge process for partial payroll periods split across the transfer date. This resulted in considerable additional planning, testing, communicating, and administrating.

The Consultants’ View of the Project’s Complexity

For the SAP ERP HCM payroll consultants, the initial investigation and analysis resulted in a very different picture of this project’s challenges. The employees were unionized, and a number of collective bargaining agreements were in place. In the UK and Europe a significant area of labor law covers such employee transfers. Under these laws, all the employees’ existing contractual arrangements were to be maintained. These terms and conditions were considerably different from those in place at the new company.

Employees were to be allowed (and encouraged) to transfer over to the new parent company contract terms in the months following the transfer. However, under the existing labor laws, this was only permissible once they had initially been transferred with their current terms and conditions. Consequently, there was intense scrutiny during the project from union representatives, HCM, and the legal departments to ensure that contractual details had been set up exactly and identically on the new system to meet these legal requirements.

This requirement directly affected the complexity of the payroll implementation of the new SAP ERP HCM system. While the absolute number of employees being transferred was low (fewer than 1,000), the employees were spread across a large number of these collective-bargaining agreements. Therefore, a number of complex pay scales and supporting configuration items would be required to evaluate salary and basic pay, additional linked allowances, annual leave, and sick pay entitlements. Overall the number of rules, terms, and conditions was disproportionate to the number of employees. In other words, contrary to the prevailing business-side view, the low number of employees affected had no correlation to the complexity of the build and test efforts required. For example, a complex sick pay scheme was required for fewer than a dozen employees. At the same time, due to the specialized skill set of the employees, a number of exceptions had built up over the years on which personal contractual details had been agreed. These exceptions also had to be replicated on the new system.

Implementation Methodology Chosen

By the time the SAP implementation team was formally engaged, the parent company already had outlined the project plan. The parent company wanted a mini-project that was delivered quickly and driven by the previous build. Consequently, the implementation team was allowed supervised access to the old system to view the existing configuration. The implementation team could also contact key business users via phone or email. The company had taken the position that a set of requirement-gathering workshops wasn’t necessary. Other than skipping this step, the project was planned with the normal phases in place: blueprint, configuration, user-acceptance testing, parallel run, regression test, and final cutover.

The implementation team did not like this approach. The team expressed doubts about the viability of reverse engineering a complex SAP ERP HCM and payroll system mainly from configuration entries. Some areas of functionality (e.g., payroll rules and schemas) can be very difficult to interpret on their own outside of the context of the business rules and processes for which they were built.

In addition, the view was that interaction with business users is fundamental to understanding the final requirements, and, from my own experience, this is a prerequisite for delivering a successful project. Without this key interaction there is a high risk of overlooking important details. To avoid this problem, the old and new payroll teams agreed to communicate fully during the project and participate in a number of knowledge-transfer sessions. Both teams also decided that completing three full parallel runs would capture any significant differences. With these additional risk-mitigation steps in place, the teams agreed to use this approach.

Technical Challenges

The project presented a number of technical challenges with regard to the old system, particularly extracting configuration details for customized infotype fields and analyzing details for wage types, schemas, and features. Configuring into the new system presented a different set of challenges, primarily avoiding breaking the existing payroll.

Extracting Configuration Details

The first technical challenge was how to extract configuration details from the old system. The SAP ERP HCM payroll system that the employees were being transferred from was about 12 years old and was used to pay around 60,000 employees in total. The key challenge was to identify useful and portable items of configuration that were applicable only to the small number of employees being transferred. The main sources of information for the build were employee data downloads, screen prints, and configuration table extracts combined with targeted questions to business experts on the old system. Extracts of data and configuration were carried out to the implementation team’s specifications, and SAP support partners for the old system delivered them in a timely fashion, normally by the next business day. It’s conceivable that this wouldn’t always be the case, and if they had been more obstructive or selective in providing information, then this would have stopped the project in its tracks.

Customizing SAP ERP HCM Infotypes

The starting point was to identify all the infotypes currently used to store HCM and payroll data on the old system. The implementation team created a list of personnel numbers of all the employees being transferred. Using this and the General Table Display in transaction code SE16N, the team identified which infotypes were in use. Then the team manually reviewed each infotype in the display master data transaction to identify nonstandard and highly customized fields. Extracts were taken to get the customizing table entries behind the fields. The customizing table values were filtered so that only entries that were applicable and used by the transferring employees were selected.

Analyzing Wage Types

The implementation team used the wage type reporter (transaction code PC00_M99_CWTR) to create a listing of all the wage types that had occurred in the payroll results over the previous 12 months. The implementation team applied totals and counts in Excel to identify wage types that were rare, which were then cross-checked by the old payroll team to see if these infrequently used wage types were still required. When the list of wage types had been verified (using program RPDLGA40), the wage type characteristics were extracted to get the details of the cumulation classes, evaluation classes, and processing classes. This data was merged into a wage type catalog.

This catalogue was forwarded to the payroll team members who administered the new system as they wanted to avoid having any duplicate wage types as much as possible. As there was a large overlap in payroll functionality between the old and new systems, they were able to identify that about 40 percent of the wage types already had equivalents. When this wasn’t the case, new wage types were configured. This list was also used to start building up a wage type mapping document, which cross-referenced wage types on the old system against wage types on the new system. This was required for data loading and for comparing results in the parallel runs.

Analyzing Payroll Schemas

The payroll schema was downloaded into Excel using program RPDASC00 (formatting schemas and personnel calculation rules). The resulting schema listing was formidable and it was initially impossible to identify any specific payroll calculation rules that would need to be replicated. The approach taken was to identify any highly customized payroll rules specifically for the employees that were being transferred. This was done by searching the payroll schema to identify explicit references to specific payroll areas and personnel areas using the text search function in Excel.

Excel formulas were set up to count the number of times that each wage type in the wage type catalog was mentioned explicitly in the payroll schema. This provided an approximate measure of how important each wage type was in terms of how many custom payroll calculation rules had used it. The thinking was that this would highlight any complex and nonstandard calculations. This approach helped identify approximately 30 custom payroll rules in the old system on which we needed to focus. Corresponding payroll calculation rules were added to the payroll schema on the new system. Additionally, the spreadsheet was used as a useful reference tool during the parallel runs to identify where differences were coming from.

Customizing Features

All the common HCM features were reviewed on the old system (e.g., SCHKZ Work Schedule Defaults). Where these were small, a screenprint was taken. Where the features were larger, the General Table Display transaction code SE16N was used to take table extracts straight from customizing table T549C Decision Trees for Features (Customers). The corresponding features on the new system could then be modified based on this information.

Other Customizations

There were a few key other areas of customizing that could be configured more or less exactly by creating configuration table entries based on extracts from the old system. These included sickness schemes and leave quota generation rules.

Challenges Presented by Configuring into the New System

The technical details gathered in the preceding sections were used to create the blueprint and the configuration documents to guide the new build. The main technical challenge faced was in configuring the payroll schema. It was a live payroll system used to pay around 40,000 employees. One single payroll schema was used for all weekly, four-weekly, and monthly employees. This 10-year-old schema contained more than 5,000 lines of code, and it had been considerably patched during upgrades, other corporate reorganizations, and general ongoing support fixes.

Consequently, building new rules into this schema was difficult. A considerable amount of time had to be spent trying to understand the way that the current system had been built and why certain design decisions had been made. The ever-present risk was not only that pay would not be correct for the new set of transferred employees but also that errors would be caused to employee pay on the other pre-existing payrolls.

A really useful tool was a spreadsheet payroll results comparison tool similar to the one described in my SAPexperts article, “How to Compare Payroll Results Before and After a Major Schema Change.” Wage-type-by-wage-type checking was carried out for all employees for all parallel runs. This helped rapidly identify any configuration errors or missed requirements. The same tool was also used for regression testing. By taking payroll results set before and after the configuration transport had been applied to a client, it was possible to confirm that no inadvertent changes had been made to existing payroll calculations.

Migrating Data

Data migration was made easier as the source and target were SAP HCM systems, with negligible differences in version. In most cases data was stored on the corresponding infotype and fields on the target system as the source. Some data was transposed to a different infotype (e.g., some contractual allowances were moved from the basic pay infotype to the recurring payments infotype).

Familiarity with the data structures made creating a data migration plan, detailed field listing documents, and data transform rules straightforward. Data was extracted from the source system using SAP queries and table extracts with the General Table Display SE16N. Data was amalgamated and transformed in a custom external database, then loaded on the target system using a set of Legacy System Migration Workbench scripts. A business decision was taken early on that the same personnel numbers would be used on both systems, which also saved a lot of time as it was never necessary to map employee numbers.

Results and Lessons Learned

In the end this project was delivered successfully and generally exceeded expectations. There were very few additional payroll queries from the employees immediately after the transfer, and a low volume of minor support issues had to be resolved in the first live months. In this case, a few factors were probably key to why it was possible to use a lift-and-shift approach successfully. These are:

• The payroll implementation team was able to leverage its wide system knowledge and experience to interpret and reimplement configuration into a challenging new environment.
• The data migration consultant provided an agile and flexible utility for data transformation that made repeated data loads for testing possible and painless.

Despite the successful outcome of this one project, however, none of the implementation team members would be able to recommend this as a general methodology, and the whole experience reinforced to everyone the key importance of engaging with business process experts in understanding and designing a successful system.

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.