まさぼっち.net

SI→MBA→起業→事業開発エンジニアのただの日記。

システム提案

システム受注するためには、提案する前から勝負は決まっている

僕はMBA出る前は、SIerでSEとして提案活動を行っていた。
そこらへんのノウハウを残しておきたい。

提案依頼書(RFP)・調達仕様書ができる前から提案活動は始まっている

提案はRFP作成する前から始まっていて、基本的に顧客側にSI側は入りこまないといけない。SIではよくウォータフォールモデル(このご時世でも大手SIはなんでもこのモデルでやっているから機動性がよくなかったりするけれど、)でやっているが、上流工程と言われる前から提案活動を行わなければならない。つまり、提案書作成のための提案をしないといけない。RFP作成の支援を行い、RFPが他のベンダーからくるよりも先に、自社は提案書作成や体制づくりなど先駆けていくことが可能である。この動きをすることによって、競合他社よりも遥かに有利になる。
だから、顧客のシステムの参謀になるくらい、切り込みにいかないといけない。ここで、重要になるのが、スピード感を持っている営業とSE。営業が顧客のニーズを掘り起こし、SEがシステム化可能かどうかとか実際にできるかどうかをみるわけだ。営業とSEの二人三脚がないとだめ。営業が偉いとか、SEが偉いとか顧客には関係ない。スピード感を持って顧客の要望を聞き出し、RFP前の提案書を作成して提案するわけだ。
顧客にもよると思うが、ビジュアル重視の提案書で、現行の状態と、システム化したことで、ここが変わるということを示さなければならない。顧客のメリットはどうなのかという点を客観的に示さないといけない。もちろん、顧客が求めるものとベクトルを一緒にする必要がある。そこは顧客の視点に立ったうえで、資料作りしないといけないんだけれど、そのシステムを使うユーザーの視点も必要。目の前の顧客がシステムを利用するわけでない場合も多い。システムを使うのは顧客の他部門かもしれないし、自部門の同僚・上司かもしれない。または僕らを含む一般消費者かもしれない。その視点に立つことも重要であり、その人にあった目線でシステムを作ることが重要だ。
SI業界に身を置いていると、よくよくあることが、顧客(システム部門)とシステムを使う人ととで、乖離があったりする。現場のことを知らないやつがシステムを作ったことで、現場に適応できない、あるいは非効率的や無駄な作業が発生しまいかねない。だから、システムを使う現場にも踏み込まなきゃいけない。顧客との関係が良好であれば、顧客に言って、現場を見せてもらうようにした方がいい。現場をみることで、新しい課題、システム化することによる恩恵を見つけ出すことができると思う。

それができたら、踏み込んでRFP作成を行う。最近は公平性を持つために、RFPを他社にも公開してコンペ形式で行うことが多い。コンペ形式といえど、裏では、顧客のRFP作成にも支援することで、自社が優位になることができるはずだ。ぜひ、そのフェーズから入り込みたい。企業によって、スタートラインが違うのだ。RFPが公開された時と、RFPを作成している段階で、RFPを把握しているのとどちらがいいかという話だ。

じゃあ、どういうRFPを作ればいいか

今、書いてて思ったけれど、個人的にRFPという書き方が気に食わないけれど、ここまで書いてしまったので、提案依頼書や仕様書でもなくRFPで書くとする。
じゃあ、どういう項目をRFPで書けばいいかという話だけど、基本以下のような項目になる。

・挨拶文~はじめに
・経緯、背景、目的
・解決したい課題・導入効果
・当組織の説明
・業務の特徴
・用語の説明
・提案の範囲、対象業務範囲
・対象ユーザーの範囲・規模
・ユーザー要求、要求機能
・業務数値情報
・システム要求
・パフォーマンス(処理能力)要求
・セキュリティ
・コンプライアンス
・移行
・運用
・ドキュメント
・資格
・教育、訓練
・保守、サービス
・納品成果物
・プロジェクト体制
・開発条件(作業場所、開発用機器、設置)
・スケジュールと納期
・貸与物件および資料
・機密保持
・知的財産権などの権利
・契約条件(発注・契約形態・支払い条件)
・納品・研修の方法・場所
----
・提案項目
・提案手続き、スケジュール
・提案書の書式
・Q&A
・提案説明会(プレゼンテーションの日程・場所等)
・ヒアリング
・選考基準・方法
・提案の採否連絡
・対応窓口・連絡先

こんな感じ。顧客によって、書き方も異なるけれど、最低限、この情報を網羅する必要がある。
顧客からしたら、作成するのに、めちゃくちゃ工数がかかるものだ。顧客がそこまでシステムが詳しくないケースも多いので、有識者がそこを支援してほしい要望をあるはずだ。そこに切り込む必要がある。

で、ここで大事なのが、パフォーマンス(処理能力)要求だと思う。
ここはしっかりと書こう。システム化する際は、機能要求が重視されるが(もちろん、重要)、それだけでなく、裏方の処理についても十分記載しないといけない。ここで、記載しないと、納品後に、処理が全然出なくて、現場が大混乱。使えないシステムが出来上がったよと言われる。システム開発側は記載していないから、といえば、それで逃げてしまうこともあるので、顧客側もRFP作成時は要注意である。なので、パフォーマンスはしっかりと書き込まないといけない。SI企業の言いなりになっちゃいけないというのも顧客側はちゃんと認識する必要がある。そういうのもしっかりとSI企業は書くことが社会的にも重要だと思う。
あとは、セキュリティも重要だ。昨今はますますセキュリティといわれることが多いので、システムがウェブ系であれば、なおさら、しっかりとしたセキュリティ項目を記載しないといけない。
あと、受注者の資格要件も重要。資格要件で、変なシステム会社が入ってこないようにするのも顧客にとってもSI企業にとっても重要なことである。システム会社によっては、システム化が失敗してしまうことがある。そのときに保証できるかどうかも鍵になる。簡単に言えば、知らない会社がとったときにちゃんと責任とってくれるんだよねってことが大事になる。それ以上にその企業を資格要件から除外させてしまうのも手。例えば、規模感の記載、あるいはちゃんとした会社しか取れない資格を記載する。そういうこと書くと公平性に欠けるとかあるかもしれないけれど、受注後、できませんでしたと言われるよりマシだと思う。あからさますぎるのは問題だけどね。

ざっくりとした書き方になったが、結局何が言いたいかというと、RFP作成支援をすることが、顧客との関係性を強化し、受注の鍵にもなる。

-システム提案