Enterprise-wide software is complicated enough but when the application must be distributed across multiple countries, there are elements of complexity that must be considered long in advance of the start of implementation. When data from a system that spans multiple countries spans multiple countries, cultures, time zones and environments must come together to form a coherent picture for management, some additional thinking must be done in advance.
At our firm we’ve done enterprise wide project control systems for years and on many occasions with multi-national firms but it was not until this year that we had to deal our first multi-national implementation of one of our systems.
When a data-oriented system such as an ERP environment or, as was our case, an all-employee project oriented timekeeping system must be deployed in such an environment, there are several areas to consider:
Language
Is the software you’re installing even available in a local language? Is this important? If the system is available in a local language, is it the identical version that is available in English? (Often not). Will the data be saved in exactly the same way when it’s stored in a foreign language version (for example, 2-byte characters for some middle-east and far-east languages)? While we’re speaking of languages, how will you handle training, consulting, implementation assistance and technical support in the local language?
Communications
How will the systems communicate with each other? Is there a data pipeline already established and is it fast enough to handle the anticipated traffic. How reliable is the connection. If it’s not, will your system allow for data to be pooled then transmitted in a batch? In some countries, PCs and other computers are readily available but fast telephone data connections are not.
Multi-platform
The larger and more diverse the implementation, the more likely that you’ll find different hardware platforms, operating system platforms, database selections, network environments and so on. Is the system you’re looking at ready to deal with this diversity or have you budgeted the costs of switching some areas into a common operating environment? If so, remember such an action affects everything else already established on that environment.
Configuration management (upgrades)
You may find it a challenge to keep up with software upgrades, patches, fixes and so on but when you’re dealing with such items at great distances, the challenges become much more difficult. Have you established a plan for upgrading the system and for maintaining it?
Real-time data and time-zone issues
This one is insidious and many, many people don’t think about it but if you are planning to move data to a central location, it often must be closed or grouped at some specified time or date. For example, month-end closings. If you have not allowed for multiple time-zones, this can cause tremendous upset. If the head-office is in Toronto and some of your users are in Australia, you can be dealing with a 12 hour time difference.
O/S and local version issues
It’s not enough to tackle the local software versions, what about the local operating system and systems which must be integrated. The other day, I walked through our technical support office only to find a Microsoft Project 98 CD on someone’s desk. That in itself isn’t too unusual. Our timesheet system links to Project98. What caught my eye was that it was the Swedish version and no one in our office speaks Swedish. Sure enough, it turned out that we had to make adjustments in our product so that the data could be linked properly to the Swedish version (and other European versions) of Project98 as the system was not properly recognized. We’ve had to make similar adjustments for Regional Settings in Windows and for different language data.
This may seem like an overwhelming challenge but there are numerous methods of handling it. Here are a few you can think about:
Make a Project Plan
Can I say this enough? Make a plan. If you don’t, this kind of detail will come up to bite your behind and the consequences to your implementation schedule can be monstrous. Include in your plan a list of potential risks you’ve identified already and canvas your international colleagues for risks they may be able to think of.
Identify a Local Champion
Put someone on your implementation team from each major region and put them on the team from the beginning. This will keep these countries in the loop and give you a better chance of identifying issues before they come up.
Look at alternative platforms
Server based code for example, allows you to beat the configuration management issues by centralizing the application and distributing working through the Web. Sounds great but there are technical issues here too not the least of which is security. Make sure the technology you choose gives you the capacity to handle the workload.
Think about being less integrated
I know it’s an enthralling prospect and the salespeople had the CEO loving it during the product demonstration but make sure that integrating all these countries will have a bigger payoff than the cost in time, money and effort. “Sometimes it’s better to look integrated than be integrated,” I say and it often holds true for this kind of thing. You can still be compliant and use data that can be brought together in batches without having to have all the data talking to each other all the time. Deciding to establish regional data centers where data is pooled as though it was a separate organization can solve multiple networking and data movement issues.
Make sure there’s local support
No matter how great it sounds, there has to be local support for your application of some kind If it isn’t there, budget for creating it yourself because supporting enterprise applications from a different time zone is very difficult.
Finally, make sure your schedule allows time and budget for prototyping, testing, travel and lots of “miscellaneous”. Build some extra slack into this element of the schedule. You can make this even better by avoiding promising particular structures prior to starting. If your design has promised management a “Real-Time true client/server link with transactions updated second-by-second”, then be ready to wipe some egg from your face. Some countries can at best muster a 1,200 baud data connection out of the country. While I remember getting my first “high-speed” 1,200 baud modem, it won’t be fast enough any more to take care of moving corporate data in real time for a client/server system.
If you take some time doing preparation in your project plan and creating some contingencies to the risks you’re facing, you’ve got a much better chance at bringing your organization closer together and helping to make the world a smaller place.
