|
Localization service providers translating ERP software packages or SAP support had better make sure to use translators who know these domains inside out and should not rely on translators just looking at some glossaries. Localization companies now need to face these new challenges and higher customer demands. This was one of the conclusions in my article “The Evolution of Localization” (MultiLingual Computing & Technology #57 Volume 14 Issue 5, supplement “Localization”).
Enterprise resource planning (ERP) is a domain where much translation is going on. SAP, for example, the leading provider of ERP systems, employs hundreds of translators who produce localized versions of the various SAP solutions. In addition to the in-house localization teams, SAP partners with localization vendors and freelance translators to ensure scalability or to access specific domain knowledge. More than 100 million words are translated each year, primarily consisting of software strings, documentation, training courses and support notes.
Many companies implementing ERP systems do so on a global basis, inherently making global business practices and support for multiple languages a requirement. ERP solution providers have been quick to realize the strategic importance of this requirement.
In this article I will introduce the complexities of global ERP deployments with a focus on the challenges of supporting multiple languages.
WHAT IS ERP?
ERP systems attempt to integrate all departments and functions across a company onto a single system. ERP automates the tasks involved in performing a business process. An example is order fulfillment, which involves taking an order from a customer, shipping it and billing for it.
Most ERP systems feature components for finance management, logistics, human resources, manufacturing, customer relationship management, procurement and supply-chain management.
Decades ago, ERP deployments were primarily countryspecific. Today, we frequently see global ERP deployments by multinationals who want to capture and standardize their business processes across the globe. One of the main business drivers for global ERP deployments is the centralization of data in a single repository to assess performance on a global scale rather than for each individual market. Increased globalization of business practices and value chains has called the need for a global overview of business data.
Examples of companies selling ERP software are SAP, PeopleSoft, Oracle and Microsoft Business Solutions (formerly Great Plains). SAP has the largest market share (approximately 25%), followed by Oracle, PeopleSoft, Sage and Microsoft. A typical ERP implementation project has these phases: a fit/gap analysis to define business processes and the need for customization; system design and development; data conversions from legacy systems; testing of the new system; training of the super-users and end users; and deployment.
Most ERP implementations are coordinated by consulting or systems integration firms such as IBM Global Services or BearingPoint, at least in the initial stages. Consultants work with employees of the company that is implementing ERP to define and tweak end-to-end business processes, customize the system, develop new features if required and test the system Global implementations typically are first rolled out in a few pilot markets, followed by additional markets or groups of markets.#p#分页标题#e#
GLOBAL ERP DEPLOYMENTS
Global ERP deployments run, on average, between one and three years. The number of modules used and the global reach of the deployment are factors that influence the time it takes to implement an ERP solution. Some organizations decide to implement only the human resources solution globally, for example. Others implement the full ERP solution across a wide range of markets or regions.
The global rollout schedule is normally based on the system needs in the respective markets. Although language or translation is hardly ever considered as a critical factor during planning, some companies prefer to roll out new systems in English-speaking countries first to avoid the complexities of multilingualism.
Most ERP systems can also be tailored to the industry of the company that is implementing the system. SAP, for example, now has 23 distinct industry portfolios including automotive, health care, media and telecommunications.
A recent Gartner study outlined seven generic issues that should always be considered in a global ERP deployment project: language — code page support and system translation; currency — dual- or multiple-base currency capabilities; simultaneous operation of multilanguage and multicurrency on a single system — Unicode support; statutory compliance — complying with local legal, taxation and accounting rules; implementation services — regional consultant staffing and travel; product support — local support or global 24/7 support; and upgrade timing and availability — delays for language version updates.
Although the business in most organizations is structured according to product group, enterprise function or geography, in global ERP deployments there will be combinations of these dimensions.http://www.ukassignment.org/yingguozuoye/ying_liu_zuo_dai_/
WHAT IS ERP LOCALIZATION?
The term ERP localization is used in various different contexts: localization of the user interface text of the ERP system itself; of the system to comply to market-specific business processes; of any custom developments made on the system; and/or localization/translation of support documentation and training materials.
Most ERP applications and systems are provided in multiple languages by default. As I mentioned earlier, most ERP solution providers localize their products in a large number of languages. Most ERP vendors outsource their product localization.
Next, the word localization is also used to describe the process of customizing the product’s functionality to the business practices of a particular market. Some ERP manufacturers use the term a localization to refer to a specific country version or extension of their product. ERP solutions are normally available in “country versions” and “language versions.”
Oracle, for example, sells a fully globalized product, stating, “Oracle E-Business Suite supports multiple languages, unique global business practices, and local statutory and regulatory requirements, such as the Euro — powerful capabilities that include localizations for 43 countries and support for 29 languages.”#p#分页标题#e#
After tailoring a solution to suit local market and industry domain requirements, a company implementing an ERP system may still require customization of the product, simply to make the ERP product reflect a company’s existing business processes. Prior to deployment, all critical business processes are analyzed and compared with the standard functionality offered by the ERP product. In case of major discrepancies, the decision is made to either change the process to comply with the ERP package or to customize the software to follow existing processes. During this fit/gap process, the decision can be made to provide customizations in the local language or to leave them in English. Using a local language version of an ERP package with customizations in English could, in fact, produce even a user interface consisting of fields or controls in different languages.
The final level of localization in global ERP implementations is normally called “translation” by organizations implementing ERP and refers to the translation of end-user reference documentation or training materials. Change management practices common to ERP deployments dictate extensive training for end users, and training materials are normally provided in the local language. To complicate matters even more, support documentation is often translated from a base language, for example, English, into a select number of target languages, such as French and Spanish. Then it’s up to the individual market to create “localizations” of these translations — that is, to adapt the translated materials to local needs and practices. This approach obviously requires careful version control and update management.
TECHNICAL CONSIDERATIONS
In addition to the business and procedural challenges to deploying an ERP system globally, a global system also has many technical complexities. Some of the technical issues to consider when deploying an ERP package for multiple countries include globalization features — multiple time zones, currencies, calendars, address formats and data standards; support for various character sets — on-screen display, storage of data and output to various devices such as faxes or printers; efficient global system landscape — for example, one central global system or distributed systems in each market or region.
Considering the amount of data processed by a global ERP system, it is extremely important to create the right balance between centralized data and local deployment.
Globalization features. The first challenge has been addressed by most ERP solution providers for many years, simply to meet customer demands that were increasingly global. SAP especially has been a forerunner in implementing advanced globalization features in its products.
According to SAP’s white paper Global Solutions Without Boundaries, “With business solutions based on mySAP.com, you can adapt your operations to each country individually. SAP has applied local experiences and knowledge to develop country versions that meet the unique business requirements of each country.”#p#分页标题#e#
An Oracle developer recently stated, “In addition to this country-specific functionality, the standard Oracle Applications products have an underlying architecture which is capable of supporting global business practices, for example, with a flexible chart of accounts, tax reporting ledger, shared service capabilities and multiple organizations structures. Our features are all designed and built with a global perspective, and, increasingly, the country-specific requirements are being integrated into the standard products.
Statutory compliance may be the hardest globalization feature for ERP solution providers to maintain, especially because some countries such as Brazil change their regulations frequently.
Character sets. The technical complexities of supporting multiple languages in global ERP solutions have always been numerous, but these are being greatly simplified by the adoption of Unicode by most providers. Character-set support is critical, for example, for the storage of multilingual data in a central repository. Even though most ERP solutions had workarounds, creating one central repository containing data in multiple character sets has always been cumbersome.
A growing number of solutions now support Unicode, which makes the character set issue less stringent, especially for new implementations that don’t have to deal with too many data conversions and legacy systems.
According to the PeopleSoft Web site, “PeopleSoft is one of the first to embrace Unicode fully, which allows you to run PeopleSoft 8 applications simultaneously in more than 100 languages. This capability empowers you to store data from any language in a single database instance and build applications with global functionality within a single code module.”
System landscape. Implementing one ERP central system to manage business processes and data worldwide obviously has many advantages such as central control, reporting and IT efficiencies, but it is often simply not feasible for size and performance reasons. Most organizations, therefore, adapt the ERP implementation to the current business environment — only centralizing, for example, those processes that are already global.
Global ERP systems can be deployed in several layers, for example, Global, Regional and Local. Each layer has separate systems, customizations, functionality and translation needs. Organizations can choose which business processes are placed in which layer.
LANGUAGE CONSIDERATIONS
Every organization implementing software globally has to make some strategic decisions related to language and translation of systems or documentation.
The translation strategy should aim to find answers to the following questions: Which languages do we need to cover and how do we prioritize? What is the impact of language support on our system landscape? What do we translate and when do we start? Who will own the translation initiative and budget? Who will be involved in the execution? How can we minimize translation costs and still guarantee quality? How do we organize and automate the translation process? The most important decision to be made in global ERP implementations is to what extent the system (user interface) will be translated. Common criteria for this decision include: Availability of the module in the required language. Most, but not all modules are provided in all languages — that is, the language gap must be identified.#p#分页标题#e#
Business and regulatory requirements in the markets. Most countries have a legal requirement to provide all financial reports for taxation in the local language.
Level of customization. Customizations need to be translated from scratch because they are not provided in the local language by the system vendor.
Technical infrastructure limitations. Code pages, Unicode, hardware requirements for language packs, data conversions, response times and so on.
Availability of technical resources to set up and support translation environments and provide quality translations. Translation business case. Number of users, market demands, frequency of use, return on investment and so on. Although translation of the system is most complex, the supporting documentation and training materials normally contain the most words to translate.
One major issue with ERP translation programs is that organizations often do not build a translation phase into their implementation plans. This is particularly true in the case of large global corporations such as manufacturers that have not previously had to deal with centralized, large-scale translation to any extent.
The impact of translation should not be underestimated. It forms a large piece of the change management activities. Using training material in English to train users in international markets, for example, might considerably slow down the use and adoption of the new system.
A translation strategy should ideally be clearly defined early in the deployment scoping and planning phase. This way the implementation teams can gain a much better idea of the work, costs and time involved in delivering a translated solution to international markets.
Once a translation strategy has been defined, it is important to involve qualified resources for the translation work. Translators working on ERP programs need to have the technical, terminological and domain expertise to produce translations that speak to the business users of the system or the people being trained.
A supply-chain management ERP module will require different skills and terminology than a human resources management module, for example, even though some commonalities exist. In some cases, the same term may even have different meanings and require different translations. An example often used by SAP is the German word Vorgang. Depending on the context or application, it can have three different English translations: activity, transaction or operation.
It is virtually impossible to be a subject matter expert in all areas that ERP systems cover. During implementation, functional consultants may define the business processes in each of the core areas such as finance, logistics and human resources. It is not realistic to expect knowledge of all these fields from one or two translators.
So, global ERP implementations should be supported by a strong and scalable team of translators who have a knowledge of ERP in general and specific subdomains in particular. After dealing with all the business-related and technical complexities of deploying an ERP system on a global basis, it would be a shame if that investment were devaluated by presenting end users with a user interface or supporting documentation that is badly localized. #p#分页标题#e#
|
