採用から退職まで:従業員の在籍期間向けデータテンプレート
採用から退職まで:従業員の在籍期間向けデータテンプレート
これは採用から退職まで:従業員ライフサイクル向けの汎用プロセスマイニング用データテンプレートです。より具体的なガイダンスについては、システム別テンプレートをご利用ください。
特定のシステムを選択- システム間で一貫性を保つための標準化されたデータ項目
- プロセス全体を把握するための推奨アクティビティ
- スムーズなデータ抽出と準備のためのガイダンス
採用から退職まで:従業員ライフサイクルの属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 従業員の在籍期間中に発生した特定のイベント、タスク、マイルストーンの名称です。例として、「オファー承諾」や「評価完了」などがあります。 | ||
| 説明 アクティビティ名は、採用から退職までのプロセスにおける個々のステップを表します。これらのアクティビティはプロセスマップを構成する要素であり、最初の求人申請から最終的な退職確認まで、プロセス内のさまざまな動きを示します。 分析では、この属性を使ってプロセスの流れを可視化し、イベントの順序を確認し、各ステップの頻度と所要時間を測定します。実際に行われている作業を把握し、標準プロセスからの逸脱を見つけ、長時間に及ぶ身元調査や遅延した入社手続きなど、遅延や改善が必要な段階を特定するうえで重要です。 重要な理由 プロセスマップ上のステップを定義する属性であり、プロセスマイニングによる分析と可視化の基盤となります。 入手先 イベントログ、ステータス変更記録、またはHRシステム内の特定の取引データから生成されます。 例 従業員として採用オンボーディングの完了報酬変更の承認退職手続きの開始 | |||
| イベントのタイムスタンプ EventTimestamp | 在籍期間に関する特定のアクティビティまたはイベントが記録された正確な日時です。 | ||
| 説明 イベントのタイムスタンプは、アクティビティが発生した時点を示します。このタイムスタンプは、従業員の流れを正確に再構成するために、イベントを時系列に並べるうえで欠かせません。パフォーマンス分析における主要な時間データです。 この属性を使ってアクティビティ間の処理時間を計算し、採用や退職手続きなどのプロセス全体の所要時間を測定し、時間に関するボトルネックを特定できます。また、時間の経過に伴う傾向分析や、「採用までの平均日数」「入社手続きの処理時間」など、時間に関するKPIの作成にも役立ちます。 重要な理由 イベントを正しい順序で並べ、処理時間や所要時間など、時間に基づくすべてのパフォーマンス指標を計算するために欠かせないタイムスタンプです。 入手先 通常、システムログやデータテーブル内のアクティビティまたは取引レコードとともに保存され、作成日やシステムタイムスタンプなどの名称で記録されています。 例 2023-01-15T09:00:00Z2023-03-20T14:30:15Z2024-05-01T11:21:05Z | |||
| 従業員ID EmployeeId | 各従業員に割り当てられ、組織内での在籍期間全体を通じた主要なケースIDとして機能する一意の識別子です。 | ||
| 説明 従業員IDは、採用手続きの開始から最終的な退職まで、個人を追跡する一意のキーです。入社手続き、評価、昇進、退職手続きなど、在籍期間に関するすべてのイベントを1つの一貫した流れに結び付けます。 プロセスマイニングでは、この属性がケースの関連付けに欠かせません。分析エンジンは、従業員ごとのプロセス全体の流れを再構成できます。従業員IDをケースIDとして使うことで、分析担当者は処理時間を追跡し、個々の従業員の流れにおけるボトルネックを特定し、従業員やグループによって在籍期間のプロセスにどのような違いがあるかを分析できます。 重要な理由 従業員の在籍期間に関するすべてのイベントを結び付け、採用から退職までの全体の流れを分析できる、基本的なケースIDです。 入手先 通常、HR情報システム(HRIS)内の従業員マスターデータの主要テーブルまたはレコードで確認できます。 例 EMP-10345982110USR-A54209 | |||
| ソースシステム SourceSystem | イベントデータの取得元となった情報システムまたはアプリケーションの名称です。 | ||
| 説明 ソースシステム属性は、各イベントのデータの取得元を示します。複雑なHR環境では、採用を担当する応募者追跡システム(ATS)、従業員管理を担当する中核HRIS、報酬変更を担当する給与システムなど、採用から退職までのプロセスの各部分が別々のシステムで管理されている場合があります。 ソースシステム別にデータを分析すると、データ連携の課題やプロセスの分断を把握できます。遅延や問題が特定のシステムに集中しているかを特定し、技術的な改善やプロセスの再設計に役立てられます。また、データの検証や、プロセス全体を漏れなく把握するうえでも重要です。 重要な理由 プロセスデータの取得元を示します。データ品質の問題を調査し、異なるHRシステム間でのプロセスの引き継ぎを把握するうえで重要です。 入手先 通常、データの抽出・変換(ETL)処理中に追加されるか、システム連携ログの標準項目として記録されています。 例 Workday HCMSAP SuccessFactorsOracle PeopleSoft | |||
| 最終データ更新日時 LastDataUpdate | このイベントのデータがソースシステムから最後に更新または抽出された時点を示すタイムスタンプです。 | ||
| 説明 この属性は、データがプロセスマイニング用のデータセットに最後に更新または抽出された時点を示します。業務イベントが発生した時点ではなく、データ自体の新しさを表します。 主な用途は、データガバナンスと検証です。分析担当者は、この情報を使って最新の情報を扱っていることを確認し、ソースシステムでイベントが発生してから分析に反映されるまでの遅延を把握できます。データ更新サイクルを管理し、生成された分析結果の信頼性を保つうえで欠かせません。 重要な理由 分析対象の情報がどの程度最新かを示し、データの鮮度とガバナンスを確保します。分析結果への信頼を高めるうえで重要です。 入手先 通常、データの抽出・変換・ロード(ETL)処理中に生成され、追加されます。 例 2023-10-26T02:00:00Z2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| ユーザー User | アクティビティを実行または開始したユーザーの氏名またはIDです。人事担当者、マネージャー、システムエージェントなどが該当します。 | ||
| 説明 ユーザー属性は、プロセス内の特定のステップを実行した個人またはシステムを示します。オファーを承認する採用マネージャー、入社手続きを開始する人事管理者、リマインダーを自動送信するシステムなどが該当します。 この属性により、人またはシステムエージェントの観点を分析に加えられます。業務量の分布を把握し、研修の必要性を特定し、プロセスのコンプライアンスを確認するために使います。たとえば、報酬変更などの機密性の高い操作が権限を持つ担当者だけによって実行されているかを確認できます。監査とセキュリティの観点で重要です。 重要な理由 誰が操作を実行したかを示します。業務量、コンプライアンス、自動化の度合い、研修の必要性を分析するうえで欠かせません。 入手先 システム監査ログまたは取引レコードで確認できます。「変更者」「作成者」「ユーザーID」などの項目名で記録されることがよくあります。 例 jane.doe@company.comjohn.smithSYSTEM_AUTOMATIONHRServiceCenter | |||
| 勤務地 Location | 従業員が勤務する地理的な場所、オフィス、または国です。 | ||
| 説明 勤務地属性は、従業員の実際の勤務場所または登録上の勤務場所を示します。国のように広い範囲から、オフィスビルやキャンパスのように具体的な場所まで指定できます。 グローバルな組織では、HRプロセスマイニングにおいて地理的な分析が欠かせません。現地の労働法や市場環境による採用期間の違いなど、地域ごとのプロセスパフォーマンスの差を明らかにできます。また、拠点別の離職率を比較し、現地の管理体制や職場環境の問題を示す兆候を見つけることもできます。このデータは、標準化できるプロセスをそろえつつ、地域ごとに必要な対応を取り入れるうえで重要です。 重要な理由 地域ごとのプロセスの違いを特定し、現地規制へのコンプライアンスを評価し、異なる勤務拠点のパフォーマンスを比較できます。 入手先 通常、HRシステム内の従業員の個人住所または勤務先住所の情報に保存されています。 例 米国ニューヨーク英国ロンドンドイツ・ベルリンリモート | |||
| 求人申請ID JobRequisitionId | ポジションの採用プロセスを開始した求人または求人申請を識別する一意のIDです。 | ||
| 説明 求人申請IDは、特定の求人を埋めるためのすべてのアクティビティを結び付ける一意のキーです。求人の作成と承認から候補者の募集、オファー提示までを関連付けます。採用時に従業員IDが生成される前のケースIDとして機能することもあります。 この属性は、従業員の在籍期間のうち採用前の段階を分析する際に特に役立ちます。「採用充足までの期間」などのKPIを測定し、特定のポジションに対する採用プロセスの効率を把握できます。求人申請単位でプロセスを分析すると、さまざまな求人に共通する承認、候補者募集、面接の段階でボトルネックを特定できます。 重要な理由 採用前のすべてのアクティビティを結び付け、採用プロセスや「採用充足までの期間」などの指標を詳細に分析できます。 入手先 新しい求人が作成された際に、応募者追跡システム(ATS)またはHRISの採用モジュールによって生成されます。 例 REQ-2023-05-112JR-459018001543 | |||
| 終了時刻 EndTime | 入社手続きや研修モジュールなど、所要時間を測定できるアクティビティが完了した時点を示すタイムスタンプです。 | ||
| 説明 終了時刻属性は、一定の時間にわたって行われるアクティビティの完了時点を示します。「オファー提示」のように瞬時に発生するHRイベントがある一方、「身元調査」や「入社手続き」のように明確な開始時点と終了時点があるものもあります。このタイムスタンプをイベントのタイムスタンプ(StartTime)と組み合わせることで、所要時間を正確に計算できます。 プロセス分析では、終了時刻が特定のタスクの処理時間や実作業時間を計算するうえで重要です。これにより、待機時間(異なるアクティビティ間の空白時間)と処理時間(1つのアクティビティにかかった時間)を区別できます。所要時間を分析すると、非効率なタスクや自動化、リソースの再配分が必要な箇所を特定できます。 重要な理由 アクティビティの所要時間を正確に計算し、プロセス内の実作業時間と待機時間を区別できます。 入手先 タスクの開始と完了の両方を記録するイベントログまたは取引テーブルに保存されています。明示的に記録されていない場合は、別の「完了」イベントから算出する必要があります。 例 2023-01-20T17:00:00Z2023-04-01T10:15:45Z2024-05-10T16:00:00Z | |||
| 職種名 JobTitle | 従業員の具体的な職種、役割、またはポジションです。 | ||
| 説明 職種名属性は、従業員が組織内で担う役割に関する詳細情報を提供します。「部長」などの上位職から、「シニアソフトウェアエンジニア」や「アカウントエグゼクティブ」などの具体的な職種まで含まれます。 分析では、職種名を使って特定の役割や職位のプロセスを絞り込み、分析できます。「上級職は初級職より採用に時間がかかるか」「技術職と非技術職で入社手続きは異なるか」といった問いに答えるのに役立ちます。この詳細度は、対象を絞ったプロセス改善を行い、従業員によって在籍期間の流れがどのように異なるかを把握するうえで欠かせません。 重要な理由 従業員の役割、職位、職務によって在籍期間のプロセスがどのように異なるかを詳細に分析し、対象を絞った改善を支援します。 入手先 HRマスターレコード内の従業員の職務情報またはポジションデータに保存されています。 例 ソフトウェアエンジニア営業マネージャーHRビジネスパートナーデータアナリスト | |||
| 退職理由 TerminationReason | 従業員が組織を離れた理由として記録された内容です。本人都合の退職や会社都合の退職などがあります。 | ||
| 説明 退職理由は、従業員が会社での在籍を終えた背景を示します。通常、本人都合(退職、定年退職)や会社都合(業績、組織再編)などに分類されます。 この属性は、従業員の離職分析の基盤となります。退職理由を他のデータと関連付けることで、組織は有用な情報を見つけ出せます。たとえば、特定の部門で本人都合の退職が多いか、特定の採用経路から入社した従業員が業績を理由に退職する傾向があるかを分析できます。こうした分析は、効果的な人材定着施策の策定や採用の質の向上に役立ちます。 重要な理由 離職分析に必要な背景情報を提供し、本人都合と会社都合の離職を区別しながら、根本原因を特定できます。 入手先 退職または雇用終了の手続き中に記録され、通常は従業員の最終雇用レコードに保存されます。 例 本人都合:退職会社都合:業績不振会社都合:組織再編定年退職 | |||
| 部門 Department | 従業員が所属する組織上の部門または単位です。営業、エンジニアリング、財務などがあります。 | ||
| 説明 部門属性は、従業員が組織内でどの部門に所属しているかを示します。全社のプロセスパフォーマンスを分類し、比較するための重要な切り口です。 この属性を使って、採用から退職までのプロセスを比較分析できます。たとえば、エンジニアリング部門と営業部門の採用までの所要時間を比較し、採用上の課題の違いを特定できます。また、部門別の離職率を分析して、管理体制や組織文化に問題がある可能性を示す領域を見つけることもできます。部門でプロセスマップを絞り込むと、特定の業務機能に固有のプロセスの違いやボトルネックが明らかになります。 重要な理由 詳細な分類と比較分析を可能にし、組織内の各部門でHRプロセスがどのように実行されているかを明らかにします。 入手先 HRシステム内の従業員の基本プロフィールまたはマスターデータレコードで確認できます。多くの場合、職務やポジションと関連付けられています。 例 エンジニアリング営業人事財務 | |||
| 雇用形態 EmploymentType | 正社員、パートタイム、契約社員、インターンなど、従業員の勤務形態を分類します。 | ||
| 説明 雇用形態は、個人の雇用契約または勤務形態の種類を分類します。HRプロセスの進め方に大きな影響を与えることが多い、重要な属性です。 雇用形態別にプロセスを分析すると、重要な違いが明らかになります。たとえば、契約社員の入社手続きは、正社員に比べて大幅に短く、内容も少ない場合があります。同様に、評価サイクルや退職手続きも異なる可能性があります。この分類は、コンプライアンスを確保し、異なる種類の従業員に合わせてプロセスが適切に設計されているかを確認するうえで重要です。 重要な理由 勤務形態によるプロセスの違いを分析できます。コンプライアンスの確保や、従業員区分に応じたプロセスの最適化に役立ちます。 入手先 従業員の基本HRプロフィールまたは雇用レコードにある標準項目です。 例 フルタイムパートタイム契約社員インターン | |||
| マネージャー Manager | イベント発生時点における、従業員の直属のマネージャーまたは上司の氏名またはIDです。 | ||
| 説明 マネージャー属性は、従業員の直属の上司を示します。マネージャーは、承認、評価、役割変更の開始など、採用から退職までの多くのプロセスで重要な役割を担います。 マネージャー別にプロセスを分析すると、管理の有効性やプロセス遵守の違いを明らかにできます。たとえば、評価を迅速に完了するマネージャーと、常に遅れるマネージャーを特定できます。また、チーム別の離職率を分析し、リーダーシップ上の問題を示す兆候を見つけることもできます。対象を絞ったマネージャー向け研修や支援につなげられます。 重要な理由 チームまたはマネージャー単位でプロセスのパフォーマンスと結果を分析し、管理方法やプロセス遵守の違いを明らかにします。 入手先 HRシステム内の従業員の職務またはポジションデータに保存されています。別の従業員レコードへのリンクとして記録されることもあります。 例 Robert Smithsusan.jones@company.comMGR-9012 | |||
| 事業部門 BusinessUnit | 従業員が所属する、部門より上位の大きな事業上の区分またはセグメントです。 | ||
| 説明 事業部門は、会社内の主要な業務区分を示します。「消費者向け製品」「エンタープライズソフトウェア」「グローバルサービス」などがあります。部門より上位の組織上の文脈を提供します。 事業部門単位で採用から退職までのプロセスを分析すると、戦略的かつ大局的な比較ができます。経営層は、主要な事業セグメント間で人材管理の方法や結果がどのように異なるかを把握できます。たとえば、ある事業部門の社内異動率が大幅に高ければ、組織全体で共有できる優れた取り組みがある可能性を示します。この視点は、HRプロセスをより広い事業戦略と結び付けるうえで欠かせません。 重要な理由 戦略分析に適した上位の組織軸を提供し、主要な事業部門間でHRプロセスのパフォーマンスを比較できます。 入手先 中核HRシステム内の従業員の組織配属データで確認できます。 例 消費者向け製品コーポレート機能研究開発グローバルサービス | |||
| 採用経路 RecruitmentSource | 候補者を最初に見つけたチャネル、プラットフォーム、または方法です。求人サイト、紹介、就職フェアなどがあります。 | ||
| 説明 採用経路は、採用に至った候補者の取得元を示します。従業員紹介のような社内経路や、専門職向けネットワークサイト、大学の就職フェア、外部の人材紹介会社などの社外経路があります。 この属性は、さまざまな人材獲得施策の効果を評価するうえで欠かせません。採用経路別に従業員の在籍期間全体を分析すると、評価スコア、昇進率、定着率などの指標から、質の高い候補者を生み出すチャネルを特定できます。このデータに基づく方法により、採用チームは効果の高い経路に費用と労力を集中できます。 重要な理由 採用チャネルの効果を分析し、候補者の質や定着率に基づいて採用戦略と費用を最適化できます。 入手先 通常、応募または候補者募集の段階で応募者追跡システム(ATS)に記録されます。 例 社員紹介LinkedIn会社採用ページ大学就職フェア | |||
| 雇用ステータス EmploymentStatus | 従業員の現在または過去の雇用状態です。在職中、退職済み、休職中などがあります。 | ||
| 説明 雇用ステータスは、特定の時点における従業員と会社との関係を示します。従業員の在籍期間に応じて変化する動的な属性です。 プロセスマイニングでは、このステータスの変更自体が重要なアクティビティになる場合があります。例として、「休職中に変更」などがあります。また、分析対象を絞り込むための属性としても役立ちます。在職中の従業員の流れに集中したり、退職した従業員の退職に至るプロセスを分析したりできます。さまざまな在籍期間分析で、適切な対象者を含めるために役立ちます。 重要な理由 従業員の現在の状態を定義します。在職中や退職済みなど、特定の対象者に分析を絞り込むうえで重要です。 入手先 HRISの主要な従業員レコードまたは職務情報テーブルにある基本項目です。 例 在籍中退職済み休職中有給休暇 | |||
採用から退職まで:従業員ライフサイクルのアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| オファー承諾 | 候補者が採用オファーを正式に承諾したことを示し、入社前の準備プロセスが始まります。候補者の応募ステータスが「Offer Accepted」または「Hired」に更新された時点で取得します。 | ||
| 重要な理由 採用が成立したことを確認する重要な転換点です。その後のオンボーディングや新入社員の初期設定に関するすべてのアクティビティを開始するきっかけになります。 入手先 候補者の応募ステータスの変更、または電子署名システムに記録された明示的な承諾タイムスタンプから推定します。 取得 候補者のステータスが「Offer Accepted」などの値に更新された時点のタイムスタンプを使用します。 イベントタイプ inferred | |||
| オンボーディングの完了 | 初期オンボーディングのチェックリストまたはワークフローが正常に完了したことを示す重要なマイルストーンです。通常は、新入社員に必要な書類、システムアクセスの申請、初期の事務作業がすべて完了した状態を指します。 | ||
| 重要な理由 このイベントは、事務手続き上、新入社員が組織に完全に受け入れられた時点を示します。オンボーディング完了までの時間を分析することで、初期の生産性やエンゲージメントに影響する非効率を特定できます。 入手先 通常は、オンボーディングチェックリストの最後のタスクの完了タイムスタンプ、または従業員のオンボーディング計画のステータス変更から推定します。 取得 オンボーディングプロセスまたはチェックリストのステータスが「Completed」に変更された時点、または最後の必須タスクの完了タイムスタンプを使用します。 イベントタイプ inferred | |||
| 役割変更の処理 | 昇進、異動、横移動など、従業員の職務に変更があったことを示します。通常は、基幹HRレコードの職務情報変更の有効日から取得します。 | ||
| 重要な理由 このアクティビティは、社内人材の流動性、キャリア形成、人材育成を分析するうえで欠かせません。こうした変更を追跡することで、将来性の高い従業員を特定し、組織再編の状況を把握できます。 入手先 従業員の職務履歴データにある「Job Change」または同様の処理の有効日から取得します。 取得 従業員のJob Title、Department、Position、Gradeフィールドの変更に設定された有効日を使用します。 イベントタイプ explicit | |||
| 従業員として採用 | 応募者レコードを基幹HRシステムの従業員レコードに変換する正式な処理です。正式な入社日と恒久的な従業員IDの付与を示します。 | ||
| 重要な理由 このアクティビティは、ケースをライフサイクルの「Hire」段階から「Retire」段階へ移行させる主なイベントです。在職期間や離職を分析する際の、雇用開始を示す確定的な起点になります。 入手先 基幹HRISにある従業員の主要な雇用レコードの有効開始日から取得する明示的なイベントです。 取得 従業員の採用日、または基幹従業員プロフィールの作成日を使用します。 イベントタイプ explicit | |||
| 従業員の退職 | 従業員が会社を正式に離れ、ステータスが非アクティブになったことを示します。従業員ライフサイクルの最後のイベントであり、最終出勤日に基づきます。 | ||
| 重要な理由 従業員の在職期間の確定的な終了点です。離職率、勤続期間、その他の主要なHR指標を正確に算出するために欠かせません。 入手先 従業員のステータスを非アクティブに変更する「Termination」処理の有効日から推定します。 取得 従業員のステータスが「Terminated」、「Inactive」などの値に変更された、最終的な退職処理の有効日を使用します。 イベントタイプ inferred | |||
| 求人申請の作成 | このアクティビティは、新規または補充ポジションの申請が作成・承認された時点で、採用プロセスが正式に開始したことを示します。通常は、採用モジュールで求人申請が保存され、掲載された際の明示的なイベントとして記録されます。 | ||
| 重要な理由 採用全体にかかる期間を測定する際の主な開始点です。求人申請から充足までの期間を分析することで、人材獲得の初期段階にあるボトルネックを特定できます。 入手先 このイベントは、通常は採用システムまたは人材獲得システムにある求人申請レコードの作成タイムスタンプから取得します。 取得 求人申請レコードの作成日を使用します。通常は、特定の求人申請IDに関連付けられています。 イベントタイプ explicit | |||
| 退職手続きの開始 | 従業員の退職意思表示または会社の決定をきっかけに、退職手続きが正式に始まったことを示します。後続の退職手続きワークフローを開始する明示的なイベントです。 | ||
| 重要な理由 退職手続きのサイクルタイムを測定する起点です。適時かつ適切に管理された退職手続きは、コンプライアンス、セキュリティ、知識移転の観点から重要です。 入手先 退職処理がシステムに初めて入力された時点で取得します。通常は、将来の有効日も含まれます。 取得 最終退職日ではなく、退職申請または退職処理の作成日を使用します。 イベントタイプ explicit | |||
| オファー提示 | 面接と社内承認を経て、正式な採用オファーが候補者に提示されたことを示します。通常は、候補者の応募レコードのステータスが「Offer Pending」などに変更されたことから推定します。 | ||
| 重要な理由 このマイルストーンは、候補者の評価から最終的な採用決定へ移行したことを示します。オファー提示から承諾までの期間は、候補者体験とオファーの競争力を示す重要な指標です。 入手先 通常は、候補者の応募ステータスの変更、またはオファーレター文書の作成日から推定します。 取得 応募ステータスが「Offer Extended」、「Offer Generated」などの状態に変更された時点のタイムスタンプを特定します。 イベントタイプ inferred | |||
| オンボーディングの開始 | 新入社員のオンボーディングプロセスまたはワークフローが正式に始まったことを示します。通常は、オンボーディングのタスクリストまたはワークフローが新入社員とその管理者に割り当てられた時点で取得します。 | ||
| 重要な理由 オンボーディングを速やかに開始することは、新入社員に良い体験を提供するうえで重要です。このアクティビティは、HR業務の効率を測る重要な指標であるオンボーディングのサイクルタイムの起点になります。 入手先 通常は、新入社員に割り当てられたオンボーディングプロセスのインスタンス、ワークフロー、またはチェックリストの作成日から取得します。 取得 オンボーディングチェックリストの割り当て日、またはオンボーディング業務プロセスの開始日を使用します。 イベントタイプ explicit | |||
| バックグラウンドチェックの開始 | 入社前のバックグラウンドチェックが始まったことを示します。通常は、第三者の審査ベンダーに依頼を出した時点、または社内プロセスを開始した時点で取得します。 | ||
| 重要な理由 バックグラウンドチェックの遅延は、新入社員の入社日に大きな影響を与える可能性があります。このステップのサイクルタイムを監視することで、入社前の準備をスムーズかつ適時に進められます。 入手先 審査ベンダーとの連携ログ、またはHRシステム内のステータス変更やタスク作成から取得します。 取得 バックグラウンドチェックを開始するタスクの作成時刻またはAPI呼び出しのタイムスタンプを使用します。 イベントタイプ explicit | |||
| 人事評価の完了 | 従業員に対する正式な人事評価サイクルが完了したことを示します。通常は、人事評価フォームまたはワークフローの完了日から取得する定期的なイベントです。 | ||
| 重要な理由 人事評価を追跡することで、会社のポリシーへの準拠と公平な人材管理を確認できます。部門ごとの評価サイクルの期間や遵守率も分析できます。 入手先 通常は、パフォーマンス管理モジュールで評価フォームのステータスが「Completed」または「Closed」に変更された日付から推定します。 取得 人事評価フォームまたはワークフローのステータスが最終的な完了状態に更新された時点のタイムスタンプを使用します。 イベントタイプ inferred | |||
| 休職の開始 | 病気、個人的な事情、家族の事情などにより、従業員に承認済みの休職が始まったことを示します。従業員のステータスが非アクティブまたは休職中の状態に変更された時点で記録します。 | ||
| 重要な理由 休職を追跡することは、人員計画、リソース管理、コンプライアンスに欠かせません。欠勤のパターンと生産性への影響を把握するのに役立ちます。 入手先 従業員のHRレコードまたは専用の休暇管理モジュールにある、休職ステータスの有効開始日から取得します。 取得 従業員のステータスが「On Leave」などの状態に変更された処理の有効開始日を使用します。 イベントタイプ explicit | |||
| 候補者の応募 | 候補者が募集中の求人に応募を送信した時点を示します。通常は、システムで新しい応募者レコードが作成され、特定の求人に関連付けられた際に明示的に記録されます。 | ||
| 重要な理由 応募を追跡することは、採用チャネルの有効性と候補者パイプラインの規模を把握するうえで重要です。応募から面接、その後の段階までにかかる期間の測定にも役立ちます。 入手先 新しい候補者または応募者のレコードが作成され、求人申請に関連付けられた時点で取得します。 取得 候補者の応募レコードにある送信タイムスタンプを使用します。 イベントタイプ explicit | |||
| 報酬変更の承認 | 従業員の給与、賞与、その他の報酬要素の変更が承認されたことを示します。通常は、承認済みの報酬変更処理の有効日から取得します。 | ||
| 重要な理由 報酬の変更を分析することで、給与の傾向、昇給サイクル、報酬の公平性を把握できます。従業員の金銭面でのキャリア推移を理解するための重要なイベントです。 入手先 基幹HRまたは報酬モジュールにある、承認済み報酬変更レコードの有効日から取得します。 取得 報酬変更処理に関連付けられた有効日を使用します。 イベントタイプ explicit | |||
| 退職手続きの完了 | 資産の返却、知識移転、システムアクセスの無効化など、退職に必要なすべてのタスクが完了したことを示します。退職手続きのチェックリストまたはワークフローが最終的な完了ステータスに達した時点で推定します。 | ||
| 重要な理由 退職に関するすべてのタスクを完了することは、セキュリティリスクの抑制とコンプライアンスの確保に欠かせません。このマイルストーンにより、退職プロセスの効率と徹底度を追跡できます。 入手先 退職手続きのチェックリストの完了、または従業員の退職ワークフローにおける最終ステータスの変更から推定します。 取得 退職手続きのステータスが「Completed」に変更された時点、または最後のタスクの完了タイムスタンプを使用します。 イベントタイプ inferred | |||
データ抽出ガイド
始める準備はできていますか?
以下の選択肢からシステム別のガイドを選び、データ抽出の方法を調整してください。または、この汎用テンプレートを任意のシステムでの出発点としてご利用いただけます。
従業員のライフサイクルを最適化し、今すぐ無料で始める
分析結果を得てプロセスを効率化し、従業員体験をすばやく向上させます。
クレジットカード不要 • 5分でセットアップ