Thursday March 31, 2005

Myth #7 - IT depts., are you feeling lucky?

In this, the next installment (or instalment, if you prefer) of the myths series, we explore something nearer to our hearts^H^H^H^H^H^Hselves:

"All company employees speak English, so only English needs to be supported by internal tools."

Seems pretty straightforward, huh? But the question is, what are internal tools used for? Even if all employees speak and read English, their data may not be in English. If they live in Beijing, it might make sense to store their Chinese addresses, for example.

Much of the data that internal tools process is not employee data, however. We at Sun have bug tracking and reporting tools, as do many companies. These tools are used to log and report on bugs found in most of our products. Not only can those bugs originate from people outside the company who may not be able to write in English, but the problems can be regarding the processing of data other than English. Our products are internationalized, and so our customers use our products to process data from all over the world. If they encounter a problem, they're going to want to put in the data they were using when the problem occurred (if we're lucky). Without that data, we may not be able to reproduce the problem. Worse, if we don't allow that data, the customer may not bother to tell us about the bug at all!

Think about your internal customer databases - can they handle customer data in the local languages? This can be extremely important for customer relations and communications. What about Web based feedback? Could a Greek customer who doesn't write English send you some feedback? Wouldn't you want to know? Getting the feedback translated is a simple matter; getting the customer back after they left in frustration from not being able to communicate with your company is a lot harder and more expensive.

There are many other examples of internal tools that need internationalization: survey tools, forum discussion software, employee benefits tools (if you have worldwide employees), product registration tools, financial tracking tools (does all your revenue arrive in US dollars?), etc. The trick, and I know this is really tricky, is to carefully look at the tool requirements and all the data that the tool will be processing in the foreseeable future. Then design, architect, and implement to cover it. Piece of pie. Easy as cake.

( Mar 31 2005, 09:15:37 AM PST ) Permalink