Friday Apr 10, 2009

Assumptions, Assumptions

[Read More]

Monday Apr 06, 2009

GSI Architecture Strategy Part 4: Project Environments & Wrap

I am going to wrap up this initial series of posts on Global Single Instances with some thoughts on the number of test environments you’ll need to support your project(s). It may not give you instant happiness, but it will give you:


Many project or program managers have no firm idea on this subject and delegate the decision making to the technical lead/solution architect/chief propeller head.

This is OK if you accept that having no firm idea = having no clue. Alternatively (waxing lyrical here):

If you don’t stand for something you’ll fall for anything.

So what do I recommend PM’s need to know? It depends on the size of the rollout and the solution footprint.

[Read More]

Friday Mar 27, 2009

It’s CRM Jim, but not as we know it…

[Read More]

Wednesday Mar 25, 2009

GSI Architecture Strategy Part 3: Multilingual


[Andrew Sparks 17 June 2011] I made some editorial changes to reflect feedback from colleagues based on recent project experience

How many languages do I need to install in my Single Instance? Can I get away with just using English (or French/Spanish/Chinese/German depending on where HQ is in the world)?

Over the years I have had this discussion on many occasions. Here are some basic truths that keep popping up. Please note that these comments are primarily applicable to functionality in Oracle E-Business Suite but you may be able to extend the ideas to other applications. Your mileage may vary.

I’ll adopt a FAQ format. For simplicity I will assume English as the default base language. You can substitute any other language here for your case – but English always remains installed no matter what.

Also see  the Homework section for additional reference information basics and background regarding NLS (National Language Support) and MLS (Multilingual Support).

How many languages do I need to install? What are the main drivers for making the choice?

Obviously this depends on the number of different language areas you will be covering in your program.

Oracle E-Business Suite R12 supports up to 30 languages (see MetaLink  Note 412218.1 Software Translation Matrix) so there is no lack of choice.

As each additional language installed carries a maintenance and performance overhead you need to choose carefully. Main drivers for consideration are:

  • Local language preference. Experience shows that some customers (e.g. public sector) and some user groups within a customer (e.g. shop floor/shipping dock) require local language to be installed while others don't mind if they use the system in English (e.g. Financials users in a Shared Service Centre). Weighing the impact of local language UI on user adoption is a qualitative process but common sense needs to prevail.
  • Workers council sign-off. In some countries you are obliged to obtain formal workers council sign-off as a prerequisite to getting formal system acceptance. Installation of local language can be important component in gaining a positive (and binding) ruling for accepting the implementation.  After all the workers council is there to represent the interests of the people who finally be using the system. This requirement needs to be part of the business case for installing the language.
  • In many countries you are expected required to provide your statutory reporting in local language.
  • Desire to provide trading documents in local language of customer/vendor/partner

What is the impact of installing all of these languages?

There is an impact on maintenance. About 80%+ of patches have language specific components (i.e. translatable) - so you have to install the translated version of the patch for each of the installed language.

This means increasing number of languages = roughly linear increase on number of patches to be applied. Luckily this need not translate to linear increase in amount of time require to perform the maintenance. 
Specific patching and maintenance best practices can be used to keep maintenance time down, even if you have multiple languages installed.

For detailed info on patching best practice here some links from Steve Chan’s excellent blog.

Release 11i: Patching

Release 12: Patching

Do I need to test everything in every language?

Experience shows that (regression) testing every patch or setup change in every language is not needed. What you need is a good set of regression tests in your base language (English, say) supplemented with some random samples for one or more of the other installed languages. You only need to look further if tests in one of the extra languages show problems that are not present in the base language. This much more efficient and cost effective.

Where can I find more reference material?

Links are to relevant notes in MetaLink/My Oracle Support.

Release 11i

Release 12


Friday Mar 06, 2009

How Other Folks Do PM (or not)

[Read More]

Thursday Mar 05, 2009

GSI Architecture Strategy Part 2: How Many? Network is Key.

In the second of a series of posts on the subject of Global Single Instances I wanted to talk about how many you should have and how your ability to ramp up WAN capacity is a key consideration.

Oddly, as the subject implies, you should only aim to have one GSI. Of course Part 1 of the series debunked that idea right away. The idea is to…

Consolidate your business systems and business information to as few places and platforms as possible.

In other words, as many as you need, but no more than that…

[Read More]

Friday Feb 27, 2009

Maintenance Note Feb 2009

[Read More]

Thursday Feb 26, 2009

GSI Architecture Strategy Part 1: Basics

To start to my series on Global Single Instances let’s deal with some basics first.

Not Literally “Global” or “Single”

We may not literally be talking about a single instance of a system supporting global operations for a corporation.

A true GSI may only be a realistic goal for few enterprises right now.

As a provocation or target, however, it can work well for anyone. So the less sexy, non-soundbite version might be something like:

Consolidate your business systems and business information to as few places and platforms as possible.

[Read More]

Global Single Instance Architecture Strategy

[Read More]

Thursday Feb 19, 2009

Old Dogs, New Tricks, All That…

[Read More]

Wednesday Feb 11, 2009

Build Load-Bearing Project Teams

[Read More]

Tuesday Feb 10, 2009

Have We Got A Methodology for You!

[Read More]

Friday Dec 19, 2008

Happy Holidays & Go-Lives

[Read More]

Tuesday Dec 09, 2008

Unstuck By OODA


[Update 10-Dec-2008 –  review comment from Chet Richards added to the text]

An article in the February 2008 Harvard Business Review (The Experience Trap by Kishore Sengupta, Tarek K. Abdel-Hamid, and Luk N. Van Wassenhove) led me on a treasure hunt of new concepts.

The article prompted me to research the topics of cognitive feedback and situational awareness to see how these fields could be applied to the field of Project Management.

On looking deeper into the body of knowledge around situational awareness I happened on the work of the late Col. John Boyd.

This post reflects on how one lesson taken from this obscure military strategist can make a big difference in your handling of interaction with your stakeholders and ultimately your project outcomes. Boyd’s work provides a great explanation of how project teams can come unstuck from their primary stakeholders and ultimately fail, while apparently doing everything “right”.

[Read More]

Wednesday Dec 03, 2008

Maintenance: Blogroll Added, HTML Feedback Disabled

[Read More]

Projects have become a lifestyle in business. Lets get good at them.


« May 2016