失敗事例にみるRFP作成のポイント~2.社内プロジェクトの構成

RFPを作成する場合、提案依頼を行う側は社内プロジェクトを設けるのが一般的ですが、ここではIT部門のみならず、業務部門や調達部門が参画することが好ましいといわれています。

IT部門や契約調達する部門だけでなく、実際にシステムの利用・運用に関わる部門が新たなシステム導入に参画するのは好ましいことですが、多くの部門が集まりながら、その効果を享受できないケースもあります。

効果が得られないばかりか、システム化のポイントがずれてしまったり、作業が遅延したりというデメリットの方が大きくなることもあります。

多部門が集まる意義は?

RFP作成において複数部門が集まりプロジェクトを構成する意味は、情報システムに関連する多様な部門・多様な階層が抱えている課題・問題点、意見・要望を集めることにあります。

しかし、このようなプロジェクトを構成したにもかかわらずシステム稼働後に問題が出る原因としては、部門のトップは集まっているが「現場の要望が吸い上げられていないケース」や、「部門間で調整する際に適切な判断を行えなかったケース」が挙げられます。

それぞれの部門長が集まっているものの、各部門内の意見集約が不十分であるために単なる「部門長」の意見交換で終わり、最終的には「ITベンダーにお任せ」となることもあります。また、ある程度、部門の意見を持ち寄ったケースでも、プロジェクト内で適切な調整(解決策の策定)ができず、新たな情報システムに適切な機能を盛り込めなかったという事もあります。

特に、組織が大規模化するとこのようなことが発生しやすくなるので、これを回避するためには部門長の資質の問題とみるのではなく、RFP作成プロジェクトの仕組みで解決を図ることが重要です。