前回は、ユーザー企業がソリューションプロバイダの提案書を評価する際に、7つの視点があることを示した。今回はこのうち、「RFPの理解度と提案内容の網羅性」「要件への対応度」「システムの柔軟性と拡張性」について説明する。
まず「RFPの理解度と提案内容の網羅性」であるが、これはソリューションプロバイダがRFP（提案依頼書）の内容を十分に理解し、提起した課題にもれなく回答しているかどうかという視点である。RFPの中で特に重要なのが、最初に書かれているプロジェクトの狙いや目的、解決すべき課題といった項目である。
ユーザー企業が今なぜそのシステムを構築しようとしているのかを一字一句を丁寧に読み込んでしっかりと理解しなければならない。ユーザー企業にとってはソリューションプロバイダがどれだけ自分たちの「思い」を理解してくれているかが重大な評価ポイントとなる。最初の狙い、目的、課題の理解が十分ではない提案書は、内容そのものに対する期待も小さくなってしまうのである。
多くのソリューションプロバイダは、ユーザー企業のWebサイトなどから事業環境や競合状況、事業内容、業績などについての情報を収集し整理していることだろう。しかし、ITRが提案書の内容評価を支援した経験で言うと、ユーザー企業の狙いや目的、課題を十分に認識しているとは思えないものも多い。
ソリューションプロバイダは、ユーザー企業の事業環境にどのような変化が起きつつあるのか、競合他社に何か兆候は見えないか、そのユーザー企業はどのように変化しようとしているのか、などについても調べておくべきだろう。そうした背景を理解した上でRFPに書かれた狙い、目的、課題を読むと、経営課題に対するそのシステムの位置づけや役割、期待がよく見えてくるはずである。
そして、ユーザー企業にさらに突っ込んだ質問を入れたり、自分たちの理解をユーザー企業に確認したりすることによって、提案書の中に記載する現状認識の質の高さをアピールすることができるだろう。提案書では通常、冒頭でソリューションプロバイダとしての課題認識と理解内容について述べるが、こうした事前調査が十分に行われたソリューションプロバイダからの提案書は、競合他社の提案書とは明確に差異化できる。ソリューションプロバイダの提案への期待度が高まるし、提案内容もより具体的な解決案になっていると考えられるからである。
提案内容に濃淡が出ないように
提案内容の網羅性も重要である。多くの場合、RFPには、提案書に盛り込むべき事項が指定されているが、記載順序などはソリューションプロバイダに任せていることが多い（図1）。しかし、指定された事項への記載がなかったり、各事項の内容の深さに極端な差があったりする場合が多い。
 |
| 図1●「提案書に盛り込むべき内容」を指定するRFPの例 |
ユーザー企業がRFPにそれらの事項の記載を求めているということは、ユーザー企業が理解できるような具体的説明を求めているということである。ソリューションプロバイダは提出する際に、営業部門で提案内容に極端な濃淡の差がでないようチェックすべきであろう。特に大規模システムの提案書は多数で分担して作成することになるが、全体のまとまりと記載内容の具体性のレベルをチェックしてほしい。
網羅性の面で最も気になるのが、システム要件への対応内容にかかわる部分である。ITRが見てきた多くの提案書は、全体的なソリューション体系を紹介した後、製品や機能の紹介で終わっているものが多い。これでは、ユーザー企業が挙げた個々の課題がどのように解決されるのかが分からない。質問すると「このページのここに書かれています」と言うのだが、その個所を見ても、課題が解決できるのかどうかが不明であることが多い。
ユーザー企業の多くはRFPに記載した要件をExcelなどに整理し、各ソリューションプロバイダがどのように回答しているかを比較評価する。そのため、すべての提案書の全ページを何度も読み返しながら、その要件については提案書の何ページにどのように記載されているかを要件一覧表に書き込んでいる（図2）。この作業は、提案書ごとに書き方が異なっているため、ユーザー企業にとっては大きな負担だが、非常に重要な作業である。要件一覧表への書き込みを行うと、想像以上に回答漏れや回答不十分なところがあることに気がつく。
 |
| 図2●ユーザー企業が作成する要件一覧表の例 |
ソリューションプロバイダの営業担当部門には、こうした視点での最終チェックもお願いしたい。ソリューションプロバイダの中には、ユーザー企業が示した要件を表に整理した上で、個々に要約した回答を入れたり、提案書の中での記載箇所を示したりすることで、ユーザー企業の見やすさの向上に努めているところもある。当然、ユーザー企業の評価は高まる。
要件に対する質問はSEが行うのが鉄則
「要件への対応度」は、ユーザー企業にとって最も重要な観点である。新規開発システムの場合には各機能がどのように構築されるのか、システムの再構築である場合には現機能が漏れなく移行されるのか、何がどのように変わるのか、新機能がどのように追加されるのか、などをしっかりと確認しておきたいのである。
品質要件や性能要件は、数値で示されるため目標値として設定しやすいが、機能要件はソリューションプロバイダにとって非常に理解しづらいものである。RFPに機能要件が何ページにもわたって記載されていても、それは全体を要約したものであり、ごく一部を表現しただけである。ソリューションプロバイダはまず、RFPに記載されている要件を理解しなければならないが、それを読んだだけで十分に理解できるはずがない。従って、その背景、関連事項をユーザー企業から聞き出す必要がある。
ITRの経験では、ソリューションプロバイダの対応は大きく異なる。営業担当者が窓口となり質問をユーザー企業に投げるところや、担当予定のSEが直接問い合わせを入れるところなど様々である。受注前であるためソリューションプロバイダ側はSEのアサインは難しいであろうが、本気で受注したいのであれば、「受注のためのプロジェクト」として、その業種や業務に詳しいSEを数名アサインして、RFPに記載された要件の分析を徹底的に行うべきであろう。ユーザー企業側の業務のキーパーソンに説明を受ける機会を作ったり、工場や営業店舗を含む現場訪問を依頼したりしてもよい。そうすることによって、ユーザー企業の課題や真の悩みを確認し、具体的な改善提案が可能となり、要件への対応度もおのずと高くなるはずである。
こうしたことを躊躇するソリューションプロバイダもあるが、ユーザー企業にしてみれば、中途半端な理解による中途半端な提案書を出されるよりも、はるかに期待と信頼が高まるはずである。ユーザー企業には、ソリューションプロバイダからの質問回数やその内容を記録して比較するとこともある。質問回数が多く、質の高い質問をしてくるソリューションプロバイダは提案内容の質も高くなり評価も高くなるのは当然だろう。一方、営業担当者が間に入り質問しているようなソリューションプロバイダに対する評価がどのようなものになるかを、想像するのはたやすいだろう。
ところで、コストダウンや新機能の構築、新技術への対応などを理由にシステムを再構築しようとしているユーザー企業への提案で忘れてはならないことがあ る。それは、現有の機能が新システムでどのように変わるのかを明確に示すことである。ゼロベースで機能を構築するとして、現行機能を取りこぼすソリュー ションプロバイダがあるが、これは論外である。資料として現行システムのプロセスや画面、帳票のレイアウトなどがRFPに添付されている場合には、特に注意が必要である。これらの現行システムの機能 を分析しながら、ユーザー企業が認識している現行システムの問題点などを確認しておくと、提案がさらに効果的になるだろう。
システムの柔軟性と拡張性の説明は丁寧に
「システムの柔軟性と拡張性」もユーザー企業にとっては気になるポイントである。提案されたシステムが、今後の事業環境の変化や業務変革の取り組みに対して、どれだけ柔軟に対応できるかということである。将来的に必要となる機能を、ユーザー企業がRFP段階で明確に定義することは困難であるため、具体的に記載されていないことが多い。しかし、ユーザー企業は将来の変化について不安を抱いている。
ソリューションプロバイダとしては、システム稼働後も変化に対応しやすくするためにどのようなアーキテクチャを採用し、どのような開発手法を用いるのかを提案すべきであろう。少なくとも保守については、ユーザー企業は現行システムよりも負担が軽くなることを期待しており、保守生産性ついても述べておくとよい。また、自社や他社のパッケージを活用する場合には、その保守性や拡張性についてもユーザー企業が安心できるような説明が必要だろう。導入実績や将来の製品強化計画、ロードマップなどを添付すると安心感が増す。
|
