ERP（Enterprise Resource Planning：統合型基幹システム）を導入したいと考えた時、ERPベンダー各社やシステムインテグレーターに「RFP（Request for Proposal：提案依頼書）」の提出を行います。このRFPの仕上がり次第で導入が成功するかどうかに大きく変わります。このRFPでつまずいてしまう企業もありますので、本稿ではRFPの基礎について解説します。RFPに関する知識を付け、ERP製品の導入を成功に導くためにぜひ役立ててください。
RFPとは？
RFPは文字通り、ERP提供企業各社に「提案を依頼する」ための書類です。では、提案を依頼するとはどういうことなのでしょうか？
現在のERP市場には非常に多くのプレイヤーが存在します。海外製のもの、国産のもの、製造業に特化したものなどなど、ERP製品の数だけ多種多様な特徴があります。ERPを導入する企業にとって第一関門となるのが、「会社にとって最適なERPを選ぶ」ことです。ERPは統合型基幹システムといって、経営活動に欠かせない基幹システムを複数統合している製品ですので、それによって様々な経営効果がある反面、業務プロセスがERPに依存するという側面もあります。
そのため、ERPそのものが会社の業務プロセスや現場環境にマッチしていないと、ERPによる経営効果を最大限引き出すことが難しくなります。この関門をクリアするために、ERP提供企業各社にRFPを送付し、ERPに関する提案を受けることで会社にとって最適なERPが選びやすくなるということです。
ちなみに、RFPと類似した書類として「RFI（Request for Information：情報依頼書）」があります。これは、RFPよりももっと簡素的な依頼書であり、ERPはERPベンダーに関する基本的情報の提供を求めるというものです。RFPと同時に送付してもよいですし、RFPの前段階として活用するのもよいでしょう。
なぜRFPが必要？
「RFPが無くても、製品情報をしっかりと調査すれば会社に最適なERP製品が判断できるのでは？」という意見もあるでしょう。しかし、ERP製品の選定はそう簡単にいくものではありません。なぜなら、ERPを導入する目的は企業によって千差万別であり、同じERP製品でも目的に応じて構築方法などが変わるため、製品情報を確認しただけではそれが会社に最適かどうかの判断が難しいからです。
たとえば、ある経営課題を解決するためにERP導入を決意し、会社独自の製品情報調査によって「このERP製品なら我が社の課題を解決できそうだ！」と確信したERP製品を導入したとします。しかし実際に導入してみると、会社の業務プロセスにマッチしていなかった、解決できるはずの経営課題が「運用次第で対応」といったように、ERP製品そのものの特徴とマッチしない可能性が大いにあります。
これはあくまで一例ですが、成功すると確信したERP製品導入が、実は会社にまったくマッチしていない、むしろ業務プロセスが複雑になってしまったという失敗事例がたくさんあります。だからこそRFPを作成し、送付し、ERPベンダー各社からの正式な提案を受け、それから会社に最適なERP製品を選ぶことがとても大切なのです。
何事も正しいステップがあるように、RFPはERP導入を成功させるために欠かせないステップとなります。
[RELATED_POSTS]RFPの目的は「良い提案を受けること」
1つ誤解しないでいただきたいのは、「RFPはERP製品を選ぶための書類」ということです。確かにRFPは会社にマッチするERP製品を選定するための、プロセスの一環として使用するステップです。しかしながら、その本質的な目的は「ERPベンダー各社から良い提案を受けること」です。
ERPベンダー各社にRFPを送付すると、こんなケースがよくあります。
A社はERP導入にあたり、いくつかピックアップしたERP製品の提案書を依頼するためにRFPを作成。ERPベンダー各社に送付しました。RFPの内容には、ERPに実装したい機能要件の一覧表を作成し、その対応可否について情報を求めました。「時間をかけて作ったし、これなら提案書には、ほとんどの機能要件に対して「対応可能」と記載されています。A社は、「我が社にとって、一体どの製品が最適なのだろう？」と、判断に困ってしまう結果になりました。
A社のRFPを受け取ったERPベンダー各社は、一覧表からERPに実装したい機能要件を把握することはできても、そのプライオリティ（優先度）までは把握できません。従って、ほとんどの機能要件に対して「対応可能」と記載するしかなく、しかし実際には、アドオン開発で対応したり、運用で対応したりと、ERPベンダー各社によってその中身は大きく違うのです。
もしもこの状態でERP製品選定を行ったら、A社がERP導入に成功する可能性は低くなるでしょう。つまり、A社はRFPによって「良い提案」を受けることができなかったのです。では、「良い提案」の定義とは何でしょうか？
それは、ERPベンダー各社がクライアントの経営課題やERP導入を決断した背景などをしっかりとくみ取り、機能要件に対しする単純な対応可否だけではなく、どういった方法で対応するかを記載し、時にはクライアントのことを考えて機能要件の添削などの提案を含めたものを「良い提案」と呼びます。
[SMART_CONTENT]
「良い提案」を受けるためのRFPを作ろう！
「ERP導入は初めてだし、RFPなんか作ったことがない、作れる人もいない」という企業でも問題ありません。RFP作成は、下記に紹介するポイントを押さえるだけでERPベンダー各社から「良い提案」を受けることができます。ここでは代表的な項目をご紹介します。
1.RFP（提案依頼書）の趣旨
なぜERPを導入したいのか？なぜRFPを送付するに至ったのか？などの経緯をRFPの趣旨として説明すると、ERPベンダー各社はERPが必要になった背景を読み取ることができます。
2.システム構築方針
システム構築の際に会社が取っている方針などがあれば、それも漏らさず伝えることでより要望に沿った提案ができます。情報セキュリティ人材が在籍しておらず、システム構築方針を持っていない場合は特別記載せずとも、ERPベンダー各社が他の情報から最適な構築方法を提案してくれます。
3.現状抱えている課題
現状として、どういった経営課題や業務課題を抱えているのか？RFPを作成する前に課題の洗い出しを行い、解決優先度の高い課題についていくつか説明することで、その課題に沿った提案が受けられます。
4.機能要件
機能要件とは「ERPにこんな機能を実装したい」というクライアントの要望です。ただし、「To-Beモデル（理想型）」ではなく「Can-Beモデル（現実型）」の機能要件を提示することが大切です。「To-Beモデル（理想型）」とは、部門ユーザーの要望を一気に吸い上げて、それを機能要件に反映させたようなタイプのもので、この場合、アドオン開発（追加開発）が膨れ上がり、開発コストが高額になる可能性があります。一方、「Can-Beモデル（現実型）」とは吸い上げた要望から優先順位や業務プロセスの繋がりを考慮して、必要な機能要件だけをまとめたものです。機能要件を作る際は「Can-Beモデル（現実型）」を意識しましょう。
5.導入要件
導入要件は「When（いつ？）」「Who（誰が？）」「What（何を？）」「Where（どこで？）」「How（どうやって？）」という「4W1H」の視点で説明するとまとまりが良く、分かりやすくすることができます。ただし、導入要件があまりに企業都合だと、何らかのトレードオフ（要件をクリアするための犠牲）が必要になるため、この点をしっかりと考慮していないと良い提案は受けられないので注意しましょう。
6.インターフェース要件
導入するERP製品が、周辺システムとどういったデータ連携を実現したいのか？データの内容、連携方法、連携の頻度などを明確にしておくと、システム環境を総合的に捉えた提案を受けられます。
7.利用環境
これから導入するERP製品は、当然ながら会社の環境に適合したものでないといけません。サーバーの種類とOS、クライアントの種類とOS、利用可能なブラウザ、セキュリティシステムの有無など、細かい利用環境を記載しましょう。
8.情報開示範囲と秘密保持契約
RFPの送付は、ERPベンダー各社の会社の機密情報を少なからず伝えることになります。そのため、どこまで情報を開示するのかの範囲をしっかりと決めて置き、重要な情報に関しては機密保持契約を交わすことが欠かせません。
いかがでしょうか？これらのポイントを押さえて、皆さんもERPベンダー各社から「良い提案」を受け、会社にとって正しいERP製品を選びましょう！
