どうも、木谷です
前回のベンダー評価シートのテンプレートがありますので、今回はいよいよ選定の場面です
スコア決めのときも、ベンダー選定のときも、揉めることも多いので、ぜひ事前にチェックしておいてくださいね!
ちなみに、ベンダーのプレゼン後3日以内に選定を終了することが目安なので迅速にここらへんはやっていきましょう
客観的にベンダーにスコアを振り分ける
ベンダーに点数をつけていくときに、注意すべきが客観性です
では具体的に見ていきましょう
同じもので比べる
例えば、創業30年とIT開発実績10年ではどちらのITベンダーが良いのでしょうか?
この判断基準は微妙に違うので、一概には言えません
創業30年といっても、最近IT事業をはじめただけなのかもしれないからです
このように、同じ基準で測ることを「アップルtoアップル」と言ったりします
では、自社システムを一括購入する場合と、クラウドサービスを利用するのでは初期費用と保守費用の考え方が根本的に異なります
当然、一括購入の場合初期費用が大きくなり保守費用は抑えられますし、クラウドサービスでは初期費用はほとんどかからないですが保守費用が使用期間にかかります
アップルtoアップルにしにくい場合、どちらがいいかがはっきり見えてきません
基準を強制的に揃える必要がありますが、ここで自社が何を大事とするかを反映します
また、意味合いは違うが、効果を見る上で同列にしたほうが良い項目というのもあります(例えば、システム基本費用とパッケージ費用は同列として扱えますよね)
それを次のグルーピングで揃えていきます
強制的に基準を同じにする
比べにくい項目がある場合の対処法として2つ挙げられます
- 自社基準の項目に合わせる
- グルーピング
の2つについて具体的に見ていきたいと思います!
自社基準の項目に合わせる
先ほどの例であった、初期費用と継続費用の比較の場合は、自社で優先する評価基準を優先して項目を作る必要があります
費用の面で、一番考えられるのが「使用年数」を定めることです
いまから導入するパッケージは何年使う予定か? が決まれば、その期間にどれだけの費用がかかるかを計算すればよいだけです
よくわからないという方は、「5年」を基準にされると良いでしょう
グルーピング
名称が違うものでも、同じ評価基準として扱えます
例えば、パッケージ導入費用の場合だと以下のようになります
初期費用 | ・導入サポート、コンサルティング費用、ソリューション費用
・移行支援費用、運用支援費用 ・サーバー運用、ソフトウェア費用、アプリケーション費用、システム一式費用 ・システム基本費用、パッケージ費用、カスタマイズ費用、システム開発費用、システムテスト費用、システム改修費用 |
---|---|
項目名 | ・ライセンス費用、年間使用料
・年間保守費用、カスタマイズ保守費用、保守差額費用 |
項目が多くなってしまうの見にくいので、このようにまとめてしまったほうがメリットが大きいです
選定会議をスムーズに
最後に決定するのは、人です
スコアを振って客観性を高るとは言え、当然意見が食い違うこともあります
最初に申し上げたように、ベンダー選定はそれほど時間をかけるフェーズではなく、最大3日で終わらせる必要があるので、揉めている場合ではありません
しかし、どちらの2社にするか定まらないまま進行して、延期となるケースもしばしば…
プロジェクト延期を防ぐために、選定会議をこなすための前準備をしていきましょう
ほらみろ! と言われないために
もちろん、スムーズにベンダー選定がいくこともあります
しかし、そうではなく意見が完全に分かれてしまう前に対策が必要です
例えば、無理やり多数決で決めてしまった場合、少数派の人たちはどう思うでしょうか?
少数派の人たちはなんとなく意見を聞いてもらえなかった気がして、プロジェクトと距離を置き始めるようになります
不満を抱えたまま、変な空気が流れながらプロジェクトが進んでしまうのです
さらにプロジェクトが良くない方向に傾き始めたら「やっぱり失敗する!」となり、協力して欲しい場面での人員が不足し状況がいっそう悪化します
では、どのように議論を進めていけばよいのでしょうか?
このような状況では、ファシリテーション(会議進行)が大事になってきます
平等に参加者の意見を吸い上げ、納得感の高い結論に誘導します
そのために進行役が以下4つのように進めていく必要があります
- アジェンダを準備する
- プロジェクトメンバーの全員参加
- 各評価項目の読み合わせ
- 影響力の強い人を後回し
具体的に見ていきましょう
① アジェンダを準備する
会議の課題、進行予定は先に決めておきましょう
というのも、ベンダー選定会議では特定機能で話が盛り上がるなど話が発散しがちです
進行をコントロールするためにアジェンダは欠かせません
構成としては
- 会議の目的
- 評価項目の読み合わせ
- 総合評価コメント発表
- 選定
が必須要件です
② プロジェクトメンバーの全員参加
これは基本かもしれませんね
もちろんプロジェクトオーナーも参加してもらいます(どうしても多忙でオーナーが来られない場合は後に承認を取ります)
これは、やはり先駆けで関わってもらい、意見を発信してもらうことで「参加している感」を持ってもらうことが大事だからです
メンバーが重要事項の決定に参加することで参加度を上げます
③ 各評価項目の読み合わせ
会議進行ではベンダー評価シートの主要な部分を読み合わせします
意見が割れそうな項目は、参加メンバーにコメントを求め、評価を1つずつ確定させていきます(ベンダー評価シートについてはこちら)
④ 影響力の強い人を後回し
最後にひとりずつコメントを求めて、思いをすべて吐き出してもらいます
このとき、影響力の強い人は後回しにします
部長が「A社がいい」と言った後に、若手の担当者が「いやB社」だとは言えないでしょう
プロジェクトオーナーは当然最後に意見を言ってもらいます
意見が割れた時こそオーナーの出番です
選定の記録は残す
補足ですが、新しくメンバーに加わる人のために「なぜそのベンダーを選んだのか?」を記録しましょう
- ベンダー評価シート
- 選定会議の議事録
この2つさえ残しておけば基本的に大丈夫です
ベンダー評価シートは最終評価を反映後に保管しておきます
プロジェクトが問題になったときには「誰がこのベンダーを選んだんだ」と言われるので、責任を分担する役割もあります
選定に時間をかけないことがマナー
評価項目は自社の基準を優先し、評価は客観的に下す
選定会議を円滑に進めることは今後のプロジェクトにおいても重要