Historically, ERP solutions were designed to manage data from all functional areas and to perform all business processes within a single source. Major ERP software companies realized that it is impossible to address business requirements from all industries. From that point, the ERP solutions have opened the integration to specialized solutions requiring integration and clear rules about data maintenance. I share what to consider before making a final decision on which solution will host each data component: the system of record. The focus is on data components affecting payroll processes.  

What Is a System of Record?

  The system of record is your source system that owns that data component. The leading practice is always to create, modify, or delete this data within the same system of record and never within a downstream solution. Adopting this practice facilitates data auditing as you know the source system based on the data component. This practice ensures all solutions are in sync, which ensures reporting accuracy. You can imagine the headache that results when you run a report in your HR solution and one in payroll and they do not match because of asynchronous solutions.  

Key Considerations for Designing Your Systems of Record

  This section shares the questions and actions you should go through to be ready for designing your systems of record as part of a hybrid solution. When I refer to a hybrid solution, I mean an environment that uses different solutions or vendors, not one strictly limited to SAP SuccessFactors.  

Potential Systems of Record

  As part of a hybrid solution, one or more solutions can manage one data component. As an example, SAP SuccessFactors Employee Central Payroll (a hosted cloud functionality) could be the source system for pay codes. It is important to understand the functionalities and fields from each potential system of record. In SAP SuccessFactors Employee Central (a cloud solution), you can enter pay components, but you have more limited functionalities than if you used Employee Central Payroll, where the offering for performing pre-payroll validations is more extensive. Employee Central Payroll uses SAP HR and Employee Central. You may discover only after the pay components from SuccessFactors Employee Central are passed to Employee Central Payroll or SAP Payroll (the on-premise solution) that an employee is not eligible for a wage type due to a specific attribute. It requires you to go back to Employee Central to correct the pay components and wait for (or manually trigger) the integration between your solutions.  

Data Owner

  It is important to understand who is managing each data component as part of your actual business processes. A process drives each data component. This information helps you to define your system of record.  Many companies segregate the solutions by functional area as a design consideration as shown in Table 1. This table provides you some examples of potential solutions that could be used as part of a hybrid solution.

Functional area	Solution
Human Resources	SAP Human Resources (on premise) Employee Central
Payroll	SAP Payroll (on premise) Employee Central Payroll
Time Management	Employee Central Time Off SAP Time Management (on premise) WorkForce software
Benefits	SuccessFactors Benefits SAP Benefits (on premise) Vendors
Financial	SAP Finance (on premise) Others

 

Knowledge Transfer

  Most companies try to minimize the learning curve of impacted employees. They try as much as possible to have them focus on one specific solution included in a hybrid solution. Even if solutions are integrated, they have their own data structures and functionalities. It is not intuitive for all employees to learn multiple solutions. Most companies prefer to leverage reporting and dashboards to have access to other required information that has other solutions as a source. This approach does not enable them to update data, but to have the capacity to review the required data directly from the system of record.  

Segregation of Duties (SoD)

  The system of record definition is also a common way for companies to perform SoD. I often see companies that have only the compensation pay codes entered in Employee Central. Only bonuses and awards and some other pay codes are entered in Employee Central as they are specific to human resources (allowances). Items that are payroll specific such as taxes are often managed directly in payroll (on premise or in the hosted cloud). Some companies decide to use the mashed-up infotypes concept to initiate the creation of tax infotypes in Employee Central Payroll. The decision element that can influence this choice is whether you agree that based on Employee Central addresses data, you want the tax infotypes to be initiated and completed by the payroll department, or if you prefer that based on a new hire report, the payroll resources create the entire tax infotypes record. I prefer to have them created entirely in Employee Central Payroll so that nothing is overlooked, but some people could argue with this decision. Because garnishments are purely payroll data, I recommend keeping them in Employee Central Payroll as no real functionality is offered in Employee Central. The last pay component I cover is worker compensation, which I prefer to manage in Employee Central Payroll or on premise based on the data feed from Employee Central for job, position, or organizational unit.  

Solution Functionalities

  Companies should never select one solution as the system of record before reviewing the solution functionality. The functionalities offered could potentially not accommodate your business requirements. This approach could influence how you select the system of record for a specific data component. I have seen companies make the decision to use Employee Central as the source system for a specific pay code. This pay code requires various eligibility controls as far as which employee could be have each pay code entered for them. The issue is that Employee Central does not offer all supporting configuration to have those controls applied. For example, a pay code was assigned to an employee who was not eligible. The code assignment was transferred to Employee Central Payroll, which rejected that pay code assignment. The payroll team had to ask the Employee Central user to remove the pay code and wait for the integration between both solutions to happen. This situation could generate a bigger issue on a payday.  

Integration and Timing

  You should never overlook the need to integrate among the solutions and the data transfer timing. Consider a scenario in which pay code information is only available shortly before payroll processing. I recommend having this pay code directly entered in Employee Central Payroll to avoid last-minute payroll issues. You need to keep in mind that a pay code should always be entered in the same solution to make the auditing consistent.  

My Recommendations

  I recommend you manage your data based on the guidelines in Table 2 for your future hybrid solution to align with leading practices.

Functional area	Solution	Data component
Human Resources	SAP Human Resources Employee Central	Personal Data Demographic Data Assignment Data Salary Data Default Financial Data Default Work Schedule Pay Components related to compensation Bonus and Awards
Payroll	SAP Payroll Employee Central Payroll	Recurring Deductions and Payments Additional Deductions and Payments Garnishments Tax Information Financial Data Override Payroll Calculations
Time Management	Employee Central Time Off SAP Time Management WorkForce software	1.Time Entries 2. Work Schedules 3. Holiday Calendar 4. Substitutions 5.Time Banks 6.Time Calculations
Benefits and Saving	SuccessFactors Benefits Vendors	Plans Attributes Deductions Amount
Financial	SAP Finance Others	Posting Period Chart of Accounts Cost Centers  Vendors