SAP ERP HCM implementations often result in historical data conversion business requirements that emerge at the beginning of a project or later during an implementation. These requirements could result from one of the following circumstances:

• Retirement of legacy systems to reduce maintenance dollars, removal of outdated technology, or a reaction to a lack of vendor support
• Union agreements that require data and calculations to go back a few years
• Compliance and retention policies that mandate the storage and access of historical data

The conversion of this historical data can become a challenge as a result of three factors:

Retroactivity: Most legacy systems do not handle retroactivity the way SAP ERP HCM does. Therefore, everyone involved with the implementation needs to understand how SAP ERP HCM handles retroactivity and its impact on historical data requirements and options.

Date sensitivity: Unlike many legacy systems, SAP ERP HCM is date driven. Similar to retroactivity, those working in an SAP environment need to understand date sensitivity and date de-limiting functionality.

HR structures: Enterprise structures in Personnel Administration (PA) and organizational structures in Organizational Management (OM) modules need to be related to historical data discussion

A good starting point for the historical data requirements discussion is the four force model presented in Figure 1.

Figure 1

Four forces of historical data

Regulatory, legal, and compliance requirements are normally at the top of a historical data considerations list. The regulatory requirements dictate the number of years of historical data that you need to convert and maintain. For example, you often hear that you need to keep data for seven years. However, in certain industries — such as chemical and food and drug — the requirements for data maintenance could go far beyond the seven year standard. Some companies also want to maintain data related to employee incidents, such as exposure to asbestos, as a safeguard. The US and Europe have norms for this. Some countries in Asia have retention periods similar to those in the US.

For strategic requirements, companies maintain historical data for topics such as organizational changes, compensation, and benefits. Trend analysis and analytics with historical data help companies with their strategies, such as gauging the effectiveness of a reorganization.

Operational requirements could call for retroactive treatment of historical data or, in some cases, accessing and printing documents using historical data. These requirements often result from union agreements.

Emotional requirements must also be taken into account. After many years of using a system, users may become emotionally attached to the data and tools associated with analyzing the data. These users want to carry the data into the new world of SAP, despite a lack of any valid strategic or operational reasons — for example, “I designed a query in our legacy HRIS system and I like it.”

Requirements Analysis

You need to identify specific requirements based on the four forces described above when you plan your strategy for managing historical data. I will discuss a few sample requirements, but companies need to develop a detailed requirements matrix for their unique initiatives. Using my example, you can separate the emotional requirements from the necessary requirements.

Regulatory/Legal Requirements

The following examples of regulatory or legal requirements use historical data samples that are representative of typical user requirements:

• Regulatory requirements state that you need to maintain at least seven years of employee data

• You need to maintain workplace safety and employee complaint data from the last 20 years. In addition, you need to be able to generate reports and ad-hoc queries using this data.

• Your company acquired a business unit last year and needs to bring this unit's historical data into the company's format so that it can run reports

Operational Requirements

Operational requirements often revolve around granular reporting requirements, including:

• You need to see the job history for employees for the last 15 to 20 years with Equal Employment Opportunity (EEO) categories
• You are not converting past payroll data to SAP ERP HCM, but you need to run reports on benefits deductions. You want to carry out analysis on benefits expenses and trends.
• You need to print past pay stubs, prior to SAP ERP HCM go-live periods
• You need to create calculation logic within historical data — for example, retroactive calculations in historical data. You then need to bring the calculations into the current environment. In some countries, union agreements have the potential to go back several years and demand retroactive changes. Typically, most SAP ERP HCM/Payroll implementations use the beginning of the calendar or tax year as the earliest retroactivity date — for example, January 01 in some countries and April 01 in others.

Strategic Requirements

Strategic requirements drive the scope of the implementation, as seen in the following examples:

• A need for seamless integration between historical data and current data. An example of this would be the ability to create reports by mixing date ranges between historical data and current data.
• A need to perform trend analysis on data

Other Requirements

Some requirements need to be challenged, including these:

• We have built a custom data warehouse application and need to replicate the queries and reports in the SAP ERP HCM system
• We might need the data, and if the legacy system is retired we may not have any place to access this data

There are two different approaches you can take to handle historical data. You could load the historical data into the system at the same time you implement SAP ERP HCM or you could do so after go-live. Each route presents benefits and challenges.

Handling the Data During the Implementation

If you load the historical data at the same time as the SAP ERP HCM implementation, you must have a dedicated data team. You cannot afford to only have the main implementation team address it because the activities and tasks go far beyond standard implementation tasks. The two teams can work together on the design in this approach and discuss better solutions to address your company's specific requirements. For example, teams can discuss HCM structures, action types, reason codes, and similar items from a single perspective. Table 1 presents the pros and cons for this approach.

Handling Historical Data after an SAP ERP HCM Implementation

Budgetary and resource issues sometimes force project teams to postpone the historical data until after go-live is complete. This approach needs to be independent of the original implementation and needs to keep SAP ERP HCM structures and other strategies that the implementation team designed and adopted. Table 2 presents the pros and cons for of waiting until after go-live.

SAP ERP HCM Sub-Modules

In this section, I discuss each of the SAP ERP HCM sub-modules and describe how historical data affects them.

Personnel Administration (PA): The PA module is always high on any SAP ERP HCM priority list because it is at the core of the system, with employee master data maintained in its infotypes. Most new users expect to house historical data in applicable PA infotypes. Experienced users are normally familiar with the issues around SAP ERP HCM structures and date affectivity, and therefore understand the problems with housing historical data in the PA module. The challenge is that PA infotypes depend on the start date of infotype 0001 (Organizational Assignment). The strategy for your infotype 0001 start date can go one of two ways — use the go-live date or use the original hire date for an employee. If you choose the go-live date, your other PA infotypes cannot start earlier than that date. Most teams choose a baseline strategy of converting only active employees, or in some cases, both active and retired employees. The most popular advice is to use the project go-live date as the start date of infotype 0001. That way, both the infotype 0001 and infotype 0003 (Payroll Status) dates are manipulated by project teams to load active employees and avoid cross tax year retroactivity.

Organizational Management (OM): OM data is almost impossible to convert from an historical angle. You cannot recreate organizational structures in a current SAP environment, especially with one current active plan in the OM module. As organizations go through structural changes, such as mergers and acquisitions, definitions of organizational units or business units can also change. This makes historical OM data conversion very difficult. Typically, you set the definitions for OM objects such as organizational units, jobs, and positions. However, you cannot dynamically change the definition of these objects based on historical events because you cannot create different types of OM structures based on historical definitions. In some cases, project teams look at options to create custom infotypes to house historical OM data. For example, they could create a PA custom infotype and load multiple line items for historical jobs/positions and from/to dates. Typically, the requirements demand the job history or position history at an employee level. Designing and creating a custom infotype can be a viable solution if the data is limited to few elements only.

Payroll: The most popular strategy for Payroll is to go live at the beginning of the year to avoid historical data. Mid-year go-lives convert the data with quarterly cumulator conversion so it is applicable to the particular payroll tax year – for example, you can perform a cumulation of earnings, taxable earnings, and calculated taxes. You can maintain cumulators on a monthly, quarterly, or yearly basis. You can convert the quarterly accumulated figures (quarter to date) instead of a payroll (monthly or weekly as per pay frequency). However, most implementation teams never plan to convert historical payroll data in SAP, even if there may be requirements for this. This is because they decide to go live at the beginning of the year and thus do away with this requirement. In a few cases I have seen, retroactivity needs to go back many years, which must be handled manually. In an SAP system, retroactivity is recommended to stay within a tax year or a little beyond a tax year.

Benefits: Historical benefits data requirements can fall into two categories — one related to enrollments, plans, and eligibility, and the second related to actual deductions. The first category is closely linked with PA data, while the second category is linked with Payroll data.

Options for Handling Historical Data

Some implementation teams decide to continue with their legacy data warehouse or legacy system to access historical data. If you decide to continue with the historical data conversion, there are some options for different types of conversions using SAP modules. Each option may not work in every situation, but you can use these examples as starting points to build upon.

Create and store one or more custom PA infotypes in the PA module. Instead of using infotype start and end dates, you can maintain the historical dates in the infotype itself. For example, you can design a custom infotype to house all historical jobs for an employee, with a start and end date for each job. Similarly, you can capture total compensation against those jobs. This is a relatively easy and straightforward option, though there are some limitations you face because you are using a single infotype design. HR Expert has offered articles in the past on the topic of creating custom infotypes. For example, refer to Dawn Burns' and Kathy Howard's article, “Create New Infotypes or Enhance Standard Ones to Meet User Needs,” which was posted to the HR Expert knowledgebase in September 2003.

Create inactive OM structures. You can create an OM plan with legacy structures. For example, you can create an inactive plan version in the OM module and also create the historical structures. This option is useful only when you want to convert historical structures without any employee or people data associated with them. In the OM module configuration, you can create a plan version. However, only one version can be active at any given point. You can create other plan versions and maintain the structures under them. When you only want to maintain organizational units, jobs, and positions, you can maintain those structures under the plan versions.

Create custom infotypes similar to SAP's 4xx series for Payroll. SAP has provided the 0402 through 0460 series of infotypes to convert payroll results in PA infotype form. These are called the 4xx series. I recommend that you look at these infotypes in the PA module using transaction PA30. You then need to configure them and activate them through the IMG.

Convert payroll history. Many implementations demand that payroll history be converted. In many countries, the payroll history is used for items such as union agreements or salary revisions. You can use payroll clusters, the 4xx series of infotypes, or SAP NetWeaver BI, as discussed below.

Use an SAP NetWeaver BI DataStore object (DSO). You can create a DSO to house legacy employee data. You create the codes — such as those related to SAP ERP HCM structures — in text form rather than as codes and types. You load the text instead of building codes that may not have meaning for historical data.

Create an InfoCube based on historical data requirements. When you start gathering requirements for historical data analysis and reporting, you can design a comprehensive InfoCube to store the data. In some cases, the InfoCube could be focused on just PA-oriented data or a combination of PA-oriented and Payroll data. Designing and data modeling these InfoCubes is up to the implementation team. SAP NetWeaver BI comes with standard InfoCubes that are typically organized by module (i.e., PA, Payroll, Time Management, Benefits), so they do not combine data across modules.

Combine current data and historical data. You can use the texts from the past to combine personnel areas/organizational units from current data to build queries. The text on the SAP object should not include any reference to the old legacy object IDs, but instead only include the description of the object. For example, rather than showing an organizational unit as “5000010 Distribution Center- Consumer products,” show it as “Distribution Center- Consumer products.”

Create a custom data warehouse. If a custom data warehouse or a legacy system is retiring due to technology changes or limitations, consider creating a custom data warehouse using third-party database tools and technologies. However, you should consider the SAP NetWeaver BI option prior to going down this path because SAP NetWeaver BI provides a much more integrated solution.

Use a PC-based database such as Microsoft Access. Storing the data in PCs or small servers can be a cost-effective option rather than in SAP ERP HCM or SAP NetWeaver BI. This option has restrictions due to the technology architecture but can be suitable for mid-size implementations. Specifically, the constraints and restrictions are related to the maximum size of databases and the query and data analytics tools that are available in Microsoft Access. However, if the legacy data requirements are such that the data does not need to be combined with ongoing SAP ERP HCM data (after go-live), this could be a cost effective and easy-to-use option.

Build a custom bridge between outside data stores and SAP. In some cases, it may be possible to build mini-applications to access the outside data and build a bridge between SAP ERP HCM and outside data stores. This may come in handy when the mini-application can do calculations. For example, you could create a custom application in ABAP that performs payroll calculations by looking at historical Payroll data that is stored outside of SAP ERP HCM.

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.