One goal of the designer of a system, which is to be deployed multinationally, is to reduce costs by minimizing customization, except where it is clearly necessary or benefits the user.

An example of where customization is often necessary is the language and font of the screens and reports.

An example of where customization is unnecessary is in the format of the fields used to capture, store and key name and address data. To simplify system expansion, these fields should be the same size and format for all countries.

In the internal design of the database keys, search keys and matching logic, then country level customization of names and address processing is essential. The processes, which build keys and perform matching, should be able to succeed with unformatted or partially formatted data. When the multinational system is implemented separately per country or regionally, then it will be beneficial to have key building, searching and matching algorithms that are tuned to each separate country or region’s population of data.

If multiple character sets will be in use then character mapping algorithms, stabilization algorithms and tables for abbreviations, nicknames and other naming word rule bases will need to be externalized from the standard executable code. In some cases where multiple character sets and languages are in use in one country, translation rule bases will be also necessary.

These processes should be designed with a common interface such that implementing a new country requires only that new country-level modules and rule bases are plugged in.