Poor user adoption can ruin even the most technically sound SAP projects, a fact that has haunted project managers from the earliest days of the ERP system. Proper training and user buy-in are critical for ensuring the success of any SAP project.

Securing user adoption is even more challenging in a global project involving multiple sites with different languages and cultures. While SAP applications support dozens of the world’s most widely-used languages, successful project managers recognize the limitations of relying too heavily on that support.

“The chances that your users are going to start to use software just because it’s in their language are minimal without the proper training,” says Camilo Muñoz, founder and managing director of Translation Source. “The last mile is transferring the knowledge of how and why to use it. That’s not being accomplished at many companies.”

While adding a localization plan into an already complicated project blueprint may seem like a daunting exercise, Muñoz cites several reasons why companies should consider it. For one thing, it helps users learn their new or updated system more quickly. Also, the benefits last far longer than the early post-go-live period, says Muñoz.

“After you have the training in a given language, users are less likely to ask for support and more likely to do things right,” he says. “That is critical, because in a lot of cultures, things are not like in the US where you raise your hand if you don’t understand something. If you go to Asia or Latin America, these are sometimes cultural issues that prevent you from saying anything.”

When done properly, localization should add anywhere from ½% to 1% to the total project cost. The ongoing benefits, however, will pay for themselves, says Muñoz.

“The great thing is that it is a one-time expense. Ongoing maintenance and updates are really not a factor unless you go for a big rollout later on,” he says.

However, only a carefully-planned localization effort will yield positive results. Muñoz says abiding by the following six rules will help ensure your success.

Rule #1: Define Measurable Objectives

As with any project, establishing key goals and tracking progress is a critical component of success. The same applies to a localization plan, which should include objectives for budget, scope, timeline, technology, and deliverables.

Project managers must first assess the needs of users to determine what kind of localization the project will require. Localization plans will vary widely based on what applications are to be installed, what countries users are from, the training delivery method selected, and the urgency of the project.

“The top challenge is usually the timeline,” says Muñoz. “Sometimes you realize in the middle or end of an implementation that there’s a language or cultural dimension that needs to be addressed.”

When creating budgets for localization, Muñoz recommends starting with the vision for the final localized scenario and working backward to define the necessary requirements. Those requirements can then be broken down into discreet deliverables that project managers can track. For example, if there are 500 work instructions to be translated into 12 languages, that’s 6,000 documents the project team will be responsible for delivering.

Defining your technological objectives can be tricky, Muñoz says. Several popular software training tools are in the process of adding support for multi-language projects, yet those tools are still evolving and are not a substitute for implementing a full localization plan.

Rule #2: Integrate Your Localization Strategy with Your SAP Initiative

While the duties of your localization experts — either in-house or from consulting companies — are significantly different from those of your core project team, successful project managers will find a way to integrate all related tasks and initiatives.

For example, a global rollout of SAP ERP Human Capital Management (SAP ERP HCM) may require 40 to 50 project team members. Muñoz suggests that each non-English language will require another three to four team members. A project including support for multiple languages will require “a small army” of localization-focused resources.

“That’s the bad news. The good news is that if you do it properly, it can be streamlined and self-contained,” says Muñoz.

The bulk of these localization resources should work off-site, says Muñoz. The project manager should interact with only one or two leads from the localization team. Those leads are then responsible for managing the off-site team. The localization team’s efforts should be accounted for in the project manager’s regular reports, says Muñoz. He recommends weekly operations reports and monthly budget reports.    

While many of the larger consulting firms offer localization and translation services, Muñoz warns project managers to approach these offers carefully. Resources from those firms will leave your project in a few months, so it is critical that you insist on proper documentation of localization efforts.

Likewise, a professional document translation company may be able to translate all documents necessary for training. However, project managers must be careful to have all documentation reviewed by native speakers before approving the work.

“If you have enough people who understand the issues, you can set it up in such a way that the issues are handled,” says Muñoz. “The best thing to do is to plan ahead.”

Rule #3: Select and Manage Translation Assets

When it comes to translating your SAP transactions, documents, and other needs into multiple foreign languages, project managers have to rely on both human and technological resources. Both must be selected and managed carefully for success, says Muñoz.

The human component is often difficult for busy project managers, who don’t necessarily know what separates good translation resources from bad ones. The key is to familiarize yourself with the basic qualifications and experience that are most relevant.

“If you’re running a large SAP implementation, it’s not your job to find the best linguists,” says Muñoz. “However, it is important to know how people are selected. You don’t have to interview people — you just have to know that there are degrees in translation, and that some people have more experience than others.”

From a technological perspective, there are three common translation tools that project managers should understand (and ask about) when selecting a localization partner:

• Translation memories
• Bilingual glossaries
• Style guides

A translation memory is a software tool that stores translated sentences that may need to be reused. For example, a disclosure embedded in financial transactions may need to be repeated dozens or hundreds of times. The translation memory allows the localization team to quickly plug the disclosure in as necessary. Translation memories also help ensure consistency of usage across an entire deployment.

Bilingual glossaries (Figure 1) give users a quick, customized reference guide for terms that may be unfamiliar. The bilingual glossary works like a dictionary, where users can look up terms and read definitions in their native language. This helps ensure that users have a consistent understanding of what certain terms mean.

Figure 1

A sample bilingual glossary

Style guides are used to create the requirements of your localization plan. The style guide accounts for culture, language, industry, and company-specific needs, and gives explicit directions for the localization. These directions may include which terms to not translate, how to account for numbers, how to format characters, and grammar and punctuation instructions.

“For things that are very repetitive, like SAP, these tools are critical,” says Muñoz. “You can easily cut your localization budget in half by using them.”

Rule #4: Streamline Project Management

As mentioned in the discussion of Rule #2, an effective localization plan may add significant headcount to your project team. It is important, Muñoz says, for the project manager to streamline the management of this team to move the project forward.

“In a high pressure environment like an SAP implementation, where people may be working 70 or 80 hours a week, it’s critical that you have one person controlling this part of the process,” he says.

For project managers, the most difficult aspect of a localization effort may be predicting and managing the translation budget, according to Muñoz. Most translation companies are paid per word, with repeat phrases billed at 40% to 50% of the original translation cost. The non-translation localization costs are comparatively minor, Muñoz says, consisting mainly of technology integration and training costs.

Understanding the composition of the localization team is also important for project management. The team should include leads, translators, an editor, a desktop publisher, and an in-country reviewer to verify the work.

The translation and localization work should be divided into phases and managed within the overall project blueprint. A sample localization plan is shown in Figure 2.

Figure 2

A localization plan grouped by phases and responsibility

Rule #5: Use Cultural Challenges to Your Advantage

Cultural differences can have a major impact on the success of any SAP project. However, Muñoz says there are ways to understand major cultural differences and use them to ensure high adoption rates.

“It’s easy to be blindsided by cultural dimensions,” he says. “However, once you familiarize yourself with them they become self-evident. People in Japan don’t think the same as people in America. Having a structured approach to dealing with cultures is a good way to pinpoint potential challenges.”

Muñoz recommends using Geert Hofstede’s cultural dimensions as a framework for approaching these issues. Hofstede catalogs the differences between cultures along several lines such as the Power Distance Index — defined loosely as the relative acceptance of power inequality among the less-powerful members of any group. See the sidebar “The Geert Hofstede Cultural Dimensions” for a rundown of the five cultural dimensions.

Davin Wilfrid

Davin Wilfrid was a writer and editor for SAPinsider and SAP Experts. He contributed case studies and research projects aimed at helping the SAP ecosystem get the most out of their existing technology investments.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.