RFI、RFQ、及びRFP:相違は何ですか。

B2Bビジネスの売り手の側面のあらゆる長さの間働いたら、あなたのプロダクトおよびサービスに興味がある顧客からRfpを受け取ること “Request for proposal”の略で、RFPは、企業レベルのサービスを探している企業が、複数のベンダーからの製品とコストの概要を一度に取得するために使用できる文書です。 ベンダーがRFPに参加すると、製品、サービス、方法論、および会社のニーズを満たすためのコストに関する一連の質問に答えます。,

エンタープライズソフトウェアでRFPがどれほど大きな役割を果たしているかを考えると、私たちの多くは、それらがどのように構造化されるべきか 数ヶ月前、私の同僚Chrisは、多くの企業が”RFPプロセスを間違っている”と主張する記事を書いています。”RFPを送信する前に十分なデューデリジェンスを実行していないことによって、彼は書いた、会社は最高のそのニーズに応えることができる非常にベンダー,

現代のRFPを悩ませるもう一つの問題は、多くの場合、それがまったくRFPではないということです。 これは、Rfp、Rfi、およびRfqに適用される包括的な用語になっています。, すべての三つは共通して特定の機能を持っていますが、それぞれが明確な区別を持っており、それらの区別を理解することは、ベンダーを検索するとき

RFI

“request for information”の略で、RFIは実際には、彼らが参入しようとしている市場を理解していない企業が使用する予備的な文書です。, たとえば、CRMを探している企業の場合、CRMの経験がなく、CRMスペースのオプションの範囲を理解したい場合は、RFIを使用します。

RFIは事実発見の文書であるため、ベンダーがその全範囲の製品について話すことを可能にするオープンエンドの質問をしたいと思うでしょう。 通常、RFIはあなたが抱えている広範なビジネス課題を述べ、その後、ベンダーはそれらの課題のコンテキスト内でその応答を調整することができます。, 多くの場合、ベンダーは市場での地位（たとえば、どの業界に特化しているか）、製品のライセンス方法、その他の手数料について説明します。

RFP

RFP”Request for Proposal”は、ベンダーに顧客の問題やビジネス要件に対する解決策を提案するよう求めるドキュメントです。 実際には、会社がRFIからRFQに移行することはまれです（以下で明らかになる理由から）。, RFPは、プロジェクトのビジネス目標を概説し、要求される作業に必要な特定の要件を特定することによって、企業のニーズが何であるかという点で、はるかに特異性が含まれている必要があります。 このドキュメントの鍵は、ベンダーが有効なソリューションを提案するために必要なコンテキストを提供するのに十分な詳細があることですが、ベンダーがそれらのニーズを満たすために創造性とベストプラクティスを適用す,

RFQ

“見積依頼”の略で、RFQは、会社が必要とする正確な仕様にドリルダウンし、さらに詳細な文書です。 B2BソフトウェアプロジェクトにRFQが使用されている状況では、同社は現在のシステムと、将来どのように変更または改善したいかを十分に知,

ベンダーが問題に対する創造的な解決策を提案する柔軟性を可能にするRFPとは異なり、RFQを展開する企業は創造性を求めるのではなく、ベンダーが予め定められた仕様を使用してソフトウェアを展開することを求めています。 通常、RFQには各要件を一覧表示するテーブルが含まれており、仕入先にその要件を満たす能力を評価するように要求します。, その後、ベンダーは、要件をすぐに満たすことができるかどうか、何らかの構成が必要かどうか、カスタムコードが必要かどうか、またはサードパーティベンダーを活用する必要があるかどうかを指定します。

どちらがベストですか？

ベンダーとして、私は特定のバイアスでこの問題に遭遇しますが、RFQではなくRFI-RFPルートを好みます。 どうして？ 通常、RFQで私たちに来るクライアントは、彼らのアプローチでクローズド志向になる傾向があります。, あなたは創造性とベンダーの蓄積された制度的知識に自分自身を開いていないので、あなたは基本的にあなたが新しいものを学びたくない、またあなたが新しいアプローチに自分自身を開きたくないことを知らせています。

私の経験では、多くの顧客がRFQをRFPと誤って名付けていますが、応答するときには、さまざまなソリューションを”提案”し、RFPの目的である提案されたオプションについてその後の会話をすることはできません。, このようなケースでは、要件のリストを記入し、その定義によって単にRFQである各明細の詳細なコストを与えるように求められます。 RFQは、既存のシステムに追加または拡張するプロジェクトに適しています。 このアプローチは、ベンダーが現在のシステムが行うことを正確に行うシステムを提供するように要求するという罠に簡単に陥る可能性があるため、, その場合は、最初に新しいシステムを実装している理由を見て、ビジネス目標がプロジェクト目標に沿っていることを確認する必要があります。

通常、今日使用しているものがニーズを満たしていないため、新しいシステムを実装しようとしています。 それが本当にそうであれば、ベンダーに現在のビジネスプロセスを協調的に議論する柔軟性を与えない限り、どのようなシステムがニーズを満たすかを, あなたは単にあなたが今日何をすべきかに基づいて詳細なニーズのリストを出す場合は、ベンダーがそのリストを満たすために彼らのソリューションを靴

RFQの考え方は、要するに、あなたのビジネスプロセス全体で見ることができる肯定的な変化のいくつかをアンダーカットします。 そして変更に目をつぶることは会社の陳腐化へ最も速い道である。

あなたは最先端のCRM技術で次のレベルにあなたのビジネスを取る準備ができていますか？ 詳細はこちらをご覧ください。