Hitoshi Goto<\/p>\n\n\n\n
Ukihiko Takagi<\/p>\n\n\n\n
In the previous installment, we introduced risk management when participating in overseas projects. This time, we will examine key points for implementing a ‘common system’ across headquarters and overseas subsidiaries.<\/p>\n\n\n\n
In system implementation projects, there is various resistance when trying to deploy a standard system built by headquarters to overseas subsidiaries that already have existing systems in place. How can you implement a standard system while suppressing such resistance?<\/p>\n\n\n\n
A global manufacturer had templatized their global accounting system. Let me share a story about when that template was deployed to Australia. The standard system was built based on Oracle E-Business Suite (hereinafter EBS).<\/p>\n\n\n\n
The Australian subsidiary had already built a system using Oracle Database (hereinafter Oracle), but they were using a DB version one generation older than the standard system’s Oracle. Therefore, an Oracle version upgrade was also necessary, but this subsidiary was very strong in Oracle and had done their own customizations.<\/p>\n\n\n\n
When deploying a templatized standard system, customizations based on individual company requirements cause various contradictions and are fundamentally not permitted. For this reason, local pushback on this matter was extremely strong, and project progress was difficult.<\/p>\n\n\n\n
There are three key points for leading such projects to success.<\/p>\n\n\n\n
The first is to establish a dedicated key person who can drive the project strongly while conducting tough negotiations with user departments. When implementing an ERP, it is important to minimize add-on development as much as possible, but not only in this Australian case\u2014in ERP implementations, there is usually an existing system, and local business users are accustomed to its functions.<\/p>\n\n\n\n
Therefore, ERP implementations always require a key person who can coordinate with local business departments, and in such cases, it becomes especially important to place someone with strong negotiation skills in a nearly dedicated role. It is best to ask someone in the local business department who understands standardization to be the key person. Generally, information systems departments have weaker negotiating power (though if someone influential from the local business department has been placed in the information systems department, that person may be better).<\/p>\n\n\n\n
The second is to permit, rather than flatly refuse, voluntary customization from the local side. While there are cases where no customization is done in ERP implementations, this is not very realistic. Even if you force it through, there are risks that it won’t be used in business operations or that operations will become inefficient. Therefore, it is practical to consider allowing a certain degree of customization.<\/p>\n\n\n\n
However, in such cases, the implementation promotion side\u2014that is, headquarters\u2014must not bear the costs. By having it implemented strictly within the local side’s budget, you can restrain the scale of customization.<\/p>\n\n\n\n
The third is that even for customization within the local side’s budget, customization based on individual company requirements that contradicts the standardization defined by headquarters must not be permitted. Since the primary purpose of ERP implementation is business standardization, customization in that area must never be allowed. For example, aligning product codes to achieve global ‘visualization’ falls into this category.<\/p>\n\n\n\n\n
Global major corporations have many systems including supply-demand management, procurement management, production management, order management, and accounting. The general approach of Western companies is to unify these systems globally as much as possible and have overseas branches use them. This unifies both operations and mechanisms with headquarters. Authority delegation is not done in principle. The entire world operates under headquarters’ direction.<\/p>\n\n\n\n
On the other hand, Traditionally, many Japanese multinational companies have often allowed each country or regional base to build their own systems. (though recently they are moving closer to the Western model). Business authority was also delegated to each country or regional base, and the delegated sides built their own systems with their own budgets. Such delegation of authority was necessary partly because it seems that without delegating authority, they could not secure talented personnel at overseas locations.<\/p>\n\n\n\n
Recognizing that Japanese companies originally tended to allow autonomy for overseas subsidiaries, we should understand the need to advance standardization through negotiation rather than coercion.<\/p>\n\n\n\n\n
<< Read Part 3 of the Series<\/a> | Read Part 5 of the Series >><\/a><\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" Hitoshi Goto Ukihiko Takagi In the previous installment, we introduced risk management when participating in o […]<\/p>\n","protected":false},"featured_media":31,"template":"","case_wall_type":[13,12],"case_business_area":[47],"class_list":["post-68","column","type-column","status-publish","has-post-thumbnail","hentry","case_wall_type-wall-8","case_wall_type-wall-7","case_business_area-business-area-6"],"acf":[],"yoast_head":"\n