ベンダー及びパッケージ選定プロセスのポイント、RFPとRFIについて
2020年04月08日(水)掲載
はじめに
「ステップ4」のベンダー選定・評価プロセスの流れを、以下の3-2.図1で例示しました。尚、下記は、RFIとRFPを使用する2段階での選定ケースがあります。また、下記の3-2.図1中のPMPとは、プロジェクトマネージメント計画書(Project Management Plan)を意味します。
3-2.図1 ベンダー選定・評価プロセス
では、3-2.図1をもとに、ベンダー選定・評価プロセスの中で重要なポイントを解説しましょう。尚、「選定準備フェーズ」で、候補ベンダーからのRFP回答が返ってくるまでに実施すべき作業の詳細は、「ステップ6:ベンダー提案回答受領迄になすべきPMPの作成」に記載しております。
そして「選定・評価フェーズ」作業についても、「ステップ7:プロジェクトマネージメント計画書(PMP)をもとに選定」のところで詳しく解説しますので、ここでは全体の流れとポイントのみを解説しておきます。
RFPとRFIについて
パッケージありきで候補ベンダーを選定することは、再構築プロジェクト全体を考えると必ずしも得策ではないということを念頭において、RFIやRFPを作成することが重要だと説明してきました。ここで今一度RFIとRFPについて言葉の意味をおさらいしましょう。
RFIとRFPとは?
●RFI
RFIは、Request For Information、の頭文字をとっています。つまり、直訳すると、情報の提供を依頼する書類です。
ITベンダーやSIerは各諸情報を理解しないと、クライアントに最適な提案をできません。このため、クライアント(依頼元)のどういった情報を知りたいか、それらの情報を書類にして情報提供を依頼するのです。
また、ベンダー側が出すRFI以外にも、依頼する側が出すRFIもあります。パッケージ情報やベンダーの情報を依頼する書類です。このため、RFIはどちら側からも出す可能性があります。
●RFP
RFPとは、システムの構築要件など、依頼側がベンダーに出す書類です。ベンダーがより具体的に提案ができるように、クライアント側から依頼を出すのに使います。
RFPなしにベンダーを探してしまうと、時間がかかったり、提案がズレてしまったり、時間のロスが生まれてしまうので、効果的なRFPの作成が必要です。
RFPについては、以下にて詳しく説明していますので、ご覧ください。
●RFIとRFPの違い、関係性
RFIとRFPで比較すると、RFIの方が作成に時間がかからないメリットがあります。このため、いきなりRFPを作成するよりもRFIと貰ってから作成した方がさらにロスのないベンダーとのコミュニケーションが完成します。
・RFIとは、情報提供を依頼する書類である。ベンダーから欲しい情報を依頼されるものであるが、発注側から出す場合もある。
・RFPは、システムの構築要件について、依頼側がベンダーに出すものである。
・RFPをいきなり作成するのは工数がかかるため、RFIをもらってからRFPを作成するとロスがなくなる。
事前準備フェーズのポイント
一緒にプロジェクト推進ができるベンダーを選ぶ
先ず、ここで一番重要なことは、一緒に再構築プロジェクトを推進して貰えるベンダー(パッケージベンダー、或いはITベンダー)を特に意識して選定することです。ITベンダーでも、複数のパッケージライセンスを提供できるベンダーもありますので、パッケージベンダーにこだわる必要はありません。よって、幅広い観点からRFIを送るベンダーを選定してください。ここで、パッケージのみで判別し、選択肢を狭めてしまうことは非常にもったいないので避けましょう。
10社以上を候補にする
候補ベンダー数は、この段階では少なくとも10社以上は選定する必要があるでしょう。
そして、その中からRFPを送り、回答を貰うベンダーを8社ほど選定します。ここで注意するポイントは、ベンダーが回答内容をよく検討できるように、十分な回答期間を確保することです。よくあるケースは、早くベンダーを選定したいがために、RFPの回答までに1週間~10日間程度しかないケースです。これではベンダーが十分な提案回答書を作成できず、また、RFPの内容に関しての質問・回答の期間も十分に取れません。
可能であれば、最低でも2~3週間ほど確保してください。また、その間の各ベンダーからの質問に対しては、公平性を保つために全ベンダーに同時に回答するように心がけてください。そして、その対応は再構築プロジェクト開始後にメインで加わるメンバーがRFPの内容を深く理解した上で、RFPの問い合わせ対応や回答取り纏めにあたる必要があります 。
既にこの一連のコラム内のRFPの作成部分で、「可能であれば、基幹システム再構築プロジェクト開始後にPMとなるメンバーが、RFPの作成の取り纏めをしてください」と書いたのもこのような背景があります。この再構築「準備フェーズ」の段階から、既にプロジェクトは始まっているともいえるのです。
RFPに関する説明会の実施も検討をする
RFPに関する質問や回答の手順もRFPの中にも記載していると思いますが、依頼するプロジェクトの主旨やベンダーに期待すること、また、これら質問回答の手順等を周知徹底するためにも、RFPに関する説明会を開催するのが望ましいです。各ベンダーからRFP説明会に出席して貰い、RFPを渡すタイミングでこれらについても説明すると良いでしょう。
また、通常、各ベンダーからの出席者は2、3名に絞るのが適切です。なぜなら、各ベンダーの取り纏め営業、取り纏めSE(システムエンジニア)のみならず、プロジェクト開始後にベンダーからメインでプロジェクトに参加する技術者も出席するケースもありますので、2名とお願いしてもベンダー側からそれ以上の出席者を要望してくるケースもあります。それ故に、出社者の人数を平等に決めておく必要があります。誰が(プロジェクトに関わる可能性のあるどのような技術者が)RFP説明会に出席するか否かも、実はベンダー選定上の基準のひとつになり得るのです。
・RFPの回答期限は長めにもうけ、しっかりとした回答をベンダーにしてもらうことで、より良い選定を実現できる。
・ベンダーに自社の狙いを明確に伝えるために、RFPに関する説明会を開催するのが望ましい。その際は、人数比などにも気を配り、「公平性」がある説明会にするようにする。
選定準備フェーズのポイント
各ベンダーがRFPへの提案回答書を作成している間に、企業側としてやるべきタスクはたくさんあります。故に、依頼する企業側にとっても、RFPを送ってから回答受領までのそれなりの期間必要となるのです。これは、3-2.図1の中の「選定準備フェーズ」にあたります。そして、その間になすべきタスクは以下に記載しています。
PMPの作成を行う
●プロジェクトマネージメント計画書(PMP)(案)の作成~
この詳細は、「ステップ6:ベンダー提案回答受領迄になすべきPMPの作成」で詳しく解説しますが、このPMP(案)は、 基幹システムの再構築プロジェクト開始後のバイブルとも言うべき重要な位置づけのドキュメントです。
この「準備フェーズ」の段階では、既に策定済みのプロジェクトの全体計画やRFPの作成段階において策定した情報をもとに、ベンダーに依頼する企業の情報システム部門自らで策定するということが重要なのです。ただし、この段階ではあくまでもPMPのドラフト、つまり素案レベルで十分です。
ベンダーからRFPの回答提案を待っているこの段階で、素案を作成するのは早いと思われるかしれません。しかし、このPMPはベンダー選定の観点からも必要となります。特に最終候補に残るようなベンダーのPM候補から詳細をヒアリングする際に、ベンダーPMの経験やスキルの判断材料にもなります。PMPの項目内容等の詳細は、次回のコラムをご参照ください。
評価基準の策定を行う
●評価基準の策定~
この「ベンダー評価基準」は、「再構築プロジェクトを成功すべく、最適な支援ベンダーを選ぶ」という意味で重要です。この評価基準が明確でないが故に、ベンダーの選定を間違えてその後プロジェクトが大変な状況になるという事例も実際多々ありますので、あながち大げさではありません。
この「評価基準」に関しても、次のコラムの「ステップ7:プロジェクトマネージメント計画書(PMP)をもとに選定」のところで詳しく解説しますが、ここで敢えて少し触れるとすれば、最初の提案回答の内容からベンダーを絞る際のベンダー評価シートの評価項目についてです。
注意すべきことは、この評価シートのみでベンダーの候補を程度絞ってしまうと、そのあとのベンダープレゼンテーションで本当に貴社にとって有益なベンダーを選定から外してしまうというようなリスクも存在するということです。確かに回答の内容も重要です。しかし、ITの導入サポート、プロジェクトサポートとしてのベンダー選びには、単に技術面だけでは評価できない難しい面も多々あります。もし、そのようなドキュメント上では評価できない優れたベンダーを安易に書類上の評価から排除してしまった場合、最終候補ベンダーを選ぶ際に、その中に最適なベンダーがいない選択肢の中から選ばざるを得ず、間違った観点からベンダーを選んでしまうという、後戻りが出来ない状況になる可能性もあります。
よって、安易に書類選考だけでベンダーをふるいに掛けるのは少し注意が必要です。各評価項目の内容、重みも重要となるのです。このあたりの詳細は、次のコラムで詳しく解説します。
・RFP回答してもらっている間に、PMP案を作成する。
・評価シートをもとにした、安易な書類選考では、最適なベンダーを落としてしまう可能性があるので、慎重に選定する必要がある。
評価・選定フェーズのポイント
上記(2)の準備フェーズがしっかりできていれば、あとはそれに従って貴社に最適なベンダーを選ぶだけです。しかし、ここにも重要なポイントがいくつかあります。
詳細は、評価基準同様、次のコラムの「ステップ7:プロジェクトマネージメント計画書(PMP)をもとに選定」のところでも触れますが、ここで先ずひとつだけお伝えしたいことがあります。
ベンダーの選定はプレゼンテーション形式で行うのがおすすめである
それは、ベンダーの選定を、IT部門だけでなく業務メンバーや幹部も含めた場にて、プレゼンテーション方式で行っていただきたいということです。これには、いくつかの明確な理由がありますが、ここでは一番重要な理由を以下に記しておきます。
今の時代、企業にとって将来の企業戦略にも深く関与する基幹システムを支援して貰えるベンダーの選定は、非常に重要であるため、全社的に合意を取った上で進める必要があります。つまり、今後の基幹システム再構築プロジェクトの開始に向けて、企業としての一体感、コンセンサスを得ることが重要なのです。
よく、幹部の中から、「ITは分からないから情報システム部門で決めて貰いたい」というような意見をもらう場合もありますが、企業の基幹システムはITよりも業務のほうが重要であり、これを実現するのがIT、基幹システムなのです。よって、このITの選択を間違えると、企業のIT戦略、ひいては企業戦略全体にも大きな影響を与えます。
・ITベンダーの選定はプレゼンテーション形式で行うのが賢明である。
・企業としての一体感、コンセンサスを得ることが重要なので、IT部門のみでの決定などは避けたほうが良い。
まとめ
最後に、このコラムで私からお伝えしておきたいことがあります。
それは、基幹システム再構築開始前の「準備ステップ」を実施するにあたり、推進体制はIT部門だけではなく、業務部門を考慮したベストメンバーをあてていただきたいということです。当然、現場の業務メンバーは常に多忙であり、時間や費用面で人材リソースにも限りがあるのは承知しています。しかし、メンバーの採択はそれだけ重要なことであると私は認識しております。そして、決して「基幹システムの再構築」プロジェクトの開始を焦らず、じっくりこの「準備ステップ」も重要なステップの一部と認識し、全社的に進めてください。先ほど「企業としての一体感、コンセンサスを得ることが重要」と言わせていただいた理由はここにもあります。
私は、これまで国内外の多くのプロジェクト、特にグローバルERP導入プロジェクトを見てきましたが、この準備フェーズで焦る、もしくは疎かにしたが故にプロジェクトが上手く行かなかったり、結果的にコストが大幅に増額したケースもありました。会社全体で準備フェーズをしっかり取り組むことで、プロジェクトの終盤で業務メンバーから満足のゆく承諾を得られず、本番運用が出来ないというトラブルも避けることが出来るのです。このようなトラブルは、過去多くの企業で発生しており、これは「プロジェクトの準備フェーズ」から推進体制に業務のキーパーソンをプロジェクトに巻き込んでいないことが原因だと考えられます。
そして、プロジェクト失敗の原因をベンダーやパッケージの責任にするケースが多くあるようです。その原因を追求すると、結局は企業側がこの「準備フェーズ」を疎かにして強引にプロジェクトを進めてしまった、あるいは、プロジェクト開始後の企業側のプロジェクトマネージメントが上手くいっていなかったケースが多いと考えられます。これは、ベンダーに多くを任せてしまっている、もしくは企業側のPMにマネージメントスキルが不足している等、企業側にも様々な課題があるが故に発生しています。しかし、これらは事前にPMがリスクマネージメントをすることにより多くの課題は回避することが出来ます。これを称して「プロジェクトマネージメント」、その「リスク管理」を実行する人をPM(Project manager)といい、単にプロジェクトの進捗結果をフォローするだけではPMとは言えません。
PMやPMO(Project Management Office)に関しての詳細は、また別のコラムでの解説としましょう。
私の一連のコラムでは、これまでの私の経験をもとに、今後「IT分野での2025年問題」や「2025年の崖(経済産業省のレポートより)」に対応するために、「基幹システムの再構築」を早急に実施しようとしている企業が、少しでも再構築プロジェクト成功のための参考になる情報をコラムの中で提供させていただきます。
そして、プロジェクト開始後も重要な「ITプロジェクトマネージメント」の失敗事例や成功ノウハウも含めて、この一連の「準備フェーズ」のコラムの中で、併せて随所にふれさせていただきます。
・推進体制はIT部門だけではなく、業務部門を考慮したベストメンバーをあてるのが大事である。
・プロジェクト失敗の原因をベンダーやパッケージの責任にするケースが多くあるようだが、その原因を追求すると、結局は企業側がこの「準備フェーズ」を疎かにして強引にプロジェクトを進めてしまった、あるいは、プロジェクト開始後の企業側のプロジェクトマネージメントが上手くいっていなかったケースが多い。発注側で改善できる箇所も多くあるので、その点を改善していくことが必須。
ベンダー選びでお困りなら
ベンダーにシステム再構築を依頼するのは、コストや労力のかかる作業です。さらに、RFIやRFPの作成など、自社にとって初めての経験であれば、どうすることが正しいのかわからずなかなか難しいものになってしまうでしょう。そもそもRFIにどういった項目を掲載するべきなのか、プロジェクトメンバーにはどういった部門をアサインするべきなのか。基本的な部分から知見がないとわかりませんし、システムに知見のあるベンダーから指示される内容のみで動いていては、最終に自社の事業理解が足りずプロジェクトが転んでしまう可能性もあります。
そんな際に力になるのが、HiPro Bizに在籍するプロ人材です。プロ人材と言うと、経営戦からすべてを指南するイメージがある方も多いと思いますが、昨今のプロ人材の働き方はそれだけにとどまらず、例えば、ベンダーコントロールのようなことも行います。システムの再構築は経営に携わる重要な部分です。だからこそ経営戦略にも実績があり、システム周りにも強い実績あるプロ人材をプロジェクトメンバーに入れ、再構築に向けて動き出していくことで、自社に合った形でのプロジェクト推進が可能です。
HiPro Bizのプロ人材であれば、実働型での支援が可能です。自社に一番適切な形で、実働までを支援します。ご興味のある方はぜひご相談ください。
執筆者H.K氏
大阪大学工学部卒業後、電機業界の大手企業に入社し、情報システム事業部門勤務。米国への社費留学にて、コンピュータサイエンス修士号取得後、米国・東南アジア・欧州の関連会社に出向駐在を経験。日系企業の基幹システム導入支援等を多数実施。定年後はITプロ人材として活動中。英語・海外関連著書30冊以上あり