【第２章】人事情報システム導入の進め方 その４
［ 掲載日 ］2013/05/30
［ 掲載日 ］
コンサルタント bdchp
- 今回は「調達フェーズ」の概略について考えます。
- 具体的には、「パッケージセレクション」という様相ですが、何をするのか、何をポイントとすべきなのか、考えてみましょう。今回は１）と２）について。
- 【調達フェーズ】
- １）提案依頼書の作成
２）選定基準の準備
３）提案書の受領・プレゼン／デモの実施
４）ベンダー選定
５）交渉
６）契約の締結 - 第４話 調達フェーズとは何か（前編）
- 【提案依頼書の作成】
- 前フェーズで作成した企画書を基に提案依頼書を作成します。企画書は企業としての意思決定を行うためのものですが、 「提案依頼書」は、この調達フェーズで行う「ベンダーの選定」のための材料を整理したものです。 従って、企画書よりもう少し実務的な内容になります。
- 「提案依頼書」は「ＲＦＰ：Request For Proposal」とも呼ばれていますが、要はシステムの構築を行うベンダーに対して、 ユーザの要求を提示し、よりよい提案をしてもらうための依頼書です。よく言いませんか。 システムというのは「思った通りにはできない、言った通りにできても。」と。きちっと利用者としての要求、要件を整理し、 提案者にコミュニケートすることが重要です。この提 案依頼書でベンダーは、提案書と見積書を作り、 必要に応じてプレゼンテーションやデモンストレーションを行います。
- ベンダーの立場から見ると、「提案依頼書」の真意を解きほぐし、他のベンダ ーよりもよりよい提案をすることが、 受注獲得に繋がることを知っています。この「提案依頼書」の出来不出来によって提案書の内容が決まってしまうのですが、 文章や図式、表などのコンテンツ以外に、説明会を行うことでカバーされる部分 もあります。 しかし、契約書の基にもなりうる「提案依頼書」を如何に作成するかが、良い人事情報システムを獲得する第一歩でしょう。
- ＩＴコーディネータ協会から参考に出ている「提案依頼書」の目次を下記に示します。
- １．システム概要
- １）システム化の背景
２）システム化の目的
３）解決したい課題
４）狙いとする効果
５）現行システムとの関連
６）会社・組織概要
７）新システムの利用者
８）予算 - ２．提案依頼事項
- １）提案の範囲
２）調達内容・業務の詳細
３）システム構成
４）品質性能条件
５）運用条件
６）納期・スケジュール
７）納品条件
８）定例報告及び共同レビュー
９）開発推進体制
１０）開発管理・開発手法・開発言語
１１）移行方法
１２）教育訓練
１３）保守条件
１４）グリーン調達
１５）費用見積
１６）貴社情報 - ３．提案手続きについて
- １）提案手続き・スケジュール
２）提案依頼書に対する対応窓口
３）提供資料
４）参加資格条件
５）選定方法について - ４．開発に関する条件
- １）開発期間
２）作業場所
３）開発要コンピュータ機器・使用材料の負担
４）貸与物件・資料 - ５．保証要件
- １）システム品質保証基準
２）セキュリティ - ６．契約事項
- １）発注形態
２）検収
３）支払条件
４）保証年数（瑕疵担保責任期間）
５）機密事項
６）著作権等
７）その他 （添付資料） - ここにあるすべての事項について提示できれば文句はありませんが、５、６については、ベンダー選考の後でも構いません。 やはり大事なのは１で、システム の情報はどこにも分からないわけですから、ここに全勢力を注ぎ込まないといけません。 ２については、慣れているベンダーであれば、黙っていても記述してき ます。形だけ整っていても、 伝える内容は１に集中している訳ですから、ここを大事にして下さい。この「導入したいシステム」の概要ができないというのは、 企画そのものに問題があります。経営の意志決定が通ったこと自体を疑ってかからなければなりません。
- 【選定基準の準備】
- 提案を受ける準備は、提案依頼書の完成で完了するわけではありません。 実は 提案を受ける前、どういう基準でベンダーを選定するかの基準を作って置くことが必要です。 これは、選定の軸がぶれるのを防ぐためと、公平に何をもってベン ダーを選ぶか透明性を確保するためです。 もともと好き嫌い」や「これまでのつきあい」のような基準が大事であれば、大仰なセレクションをする必要はありません。
- 「どうしてこのベンダーを選定したのか」と問われた時に、「こうこうこうい う理由で」と明快な解答できるようにしておくのです。 もちろん、「入札」で選 定が行われる場合はよりいっそう厳格な基準が必要ですが、一般私企業でも、 経営者あるいはステークホルダーに説明を求められて、不明朗な解答しか準備できていないのは困ります。
- 選定基準は、おおまかには
- １）ベンダーそのものの評価
- ・信用力や規模について問います。ただし、この部分の比重を大きく取ると、 ベンチャーや中小でも良い提案をしてきたベンダーを排除することになりますので注意が必要です。
- ・実績については、過去に行った人事情報システムのプロジェクトの内容について聞くことです。 ただやっただけではなく、どうであったかのか、課題はどうであったかが聞けるとかなりの参考になります。 勿論、守秘義務があるので限界はありますが。
- ２）選定したパッケージの評価
- ・人事情報システムはパッケージを導入することが主流になっています。 この場合、使うパッケージを選んだ理由を言わないベンダーもありますが、注意が必要です。 「当社はこのパッケージしか使いません」という場合でも、 ではどうしてそのパッケージが今回のプロジェクトに適合しているのかを尋ねなければなりません。
- ・今回のプロジェクトを検討して、どういう部分があうのか、他社ではどうしてだめなのか。 利用するパッケージでも「リスク」は何なのかを明快に説明できるベンダーは信用できます。
- ３）提案プロジェクト内容の評価
- ・乱暴な意見ですが、わたしはどんなパッケージを選ぼうが、プロジェクトは大変だと思っていますので、 このベンダーが提案するプロジェクトの内容が一番重要だと考えています。
- ・問題はプロジェクトマネジャです。次回ご説明するプレゼンテーションは、是非アサインされるプロジェクトマネジャにやってもらうべきです。 俗に草野球は７～８割方、ピッチャーで決まるといいますが、こういうプロジェクトもプロジェクトマネジャで成功の７～８０％は決まってしまうかもしれません。 ベストは、選定したパッケージで人事給与システムのプロジェクトを３～４回経験した人ですが、 少なくとも、システム開発案件の経験がないコンサルタントではリスクが大きいと思います。
- ・プロジェクトの管理手法などは最近、プロジェクトマネジメント手法がよくできているので、 提案内容に大きな差はでない思われます。
- ・ベンダーとして一番気にしているのは、ユーザ側で物事を決めてくれる方がちゃんと専任でアサインしてもらえるかなのです。 従って、ユーザに対するプロジェクトメンバーの要件や条件について、明快に要求しているベンダーが信用できるでしょう。 あやふやな要件しか出さないベンダーは危険です。内容が人事システムだけに、 あまり情報システム部にお願いすることができないと考えているベンダーは多いはずですから。
- ４）ソリューション（依頼した問題解決事項）の提案内容
- ・この部分は、別にエクセルで人事業務別にリスト化して提出することになります。 従って大部分が「パッケージで対応が可能です」的に解答になってきます。問題は、機能がない場合の解決方法の提案です。 最もイージーなのが「作ります」。最近はパッケージ本体に手を入れるカスタマイズではなく、アドオンという、 インターフェースをかませて追加開発する手法が主流です。
- ・最近、日本の人事業務の９割以上をカバーしています、とアピールしているパッケージがありますが、 慎重に検討することが必要です。そういうパッケージでも、アドオン開発をしているプロジェクトがあるということは、 残りの１割についてなのか、 カバーしているけどフィットしていないため追加開発をしているのではないかと疑ってかかるべきです。
- ・このアドオン開発は、作ることで利益が生まれるベンダーにとっては大事な商売のタネです。 どんな企業でも余計なコストはかけたくないもの。例えばＯＡツールで代替できるとか、年に１～２度だから手計算でもよいとかの判断は、 ベンダーとしては提案しにくいものです。多少手ずるになるような条件をＲＦＰに付加しておくのは、賢いやり方です。 やたら貪欲に機能を要 求し、価格は下げろの一点張りでは、 江戸の仇を長崎でのリスクを産むことになるかもしれません。
- ５）見積価格
- ・価格の比較は、当たり前のことですが、全部一直線に並べることです。 下手にベンダー提示価格を並べてしまうと、あとであれが抜けていた等の問題を引き起こしかねませんので注意して下さい。
- ・あるパッケージは提示価格が他社よりかなり安かったのですが、自分で導入の実作業を行わなくてはならないことが分かりましたが、後の祭。 その価格が一人歩きして経営陣に伝わったものですから、あとから人事部と情報システム部がてんてこ舞しているそうです。
- 上記の各要素は平板に点数をつけて評価を行うのではなく、それぞれの要素を 自社の状況に合わせて重み付けをします。 実はここに大きな落とし穴というか、 抜け道があります。重み付けのやり方で、恣意的な選定が可能になってしまう事 です。 ですから、重み付けについても透明性確保のため、説明できるようにしておいて下さい。