If you are planning a global SAP rollout, it’s very likely that translation is on your to-do list. But since translation is often a great unknown (since it is not part of most SAP projects) it can be daunting to come up with a good cost estimate. Let’s take a look at the various factors that influence the cost of SAP translation.
Complexity and Footprint
Translation costs depend on the size of your SAP implementation, as well as on its complexity (that is on how much custom functionality you have added). The fact is, smaller SAP translation projects can cost less than 10 percent of big ones – and every translation project is different. For the purpose of translating, you can gauge the size and footprint of your SAP implementation by looking at the number of systems and the number of SAP modules that require translation.
The complexity of your implementation is most easily estimated by how long ago your organization first implemented SAP. If you have recently done a greenfield SAP S/4HANA implementation or you are in the midst of one, you’re in luck: It’s very likely you were able to leverage a lot of standard SAP processes and were able to keep custom code to a minimum. But the older your SAP implementation is, the more likely it is that there will be large numbers of Z transactions and programs. And more custom code means more custom user interfaces, which means more translatable texts.
The texts you do need to translate are also less likely to be properly internationalized the older your installation is. This means you may also have to deal with larger-than-usual numbers of hard-coded texts, for example. Your custom developments were also probably done with on a release where the development tools did not automatically account for texts in other languages often being longer than in English, and you may end up extending the field length of large numbers of text elements and Screen Painter texts. In addition, defining the scope of your project becomes trickier on older installations, since you will have many development packages, where only some of the objects will be translation-relevant. Other objects in those packages will not be needed at all in the country that you are rolling out to, or they will be completely obsolete. This means the scoping process takes longer, and you may need specialized tools.
Count Your Stacks
Another aspect is that with every additional user interface technology deployed, translating becomes more complex. This holds true for the various SAP forms technologies, for Report Writer, BW, and, of course, for SAP Fiori. The truth is, SAP‘s new user interface technology makes the end user‘s life easier, but for translation, it’s an additional technology stack to deal with. After all, while SAP Fiori screens come with their own texts from their own repository, they also surface texts from the SAP backend. That means things get more complicated. And that is true for every new type of UI you add to the mix, whether it is made by SAP or not.
Master Data Texts – In or Out?
An important question is whether you include master data texts in your translation scope. In many projects, master data tables are either completely out of scope, or the only thing that needs to be translated is a handful of financial master data, such as the chart of accounts. The most common reason for this, especially with mid-sized companies, is that large-scale master data translation would be too expensive.
With master data, the volume of text to be translated can be be very large, especially when you include material texts. And even some financial master data can contain many thousands of lines, such as cost elements or cost centers. So a common approach is to show English texts, irrespective of the language a user is logged onto. Another common approach is to separate out master data migration and translation into a separate project and not make it part of an SAP translation project at all. The bigger the company, the more common this second approach is. And since master data translation poses challenges that are quite different from SAP translation and require a different, albeit adjacent skill set, it’s often best handled by a dedicated team.
Testing Expectations
Testing also heavily influences the cost of SAP translation projects. The main factors are test scope and test depth. If you test every last F4 help (SAP GUI) or every dropdown menu (SAP Fiori) on every screens, your testing effort may end up costing as much as the entire translation project. A more common approach is to either only do spot checks, or to only test the texts that are immediately visible on a screen. And if you can coordinate language testing a with a user acceptance test that you have to do anyway, that is also a distinct advantage.
Project Management and Methodology
As with every project, the better it is run, the better you are able to keep costs in check. A large part of this comes down to methodology used and the experience of the team doing the implementation. Since SAP translation is not something that is top of mind for most SAP consultants, but also can be surprisingly complex, it is a good idea to seek external help if you don’t have this skill set covered by your in-house teams.
It’s true that one of the biggest levers you can pull to keep translation costs down is to get expert advice. That sounds pretty obvious, and, of course, it’s the kind of advice you would expect to get get from someone specializing in “consultancy and tools for SAP translation”. But that does not make it any less true that costs for SAP translation projects can easily spiral out of control if you jump in unprepared, and a few hours with an experienced SAP translation consultant can set you on the right track to determine what the right approach is for you, how much you can handle in-house, and what to outsource.
Learn more about our SAP translation consulting services…