Table of Contents
Hitoshi Goto
Ukihiko Takagi
In the previous article, we covered how to work effectively with local experts. This time, we will look at ‘uniquely Japanese’ IT techniques that don’t work in overseas projects.
There Are No Engineers Who Can Do Add-On Development Like in Japan
Japanese ERP projects have historically developed advanced customization practices that differ from those commonly seen in many other markets. Taking Oracle E-Business Suite (EBS), which we frequently use, as an example: each table is limited to 15 additional fields, but this is often not enough, and we sometimes even subdivide within each field using ‘|’ (pipe) characters.
These are ‘descriptive flexfields’ (fields pre-prepared by the package to allow adding non-standard fields for user business use), so there is no problem with this approach. However, to the best of our knowledge, Such extensive customization practices are particularly prevalent in Japanese ERP implementations.
For Japanese ERP engineers, the true test of skill lies in how elegantly they can integrate add-ons into packaged software. Designers and developers have also accumulated and refined add-on techniques and rules for their respective packages.
However, overseas there is a general tendency to avoid add-on development. One reason is the high mobility of IT engineers – they change jobs quickly, so there is a risk that know-how about company-specific add-on specifications will not be passed on. Another reason, commonly cited in Japan as well, is that operation and maintenance costs become expensive.
When there is a major version upgrade of an ERP package, reviews and testing of the add-on developed portions become necessary.
That said, overseas they do sometimes modify ERP packages for business reasons. In such cases, since there is no add-on development know-how overseas, they do things that would be strictly forbidden in Japan. For example, they use DB triggers (meaning direct database access) or hard-code modifications onto the package.
We call this ‘modification’ to distinguish it from add-ons, but such approaches should be carefully evaluated because they may fall outside the package vendor’s support and warranty coverage.
When you want to customize ERP packages in global projects, keep in mind that The expertise required for large-scale ERP customization may be less common outside the Japanese market, and if you push too hard, they may propose approaches that differ significantly from common practices in Japan. With this understanding, you should establish firm policies.
Overseas, They Do Not Do Complex Job Scheduling!?
Automatically executing batch jobs with a job scheduler is the same in Japan and overseas. However, whether the kind of job scheduling that Japanese people envision is also necessary overseas – well, not really.
Japanese job schedules are meticulously constructed like tree diagrams, with fine-grained conditional branching to ensure each program executes in the correct order. They are themselves almost like complex programs, and it is no exaggeration to call them masterful craftsmanship.
However, overseas, in many global projects, job scheduling tends to be designed with a greater emphasis on simplicity and maintainability. Programs are typically just grouped by daily/weekly cycles and start times.
From a Japanese perspective, you might worry that some processes will not execute or that database inconsistencies will arise. But you should recognize that even if such things happen, the underlying philosophy is that by increasing job execution frequency, it is fine as long as the next run catches it.
That is not the only reason Japanese job schedules become complex. Overseas, especially in America, payment within 30 days of invoicing is common, whereas in Japan, month-end closing with payment at the end of the following month is standard, making monthly batch processing inevitably massive and complex.
Monthly processing is not just billing – there are many other processes too, making things even more complex. On the other hand, overseas, month-end aggregation is done mainly for accounting purposes, so the attitude is that some organizations place greater emphasis on recovery and reprocessing mechanisms than on preventing every potential exception in advance.
There are fundamental differences in system operation philosophy between Japan and overseas. At the very least, operational designs in many global environments aim to reduce dependency on specific individuals and enhance maintainability; the emphasis is on making systems operable by anyone. When considering operational design for global projects, this must be taken into account.
