採用およびタレントアクイジションのデータテンプレート
採用およびタレントアクイジションのデータテンプレート
こちらは採用とタレントアクイジション向けの汎用プロセスマイニングデータテンプレートです。より具体的なガイダンスが必要な場合は、システム固有のテンプレートをご利用ください。
特定のシステムを選択- 採用プロセスデータ抽出のための汎用フレームワーク。
- 堅牢なプロセス分析のための推奨される属性とアクティビティ。
- 任意の基盤となる人事システムまたはATSシステムと互換性のある堅固な基盤。
採用とタレントアクイジション属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 求人応募の採用プロセス内で発生した特定のタスク、ステップ、またはマイルストーンの名前。 | ||
| 説明 この属性は、「応募受付」「面接設定」「内定通知」など、採用ライフサイクルにおける特定のアクティビティやステージを表します。記録された各アクティビティは、応募ステータスの変更や重要なアクションが行われた時点を示します。 プロセスマイニングの分析では、これら一連のアクティビティがプロセスマップの基礎となります。これにより、実際の採用プロセスの流れを可視化し、一般的なルートの特定や標準手順からの逸脱の発見が可能になります。採用ファネルの分析、候補者が離脱する箇所の特定、各ステージでの所要時間の測定において、アクティビティの分析は不可欠です。 その重要性 プロセスのステップを定義し、採用ファネルの可視化とボトルネックや逸脱の特定を可能にします。 取得元 求人応募に関連するイベントログ、ステータス変更記録、またはアクティビティ履歴テーブルにあります。 例 申請審査済み面接実施済み内定承諾済み | |||
| アクティビティ開始**データ** ActivityStartTime | 採用アクティビティの開始、またはそのアクティビティが記録された日時(日付と時刻を含む)を示すタイムスタンプです。 | ||
| 説明 このタイムスタンプは、アクティビティが発生した、またはシステムに記録された正確な瞬間を示します。所要時間のあるアクティビティの場合は開始時点を、即時的なイベントの場合は発生時点を表します。正確なタイムスタンプは、各応募案件のイベントを時系列で再構築するために不可欠です。 この属性は、プロセスマイニングにおけるすべての時間ベース分析の基盤となります。アクティビティ間の時間(サイクルタイム)、各ステージの所要時間、および総採用所要時間の算出に使用されます。これらのタイムスタンプを分析することで、組織は遅延を特定し、サービスレベル合意(SLA)に対するパフォーマンスを測定し、採用プロセスを加速させる機会をピンポイントで特定できます。 その重要性 これはイベントを時系列に並べ、サイクルタイムや総採用所要時間などのすべての時間ベースの指標を算出するために使用される主要なタイムスタンプです。 取得元 通常、採用システム内のイベントログやトランザクションレコードにおいて、アクティビティ名と併せて記録されています。 例 2023-10-25T10:00:00Z2024-01-15T14:35:10Z2023-11-30T09:15:00Z | |||
| 求人応募ID JobApplicationId | 候補者の特定の求人応募に対する一意の識別子です。これは採用プロセスにおける主要な`ケース`識別子として機能します。 | ||
| 説明 求人応募IDは、求人依頼に応募する候補者の単一のインスタンスを一意に識別します。最初の提出から「採用済み」または「不採用」のような最終決定までの各応募プロセスは、このIDの下で追跡されます。これは、1つの応募ジャーニーに関連するすべてのアクティビティ、タイムスタンプ、およびデータポイントを結びつけるスレッドとして機能します。 プロセスマイニングにおいて、この属性はケース分析の基礎となります。これにより、ツールは各応募のエンドツーエンドのプロセスフローを再構築し、候補者がたどるさまざまなパスを可視化できます。共通の求人応募IDの下ですべてのイベントをグループ化することで、アナリストはケース期間を正確に測定し、特定の応募ライフサイクルにおけるボトルネックを特定し、プロセスバリアントを比較できます。 その重要性 このIDは、各応募の開始から終了までの経過を追跡するために不可欠であり、Time to Hire(採用所要時間)などの主要指標の算出やプロセスのバリエーション分析を可能にします。 取得元 通常、採用システム内の主要な求人応募または候補者のアクティビティレコードに含まれています。 例 APP-2024-00123789456123R-98765 | |||
| ソースシステム SourceSystem | 採用データが元々抽出されたシステムまたはアプリケーションの名前。 | ||
| 説明 この属性は、採用アクティビティが管理・記録されているソースシステム(採用管理システム(ATS)や人事管理(HCM)プラットフォームなど)を識別します。複数のシステムを使用している環境では、このフィールドによってデータの起点を確認でき、透明性とトレーサビリティが確保されます。 プロセスマイニング分析において、ソースシステムの把握はデータの検証とガバナンスに不可欠です。データのコンテキストを理解するのに役立ち、複数のシステムが統合されている場合に特定のシステムに絞り込んで分析を行うことができます。これは、データ準備中や不整合のトラブルシューティングの際に、データ品質の問題を調査すべき箇所を特定する上で特に重要です。 その重要性 データの起源に関するコンテキストを提供し、これは複数システム環境におけるデータガバナンス、検証、およびトラブルシューティングにとって重要です。 取得元 データ抽出プロセス中に追加されるか、データウェアハウスの標準フィールドとして利用可能です。 例 WorkdaySAP SuccessFactorsGreenhouse | |||
| 最終データ更新 LastDataUpdate | 特定のレコードのデータが、ソースシステムから最後に更新または抽出された日時を示すタイムスタンプです。 | ||
| 説明 この属性は、データがソースアプリケーションから最後に同期または取得された日時を記録します。分析対象となっている情報の鮮度を反映するメタデータフィールドとして機能します。これは、ビジネスイベントが実際に発生した日時を記録するアクティビティのタイムスタンプとは異なります。 プロセスマイニングにおいて、このタイムスタンプはデータの整合性を維持し、分析の最新性を把握するために不可欠です。ユーザーは最新の情報を見ているかどうかを確認でき、これは継続的なモニタリングや運用ダッシュボードにおいて特に重要です。また、古いデータを除外したり、データパイプラインの更新をトリガーしたりするためにも使用できます。 その重要性 このタイムスタンプにより、ユーザーはデータの鮮度を確認できます。これは、継続的なプロセスモニタリングや分析の関連性と正確性を保つために極めて重要です。 取得元 通常、データ統合またはETL(Extract, Transform, Load)ツールによって、データロードプロセス中に追加されます。 例 2024-03-15T02:00:00Z2024-03-14T23:59:59Z2024-03-15T05:30:00Z | |||
| アクティビティ終了時間 ActivityEndTime | 特定の所要時間を伴う採用アクティビティが完了した時点を示すタイムスタンプです。 | ||
| 説明 この属性は、面接やバックグラウンドチェックなど、一定期間にわたるアクティビティの完了を記録します。多くの採用アクティビティは開始日時のみで記録されますが、終了時間を記録することで、各プロセスの正確な所要時間を測定できます。 プロセス分析において、終了時間は待機時間と処理時間を区別し、アクティビティ単位での所要時間算出を可能にします。例えば、面接のスケジューリングからフィードバック受信までの時間だけでなく、面接そのものの時間を測定できます。これにより、単にタスク間の時間を見るだけでなく、特定のタスク内でどこに時間がかかっているかを詳細に把握し、非効率な箇所をピンポイントで特定するのに役立ちます。 その重要性 個々のアクティビティの期間を正確に計算することを可能にし、アクティブな処理時間とアイドル状態の待機時間を区別するのに役立ちます。 取得元 アクティビティ期間を追跡するシステムの場合、イベントまたはアクティビティログにあり、多くの場合、開始時間と同じレコード内にあります。 例 2023-10-25T11:00:00Z2024-01-15T15:05:10Z2023-11-30T09:45:00Z | |||
| アプリケーションソース ApplicationSource | 候補者の応募が受け付けられたチャネル、プラットフォーム、または方法。 | ||
| 説明 この属性は、候補者がどのようにして求人を知り応募したかという応募経路を追跡します。一般的なソースには、採用サイト、社員紹介(リファラル)、リクルーターによるソーシング、LinkedIn、大学の求人説明会などがあります。 これは、さまざまなタレントアクイジション戦略の有効性を評価するための重要な属性です。各ソースからの候補者の量と質を分析することで、採用チャネルの投資収益率(ROI)を算出できます。プロセスマイニングを活用すれば、どのソースの候補者が選考プロセスの後半まで進んでいるか、あるいは最も多く採用に至っているかを明らかにし、採用マーケティング費用の最適化を支援します。 その重要性 さまざまなソーシングチャネルの有効性とROIを測定するために不可欠であり、採用マーケティングと戦略の最適化に役立ちます。 取得元 通常、追跡リンクを介して、または候補者による自己申告によって、応募送信時に取得されます。 例 LinkedIn従業員紹介会社`採用ページ`Indeed | |||
| 役職 JobTitle | 候補者が応募した職位の名称です。 | ||
| 説明 この属性は、「シニアソフトウェアエンジニア」や「マーケティングマネージャー」など、募集職種の正式名称を指定します。採用プロセスに対し、どのような職種を補充しようとしているのかという重要なビジネスコンテキストを提供します。 職種(ジョブタイトル)は分析のための重要な要素です。ステークホルダーは、職級、職能、専門分野ごとに採用パフォーマンスを分類できます。例えば、技術職と事務職の採用所要時間を比較したり、エグゼクティブ職に対するさまざまなソーシングチャネルの有効性を分析したりできます。このセグメンテーションは、職種固有のボトルネックを発見し、採用戦略を最適化するための鍵となります。 その重要性 重要なビジネスコンテキストを提供し、異なる職務、レベル、機能間でのパフォーマンス分析とベンチマーキングを可能にします。 取得元 求人応募に関連する求人依頼詳細から抽出されます。 例 `シニア``ファイナンシャルアナリスト`プロダクトマネージャーリードデータサイエンティスト | |||
| 採用マネージャー HiringManager | 募集する職位の管理者の氏名または識別子です。 | ||
| 説明 採用マネージャーは、最終的な採用決定を行い、新入社員が報告する個人です。彼らは採用プロセスにおける主要なステークホルダーであり、職務要件の定義、候補者面接、フィードバック提供に責任を負います。 採用マネージャー別にプロセスパフォーマンスを分析することで、プロセス効率に関する重要な洞察が得られます。例えば、面接フィードバックの提供が遅く遅延を招くマネージャーや、オファー承諾率が非常に高いマネージャーを特定できます。この情報は、マネージャーに的を絞ったトレーニングやサポートを提供し、採用プロセス全体を合理化するために利用できます。 その重要性 特定の採用マネージャーに関連するボトルネックや遅延(遅いフィードバック時間など)を特定するのに役立ち、これは全体の採用期間に直接影響します。 取得元 応募に関連する求人依頼データから抽出されます。 例 David ChenEmily Rodriguezfrank.miller@acme.com | |||
| 採用担当者 Recruiter | 求人応募の管理を担当する採用担当者またはタレントアクイジションスペシャリストの氏名または識別子です。 | ||
| 説明 このフィールドは、特定の応募や求人に対して採用プロセスを担当しているタレントアクイジションチームの主な担当者を特定します。通常、この担当者が候補者のスクリーニング、面接の設定、ステークホルダーとのコミュニケーションに責任を持ちます。 プロセスマイニングにおいて、リクルーター属性はチームおよび個人のパフォーマンス分析に不可欠です。各リクルーターがいくつの案件を管理しているかを示すワークロードバランスのダッシュボードを作成できます。また、採用所要時間や候補者の質などのパフォーマンス指標をリクルーター間で比較し、ベストプラクティスや、コーチング・プロセス改善が必要な領域を特定することも可能になります。 その重要性 個々の採用担当者およびタレントアクイジションチーム全体のワークロード分析とパフォーマンス測定を可能にします。 取得元 通常、求人応募または求人票(ジョブリクイジション)のレコードに含まれています。 例 Alice JohnsonBob Smithcharlie.brown@acme.com | |||
| 申請ステータス ApplicationStatus | 求人応募の最終結果または現在の処理状況。 | ||
| 説明 この属性は、採用プロセスにおける応募の最終的な状態を示します。一般的なステータスには「採用」「不採用」「内定辞退」「候補者による辞退」などがあります。これは、その特定の応募ケースにおけるプロセスの完了を表します。 プロセスマイニングにおいて、最終ステータスは成果に基づいた分析に欠かせません。プロセスマップをフィルタリングして、採用に至った候補者と不採用になった候補者のプロセスを比較できます。これにより「ハッピーパス」を特定し、どのようなプロセスパターンが成功につながるかを理解できます。また、内定承諾率や各ステージでの離脱率などの主要な指標を算出する基礎にもなります。 その重要性 各ケースの最終結果を定義し、どのプロセスバリエーションが採用成功につながり、どのバリエーションが不採用や辞退につながるかを分析できるようにします。 取得元 主な求人応募記録にあり、最終的な処理結果を表します。 例 採用済み却下オファー却下撤回済み | |||
| 職務要件ID JobRequisitionId | 候補者が応募した求人または職位の一意の識別子です。 | ||
| 説明 求人依頼は、空席を補充するための正式な要求です。求人依頼IDは、この要求に割り当てられる一意のコードであり、承認から充足までを追跡します。単一の依頼には、多くの関連する求人応募があります。 プロセスマイニングにおいて、このIDは集計とフィルタリングのための強力な属性です。アナリストはこれを使用して、特定の役割の採用プロセスを分析したり、異なる種類の職位の採用効率を比較したり、求人ごとの応募総数を評価したりできます。これは、「どの求人依頼が最も充足に時間がかかるか?」や「役割ごとの平均応募者数はどのくらいか?」といった質問に答えるのに役立ちます。 その重要性 単一の求人に関連するすべての応募をグループ化し、分析することを可能にし、異なる役割や部署間でのパフォーマンス比較を可能にします。 取得元 求人応募記録にあり、多くの場合、求人依頼または職位マスターデータからリンクされています。 例 REQ-FIN-056JR-100523987654 | |||
| 部署 Department | 職務が配置されている事業ユニットまたは部署。 | ||
| 説明 この属性は、「営業」「エンジニアリング」「人事」など、求人を行っている組織単位を識別します。会社の組織階層に従って採用プロセスの分析を構造化する手段を提供します。 部門別での採用データの分析は、ビジネス全体で採用パフォーマンスがどのように異なるかを理解するために不可欠です。どの部門の採用プロセスが最も効率的で、どの部門にサポートが必要かを特定するのに役立ちます。この属性を使用して、部門別のダッシュボードを作成し、チーム間での採用所要時間や内定承諾率などのKPIを比較し、採用リソースを効果的に配分できます。 その重要性 事業ユニット別の採用効率とワークロードの分析を可能にし、部署固有のトレンド、課題、リソースニーズの特定を支援します。 取得元 応募に関連する求人依頼または職位マスターデータから抽出されます。 例 テクノロジー財務会計マーケティング人事 | |||
| オファー金額 OfferAmount | 求人オファーで候補者に提示された予定給与または報酬額。 | ||
| 説明 この属性は、候補者に提示された報酬パッケージの金額を記録します。採用プロセスの最終段階における重要なデータであり、通常は現地通貨で記録されます。 プロセスマイニングの視点では、提示額の分析が貴重なコンテキストを提供します。提示額を内定承諾率や辞退率と関連付けることで、報酬の競争力を把握できます。また、職種、部門、地域ごとの報酬トレンドの分析も可能です。他のデータと組み合わせることで、給与ベンチマークの評価や、公平な賃金慣行の確保にも役立ちます。 その重要性 オファー金額と、さまざまな役割および場所における承諾率および却下率を関連付けることにより、報酬パッケージの競争力分析を支援します。 取得元 採用またはHRシステム内の求人オファー記録から抽出されます。 例 8500012000065000 | |||
| 候補者タイプ CandidateType | 候補者が社内従業員か外部応募者かを示すフラグまたはカテゴリ。 | ||
| 説明 この属性は、応募者が組織の現職従業員(内部)か、そうでないか(外部)を区別します。採用プロセスやタイムライン、規定が両者で大きく異なることが多いため、これは基本的なセグメンテーションとなります。 候補者のタイプに基づいた分析は、内部流動性と外部採用の有効性を理解する上で極めて重要です。プロセスマイニングを用いて、内部候補者と外部候補者の採用所要時間、採用コスト、成功率を比較できます。これにより、社内公募制度などのパフォーマンスを評価し、両方の採用ルートが効率的かつ効果的であることを確認できます。 その重要性 採用プロセスが異なる社内外の候補者を区別し、社内異動と外部採用の効率性を比較分析できるようにします。 取得元 候補者のIDまたはメールが従業員マスターデータに存在するかどうかを確認することで、多くの場合導き出されます。一部のシステムには専用のフラグがある場合があります。 例 内部外部 | |||
| 却下理由 RejectionReason | プロセスのどの段階であっても、候補者の応募が却下された際に提示される具体的な理由。 | ||
| 説明 候補者の選考を見送る決定がなされた際、その理由が記録されることがよくあります。その理由は「カルチャーフィットしない」「必要なスキルが不足している」から「他の候補者が採用された」まで多岐にわたります。この属性は、そうした定性的な情報を取得します。 不採用理由の分析は、採用プロセスや職務要件に関する貴重なフィードバックを提供します。不採用理由を応募経路や面接ステージと関連付けることで、求人票の定義が不十分で不適格な候補者が集まっている、あるいは面接官による評価に一貫性がないといった問題を特定できます。これにより、採用戦略を洗練させ、候補者プールの質を向上させることができます。 その重要性 候補者が不適格となる理由に関する洞察を提供し、職務記述書の改善、ソーシング品質の向上、スクリーニングプロセスにおける潜在的なバイアスの特定に役立ちます。 取得元 通常、リクルーターや採用マネージャーが応募ステータスを「不採用」に更新した際に記録されます。 例 最低資格要件を満たしていないより適格な候補者の特定関連経験不足採用凍結 | |||
| 場所 Location | 職務に関連する地理的な場所(都市、州、国など)。 | ||
| 説明 この属性は、求人の勤務地を指定します。リモートワークのポジションの場合は、特定の地域を示すか「リモート」と記されることがあります。これにより、採用データに地理的な次元が加わります。 プロセスマイニングにおいて、勤務地は地域別分析の主要な属性です。企業は、拠点や国ごとに採用サイクルタイム、ソーシングチャネルの有効性、内定承諾率を比較できます。これにより、労働市場の地域差、採用チームのパフォーマンス、プロセスの遵守状況を明確にし、より適切な管理と戦略立案が可能になります。 その重要性 採用パフォーマンスの地理的分析を可能にし、異なる地域やオフィス間での採用効率と課題を比較するのに役立ちます。 取得元 応募に関連する求人依頼詳細にあります。 例 ニューヨーク、NYロンドン、英国リモート(米国)ベルリン、ドイツ | |||
採用とタレントアクイジションアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| オファー却下 | 候補者が会社から提示された求人オファーを正式に辞退しました。これはプロセスの後半で発生する失敗の終着点です。 | ||
| その重要性 これは内定承諾率のKPIに直接影響します。内定辞退の理由を分析することで、報酬、福利厚生、職種の競争力に関する洞察を得ることができます。 取得元 応募またはオファー記録上の明確なステータス変更として記録され、「オファー辞退」または「オファー却下」など、多くの場合理由コードが付随します。 取得 ステータスが「内定辞退」に変更された際のタイムスタンプを使用します。 イベントタイプ explicit | |||
| 候補者採用済み | 候補者は採用前要件をすべて正常に完了し、正式に採用されました。これは応募プロセスの成功した終着点です。 | ||
| その重要性 このアクティビティは採用ライフサイクルの正常な完了を意味します。Time-to-Hire(採用所要時間)の指標を算出するための主要な終了イベントとして機能します。 取得元 HRシステムで主要な「採用」ビジネスプロセスが完了したとき、または採用ツールにおける候補者の最終ステータスが「採用済み」に設定されたときに記録されます。 取得 採用トランザクションの発効日、または「採用済」への最終ステータス変更日を使用します。 イベントタイプ explicit | |||
| 内定承諾済み | 候補者が正式に求人オファーを受諾し、入社意思を示しました。これは採用プロセスの主要な成功マイルストーンです。 | ||
| その重要性 これは内定承諾率のKPIに直接影響する重要な成功イベントです。これにより、最終的な採用前手続きやオンボーディングのアクティビティが開始されます。 取得元 候補者がオンラインポータル経由で承諾した場合、または採用担当者が口頭または書面による確認に基づいて応募ステータスを「オファー受諾済み」に手動で更新した場合に記録されます。 取得 候補者による電子承諾のタイムスタンプ、または「承諾済」への手動ステータス変更時のタイムスタンプを使用します。 イベントタイプ explicit | |||
| 内定提示済み | 正式な求人オファーが候補者に公式に伝えられ、審査と検討を求められました。これは採用プロセスにおける主要なマイルストーンであり、正式な採用意図を表します。 | ||
| その重要性 これは応募から内定までの時間を測定する重要なポイントです。内定通知から候補者の回答までの期間は、承諾の判断にかかる時間を理解するための鍵となります。 取得元 採用システムからオファーが送信されたときに、明示的なイベントまたは明確なステータス変更として記録され、多くの場合、対応するタイムスタンプが伴います。 取得 オファー送付のイベントタイムスタンプ、またはステータスが「オファー提示済み」に変更されたタイムスタンプを特定します。 イベントタイプ explicit | |||
| 応募を受理しました | 候補者が特定の求人に対して応募を提出したときにプロセスが開始されます。これは、求人応募`ケース`にとって最初に記録される`イベント`であり、採用活動の最初の入り口となります。 | ||
| その重要性 このアクティビティは採用プロセスの開始点であり、全体の「Time-to-Hire(採用所要時間)」の算出や総応募数の把握に欠かせません。 取得元 このイベントは、応募の送信ログ、または主要な採用・タレントアクイジションシステム内の応募レコードの作成日時から取得されます。 取得 求人応募レコードの作成日時を使用します。 イベントタイプ explicit | |||
| 申請却下済み | 会社は、採用プロセス中のどの時点でも候補者との選考を進めないことを決定しました。これは最も一般的な失敗の結果です。 | ||
| その重要性 これは極めて重要な終了イベントです。不採用がいつ、どの段階で発生しているかを分析することで、ファネルの離脱ポイントや各ステージでの選考基準の有効性を把握できます。 取得元 採用担当者または採用マネージャーが、応募ステータスを最終的な「不採用」または「不選出」ステータスに更新した場合に記録されます。 取得 応募ステータスが最終的な「不採用」処分に変更されたときのタイムスタンプを特定します。 イベントタイプ explicit | |||
| 面接実施済み | 候補者との面接が採用チームの1人または複数のメンバーによって完了しました。このアクティビティは、特定の面接ラウンドの終了を示し、意思決定段階の前段階となります。 | ||
| その重要性 この 取得元 多くの場合、スケジュールされた面接時間が経過したこと、または面接が行われた後に採用担当者が応募ステータスを更新したことに基づいて推測されます。 取得 スケジュールされた面接日以降に、応募ステータスが「面接完了」または類似のステートに更新された時期を特定します。 イベントタイプ inferred | |||
| `オンボーディング`開始 | 新入社員の受け入れ準備プロセスが正式に開始されました。これは、多くの場合、採用システムから主要な人事システムまたはオンボーディングプラットフォームへの引き継ぎを伴います。 | ||
| その重要性 これは採用から従業員の統合への移行を意味します。この引き継ぎポイントを分析することは、スムーズな入社体験の確保とプロセスの効率化において非常に重要です。 取得元 候補者のレコードがオンボーディングモジュールに移動された場合、またはステータスが「採用準備完了」または「オンボーディング開始」に更新された場合に記録されます。 取得 オンボーディングステートへのステータス変更、またはオンボーディングシステムでの候補者の作成を特定します。 イベントタイプ inferred | |||
| オファー準備済み | 正式な求人オファーの詳細を作成し、承認するための内部プロセスが開始されます。これは、採用決定後、かつオファーが候補者に送信される前に行われます。 | ||
| その重要性 この内部ステップの期間を分析することで、候補者には見えない報酬レビュー、法的承認、または経営陣の承認におけるボトルネックが明らかになる可能性があります。 取得元 応募が「オファー承認」または「オファー草案」段階に移行したこと、またはシステムでオファーオブジェクトが作成されたことから推測されます。 取得 応募ステータスがオファー準備または承認段階に変更されたときのタイムスタンプを検出します。 イベントタイプ inferred | |||
| フィードバック提出済み | 面接官が面接後、候補者の評価、メモ、またはスコアカードを正式に提出します。これは、集団的な採用決定にとって重要な入力となります。 | ||
| その重要性 これはフィードバックループの効率を測定します。ここでの遅延は意思決定プロセス全体を停滞させ、候補者の体験に悪影響を及ぼす可能性があります。 取得元 通常、フィードバックフォームやスコアカードが保存され、候補者の応募に紐付けられた際に、明示的なイベントとして取得されます。 取得 面接フィードバックまたはスコアカードのレコードの作成日時を使用します。 イベントタイプ explicit | |||
| 候補者が応募を撤回 | 候補者が自発的にその役割への応募を取り下げました。これはプロセスのどの段階でも発生する可能性があります。 | ||
| その重要性 これによって候補者の体験とプロセスの所要時間に関する洞察が得られます。辞退率が高い場合は、採用プロセスが冗長で非効率、あるいは候補者の意欲を削ぐものである可能性を示唆しています。 取得元 採用担当者が候補者からのコミュニケーションに基づいて応募ステータスを「撤回」に更新した場合、または候補者がポータル経由で撤回した場合に記録されます。 取得 応募ステータスが「撤回」に変更されたときのタイムスタンプを検出します。 イベントタイプ explicit | |||
| 申請審査済み | 採用担当者または採用マネージャーが、候補者の応募書類を主要な職務要件と照らし合わせて初期レビューを行います。このアクティビティは、プロセスにおける最初の選考ゲートとして機能します。 | ||
| その重要性 このステップにかかる時間を分析することで、初期応募処理におけるボトルネックを特定し、採用担当者のワークロードを評価できます。また、初期の適格率も把握できます。 取得元 通常、「新規」から「審査中」または「スクリーニング中」への 取得 応募ステータスが「審査中」または「スクリーニング中」ステートに変更されたときのタイムスタンプを特定します。 イベントタイプ inferred | |||
| 身元調査を開始しました | 候補者に対する採用前スクリーニングプロセス(身元調査や照会確認など)が開始されたことを示します。通常、オファーが承諾された後に発生します。 | ||
| その重要性 これにより、最終的な採用確定前の遅延の原因となりやすい、外部ベンダーによる調査や採用前スクリーニングの内部プロセスの効率を追跡できます。 取得元 通常、応募ステータスが「バックグラウンドチェック」ステージに変更されたことから推測されます。多くの場合、これにより調査ベンダーとのシステム連携がトリガーされます。 取得 応募ステータスが「バックグラウンドチェック進行中」に移動したときのタイムスタンプを検出します。 イベントタイプ inferred | |||
| 電話スクリーニング実施済み | 採用担当者が候補者と予備的な電話またはビデオ会議を行い、基本的な資格、興味、企業文化への適合性を評価します。これは多くの場合、候補者との最初の直接的なやり取りとなります。 | ||
| その重要性 この 取得元 通常、電話インタビュー(電話スクリーニング)の完了を反映するために応募ステータスが更新された際に取得されます。 取得 「電話スクリーニング完了」、「電話スクリーニング通過」、または類似の値へのステータス変更を検出します。 イベントタイプ inferred | |||
| 面接予定 | 候補者と採用チームの間で、仮想または対面での面接が正式にスケジュールされました。このアクティビティは、両当事者からの時間のコミットメントを表します。 | ||
| その重要性 これは候補者の進捗を示す重要なマイルストーンです。スクリーニングからこのイベントまでの時間を追跡することで、スケジューリングの効率や潜在的な遅延を浮き彫りにします。 取得元 スケジューリングシステムでの明示的な入力、カレンダー連携、または応募ステータスが「面接スケジュール済み」に変更されたことから推測されます。 取得 応募に関連付けられた面接またはカレンダーイベントの作成日時を使用します。 イベントタイプ explicit | |||