For any HCM solution, data conversion is the key for the success of the implementation. SuccessFactors Employee Central is a fairly new product that is quickly evolving and improving. Every implementation has its own particularities that provoke creative thinking and present new and different challenges. As a result, creating a solid data conversion team at the outset enables the success of the conversion and, eventually, the delivery of the project. This article provides guidance that helps as a reference when implementing SuccessFactors Employee Central. The objective is to outline how core data conversion concepts should be planned, designed, and implemented throughout a SuccessFactors Employee Central implementation project. These elements can apply to Employee Central standalone or Employee Central with SAP payroll integration (hosted or on premise). The three key parts of a successful data migration are:

• Planning the data conversion before you begin
• The actual data conversion process
• Lessons learned and some common mistakes to avoid

Data-Conversion Planning

In order to plan your conversion, you first need to understand how the data is assembled—in other words, how it is stored in the legacy system and how it fits into the SuccessFactors Employee Central system. Once this is understood, the complexity of the translation and mapping efforts needs to be evaluated. The final step is to evaluate the volume of the data to be converted. There are three variables that are part of the data assembly process: accessibility, complexity, and volume. Each of these variables needs to be fully identified and analyzed. Figure 1 illustrates the steps required for successfully migrating data, which I discuss in greater detail later in this article. An employee who has multiple transactions over time has layers of employee records in the system. For example, an employee was hired in 1985, promoted in 1990, terminated in 1991, re-hired in 2001, transferred in 2014, and retired in 2015. If there is a requirement to keep all the history in the system, all these layers need to be carefully analyzed and studied to see how the data is going to be loaded.

Data Accessibility

When producing the conversion strategy, you must know the answers to the following: Where is your data coming from and how available is it? To answer those two questions, the data needs to be identified (what are you converting?), you need to know how many legacy systems the data is coming from (source systems), and you need to identify if there are any technical mechanisms to query the data out. I go into more detail about each of these layers later on this article.

Data Complexity

After the source of the data is fully understood, the next step is to understand how complicated it will be to map that data to the new system. For example, you need to know if Position Management is required in SuccessFactors Employee Central and if the legacy system is an employee-based system. Additionally, it is imperative to know how standardized the data in the legacy system is. In other words, how difficult will it be to match the data with the new system or how consistent are the values? Some examples of standardized data elements are the main drivers of complexity. Here are some examples:

• Employee numbers (Are they all numerical? Do they contain the same amount of digits?)
• Historical records (Do all records have the same amount of detail regardless of how much history is being converted?)
• Transactional data (Are transactions uniform?)
• Languages in scope (Are there any special characters? Are you converting to a supported language?)
• Country-specific data
• Organizational data
• Personnel structures

Data Volume

If the data is fairly accessible and easy to extract, and the format is equal to the required format in SuccessFactors Employee Central, the volume of data should not be an issue. The chances of all this happening are slim. For this reason, volume plays an important part and needs to be scoped appropriately. For example, you need to know how many years of historical data is being converted and how much transactional data there is (e.g., layers of employee records, discussed previously). Each of these pieces increases the time that needs to be allocated to load data into the system.

Dependencies

The next elements to keep in mind when planning for a successful data conversion are the dependencies. As with any other project, you should be able to identify the critical path and when the process needs input from other work streams or moving pieces within the project. The first thing that needs to be considered is a stable configuration. SuccessFactors Employee Central provides loading templates that change if the configuration changes. For this reason, I recommend that you not start your load until the configuration has been signed off. Project deadlines are factors that might put pressure on your data conversion as they depend on the configuration. Therefore, pushing a conversion deadline very close to the configuration deadline may cause stress and errors. Additionally, I recommend that you consider the availability of the environments. For example, if you are going to use a different system for each conversion, you need to make sure the configuration is up to date in that environment.

Time and Resources

Lastly, time and resources are key considerations to take in account. Time in this case does not refer to the project deadlines, but refers to the number of conversion cycles (also known as mocks) that will be executed, the scope of those cycles, and the validity periods of the conversion (in other words, how far back in time you are going to convert for the first cycle). It is common for project managers to allocate time based on the volume of the data.  However, these other additional variables that were previously mentioned—namely, accessibility and complexity—also need to be considered, as well as the deliverable deadlines of other phases of the project. Allowing enough time for the conversion results in better data, better testing, and an overall smoother deployment. To accomplish this, you need to allocate time for the data-related activities and not the volume as a stand-alone variable. Resources refer to the roles that are needed as part of the conversion efforts. Depending on the scope, these roles could be absorbed by one or more full-time employees (FTEs). Functional teams often have the operational knowledge and quickly become indispensable for the delivery of the project. If the data team becomes involved later in the process, more time will be required from the functional teams to help overcome the learning curve.

Data Champion

I recommend that a resource be dedicated early in the project as the designated data champion. This resource needs to be involved in the design and requirements-gathering phases. By doing this you will be able to segregate the data activities from the functional teams, allow the data team to understand the design, and drive the efforts of the data team to sync with the functional teams. Besides the data champion, there are two other key roles that need to be filled during the extraction phase: the data agent and the data collector.

Data Agent

The data agent manages and coordinates all data requests and activities to support data gathering and extraction. This person is responsible for mapping fields from current systems into SuccessFactors Employee Central fields, and is involved in data validation and cleansing efforts.

Data Collector

The data collector creates programs or reports to extract the data from the current systems. The objective is to automate the process. The data collector works closely with the data agent to ensure that all the required data elements and values are provided in the correct format. All these elements are pieces of the puzzle that lead to clear planning and poise the project for a successful delivery of the converted data.

The Data-Conversion Process

Data conversion is the process of converting legacy data from one or more formats to meet the requirements to upload the data into SuccessFactors Employee Central for business processing. The main steps of this conversion process are extract, transform, and load (ETL). The data extract stage involves identifying data sources, gathering data element definitions, and technically extracting the data. The transform stage involves manipulating the data in its current form so that it can be used in the new system. This may involve cleansing, enriching, and standardizing data values. In the load stage, processes are deployed to feed the new data into the new system.

Extracting Data

During the extraction, data sources that contain all the in-scope data elements for SuccessFactors Employee Central and Employee Central Payroll are identified. As mentioned before, many data sources may be identified to address the full scope of the implementation (e.g., the payroll, HR, and benefits systems). These sources are most commonly referred to as the System of Record (SoR) and it is the governing system of truth that is used to identify if the data is correct. Typically, the SoR is used as the data source, but it is acceptable to use other sources downstream of the SoR as long as the data is synchronized. This is a common practice if third-party vendors manage the SoR and data feeds are sent overnight to a local system where they can be easily accessed. The recommended method for transmitting any employee data information is via Secure Shell File Transfer Protocol (sFTP). This enables data to be transmitted over a secure channel to a secure repository. The volume of data extracted typically depends on the breadth and depth of information needed for each object. The breadth of a data object describes the range of coverage included. For example, the employee object may only include active employees and not terminated or contingent workers. The depth of a data object describes the amount of historical information included in addition to the current record—for example, current employee information plus values from the last two years. The primary challenge with loading historic employee information is whether foundational data that supports it must also be loaded (e.g., supervisory organization, job codes, cost centers, and so on). Typically, only current information relating to active employees is extracted, with the only historical reference being the individual’s original hire date.

Transforming Data

In the transform step, the data is processed in a secure repository (or workspace) by the data conversion team. This is done using business and technical rules to convert it from its current state to standardized values that are used in SuccessFactors Employee Central. These rules need to be created to address all situations and variability of the data as it is currently stored. For example, if the current system has a Gender field that contains values such as Female, F, female, FEMALE, and Woman, then the conversion logic must explicitly identify all cases and point them to a single value that will be stored in SuccessFactors Employee Central. Typically the rules are provided by the data owner and then implemented by the data agents in their local systems. For example, job codes may be centrally defined and implemented by the local divisions. The data owner is from the corporate office that can define consolidation and standardization rules. The data agents (at the local or functional level) are implementing the rules in their systems or providing direction on how the values that currently exist will be mapped to the new values. The data owner’s involvement in the transformation stage is key to ensuring that business data domain and integrity rules are applied appropriately. You can use a number of commercially and publicly available tools to convert the data. Client tools and environments should be used if their policies dictate the use of specific tools and processes to manipulate their data. However, if available, open-source software can be used to perform many of the critical operations required for data conversion. Common tool examples are Microsoft Excel or Microsoft Access.

Loading Data

In the load stage, converted data is loaded into SuccessFactors Employee Central. SuccessFactors Employee Central data security policies prohibit direct access to the proprietary database and only allow SuccessFactors Employee Central-approved loading mechanisms. There are two SuccessFactors Employee Central-approved load mechanisms: the application data import function and the SuccessFactors Employee Central partner Application Programming Interface (API). Both of these mechanisms can transfer data files using a secure FTP connection with encryption. Loads must be processed in a logical and sequential order. For example, a person must have an applicant record before an employee record is created, and an employee record must exist before a compensation record is created. As a result, these load mechanisms may be iterated many times to imitate a sequence of transaction events. For example, in 1980 Person A is hired (hire load is processed), in 1985 Person A is terminated (terminate load is processed), and in 1990 Person A is re-hired (hire load is processed).

Foundation Objects

As mentioned before, order is important when loading data. First and foremost, foundation objects need to be loaded, then all the standard and custom metadata framework (MDF) objects, and, lastly, the employee data. Table 1 shows a list of the order in which the foundation object data needs to be loaded into SuccessFactors Employee Central.

1. Frequency	10. Department
2. Event reasons	11. Pay grade
3. Company	12. Job function
4. Company local	13. Job classification
5. Business unit	14. Job classification local
6. Geographical zone	15. Pay range
7. Location group	16. Pay group
8. Cost center	17. Pay component
9. Division	18. Pay calendar

Employee Data

It is important to understand the validity dates. Start Date/Event Date used in the effective-dated files should be the same (except for the hire date/job history import). Typically it is the date the information is effective. When adding users to the system, the order of the imports matters. It is recommended by SAP that the data be imported in the following order (this should be the same order as shown in the Import Employee Data area of Employee Central):

• Basic user import – only the Status, User ID, and Username
• Person Info (biographic) import
• Employment details
• Personal information import
• Global information import
• Job information (for the first load, Manager ID and HR ID should be defaulted to NO_MANAGER and NO_HR respectively) – The ID will be updated in the next layer. This is done this way because in the initial load the system performs a validation of those IDs. When this validation is done, must likely those IDs won’t be found; therefore, the record fails to load. Typically there will be two or more layers for this record. If no history is converted, it is generally recommended that you have an initial conversion layer that specifies the origin of the record, and a current conversion layer that has the latest data of that record.
• Compensation Information Import
• Address Information Import
• National ID Import
• Emergency Contact Import
• Work Permit Information Import
• Phone Information Import
• Email Information Import
• Direct Deposit Import
• Pay Component Recurring Import
• Job Relationships Import

After the data has been loaded, the data needs to be verified or validated. Data integrity is key to the success of the delivery of the project. To do this, I recommend that the following actions be performed after the load has been completed:

• Define data reconciliation reports – These should be provided by the conversion team and help to validate key elements (such as counts and accuracy of data loaded during the correspondent testing cycle loads).
• Define data validation reports – These need to be performed at the end of the conversion cycle by the functional team. Then testing needs to be completed and sign-off given before you can proceed to the next phases and, eventually, go-live.

Establishing key performance indicators (KPIs) helps in validating the data; some of these are easy to set and review. For example, ensure that the format is correct, the population is complete (number of records and types of employees are as expected), the files are consistent between them (for instance, if there are 5,000 employee records, make sure there are 5,000 corresponding national ID records), and there are no blank or missing fields or records. Once the load is completed, the functional team reviews and validates the data loaded directly into the Employee Central environment. During this check, the team executes ad-hoc reports, compares them with the previously validated flat file, and, finally, runs audit checks against the legacy system. Additionally the functional team can perform audit validations, consisting of semi-manual smart checks. For example, I could check the 50 top executives, international transfers, and special cases that have been previously identified. Ultimately, the most effective conversion strategies should contain planning and thorough testing. The efforts related to conversion should be carefully planned and not underestimated. Any headaches caused during conversion are caused by poor planning, which leads to underestimated efforts. That causes poor testing, all of which result in bad data.