"Glocalization" or the five pillars of a localized software offering

RIO DE JANEIRO
In Brazil where I am assisting a customer in their post-PeopleSoft strategy (among the choices confronting us: keep the global system or go with a local one?), I am constantly reminded of what it means to have an HR system localized for different markets, especially when the product is initially American. And time and again I can't help but witness how far HR systems have to go before becoming truly international - contrary to vendors' claims that they are "global." Indeed many US software firms suffer from the "build once, run many" syndrome believing that "if it's good for the US, it's good for the rest of the world."  You can safely bet your HR project budget that most vendors attending the HR Technology Conference in Chicago later this month will have in their glossy product brochures, slick demo presentations and sexy websites the words "international", "global" and "localized," purporting to cater to the needs of customers hailing from different regions of the world. You can also safely bet the same amount (actually even more) that most of these boastful claims are based on anything but the truth. Why? Simply, because to have a truly global (or international) system you need to localize (or adapt) your product to the country-specific needs of the markets you want to enter: what I call a "glocal" approach, term which I created five years ago when I was at Oracle and recently used as a chapter title in my book High-Tech Planet: Secrets of an IT Road Warrior (available from Amazon).  However, and here's the rub, a truly "glocal" system needs to cover five areas without which it fails its purpose. Call them the five pillars of a localized HR offering.

1. Translation:  Since of all a company's functions, HR (maybe along with Finance) is the most parochial (all those mystifying national rules), it is a no-brainer to say that an English-only system will fail miserably in countries where it is not the native language or widely used as a second, business language (such as India or Africa.) In countries where English is, at best, a third language (such as the one I'm currently in, but also China, most Spanish-speaking countries, the Arab world, Japan, a good portion of Europe) users will not even bother to look at your system, let alone use it to complete a new-hire process, calculate employee overtime or evaluate their annual performance. That English-only software will remain pure shelfware. Now, some smart vendor might think that the emergence of online translators (such as the Google tool) can help them save on their translation budget. Not  a chance. I have seen the results of automated translation in HR software and it is appalling: inconsistency, inaccuracy and incomprehension are the inevitable results of any translation carried out on the cheap. But, even with human translation, issues abound.

For one thing, let's say you have decided to enter the Brazilian market and happen to have a native from  Lisbon, Portugal, on your payroll. Good, he'll do the English-to-Portuguese translation for me, you might think (actually, a true situation I saw at PeopleSoft in the late 1990's). Well, to paraphrase Churchill, Portugal and Brazil are two countries separated by the same language. Portuguese as spoken and used in Brazil varies markedly from the one used in Europe: administrative, legal, business terms are quite different, even more so than between Britain and the US, or between Spanish-speaking South America and Spain. The users will be so mystified that their chances of using your system are going to be very limited.

Second, remember that translation should take into account industry terms: your system may refer to "employees" as the people in your system, and in France if the customer is a private business, "salarié" would be fine; but if they are a government organization, "fonctionnaire" or "agent" will be the norm. The same thing applies in other Latin-based languages.

Third, if you think that you can get away with translating just the data fields and labels along with some reports, think again. Even local reports (for instance, those required by one country such as the Bilan social in France) will have to be translated: what will your (English-speaking) Australia-based Global Head of HR make of a report she can see but can't understand? What about those error messages that still pop up in German for UK users of SAP? And , please, have some respect for your customers: avoid mixed-language screens with some fields translated, others not. Of course, if your system's technology isn't Unicode-based, your customer won't have any other choice but see those maddening hieroglyphics ("Does it mean I have promoted or fired this one?") And, last but certainly, not least, don't forget user's manuals and online support. So many vendors fail here, by producing poorly translated documents that make using the software quite an arduous task.

2. Local data: Translation is necessary for the success of your HR system, it is hardly sufficient to ensure it. Every country, and sub-division within the country (such as American states, Spanish regions, Canadian provinces) need to track data that are unique to them. For some perverted reason, data that need to be tracked in one country (say, ethnic background in the US or religion in Germany) is forbidden in others (France.) You have to make sure that all the statutorily required data is available but only viewable by the right users, based on locale (or legislation, depending on how your system partitions data.)  Even data common to all countries (think ZIP codes or Social Security numbers) are structured and formatted differently from one country to another (digits in the US, British-inspired alphanumerals in neighboring Canada). Although I'm making this paragraph short (in comparison with the previous one on translation) it is the most complex one: do a lousy job of it, and you ruin your chances of having a decent system and ensuring user adoption. I remember in the mid-2000's being mystified by the fact that at Oracle we had spent several million dollars to localize the HR offering for the Italian market, and yet a dozen Italian customers didn't use it: they would just license the core HR system and then build their own Italian localization. When I asked them why, the answer was: "Your Italian version misses so many of our requirements that we prefer to build it ourselves." The lesson for vendors is simple: don't skimp on this. Make a comprehensive list of all data needed to sell in your target market. Hire local people, preferably have them be based in that market you want to enter, make sure they interact with locals (such as sales, customers, opinion leaders, consultants) to ensure the data  reflect most of the requirements expected from that market.

3. Localized rules and processes:  If you've decided to enter a market with your own payroll product (versus a partnership with a local vendor), this pillar needs to be built, as payroll rules vary from country to country, and their level of complexity may be such that changes to your core payroll engine may have to be considered. In some Middle Eastern countries such as Saudi Arabia, a customer (especially from the public sector) may require a lunar calendar of 30-day months (as opposed to the Gregorian calendar used  elsewhere), something most systems can't deal with. But even without payroll, some other modules in your offering (HR Administration, Benefits) may need to be adapted to some local rules. Again, rules and processes need to reflect the needs of a country's decentralized system of government. For instance, PeopleSoft claims to have a localized payroll for China, but in reality it includes in its "vanilla" product only the earnings and deductions for the Beijing, Shanghai and Canton (Guangzhou) provinces. What about the other 19 provinces with their hundreds of millions of employees? Completely non-existent in PeopleSoft's world view.

4. Local reports: I mentioned earlier the case of a local report that needs to be viewed by an international HR executive. If there is one thing where labor lawmakers have in common all over the world it is their "creative" output: the number of reports that have to be filed with the Tax Office, the Labor Department, the Equal Opportunities Commission, Social Security etc. runs in the hundreds ...per country! -  and each has its own reporting and formatting requirements. A nightmare when it had to be done manually - not less of one when you have to build it as part of a standard software offering. The success of a global system is directly correlated to whether, and how well, local reports are made available. One reason why local HR systems still dominate their markets versus the global vendors is due to their strength in this area.

5. Look and feel: Last but certainly not least is the weakest link in the "glocal" offering. Every culture has a unique way of interacting with systems, figures and data as well as doing business. A US-made software largely reflects the way American users work, not that of a European or South American or Chinese or Arab user. Since we know that a major reason for HR technology project failures is user rejection, why don't vendors do a better job at this? Examples of what is needed go beyond date formats and numeral separators. It can be the number of screens needed to complete a transaction (in some cultures, people would rather have a longer screen than several ones to toggle through.) That this is still Work in Progress is obvious from the fact that if you look at SAP, Oracle, Meta4 and HR Access in English (and without knowing which is which) after a few minutes you'll be able to guess that the first one was made by German engineers, the second one by an American company, the third is clearly Spanish and the last one's French flavor is unmistakable (despite having been owned for the past 15 years by American companies IBM and Fidelity.)

One last comment: you may sometimes hear in HR softspeak that a localized feature has been globalized. This is more than semantic quibbling. The way localized software has been traditionally delivered is though a specific patch. You buy the core system, install it and as you enter more countries you decide to turn on the UK features or the South African ones. Well, unless said features have been globalized (that is put in the core system and therefore open to all users) you'll need to install the specific patch that includes that country localization (that feature is said to be localized.) The problem is that often a patch is only valid with a particular release, meaning that you may have to either wait until the next upgrade (in the meantime, how are you going to pay those thousand new employees you have in Argentina?)  or proceed with a new installation, both unpalatable choices. Vendors don't share with you these little "details" when they sell you their "global" solution.

Localization can sometimes become a question of life and death. In Quentin Tarantino's World War II movie Inglourious Basterds, a British undercover agent tries to infiltrate a group of Nazi officers  by pretending to be German. He befriends them in a Paris café and everything is going hunky-dory until he orders three drinks. What gives him away is that he holds the wrong set of fingers, exposing himself as a fraud (and losing his life in the gun battle that ensues.) Although he spoke perfect German, he had not "localized" his behavior sufficiently well. Hopefully, the consequences with badly localized HR software don't have to be as tragic.

(A list of which countries around the world have been localized by the major HR vendors is available from www.AhmedLimam.com - Vendor Localization Footprint)