グローバルERP導入の勘所—業務の標準化を徹底　各拠点の「手離れ」に知恵絞る

宿谷俊夫 - 2010年1月13日(水) 09:00

欧米企業の多くは、世界各国に展開するグループの全拠点に共通のグローバルＥＲＰを導入し活用している。海外拠点に対して強い統制をかけることに消極的だった日本企業においても近年、「ＩＴをテコにグループ内のガバナンスを強化したい」という声が高まっている。本稿では、グローバルＥＲＰを導入する際のポイントを解説する。

国内の景気回復が思うように進まず、企業にとって海外拠点の重要性がより高まっている。特に、中国をはじめとする東アジア、シンガポールやタイを中心とした東南アジア、さらにインドでのビジネス進展に期待する企業は多い。

こうした経営環境のなか、企業のシステム担当者から「グローバルでのガバナンスを強化したい」という相談を受けることが増えている。それに対する筆者の提案の1つが、グローバルERPの導入である。その理由について述べる前に、ここではまず、海外に拠点を持つ日本企業におけるガバナンスの現状について見ていく。

拠点任せのシステム化でビジネス継続性に黄信号

従来、日本企業の本社システム部門は、海外拠点のシステムにあまり関与してこなかった。このため、日本企業の海外拠点では、担当者が自力で情報を収集したうえで限られた予算を割き、販売や生産といった業務ごとに様々なベンダーのパッケージソフトを導入してシステムを構築してきた。表計算ソフトを駆使した手作りのツールを使い続けているところも少なくない。

これは、日本企業が海外拠点の自立性を尊重してきたことのあらわれだろうし、筆者は様々な企業の海外拠点がそれぞれ業務効率化のために注いできた努力を否定するものでは決してない。しかし、結果的にはグループ内に異なるシステムやツールが拠点の数以上混在することになってしまった。その弊害は大きい。

つまり、1つひとつのシステムは拠点最適にとどまっており、グループ全体で見るとデータや機能の重複や不整合が生じている。加えて、システムの面倒を見ていた担当者が会社を辞めてしまったり（海外ではよくあることだ）、本社に戻ったりすると、そのシステムは使われなくなりがちである。ユーザーはいつの間にか、手元の表計算ソフトなどを使って業務を回すようになってしまうのだ。これでは当初のシステム投資が無駄になるだけでなく、手作業が増えて業務が属人化・非効率化する。ひいては、ビジネスの継続性に重大な影響を及ぼすことは想像に難くない。

それだけではない。システムがばらばらであるがゆえに、拠点ごとの経理の監査証跡がとれないなど、内部統制上の重大な問題を抱えるケースも散見される。ある拠点が現地当局に支払っている税額が正しいかどうかすら本社からは分からない、といった深刻な事態も実際に起きている。

標準の業務プロセスを埋め込んだ世界共通のグローバルERPは、こうした課題に対する有効な解決策の1つである。

グローバルERPにより、経営層は海外拠点の財務や出荷量などの情報を、本社にいながらリアルタイムで把握できる。このため、必要なアクションを考え素早く実行できる。加えて、グローバルでどこでも同じ業務プロセスを運用していれば、拠点が独断で無駄な業務を実施するリスクが減少する。本社の経営層や事業の責任者が、定められたルールに沿って業務内容の評価をしやすくなるメリットもある。

このように、グローバルERPを導入することで本社によるガバナンスを強化できる。本社経営トップの意思に沿い、文化も教育レベルも様々な海外拠点の人材の足並みをそろえて一定の業務品質を確保できるわけだ。

システムブループリントを作成
費用対効果のイメージをつかむ

日本企業はこれまで、国内拠点へのERP導入に数十億円単位の巨額を投じてきた。各事業部門やユーザーの意見の多くを聞き入れ、膨大な追加機能を盛り込んだからだ。そうした経験を持つシステム担当者が、「ERPをグローバル展開するとなれば、さぞかし莫大な費用がかかるはず。そんな資金的な余裕はない」と躊躇するケースは少なくないと思う。だが実は、業務プロセスの標準化を前提にしたグローバルERPは、比較的安価に実現できる。

グローバルERPのおおよその費用感や現実的な効果を確認するには、業務標準化および「システムブループリント策定プロジェクト」を実施するとよい（図1）。まず、複数の事業から規模などに応じてモデル拠点を1つずつ選び出し、それらの業務およびシステムを網羅的に把握。様々な課題を識別して対応策を立案するとともに、業務プロセス標準を定める。この業務プロセス標準に基づき、グローバルERPの青図（ブループリント）を、2〜3カ月程度で策定するのだ。

図１　業務標準化およびシステムブループリント策定プロジェクトのアプローチ（図をクリックで拡大）

こうしてブループリントを策定すると、たとえ事業や拠点は異なっても業務プロセスは意外に似通っており、つきつめれば標準化できることが分かる場合が多い。これは、ほぼ標準機能のみに絞った1つのERPを複数拠点が共同利用できるということを意味する。標準機能を活用し、追加機能を極小化すれば、数億円程度でERPをグローバル展開できる。この程度の投資であれば、十分に効果とのバランスをとれるはずである。日本で生産した商品を中国で販売するといったグローバルサプライチェーンを構築しているような企業については、より大きな投資対効果を期待できる。

ただしもちろん、ブループリントは画に描いた餅にすぎない。導入先が国内かグローバルかを問わず、ERP導入には途中の機能追加が相次ぎ費用が当初予算から膨れ上がるというリスクがつきまとう。そこで、グローバルERPを低リスクかつ低コストで導入するための4つのポイントを以下で述べていきたい。

事業部別の要件定義を排除し
1つのテンプレートを全体に適用する

1つめのポイントは、グローバルアプリケーションアーキテクチャの構築である。

アプリケーションアーキテクチャとは、ERP導入後のシステムの姿。いわば、システム全体の設計図である。この設計図を描く対象がグローバルであれば、それがグローバルアプリケーションアーキテクチャとなる。

グローバルアプリケーションアーキテクチャには、企業のビジネス状況によりいくつかのパターンがある。例えば、社内の事業間に業務の連動性があまりない場合は、事業ごとに個別のERPを導入する。事業間や地域内で商品の引き当てがあるなど業務の結びつきが強い場合は、複数事業で1つのERPを導入、または地域で1つのERPを導入する、といったパターンになる。

図2左は、化学メーカーを想定したグローバルアプリケーションアーキテクチャの例である。事業ごとの自立性をある程度重んじ、SAPで言えば複数インスタンスを導入するパターンだ。実際はもっと詳細なモデルを作成すべきだが、ここでは誌面の制約から簡略化した。

図２　アプリケーションアーキテクチャ例（図をクリックで拡大）

こうしたグローバルアプリケーションアーキテクチャの構築は、将来のビジネス構造を想定しておくことが前提となる。決して簡単な作業ではないが、システム部門の主体的な取り組みにより、3カ月程度で策定している事例は多い。

この設計図に基づき、グローバルERPを展開する。ブループリント作成時に定めた業務プロセス標準を基に、ERPの標準機能に最低限の企業特性を組み込んだ「グローバルERPテンプレート」を構築。まずは、経理業務と1つのモデル事業に導入する（図2右）。

次に、テンプレートをコピーして別事業に展開する。この際、対象となる事業部門から追加・変更要請があるかもしれないが、できるだけ標準に合わせたい。例えば、導入費用を事業部門の負担とすれば、過剰な機能追加を抑制できる。同様のやり方で、すべての事業にERPテンプレートを順次展開していく。事業別や拠点別にゼロから要件定義してERPを導入する場合に比べて、格段にコストが下がることは明白だろう。

「事業ごとに独自の販売や物流方式がある。1つのテンプレートをコピーして使い回すことなどできない」と言う読者がいるかもしれない。だが筆者の経験から言って、よほど多岐にわたる事業を運営していない限り、ほとんどの企業にこの展開法は有効である。しかも、厳しい経済環境の下で多くの日本企業は「選択と集中」という戦略を打ち出している。そうしたなか、このようなアプローチは適合しやすくなっている。

複数のプロセスオーナーが合議制で要件を決定

アプリケーションアーキテクチャの策定と並んで重要なのが、プロセスオーナーの設置だ。これが、第2のポイントである。プロセスオーナーとは、業務プロセスを設計・構築・運用する責任と権限を持つ担当者を指す。

大勢のユーザーが寄ってたかって業務プロセスの要件を定義すると、膨大な追加機能が発生し、予算も期間も超過してしまいやすい。これを回避するには、可能な限り少人数で要件を検討することが理想である。とはいえ、各部門から上がってくる要件の要否をたった1人で判断することは非常に困難であることも確かだ。

そこで、3つのレベルでプロセスオーナーを任命し、合議制で事に臨むとよい（図3）。全体を視野に入れて最終的な要件の決定権限を持つ「コーポレートプロセスオーナー（CPO）」、特定の事業領域における要件の検討・申請に権限を持つ「ビジネスプロセスオーナー（BPO）」、拠点ごとの要件をとりまとめる「ローカルプロセスオーナー（LPO）」である。事業に固有の要件については、CPOとBPOの2者が議論し決定する。拠点に固有の要件を取捨選択する際には、この2者に当該拠点のLPOを加えた3者で判断する。

図３　プロセスオーナー設定例（図をクリックで拡大）

3レベルのプロセスオーナーのなかで、CPOは導入期間に限らず常設のポストとしたい。グローバルERPテンプレートの作成時から各拠点への展開、さらにシステム稼働後における仕様変更や追加の要否を判断する任務に一貫してあたるためである。CPOには、部門に偏らず全体的な視点から判断できる中立的な立場の人材を登用したい。筆者は、グローバルERPテンプレート構築・導入時に活躍したシステム業務経験者が適任ではないかと考えている。実際、私が携わった米国企業のプロジェクトでは、システム部門出身者がCPOを務めているケースが多かった。

ビジネス主導のプロジェクト体制で過剰な要求をコントロールする

グローバルERP導入プロジェクトを成功させる3つめのポイントは、システムではなくビジネス部門の長をプロジェクトのトップに据えることである。

一般に、日本企業における開発プロジェクトは、次ページ図4左のような体制をとることが多いようだ。プロジェクトオーナーにはCIOやシステム部長が就き、導入費用もシステム部門の予算でまかなう。これは事業間の利害を調整する“行司役”として、全体最適を導き出そうとする役割と、アドオン開発など予算超過を引き起こす事項をばっさりと切るためでもある。「業務の事情をあまり細かく知らない立場の人間のほうが、無駄なプロセスを切りやすい」というわけだ。

図４　プロジェクト体制はCIO主導からビジネス主導へ（図をクリックで拡大）

確かに、これは非常に合理的な考え方だ。しかし実際には、CIOやシステム部門長をオーナーにしたプロジェクトは、なかなかうまく機能しない。それは一般に、お金を稼いでくる各事業部門のほうが、システム部門より“強い”傾向があるからだ。

もう少し具体的に述べよう。システムを担当するCIOやシステム部長は、要件決めを行う業務担当者に指示を出しにくい。業務担当者に対する評価権限を持たないからである。このため、業務担当者が出してきた要件を却下するには、その論理性や妥当性を根気強く説明して相手を説得するしかない。時には、コスト責任のない業務部門の長が乗り込んできて明らかに過剰な要件を採用するよう迫り、結局はCIOが押し切られてしまうといった事態が発生することもある。CIOやシステム部長がよほど強いリーダーシップを発揮しない限り、こうしたパワーバランスのなかでプロジェクトを成功に導くことは難しい。

この問題を回避するには、CEOやCOOなどユーザー部門を横断的に束ねるトップをオーナーに位置づける。これにより、意思決定の構図がシンプルになり、要件を決めやすくなる。そうしたオーナーは、予算内でプロジェクトを完了する責任を持つと同時に、業務担当者に対する評価者という立場にある。このため、予算内に収まる範囲でしか要件を認めないはずだし、必要以上の要件について統制を効かせやすい。

デプロイメント活動でユーザーの手離れをよくする

第4のポイントは、デプロイメントである。

デプロイメントとは、ユーザー部門が新しい業務プロセスやシステムを自立的に運営していくために必要な活動を指す。グローバルなプロジェクトでは、このフェーズは国内プロジェクトにも増して重要なポイントになる。本社システム部門のリソースは限られており、新システムが根付くまですべての海外拠点に常駐して支援することは不可能だからだ。具体的には、図5に示すような作業を実施したい。なかでも重要なのは、BIA（Business Impact Assessment）における集中検討会の実施である。

図５　デプロイメントの主な作業（図をクリックで拡大）

海外拠点のユーザーに、業務の変更点や新しいシステムの使い方などを理解してもらうことは容易ではない。特に、アジアパシフィック地域のユーザーとは、互いに第2言語である英語で意思を疎通させなければならないことが多いだけに、コミュニケーションギャップが生じやすい。国内プロジェクトのように短時間のトレーニングセッションを１〜2回実施する程度では、言いたいことは伝わらないと考えたほうがよい。また、ユーザーが「OK」と言っても、それは決して理解しているという意味でないことも多く、習得状況の把握が難しいことがある。

そこで、プロジェクト中に複数回、各拠点の主要ユーザーを1カ所に集めて2〜3日の合宿形式による検討会を実施する。検討会では「ERPとは何か」の説明から始め、プロジェクトの目的や業務がどう変わるかなどを伝える。出席した主要ユーザーには、その後それぞれの拠点で今度は講師として検討会の内容をほかのユーザーに説明してもらう。

このほか、プロジェクトのリーダークラスは手分けして各国拠点に足を運び、新システムに対するユーザーの理解度を確認しつつフォローアップする。筆者は以前携わったグローバルERP導入プロジェクトで、日本を出発して香港、深センを回りバンコクへ。さらに、インドのチェンナイとニューデリーを回ってそこからメルボルンに渡り、シドニー経由で帰国する。そんなタフな出張を何度か経験した。今回の主旨とは多少異なるが、このような海外出張を事前に考慮し、プロジェクトの旅費交通費や宿泊費などは国内プロジェクトと1ケタ違う予算を計上しておきたい。

グローバルERPの稼働直前には、出荷の一時停止や長期滞留在庫の処分、売掛金の回収といった作業が発生する。あらかじめ、各拠点でそうした作業を率いる「サイトリーダー」を選出しておきたい。プロジェクトメンバーが支援しつつも、可能な限りユーザーだけで稼働を迎えられるようにしていくためである。

こうしたデプロイメントの取り組みを徹底することにより、グローバルERP導入後の“手離れ”は格段によくなる。新システムを稼働して最初の月次決算を実施するまで、つまり最長でも1カ月程度でプロジェクトからの支援をなくし、ユーザー自身で業務を回せるようになることを目指したい。

将来のグローバルERP導入に向けて今から検討すべきこと

以上、グローバルERPを導入・展開していくためのポイントを述べてきた。「グローバルERPの効果は理解できるが、当社にはその導入に踏み切るだけの余裕がない」という企業もあるだろう。そうした企業も、将来のプロジェクトに向けて今から準備を開始すべきだ。業務とシステムの双方を理解しているシステム部門が中心となり、どうすればより安く簡単にグローバルERPを導入・展開できるのか、そのためには何を捨てて何を残すべきかを議論しておいてほしい。

さらに、プロセスオーナーたり得る人材の育成にも着手しておきたい。人材育成にはそれなりの時間がかかるし、経験を積ませるためのキャリアパスが必要だ。早めに着手するに越したことはない。