Many SAP clients face the challenges of acquiring a new company or taking over a new business unit in their existing setup. Sometimes they have to assist a company that is acquiring them. Typically the HR and IT departments carry a large burden during this process. I’ll explain how to prepare for mergers and acquisitions, specifically addressing Personnel Administration (PA), Organizational Management (OM), Benefits (BN), Payroll (PY), and Personnel Time Management (PT).

The two merging organizations are likely to have different ERP environments, as shown in Table 1. On one end of the spectrum, both companies run SAP; on the other end, the merging environment may not even have a centralized ERP system. Your challenge in bringing the other environment to SAP HR/PY increases greatly if the merging environment is non-ERP with no centralized IT and HR processes.

Figure 1 shows how the complexity of your mergers and acquisitions project increases with a more complex organizational structure or more HR submodules. Now I will go into more detail about how to analyze your HR system. This analysis serves as the foundation for a typical SAP HR implementation, and therefore it is crucial to a successful go-live. I’ll use a module-based approach to help you understand the migration phase and issues surrounding the migration process.

Figure 1

Approximate complexity chart (the x axis is your SAP system’s complexity and the y axis is the merger or acquisition’s complexity)

Planning

During the planning phase, you should assess your enterprise structures and the PA, OM, BN, PY, and PT modules. The references to SAP HR are generic and mostly applicable across versions. My broad discussion about these modules establishes the planning criteria and helps estimate your efforts. It will serve as a good starting point in establishing technical design as well as in transition management documents.

Enterprise Structure

Figure 2 shows a top-down approach of how SAP software relates to a company’s structure. The left side lists the corporation view from the acquisition perspective while the right side shows an SAP HR structure perspective. Figure 2 includes the elements of SAP employee-related structures that you may need to address.

Figure 2

Enterprise top-down approach

• Country code: In many merger or acquisition situations, you may have cross-border mergers of HR systems. In this scenario, your starting point is MOLGA (country code) in the SAP HR environment. That means the merger affects all levels.
  
  
• Company code: If you merge a new company and keep the legal entity separate, you have to follow the full company code creation process in SAP. In this scenario, it is easy for you to replicate the second company’s existing structures, thus reducing any mapping efforts between legacy and SAP systems.
  
  
• Personnel area/subarea: If you are acquiring a line of business, a plant, or a geographical unit, the best way to start is with the personnel area. Obviously, the constraint is your existing enterprise structure and the arrangement of personnel areas.
  
  
• Employee group/subgroup: While merging the incoming employees with the employee group/subgroup structures, you have to map the structures just like any legacy data conversion to SAP. You may want to use cross-walk tables as required during data conversion.
  
  
• PY: The payroll frequency and calendars of incoming employees play a role in deciding the payroll strategy. In case you are able to move employees from an old payroll system into an existing payroll area, you have to plan for year-to-date (YTD) data conversions. Later in the article, I’ll discuss more about payroll.
  
  
• Employee numbering: You can handle this in one of two ways. You may decide to bring over the legacy numbering from the merging organization or use SAP numbering and convert the legacy numbers into SAP numbers. If you decide to convert the legacy numbering to SAP numbering, then you can use infotype 0032 to maintain the legacy numbers. This assists the users in referencing their old numbers until they become used to SAP-generated numbers.

Next I’ll discuss some SAP HR modules and present tips about how to deal with mergers and acquisitions within each module.

PA

Starting with the PA module, you need to prepare for configuration, data mapping, data conversion, and transition management. Table 2 shows how to deal with these four major migration tasks.

OM

The mergers and acquisitions process can follow one of two routes that impact the OM structures and relationships:

• Option 1: Create a completely new organizational unit with a top-down approach. For instance, if there is a company-code-level acquisition, replicate the entire organizational structure starting at the top all the way to individual departments. In this scenario, you can potentially have two different structures — one for your existing organization and one for the incoming new organization. This option makes it easy to create and migrate the OM structures.
  
  
• Option 2: Absorb the incoming employees into different organizational units of your existing organization. If you merge an incoming IT department with the existing IT department, you need to ensure that you create the appropriate jobs and positions in your system to absorb the incoming employees. If the unit of business you are acquiring merges with existing operations (e.g., your company acquires a smaller firm), absorb it in your existing organizational structures. Remember that a true merger may demand new organizational structures.

Table 3 presents the pros and cons with each of the options. Although option 2’s data conversion takes longer, this method may be more advantageous.

Useful Migration Tips

• For employees’ hiring and start dates in infotype 0001, follow the same philosophy that you adopted for your original SAP HR implementation. For example, if you use the go-live date as the from date in infotype 0001 and maintain the original hire date in infotype 0041, follow the same logic for the migration.
  
  
• In case your merger or acquisition calls for golden parachutes or separations, make sure to plan work efforts for appropriate configuration of personnel actions. Immediately after the acquisition, you will need personnel actions for separations that impact benefits.
  
  
• Check whether you’ll need to access the historical data from the legacy environment at any stage for reporting or analysis. If so, develop a strategy to keep the data in a data warehousing (SAP BW) system. Do not mix the legacy structures in HR for occasional reporting needs. Remember that reporting needs increase immediately following the merger and eventually decrease.
  
  
• Try to keep HR features that specify default values in PA (e.g., LGMST [planned payment specification] and TARIF [default pay scale type and area]) in their existing form to simplify your maintenance. Maintaining features can be very tricky for complex organizational structures. It can also cause problems with your personnel actions as well as defaults when maintaining infotypes.
  
  
• If you need to create new base pay wage types to handle complex scenarios for the incoming employees, make sure that the from date of infotype 0008 is valid from the merger date.
  
  
• Provide enough resources and time to match the direct and indirect valuations of your existing base pay wage types with the incoming employees’ base pay models. I suggest that you provide a wage type configuration resource during the migration phase of the project.

Table 4 provides a list of SAP HR functional areas that mergers and acquisitions impact the most. Next, I’ll discuss these areas in more detail.

BN

During consolidations, companies often try to re-engineer their historical benefits plans to increase employee contributions and decrease company contributions. Transferred employees are also likely to carry frozen pension plans in most cases. Bringing the new employees into your organization involves one or many of the following situations in your SAP configuration, depending on the agreements and legal issues around the mergers and acquisitions:

• Create a completely new benefits area for incoming employees and manage the benefits separately from your existing employee population
  
  
• Configure new benefits plans under the existing benefits area
  
  
• Maintain all relevant features (transaction PE03)
  
  
• Change the cost structures
  
  
• Customize programs to move employees from one plan to another if you have to handle large employee populations

Table 5 shows how to deal with the major migration tasks in the BN module.

PY

As in the case of a normal SAP PY implementation, the timing for payroll transition is crucial in mergers and acquisitions. If the merger or acquisition takes place in the middle of the tax year, this creates more work for your planning and blueprinting transition.

You may face the issues of a mid-fiscal year transition and new payroll frequencies and have to adjust your configuration accordingly:

• Create a new payroll area for the incoming payroll employees and therefore complete downstream configuration related to the payroll calendars, features, and control record management.
  
  
• Convert payroll results in the middle of a pay period by using schema ULK9 to transfer payroll results. Another option is to use infotype 0221, which allows you to assign tax company and tax authority overrides.
  
  
• Configure additional wage types as necessary
  
  
• Maintain payroll schemas and rules (in rare cases, you may create a completely new schema)

Table 6 shows how to deal with these four major migration tasks in the PY module.

PT

The impact of a merger or acquisition on the PT module largely depends on your company’s discussions with unions and collective bargaining agreements. The following factors could complicate your transition in PT:

• Convert existing leave and vacation balances
  
  
• Create new absence quotas
  
  
• Change the rules related to time evaluation (overtime, shift differential)
  
  
• Change front-end time capture tools (Cross-Application Time Sheet [CATS] or other)

Table 7 shows how to deal with these four major migration tasks in the PT module.

Even after the planning and documentation that I listed above, you will face concerns during the migration. In a subsequent article, I plan to focus on testing and problems that may arise during the actual migration process.

Satish Badgi

Satish Badgi has been helping clients implement SAP ERP HCM and payroll for more than 15 years. He has been involved with large full-scale SAP ERP HCM and payroll implementations using the breadth and depth of SAP modules. Satish works for a large management and systems integration consulting firm and handles global payroll for clients. He has published two books on SAP payroll, Configuring US Benefits with SAP and Practical SAP US Payroll.

You may contact the author at sbadgi@comcast.net.

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