In the globalised world that we live in today, the question of how to share business processes across multiple countries and multiple language is a very real one. Global organisations often deliver their end-to-end processes across both several languages and several countries. In order to deliver a consistent, quality product or service, it is essential that they can share their business processes across several languages and countries too.
This article looks at how this can be achieved.
The initial challenge is of course to establish a standard process that will work in multiple countries; but for the purposes of this article I am going to assume that this has been achieved.
Now how to share it?
The start point is to ensure that the platform used for sharing the process is web based. Websites and intranets can generally be accessed from anywhere across the world. Performance may be a little bit slower if a person accesses a web site from, say the West Coast USA, that is hosted somewhere like Italy, but by and large multiple country access poses no difficulties.
The difficulties arise when the person in the West Coast USA accesses content on a sever in Italy that is written in Italian, and they want to read it in English. How is that done?
Let’s first deal with “auto-translation” as a possible solution. There are now a growing number of tools that can translate text into any language.
Unfortunately, our experience at Triaster suggests that in late 2016 this is not yet a sufficiently accurate technology to entrust with tasks such as translating a business process. Business processes tend to contain technical language, jargon, and untranslatable short-hands. Auto-translation is not yet fit for purpose, especially in processes where incorrect interpretation might cause harm. That means therefore that each piece of text in the process model needs to be translated by a human into the language of the consumer.
At Triaster, we refer to this as a “language translation database”, it is simply each piece of text in the process model with its primary language in one column, and all the language translations in the other columns. A spreadsheet is an ideal solution for a straightforward implementation.
For example, this process:
could have a language translation database in Excel similar to:
By disconnecting the language translation strings from the process itself, it makes it possible for a process to “display itself” in a variety of languages, and quality control is moved to checking the single translation database rather than inspection of each process.
The next thing to deal with is language display. Not all languages are written left to right, top to bottom with the symbols of the Roman script. Arabic and Hebrew for example are written right to left using Arabic script. You must therefore ensure that the tools that are used to capture and share your business processes, and the language translation database itself, supports the scripts and directionality of all the languages you need to support. This capability should not be assumed, there are still many systems out there that only support left to right - top to bottom directionality of text.
The term “Unicode support” is the technical term for a product that can display characters from several scripts – but double-check this because there are varying levels and quality of support. From our experience Microsoft Office offers very good support for all languages.
So, you have produced your business process in the primary language. You have a language translation database in something like say Excel, and you have tools support for all the scripts and directionality you need to support. What strategy should you now use to display your business processes in the appropriate language for the different user groups?
The model we recommend at Triaster is to host the standardised business process in a Process Library. A Process Library is a website with a globally unique URL. Then for each language translation, host the corresponding translated processes in a Process Library with a language suffix on its URL (or in a language specific sub-domain).
For example, if you go to: http://processlibraries.triaster.co.uk you can see an example process library. If we were to translate this to Spanish, we could simply create processlibraries-spanish.triaster.co.uk and so on, or processlibraries.spanish.triaster.co.uk.
This model is scalable, and it means things like menu options, report names and so on can also be language specific.
For any organisation looking to share standard business processes across Multiple Countries and Multiple Languages the two things that matter most are:
Any manual work, other than translating the text itself, is likely to lead to inconsistencies and errors.
The Triaster platform has fully automated support for the approach outlined above, so if you need to publish the same process in several languages, we have the tools and training for you to achieve this right out of the box.
As this is a very specific topic there are no directly related articles, but please do contact us on +44 (0)207 770 8053 or michael.cousins@triaster.co.uk if you would like to discuss the subject further with me, or learn more about the approach. Triaster are always happy to chat through projects you may be involved in or are considering, and with no obligation to pursue anything further past the initial conversation. You may also find the following report helpful.
Related Articles:
How to Avoid the Problem of a Complex Business Process Management (BPM) System
Inconsistent working: How can I get people to work consistently?