次の例はＥＲＰ導入上の障害です。ＥＲＰは一元化した情報で経営資源に対する計画・統制を行うようにビジネスプロセスを再構築し、そのスピードを上げるという思想です。しかしながら、現在日本ではＥＲＰの実施とはＥＲＰパッケージソフトの導入と同義と解釈されていることが多いようです。

　パッケージソフトの導入と解釈しても、うまくいけばソフトウエア開発期間の短縮や、他社のベストプラクティスの取り込み、最新の情報技術の導入などが効果としてが得られます。ところが導入が必ずしも成功していないのが実態です。不成功の状態には以下のようなものがあります。

・財務管理などＥＲＰパッケージの一部の機能だけを導入したため情報の一元化による 　　業務のスピードアップが実現できない。またパッケージと既存ソフト間の情報交換の 　　ためのインターフェイスプログラムの開発費用がかさむ。 　・自社の業務をパッケージソフトに合わせられずに元のソフトに戻した。 　・パッケージソフトを自社の業務に合わせたために、情報の一元化ができない。 　　またソフトのカスタマイズや追加開発が多くなり、開発費用と期間が 　　独自開発の場合と同等かそれ以上にかかる。

　こうした状態に陥る原因は以下のような点です。

�@「ＥＲＰを導入する目的・方針が不明確」
　ＥＲＰ導入がビジネスプロセスの再構築なのか、ＥＤＰシステム開発費用の削減なのかが不明確な場合です。例えば経営者は開発費用の削減を考え、ＥＤＰ部門では「どうせ導入するなら、この辺のプロセスをついでに変えたい」と思い、現業部門では「今の作業を機械化してくれれば」と願っていたとします。明文化した目的や方針なしに、関係者がこの思いや願いを持ったまま進めるとどうなるかは説明するまでもないでしょう。

�A「ビジネスの個別プロセスのレベルが低い」
　営業・開発・生産・会計など、ビジネスを構成する個別プロセスのレベルが低い場合です。プロセス間の情報が一元化・スピードアップされても、個別プロセスのスピードや精度がボトルネックになっているとERPは効果を発揮しません。効果が出ないどころか、精度の悪い情報が修正されずにビジネスプロセス中に波及するといったことさえ起こります。

�B「ＥＲＰを導入して目指すビジネスプロセスの姿が描けない」
　ビジネスプロセス再構築の方針はあっても、新しいプロセスの設計図を具体的に描けない場合です。これはリーン生産の場合と同様、現状の姿すら描けないことが要因です。適切な手法を用いて姿を描く作業を意図的に実施する必要があります。

　また、目指す姿がないと導入しようとするパッケージソフトを評価できません。目指すビジネスプロセスと、パッケージソフトが前提としているビジネスプロセスとのギャップがどこにあるかを認識できなければ、そのソフトが妥当であるかは判断できないのです。

�C「ＥＲＰ導入に現場に抵抗する」
　新しいプロセスの設計図が描けても生産、販売などの職場において変革に対する抵抗が強いケースです。新しいプロセスに変える時に技術的な困難が伴う時はこれにあたります。しかし技術的な困難よりもむしろ評価制度が要因となっている場合が多いのです。

　プロセスの変革を誘導する評価制度がないこと、または現状の評価制度そのものが阻害要因になります。例えば「総生産リードタイムなど計測したことも考えたこともなかった。だからそれを短縮しろと言われても困る」「ロットサイズを小さくすると製造原価が上がる」といった場合です。