Brian Lutz is Knowledge Architect at SAP. Brian has worked in the area of translation at SAP for over 25 years, starting as a translator and moving later into various coordination and strategic project management roles. He currently co-leads the program implementing localization technology as part of SAP’s translation landscape.
Brian, can you list some of the main pain points for your company that made you consider making changes to your localization program to make it more effective or productive?
There were really three main factors. I think that that made us want to make the shift. The first one has to do with this proprietary approach that we originally had. We’ve always kept trying to adapt our own tools to make them more efficient and more modern as much as possible, but that’s very hard to do. The effect of that is that some tools can take a couple of days to learn how to use, and then a lot of practice to learn how to use them well.
This was a bit of a hard sell, so scaling becomes difficult when you have this type of situation. The second point was that SAP also diversified in its technological approach. In particular, SAP was buying lots of companies and merging with other companies over the years, and these companies often brought their own localization processes with them. Some of them were already familiar with translation management systems (TMS) that were on the market, and that gave us insight into that field as well.
We therefore realized that there are formats out there that simply work better with a system like a TMS than with our legacy system. So that was an additional motivating factor to look for a solution outside SAP. And finally, the third part was the cloud revolution that really took hold in the just in the last decade or so.
What has the transition to the cloud brought about?
The software industry used to deliver big releases every 12-18 months. We’d have a considerable time frame that came with huge translation volumes, and then everything would quiet down for a few months. It’s not like that anymore. Now, development is constantly ongoing, and updates to the cloud systems are on a weekly or bi-weekly basis for most companies. That means that updates to the UI and to the content also need to happen on a weekly or bi-weekly basis.
Success Stories
How Acolad divided by 8 the number of steps required to translate content
And what are the consequences of this shift in delivery times?
The amount that we need to get translated is a lot smaller on a project level and delivery times are a lot faster. We therefore needed to have a tool that was going to enable us to work with these smaller volumes and faster delivery times.
How do your market position and go-to-market benefit from the successful localization program that you’re running right now?
Our board never hesitates to tell us that we don’t sell products, we sell solutions. Our solution is, of course, a suite of software that can encompass a number of components and perhaps even components that are developed and serviced by other companies. Customers put these components together and pick the functions that they want to use, and they might be crossing a lot of different systems, which in the past had completely different language scopes.
Therefore, you couldn’t sell to a company in, say, Spain, if half of the components were not in Spanish. You just can’t sell a product like that. Companies need to be able to see all of the screens that they use in their local language. So we’ve basically gone to a harmonized-suite approach with regard to our language strategy as well, and we’re aiming to get the language scope harmonized across the whole of the SAP suite.
Why?
Because this is a big part of how SAP approaches the market. One of the really big selling points is that we have such a strong language scope. Even for the smallest products, it’s still well over 20 languages that we offer, and it’s a really big benefit. It’s also one of the reasons why SAP is a leader out there.
The amount that we need to get translated is a lot smaller on a project level and delivery times are a lot faster. We therefore needed to have a tool that was going to enable us to work with these smaller volumes and faster delivery times.
Brian Lutz
Knowledge Architect
Tell us a little bit more about the tools and processes that you adopted that have now become essential for you, and what problems have they solved in particular.
We have always had a focus on simship, even back in the day when it was still a word — I don’t think anyone says sim ship anymore because it’s just a given [laughs]. So we’ve always needed to have some kind of integration between the development environment and the translation environment. This is even more the case, though, now in the cloud environment, where you need to have updates translated on a very short turnaround. We have products where we need to deliver translations on a daily basis, and we actually get source language updates twice a day and are expected to deliver language translations twice a day. And that’s for many languages at the same time. So we need to have a tight integration between the actual source repositories and the translation environment.
How does this integration work?
This is something where we see the real strength of XTM. It’s been helping us a lot. We can use the APIs that XTM has to reach into the middleware, into our repositories, and pull out the text changes, send them into the system where they’re automatically routed to the translation suppliers for our 30 or however many languages that product needs, and the suppliers can even help them directly automatically to an individual translator if they if they choose to do so.
So, real emphasis on automation
We can actually have a no-touch process where the source gets to the translator without any human intervention in a best-case scenario. And if the translator then quickly does the translation, the text can come back in the same manner. So we have a very low-touch, no-touch project management. And this is our goal is really to be as no-touch as possible in that regard.
This is the only way that we can really keep up with the speed that our internal customers are expecting. And this is of course, only possible because of the APIs.
The standardization journey never really stops. We need to improve how we can make our processes more simple to work better with the tooling that we have.”
Could you summarize some of the benefits that having a successful localization program enabled your company to do?
I’ll highlight two benefits that I think are worth worth mentioning here.
One, it relates to the APIs, because beyond that, it’s about automatic translation. We have tons of [translation] volume that we have to pump through a translation system. We don’t want to have to send all of it to human translators. That would just take too much time as well. So we’ve been able to use all of the translation content that we’ve put together over the last 40 years to not only fill memories and do things like context matching, but also to develop our own machine-translation system, the Safety Translation Hub, which actually integrates with XTM. Between SAP and the automatic leveraging, we actually achieve a leveraging rate or an automatic translation rate of over 95% of the text that goes through our infrastructure.
That means that what actually needs to be “touched” by human translators is just a minimum of what we actually get from our tech suppliers. And this is a really, really great achievement. That number keeps getting a little bit better incrementally, but we’re close enough to hundred percent. It’s hard to make a big leap at that point.
And the second one?
The other thing that is a real benefit of our current solution with XTM is in the area of customer satisfaction. As I mentioned, the translation volumes are huge, especially with documentation. In fact, so much so, that for many of our products we have only delivered the documentation in English or in just a couple of languages, but never the full language scope of all of the countries that we’re trying to target with those products.
With XTM, what we are able to do now for the first time, is to actually provide this documentation translated in a way to the market quickly with a machine-translated version. At the same time, we can route the machine translation through a post-editing process and deliver the post-edited versions shortly after.
Do you have an example of this process that you could share?
If we set up a production process so that a new version goes out every week or so, we could send out machine translation into, say, Japanese, and the market already has that available. But if we know that the Japanese market is particularly quality-conscious or really needs special attention, we can do the post-editing and deliver that shortly afterwards automatically. I imagine that we will do a lot more of this for a lot more markets in the coming months as well. But this is something that we see a huge benefit for.
And lastly, what are the next steps on this journey?
The standardization journey never really stops. We need to improve how we can make our processes more simple to work better with the tooling that we have, and at the same time enhance the tools so that our processes run more smoothly.
And of course we also hope that the quality improves over time so that we can be even more reliant on that and need even less human translation. Or let’s say not less human translation total, because we still need as much human translation, but more, more volume without more human translation.
Want to learn more about how software companies can make their translation processes more efficient?
Watch our on-demand webinar or read more about successful localization for life-science companies in our dedicated page.
Related articles
Looking for more content? Check out these suggestions.
