ホーム > ブログ

Articles from July 2012



ERPシステムの導入が難しい理由(4)スイッチングコストの問題

カスタマイズ重視で行うERPシステムの導入は、大きな問題が発生し易いという話しを前回しました。今回は、カスタマイズに依存しないで現在の業務プロセスとERPシステムの制約とのギャップを埋める方法を検討します。 要な業務プロセスが非標準的である場合。ビジネスプロセス・リエンジニアリングという手法を用います。つまり、関連する業務部門全体の業務フローの最適化する為の業務改善を行います。その一例として日鐵商事のSAP導入事例を紹介します。弊社はかつて、香港にあるこの会社の販売管理システムの受託開発を行った経験がありますので、日鐵商事のSAP導入がいかに大変だったかが理解できます。鉄業界という特殊な業界の為、主要な業務プロセスが非標準的であり、ある程度のカスタマイズを行ったようですが、「システムを業務に合わせる」という事に執着せず、各部門の現場が業務プロセスの標準化を行った事が、ERPシステム導入の成功に結びついたのではないでしょうか。 例外処理(局所的な非標準的業務プロセス)がある場合。対応する処理内容は単純でも、その原因は何レベルもの入れ子状になった重層的な問題である場合が少なくありません。また、その原因は他部門であるとか、購買業者、外注業者、客先や倉庫業者が持つ制約条件に起因する場合があります。詳細な原因の究明を行い、関連部所や関連会社を含めて、業務プロセスの最適化を可能な限り行います。社外に起因している場合で、その会社の理解や協力を得られない場合には、その例外処理はシステム外で対処するようにします。ERPシステムは例外処理の対応を苦手としていますが、単純にシステム外処理として排除するのではなく、例外処理の原因となる非標準的業務プロセスの解決を行うように努める事で、現場の担当者も、この例外処理が何故発生するのかという理由が分かり、業務プロセスを見直すとしても、システム外とするにしても、当該部門の管理者や担当者の理解を得やすくなります。 いきなりビジネスプロセス・リエンジニアリングの話しに入りましたが、現在の業務プロセスを否定して改善提案を行う為には、販売・購買・生産・在庫など、企業が行う業務には、合理性を持つ標準的な業務プロセスが存在していると認める事が前提となります。 ERPシステムのパッケージは、当然ながらその標準的な業務プロセスを念頭に置いて設計されていますので、システムに合わせて業務を最適化するのではなく、標準的な業務プロセスに近づくように業務を最適化するという考え方が正しいと言えます。故に、企業の業務プロセスが標準的であるならば、パッケージソフトをそのまま使用する事も可能な訳です。しかしながら実際の企業はそう簡単ではありません。 現実のビジネスはシステムではなく人間が行います。人間は矛盾や例外を許容しますので、顧客や購買業者の事情に適応しながら構築された現在の業務プロセスは、標準的な業務プロセスと比較してギャップがあります。このギャップを如何に埋めるかが、ERP導入プロジェクトの成否を分ける重要な鍵の一つとなります。 ところが、業務プロセスやシステムの変更を行おうとすると、大きな問題に直面します。導入責任者が経営者を説得し、やっとビジネスプロセスの改善を行おうとすると、今度は現場の実務担当者から大きな抵抗を受ける事になります。なんだかんだと問題はあっても、とりあえず廻っている手慣れた業務プロセスを大幅に変更する事は、業務担当者にとってデメリットの方が大きいのです。また、業務プロセスを変更する事で作業量も作業時間も増大します。このように、古い手段から手段へ変更する場合に生じるコストの事をスイッチングコストと言いますが、業務プロセスの改善は、大きなスイッチング・コストを伴い、これを乗り越える事は容易ではありません。 総論としては了解できるビジネスプロセス・リエンジニアリングが、すべてのERPシステムの導入事例で、必ずしも成功する訳ではない理由がこれです。 この問題に対する回答は、上記の日鐵商事のSAP導入事例の中にあります。その部分を以下に引用します。 「3度にわたる全社説明会も、営業部門に対する徹底したヒアリングも、経営トップの高い意識と全面的な支援があって実現したものです。ことあるごとにNEXTプロジェクトの意義について経営トップから全社員にメッセージを発信していただいたおかげもあり、全社一丸となってプロジェクトを遂行する環境を整えることができました。経営トップの意志を受けて、われわれプロジェクトメンバーも地道に努力を重ね、その結果として得られた全社員の意識の高まりに支えられながらプロジェクトを進めることができたのは本当によかったと思います」 企業トップがSAP導入を推進するという強い意思を永続的に示す事、トップの意思が末端まで伝わる為のガバナンスが企業内で正しく働いている事、これらがあってこそ、大きなスイッチング・コストの壁を超えて、ビジネスプロセス・リエンジニアリングを実施できるのだと考えます。

ERPシステムの導入が難しい理由(3)カスタマイズ依存の問題

本シリーズ最初の記事で、「この資料で注目すべきは、外資および中資で規模の大きな会社が、ERPシステムの導入に成功し易い傾向がある」と述べました。会社の規模が大きくなると、税務署や監査法人との関係で、社内の管理体制は必然的に整備され、規模に応じた高い管理力を要求されます。ガバナンスの問題で述べたように、会社組織がしっかりしていて、トップの指示が本来の指揮系統をたどって末端へ浸透する事があたりまえにできる会社では、ERPシステム導入の環境が整備されていると言えます。しかし他にも、会社の規模の大小で、ERPシステムの導入リスクに違いが生じる場合があります。 大企業と小企業では、当然の事ながらシステム導入の為に準備する予算に大きな違いがあります。大企業は高機能のパッケージやサーバーを選択し、ユーザー数も多いのでERPシステム導入の全体予算は100万元を軽く超え、非常に高額になります。こうなると、購入側の企業(導入責任者)も、販売側の業者(プロジェクト責任者)も、導入失敗した時に大きなダメージを受ける事は容易に想像できます。そこで業者側は、導入リスクを低減させる為に、ERPシステム導入前の業務フローの詳細な分析とBPR(ビジネスプロセス・リエンジニアリングとは要するに業務フローを最適化する為の改善)を提案する事が一般的です。この為に導入費用は更に大きく膨らみますが、企業側の責任者もリスク回避の為にそれを受け入れる可能性が高くなります。そして、この工程の有無は、ERPシステム導入の結果を左右する大きな要素となります。 多くの企業の中間管理職や現場担当者は、現在の組織構成や業務フローはかなり最適化されており、「我々にとってベスト、あるいはよりベターである」と考えている 事が多いようです。その一方で経営者は、「毎月財務の締めが遅れる」、「在庫の精度が悪い」、「生産工程の進捗が見えない」といった管理力の問題を抱えている事が多く、その問題を解決する為にERPシステムを導入したいと考ています。これは要するに、各部門は業務への最適化が進んでいるが、会社全体についての最適化はされていないという状況を表しています。 このような状況の企業がERPシステムを導入する場合、現在の業務フローへぴったりフィットするように大幅にカスタマイズする場合と、ビジネスプロセス・リエンジニアリングにより最小限のカスタマイズに抑える場合とでは、導入リスクは大きな違いとなります。 「現場の業務は既に最適化されている」という前提でERPシステムの導入を開始すると、必然的に「現場の業務に合わせてシステムをカスタマイズせよ」という強いニーズが生まれ、ERPシステムは大幅なカスタマイズを行う事になります。特に日系企業においては、このようなニーズが強い事は私も経験的に知っています。しかしながらカスタマイズに依存したERPシステムの導入を行うと、導入リスクが飛躍的に高まります。その理由は次の通りです。 多くの企業は、てっとり早く利益を高める為に人件費の削減を検討します。ERPシステムが存在せず、人件費が必要最小限となるように最適化された「現場」には、たくさんの非正規な業務フローや例外処理が存在します。人間がエクセル表で業務を管理している場合、担当者が実行可能なあらゆる非正規な業務フローや例外処理は容易にエクセル表に盛り込む事ができます。エクセル表による管理なら、新しい例外処理の発生に応じて毎日でも管理帳票を変更する事ができます。ところが、あらゆる業務システムにとって、非正規な業務フローや例外処理への適応には個別のカスタマイズを必要とします。100の例外処理に適応するには、100のカスタマイズが必要になるのです。更に非正規な業務フローや例外処理は、ERPシステムの複雑なデータの一貫性を損ないます。それにより、ERPシステムが持っている多数の管理レポートが悪影響を受け、レポートの信頼性を損ないます。出来上がってみたら、「こんな筈ではなかった」というERPシステムの多くは、例外処理への対処を誤った事が原因です。 上記で簡単に述べましたが、ERPシステムは受注から出荷までの処理情報が財務と一体化され、全体が一貫性を保つように構築された、大きくて複雑なシステムです。大幅なカスタマイズとは、複雑に構成された各部分の連結を大規模に壊して再構成する作業なので、ある意味、再開発するようなものです。それを3ヶ月とか6ヶ月の短期間で行う事はそもそも困難なのです。業者側の営業は契約欲しさに無理を通して受注しますし、顧客側はそういうところが見えないので「それが可能である」と期待しますが、結局は納期が大幅に遅れ、問題の多いシステムが納品される事になります。SAPの業者コンサル向け導入ガイドには、「カスタマイズは可能な限り受けないように」と書かれているそうですが、主要な理由がこれです。 上記のような理由によって、企業側が「実際の業務フロー」とシステム側の制約のギャップを、カスタマイズに依存して乗り切ろうとした場合、カスタマイズ費用が高額になり、開発納期が長くなるだけでなく、開発後のテスト期間が長期化し、カスタマイズ部分の仕様上の問題が後から後から湧き出てきて、何年も続くエンドレスの開発プロジェクトとなるか、出来上がっても使えないシステムとしてギブアップする事になる場合が多いようです。 そこで、このような問題を最小限とする為に、先に述べた、会社全体で業務フローの最適化を行う為の改善(ビジネスプロセス・リエンジニアリング) が登場します。これについては次の記事で述べたいと思います。