RFP作成をITベンダー自体に頼むと結果的に高くつく

最近、特にERP等のパッケージソフト導入の初期フェーズであるRFP(Request for Proposal)の作成を請け負うITベンダー(SI会社)が多く見受けられます。SIベンダーやパッケージを選定する作業自体をSI会社に依頼することは本来ありえないことです。

表面的にRFP作成作業自体は安く(ほぼタダに)見えても、そのSIベンダーの紐付きになり、トータルでは高額になる事が容易に想定できます。RFP作成は中立性が大前提なのです。

RFP作成はIT基本構想の策定

RFP作成とは

RFP作成というと、単なる文書作成をベンダーに依頼する作文的なイメージを持たれる場合がありますが、それば自社ビジネスに大きく影響するビジネスモデルや業務プロセスを設計し、ITとして実装するIT基本構想の策定なのです。

そこには、自社の属する市場構造や仕入れ、物流、在庫、販売などのSCM面、財務面、そして社内組織構造などを含む、自社ビジネスを多角的に外部のITベンダーに理解できるように説明する必要があります。

そして、競合に対して競争優位の源泉となる部分を見積り可能な範囲でどの様に説明するかも重要になってきます。特に大手のITベンダーは自社の競合の仕事もしている可能性が高いため、秘匿性も考慮する必要があるのです。

 

RFPには決まりがある

RFPとしてITベンダーに提示すべき内容や選定の進め方など、ある程度決まったやり方があります。それは、各ITベンダーの中立性を担保すると言う意味以外に、自社の意図が正しく相手(提案依頼先)に伝わっていなければ、意図した(それ以上の思いもよらない)提案を受けられる可能性が無くなってしまうからです。

基幹システムの更改は短くても4,5年毎だと思いますので、IT部門の方であってもRFP作成やベンダー選定に慣れている方は殆どいないのではないかと思います。その意味で外部にRFP作成や自社に適切なIT構築の委託先選定のリーディングを依頼されるのは仕方ないことです。

但し、問題はそのRFP作成やITベンダー選定の依頼先なのです。

 

決定の順番がある

ものには順番があります。ITシステムを導入していくにも当然順番があり、ITベンダーは安く、品質の高いシステムを納期通りに作成できればいいので、選定するのは最後なのです。ITベンダーにRFP作成を依頼すると言うことは、その時点でITベンダーを決めているに等しく、順番が逆になってしまいます。

 

その決める順番としては概ね次の様な順番になるのが自然です。

 

◆ ビジネス構想・戦略の策定

昨今はITシステム(ツール)が関わらないビジネス戦略は殆ど無いと言って良いほどITが関連してきます。だからと言ってITシステムありきではおかしな方向に行ってしまします。そこはやはり、先ず、自社としての方向性・戦略を策定し、それに沿って必要なITツールを検討していくべきでしょう。

 

◆ パッケージ選定

そして、自社の戦略にとってサポートするITツールが必要であると認めたら、そこからどの様なITツールを使うのかの調査・検討に入ります。ビジネス環境の変化が激しい昨今では、余程特殊な業務でない限りITツールはパッケージソフトとして販売されています。

 

逆に言うと、どうしてもパッケージソフトが見つからず、1からシステム開発する必要がある業務こそが自社の競争優位の源泉となるコア業務なのかも知れません。その様な業務に対しては注意深くベンダーを選び、(もしかしたら自社内で)委託(スクラッチ)開発します。

外部(特に競合)に漏れてはいけないのです。しかし、それ以外の通常パッケージソフトとして販売されている様な部分で重要となるのは「自社ビジネス(業種・業態)取引形態などにどれだけ向いた機能のつくりになっているか」でパッケージを選んでいけばいいものです。

 

◆ ITベンダー選定

そして、自社にある程度合いそうなパッケージソフトが見つかったら、いよいよそのパッケージソフトの導入を得意とするITベンダー(SI会社)を選定していきます。あくまでITベンダーの選定は最後なのです。

従って、ITベンダーが安く(殆ど無料で)RFP作成を持ちかけてきても、裏があると思って対応するのが無難です。どこかで取り返す算段が無ければその様なことをするはずはなく、「ただほど高いものはない」のだと思います。

 

安くてもITベンダーにRFP作成を依頼してはいけない理由

上記でもご説明してきましたが、「安くてもITベンダーにRFP作成を依頼してはいけない理由」を纏めると、次の様な明確な理由があげられます。

RFP作成はIT構想策定

RFPを作成する段階ではITツール(パッケージ)を意識する必要は殆どありません。むしろ、パッケージでは難しそうだから、と本来進めるべき自社の戦略をパッケージの機能に合わせて曲げてしまったのでは、本末転倒です。

とは言っても、RFPとして外部の会社に提案を依頼する以上は、最低限満たしているべき内容や、体裁、失礼にならない進め方などがあり、通常業務をしていた社員の方では難しかったりもするかとは思います。

その様な場合は外部のIT導入を行わない中立な立場のコンサルティング会社に依頼するのが無難だと思われます。

  • RFP作成を依頼する場合
    • 導入しようとするITツールの開発・導入を行っていない(関連会社も含め)
    • 大手ITベンダーの資本(役員など)が入っていない独立性
    • 自社のビジネス(業界)に精通している(業務要件を纏める作業として)、個別ITに詳しい必要性は必ずしもない

特に最後の点が重要になる業界もあります。それは、医薬品業界や医療機器の製造・販売のような人の命に係わり、米国FDAに代表される規制当局への対応が求められる業界です。このような業界では、業界の自主規制や、社会通念、取引慣行などのような自社の戦略として意図的に壊していけるような類のものではありません。

厳格な基準・規制、査察があり、認可を受けていなければ製造・販売行為すら出来ないのです。

この様な規制業界の場合、規制で何が求められているのかを知った上でRFPを作成することが重要

 

 

 

ITベンダーはIT戦略を策定出来ない

これは個別の能力の話ではありません。ITベンダーである以上、当然自社のビジネスの中でなにがしかの役割を担っています。そして、往々にしてそれは「自社が扱っているITツールやサービスを販売する」役割なのです。

目の前にいるITベンダーの人間が個人として、「あなたの会社には向いていない」と感じたとしても、会社として求められているのが「自社が扱っているITツールを販売すること」である以上、追加開発なども安く見せて自社のITツールを売り込もうとするのは当然です。

それを責める訳にもいきませんし、そもそも、ITベンダーにRFP作成やパッケージ選定を依頼する行為自体が間違っているのです。

 

紐付きになってしまう

ITベンダーにRFP作成やパッケージ選定を依頼すれば、ほぼ、そのベンダーにITツールの開発・導入も依頼することになってしまいます。意図的にそちらの方向に持っていこうとするでしょうし、仮にIT導入以降をニュートラルに選定しようとした場合、作成したRFPはどこまで信用していいものか判らなくなってしまいます。

なぜなら、それは意図的に自社(ITベンダー)に有利になるように作成されたRFPだからです。

 

ベンダーロックインに繋がる

こうして、前段のRFP作成やIT構想策定部分をほぼ無料で請け負うことで後続のIT開発・導入を自社のほうへ誘導し、更に自社でしか保守・運用出来ない状態にまでするやり方で長年事業会社や官公庁から税金を搾取してきたのです。

この様な状況で導入したITツールの保守・運用自体も導入したITベンダーに丸投げし、数年使い続けると自社のIT部門ですら、どうなっているのか解らない状況になってしまいます。正に「ベンダー・ロックイン」の状態で、こうなるとITツールが陳腐化し入れ替えたいと考えても、そこのITベンダー以外には発注できなくなってしまいます。

自社のITシステムがどうなっているか、IT関連部門の社員ですら解らないのですから、そこのITベンダーに依存し続けるしかなくなってしまうのです。

 

 

RFPを出した後が重要

RFPを作成し、候補となるITベンダー各社に説明して提案依頼をするわけですが、ここまででほっとしてその後を考えていない会社が多く見受けられます。その後には、IT各社から来た提案を評価していくという大仕事が待っているのです。

RFP説明会を行た後に、「さて、どの様に評価・決定していこうか?」とお互いに顔を見合わせても既に遅いと言えます。RFPをベンダー各社に説明する前までに「どの様に各社の提案を評価するか」その評価軸・基準を予め社内で作成し・合意しておく必要があります。(決して提案の後ではない)

明確な評価基準が有って始めて自社の上層部に結果を説明出来るのです。そこには基準の妥当性、論理性、あるベンダーに有利となる作為的な点数付けがされたのではないか、と言われない明確な公平性が最初に必要なのです。

 

 

 

 

関連記事

  1. ERPのテストはRPAで自動化する

  2. AI活用はPoCから

  3. RPAやAIによる付加価値を付けたERPへ

  4. AI・クラウド時代で日本型 SI は終わる

  5. RPAが導入を加速する:スピード重視のERP導入

  6. あふれる情報を選別する方法

カテゴリー

人気の記事