セールスとエンジニアのためのIT提案戦術～SIベンダーの営業方法

「セールスとエンジニアのためのIT提案戦術」を借りて読んだ。
受託開発中心のSIで、顧客折衝が多いSEやシステム提案の機会が多いPMにとっては必須の本だろうと思う。
感想をラフなメモ書き。

【1】システム提案プロセスの問題

普通のシステム提案プロセスでは、発注者がRFIを作ってベンダーに提示し、ベンダーは実現するシステムの内容や見積金額をRFPで発注者に提案する。
日本ならば、ユーザ企業がITを使って経営革新や新しいビジネス戦略を行うための道具としてITを使いたいので、ベンダーにシステム構築だけでなく、ITを使ったソリューション、つまりコンサルティングも求める時は多い。
そして、SIが作ったシステムの運用保守もユーザ企業ではなくSI任せになりやすい。
だから、どうしてもユーザ企業がSIへ丸投げしてしまいがちという日本特有の特徴が出るように思われる。

システム提案プロセスの問題としては、ユーザ企業にとってもSIにとっても、お互いにWin-Winの関係を作るにはRFPをどのように作り、選定するためにどのように使うか、ということがあげられるだろう。
ユーザ企業は自分たちのビジネスに合致するシステム構築のために、どんな観点でSIベンダーを選定すべきなのか？
SIは、売上や利益のためだけでなく、顧客と共存共栄していくために、システム提案プロセスでどんな点に注意すべきなのか？

この本では、RFPをSIの営業が使う道具だけでなく、発注者がSIが書いたRFPを見抜く観点も提供している点で面白い。
特に、著者の経験談が含まれているケーススタディのコラムが断然面白い。
いくつか興味深い箇所だけ書き留めておく。

【2】慢心を詫び再構築を依頼する

ユーザ企業が既存ベンダーを見切るかどうかいつも見極めているよ、というお話。
あるユーザ企業のSCMは度重なるシステム追加で複雑化し、いつか抜本的な再構築が必要になると、開発を請け負ったSIは思っていた。
だが、なかなかSIからは過去の経緯もありずっと言い出せなかったが、ユーザ企業の動きに何やら不穏な動きがあるように見えた。
そこで、SIのチーム内で議論した所、意見が2分されたが、再構築する方向で提案することにした。
SIは再構築の提案をユーザ企業に持って行き、なかなか再構築を切り出せなかったお詫びと提案をお話した。
すると、ユーザ企業のマネージャは、実は既に4社ほど当たって、再構築の提案をもらっていた。その提案を貴社から来るのをずっと待っていた、と。

既存ベンダーはユーザ企業の基幹システムを一度作れば、なかなか離れられなくなるという自惚れを抱きがちだが、実はユーザ企業も賢いんだよ、という指摘。
逆に言えば、新規営業のベンダーも既存ベンダーの隙を狙う機会はある。

【3】RFIで受注ベンダーを絞り込む

ある部品メーカーの調達システムにおけるベンダー選定のお話。
そのシステムはかなり特殊な部品を調達管理するために、普通のパッケージ製品には向いていないということが分かった。
そういう事情を書かないでRFIをSIへ送ると、見当違いのRFPが届いて、ユーザ企業も困る。
そこで、RFIに、業務が分かる人向けにこういう特徴を持つEDIが欲しいと書いて、20社ほどのベンダーに送ってみた。
すると、各社のRFPは効果てきめんで差が歴然としていた。
ごく一般のEDIソリューションという的外れなRFPもあれば、見事に的を得たEDIソリューションを提供するRFPもあるし、こちらの業務の特徴や問題を推測してRFIに書かなかった部分まで提案してくるRFPもあった、とのこと。
しかも、RFPのうちの1社は、特注品に特化した調達EDIを扱う開発部隊を持っていたことまで分かったとのこと。

このケーススタディでは、ユーザ企業もRFIをきちんと書かかなければ、ユーザ企業の要望に本当に見合うSIは見つからないということ。
まさに人間のお見合いみたいなもので、いくら安い提案をされても、ユーザ企業の要望に釣り合わなければ、お互いが不幸になる。

【4】意外に多い的外れ提案

個別指導塾のユーザ企業に、教育ソリューションを持つ有力SIベンダーがシステム提案にやってきた。
ところが、その提案内容は、集合教育を想定したソリューションであり、ユーザ企業の要望に全く合致しておらず、座がいっぺんにしらけてしまった。
その原因は、ベンダーが今売り込み中のパッケージ製品を売るために、安易に考えて自分たちのソリューションを押し付けたのが真相らしい。
ユーザ企業にとっても、有力SIベンダーの脱落は選択肢を狭めてしまうということで痛い損失だった、と。

他業界の営業マンでも、顧客は欲しがっていないのに、自分たちの商品の押し売りはよく見受けられる。
当たり前とはいえ、SIの商品は数百万～数億円もする高い買い物だからこそ、的はずれな提案は禁物。

【5】良い提案書とは

以下の9つの条件があるらしい。
・形式要件を満たす
・依頼内容に対して正しく回答している

ここまでは最低ライン。

・RFPの漏れやあいまいさをフォローしている

付加価値の部分。
システムを実現する(フィージビリティ)上でどの部分が課題なのか、そしてその課題に対してどんな対策があり、その対策の効果はどう評価されるか、などを書くことが大事。
いわゆるアーキテクトの観点が重視される。

・具体性があり分かりやすい

差別化の部分。
特に業務系基幹システムは具体的な代物が想像しにくい。
「使いやすい」「処理速度が速い」「サポートが充実」などを具体的に分かりやすく実例や場面をRFPで説明するとよい。
アーキテクトの観点に含まれる。

・良い話だけでなくリスクも考慮している

バランス感覚の部分。
「動かないコンピュータ」という日経の記事が流行したが、夢の部分だけ語った提案書は嘘臭い。
システムを実現できたら、利点もあるが、逆にリスクや弱点もあるという観点もRFPに入れると、バランスが取れたものになる。
いわゆるアーキテクチャ設計のトレードオフの観点。

・よく考え、悩んだ形跡がある

信頼感、技術力の証明の部分。
できるSEは、要件を仕様化する時に、行間を読み解いて、実装方法だけでなく、仕様が矛盾したり不整合の部分を洗い出して突き詰めていく。
ユーザ企業の課題を完全に解決できる正解はないし、全てを解決しようとするのはコストや納期の観点で非現実的ということはよくある。
だからこそ、そういう試行錯誤を経たRFPは、苦心の跡を見つけることができ、プレゼンの場で鋭いツッコミに遭遇しても、ごまかしや言い逃れではない真摯な回答をしてくれるので、ユーザ企業も高く評価する。
まさに、アーキテクトやストラテジストの観点が重視される。

・見積金額の根拠に合理性がある
・熱意が感じられる
・お客様の視点で書かれている

これらも必須ポイント。

【6】実は当て馬ではなかった

複数ベンダーによるコンペは、当て馬になるSIや出来レースのコンペがあったりする。
特に、既存ベンダーが圧倒的に有利な立場にいる時は特にそう。
とはいえ、ユーザ企業の要望と釣り合いが合うSIが受注しなければ、お互いに不幸だったりする。

ベンダーA社はユーザ企業のシステムを20年もサポートしてきたが、最近いくつかの問題を起こした上に、ユーザ企業の信頼関係を損なっていた。
とある案件で、A社以外にも数社のベンダーがコンペに参加したが、どのベンダーも消極的だった。
著者はユーザ企業の立場でRFPの作成支援をしていたが、このままでは期待しているC社が脱落してしまうと懸念を抱いた。
そこで、著者はQ&Aの終了後帰り間際に、C社のリーダーの肩をしっかり掴み、あなたが思っている以上にお客様は貴社に期待していますよ、と囁いた。
すると、C社リーダーはびっくりしたものの、真意を察し、後日再びQ&Aの場で再提案した。
すると、その議論は白熱して、夜遅くまで及ぶ中身の濃い議論になった、と。

出来レースであっても、既存ベンダーとユーザ企業の関係は実は信頼関係が崩れていたりする。
営業ではよくあることだが、自分たちの技術力を示して、種を蒔いておくことは大事。

【7】リアルな見積が安さに勝つ

3社のコンペで、著者がリアルな見積り金額を提示して受注できたケーススタディ。
お客様はこっそり著者へ予算金額を伝えて便宜を図ろうとしたが、著者は何を思ったか、ちゃんと見積りを計算しますから大丈夫です、と断ったらしい。
著者は後で後悔したが、腹を決めて一からスケジュールを作り見積りを計算してみた。
4ヶ月の工程で、要件定義のヒヤリングはいつやって、どんなミーティングを開き、どんな成果物をどれくらい作るか、を具体的に現実的に計画を立てていくうちに見えてきた。

コンペでは、著者を含む3社ともお客様の予算の枠内の数値になったけれど、著者が受注できた。
後で聞くと、他のA社はお客様の予算金額に合わせてざっくり90％で見積り、B社は無理をしても受注したいがために値引きして合わせてきたらしい。
お客様に、著者がお客様の予算の枠外で高かったらどう判断するか聞いた所、著者が作ったRFPとその計画書はとてもリアリティがあり魅力的だったので、予算の枠内に収まる再提案をお願いしたでしょう。他の2社とは格が違っていたから判断しやすかった、と。

この話では、SIがリアリティのある見積りをすればお客様も理解してくれるし、逆にリアルな見積ができなければ、SIは最初から失敗案件を受注してしまうことを意味している。
お客様の要望に見合ったシステムを開発できる技術力を持つSIをお客様も欲しがっているし、システムの実現可能性(フィージビリティ)に見合った見積りでなければ、お客様もSIも不幸という指摘。

システム提案で改めて思うのは、システム提案は、ビジネスや業務に詳しいだけでなく、システムの実現可能性(フィージビリティ)を突き詰めて考えることができるアーキテクトの観点も必要なこと。
たくさんの技術の選択肢から最適なものを選択し、組み立てる能力が必要とされる。
他のケーススタディも興味深いので読んでみると良いだろうと思う。