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