これはある専門商社の例です。使用しているコンピュータが古くなったので、リプレースすると同時に、営業力を強化するためのシステムを新たに導入する計画が始まったのですが、社長は自ら陣頭指揮を取ることなく、システム部門担当の役員にすべて任せてしまいました。

　まず、ユーザー部門である営業部門とシステム部門の合同プロジェクトがスタートしましたが、両者は互いに相手のことをよく思っていません。
　システム部門は「営業の連中はシステムのことが判っていないので、勝手なことを言う。彼らの言うことを全部聞いていたら、システムができない。」と言い、営業部門は「システム屋は自分勝手に好きなようにシステムを作るから、使い物にならないものになってしまう。」と言う始末です。
　このような時には社長が両者の上に立ち、経営的な視点からの判断を下していけばプロジェクトは迷走しないですむのですが、この社長は“システムはシステム部門に任せる”という姿勢を崩しませんでした。
　結局、システム部門主導で開発は行なわれシステムそのものは稼動したものの、営業部門にとっては使いづらいものになってしまい、当初の営業力強化の目的は達成できないままです。

　次に紹介するのはある製薬会社の例です。今までは営業支援、販売管理、生産・購買管理、会計管理のシステムが別々に稼動していましたが、今回ERPパッケージを利用して、統合システムに切り替えるプロジェクトが発足しました。
　しかし、統合システムを構築するという点では各担当部門の意見は一致しているのですが、各業務システムの検討の段階になると、どの部門も現行システムとの継続性を強く主張し始めたのです。特に営業畑の古参社員は、現在の業務の仕組みが最適であると信じています。

　ITベンダーはERPパッケージによる業務モデルの優位性を説くのですが、もともとこのERPパッケージは外国流の業務モデルを基にしているので、確かに日本的な商慣習に合わない部分もありました。そこで、現場の担当者はカスタマイズによるERPパッケージの変更を求め、結局最終的にはITベンダーが押し切られて、かなりの部分がカスタマイズされることになりました。
　その結果どのようになったのでしょうか。2年近い開発期間を経て、システムは無事稼動しました。しかし、実際の業務改善は行なっていないので、稼動したシステムは以前と大きく変わったところもなく、またカスタマイズのために開発費用は当初の予算を大幅にオーバーしたこともあり、ERPパッケージによる統合化のメリットは生じていません。

　以上の例では、開発途中で挫折するプロジェクトも多い状況で、どちらもシステムは無事に稼動しているだけでも成功ということになっています。しかし、本来の「業績向上」という大きな目的は達成できていないことを忘れてはいけません。それを考えると、これらは隠れた失敗例であると言えるでしょう。