プロジェクトを推進する専任のキーパーソンを設置

システム導入プロジェクトでは、既にシステム導入済みの海外子会社に、本社が構築した標準システムを展開しようとするとさまざまな抵抗があります。そのような抵抗を抑えながら、標準システムを導入するにはどうしたらいいのでしょうか。

あるグローバル製造業のグローバル経理システムはテンプレート化されていましたが、そのテンプレートをオーストラリアに展開したときの話を紹介します。標準システムはOracle E-Business Suite（以下EBS）をベースに構築されていました。

オーストラリアの子会社では既にOracleデータベース（以下Oracle）を利用したシステムを構築していたのですが、標準システムのOracleより1つ古いDBバージョンを使っていました。そこでOracleのバージョンアップも必要だったのですが、この子会社はOracleに非常に強い会社で、独自のカスタマイズを行っていました。

テンプレート化された標準システムを展開するうえで、個社要件によるカスタマイズはさまざまな矛盾を生じさせるため、基本的には認められません。そのため、このことに関する現地の反発は極めて強く、プロジェクト推進は難航しました。

このようなプロジェクトを成功に導くためのポイントは3つあります。

1つ目は、ユーザー部門とタフな交渉をしながらプロジェクトを強力に推進する専任のキーパーソンを置くことです。

ERP導入に際しては、アドオン開発は極力少なくすることが重要ですが、このオーストラリアのケースに限らず、ERP導入に際しては既存システムがあり、その機能に現地業務ユーザーが慣れていることが普通です。

そのため、ERP導入では常に現地業務部門と調整してくれるキーパーソンが必要になりますが、このようなケースでは特に強力な交渉能力を持った人を、それにほぼ専任できる形で置くことが重要になってきます。

キーパーソンは現地業務部門で標準化に理解ある人に依頼するのがいいでしょう。一般的に情報システム部門では交渉力が弱くなります（現地業務部門で影響力のあった人を情報システム部門に配置している場合は、その人のほうがいいこともあります）。

2つ目は、現地側の自発的なカスタマイズであれば、むげに拒否せず許可することです。ERP導入でカスタマイズを全くしない事例もありますが、あまり現実的とはいえません。無理に断行しても、業務運用で利用されなくなったり、業務運用が非効率になったりするリスクもあります。そこである程度のカスタマイズは許可する方向で考えるのが実際的だといえます。

ただし、その場合は導入推進側、すなわち本社側からは費用を負担してはいけません。あくまで現地側の予算で実施することで、カスタマイズの規模を抑制できます。

3つ目は、現地側の予算でのカスタマイズといっても、本社で規定した標準化に矛盾する個社要件のカスタマイズは許さないことです。ERP導入の最大の目的は業務の標準化ですから、その部分のカスタマイズは絶対に許可してはいけません。例えばグローバルでの「見える化」実現のために製品コードを合わせるといったことが、それに該当します。

本社中心志向の欧米企業と現地自治志向の日本企業

グローバル大手企業には、需給管理・調達管理・生産管理・受注管理・経理など多くのシステムが存在します。

こういったシステムを極力、世界で統一し、海外支社に使わせるのが欧米企業の一般的なやり方です。このことにより業務も仕組みも本社と統一します。権限委譲も原則として行いません。世界中が本社の指示で動きます。

一方、日本企業は、各国や地域の拠点で独自のシステムを構築させることが多かったといえます（最近は欧米型に近づきつつありますが）。業務権限も各国や地域の拠点に委譲され、委譲された側は自分たちの予算で独自システムを構築してきました。

こうした権限委譲が必要だったのは、権限委譲しないと海外拠点に優秀な人材を確保できないという事情もあったようです。

日本企業は元々、海外法人の自治を認める傾向があったことを踏まえたうえで、強圧ではなく、交渉によって標準化を進めていく必要があることを認識しましょう。