第８回「人事情報システム導入のプロセス」７
［ 掲載日 ］2023/10/17
［ 掲載日 ］2023/10/17
（１）システム更新の企画段階
８）ＲＦＩフェーズのパッケージベンダー絞り込み
お互い商売だからといって甘えてはいけないことは前回お話ししました。簡単なカタログの送付依頼であったとしても、情報提供の手間をかけていただいた分、感謝しなければなりません。
ＲＦＩはＲＦＰの小型版と考えることもできますが、ＲＦＰほどベンダーに対して発注のコミットをしているわけではありません。ただし、自分たちが計画していることを明らかにしているので、先方には営業をかける機会を与えていることになります。したがって、「ぜひ話を聞かせていただきたい」という要望が各所から寄せられています。ＲＦＩを出した覚えはありませんが、どこから情報が伝わり、検討もしていないベンダーからも情報が届いています。こういった状況が煩わしいと感じるのであれば、専門のコンサルタントに依頼すべきです。
さて、例えば１０社程度の送付先であれば、５社程度に絞ることが必要ですが、どのように絞るべきでしょうか。一次選考のポイントを考えてみましょう。
① 計画範囲とパッケージのカバレッジ
・ まず、人事給与なら当然、人事管理と給与計算が機能として備わっていなければなりませんが、外資系ソフトの場合は日本の法令に従った給与計算がない場合があります。給与計算をどうするか、他のパッケージとの組み合わせを検討するか、またはアウトソーシングする方法も考えられます。
・ すべて揃った統合型のパッケージを必須とするか、その他のパッケージとの組み合わせを許容するかで、ベンダーを残すべきかどうかを決めます。ただし、細かい話をすれば、給与計算に退職金が含まれていないなど、他のソリューションを検討する必要があることも理解しておくべきです。
・ 要するに、計画している導入プランとのギャップが大きいかどうかを基準にすればよいと思われます。この時点では詳細な要件定義は行っていないため、細部までのフィットギャップは掌握できません。
② トータルの予算
・ 予算の対象となるのは、大きく次の項目です。
＊ パッケージのライセンス（社員数に応じて費用が高くなります）
＊ データベースや利用言語などのミドルウェアのライセンス
＊ ハードウェアの費用
＊ アドオン費用（※1）
＊ 導入費用（外部コンサルタントやSE、内部労力の見積もり）（※2）
＊ 保守費用
＊ オペレーション費用（※3）
＊ 要件定義やＰＭＯ費用などその他の費用（※4）
＊ 上記の中で、（※）については説明が必要です。
※1 アドオン費用
ＲＦＰフェーズでは、パッケージの標準機能では対応できない細かい機能について、
A）仕事のやり方を変えてパッケージに合わせる
B）アドオン開発を行って機能を追加する
C）他のソリューションを組み合わせてシステムをアップグレードする
という３つの方法があります。
ＲＦＩ段階ではこういった情報は提供されないため、正確な見積もりを要求することはできません。したがって、事例を求める必要があります。同様な業種や規模の企業がどの程度のアドオン費用をかけているかを知る必要があります。
これに答えられないベンダーは、退場していただくべきです。ユーザーに見積もり作業のための情報を提供しないからです。ただし、これは参考情報として理解されるべきです。パッケージ導入プロジェクトの重要な要素です。
一般的に、パッケージベンダーは３年以上ビジネスを行っており、導入事例が１０社を超える場合、自社製品の弱点については理解しているはずです。つまり、たとえば「当社は○○機能については弱いです。機能の強化は計画に含まれていますが、具体的なリリースの約束をすることができません」といったメッセージがあることがあります。
××業務レベルで、標準機能で可能か、アドオンが必要かなどの情報を求めることが必要です。もちろん、パッケージに適応する方針を持つことも重要ですが、理想論に走りすぎるとプロジェクトが始まって後悔することになる可能性があるため、注意が必要です。
※2 導入費用
ある種のパッケージは、ソフトウェアのみを提供し、自社で導入することを前提としています。しかし、ほとんどの場合、提携しているＳＩｅｒが導入作業を行う前提で提案されます。この場合、ユーザーのプロジェクトで実施される役割は通常のものとなります。
ただし、要件定義、テストに関連する時間、プロジェクト管理などの間接的な作業にかかる時間を考慮しなければならないことを覚悟しておかなければなりません。
※3 オペレーション費用
ユーザーの中には、保守費用とオペレーション費用を混同している場合が見受けられます。保守費用は、日常的に必要なシステムを操作してアウトプットを得るためのものではありません。システムに問題が発生した場合の修正や、労働法令が改定され、給与や税金の計算方法が変更される必要がある場合の修正プログラムの提供など、システム機能が正常に提供できるために必要な対応費用が保守費用です。当然、パッケージのバージョンアップや供給側に問題がある場合の対応もこれに含まれます。
オペレーション費用は、たとえば人事データの登録や給与計算用のデータを収集し、システムに入力して給与計算を開始するなど、日常的な操作を指します。
ここで問題となるのは、データが変更されるイベントに関する操作です。具体的には、健康保険の料率が変更されたため、その値を変更したり、賃金表が改定されたため、そのテーブルをシステムに一括で取り込んだりする作業です。
保守費用は「システム機能が納入された時の状態から変更が発生した場合の費用」だと考えると理解しやすいでしょう。法令の変更などもこの対象に含まれますが、ユーザー独自の環境の変化、つまり制度の変更などはシステム機能ではなく、ユーザーデータの変更に関連するため、オペレーションの範囲として考えるべきです。
「これまではシステム部門にその作業を委託していた」というユーザーにとっても、今後は考え方を変えなければならないかもしれません。通常と異なる操作になる可能性のある場合、誰がその操作を行うかについても考慮する必要があります。
※4 要件定義やＰＭＯ費用などその他の費用
パッケージの導入方法は、従来のウォーターフォール型とは異なり、プロトタイピングやスパイラル開発などが一般的になっています。つまり、システムのすべての機能をあらかじめ決定してから一気に開発するウォーターフォール型とは異なり、パッケージの導入方法ではシステムの完成度を高めながら、途中で見せながら相談していく方法が主流です。
この場合、問題となるのは、提案段階で要件がすべて確定していないため、提案ベンダーから「プロジェクトが開始してから２～３か月以内に詳細な要件定義を行い、再度見積もりをさせてください」というメッセージが届くことがあります。この提案のベースはウォーターフォール型ということになります。
パッケージは、標準の機能群を使用する限り、基本的な設定を行えばすぐに動作します。したがって、外部設計や内部設計のようなシステム開発のステップは不要です。そのため、要件定義の方法は異なります。
パッケージの要件定義は、まず標準機能がどこまで適合するかを確認し、その後アドオンの開発やＢＰＲを使用して対応するかどうかを決定し、全体の形を想定するというアプローチです。したがって、要件定義を事前に行い、一気に開発する方法は適切ではありません。この点については、ベンダーと十分に相談する必要があります。
ＰＭＯ（プロジェクトマネジメントオフィス）は、プロジェクトを効果的に進行させるための事務的な役割を果たす存在です。大規模なプロジェクトになると、調整のための組織的なアプローチが必要になります。この組織が必要かどうかは、ユーザー自身が判断する必要があります。通常、億を超えるプロジェクトでは、いくらかのレベルのＰＭＯが必要と考えられています。
③ 自社の情報システム環境と戦略性
自社がＥＲＰパッケージなどを使用していない場合、ＳＡＰを選択する理由はないでしょう。逆に、主要なシステムがすべてＳＡＰで統合されている場合、他の外国製ＥＲＰを人事に選択する理由は少ないでしょう。これはＥＲＰパッケージを正しく理解していない証拠であり、情報システム部門の日和見的なアプローチを示唆しています。
ＥＲＰは経営者向けのソリューションであり、人事部門の独自の選択を許容する状況は、経営者がＥＲＰの真の価値を理解していないことを示すものです。情報システム部門の好みで高価なシステムが導入されることはまずありませんが、ＥＲＰがなぜ必要かを理解すると、人事部門自体も自社の状況に応じて選択しようとする姿勢が現れるでしょう。
国産のパッケージについては、基幹システムとの統合環境を制約としない場合、次のシステムのアーキテクチャを検討する必要があります。これに関する話は、人事部門のメンバーでは判断が難しいため、情報システムの計画担当者と相談することが望まれます。
問題点は、人事システムが情報システムであるため、全社の環境で異質なものを避けることができるべきだということです。それは、自社の中でマイノリティ的なシステムになる可能性が高く、将来的に問題を引き起こす可能性があるためです。
思い浮かべてみてください。例えば、すべてが英語で動いている工場で、ただひとつだけロシア語でしか動かない機械があったとしたらどうでしょう。それも全員、アメリカ人の会社で。それは大事な機械だけど、手を出したがる人は少ないでしょう。好き嫌いはともかく、また良い悪いもともかく、とにかくマイノリティ的な環境でシステムを動かしていくのはリスクなのです。
ただ最近は、クラウドという自社以外の環境でサービスだけを享受する仕組みも多くなってきました。これらについては、機能やサービスなど検討すれば良いのでどんなリソース（言語やデータベース）で出来ているのかは二の次です。しかしあまりにエキゾチックな環境で動いているシステムは敬遠した方が良いと思われます。
次に戦略性について考えてみましょう。別に難しい話ではありません。これは会社の事情ということになりますが、制約として存在する問題を認識しておく必要があります。
ひとつは、企業グループにいるという事実です。○○グループのシステムは○○システム会社から買うという方針ありきの場合があります。これは会社としての所与の条件ですから、無理に抵抗する必要はないと思います。ただあまりにゴリ押し的な選択を迫られた場合、覚悟が必要になります。
もうひとつは、人事部門に「戦略性」のセンの字もない場合。この場合は素直に個人情報管理と給与計算がまともにできるパッケージを選択しておけば良いと思います。
実は、なんでもあります的な統合型を選択するのは、戦略性のある人事部門が選択すべきかどうかは議論も余地があるのです。ましてや、地道に人事給与のオペレーションができれば良いと考えている経営者や人事部長には、難しい理屈を並べても高い統合型のシステムを導入させようとするのは得策ではありません。
企画を上げる時に、「なんでもあり」とか「全部乗せ」的な方針で選択の幅を狭めるのは、リスクは少ないが後で困ることになります。統合型パッケージは、人事～給与～勤怠～ＷＥＢ等で構成されています。さらに最近では、タレントマネジメントなどの先進的といわれる領域も含めて提供できるというパッケージさえあります。
勤怠から人事・給与の基本領域は、人事インフラと呼ぶべき部分と考える方法もあります。つまり、人事の業務管理をスタンダードとして考えると、そこで頑張っても企業の競争力にあまり寄与しないという部分です。もっと突っ込んでいえば、この部分をアウトソーシングしても誰も困らないという部分でもあります。業務そのものに差別化する価値がないのなら、それを支えるシステムにも戦略性がないということになります。ですから、この部分を自社はどう評価するのかが決め手になるということです。
では人事部門の経営戦略に寄与する、もっと簡単にいうと業績に寄与する部分はどこなのでしょうか。それを意識してシステム導入企画をすると、自ずから「全部乗せ」統合型システムの導入に問題意識を持つことになるでしょう。全部乗せは、その具を見た時、大体において単品注文のものより劣ることは容易に理解できると思います。揃ってはいるが、７０点主義の機能の集まりで良いのかどうかを判断するのです。
こう考えた時、全社でＥＲＰパッケージ導入を推進しているとき、人事だけがその部分で抵抗することに疑問は感じないでしょうか。部門単独でコストを考えるのならばともかく、機能面等で全社最適に抵抗することは意味がありません。となると、ＥＲＰはインフラとして使い、戦略的な部分は別に考える、という考え方が良いのかもしれません。
スタンダードな部分はＢＰＯ、業績に寄与すべき管理部分をタレントマネジメントシステムなどで管理するという選択肢もあります。ただし、個人情報管理と給与計算をしていれば良いという人事部門から脱する覚悟が必要です。こういったポリシーの変革を伴う企画の上申は、一担当者の提案では難しいとも言えますが、日頃からミドルマネジメントと問題意識のすり合わせをしておくことが必要ですね。