ホーム > ブログ

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

本シリーズ最初の記事で、「この資料で注目すべきは、外資および中資で規模の大きな会社が、ERPシステムの導入に成功し易い傾向がある」と述べました。会社の規模が大きくなると、税務署や監査法人との関係で、社内の管理体制は必然的に整備され、規模に応じた高い管理力を要求されます。ガバナンスの問題で述べたように、会社組織がしっかりしていて、トップの指示が本来の指揮系統をたどって末端へ浸透する事があたりまえにできる会社では、ERPシステム導入の環境が整備されていると言えます。しかし他にも、会社の規模の大小で、ERPシステムの導入リスクに違いが生じる場合があります。

大企業と小企業では、当然の事ながらシステム導入の為に準備する予算に大きな違いがあります。大企業は高機能のパッケージやサーバーを選択し、ユーザー数も多いのでERPシステム導入の全体予算は100万元を軽く超え、非常に高額になります。こうなると、購入側の企業(導入責任者)も、販売側の業者(プロジェクト責任者)も、導入失敗した時に大きなダメージを受ける事は容易に想像できます。そこで業者側は、導入リスクを低減させる為に、ERPシステム導入前の業務フローの詳細な分析とBPR(ビジネスプロセス・リエンジニアリングとは要するに業務フローを最適化する為の改善)を提案する事が一般的です。この為に導入費用は更に大きく膨らみますが、企業側の責任者もリスク回避の為にそれを受け入れる可能性が高くなります。そして、この工程の有無は、ERPシステム導入の結果を左右する大きな要素となります。

多くの企業の中間管理職や現場担当者は、現在の組織構成や業務フローはかなり最適化されており、「我々にとってベスト、あるいはよりベターである」と考えている 事が多いようです。その一方で経営者は、「毎月財務の締めが遅れる」、「在庫の精度が悪い」、「生産工程の進捗が見えない」といった管理力の問題を抱えている事が多く、その問題を解決する為にERPシステムを導入したいと考ています。これは要するに、各部門は業務への最適化が進んでいるが、会社全体についての最適化はされていないという状況を表しています。

このような状況の企業がERPシステムを導入する場合、現在の業務フローへぴったりフィットするように大幅にカスタマイズする場合と、ビジネスプロセス・リエンジニアリングにより最小限のカスタマイズに抑える場合とでは、導入リスクは大きな違いとなります。

「現場の業務は既に最適化されている」という前提でERPシステムの導入を開始すると、必然的に「現場の業務に合わせてシステムをカスタマイズせよ」という強いニーズが生まれ、ERPシステムは大幅なカスタマイズを行う事になります。特に日系企業においては、このようなニーズが強い事は私も経験的に知っています。しかしながらカスタマイズに依存したERPシステムの導入を行うと、導入リスクが飛躍的に高まります。その理由は次の通りです。

  1. 多くの企業は、てっとり早く利益を高める為に人件費の削減を検討します。ERPシステムが存在せず、人件費が必要最小限となるように最適化された「現場」には、たくさんの非正規な業務フローや例外処理が存在します。人間がエクセル表で業務を管理している場合、担当者が実行可能なあらゆる非正規な業務フローや例外処理は容易にエクセル表に盛り込む事ができます。エクセル表による管理なら、新しい例外処理の発生に応じて毎日でも管理帳票を変更する事ができます。ところが、あらゆる業務システムにとって、非正規な業務フローや例外処理への適応には個別のカスタマイズを必要とします。100の例外処理に適応するには、100のカスタマイズが必要になるのです。更に非正規な業務フローや例外処理は、ERPシステムの複雑なデータの一貫性を損ないます。それにより、ERPシステムが持っている多数の管理レポートが悪影響を受け、レポートの信頼性を損ないます。出来上がってみたら、「こんな筈ではなかった」というERPシステムの多くは、例外処理への対処を誤った事が原因です。
  2. 上記で簡単に述べましたが、ERPシステムは受注から出荷までの処理情報が財務と一体化され、全体が一貫性を保つように構築された、大きくて複雑なシステムです。大幅なカスタマイズとは、複雑に構成された各部分の連結を大規模に壊して再構成する作業なので、ある意味、再開発するようなものです。それを3ヶ月とか6ヶ月の短期間で行う事はそもそも困難なのです。業者側の営業は契約欲しさに無理を通して受注しますし、顧客側はそういうところが見えないので「それが可能である」と期待しますが、結局は納期が大幅に遅れ、問題の多いシステムが納品される事になります。SAPの業者コンサル向け導入ガイドには、「カスタマイズは可能な限り受けないように」と書かれているそうですが、主要な理由がこれです。

上記のような理由によって、企業側が「実際の業務フロー」とシステム側の制約のギャップを、カスタマイズに依存して乗り切ろうとした場合、カスタマイズ費用が高額になり、開発納期が長くなるだけでなく、開発後のテスト期間が長期化し、カスタマイズ部分の仕様上の問題が後から後から湧き出てきて、何年も続くエンドレスの開発プロジェクトとなるか、出来上がっても使えないシステムとしてギブアップする事になる場合が多いようです。

そこで、このような問題を最小限とする為に、先に述べた、会社全体で業務フローの最適化を行う為の改善(ビジネスプロセス・リエンジニアリング) が登場します。これについては次の記事で述べたいと思います。

Leave a Reply