Session 3291 in the OAUG section. I went to Sylvain Nguyen’s presentation on PeopleSoft global rollouts. Sylvain used to be a manager for PeopleSoft Global Financials development, and is now the CEO of Ataway. Ataway is a consulting company that specializes in PeopleSoft (note that we’ve worked with them before) I came in about 15 minutes late, because the OAUG tracks are not sync-ed up with the Quest tracks timewise. Which is probably driven more by scheduling lunch for everyone here than anything else. Sylvain was in the middle of discussing the question “How can a global rollout be cost efficient, fast paced, and with quality when so many odds are stacked against it?”. This then led into a series of Dos and Don’ts. Do

• Define template based global methodology
• Identify business leaders and analysts in the US and local countries
• Use local resources in the project team

Don’t

• Start user requirement gathering before corporate business processes are mapped
• Underestimate the impacts of working with remote teams

Do you have a US based team travel to each country to gather requirements? Sylvain recommends having local people onsite for the project implementation. They know the business practices, they know the culture, so they can be of great assistance. Gathering local requirements. When planning deployment, the first thing to do is identify/document your proper business processes. If the core business processes are documented then the requirements gathering is much easier. One other thing that Sylvain recommended is to avoid consulting companies that don’t have global experience. He gave an example of an implementation where consulting company didn’t know what VAT was, so they left it to be calculated manually. The local users thought this was a joke since the most basic local packages would do this automatically, but they were told that PeopleSoft was state of the art, etc. The presentation then got into data strategies. It’s common to have a single set of vendors, a small number of setids for US based implementations. That probably won’t work for a global deployment, so if you haven’t looked at how PeopleSoft supports this, then it’s time to learn. (note: a great resource for this is our weblog post on SetIDs and Business Units). One thing that comes up in some implementations is that the local users already know English, so people wonder why it’s necessary to have the global support. Sylvain gave an example of Japanese users that know English. But they need to interact with other people that don’t. If you send an invoice in English in Japan, you probably won’t get paid because the mailman won’t know how to deliver it. So you do need to be sure that your Japanese users can enter things like addresses in Japanese. Do

• Trust psft features around global
• Prototype early as possible
• Involve local business leaders in review of designs. Implementation time is too late.

Don’t

• Underestimate the impact on existing customizations
• Forget that production support will have to change to handle global users and requirements

There was then a short performance discussion. Most people understand about wide area networking and that there may be performance issues when you have users half way around the world. But you also have to consider things like running batch jobs in the middle of the night in the US. There’s never really a good time to do that in a global implementation because it’s always someone’s work day. So you have to look at better tuning of batch or even locking out users from targeted areas while batch is running. Global deployments also impact your support organization. If a critical business issue happens at 3am headquarters time, who takes the call? (Hillary!) Would you allow the local teams to make code changes to do a critical fix if needed? Would you make your project team at headquarters wear pagers? Sylvain recommends setting service level agreements up front for these sorts of things so that it can be decided upon rationally up front, instead of waiting for a crisis to happen. Do

• Identify and train local SME as early as possible
• Assign dedicated local support analysts
• Train the support team on the new processes and features

Don’t

• Underestimate time and cultural differences in resolving problems.
• Think the project is over when the country is live.

Sylvain gave an example of a project review where there were no complaints about the new country rollout in Japan. As it turns out, the users were unhappy, but did not want to say anything. This is just a cultural difference, but the project team was not aware that no complaints was not the same thing as no issues. One question came up at the end was about whether or not to use a single PeopleSoft instance or multiple PeopleSoft instances for development when you have different development teams around the world. Sylvain recommends a single instance so that you don’t have to worry about missing changes from one environement. There were a few nodding heads in the audience that Sylvain pointed out. Labels: 2008, Collaborate, Global