As project leaders begin a global SAP ERP HCM implementation, several tasks take place immediately, including defining a global design and solution for the project to follow. The end deliverable is the global template for the SAP ERP HCM implementation. Many projects struggle at the outset with understanding how to effectively create and document an SAP ERP HCM global template that can be followed from project blueprint all the way to production support (post go-live).

Creating a global template for your SAP ERP HCM project should be based on instilling key design principles for global HR processes, an effective SAP ERP HCM data model for organizational management (OM) and personnel administration (PA) data, a detailed and well-documented custom RICEFW (Reports, Interfaces, Conversions, Forms, and Workflow), and local considerations. Below I discuss many of the challenges and implementation considerations that users face.

SAP ERP HCM Process Design

At the beginning of the project blueprint, SAP ERP HCM project teams should establish an HR process inventory, and document global process flows and design documents by module (e.g., OM, PA, Time, and Payroll). The key consideration at this stage is that the HR processes being built should be global in nature, and all countries within the company should follow these business processes as a standard. Of course, there may be some country-specific variations required for legal or data privacy reasons, but these should be the exception.

During the design phase of the process flows, it’s important to have all the necessary stakeholders buy into the process, including regional and country-specific leadership, to ensure that the process flow is followed and built into the overall SAP ERP HCM solution. This is instrumental later in the project as these process flows ultimately feed into configuration and workflows. The process flows should have a clear distinction of roles (e.g., who is performing the task within the process) so that there is a clear understanding about roles and responsibilities.

Figure 1 shows a simplified employee data change process and indicates the type of format to follow. With this example, it is clearly documented what steps of a given process are SAP-enabled as well as the key roles involved. These process flows not only help build your solution design at the beginning, but also capture any customizations needed later on, as well as all security requirements. The example in Figure 1 shows a custom workflow.

Figure 1

Simplified employee data change process flow illustrating the swim lanes and details captured

Finally, these process flows should be captured in a process design document that captures key information such as the process overview, process flow, assumptions, data requirements (e.g., it captures required data such as SAP infotypes), as well as any country-specific exceptions. There should be one process design document for each process that the project has in the process inventory. As you can see, these documents are essential as they not only capture the business process, but also feed into build (configuration and customization) and security requirement documents.

HR Data Model

As the process flows are defined, project teams can then work to determine the data model of the global template. Documenting the data model includes key tasks, such as defining HR personnel actions in scope, infotypes in scope, infotype requirements (e.g., which fields are required or optional or hidden, as well as their individual drop-down values), and the OM data model (e.g., what objects and relationships are to be used within OM). This is the main deliverable of the global template as it essentially captures all global and country-specific ERP system settings. The data model within the global template should be the guiding principle that each country follows.

Each personnel action should be clearly mapped to a process flow design. For example, if you have 12 personnel actions (e.g., new hire, rehire, change in position, or termination), they should directly correlate to the equivalent HR process design document (described in the previous section). This is a key integration point as the business process design sets the requirements and solution design for the personnel actions that are configured as part of the global template.

It is also key to capture within the global template the infotypes being used across each process team. The global template should clearly state if the infotype is a global or country-specific infotype. If global, additional countries that roll onto the solution should follow these as the standard. For example, the global infotypes listed below are the ones that that, typically, are standard across all countries:

• Infotype 0000 — Actions
• Infotype 0001 — Organizational assignment
• Infotype 0002 — Personal data
• Infotype 0006 — Address
• Infotype 0007 — Planned working time
• Infotype 0008 — Basic pay
• Infotype 0009 — Bank details
• Infotype 0019 — Reminder of dates
• Infotype 0041 — Date specifications
• Infotype 0105 — Communications

For each infotype, the global template should also capture the requirements or characteristics that are associated. For example:

• Field listing: Which fields are within the infotype and capture both the field name and the technical name. An example for infotype 0000 would be to capture the data listed in Table 1.

Table 1

Examples of data contained on the actions infotype (0000) as well as field characteristics

• Drop-down values: These should capture all the global and country-specific values associated with the infotype. The global template should also identify the configuration tables associated with the dropdown.
• Dynamic actions: A dynamic action is the configuration done on an infotype that automates a subsequent action. For example, you may have a requirement to have the SAP system automatically bring up infotype 0021 (family/related persons) if you change the marital status on infotype 0002 (personal data) to married. The global template should capture all dynamic actions that are being configured both globally as well as anything country-specific.

Finally, the OM data model should also be clearly defined in the global template. This is essential as it sets the foundation for all employee data within the system and sets a standard for future countries as they roll onto the SAP ERP HCM solution. The data model should capture the following:

• Objects in scope: Captures the OM objects that are in scope and used within the system. Captures key objects such as organizational unit, position, job, work center, and cost center. It also captures any customer-specific objects defined for the implementation.
• Relationships in scope: Defines how the object types within OM are related to each other. Examples of this are listed in Table 2.

Table 2

Examples of OM relationships in scope as per the global template data model

• Evaluation paths:  Evaluation paths are a view of how the SAP system can read the organizational structure to report on a given person or object. The global template should capture all of the evaluation paths created for the implementation as this documents the global standards that countries adhere to. An example of the SBESX evaluation path is shown in Table 3. The global template should capture it in this format.

Table 3

Example evaluation path for SBESX

Reports, Interfaces, Conversions, Forms, and Workflow (RICEFW) Objects

In addition to the process flow and data models, it is also important to clearly document both a functional design document as well as a solution overview for each custom RICEFW. The functional design document must be a very detailed document that captures the key requirements for the customization, whereas the RICEFW solution overview is more of a paraphrased description of the specific functionality for the purpose of capturing a summary of customizations within the SAP ERP HCM global template.

The main reason to document the solution overview within the global template is to provide a description of all custom SAP ERP HCM functionality that captures all of the available non-standard functionality within the solution. As countries are added to the SAP ERP HCM solution, your target audience is able to see all the global and country-specific functionality available within the company’s SAP ERP HCM environment. This drastically speeds up the time it takes for a roll-out country to understand what customizations are in place on the initial implementation. It also gives them a reference point as to where the detailed functional designs are stored. The global template should capture the links to the individual functional and technical specification documents so that users can view the functional and technical requirements for the individual RICEFW object.

If the RICEFW object is related to a custom report or a custom infotype, the project should also put forth effort to capture screenshots within the global template so the user gains a clear understanding of what is available. For example, if a custom infotype is available to capture company-specific data, the global template should include:

• An overview of the custom infotype (purpose)
• A screenshot of the custom infotype
• The field labels and technical names of fields within the infotype
• The drop-down values (if applicable)
• Specific error checks and edits that should be in place
• Mapping to personnel actions (if applicable)

If a custom report is created, the following should be captured within the global template:

• An overview of the custom report (purpose)
• The fields available for selection
• The fields available for output
• Specific formatting needs (e.g., sort order and grouping of data)

The global template should also link a RICEFW object to a process design document. This shows how everything is linked together and also helps with explaining the global or country design at a higher level.

Localization Considerations

In addition to global configuration and design requirements being captured within the global template, it’s also important to capture any and all localization (country-specific configuration) that is included within the solution. Localization should take up roughly 25 percent of an SAP ERP HCM solution based upon legal and regulatory compliance.

Key things to capture within the global template are any and all country-specific infotypes (including drop-down values and related configuration), country-specific infogroups and personnel actions, as well as any country-specific SAP features (a feature is a mechanism in SAP ERP HCM configuration that allows infotypes to behave in a certain way). For example, one essential feature that you should consider and document carefully within your global template is the feature for the infogroup modifier (feature IGMOD). This feature is essential in configuring any country-specific variations for personnel actions.

In addition to configuration requirements around localization being captured within the global template, it’s also important to capture key SAP Notes and country add-ons that have been implemented. For example, there are 14 countries that are not delivered by default with SAP ERP HCM, but are available with add-ons. They are: Bulgaria, Colombia, Croatia, Czech Republic, Greece, Hungary, Poland, Romania, Saudi Arabia, Slovakia, Slovenia, Turkey, Ukraine, and The United Arab Emirates.

Finally, one item that is commonly left out of a SAP ERP HCM global template is any type of configuration related to language translations. It is very common for global projects to configure drop-down values with approved languages in scope. With these translations being configured, projects should also maintain the actual translations within the global template so project teams can quickly see what has been built.

Maintaining the Global Template

Once a global SAP ERP HCM implementation is complete and has gone live, it is very common for project documentation to quickly become out of date. This is the case, in particular, when SAP production support teams make changes based on bugs and new requirements. It is essential that the SAP ERP HCM global template be updated frequently as changes are made. The global template should always contain the most recent configuration as this document serves as the primary deliverable for the project (outside of the system itself, of course).

In addition, as other countries are rolled out, this SAP ERP HCM global template has to be reviewed very carefully so new countries know what has already been implemented as well as what company standards must be followed. Many projects don’t emphasize enough that the global template should be updated at all times. If it becomes out of date, it will be costly to re-evaluate the system and find and update any gaps in the SAP system documentation.

There are several things that need to be clearly documented within an SAP ERP HCM global template to ensure proper documentation and results. By clearly capturing the global HR process, HR data model, and related RICEFW associated with both global and country-specific localization projects, you ensure that your implementation project leaders and team members adhere to leading practices and have a complete picture of their SAP ERP HCM global template solution.

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.