ベンダー提案回答受領迄になすべきPMPの作成

今回のコラムでは、前回のコラムの「3-2．図１　ベンダー選定・評価プロセス」の中の「選定準備フェーズ」と名づけてある部分、つまり、各ベンダーからの提案回答が返ってくる迄の期間に行っておかないといけない重要なことについて解説しましょう。
復習も兼ねて、「3-2．図１」の「選定準備フェーズ」部分にクローズアップして、今一度その図を下記に示します。

4-1．図１　ベンダー選定・評価プロセス中の「選定準備フェーズ」

上記の４-１.図１中のPMPとは、もちろんプロジェクトマネージメント計画書(Project Management Plan）を意味しますが、今、この選定準備フェーズの段階でなぜこのPMP（案）の作成が必要なのでしょうか。
その理由は、次のステップである「ステップ７：PMP（案）ベース評価基準をもとにベンダーを選定」の段階でこのPMP(案)が必要となるからです。以下のその理由を詳しく解説しましょう。

ベンダーやパッケージの選定は、RFPを元にしたベンダーからの提案回答書にて評価・選定すれば良いと通常はそのように考えます。また、このPMPはプロジェクトの開始段階にて選定したベンダーが作ってくれるケースもあります。
しかし、これがプロジェクト推進上の落とし穴なのです。これによりプロジェクトが失敗する原因になることもあります。既に以前のコラムでも書きましたように、このPMPは依頼する企業側自らが作成する必要があります。決してプロジェクトをご支援いただく立場のベンダー側が作成するドキュメントではないのです。では、どうしてこのベンダー選定の段階にPMPを作成し、しかも「PMP(案)」の作成なのでしょうか。
それは、未だこの段階では柔らかい状態、内容でのこのPMP(案)を用いて、次のステップでベンダーやパッケージの選定を行う必要があるからです。

各ベンダーはRFPを元に提案回答書を作成・提示してきます。そして、通常はRFPをもとに、これらのベンダーの提案回答内容に企業側が提示した条件が満たされているか否かを評価します。
確かにこれも必要な基本的な評価ステップです。しかし、選定の段階で敢えてRFPだけで比較せずに、実際にその提案回答をベースに「基幹システムの再構築プロジェクト」がPMP(案)の計画通りに実行できるかどうか、という観点からもベンダーやパッケージの選定を実施する方法があります。逆に、そうしなければ、「プロジェクトマネージメント」としての観点からのチェックは、RFPからでは出来ないのです。では、なぜPMP(案)なのでしょうか。
それは、まだベンダーやパッケージが確定していないこの段階では、貴社が作成したPMPはまだ実現性が見えません。「絵に描いた餅」になる可能性もあります。そして、それが理想像に終わらず、本当に実現出来るプロジェクトであるのかどうかを、ベンダーからの提案をもとに確認＆是正する必要があります。よって、まだPMP(案)なのです。
そして、最終候補ベンダーのプレゼンテーションの内容を踏まえて、候補ベンダーと一緒にそのPMP(案)を、本当に実現性のあるPMPの完成版にして行くのです。
その課程の中で、当然よく見えなかったベンダーを含めての推進体制図も固まりますし、適用する具体的なパッケージベースでの導入スケジュールや工数、費用も固まってきます。したがって、これが出来るまでは、「選定準備フェーズ」段階では未だPMP(案)なのです。

更に付け加えるとすれば、これらの作業を再構築プロジェクトのPMとなるべきメインメンバーが実施することにより、そのプロセスを通してPM自身もプロジェクトに対しての理解がより深まります。つまり、PMとして重要なプロジェクト全体を見通す力、更には、PMとして重要なスキルの一つである「リスクマネージメント」力も醸成されると言うメリットもでてきます。
　
よって、この「選定準備フェーズ」から、PMとなるべきメンバーやプロジェクトのメインとなるメンバーが関わる必要があると、既にコラムの中で述べたわけです。

PMP(案)が出来れば、次はこのPMP(案)をベースとして、「ベンダー評価基準」の策定です。既に何度も書きましたように、「パッケージ評価基準」でなく、「ベンダー評価基準」なのです。

人気の関連コラムを読む

パッケージ自体よりも重要な再構築支援ベンダーの選定

パッケージではなく、パッケージ“ベンダー”で選定する

既にもうお気づきの方もおられると思いますが、RFPで選ぶのは「パッケージではなく」そのパッケージを担いで、基幹システムの再構築を支援して貰える「パッケージベンダー」もしくは「ITベンダー」の選定・評価基準の策定が重要です。
その理由としては、導入しようとしているパッケージの業務・機能を良く知っているのはベンダー側であって、決して依頼する企業側ではないからです。これは結構重要であり、このところをはき違えてプロジェクトを進めて失敗するケースがよくあります。

大事なのは、提案

つまり、あくまでもパッケージは「信頼するベンダーが貴社にとってベストなパッケージとして提案してくるパッケージ」を選ぶべきであり、パッケージありきで選べば、もしそのパッケージでの導入プロジェクトを支援してくれるベンダーが、実はそのパッケージの導入経験があまりない、もしくはパッケージの機能を良く知っていなければ、その再構築プロジェクトは決して上手く行きません。

一見上手く行っているように見えても、そのパッケージに関しての課題やトラブルが発生した際に、このことは露見します。
しかし、その段階で分かっても「時既に遅し」なのです。そのパッケージを一番よく知っているのは企業側ではなく提案ベンダー側なのです。そのベンダーがパッケージ関連の課題やトラブルを解決できないものを企業側のPMだけでは決して解決できません。更に付け加えると、プレゼンでベンダーからパッケージ自体の説明を良く聞いたからと言って、簡単にパッケージの細かい機能まで理解出来る筈はないのです。それを分かったつもりでそのパッケージありきで選べば、プロジェクト失敗の大きな要因となりえます。

POINT

・評価するのは、「パッケージ」ではなく、「パッケージベンダー」あるいは「ITベンダー」。なぜなら、「パッケージ」を真に理解しているのは、企業ではなく、ベンダーであるから。
・「パッケージありき」の考えは微妙。

ベンダー選定の基準のおさらい

本コラムのまとめとして、ベンダーの選定基準をまとめておきます。

提案回答をベースにPMP(案)の計画通りに実行できるかどうか

まずは、PMP（案）を作成し、ベンダーの提供するパッケージが、その課題解決になるかを考えましょう。計画通りに実行するために、パッケージが必要だというロジックになればよいのです。

パッケージありきではなくベンダーで選ぶ

また、パッケージありきでの思考は危険です。「信頼するベンダーが貴社にとってベストなパッケージとして提案してくるパッケージ」を選ぶべきです。パッケージ単体で考えるのではなく、ベンダーを含めて考えるのです。

その他、おすすめの項目

上記が非常に重要な二点ですが、それ以外にも一緒に取り組むパートナーの企業として見ておいた方が良い項目を書きます。

●企業としての信用力、実績

設立が何年か、どういう取引先があるのか、業界での実績はないか、などを見ておきましょう。設立やサービス開始の年数と導入していた実績のある企業を見て、どの程度のシェアなのか導入率なのか確認しましょう。企業としての経験値も見ておくべきです。実際に自社と似たようなモデルで導入したことがあるのか確認しましょう。

●具体性

RFPなどを提示すると、どのベンダーも「YES」と答えがちです。それが営業であるため、当然の結果ではあります。このため、どこまでプラスアルファの提案がくるかを見るのも大事です。 RFPに記載した以上のことや、より詳細な改善事項など、提案力を見ることにしましょう。

●追加費用、修正費用

パッケージを追加で開発する場合の費用についても、この段階で確認しておくのがおすすめです。

●開発体制メンバー

追加開発する場合や修正する場合について、どういったメンバーがアサインされるのかは確認したいところです。

●事業計画に伴う拡張性

事業規模拡大後にシステムを拡張したい時、拡張できる設計でしょうか。その設計が非常に重要です。

●設計変更になる場合があるか

システムがアップデートされる場合もあります。その際に、自社にとって使いにくい改変だった場合にどうするのかは予め質問しておきたいところです。

項目	見るポイント
企業としての信用力	実績とシステムのシェア率（設立年数に応じ）
実績	導入実績がいかほどか
具体性	具体的な提案か、課題解決の一歩先を行くか
追加費用、修正費用	予め見積もりを依頼してみる（無理でも、どういった肌感か見る）
開発体制メンバー	どういった人員がアサインされるのか
事業計画に伴う拡張性	規模拡大時に提案ができるか
設計変更になるか	アップデート時の対応を確認

まとめ

ベンダー選定ならHiPro Bizにお問い合わせください。選定時にチェックするポイントなどは、経験がないとわからないものです。自社にノウハウがなければ、全くわからない部分になってしまいますが、経験眼があれば最適です。ベンダーと共に自社サービスを開発してきた経営プロ人材をHiPro Bizが紹介します。ぜひお問い合わせください。

このコラムのシリーズを読む方はこちら

IＴ分野での2025年問題の本質　～　基幹システムの再構築検討の前に　～

基幹システムの入れ替え・再構築・刷新に向けて、準備からベンダー及びパッケージ選定計画の立案

基幹システムの再構築対象範囲・現状課題の明確化、ERP導入の要件定義の仕方は？

システム選定について｜提案候補ベンダー選定への提案依頼書(RFP)の作成、課題は？

パッケージ自体よりも重要な再構築支援ベンダーの選定

ベンダー及びパッケージ選定プロセスのポイント、RFPとRFIについて

ベンダー提案回答受領迄になすべきPMPの作成

PMP（案）ベース評価基準をもとにベンダーを選定

再構築プロジェクトのキックオフ迄になすべきこと、ベンダーとの契約は？

基幹システム再構築プロジェクト成功への実践、KSFとは？