PR

筆者は30年以上、ユーザー企業の情報システム部門に席を置き、ソリューションプロバイダのRFPへの対応の数々を目の当たりにしてきた。この連載では、提案を受ける側はどのような観点で提案をチェックし評価しているのか、また提案書そのものの価値については無論のこと、提案プロセスでの重要な点についても具体的に述べていきたい。

 著者は、情報システム部門でシステムの企画・開発、さらに分社化したシステム子会社の設立・育成・統括に携わり、ITの黎明期、事務の効率化・機械化の時代から今日に至るまで、さまざまなコンサルティングファームやITベンダー、SIerと付き合ってきた。その間、小さい案件は数百万円の分析パッケージソフトの導入審査から、大きいものでは開発期間2年に及ぶ百億円超のビッグプロジェクトまで担当した。いまだシステム化要件が見えない段階でのシステムコーディネーションから、取締役会における意思決定までの全プロセスにおいて、“社内コンサルタントSE”の立場で活動を続けてきた。

 こういった背景から、ソリューションプロバイダ各社から受け取るRFP(提案依頼書)に基づく提案書を幾多とチェックしてきた。ユーザー企業サイドから見ても「う~ん」と唸らせる“匠な技”の提案書もあったが、中には「こんなレベルの低い提案書は二度と見たくない!」というもの、さらには劣悪極まりなく、RFPを渡したユーザー企業サイドの担当者の見識さえ問われかねないお粗末なものも数多く見てきた。

 今年は“J-SOX(日本版SOX法)元年”。この関連の提案書が氾濫するだろうから、顧客に迷惑をかけない提案書の作成の一助になればと思い、今後数回に分けて「顧客からみた評価ポイント」について紹介していく。顧客に対してIT統制にかかわる提案や業務プロセスのIT化の提案も結構だが、ソリューションプロバイダの皆さんは、一度提案書作成の“業務プロセス”やその“統制”を見直してはいかがだろうか。

 ちなみに、ユーザー企業からのRFP提供やソリューションプロバイダによる提案書の提出などを一連の“業務プロセス”と見なすと、いくつかのフェーズに分けて考えることができる(図1)。

図1●ステージ別に見た提案の“業務プロセス”
図1●ステージ別に見た提案の“業務プロセス”

 まずステージ0のRFPを受け取る前。商談の“夜明け前”のフェーズだが、ソリューションプロバイダの皆さんは「RFPを受領するまでは何もできない」として、なすべきことを怠ってはいないだろうか。ステージⅠはRFP受領時だが、ここで大きな失敗してはいないか。そして、ステージⅡのRFP受領後から提案書作成・提出までのフェーズに、細心の注意を払っているだろうか。

 ステージⅢの提案書提出後は、プレゼンテーションに向けて、どのような点をチェックしているのか。ステージⅣのプレゼンにおいては、提案書の価値を最大限に高めることができているだろうか。そしてファイナルステージ、プレゼンの“舞台の幕引き”と“アンコール”のためのシナリオが描けているのか。

 この連載ではこうした問題意識を基に、各ステージにおけるユーザー企業サイドからのチェックポイントおよび評価ポイントについて述べていきたいと思う。

身に付けたいRFPに対する“予知能力”

 これまでの経験で痛感するのは、「RFPを受け取る前から勝負あり!」というような状況を自ら作り出していることに気が付かないソリューションプロバイダが、あまりに多いということだ。従って、今回はRFPを受け取る前、つまりフェーズ0における勘所、あるいはチェックポイントを披露したい。

 ユーザー企業としては、RFPを出すレベルのシステム化案件、つまり社内基準でCIO(最高情報責任者)以上の決裁が必要な案件については、その前段階で、社内においてシステム部門とユーザー部門から成る検討チームが編成される。ユーザー部門が単独でソリューションプロバイダにシステムを発注することなどあり得ない。

 もしあるとすれば、それは“当て馬”的な意味を持つ。「ユーザーから直接リクエストがあった」と喜ぶソリューションプロバイダもいるが、喜ぶのは早計である(システム部門が裏で仕組んでいる場合すらある)。実際には、検討チームの活動などを通じてシステム化の課題、あるいはシステム案件として“姿かたち”が見えてくるまでは、「××システムの構築計画」とか「△△システムの導入計画」といった形で顕在化しているわけではない。

 ソリューションプロバイダにとって重要なのは、システム化案件として“姿かたち”を現す前から、すなわち源流(システム構築の上流工程のさらに上流にあるニーズ)に近い段階から、出てくるであろうRFPを“予知”する能力を備えているかどうかである。このRFP予知能力の有無が、案件を受注できるかどうかの分かれ目になることは少なくない。

 もちろん顧客担当営業や客先常駐SEが、そうした予知能力を備えることは困難である。ただ案件が大きければ大きいほど、この予知能力が社内体制として備わっていなければ、RFPを受け取った後の限りある時間の中で、顧客が要求する内容を100%プラスアルファでクリアすることは至難の業となる。ただ勘違いしてもらいたくないのは、単に「同業他社はこんなシステムを先に作っているから、お宅もそろそろいかがですか」などと水を向けてみるといった、低次元の話をしているのではないということだ。

 著者は以前、ITベンダーの敏腕営業からシステム化案件に落ちる前段の業務戦略・目標からニーズの“微動”をつかみ、社内で定期的に検討しているという話を聞いたことがある。そのITベンダーでは、RFPが出されたら数日後に提案書が出せるくらいのレベルまで検討が熟成していることもあるとのことだった。

 システム化課題に結び付く経営戦略、業務戦略を把握すること自体が、実は難しい。会社として「長期・中期経営計画」としてアウトプットされ、その企業の幹部社員なら誰でも目にすることができる段階であれば、容易にキャッチ可能である。しかし産業スパイもどきは論外としても、ユーザー企業の社内事情は千差万別であり、事前に情報を合法的に入手するのは困難かつ一筋縄ではいかないのが現実である。

 その敏腕営業の話によると、日常からコンタクトの取れているシステム部門の人間から情報を得て、本社企画部門のキーパーソン、さらにはそのキーパーソンと良好なコミュニケーションが取れているユーザー部門の人間を紹介してもらうそうである。そこから先は営業としての知恵とセンスでアプローチし、コンタクトを取って“より正確な微動情報”をつかんでいるとのことであった。

 つまり、キーパーソンを紹介してくれるような人物を見付け出すことが、このステージ0での最大の勝負どころとなるわけだ。見付けるべき人物とは、システム部門の中においてユーザー部門にアンテナを張り巡らせているようなレベルの人でなければならない。いわゆる「ロビイストSE」であることが望ましい。

 ロビイストSEとは、ユーザー企業においてシステム案件の“姿かたち”が見えない時から、組織全体のシステム化戦略の企画を念頭に、社内の企画セクションに働きかけたり、各部門の意見を調整したりしたりと、ハードなネゴシエーションができるSEである。“社内営業”ができるコンサルタントSEと言い換えてもよい。はたしてソリューションプロバイダの営業の方々は、こうした客先のロビイストSEのリストを整理し、その実力をレイティング評価できているだろうか。

RFPでは“心地よさ”が勝負を決める

 さて、このようにソリューションプロバイダがRFPを受け取る前から情報収集・分析・検討に時間を割いていれば、提案書の随所にその努力の跡が自ずと“にじみ出る”ものであり、顧客は安心感を持って読むことができる。この安心感を持って読むことができるということが、実は非常に重要なのである。なぜなら提案書に書かれている内容は、社内の源流のニーズを咀嚼そしゃくして、RFPに記述されている内容に対して具体的に回答しているものだからである(図2)。そのため、リクエストしたユーザー企業サイドで“心地よく”読めるのである。

図2●RFPの記述内容は氷山の一角
図2●RFPの記述内容は氷山の一角

 そしてシステム部門が、社内で新規システムについて経営会議への上審、あるいは企画部門へ上申する場面で、ソリューションプロバイダは提案書を通してシステム部門に恩を売ることもできる。つまり、システム部門だけでは社内で意見を反映させにくい状況などにおいて、「システム部門の言いたいこと」を提案書に盛り込むことで、第三者として代弁してあげることも可能になるわけだ。従って、他のソリューションプロバイダが飛び込みでRFPを受領した後に、全社を挙げた体制を作ったとしても、もともと投下したマンパワーと知恵のボリュームにおいて追い付くはずがないのである。

 もちろん商談の大きさや内容、要求の範囲などにより一律の適用はできないが、少なくともユーザー企業にとって戦略的に重要な意味を持つ案件や投資コストの大きな案件の場合、この“にじみ出る心地よさ”の有無で勝負あり、となってしまうことが多いのは事実である。そして案件の大小にかかわらず、ソリューションプロバイダにはそうした隠れたニーズに応えようとするマインドだけでも持ってほしいと思う顧客は、少なくないはずだ。

松澤 純一 テクノロジストコンサルティング 取締役主席テクノロジスト
UFJ信託銀行で事務企画部長、IT企画部長を歴任後、UFJトラストシステム常務取締役。2006年11月にテクノロジストコンサルティング入社、現在は取締役主席テクノロジスト。