If you want your merger or acquisition to go smoothly, you need to focus on four areas that relate to SAP HR. The four key topics that I’ll discuss are testing, change management, issue resolution, and reusability of knowledge and experience (Figure 1).

Figure 1

Four cornerstones of SAP HR for mergers and acquisitions

The testing aspect of your project requires specific scenarios for the type of project you’re working on. I’ll provide some examples later. Change management is another key factor to the success of any ERP project. While some projects may succeed without full-time change management resources, a merger or acquisition project requires them. In addition, you must work to quickly resolve problems during your project to maintain credibility.

If your company plans to grow through mergers and acquisitions, do all in your power to reuse the configuration, documentation, and overall knowledge from your first project. This allows you to perform subsequent projects with less effort and money. Now, I’ll cover each of the four subjects in Figure 1 in detail. I’ll begin with testing.

Create Specific Test Plans

Many detailed conditions pertain to testing for merger and acquisition projects. I will explain these specific conditions for each of the following modules: Personnel Administration (PA), Organizational Management (OM), Benefits (BN), Payroll (PY), and Personnel Time Management (PT). I’ll present representative specific test scenarios around merger and acquisition activities.

PA

Some scenarios related to testing for merger and acquisition projects in the PA module might include:

• Transfer employees within a company. If you are merging two company codes into one, it’s essential to test transfers within the new company. Assess the impact of these transfers on personnel areas and subareas. For example, the company that’s merging with yours used to perform transfers using location codes. Plan for how to handle the transfers after the project using SAP HR enterprise structure elements and personnel actions.

• Transfer employees from one company to another. If a new company with a new company code has merged with yours, you may want to move the employees from one company code to another.

• Change approvals. Salary changes, for example, may require different approvals. Many SAP customers build approvals using the reporting hierarchy or HR departments. For instance, the director of HR must approve hiring actions before you can complete them. Likewise, the department head must review promotion actions before completion. In PA actions, if you build approvals (especially using SAP’s new Adobe forms), you should test the approvals with the changed workflows.

• Delimit positions and move people from one position to another. If positions overlap in the merged organization, you may need to move people across positions.

• Move employees from one payroll area to another. When you must create a new payroll area or merge two payroll areas, ensure that the new payroll areas work correctly.

OM

Here are key scenarios for testing activities specific to mergers and acquisitions in OM:

• Delimit organizational units. In the merged organization, some of the organizational units may overlap. Therefore, you need to delimit them and move jobs and positions to a different organizational unit.

• Isolate obsolete jobs. The merger may render some jobs obsolete. Your testing should identify all such job holders and their movements. Many project teams ask their HR department to prepare a list of overlapping positions and the employees. You can then map the positions that correspond to those jobs. Based on the managerial decisions, the HR team performs actions such as reorganizing and moving people across positions, early retirements, and layoffs.

• Change reporting relationships. In most cases, reporting relationships need additions, modifications, and deletions. The testing scenarios should cover these types of situations. The post-merger reporting relationships probably will change for incoming new employees as well as for some of the existing employees. These reporting relationships in SAP can affect many business processes such as:

– Training approvals

– Travel expense approvals

– Cost centers and head count reports

– Time sheet approvals

The testing scenarios therefore should identify these affected business processes and accordingly address test planning.

BN

I’ll now discuss some key scenarios for testing in the BN module.

• New plans and related deductions. If you have configured any new benefit plans, you should conduct similar tests as if you were creating a new benefits implementation. Let’s say that you had to bring over a certain health plan into your SAP HR environment because of contractual and legal agreements. You configured the health plan with appropriate eligibility and cost rules. You need to test this new plan with incoming employees and all applicable options such as employee only, employee plus one, and employee plus family.

• Grandfathered plans. If any of the employees have grandfathered plans, appropriate testing conditions need to cover them. Remember that the grandfathered plans are locked and not available to enrollment or new additions.

• Retroactive changes to benefit deductions. Decide how you want to handle any retroactive changes. Consider this possible scenario. You went live with the merged company on January 1, 2007. Then, on January 15, 2007, a retroactive change related to an employee’s dependent details comes through with the date of December 28, 2006. It’s likely that you may not even have the benefit plan that the employee had in December. These kinds of situations necessitate a solution that not only requires a benefit action in SAP HR, but communication with the employee about the benefit event.

• Limits (annual as well as age-based). Test the incoming employees for annual contribution and catch-up contribution limits. You should also plan to load the previous year-to-date (YTD) contributions to ensure that the annual limits are correct.

• Cost calculations. Test as you would in a normal benefits implementation. You might want to test different options (employee, only, employee plus one, and employee plus family). Also examine union rules and ensure that the new system produces correct benefit costs for the employee, employer, and provider.

• New vendors and remittance. If you have added new vendors, you need to test the interfaces and remittances to the new vendors. Typically, the post-payroll and downstream benefits vendor processing involves two parts. One relates to SAP HR’s third-party processing and the accounts payable documents, while the second relates to interfaces that send data to the vendors and benefit providers. Ensure that your testing covers both.

• Delimiting of old plans. Delimit or lock the old plans as necessary and carry out negative testing for flexible spending accounts. If the merging company had flexible spending benefits and yours does not, study the legal and regulatory issues to create the right test plans. One option is to allow the incoming employees to use their existing flexible balances and stop further deductions in their new payroll. You can handle claims processing for the remainder of year either in one of two ways: Either your company takes over or the merging company hires an administrator.

PY

When testing for the PY module, keep the following factors in mind:

• Change wage types. You may face additional or altered characteristics or processing classes for the wage types. If your payroll schema has any rules that use these wage types, then you should test employees and calculation conditions for these wage types.

• Review benefits deductions. They affect most of the mergers and acquisition projects. You need to test the benefit deductions for all different dimensions, including:

– Retroactivity

– Seasonal deductions

– Limits testing

– Percentage of based calculations and other accurate figures

• Perform W-2 and tax reporter simulations. Especially if you have merged mid-year and have transferred cumulated payroll results, you should test the W-2 simulations as well as other tax reports such as 941. These simulations check that the cumulated tax results arrived correctly.

• Assess mid-year movements across tax authorities. During the project, some people may have moved across tax authorities. Your testing should cover these movements across different work as well as resident tax authorities. Your test cases should include people who relocated as a result of the merger or office relocation. As a result, the residence tax areas and work tax areas change in those employees’ master data. You should also include such cases in your payroll testing to check that:

– Your system calculates any new tax areas correctly

– Your system calculates local tax authorities correctly

– Your tax reporter simulation works accurately

– Your system calculates unemployment rates accurately, especially if the merging company had any special rates negotiated with specific states

PT

Key testing scenarios in the PT module include:

• New attendance and absence types. Test changes to attendance and absence types and their integration through time wage types to payroll.

• Retroactive overtime calculations. Test for retroactive overtime calculations for the pre-merger period and check how the system will handle these situations. Based on the merger or acquisition agreements, this could be a large undertaking.

• Changes to leave and absence in periods prior to merger or acquisition. For example, the merging company had an absence type called emergency absence. After the merger, you remove this type. However, an employee needs to use this option. Before this situation occurs, decide whether the merging company can bring with retroactive changes or whether the legal agreement between the two companies overrides such situations.

• Leave accrual rules. New leave accrual rules may be in effect if incoming unions have an agreement in place.

• Leave balances. Check leave balances and their accuracy using infotype 2006 as well as the delivered SAP quota reports in PT.

• Time collisions. With changes to attendance and absence configuration, you may have missed some time collision scenarios. For instance, you integrate PT and Training and Event Management (PE) in your SAP HR system. Therefore, incoming employees are unable to attend your training unless the SAP HR team frees them from their work schedules.

Follow Change Management Techniques

Project teams often ignore change management because they are so caught up in technology and configuration issues that they tend to overlook other aspects of the transition. Transition management in merger and acquisition projects may be more challenging than a regular SAP implementation since entering employees face integration challenges. Sometimes, you may face resistance to change out of desperation and frustration. Employees may have psychological barriers to the merger or fear losing their jobs or their comfort zone.

Traditional change management tools and methodology may prove useful in SAP HR projects for mergers and acquisitions. Popular examples include:

• Brown-bag lunch sessions

• Web sites with announcements

• Newsletters and bulletin boards

• Workshop sessions

• Dictionary of SAP (HR) terms and nomenclature

• A project champion in each department

In addition, I offer these suggestions:

• Integrate newsletters and announcements to help join both organizations

• Create product-specific transition plans if the merging organization has a non-SAP system. For example:

– Compare terminology and references

– Compare enterprise structures and organization structures

– Compare wage types, attendance types, and other such catalogs

Such comparison between two systems helps the users to establish a frame of reference. It also makes them understand that the change management team considered their needs.

• Keep the merging organization’s legacy environment for a reasonable time frame even after go-live. The reasonable time frame depends on the strategy and decisions surrounding how you decommission the legacy environment. Consider maintenance and upkeep costs for legacy software and hardware. You have to perform a cost-benefits analysis and then make a judgment about the time frame. In some cases it may be three months, while in difficult ones, it may be as long as six months.

Resolve Problems

It is not enough to have a change management plan and tasks during the implementation. In post go-live scenarios, the employees need far more help. The typical problems with the merger and acquisition transition are well known and I will reiterate them here. They include:

• Cultural changes and integration into the new organization

• Reporting relationships and personality issues

• Technology and systems

• Compensation and HR policies

• Relocation and work-life balance issues

Now, I’ll list some of the common complaints and problems employees face as they move to the new environment, and then explain what to do about each concern. The issues relate to the following areas: change, systems, or training.

Change

“My HR specialist used to be in the office to answer questions and now you are telling me to dial a 1-800 number to resolve my issues.” To resolve this, create a visiting HR representative for at least few days each week until people settle down.

“I have been working in our information technology environment for last 20 years and now that SAP is here, I am going to lose my job soon!” Department heads or HR counselors need to have career talks about how to retrain employees using SAP tools and technology and how they should use this opportunity to move to a newer technology.

“I am doing lot more data entry in SAP compared to many old systems.” You should recognize the employees’ concerns that SAP HR has many more infotypes than the legacy environment. In addition, remind employees of the key advantages: retroactive accounting, integration with Financial Accounting, PT, and Payroll. Explain that the benefits outweigh the drawbacks.

“I used to get overtime when I worked for more than eight hours each day and now you are telling me that overtime is calculated for more than 40 hours for each week!” Solution: Explain the new company’s policies and procedures before new workers begin. Since the employees are new to these polices, make them available via a portal or in hard copy.

Systems

“I know my employee ID from my old system and now everyone asks for my new SAP employee ID.” Solution: Use standard SAP functionality to maintain legacy employee IDs and create procedures for people to access that data.

“We used to see leave balance on our pay stub and now we don’t.” Your team may have missed requirements when blueprinting and gathering requirements. If so, use appropriate change control to fix the system issue. The change control needs to create a request for the appropriate form change (for a pay stub in this case) so that the system prints the leave balances. While you’re fixing the problem, send a communication or announcement to acknowledge it and a scheduled repair date to pacify the aggravated employees.

“My Federal Insurance Contributions Act (FICA) deductions are wrong after I moved to the new company.” The wrong FICA deductions could happen for a few different reasons. Maybe you brought over incorrect earning amounts from the legacy system, the W-4 data is wrong, or the incoming company had special situations with FICA calculations and pre-tax deductions that you missed during requirements gathering.

“My old system used to deduct my local school board taxes, but the new system does not do that.” Perhaps the employee’s master data record contains the wrong infotype 0207. This could be a data conversion issue. This problem can also arise when you forget to update the Business Software Inc. (BSI) tax tables with the latest tax bulletin (TUB).

Training

“I don’t know who my new supervisor is.” Clearly communicate this type of information to new employees.

“I don’t know the procedure that I have to follow for leave approval.” Implement training or Web-based documentation.

“How do you change union dues deduction amount in SAP?” Make sure to train new employees or refer them to Web-based documentation.

“I need to run some headcount-related reports around merger and acquisition activities and do not know where to start.” Your team may have missed requirements during blueprinting. Refer this user to standard-delivered SAP OM reports such as organizational units, positions and occupied positions, staff assignments. This employee may also find the graphical toolbox helpful.

Reuse Knowledge and Experience

You want to reuse both your existing configuration and your project experience. I’ll explain how to effectively do both.

To reuse your existing configuration, you may be able to fit the new company directly into your existing configuration. Alternatively, you can enhance the existing configuration. Which option to choose depends on these aspects:

• Philosophy of enterprise, organization, and payroll structures. While designing or changing existing design to accommodate the incoming organization, you may want to ponder the following questions:

– If we do another similar acquisition, can we add to existing personnel sub-areas or can we use existing employee groups and subgroups?

– If we get more unions, how can we add to the existing structures? Can we use employee subgroups or the Contract type field from infotype 0001?

– Are we going to have multiple payroll areas or will we move everyone to our current weekly and biweekly schedules?

• User exits, customized reports, and other development objects. I do not recommend that you make changes to the core SAP system. These types of changes come with costs as well as potential problems for Support Packages and upgrades. Therefore, minimize such customization. If the merging company brings over situations that demand modifications, you need to take a hard look at their business processes and rules. Just like a new ERP implementation, you want to consider process changes and workarounds to avoid the customizations.

• Historical database of issues and resolution. I suggest that you implement and maintain a database of issues and resolutions from your original SAP HR implementation as well as from your first merger or acquisition. Your second merger project will likely repeat many of the issues, especially around authorizations, portals, and reports. You will be able to quickly access or point your help desk staff to the existing issue databases for quicker resolution.

• Champions from businesses that helped you in the original implementation. Most organizations have champions in areas like BN, PY, PA, OM, and PT. You may refer to them as process leads, business process owners, or team leads. These champions have experience and may have solved many problems during your original implementation of SAP HR. Therefore, you should invite them to share their expertise with the merger/acquisition project team for each project.

• Added requirements. Avoid adding requirements to your configuration as much as possible. Hold off on new projects such as wage type catalogs and time wage types until after the merger is complete.

• Interfaces, especially those to vendors and benefit providers. For instance, if you are bringing over a new benefit vendor, negotiate your existing file format with them. If your company plans additional mergers or acquisitions, create reusable products such as design and planning documents. This makes the process faster and cost effective. Table 1 shows a list of reusable items.

In addition, you may be able to reuse hardware. Business and IT managers should consider the following questions to decide the strategy for your implementation:

• If the merging company has an existing SAP HR environment, will you keep that as a separate instance or will you merge it into your existing SAP HR environment? Do a thorough cost-benefit analysis and examine your company strategy to determine this. For example, your company might want to keep the merging company separate for future spin-offs.

• Do you want to reuse the merging company’s hardware for purposes other than the SAP implementation? For instance, you can use database servers with different types of software, network servers for expansion, and Internet servers for many purposes.

• How do you want to handle the portal environment? To make the transition smooth, you may decide to keep the merging company’s customized portal or self-service front end.

• Is your hardware vendor part of your growth and expansion plan and are you getting the right terms from the vendor? Base your negotiations with vendors on your company’s growth plans. For example, if you are likely to add five database servers over the next five years, the vendor is likely to give you better price than on just the one you are currently buying.

Lessons Learned

Here are some tips based on the mergers and acquisitions projects that I’ve worked on.

• The planning and preparation phase is bigger than in a traditional SAP HR project. It carries more weight. Make sure to include readiness checks.

• Change management has additional dimensions such as differing attitudes, resistance to the merger, and a learning curve for incoming employees compared to a standard change management initiative.

• One of the most difficult aspects of your project may be integrating employees. They have many questions about benefits, vacation, and compensation management. Expect both challenges as well as failures in your project.

• You must resolve issues efficiently. Place added emphasis on this because you are dealing with whole new set of people who are new to your culture.

• Establish policies and procedures and keep legal issues in check. Do not leave gray areas! The project team needs to be very clear about mergers and acquisition terms to avoid conflicts and legal battles.

• Do not forget these less obvious areas:

– Disaster recovery. Revisit your disaster recovery plans and procedures in the new environment.

– Vendor management. In the preparation and project planning phase itself, educate your vendors.

– Hardware and technology. This includes network, infrastructure, front end, portals, and data warehousing systems. It may be a good idea to create an exhaustive hardware and infrastructure document that goes beyond the main application or database servers. It could include desktops, routers, front-end software standards, and browsers.

– Cutover phase. Do not overlook the cutover phase in the project plan.

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.