コラム

前回のコラムでは「RFP（提案依頼書）を見て1次評価する」と題して、RFP提出後、システムベンダーから提案書を受領し、1次評価（書類審査）するところまでのプロセスを説明しました。
評価シートの作成は自分たちが本当に求めている重要な要件を正しく評価するため、提案書を受領する前に作成することが重要で、システムベンダーから提出される提案書の見た目等の表面的な部分で評価するのではなく、RFPに対し的確に提案をしているかを評価すべきということをご理解いただけたかと思います。

今回のコラムでは、前回のコラムの続きとして1次評価（書類審査）を通過したシステムベンダーにデモンストレーションの依頼をするところから説明していきます。

2次評価（プレゼンテーション・デモンストレーション審査）ステップ

（1）システムベンダーによるデモンストレーション手配、日程調整。
提案書に記載されている提案の内容を実際どのように実現するのかを、実機画面や提案書を使って説明してもらう機会を設けます。システムベンダーとの調整はもちろんですが、社内関係者の調整も必要になり、複数機能や業務をまたがるデモンストレーションを実施する場合は、その調整にかなりの時間と労力を費やします。
また、デモンストレーションする際にシステムベンダーには以下の依頼をします。

①　システムベンダーの会社PRにデモの大半の時間を使わないようにする
システムベンダーは受注を勝ち取るため、デモの大半の時間を導入実績、提案システムの特徴、会社規模、自社の強みなどのPRに費やし、本来の提案依頼している要件やオペレーションに関しての説明が少なくなるケースがあります。これは提案依頼側の期待を無視したシステムベンダーの自己満足なデモンストレーションで、都合をつけて出席してもらった方々は、評価もできず、時間の無駄になってしまいます。そうならないよう事前にシステムベンダー側にデモの進め方などを説明しておく必要があります。

②　想定オペレーション（業務の流れ）に合わせたデモンストレーションを行う
参加者にとって意義のある時間にするために、自分たちが想定しているオペレーション（業務の流れ）に沿ってデモンストレーションをしてもらいます。具体的には、新業務フロー図（あるべき姿）（ 第三回：スムーズな要件定義方法>■要件定義の進め方>（5）新業務フロー図（あるべき姿）の作成を参照のこと）に沿う形になります。自分たちで作成した「あるべき姿」の業務の流れをイメージしながらデモを見ることにより、このシステムは自分たちが描いているあるべき業務にフィットしているかを判断でき、より具体的な質問ができるため、参加者の評価もしっかりとします。

また、デモンストレーションは、時間が足りなかったり、質問が多数出たり、詳細内容を更に確認したい場合は別途機会を作り、数回行うケースもあります。

（2）システムベンダーからの提案書とデモンストレーションについて2次評価
提案書とデモンストレーションを受けて、最終的に1社のシステムベンダーを選定します。 評価する項目は大きく以下のものがあります。

No.1：提案依頼側の状況及びRFPの理解
提案依頼側の状況及びRFPの内容は、提案をもらう際の基本です。この内容をシステムベンダーが理解していないと、提案の基本的な趣旨がずれ、提案依頼側の要件と提案側の回答が噛み合わない提案になってしまいます。 システムベンダーが提案依頼側の状況及びRFPの内容を理解できているかどうかはRFPへの質問や提案書、デモンストレーションでの説明内容から判断することができます。

No.2：システム
・機能要件（ソフトウェアに対する期待）の適合度
ここが提案の肝になります。ソフトウェアの標準機能と提案依頼した機能要件とがマッチしている件数が多いと評価が高くなります。更に、各要件に対して重み付けをすることで、定量的な点数比較をすることができます。
　　　　　重要度（サンプル）
　　　　　1.非常に高い
　　　　　2.必須ではないが重要度は高い
　　　　　3.あれば尚良い
　　　　　4.どちらでも良い

※上記サンプルの場合は、4＜3＜2＜1の順番で評価点を高くします。

これらの評価項目は、提案書から内容は把握できますが、単純に標準機能で「できる」「できない」という記載のみで具体的な解決方法の記載が無い場合があります。「できない」と記載があった場合、デモンストレーション時に何か解決策はないのかなどを確認する必要があります。 また、解決方法に「カスタマイズで対応する」と回答があった場合は、その分のコストが費用に加算されているかを確認する必要があります。

・非機能要件（ハードウェア、インフラ等に対する期待）の適合度
一昔前の基幹業務システムの提案といえば、クライアント/サーバーシステム型の提案が主流で、自社の資産として購入する形態が多かったのですが、最近では、インターネットの普及によりクラウドサービス型の提案も増え、形態もパブリッククラウド、プライベートクラウドやSaaS、PaaS、IaaS等の種類があり 料金も色々な支払形態があります。 もちろん、自社の要件や予算に合う提案であれば評価しますが、ハードウェアやインフラに関しては、技術革新に伴い日々進化しているので、当初提案時に予定していた形態にこだわらず、複数案もらうことをお勧めします。これらの評価項目は、提案書から内容の確認ができますが、提案されたインフラの形態が曖昧な場合にはデモンストレーションの場などで確認する必要があります。

・システム操作性
システムの動作状況や操作性は、提案書からは読み取れないので、デモンストレーション時に、実際の画面でその動きを見て、オペレーションのイメージから評価します。また、メニューやユーザーインタフェース（画面）がごちゃごちゃしていて使いづらいと現場の生産性が落ちることになりかねず、逆に入力項目をシンプルにしたために機能要件を満たされないということになったら元も子もありません。そのバランスを保っているかも評価します。

・拡張性
要件の中には、現実的に必要な必須要件の他に、今後あれば良いといった要望的な要件も存在します。仮に各システムベンダーの提案で、必須要件に対して同じレベルの評価だった場合、この要望的な要件を比較し、拡張性の面からも優劣を判断します。 これらの評価項目は、提案書から内容の確認ができますが、提案された解決策が曖昧な場合にはデモンストレーションの場などで確認する必要があります。

No.3：費用
・イニシャル（初期）費用
当初1年間の費用を比較します。各システムベンダーの比較することで、どの程度の要件を満たしていて、いくらかかるという、金額の妥当性を評価することができます。これらの評価項目は、提案書から金額の確認ができますが、提案された解決策に記載されている内容（カスタマイズなどの費用）が曖昧な場合にはデモンストレーションの場などで確認する必要があります。

・ランニング（維持）費用
システムを維持するためのメンテナンス費用、クラウドサービスであればサービス料の年額費用、を比較します。一般的にイニシャル費用とランニング費用5年分を足し、中長期的な視点で比較します。

これらの評価項目は、提案書から金額の確認ができますが、提案されたカスタマイズ機能の保守や保守料の過去の値上げ状況などは、デモンストレーションの場などで確認する必要があります。

No.4：スケジュール
導入プロジェクトのスケジュールをしっかり確認する必要があります。RFPの中にカットオーバー予定時期を記載すると、それに合わせてシステムベンダーもスケジュール作ってくるところもありますが、本当に実現可能かどうか、どういうステップを経てカットオーバーまで行きつくのか確認する必要があります。業種別テンプレートを用いることによる早期カットオーバーができるという提案や開発が必要なためカットオーバー時期を後ろに変更する必要があるという提案など、システムベンダーにより提案内容が変わります。また、要件定義や詳細設計、ユーザーテストなどの手法も異なるため、それぞれの期間が妥当なのかを提案書やデモンストレーションの場などで確認する必要があります。

No.5：体制及び実行能力
・導入体制
導入プロジェクトを遂行する体制を確認します。システムベンダー1社でプロジェクトを遂行できる場合はそれほど気にする必要はありませんが、最近は業務内容が複雑化しており、複数のシステムベンダーでプロジェクト体制を構成するケースが増えています。どこが主体（プロジェクトマネジメント）で、ここのパートは誰がやり、どういう指揮系統で、誰が責任を取るのかといったことが明確になっていることを確認する必要があります。 これらの評価項目は、提案書から内容を確認できますが、提案された体制案が曖昧な場合にはデモンストレーションの場などで確認する必要があります。

・実行能力（プロジェクトマネジャーのスキル）
導入プロジェクトを遂行する上で、システムベンダーのプロジェクトマネジャーのスキルも重要になります。実際の体制案でアサインされている（される予定）の方々の経験や知識に関しては、ある程度、提案書から読み取ることができますが、コミュニケーション能力やリーダーシップ能力は、実際会ってみないとわかりません。デモンストレーション時に説明者として同席していることもあるので、その方の動向、コミュニケーション能力などを評価する必要があります。もし同席していない場合は、別途面談等を行うことをお勧めします。

システムベンダーの最終評価と確定

前述の評価項目を元に評価シートを作成し、複数のシステムベンダー候補から1社に最終確定します。

評価シートから簡単に順位が付けられれば苦もなく1社に決めることができますが、各評価者の重要選定基準とする評価項目が微妙に異なるような場合（例えば経理部の評価者は会計関連の重要点を重視し、生産管理部門の評価者は、生産関連の重要点を重視してシステムベンダーが1社に決まらないなど）、その評価項目を洗い出し、社内打ち合わせを通じて、声が大きい評価者の項目の評価を高くするのではなく、会社全体にとって有益で最も効果的な項目の評価を高くすることが求められます。

また、システムベンダー選定の最終段階で、機能の評価が高く価格も高いシステムベンダーと、機能の評価はそこそこで価格は安いシステムベンダーを比較して、機能評価を重視したい場合、価格交渉により機能重視の１社に絞り込める場合もあります。見積金額も、システムベンダーからの提案をそのまま受け入れず、特に導入コンサルティングなどで「一式」と表示されているところは明細を詳細に出してもらうよう要求し、妥当な金額かどうかを確認します。 その他、契約に関しては、一般的に問題になりがちな損害賠償の責任、瑕疵担保期間、著作権の帰属等の確認をします。いずれにしても自社に取って有利な条件を引き出せるよう努力をしましょう。

条件も整い、無事1社に絞れたところで、最終的な社内の承認申請・確定作業を行います。 承認プロセスがそれほど複雑でない会社は特に悩む必要は無いのですが、企業規模が大きければ大きいほど、承認プロセスが複雑で、システムベンダーを絞り込むことはできたが、結局、社内最終承認がおりず、システム導入がペンディングなったというケースもあります。

「第三回：スムーズな要件定義方法>■要件確定終了条件」でも記載しましたが、利害関係者との合意形成をするために4つの壁（組織の壁・経験の壁・予算の壁・決断の壁）があります。海外拠点への導入の場合は、更に言語や文化の壁もあり、調整が困難になります。

しかし、どんなに壁が多く、また大きくなっても最終的に決定するのは人です。 承認プロセスを一過性の単純な作業とせず、「利害関係者をまとめる人」の「熱意」と「経営者」の「決断」がうまくかみ合うよう適宜コミュニケーションを取り続けることが、最終合意できる過程で大変重要になってきます。

最後に

今回のコラムは海外拠点への基幹業務システム導入を意識して、情報システム化計画の立案から要件定義、RFPを作成し、システムベンダーを決定するところまでを書きました。
本来であれば、その後のプロジェクト管理方法やシステム導入テスト方法等がありますが、こちらは別の機会にご案内したいと思います。

筆者は、長年、グローバル企業を中心に基幹業務システムの提案や導入に携わってきました。そこで感じたことは、世間体に良いといわれている情報システムであっても、それを使う人が満足出来なければ、良いシステムとはいえないということです。 使う人が満足出来るシステムは、やはり使う人しかわかりません。使う人が多ければ多いほどその要件や要望が増えていきます。

コストをたくさん掛ければ、それを満たせるシステムを構築することができるかもしれませんが、あまり現実的ではありません。現実的には数ある要件に重要度を付け、重要度の高い要件を中心にフィットするシステムを見つけ出すことが、使う人が満足できるシステムに最も近いと考えます。

最近はAIや人工知能など、人間の能力を超えそうな未知なるシステムも話題になっていますが、それはそれとして、今考えられる「あるべき姿」を目指したシステム構築が必要ではないでしょうか。