Whether you’re just beginning a global project or are already supporting SAP HR in multiple countries, this advice will help keep your project on the right track.
Key Concept
A global template is a design document for the footprint of a globally configured SAP HR system normally created by the core global SAP HR configuration team. It is both technical and functional in nature including not only technical configuration information for key SAP HR data elements, but also explanations of key global HR business processes. This document is the core design document that, in theory, covers 50-75% of all global requirements in SAP HR and is supplemented by complementary local design documents created by the local configuration or SAP HR user teams.
Shortsighted or incomplete SAP HR implementation planning can cost much more money in the long term than necessary. If you are currently implementing SAP HR (or considering it) globally or locally, it makes sense for you to build a system that is scalable not just for your current country scope, but also for future global expansion. A global HRIS that is properly implemented and coupled with a truly global HR strategy can result in huge economies of scale in many areas of HR. Some of the drivers for these kinds of large-scale implementations include enhanced global reporting capabilities, a streamlined workforce, and global unification of key strategic processes (e.g., performance management, recruiting, and compensation).
Global implementations can seem overwhelming in many respects. My tips focus on the modules of SAP at the core of SAP HR: Personnel Administration (PA) and Organizational Management (OM). I will discuss key considerations of the preparation phase of a global SAP HR implementation. This scope provides the foundation on which you can form your own company-specific strategy for a global SAP HR implementation with an early focus on some of the risk areas, cost drivers, and critical success factors typically associated with such a complex project. In upcoming articles, I will dig deeper into the technical details of the global template design document as well as the Payroll and Time modules.
Tip 1. Align Global HR Processes
Before tackling such a major HRIS system rollout, you should first align HR processes globally. These kinds of projects carry high risk without the added complexity of trying to align HR processes while implementing a system in parallel. Expensive consultants can end up waiting on the sidelines for executives to make HR decisions before they can continue work. This initiative does not have to be a year-long project of pure HR business process synchronization. It can be as simple as creating a global configuration template based on SAP HR processes. You should align your HR processes, starting with those required for configuration of SAP HR globally in a template rather than simply in a technical document for configuration. These core global process and configuration areas are covered in more detail below.
The extent of globalization is one of the many key cost and timeline drivers for large companies with many countries to consider in the scope of implementation. If you already have considered how globalized your processes are, then you are a step ahead of most.
You should answer this globalization question by using the technical foundations of SAP PA and OM to define the baseline of processes and data elements you should consider harmonizing. Use the configuration of these two core HR modules as the basis for what should be globalized:
- Enterprise structure (personnel areas, subareas, employee groups, employee subgroups)
- Personnel actions (hiring, termination, retire, rehire, organizational reassignments)
- Organizational structures (organizational units, jobs [job categories], and positions)
In an upcoming article, I will share my approach to create a global SAP HR design template. An empowered, centralized global template design and implementation team is a key to the success of your implementation.
At the end of a project planning phase, you should have defined the following: a project team globally and locally, an estimated timeline, countries, and processes in scope. If you have SAP HR somewhere in the organization, then you can leverage those resources to define a global template for your SAP rollout. If you don’t have internal SAP HR experienced resources, then you should definitely consider using a vendor with global SAP HR system design and implementation experience. Even with experienced SAP HR resources in house, there are certain design considerations I’ll discuss that require current local knowledge of SAP HR legal reporting.
Tip 2. Determine What Can Go Global (and What Must Stay Local)
The answer varies widely from company to company due to factors such as employee headcount, centralization or decentralization of HR, and countries of operation. The core of SAP HR is designed from the ground up with this capability in mind and it is flexible enough to provide a framework to accommodate varying degrees of globalized configuration.
Figure 1 shows what areas and percentage of SAP HR are typically global versus local. The modules on the far left of the chart indicate those areas of SAP HR that are highly localized, while those on the far right indicate which areas you can typically globalize depending on your company’s needs and global capabilities.

Figure 1
Global and local SAP HR processes
Tip 3. Choose a Phased Rollout
The strategy for rolling out a large-scale implementation such as a global HRIS is mostly company specific and depends on resource availability, internal (and sometimes competing) business initiatives, company culture, and company structure, among many other factors. However, some common questions often arise in the process of defining a rollout strategy and timeline.
The risks involved with global implementations are large in terms of time and money. Therefore, you should carefully consider your rollout strategy and plan to minimize risk of delays and definitely count on some. Specifically, you should ensure that a delay in one country does not delay the rest of the project globally. To do this, I recommend that you plan a pilot or phased strategy.
A pilot rollout rather than a big bang implementation allows you to ease into the implementation and organize the project without having to make large capital commitments up front, as you would with a big bang strategy. Although a phased or pilot approach may take a little longer to complete, the costs are much easier to control when work streams are modular and can start and stop without affecting the larger global project timelines.
A few key resources centralized on the global team can lay out the SAP HR design framework and provide training to the local resources responsible for providing the design requirements for their individual countries. The most important element is the early involvement and SAP HR training of the key resources on the global team and the local HR teams. Figure 2 illustrates a high-level approach for rolling out your entire system globally. The pilot countries and subsequent countries are rolled out according to normal Accelerated SAP (ASAP) methodology.

Figure 2
An example high-level approach for rolling out your entire system globally
The pilot rollout should test and re-work the global template before you extend it to the entire global organization. It would probably span one to three years of project work depending on your organization. You could further reduce this overview to regional work streams under country-specific rollouts. You would then implement each regional rollout using ASAP project methodology or internal corporate methodology. Small countries demand a specific rollout strategy. Refer to the “Small Country Rollout Strategy” sidebar for more information.
Tip 4. Find Qualified Team Members
Offshoring is cost effective in small doses for simple needs, but you can overdo it. The more ABAP development is offshored, the more up-front workload you place on consultants and local subject matter experts. Consultants and subject matter experts are typically more costly than developers. If they must rely too heavily on outsourced employees, then they have to create more detailed specifications and struggle with time zone differences to facilitate communications among the business, the project team, and technical resources. As a result, you may begin to offset savings from offshore development work with the higher cost of the local team.
I suggest that you enlist the help of a vendor with global experience (at least for the design phase). As I discussed above, it is most important to have the detailed technical SAP HR and country-specific knowledge at hand during the design of your global system. Some critical areas of the system are difficult to navigate due to conflicting country or company requirements.
Tip 5. Accurately Estimate Costs
Figure 3 is a chart of the various drivers for cost and timelines of a typical global implementation of SAP HR to which you should pay close attention in planning. The location of the different drivers depends largely on company-specific characteristics, but this shows what a company approaching a global implementation might face.

Figure 3
Costs associated with global HR implementations (shading indicates potentially high cost factors)
Tip 6. Communicate!
If you communicate accurately in your project, then you should encounter fewer errors. Follow this advice to keep your team on track:
- Many companies underestimate the effects of time zone differences. This is particularly important in areas in which a work stream may involve two or three different time zones.
Take the following example: You have offshored the ABAP development work for a US benefits vendor interface to a resource center in the Asia-Pacific region. The functional benefits resource is in the Eastern US (as is the vendor) and the technical ABAP lead (who manages all technical developments) is in Western Europe. At many points, especially during testing when quick turnaround is required, this arrangement presents challenges.
The time zone window in which these three people are able to speak collectively is non-existent assuming a regular 9 to 5 workday for all roles. Even at 8 am in the Eastern US, it would be 8 or 9 pm in Asia Pacific and vice versa. Many US benefits vendors are known for requiring big lead times on testing new interfaces and often cannot commit to a response on submitted test files within a day or two, instead requiring a week or more. Even without the added time zone issue, testing turnaround for third-party vendor interfaces adds significant development time. You must take this into consideration. Otherwise, you are sure to exceed the planned working days on ABAP development for complex interfaces. Third-party collaboration software (such as EMC2’s eRoom Collaboration) may assist you in organizing global work with version tracking and user authorization profiles. Another solution would be to put some employees on a later shift so they can communicate with people in another time zone.
- Plan your project with the knowledge that much of Europe may be on vacation, especially in the later months of the summer. If your major testing activities are due to take place during this time, then be sure to accommodate resource and country-specific holiday schedules or you will risk significant timeline delays.
- Another consideration when dealing with Europe is the language. You might be tempted to believe everybody is happy with English when working in a global team. However, local employees more often than not do not accept English. In addition, many legal requirements beyond statutory reporting inter- fere. Staff in many countries (France among them) could go to court if forced to do a performance review based on English forms.
- Bring communication about business initiatives planned in parallel or new initiatives created during the project to the attention of global and local teams. Most importantly, maintain transparency with your implementation partner on initiatives that directly affect system requirements or available resources. This includes, but is not limited to, anything that changes scope. Examples are company acquisitions and divestitures, changed or new systems (and vendors) sharing integration points with your global SAP HR system, and any functional HR initiatives and schedules that take resource time away from the implementation work. A well-defined, formal, and regular channel of communication among key project stakeholders and project leaders should support all of the above.
- A global change management effort should be part of your resource planning. The objective should be not only to usher in the implementation project, but also to address cultural differences among the various teams involved. Working hours, expectations of roles and responsibilities, and communication styles can all lead to unnecessary miscommunication. Clear and formally channeled communication is critical.
- The core global team, project sponsor, and project managers should tightly govern and highly centralize the change control process. Anticipate tough decisions on scope and cost that require the support of the global HR leadership. The global teams and local teams are at natural odds sometimes. The local teams strive to provide all of the functionality that their local users insist is critical. The global team is often put in a position to challenge this approach and if it is unable to effectively do so, scope and cost can spiral out of control.
Small Country Rollout Strategy
It’s difficult to group and roll out to numerous countries with very small headcounts. Many companies confront this problem in the planning stage by creating a team structure and work streams for the project plan by major regions. How you determine the regions usually depends on the following key factors:
- Headcount
- HR process similarity/business requirements
- Technical requirements (data conversion, time, benefits, payroll, finance interface needs)
- Proximity
Taking these four criteria into account, you can best determine how to group and roll out the small countries in scope. This naturally results in a clear division between countries with fewer than 100 to 200 employees and those with higher headcounts. The reasons typically relate to:
- Development time for interfaces, reports, and conversions for such small headcounts can usually be boiled down to very simple Excel sheets or text files
- Training and documentation needs are usually not significant because global SAP HR training materials normally cover 75% or more of the data maintenance required. As long as English is acceptable for training and documentation in the short term, you can hold costs to a minimum.
- The number of users in these countries is typically far below the number in larger countries and often the project directly affects only one or two HR users
As a result, you can normally implement those countries with small headcounts and relatively simple interfacing needs (such as a simple Excel download file) with involvement from (and in parallel with) the closest region or hub country. The global teams in PA design and quality assurance (QA) can assist. Those countries with more complex technical needs and 100 to 200 employees may require their own work stream and resources. However, you also must consider the programming effort required to migrate the legacy system to SAP HR and to continue to support the existing local payroll architecture.
In most cases, countries with headcounts lower than around 100 to 200 have very simple reporting and conversion needs. Therefore, you can easily group them by region and the regional teams can roll out each project. At the end of this stage, it is important to have a solid understanding of each country’s development and testing needs. You should also clearly understand what the before and after landscapes look like.
One pitfall to watch out for, particularly with small countries, is the design of a future landscape that encourages users to circumvent SAP HR maintenance in the interest of saving time in daily operations. Users are always thinking they’ll go back and manually update SAP HR after they get Payroll completed. This is a risk especially for small countries because SAP is only the HR data source versus the local Payroll system, which is probably capable of housing both HR and Payroll data for Payroll processing. If you lose data accuracy in these small countries, you will undoubtedly lose some of the value of your global reporting capabilities.
You should be sure that the source HR data for all systems locally resides in SAP HR. Ensure that no data duplication takes place that would encourage users to maintain one system in the short term (just to get Payroll out, for example). A quick way to undermine your global rollout is to not address local country data requirements fully and make data maintenance too difficult so that users begin to maintain SAP only for reporting purposes instead of day-to- day operations.
Charles Eubanks
Charles Eubanks is a senior project manager with more than 12 years of experience implementing SAP HR and Payroll systems globally.
You may contact the author at charles.eubanks@fuseanalytics.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.