タレント管理システムにおける失敗パターン7例
タレント管理システムを導入、改修、運用した経験、および見聞きしたこと、他人から学んだ内容などをもとに、考えられうる起こりうる失敗パターンについてザっと記載する。ここで言うタレント管理システムとは、人材データを蓄積するシステムと捉えても、大きく異なることはないだろう。近しい立場にある人に参考になれば幸いだ。
権限肥大化に伴う改修コストの増大
システムに登録している権限（HR権限とか営業部長権限、一般社員権限など）が増えることによって、システム改修コストが爆発的に増大するのが、最初の失敗事例として挙げられる。人事以外も広く使う人事系システムの場合、このケースが発生しやすい。
人事システムは、センシティブな情報が多く、権限制御が重要なファクターとなる。「どの権限の社員が」「どの権限の社員の」「何の情報を閲覧できるか」を細やかに制御できるシステムが多い。しかしながら、権限の種類を増やしすぎると、「どの権限の社員が」「どの権限の社員の」の組み合わせ数が2次関数的に増え、システム改修時の要件設計（新項目はどの権限の組み合わせの場合に閲覧/編集権限を与えるか？）と、そのテスト工数が激増する。
「何の情報を閲覧できるか」については細やかにしても問題ないが、いや、むしろ推奨されるべきことだが、権限の種類に関しては、必要最小限に抑えることが重要である。
他部署やグループ会社への展開時の制度・文化差分
タレント管理システムを運用していると、人材の管理範囲は徐々に広がっていく。例えばまずは、部署A/B/Cに導入し、その後全社展開、その後グループ会社に展開、といった具合だ。タレント管理システムを人材可視化のために導入したのであれば、社員全員を可視化したくなるのが当然であろう。
リーンスタートで組織の一部に導入し、その後徐々に広げていくケースは多い。この場合、他部署あるいはグループ会社に展開する際に、管理スキルの違い、評価項目の違い、データ入力に対する寛容度合いの違いなどから、導入がスムーズに許容されないケースが多い。許容されたとしても、その後のオペレーションでひずみが発生する。
全社統一的な導入を行う場合、最初から大々的に行うか、もしくはトップの責任者が導入を強く肯定するような表明を行うことが必要となる。タレント管理システムを受け入れる利用者は、別に受け入れるインセンティブがない。管理したいのは、タレント情報を可視化したい見る側の管理者だ。今までシステムがなくても業務を進めることができていたにもかかわらず、ミスマッチなシステムの運用を要請されると、ハレーションが生まれるのも無理はないだろう。
登録されていない部署・社員がいることによる弊害
組織の一部のみにタレント管理システムを導入した場合、さらに弊害が発生する。仮に、営業部社員はタレント管理システムに登録されており、経理部の社員は登録されていないとする。この2部署間で異動が発生した場合、どのように管理するかが課題となる。丁寧に情報登録オペレーション定義しないと、退職したのか、入社したのか、異動したのか分かりにくくなる。
さらに、このあまり発生しない異動事例に対して、細かな例外プロセスを定義し、ドキュメントを作成し、発生時の検知を忘れないアラートも設計する必要がある。費用対効果が合わない。
全社に展開する予定があるのであれば、最初から全社に導入し、その機能設計の議論にも最初から参加すべきである。全社でスキル管理したいのであれば、一部の部署を先に導入し、運用に載せるメリットが少ない。検証を目的とするのであれば、検証対象を明確にし、導入規模を増やすタイミングでハレーションが発生しないように検証プロセスを設計する必要がある。
部署での必要スキルが異なることによる、スキル可視化の難航
タレント管理の最大の課題が、部署によって必要なスキル、管理すべきスキルが異なることだ。スキルを可視化することによって、部署間の人材流通を活性化させるのが理想だが、当然部署によって必要なスキルは異なる。必要のないスキルまで管理するインセンティブもない。
世の中のあらゆることが多様化するとともに、スキルも多様化している。時代によっても変わるだろう。「このスキル保持者が」「どこに」「何人」というスキルを軸とした管理を推進するのは難易度が高い。必要なスキルは、各部署が自由に項目を設置し、タグ機能や全文検索機能を充実させる。検索性を向上させることによって、ジョブディスクリプションと人材スキルのマッチング性能を高めるような可能性を見出していくほうが、変化の激しい時代にあっているのではないだろうか。
システム改修に対する意思決定プロセスがないことによる問題
システムの導入範囲が広く、利用者が多い場合、システムに対する改修オーダーも増える。改修する作業それ自体は問題ないのだが、改修を実行することに対する合意を、多くの関係者から取得する必要に迫られる。
システムの導入範囲を徐々に拡大して上記に至った場合、どの範囲でコンセンサスを取るのがよいか、さらに分からなくなる。システムの導入先が増えると、意思決定プロセスが変わる。新規の利用者ドメインにも、相応の責任者がおり、自身がマネージする部署に適したシステム状態を維持する必要があるからだ。
新たな部署、グループ会社などへシステム展開を行う場合は、システム導入と合わせて、意思決定プロセスもアップデートさせる必要がある。
既存機能との機能重複によるデータ管理不全
システムの利用者が増え、改修のオーダーが増えると、そのオーダーの中に既存機能と一部重複するような機能追加のオーダーが発生する場合がある。利用者が多様化すれば、誰しもにとって最適な状態を維持するのは同然無理がある。利用者が、自分たちに最適なシステムへとアップデートさせようと考えるのは当然のことだろう。
システム管理者は、システム全体の設計思想に逸脱する、あるいは重複するような改修オーダーがあった場合、毅然とした態度でその改修オーダーを棄却することが重要である。もし、これを怠った場合、むやみに管理項目が増え、同様の情報が同じ場所に蓄積されないという事態を引き起こす。どこに情報を蓄積すべきか、極めてシンプルに分かるシステムを設計することが求められる。
制度に先立ちシステム実装することによる迷走
システム化の本質は、自動化・効率化である。何かやりたいことがあって、システム化によって、それを効率化するというのが本筋である。にもかかわらず、とりあえず先にシステム化させようという改修依頼は多々発生する。システムという形あるものが、実績として見えやすいことが一因としてあるだろう。
年間スパンでの運用を見据え、何のためにシステム化するのかを明確にし、長期スパンでシステム化の費用対効果を検討する必要がある。怠れば、システム化したものの、その機能が形骸化し、運用コストのみが残存することとなる。システム実装よりも、システムの破棄の方が何倍も難しい。破棄されるまでの間、運用コストを誰かが担うことになる。
最後に
以上、思うところをザっと記述した。継続的に改善、アップデートしていく人事システムの運用は、難易度が高い。何のためにシステムを利用するか、これを明確に意識し続ける力が大切だ。
以下のUdemyコース（私が制作したもの）は、人事データ分析やピープルアナリティクスを導入したい人事担当者に向けて、目指すべきゴールイメージと現状の差分から、導入のためのファーストアクションが述べられています。ロードマップ案も提示し、中長期で、何を視野に入れるべきかについても紹介します。一部、無料公開されているので、ぜひご視聴ください。