2022
5/26
ベンダー提案書におけるプロジェクト計画の評価項目は、主に6点あります。
① スケジュール
② 開発手法
③ 移行計画
④ プロジェクトマネージャー
⑤ プロジェクト体制
⑥ ユーザー教育
そのうちの、「⑥ ユーザー教育」について解説します。
⑥ ユーザー教育の見どころ
プロジェクト後半で必ずベンダーともめるのが「マニュアルは誰が作るんですか問題」です。「業務マニュアル」はユーザーが責任をもって作るべきですが、「システム操作マニュアル」や「システム管理者向けマニュアル」などは、ユーザーが作るのはむずかしい。
そのため、あとで「誰が作るんですか問題」が発生すると、ベンダーは計画外のため「追加費用」を要求してきます。現場に「必要」か「不要」かと問うと、かならず「必要」と言われ、のまざるをえなくなります。
あるいは、自社の発注権力をふりかざし、ベンダーに押し付けるのですが、ベンダーのリソース計画が崩れ、品質が悪くなります。関係性も悪化し、後で自分たちの首をしめるだけです。
そうならないように、事前にRFPで要求し、それが提案書に明記されているかを確認していくのです。
具体的には「成果物」と「研修計画」を確認します。
まずは、提案書の成果物欄に「マニュアル」や「説明資料」といったドキュメントが明記されているか、またその内容について確認していきます。
次にその成果物をベースとして、研修計画の内容をチェックします。
「ユーザー」と「システム管理者」で分けて考えられているか、また研修の回数や1回あたりの時間などが具体的に書かれてあるかを確認します。
このユーザー教育について、具体的に盛り込めるかどうかも、ベンダーの力量が見えてきます。
ベンダーの経験値が高ければ、いままで何度もユーザー教育を支援してきているため、その内容を具体的に書くことができます。条件の線引きもハッキリと書けます。
特にパッケージベンダーなら、パッケージに対する標準マニュアルは既に存在するはずです。そこも含めた「パッケージサービス」であり、パラメーターを変えれば完成するというベンダー内部の仕組みになっているかが問われます。
逆にベンダーの経験値が低ければ、ユーザー教育について具体的に書けません。ノウハウがないからです。
そのため、漠然と「マニュアル」とだけ書かれて、内容は「ご相談させていただきます」で逃げようとします。
そして、プロジェクト後半で相談してみると「そこまでは想定していませんでした」と「追加費用」を要求してきます。そしてベンダーともめます。
経験がもろに出る
このユーザー教育についても、提案書で確認するのは限界があるので、プレゼンテーションで直接、プロジェクトマネージャーに聞いてみます。
そこで過去のプロジェクトでの実績をもとにスラスラと答えられるかどうかで、経験を推し量っていくことになります。
（プロジェクト計画の各項目解説）
【提案評価その4】プロジェクト計画「①スケジュール」をどう読み解くか？
【提案評価その4】プロジェクト計画「②開発手法」をどう読み解くか？
【提案評価その4】プロジェクト計画「③移行計画」をどう読み解くか？
【提案評価その4】プロジェクト計画「④プロジェクトマネージャー」をどう読み解くか？
【提案評価その4】プロジェクト計画「⑤プロジェクト体制」をどう読み解くか？
【提案評価その4】プロジェクト計画「⑥ユーザー教育」をどう読み解くか？
