Learn the key concepts and leading practices for designing global HR processes and integrating them with the SAP ERP HCM Personnel Administration (PA) module. Use this article to understand key considerations in configuring the PA module to work for your global design by applying leading practices to your personnel actions, SAP ERP HCM Processes and Forms, and SAP workflow. You can apply these concepts for initial implementations, roll-outs, or upgrades.
Key Concept
Many global SAP ERP HCM implementations struggle with understanding how to effectively design the Personnel Administration module in a way that promotes a global solution while also meeting country-specific (i.e., localization) requirements. Design principles for defining global HR process flows can help define the solution for manager self-service forms and take into account workflow considerations. Personnel action configuration and customizations can streamline reporting and maintain data integrity.
An ideal global SAP ERP HCM solution is one in which every country in the environment is following similar standards in naming conventions, design principles (i.e., use of specific fields), required infotypes, personnel actions, HCM Processes and Forms, and workflow. Designing the Personnel Administration (PA) module to support and promote a global mindset is essential as it helps reduce costs in delivery and training and in ongoing support. For example, if all countries are part of a global template approach, common configuration and training can be shared across the solution and additional country roll-outs take less effort.
Benefits of Global HR Processes
The first key component of a well-thought-out solution for PA is having all countries in agreement on the global HR processes related to personnel events such as hire, transfer, termination, and pay change. When implementations don’t have global HR processes in place, the result can be an increase in system costs for country-specific training, customizations, and reporting. For example, if one country is using infotypes and fields differently than other countries, reporting will be inconsistent. In addition, custom reports and workflow will be more complex because of the different rules you need to set up based on specific country differences. While defining your global HR processes, you should design them so that all countries can use them. Country-specific variations should be granted only on an exception basis for payroll processing, legal compliance, or regulatory reasons.
It is important to establish a global process flow for each HR process (e.g., hire, transfer, pay change, and change in position) that you can use across all countries. Some additional key benefits to standard HR processes are:
- Allows for simpler SAP workflow design and maintenance. As all countries are following the same global process (with the exception of county-specific scenarios for regulatory reasons), they share the same SAP workflow rules and objects.
- Allows for more efficient HR management across the board. HR and other roles are transparent and share similar responsibilities in each country, which promotes a standard way of doing transactions within the system.
- Simplifies activities when new countries are converted into the SAP system. As a country is rolled out into the SAP ERP HCM solution, it has a baseline design to follow and does not have to start from scratch in designing its HR processes and workflow routings.
- Sets a foundation for individual countries that have to have a unique way of handling things due to local compliance
Note
Adhering to standard HR processes could result in an inconsistency in workflow routings and an increase in system costs and training complexity.
Best Practices with Defining Global HR Processes
When defining your HR global processes, it’s important to keep some key principles in mind to ensure everything is well documented and designed to work for all countries. It is best to define a global HR process for each personnel action that is in scope. For example, this would drive the need to have a process flow for such actions as new hire, rehire, addition of an external worker, pay change, country transfer, and leave of absence. While designing a specific HR process, the team should ensure that it is designing it in a way that supports the HR policies of the company as well as ensuring it is being designed for all countries in scope.
The process design ultimately drives the requirements as well as documenting the end-to-end steps to complete a specific personnel event. For example, on an HR process for transfer with promotion, it could be that the initiating manager sends the request to the receiving manager, who in turn requires approval from 1+ manager for the promotion to take place (Figure 1). Once all approvals are met, SAP ERP HCM is updated automatically with the appropriate action and workflows are sent automatically by the system. This not only captures how HR and different actors serve in the process, but also captures the SAP workflow requirements globally.

Figure 1
Sample transfer process with promotion
For each process flow, implementations should also have a respective process design document (narrative) that explains the process in detail and goes over key items such as process summary, assumptions, data definition, work steps, work step exceptions, actors, and Reports, Interfaces, Conversions, Extensions, and Forms (RICEFs). The following explains each of these components in more detail:
- Process summary: This section of the narrative explains the process flow in detail and paraphrases what the event (personnel action) is used for. This section can also be used to explain key company policies involved with the HR process and the specific reason for an HR process (which feeds into configuration requirements for personnel action reasons).
- Assumptions: Captures all the key assumptions related to the global HR process. This is important because it documents key considerations for the personnel action and ensures that the process is very clear for different countries, for example.
- Data definition: Captures all the key SAP ERP HCM infotypes that are related to the process and that are required. This is key for reporting purposes as it ensures that all countries are well aware of the different infotypes that must be captured during a hire or transfer. Note that this also helps drive the configuration requirements for the personnel actions that are to be configured.
- Work steps: This section documents each of the process flow steps in detail and captures the key information that is not included in your process flow. For example, you may have a step in the HR process flow for 1+ manager to receive a workflow request. This work step for this item documents that the 1+ manager goes into the universal work list in manager self service. This section is important as it is used to tell a story of the associated process flow and add pertinent information that would be needed for training or solution documents.
- Work step exceptions: The work step exceptions section documents any exceptions to the HR process flow. Such deviations could be to distinguish a different process step for a specific country. As an example, a specific country may require a printout of specific HCM Processes and Forms for legal compliance purposes. This ensures localization requirements are met and captured.
- Actors: The actors section captures all the people or roles that are involved in the process. For example, an HR process for promotion requires the manager to start the process, but may also require the manager’s supervisor and compensation department to approve it. As you can see this information is very useful in explaining the process and also can be used by the security/development team for requirements gathering and design clarification.
- RICEFs: This section captures all of Reports, Interfaces, Conversions, Extensions, Forms, and Workflow (RICEFWs) customizations that may be related to the process. This component of the process narrative captures any key customizations that can be used for a specific process — for example, details on design documentation related to workflow and custom forms in manager self service. The process design document is essential to ensure that global HR processes are well documented. It serves as a validation mechanism for countries to help ensure that all localization requirements are met.
During the design process for global HR flows, it is very important that implementation teams keep international stakeholders in the loop to ensure that the proposed process design works for each relevant country. Regional leads should be involved with the design workshops and with the sign-off process to ensure that everyone is on the same page. If a change is needed to the HR process design after blueprint (or after go-live), it should go through a change control board process to ensure the change is applicable to all countries. Any approved changes should be documented within the appropriate document to ensure that the process flows and design documents capture the most up-to-date information.
Designing Personnel Actions for Global and Localization Needs
It’s very important that a global HR process flow and narrative are created for each of your personnel actions in scope. Once this is complete, personnel action types and InfoGroups can be configured based on your global and localization requirements. An InfoGroup in an SAP system is a series of infotypes that come up based on a specific personnel action. For example, you may have a requirement that the following infotypes come up in a specific sequence for all countries based on a new hire action being processed: 0000 (Actions), 0002 (Personal Data), 0001 (Organizational Assignment), 0006 (Address), 0007 (Planned Working Time), 0008 (Basic Pay), 0009 (Bank Details), 0014 (Recurring Payments/Deductions), 0015 (Additional Payments), and 0041 (Date Specifications).
It is a best practice to have only one action type per personnel event globally to keep reporting and interface mappings simpler. To meet the requirements of having specific infotypes come up only for certain countries (to support payroll, social insurance, tax, and legal reporting), implementations should use the InfoGroup modifier concept with the InfoGroup. The country-specific InfoGroup modifiers are set on the InfoGroup configuration table of T588D and go hand in hand with the configuration in feature IGMOD within transaction code PE03. For example, by looking at Figures 2, 3, and 4, you can see that the country of Belgium is mapped to an InfoGroup modifier of 12 or 12A within InfoGroup Z0 for the new hire action. Many companies use the MOLGA (or country version in SAP) number as the InfoGroup modifier code. Within InfoGroup modifier 12 below, an implementation can have specific infotypes called up to meet the Belgium payroll, such as 0100 (Social Insurance B), 0101 (Fiscal Data B), or 0505 (Holiday Certificate B).

Figure 2
Personnel Action Types table showing action type Z0 (new hire) mapped to InfoGroup Z0

Figure 3
Feature IGMOD illustrating the use of InfoGroup modifiers. A separate InfoGroup modifier should be created for each country in scope.

Figure 4
Feature IGMOD illustrating the use of InfoGroup modifiers
The only drawback to having only one action type globally per personnel event is that users are not able to set country-specific reason codes. Although this can prove to be a disadvantage, a common practice is still to add the country-specific reason codes and have a custom table or user exit to restrict the system from saving the action if the reason code is not permissible for a given country. For example, in the US, projects may have a specific requirement to have a worker’s compensation reason for a leave of absence. This reason code could be added to the action types with USA Only text at the end. Then an entry in the custom table would note that it’s only allowed for employees belonging to MOLGA 10 (USA). If you try to use this reason code on an employee in China and then attempt to save, the user exit would be called and provide an error saying that the reason is not valid for the given employee.
Note
Using the custom table for permissible reason codes should also be used in manager self service or HR Admin self service when HCM Processes and Forms are being used. This ensures data integrity and that the solution is the same both in the SAP ERP HCM back end and SAP NetWeaver Portal.
Designing Your Manager and HR Admin Self-Service Transactions
When designing your manager or HR admin self service transactions as related to HCM Processes and Forms, it is important that you carefully consider the layout of the form along with how both global and localization requirements can be met. The global HR processes defined at the beginning of a project assist with documenting the requirements about which actors (or roles) are responsible in specific personnel events (e.g., transfer, termination, or promotion) and help define the workflow requirements needed in manager self service. As these process flows are global in nature, there should be very little need for country-specific exceptions other than for legal or regulatory reasons.
Some projects put country-specific fields into HCM Processes and Forms. Although this can help ensure that all data is entered within a given process, it goes against having global HCM Processes and Forms. It also adds significant costs. To help reduce complexity and costs, one approach is to have country-specific infotypes updated manually after HCM Processes and Forms is automatically updated in the system.
A common practice is to have key transactions such as promotion, transfer, and termination automatically update the SAP ERP HCM system and then have workflow routings, based on the country, sent to the local HR department to have additional country-specific infotypes updated. For example, a project may have a promotion transaction for a Belgium employee that requires the personnel action and global infotypes to be updated within SAP ERP HCM. However, as Belgium has additional country-specific infotypes to be updated, the SAP workflow sends information to the local HR department in addition to automatically updating the SAP ERP HCM system. This ensures that local HR is involved with the transaction and with updating any local infotypes as needed. This scenario is illustrated in Figure 1.
Mark S. Jackson
Mark Jackson has been working with SAP ERP HCM for more than 12 years and specializes in SuccessFactors Employee Central and the SAP ERP HCM Personnel Administration and Organizational Management modules. He has had numerous experiences with implementing and leading SAP ERP HCM and SuccessFactors globally and is a subject-matter expert in defining global templates for SAP/SuccessFactors implementations.
You may contact the author at Mark.S.Jackson@gmail.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.