> 継続的なプロセス改善 > 採用・人材獲得 > SAP SuccessFactors Recruiting > データテンプレート

採用・人材獲得のデータテンプレート

SAP SuccessFactors Recruiting

採用・人材獲得の属性(20) 採用・人材獲得のアクティビティ(16) データ抽出ガイド(3)

採用・人材獲得のデータテンプレート

このテンプレートでは、SAP SuccessFactors Recruitingから収集する必要があるデータ項目とプロセスの手順をわかりやすく説明します。プロセスマイニング分析に向けたデータの準備にお役立てください。推奨される属性や主要なアクティビティに加え、データ抽出の手順も確認できます。

収集を推奨する属性
追跡する主要なアクティビティ
データ抽出の手順

イベントログを初めて作成する方はこちら：プロセスマイニング用イベントログの作成方法.

テンプレートをダウンロード

採用・人材獲得の属性

採用・人材獲得プロセスを詳しく分析するために、イベントログに含める必要があるデータ項目です。

3 必須 8 推奨 9 任意

	名前	説明
	求人応募 JobApplication	特定の求人申請に対する候補者の応募を識別する一意のIDです。
説明求人応募IDは、採用プロセスにおける主要な案件識別子です。応募の提出から、書類選考、面接、オファー、最終的な採用決定まで、候補者1人の選考過程を追跡します。応募ごとに個別の案件として扱うため、候補者体験や求人ごとのプロセス効率を詳しく分析できます。プロセスマイニングでは、求人応募IDを使って分析することで、候補者一人ひとりの選考経路を最初から最後まで把握できます。ボトルネックや標準プロセスからの逸脱、応募1件の処理にかかった全体時間を特定できます。案件単位の分析を支える基本的な属性です。重要な理由候補者ごとの選考過程を一意に識別できるため、応募から最終決定までのプロセスを一貫して分析できます。入手先通常、SAP SuccessFactors Recruitingの求人応募エンティティにおける主キーです。JobApplication OData APIから取得できます。例 APP-0012345APP-0012346APP-0012347
	アクティビティ ActivityName	採用プロセスで発生した個々の手順やイベントの名前です。
説明アクティビティは、「応募の受領」「面接の設定」「オファーの提示」など、採用プロセスにおける個別の段階やアクションを表します。これらのイベントを時系列に記録し、求人応募1件のプロセスを構成する一連のアクションを把握します。プロセスマイニングでは、アクティビティの順序をもとにプロセスマップを作成し、プロセスのバリアントを可視化して、標準からの逸脱を特定します。どの手順がどの順序で、どのくらいの頻度で行われているかを把握することで、非効率な点やコンプライアンス上の問題を見つけやすくなります。重要な理由プロセスの各手順を定義し、採用ワークフローの可視化と分析を可能にします。入手先通常、求人応募オブジェクトのステータス変更、またはSAP SuccessFactors Recruiting内の個別のイベントログから取得します。例応募書類の選考面接の実施オファーの承諾候補者の採用
	開始時刻 EventTimestamp	採用アクティビティが発生した正確な日時です。
説明この属性には、プロセス内の各アクティビティの日時が記録され、イベントの発生順序を把握できます。採用プロセスの所要時間、待ち時間、サイクルタイム全体の算出に欠かせません。この日時は、プロセスマイニングにおける時間ベースの分析の基礎となります。アクティビティ間の所要時間の算出、遅延の特定、SLAに対する実績の測定、プロセスの時間的な動きの把握に使います。正確な日時がなければ、プロセス効率の分析や時間に関するボトルネックの発見はできません。重要な理由サイクルタイムの算出、遅延の特定、プロセス実績の分析に必要な時系列データを提供します。入手先通常、求人応募エンティティの作成日、またはステータス変更に関連付けられた最終更新日です。例 2023-04-15T10:30:00Z2023-04-22T14:00:00Z2023-05-01T11:45:00Z
	候補者ID CandidateId	求人に応募した個人を識別する一意のIDです。
説明候補者IDは、応募した求人の数にかかわらず、人材プール内の個人を一意に識別します。候補者の履歴や企業とのやり取りを継続的に追跡できます。分析では、複数回応募する候補者の傾向を把握し、候補者ごとの視点からプロセスを確認できます。あるポジションで不採用となった候補者が別のポジションで採用されたかを確認したり、複数の応募を通じた個人の体験を分析したりできます。重要な理由複数の応募にわたって候補者を追跡し、企業とのやり取りを全体的に把握できます。入手先 SAP SuccessFactors RecruitingのCandidateエンティティで利用でき、JobApplicationエンティティに関連付けられています。例 CAND-9876CAND-9877CAND-9878
	応募ステータス ApplicationStatus	応募の現在または最終的なステータスです。「採用」「不採用」「辞退」などがあります。
説明この属性は、各時点での応募結果を示します。最終ステータスは、採用プロセスが成功したかどうかを示すため、特に重要です。応募ステータスは、結果分析やファネルの転換率を把握するうえで欠かせません。各段階で「進行中」から「不採用」などの終了ステータスに移った候補者の数を追跡し、「段階別の候補者離脱率」KPIを算出できます。また、採用に至ったプロセスに絞り込んで、優れた取り組みを分析する際にも役立ちます。重要な理由プロセスの結果を示すため、離脱率の算出や採用プロセスの成功状況の分析に欠かせません。入手先 JobApplicationエンティティの主要項目で、応募が選考プロセスのどの段階にあるかを示します。例採用済み企業による不採用候補者による辞退オファー辞退
	応募経路 ApplicationSource	候補者が応募を提出した経路です。
説明この属性は、応募がどこから来たかを示します。たとえば、企業の採用ページ、LinkedIn、社員紹介、採用エージェンシーなどです。採用経路ごとの効果を評価する際に役立ちます。分析では、応募経路ごとの候補者の質や人数を測定します。応募経路と採用実績を関連付けることで、「応募経路の効果」KPIを算出できます。採用マーケティングの費用配分を見直し、効果の高い経路に注力するための判断材料になります。重要な理由採用経路ごとの効果を測定し、人材獲得の方針や予算を見直す際に役立ちます。入手先候補者の応募時に記録され、JobApplicationまたはCandidateエンティティで確認できます。例会社のウェブサイトLinkedIn社員紹介Indeed
	採用マネージャー HiringManager	採用する職務の採用マネージャーの名前またはIDです。
説明採用マネージャーは最終的な採用判断を下す担当者であり、プロセスにおける重要な関係者です。フィードバックの提出やオファーの承認など、その対応によってプロセスの所要期間が大きく変わることがあります。この属性を使うと、フィードバックの提出やオファーの承認が遅れるなど、特定の採用マネージャーに起因する遅延を特定できます。採用マネージャーごとにプロセスのバリアントを分析すれば、組織内で面接プロセスの進め方にばらつきがあるかどうかも確認できます。重要な理由ボトルネックにつながる可能性のある重要な関係者を特定し、承認やフィードバックの遅れを分析できます。入手先 SAP SuccessFactors RecruitingのJobRequisitionエンティティに標準で用意されている項目です。例アリス・ウィリアムズロバート・ブラウンチャールズ・デイビス
	採用担当者 Recruiter	求人応募または求人申請を担当する採用担当者の名前またはIDです。
説明この属性は、求人申請の採用プロセスを管理する主担当の採用担当者を示します。プロセスに関わる重要なリソースです。採用担当者ごとにプロセスを分析すると、パフォーマンスの評価や業務量の管理に役立ちます。採用までの期間が最も短い担当者は誰か、業務量は均等に分配されているか、特定の担当者がプロセスの手順を繰り返し省略していないか、といった点を確認できます。この属性は、「採用担当者のパフォーマンスと業務量」ダッシュボードや「採用担当者の業務量偏り指数」KPIの分析に直接役立ちます。重要な理由採用担当者ごとのパフォーマンスや業務量の分布を把握し、優れた取り組みや研修の必要性を特定できます。入手先通常はJobRequisitionエンティティに保存され、担当する採用担当者を示します。例ジョン・スミスジェーン・ドウエミリー・ジョーンズ
	求人申請ID JobRequisitionId	募集する求人またはポジションを識別する一意のIDです。
説明求人申請IDは、複数の求人応募を1つの採用案件に関連付けます。ポジションを埋めるための正式な申請を表し、職種名、部門、勤務地などの情報を含みます。求人申請IDで分析すると、1つの求人に対する候補者全体を把握できます。求人掲載の効果を確認したり、同じ役割に応募した候補者の選考過程を比較したり、「採用までの期間」などの指標を算出したりする際に役立ちます。重要な理由 1つの求人に対するすべての応募をまとめ、特定のポジションにおける候補者ファネル全体を分析できます。入手先 SAP SuccessFactors RecruitingのJobRequisitionエンティティにある主要項目で、JobApplicationエンティティに関連付けられています。例 REQ-2023-101REQ-2023-102REQ-2023-103
	職種名 JobTitle	候補者が応募したポジションの名称です。
説明この属性は、採用する役割を示します。例として「ソフトウェアエンジニア」や「プロジェクトマネージャー」があります。採用プロセスを分類・比較するうえで重要な項目です。職種名ごとに分析すると、役割によって採用サイクルが異なるかを把握できます。たとえば、技術職では事務職より面接の段階が多い場合があります。「重要な役割の採用までの期間」などの重要業績評価指標（KPI）の算出や、役割ごとのボトルネックの特定にも欠かせません。重要な理由役割ごとの採用プロセスを比較し、職種特有のボトルネックや違いを特定できます。入手先 JobApplicationに関連付けられたJobRequisitionエンティティの項目です。例シニアソフトウェアエンジニアプロダクトマネージャーデータアナリスト
	部門 Department	職務が属する部門または事業部門です。
説明この属性は、新しい採用者を受け入れる組織単位を示します。たとえば、「エンジニアリング」「マーケティング」「財務」などです。部門は、根本原因を分析するうえで重要な切り口です。組織内の部門ごとにプロセスのパフォーマンスを比較し、採用期間が長い部門を特定したり、プロセス逸脱が特定の事業部門に集中しているかを確認したりできます。部門別のパフォーマンスを示すダッシュボードの作成にも役立ちます。重要な理由事業部門ごとのパフォーマンスを比較し、部門固有のプロセス上の問題を特定できます。入手先この項目はJobRequisitionエンティティの一部で、組織構造のデータに関連付けられています。例研究開発営業人事
	オファーが承諾されたかどうか IsOfferAccepted	候補者が求人オファーを承諾したかどうかを示す計算フラグです。
説明これは、結果分析を簡単にするための派生真偽値属性です。通常、応募の最終ステータスが「オファー承諾」または「採用」の場合は「true」に設定され、「オファー辞退」や「辞退」を含むそれ以外の場合は「false」に設定されます。この属性を使うと、オファー承諾率に関するダッシュボードやKPIを簡単に作成できます。職務名や部門などの要因とオファー承諾率の高低との関連を分析するため、データの絞り込みや集計にも利用できます。重要な理由オファー承諾率の分析を簡単にし、オファーの承諾に関係する要因の特定に役立ちます。入手先これはソースシステムの項目ではありません。データ変換時に「ApplicationStatus」項目から算出します。例 truefalse
	オファー金額 OfferAmount	候補者に提示した給与額です。
説明この属性には、求人オファーで提示した給与額が記録されます。採用プロセスの最終段階で重要な情報です。オファー金額を分析すると、「オファー交渉の所要期間」を把握する際の参考になります。交渉に平均より時間がかかる場合、職務の給与レンジの下限に近い金額を提示していることが関係している可能性があります。また、職務や部門ごとの報酬の競争力も分析できます。重要な理由オファー交渉にかかる期間の背景を把握し、報酬方針や競争力を分析できます。入手先このデータは、JobApplicationに関連付けられたOffer DetailsまたはOffer Approvalエンティティに保存されます。例 8500012000095500
	ソースシステム SourceSystem	採用データの抽出元となるシステムです。
説明この属性はデータの取得元を示します。複数のシステムからデータを取得する環境では特に重要です。このプロセスでは、通常「SAP SuccessFactors Recruiting」が該当します。分析では、データの来歴を確認するために使います。複数の採用プラットフォームを使用している場合は、データの絞り込みや分類にも利用できます。データガバナンスや問題の調査に必要なコンテキストを提供します。重要な理由データの取得元を確認できるため、データガバナンス、検証、複数システムを利用する環境で重要です。入手先レコードの取得元を示す固定値です。データ抽出時に追加します。例 SAP SuccessFactors RecruitingSFSF-RCM-PROD
	不採用理由 RejectionReason	候補者の応募を不採用とした際に記録される理由です。
説明応募のステータスが「不採用」に変更されると、多くの場合、その理由が記録されます。資格、面接の結果、その他の要因などが該当します。候補者が選考を通過できなかった理由を定性的に把握できます。この属性は「候補者パイプラインの離脱分析」に役立ちます。離脱率の数値に背景情報を加えることで、根本原因の把握につながります。たとえば、スクリーニング段階で「基本的な応募資格を満たしていない」として不採用になる候補者が多い場合、求人票や応募経路に問題がある可能性があります。重要な理由候補者が選考から外れた理由を把握し、求人票や人材獲得経路の問題を特定するのに役立ちます。入手先応募のステータスが「不採用」に変更された際に入力されることが多い項目です。例応募資格を満たしていないより適した候補者がいた技術評価に不合格企業文化との適合性が低い
	最終データ更新日時 LastModifiedDate	ソースシステムでレコードが最後に更新された日時です。
説明この属性には、SAP SuccessFactorsでイベントまたは案件データが最後に変更された日時が記録されます。データの更新や検証に役立ち、分析に最新の情報が使われていることを確認できます。データパイプラインでは、差分データの読み込みに欠かせない項目です。前回の更新以降に作成または変更されたレコードだけを抽出できるため、データ更新の効率が向上します。重要な理由差分データを効率よく読み込めるほか、分析に最新の情報が使われていることを確認できます。入手先 SAP SuccessFactors OData APIの多くのエンティティで利用できる「lastModifiedDateTime」などのメタデータ項目に該当します。例 2023-06-10T09:00:00Z2023-06-11T15:20:00Z
	勤務地 Location	職務に関連付けられた地理的な場所またはオフィスです。
説明この属性は、職務の勤務地となる市区町村、州、国を示します。採用プロセスにおける地域差の分析に使います。勤務地ごとの分析により、採用までの期間、候補者の離脱率、プロセスのコンプライアンスに地域差があるかを確認できます。こうした情報は、地域ごとの労働市場に合わせた採用方針の検討や、特定の地域における課題や優れた取り組みの特定に役立ちます。重要な理由地域ごとのプロセスのパフォーマンスを分析し、地域特有のボトルネックや効率のよい点を把握できます。入手先この項目はJobRequisitionエンティティの一部で、職務の勤務地を示します。例ニューヨーク州ニューヨーク英国ロンドンドイツ・ベルリン
	段階ごとの所要期間 TimeInStage	応募が次の段階に進むまで、特定の段階にとどまった期間です。
説明この計算指標は、連続する2つのアクティビティ間の時間を測定します。たとえば、応募が「応募書類の審査」段階にとどまってから「電話面接」に進むまでの期間を測定できます。この属性は、ボトルネックの特定に欠かせません。プロセスの各手順にかかった期間を算出することで、時間がかかっている段階を特定できます。「応募書類審査のサイクルタイム」や「求人申請・オファー承認の遅延」などの分析を含む、多くのダッシュボードで使用されます。重要な理由プロセスの各手順にかかった期間を数値化し、遅延の原因となっている段階を特定できます。入手先データ変換時に、同じケースにおけるアクティビティのタイムスタンプと直前のアクティビティのタイムスタンプの差を求めて算出します。例 3日10日1日
	社内候補者かどうか IsInternalCandidate	応募者が既存の従業員かどうかを示すフラグです。
説明この真偽値属性は、現職の従業員である社内候補者と社外候補者を区別します。社内異動のプロセスは、社外採用とは異なることがよくあります。このフラグに基づいて分析すると、社内異動と社外採用の両方を把握し、改善するうえで役立ちます。社内採用では、より短く簡略化されたプロセスが適用される場合があります。両者を比較することで、社外採用の効率を高める機会を見つけられます。重要な理由手順や所要期間が異なることの多い社内異動と社外採用を分けて分析できます。入手先このフラグは通常、CandidateまたはJobApplicationエンティティで確認できます。例 truefalse
	雇用形態 EmploymentType	職務の雇用形態です。フルタイム、パートタイム、契約社員などがあります。
説明この属性は、雇用条件に基づいて職務を分類します。採用する職務の基本的な特性です。この属性を切り口にすると、正社員と契約社員の採用プロセスを比較できます。雇用形態によって、手順、所要期間、承認要件が異なる場合があります。分析結果は、雇用形態ごとのプロセスの効率化に役立ちます。重要な理由フルタイムと契約社員など、職務の種類ごとにプロセスを分けて分析し、採用方法を見直せます。入手先 JobRequisitionエンティティに標準で用意されている項目です。例フルタイムパートタイム契約社員インターン

必須推奨任意

採用・人材獲得のアクティビティ

採用ワークフローを正確に把握するには、イベントログに記録する重要なプロセスのステップとマイルストーンを確認してください。

8 推奨 8 任意

	アクティビティ	説明
	オファーの承諾	候補者が正式に求人オファーを承諾した時点で発生します。採用担当者が候補者の回答を受けて応募ステータスを更新した際に記録される、重要な成功の節目です。
重要な理由選考が成功したことを示し、オファー承諾率の測定に欠かせないアクティビティです。また、オファー後の段階の開始点にもなります。入手先求人応募レコードのステータスが「オファー承諾済み」に変わったことから推定します。このステータス変更の日時をイベント時刻として使用します。記録応募ステータスが「オファー承諾済み」に更新された日時を追跡します。イベントタイプ inferred
	オファーの提示	正式な求人オファーを候補者に伝えた時点を示します。通常、システム上で応募ステータスが「オファー提示済み」などに更新されたことから推定します。
重要な理由オファーの交渉と承諾までの期間を測る起点となる重要な節目です。この時点から「オファー承諾」までの時間を分析すると、オファー交渉の流れを把握できます。入手先求人応募のステータス履歴の変更から推定します。「オファー提示済み」に更新された日時がイベント時刻になります。記録応募ステータスが「オファー提示済み」に変わった日時を特定します。イベントタイプ inferred
	候補者の採用	求人応募における採用プロセスが成功裏に完了したことを示します。通常、採用モジュールで最終ステータスが更新されたことから推定します。オンボーディングの完了後、入社日が確定した時点で更新されることがよくあります。
重要な理由プロセスが成功したことを示す主な終了点です。採用までの期間全体の算出や、採用ファネルの成功率の測定に欠かせません。入手先求人応募の最終ステータスが「採用済み」などになったことから推定します。この最終ステータスが更新された日時がイベントを示します。記録応募の最終ステータスが「採用済み」に設定された日時を特定します。イベントタイプ inferred
	応募の不採用	企業が候補者の選考を進めないと決定した場合の、プロセスの不成立を示します。応募に「不採用」や「選考対象外」などの最終ステータスが設定されたことから推定します。
重要な理由候補者ファネルの離脱分析では、各段階での不採用を追跡することが重要です。候補者が最も多く選考から外れる段階を特定できます。入手先採用担当者または採用マネージャーが求人応募のステータスを最終的な不採用状態に変更した日時から推定します。記録応募ステータスが最終的な「不採用」に更新された日時を追跡します。イベントタイプ inferred
	応募の受領	求人への応募案件ごとの開始点です。掲載された求人に候補者が応募すると発生します。候補者の応募がシステムに正常に作成された日時とともに、明示的なイベントとして記録されます。
重要な理由候補者の選考プロセスの起点となるアクティビティです。採用ファネルや候補者体験の分析に欠かせず、応募書類選考のサイクルタイムを測定する開始点になります。入手先 SAP SuccessFactorsにおける求人応募レコードの作成日です。応募ごとに固有のIDが割り当てられ、応募日時が記録されます。記録メインの求人応募エンティティの作成日時を使用します。イベントタイプ explicit
	応募書類の選考	採用担当者または採用マネージャーが候補者の応募書類を初めて確認したことを示します。通常、「新規応募」から「書類選考完了」や「候補者リスト入り」などへのステータス変更から推定します。
重要な理由初回確認の効率を測定します。この段階で遅延が生じると、候補者体験が損なわれ、有望な応募者を逃す可能性があります。入手先求人応募のステータス履歴から推定します。ユーザーが選考後のステータスに変更した日時を記録します。記録応募のステータスが初期状態から選考中または候補者リスト入りの状態に変わった日時を追跡します。イベントタイプ inferred
	求人申請の作成	SAP SuccessFactorsで新しい求人申請が作成されると、採用プロセスが正式に始まります。通常、採用マネージャーまたは採用担当者が求人申請フォームを確定して保存した時点で、このイベントが記録されます。
重要な理由採用までの期間を測定する重要な起点です。このイベントからの経過時間を分析すると、求人の承認や掲載における遅延を特定できます。入手先通常、SAP SuccessFactors Recruiting Managementの求人申請オブジェクトの作成日から取得します。求人申請レコードの作成日時をイベント時刻として使用します。記録求人応募に関連付けられた求人申請レコードの作成日時を使用します。イベントタイプ explicit
	面接の実施	採用チームとの正式な面接が完了したことを示します。通常、面接後に採用担当者または採用マネージャーが候補者の応募ステータスを更新したことから推定します。
重要な理由選考における重要な節目です。面接段階間、および面接からオファーまでの所要時間を分析すると、意思決定のボトルネックを特定できます。入手先求人応募のステータス履歴から推定します。「面接完了」などの値にステータスが更新された日時をイベント時刻として使用します。記録応募ステータスが面接の完了を示す値に更新された日時を特定します。イベントタイプ inferred
	オファー詳細の入力	候補者にオファーを提示する前の、社内での準備・承認ワークフローを示します。オファーの作成中または承認待ちを示すステータス変更から推定します。
重要な理由候補者がオファーを検討する時間と、社内のオファー承認にかかる遅延を切り分けて把握できます。オファー承認のサイクルタイムを分析するうえで重要です。入手先求人応募のステータス履歴、または関連するオファー承認オブジェクトから推定します。「オファー準備中」「オファー承認待ち」などのステータスを確認します。記録応募がオファーの準備中または承認中のステータスに変わった日時を追跡します。イベントタイプ inferred
	オンボーディングの開始	採用プロセスからオンボーディングプロセスへの引き継ぎを示します。候補者がオンボーディングモジュールに移されたとき、またはステータスが「採用準備完了」や「オンボーディング」に更新されたときに記録されます。
重要な理由採用から従業員のオンボーディングへの移行効率を測定します。引き継ぎに時間がかかると、新入社員の体験を損なう可能性があります。入手先通常、候補者データがSAP SuccessFactors Onboardingに移される前の最終的な採用ステータスから推定し、そのステータスが変更された日時を使用します。記録ステータスが「採用準備完了」または「オンボーディング開始」に変わった日時を追跡します。イベントタイプ inferred
	バックグラウンドチェックの開始	オファーを承諾した候補者のバックグラウンドチェックが始まったことを示します。「バックグラウンドチェック中」などへの応募ステータスの変更から推定します。
重要な理由バックグラウンドチェックの開始や完了が遅れると、新入社員の入社日が後ろ倒しになる可能性があります。このアクティビティを追跡すると、オファー後のプロセスを効率化できます。入手先求人応募のステータス履歴から推定します。バックグラウンドチェックの開始を示すステータスに更新された日時を記録します。記録応募ステータスが「バックグラウンドチェック」に変わった日時を特定します。イベントタイプ inferred
	フィードバックの提出	面接担当者が面接後に候補者へのフィードバックを提出したことを示します。フィードバックオブジェクトが別途作成される場合は明示的なイベントとして記録され、応募ステータスの変更を伴う場合はその変更から推定できます。
重要な理由適時のフィードバックは、プロセスのコンプライアンスを守り、採用を迅速に決定するうえで欠かせません。このアクティビティを追跡すると、面接フィードバック提出率を測定できます。入手先応募に関連付けられた面接フィードバックまたは評価オブジェクトに、明示的な日時が記録されている場合があります。記録がない場合は、ステータス変更から推定できます。記録利用できる場合は、面接フィードバックレコードの作成日時を使用します。記録がない場合は、システムの分析が必要です。イベントタイプ explicit
	候補者による辞退	候補者が自ら選考を辞退した場合の、プロセスの不成立を示します。応募ステータスが「候補者による辞退」などに更新されたことから推定します。
重要な理由特定の段階で辞退率が高い場合、候補者体験の悪さ、選考の遅さ、または競争力の低いオファーが原因として考えられます。離脱分析に欠かせない指標です。入手先求人応募のステータス履歴が辞退を示す状態に更新されたことから推定します。この更新日時をイベント時刻として使用します。記録応募ステータスが「辞退」に更新された日時を特定します。イベントタイプ inferred
	求人の掲載	求人申請が公開され、候補者が応募できるようになった時点を示します。多くの場合、求人申請のステータス変更から推定します。社内または社外の採用サイトで求人が有効になったことを示すステータスです。
重要な理由この時点を追跡すると、求人が公開されるまでにかかった社内承認の時間を測定できます。ここでの遅延は、採用までの期間全体や、候補者を速やかに集める能力に大きく影響する可能性があります。入手先求人申請データのステータス変更から推定します。「掲載済み」「募集中」「アクティブ」などのステータスと、そのステータスが初めて設定された日時を確認します。記録求人申請のステータスが、社内または社外への掲載を示す値に変わった日時を特定します。イベントタイプ inferred
	電話面接の実施	候補者との初回電話面接が完了したことを示します。「電話面接合格」や「対面面接へ」など、電話面接の完了を示す値への応募ステータスの変更から推定します。
重要な理由候補者との最初の直接的なやり取りとなることが多く、適性を見極めるうえで重要な段階です。所要時間を分析すると、採用担当者の業務負荷や効率を把握できます。入手先求人応募レコードのステータス変更を追跡して記録します。採用担当者が電話面接後に候補者のステータスを更新した時点でイベントが発生します。記録応募ステータスが電話面接の完了を示す値に更新された日時を特定します。イベントタイプ inferred
	面接の設定	候補者との対面またはオンラインの正式な面接が設定された時点で発生します。日程調整ツールとの連携で明示的に記録する方法と、「面接設定済み」などへのステータス変更から推定する方法があります。
重要な理由候補者と面接担当者の日程調整における遅延を把握できます。日程の確定に時間がかかると、候補者の不満や辞退につながる可能性があります。入手先求人応募オブジェクトのステータス変更から推定します。設定によっては、独自の作成日時を持つ面接オブジェクトが明示的に記録されている場合もあります。記録応募ステータスが「面接設定済み」に変わった日時を使用します。イベントタイプ inferred

推奨任意

データ抽出ガイド

SAP SuccessFactors Recruitingからデータを取得する方法

ステップ

Integration Centerにアクセス：SAP SuccessFactorsの環境にログインします。検索バーからIntegration Center > My Integrationsに移動します。
新しい連携を作成：「Create」をクリックし、「Scheduled Simple File Output Integration」を選択します。
開始エンティティを選択：「Select Entity」の検索ボックスにJobApplicationStatusAuditTrailと入力して選択します。このエンティティにはステータス変更ごとの記録が含まれており、イベントログの基礎となります。
連携に名前を付けて設定：「ProcessMind_Recruitment_Event_Log」など、内容が分かる名前を付けます。「Configure Fields」タブに進みます。
エンティティのフィールドを出力列に割り当て：ここで出力ファイルの構成を作成します。ビジュアルエディターを使い、左側のソースエンティティから右側の出力先列へフィールドをドラッグします。JobApplicationStatusAuditTrailから関連エンティティのjobApplication、jobRequisition、candidateへ移動する必要があります。
アクティビティ用の計算フィールドを作成：多くのアクティビティはステータス変更から導き出します。ActivityNameの計算フィールドを作成し、「If/Then/Else」または「Case」文を使って、監査履歴のstatusId（またはstatusName）をイベントログに必要な標準アクティビティ名に対応付けます（例：statusIdが「123」の場合、Interview Conducted）。具体的な対応付けはクエリのセクションを参照してください。
データを絞り込む：「Filter」タブに移動します。必要なデータだけを抽出し、処理性能を保つため、期間フィルターを追加します。JobApplicationStatusAuditTrailエンティティのcreatedDateTimeフィールドで絞り込みます。初回は過去12か月など、広めの期間を指定できます。2回目以降は、前回の正常終了以降のデータを差分で抽出するように設定します。
出力先を設定：「Destination Settings」タブに移動します。ホストアドレス、ポート、ユーザー認証情報、対象フォルダーのパスなど、SFTPサーバーの情報を入力します。出力ファイル名（例：recruiting_events.csv）を指定します。
連携をスケジュール：「Scheduling」タブで実行頻度を設定します。プロセスマイニングの要件に応じて、毎日または毎週の実行が一般的です。差分抽出の対象期間を過ぎてから実行されるようにスケジュールを設定してください。
確認して実行：「Review and Run」タブに移動し、連携の概要をよく確認します。「Run Now」をクリックすると、連携をテストして最初のファイルをすぐに作成できます。問題がなければ連携を保存すると、設定したスケジュールに従って実行されます。
求人イベントを処理：Job Requisition CreatedとJob Postedのイベントは応募ではなく、求人の属性です。これらのイベントを取得するには、JobRequisitionエンティティとそのステータス監査履歴を開始点とする、同様の連携をもう1つ作成します。ProcessMindにアップロードする前に、2つの連携で出力したファイルを結合します。
アップロードの準備：結合後のCSVファイルで、ヘッダー（CaseId、ActivityName、EventTimestampなど）が正しく設定され、タイムスタンプの形式が統一されていることを確認します。これでファイルをProcessMindにアップロードできます。

設定

連携タイプ：Scheduled Simple File Output Integration。設定したスケジュールに従ってCSVファイルを作成します。
主な開始エンティティ：JobApplicationStatusAuditTrail。求人応募ごとのステータス変更をタイムスタンプ付きで記録するため、イベントログの作成に適しています。
副次的な開始エンティティ：求人レベルの「Job Posted」などのイベントを取得するには、別の連携でJobReqStatusAuditTrail（または求人のステータス変更を記録する同等のエンティティ）が必要です。
主な関連エンティティ：必要な属性をすべて取得するには、開始エンティティからJobApplication、JobRequisition、Candidate、およびRecruiterとHiringManagerのユーザーエンティティに移動します。
フィルター方法：差分ロード方式を使うことが重要です。JobApplicationStatusAuditTrailエンティティのcreatedDateTimeフィールドで絞り込み、前回の正常終了以降に作成されたレコードだけを取得します。これにより、履歴全体の再エクスポートを防ぎ、処理性能を高められます。
期間：初回の履歴データのロードでは、分析に適した期間（過去6～12か月など）を指定します。2回目以降の差分ロードでは、「前回の正常終了時刻」などに基づいて動的に絞り込みます。
前提条件：連携を設定するユーザーには、Integration Centerの管理者権限と、Recruiting関連の必要なOData APIエンティティ（JobApplication、JobRequisition、Candidateなど）の読み取り権限が必要です。また、SFTPサーバーとその認証情報へのアクセスも必要です。

クエリの例 sql

/*
This is a configuration reference for the Integration Center, not an executable script.
It details the mapping from SAP SuccessFactors OData entities to the target CSV file columns.
Two separate integrations are required and their outputs must be merged.
*/

-- Integration 1: Job Application Events
-- Starting Entity: JobApplicationStatusAuditTrail

-- Field Mappings:
"JobApplication" -> jobApplication/applicationId
"ActivityName" -> [Calculated Field] Based on jobApplication/statusId. Logic:
  CASE jobApplication/statusId:
    WHEN '[Status ID for New Application]' THEN 'Application Received'
    WHEN '[Status ID for Screened]' THEN 'Application Screened'
    WHEN '[Status ID for Phone Screen]' THEN 'Phone Screen Conducted'
    WHEN '[Status ID for Interview Scheduled]' THEN 'Interview Scheduled'
    WHEN '[Status ID for Interview Conducted]' THEN 'Interview Conducted'
    WHEN '[Status ID for Interview Feedback]' THEN 'Feedback Submitted'
    WHEN '[Status ID for Offer Preparation]' THEN 'Offer Details Entered'
    WHEN '[Status ID for Offer Extended]' THEN 'Offer Extended'
    WHEN '[Status ID for Offer Accepted]' THEN 'Offer Accepted'
    WHEN '[Status ID for Background Check]' THEN 'Background Check Initiated'
    WHEN '[Status ID for Onboarding]' THEN 'Onboarding Initiated'
    WHEN '[Status ID for Hired]' THEN 'Candidate Hired'
    WHEN '[Status ID for Rejected]' THEN 'Application Rejected'
    WHEN '[Status ID for Withdrawn]' THEN 'Candidate Withdrew'
    ELSE jobApplication/appStatusSetItem/statusName
  END
"EventTimestamp" -> createdDateTime
"JobRequisitionId" -> jobApplication/jobRequisition/jobReqId
"CandidateId" -> jobApplication/candidate/candidateId
"JobTitle" -> jobApplication/jobRequisition/jobTitle
"Department" -> jobApplication/jobRequisition/department
"Recruiter" -> jobApplication/jobRequisition/recruiter/userId
"HiringManager" -> jobApplication/jobRequisition/hiringManager/userId
"ApplicationStatus" -> jobApplication/appStatusSetItem/statusName
"ApplicationSource" -> jobApplication/source

-- Integration 2: Job Requisition Events
-- Starting Entity: JobRequisition

-- Field Mappings (Row 1 for Job Requisition Created):
"JobApplication" -> jobReqId -- Note: Requisition ID is used as the key here for merging purposes
"ActivityName" -> 'Job Requisition Created'
"EventTimestamp" -> createdDate
"JobRequisitionId" -> jobReqId
"CandidateId" -> NULL
"JobTitle" -> jobTitle
"Department" -> department
"Recruiter" -> recruiter/userId
"HiringManager" -> hiringManager/userId
"ApplicationStatus" -> NULL
"ApplicationSource" -> NULL

-- Field Mappings (Additional rows for Job Posted from a Requisition Audit Trail entity):
-- Note: This requires a third integration starting from the Requisition Status Audit Trail, if available, or a different approach.
-- Assuming a status field on the JobRequisition entity indicates the posting date.
"JobApplication" -> jobReqId
"ActivityName" -> 'Job Posted'
"EventTimestamp" -> [Date field indicating when requisition was posted]
"JobRequisitionId" -> jobReqId
"CandidateId" -> NULL
"JobTitle" -> jobTitle
"Department" -> department
"Recruiter" -> recruiter/userId
"HiringManager" -> hiringManager/userId
"ApplicationStatus" -> NULL
"ApplicationSource" -> NULL

ステップ

前提条件と認証：必要なODataエンティティへのAPIアクセス権を持つSAP SuccessFactorsユーザーを用意します。Admin Centerの「Manage Permission Roles」で設定してください。API認証用のOAuth 2.0クライアント認証情報を作成します。Client ID、Client Secret、Company ID、およびデータセンターに対応するAPIサーバーURLが必要です。
ODataエンティティを確認：SuccessFactors OData V2 APIの主要なエンティティを確認します。抽出元となる主なエンティティはJobApplication、JobApplicationStatusAuditTrail、JobRequisitionです。Admin Centerの「OData API Data Dictionary」で、各エンティティの利用可能なフィールドを確認してください。
抽出スクリプトを設定：提供されたPythonスクリプトを開発環境にコピーします。requestsとpandasライブラリをインストールしてください（pip install requests pandas）。
スクリプトのパラメーターを設定：スクリプト内のプレースホルダー変数を、使用するSuccessFactors APIの認証情報、会社ID、APIサーバーURLに置き換えます。START_DATEとEND_DATEの変数を設定し、抽出期間を指定します。
ステータスの対応付けを設定：スクリプト内のSTATUS_TO_ACTIVITY_MAPPING辞書を確認します。ここが最も重要な設定です。使用中のSuccessFactors環境のステータス名を、イベントログに必要な標準アクティビティ名に対応付けます。スクリプトには一般的な例が含まれていますが、実際のシステム設定とは異なる場合があります。
スクリプトを実行：Pythonスクリプトを実行します。API認証後、JobApplicationとJobApplicationStatusAuditTrailのエンドポイントからページ単位でデータを取得し、応答を処理します。
求人レベルのイベントを処理：スクリプトは、指定期間内の求人応募をすべて取得します。各応募について、関連する求人のデータに基づき、「Job Requisition Created」と「Job Posted」のイベントを自動的に作成します。
応募レベルのイベントを処理：続いて、各応募の監査履歴を取得します。設定した対応付けに基づいてステータス変更をアクティビティの行に変換します。例：「Application Screened」、「Interview Conducted」、「Offer Extended」。
データを結合して整形：スクリプトは、作成した求人レベルと応募レベルのイベントを1つのリストにまとめます。
イベントログを作成：最後に、結合したデータをpandasのDataFrameに変換し、sfsf_recruiting_event_log.csvという名前のCSVファイルに保存します。ファイルにはJobApplication、ActivityName、EventTimestampなど、必要な列と推奨される属性が含まれます。
確認してアップロード：作成したCSVファイルを開き、データを検証します。確認後、ProcessMindにアップロードして分析できます。

設定

APIエンドポイント：OData V2 APIのベースURLはSuccessFactorsのデータセンターごとに異なります。例：https://api4.successfactors.com/odata/v2。
主なODataエンティティ：抽出では主にJobApplication（基本となるケースと関連オブジェクトの取得）とJobApplicationStatusAuditTrail（イベント履歴の取得）を使います。データを補うため、JobRequisition、Candidate、Recruiter、HiringManagerなどの関連エンティティも展開します。
認証：スクリプトはサーバー間認証にOAuth 2.0のクライアント認証情報を使います。SuccessFactors OAuth Managerに登録済みの有効なClient IDとClient Secretが必要です。
期間：スクリプトは求人応募の作成日（createdDateTime）で絞り込みます。データ量とAPIの応答時間を抑えるため、最初は3～6か月など、短い期間から始めることをおすすめします。例：$filter=createdDateTime ge 2023-01-01T00:00:00Z。
ステータスの対応付け：会社固有の応募ステータス（例：「Initial Review」、「First Interview」）を、必要な標準アクティビティ（例：「Application Screened」、「Interview Conducted」）に対応付ける設定が重要です。この対応付けはスクリプト内のPython辞書で定義し、実際の環境に合わせて調整する必要があります。
APIのページング：APIの応答に含まれる__nextリンクをたどり、サーバー側のページングを自動処理します。これにより、指定期間内のすべてのレコードを取得できます。
必要な権限：APIユーザーには、ロールベース権限（RBP）でJobApplication、JobApplicationStatusAuditTrail、JobRequisition、Candidateエンティティ、およびスクリプトで選択するすべてのフィールドへの読み取りアクセスを付与する必要があります。

クエリの例 graphql

import requests
import pandas as pd
import datetime

# --- Configuration --- #
# Replace with your SuccessFactors API details
API_SERVER_URL = "https://[api_server_url].successfactors.com"
COMPANY_ID = "[Your_Company_ID]"
CLIENT_ID = "[Your_Client_ID]"
CLIENT_SECRET = "[Your_Client_Secret]"

# Date range for the extraction (ISO 8601 format)
START_DATE = "2023-01-01T00:00:00Z"
END_DATE = "2023-12-31T23:59:59Z"

# --- CRITICAL: Customize this mapping for your instance --- #
# Map your specific SuccessFactors status names to the standard activity names
STATUS_TO_ACTIVITY_MAPPING = {
    "Screening": "Application Screened",
    "Phone Screen": "Phone Screen Conducted",
    "Interview": "Interview Conducted",
    "Offer": "Offer Details Entered",
    "Offer Extended": "Offer Extended",
    "Offer Accepted": "Offer Accepted",
    "Background Check": "Background Check Initiated",
    "Ready to Hire": "Onboarding Initiated",
    "Hired": "Candidate Hired",
    "Rejected": "Application Rejected",
    "Withdrawn by candidate": "Candidate Withdrew"
    # Add other status mappings as needed, e.g., 'Interview Scheduled', 'Feedback Submitted'
}

# --- Helper Functions --- #
def get_oauth_token():
    """Authenticates and retrieves an OAuth 2.0 access token."""
    token_url = f"{API_SERVER_URL}/oauth/token"
    payload = {
        "client_id": CLIENT_ID,
        "client_secret": CLIENT_SECRET,
        "grant_type": "client_credentials",
        "company_id": COMPANY_ID
    }
    response = requests.post(token_url, data=payload)
    response.raise_for_status()
    return response.json()["access_token"]

def fetch_all_pages(url, headers):
    """Fetches data from a paginated OData endpoint."""
    results = []
    while url:
        response = requests.get(url, headers=headers)
        response.raise_for_status()
        data = response.json()["d"]
        results.extend(data.get("results", [data])) # Handle single vs. multiple results
        url = data.get("__next")
    return results

# --- Main Extraction Logic --- #
def main():
    print("Starting SuccessFactors data extraction...")
    try:
        token = get_oauth_token()
        headers = {"Authorization": f"Bearer {token}", "Accept": "application/json"}
    except requests.exceptions.RequestException as e:
        print(f"Error obtaining OAuth token: {e}")
        return

    event_log = []
    
    # 1. Fetch Job Applications within the date range
    print(f"Fetching job applications created between {START_DATE} and {END_DATE}...")
    job_app_fields = "appStatusSetId,applicationId,source,jobReqId,candidate/candidateId,jobRequisition/jobReqId,jobRequisition/jobTitle,jobRequisition/department,jobRequisition/recruiterUser/defaultFullName,jobRequisition/hiringManagerUser/defaultFullName,jobRequisition/creationDate,jobRequisition/postedDate,creationDate,status/statusName"
    job_app_expand = "candidate,jobRequisition,jobRequisition/recruiterUser,jobRequisition/hiringManagerUser,status"
    job_app_filter = f"creationDate ge datetime'{START_DATE.replace('Z', '')}' and creationDate le datetime'{END_DATE.replace('Z', '')}'"
    job_app_url = f"{API_SERVER_URL}/odata/v2/JobApplication?$format=json&$select={job_app_fields}&$expand={job_app_expand}&$filter={job_app_filter}"

    try:
        applications = fetch_all_pages(job_app_url, headers)
        print(f"Found {len(applications)} applications.")
    except requests.exceptions.RequestException as e:
        print(f"Error fetching job applications: {e}")
        return

    # 2. Process each application and its audit trail
    for i, app in enumerate(applications):
        if (i + 1) % 50 == 0:
            print(f"Processing application {i + 1}/{len(applications)}...")
        
        # Common attributes
        job_req = app.get("jobRequisition", {})
        candidate = app.get("candidate", {})
        
        base_attributes = {
            "JobApplication": app.get("applicationId"),
            "JobRequisitionId": job_req.get("jobReqId"),
            "CandidateId": candidate.get("candidateId"),
            "JobTitle": job_req.get("jobTitle"),
            "Department": job_req.get("department"),
            "Recruiter": job_req.get("recruiterUser", {}).get("defaultFullName"),
            "HiringManager": job_req.get("hiringManagerUser", {}).get("defaultFullName"),
            "ApplicationSource": app.get("source"),
            "ApplicationStatus": app.get("status", {}).get("statusName")
        }

        # Add Requisition and Application creation events
        if job_req.get("creationDate"):
            event_log.append({**base_attributes, "ActivityName": "Job Requisition Created", "EventTimestamp": job_req["creationDate"]})
        if job_req.get("postedDate"): # Note: postedDate might not be enabled
            event_log.append({**base_attributes, "ActivityName": "Job Posted", "EventTimestamp": job_req["postedDate"]})
        if app.get("creationDate"):
            event_log.append({**base_attributes, "ActivityName": "Application Received", "EventTimestamp": app["creationDate"]})
        
        # 3. Fetch Status Audit Trail for the current application
        audit_trail_url = f"{API_SERVER_URL}/odata/v2/JobApplication({app['applicationId']}L)/appStatusTrail?$format=json"
        try:
            audit_trail_items = fetch_all_pages(audit_trail_url, headers)
            for item in audit_trail_items:
                status_name = item.get("statusName")
                if status_name in STATUS_TO_ACTIVITY_MAPPING:
                    activity_name = STATUS_TO_ACTIVITY_MAPPING[status_name]
                    event_log.append({**base_attributes, "ActivityName": activity_name, "EventTimestamp": item.get("createdDate")})
        except requests.exceptions.RequestException as e:
            print(f"Could not fetch audit trail for application {app['applicationId']}: {e}")
            continue

    # 4. Create and save DataFrame
    if not event_log:
        print("No events were generated. Check your date range and status mappings.")
        return
    
    df = pd.DataFrame(event_log)
    # Reorder columns for clarity
    cols = ["JobApplication", "ActivityName", "EventTimestamp", "JobRequisitionId", "CandidateId", "JobTitle", 
            "Department", "Recruiter", "HiringManager", "ApplicationStatus", "ApplicationSource"]
    df = df[cols]
    
    # Convert timestamp format
    df['EventTimestamp'] = pd.to_datetime(df['EventTimestamp'], format='/Date(%f%z)/')
    df = df.sort_values(by=["JobApplication", "EventTimestamp"])

    output_filename = 'sfsf_recruiting_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(f"Extraction complete. Event log saved to {output_filename}")

if __name__ == "__main__":
    main()

ステップ

前提条件：SuccessFactorsでAPIユーザーを設定
- 管理者権限でSAP SuccessFactorsの環境にログインします。
- Admin Centerに移動し、検索機能で「Manage OAuth2 Client Applications」を探します。
- 新しいクライアントアプリケーションを登録します。X.509証明書を作成して公開鍵をアップロードします。生成されたAPI Key（Client ID）を控えておきます。
- 「Manage Permission Roles」に移動し、APIユーザー用の新しいロールを作成します。
- 「Manage Integration Tools」で、「OData API Basic Authentication」と「OAuth 2.0 API access」のロールを付与します。
- 「Recruiting Permissions」で、JobApplication、JobRequisition、JobApplicationStatusAuditTrail、ユーザーなどのエンティティ、および属性の補完に必要なその他のエンティティ（例：部門）への読み取りアクセスをロールに付与します。必要なすべての属性について、フィールドレベルの表示権限も設定してください。
- 「Manage Employees」から専用のAPIユーザーを作成し、新しく作成した権限ロールを割り当てます。
ローカルのPython環境を設定
- Python 3.7以降がインストールされていることを確認します。
- ターミナルまたはコマンドプロンプトを開き、次のコマンドを実行して必要なPythonライブラリをインストールします：pip install requests pandas cryptography。
Pythonスクリプトを設定
- 提供されたPythonコードをextract_sfsf_recruiting.pyという名前のファイルに保存します。
- ファイルを開き、先頭にある設定セクションを探します。
- SuccessFactors APIの情報を入力します：SF_API_CENTER_URL、SF_COMPANY_ID、SF_CLIENT_ID、SF_USER_ID。
- 手順1で作成した秘密鍵ファイルのパスを、SF_PRIVATE_KEY_PATH変数に指定します。
- データの抽出期間として、START_DATEとEND_DATEを設定します。
ステータスの対応付けを設定
- スクリプト内でSTATUS_TO_ACTIVITY_MAPPING辞書を探します。
- ここが最も重要な手順です。SuccessFactors Recruiting環境で使われている正確なステータス名を、イベントログに必要な標準アクティビティ名に対応付けます。
- SuccessFactorsの管理者に、応募ステータスの一覧を確認し、正しく対応付けてください。対応付けが正しくないと、アクティビティが欠落したり、誤った名前で表示されたりします。
抽出スクリプトを実行
- ターミナルまたはコマンドプロンプトを開き、スクリプトを保存したディレクトリに移動します。
- 次のコマンドでスクリプトを実行します：python extract_sfsf_recruiting.py。
- スクリプトはAPI認証後、求人と応募ステータス変更のデータをページ単位で取得して処理し、進行状況をコンソールに表示します。
イベントログを確認してアップロード
- スクリプトの実行が完了すると、同じディレクトリにsfsf_recruiting_event_log.csvというCSVファイルが作成されます。
- 表計算ソフトでCSVファイルを開き、検証手順に従ってデータの完全性と正確性を確認します。
- ファイルをProcessMindにアップロードできます。列名は必要なスキーマ（JobApplication、ActivityName、EventTimestampなど）に合わせて設定済みです。

設定

API認証情報：スクリプトでOAuth 2.0認証を行うには、API Center URL、Company ID、Client ID、APIユーザーID、秘密鍵ファイルのパスなどが必要です。
期間：START_DATEとEND_DATEの変数で抽出期間を指定します。初回の分析では、プロセスのバリアントを十分に把握できるよう、6～12か月の期間をおすすめします。
ステータスとアクティビティの対応付け：STATUS_TO_ACTIVITY_MAPPING辞書は重要な設定項目です。会社独自の応募ステータスを標準アクティビティ名に正確に対応付けてください。
エンティティの権限：APIユーザーには、主にJobRequisition、JobApplication、JobApplicationStatusAuditTrailなど、複数のODataエンティティへの読み取り権限が必要です。採用担当者や採用マネージャーの名前を取得するには、ユーザーなどのエンティティに対する追加権限も必要です。
ページサイズ：PAGE_SIZE変数で、API呼び出しごとに取得するレコード数を指定します。通常はデフォルトの1000件で効率よく処理できますが、エンティティのスキーマが非常に広く、APIがタイムアウトする場合は、件数を減らす必要があります。

クエリの例 python

import requests
import pandas as pd
import json
from datetime import datetime, timedelta
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.primitives.asymmetric import rsa
import base64
import time

class=class="hl-string">"hl-comment"># --- CONFIGURATION SECTION --- 
class=class="hl-string">"hl-comment"># Replace with your SAP SuccessFactors API details
SF_API_CENTER_URL = class="hl-string">"[Your SuccessFactors API Server URL, e.g., https://apiX.successfactors.com]"
SF_COMPANY_ID = class="hl-string">"[Your Company ID]"
SF_CLIENT_ID = class="hl-string">"[Your OAuth Client ID / API Key]"
SF_USER_ID = class="hl-string">"[Your API User ID]"
SF_PRIVATE_KEY_PATH = class="hl-string">"[Path to your private key .pem file]"

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># Page size for API calls
PAGE_SIZE = 1000

class=class="hl-string">"hl-comment"># CRITICAL: Map your specific SF status names to standard activity names.
class=class="hl-string">"hl-comment"># Work with an SF admin to get the exact status names from your instance.
STATUS_TO_ACTIVITY_MAPPING = {
    class="hl-string">"New Application": class="hl-string">"Application Received",
    class="hl-string">"Screen": class="hl-string">"Application Screened",
    class="hl-string">"Phone Screen": class="hl-string">"Phone Screen Conducted",
    class="hl-string">"Interview": class="hl-string">"Interview Conducted",
    class="hl-string">"Offer": class="hl-string">"Offer Details Entered",
    class="hl-string">"Offer Extended": class="hl-string">"Offer Extended",
    class="hl-string">"Offer Accepted": class="hl-string">"Offer Accepted",
    class="hl-string">"Background Check": class="hl-string">"Background Check Initiated",
    class="hl-string">"Ready to Hire": class="hl-string">"Onboarding Initiated",
    class="hl-string">"Hired": class="hl-string">"Candidate Hired",
    class="hl-string">"Rejected": class="hl-string">"Application Rejected",
    class="hl-string">"Withdrawn by Candidate": class="hl-string">"Candidate Withdrew"
    class=class="hl-string">"hl-comment"># Add other custom statuses here, e.g.:
    class=class="hl-string">"hl-comment"># class="hl-string">"Interview Scheduled": class="hl-string">"Interview Scheduled",
    class=class="hl-string">"hl-comment"># class="hl-string">"Interviewer Feedback Submitted": class="hl-string">"Feedback Submitted"
}

def get_access_token():
    class="hl-string">"""Generates a JWT and exchanges it for an OAuth 2.0 access token."""
    try:
        with open(SF_PRIVATE_KEY_PATH, class="hl-string">"rb") as key_file:
            private_key = serialization.load_pem_private_key(
                key_file.read(),
                password=None,
            )
    except Exception as e:
        print(fclass="hl-string">"Error reading private key: {e}")
        return None

    class=class="hl-string">"hl-comment"># Create assertion
    assertion_payload = {
        class="hl-string">"iss": SF_CLIENT_ID,
        class="hl-string">"sub": SF_USER_ID,
        class="hl-string">"aud": class="hl-string">"www.successfactors.com",
        class="hl-string">"exp": int(time.time()) + 300 class=class="hl-string">"hl-comment"># 5 minute expiry
    }
    
    class=class="hl-string">"hl-comment"># This part requires the class="hl-string">'PyJWT' library if you want to create a JWT.
    class=class="hl-string">"hl-comment"># For simplicity, we assume the user might use a different library or method.
    class=class="hl-string">"hl-comment"># As a fallback, this example shows a conceptual SAML assertion structure.
    class=class="hl-string">"hl-comment"># In a real scenario, a library like `PyJWT` or `Authlib` would be used.
    class=class="hl-string">"hl-comment"># We'll use a simplified placeholder for the assertion generation logic.
    class=class="hl-string">"hl-comment"># For this example to work, you'd need to implement proper JWT signing.
    class=class="hl-string">"hl-comment"># The below is a placeholder and will not work without a signing library.
    class=class="hl-string">"hl-comment"># Weclass="hl-string">'ll mock the assertion for this script's structure.
    
    class=class="hl-string">"hl-comment"># For a real implementation, you would use a library to sign the assertion.
    class=class="hl-string">"hl-comment"># Let's assume we have a signed assertion string.
    class=class="hl-string">"hl-comment"># For this example, we'll proceed as if `signed_assertion` is correctly generated.
    class=class="hl-string">"hl-comment"># signed_assertion = jwt.encode(assertion_payload, private_key, algorithm=class="hl-string">'RS256')
    class=class="hl-string">"hl-comment"># Since we can't sign it here without more libraries, we will skip to the request part.

    token_url = fclass="hl-string">"{SF_API_CENTER_URL}/oauth/token"
    headers = {class="hl-string">"Content-Type": class="hl-string">"application/x-www-form-urlencoded"}
    
    class=class="hl-string">"hl-comment"># The grant_type must be urn:ietf:params:oauth:grant-type:saml2-bearer
    class=class="hl-string">"hl-comment"># You would need to URL-encode a properly signed SAML or JWT assertion.
    class=class="hl-string">"hl-comment"># This step is highly dependent on your specific SF setup (SAML vs JWT assertion).
    class=class="hl-string">"hl-comment"># We will simulate the request conceptually.
    print(class="hl-string">"Requesting access token. Note: Assertion signing is required for a live environment.")
    
    class=class="hl-string">"hl-comment"># This is a simplified payload. A real assertion is needed for the `assertion` field.
    class=class="hl-string">"hl-comment"># You must generate this assertion and sign it with your private key.
    payload = {
        class="hl-string">'grant_type': class="hl-string">'urn:ietf:params:oauth:grant-type:saml2-bearer',
        class="hl-string">'company_id': SF_COMPANY_ID,
        class="hl-string">'client_id': SF_CLIENT_ID,
        class="hl-string">'assertion': class="hl-string">'[A correctly signed SAML/JWT assertion goes here]'
    }

    class=class="hl-string">"hl-comment"># A note to the user that this part needs to be implemented.
    print(class="hl-string">"\n*** ACTION REQUIRED ***")
    print(class="hl-string">"The following API call for an access token is a placeholder.")
    print(class="hl-string">"You must replace the 'assertion' value with a real, signed SAML/JWT assertion.")
    print(class="hl-string">"See SAP SuccessFactors documentation for OAuth 2.0 authentication.")
    print(class="hl-string">"**********************\n")
    
    class=class="hl-string">"hl-comment"># As we cannot generate a real token here, we return a placeholder.
    class=class="hl-string">"hl-comment"># In your real script, you would make the request and return the token.
    class=class="hl-string">"hl-comment"># response = requests.post(token_url, headers=headers, data=payload)
    class=class="hl-string">"hl-comment"># if response.status_code == 200:
    class=class="hl-string">"hl-comment">#     return response.json().get(class="hl-string">'access_token')
    class=class="hl-string">"hl-comment"># else:
    class=class="hl-string">"hl-comment">#     print(fclass="hl-string">"Error getting token: {response.status_code} {response.text}")
    class=class="hl-string">"hl-comment">#     return None
    return class="hl-string">"[Your_Generated_Access_Token]" class=class="hl-string">"hl-comment"># Replace this with the actual token retrieval logic


def fetch_all_pages(url, headers):
    class="hl-string">"""Fetches all pages of data from a paginated OData endpoint."""
    all_results = []
    while url:
        try:
            response = requests.get(url, headers=headers)
            response.raise_for_status()
            data = response.json()
            all_results.extend(data.get(class="hl-string">'d', {}).get(class="hl-string">'results', []))
            class=class="hl-string">"hl-comment"># SuccessFactors uses __next for the next page link
            url = data.get(class="hl-string">'d', {}).get(class="hl-string">'__next', None)
            if url:
                print(fclass="hl-string">"Fetching next page...")
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"API request failed: {e}")
            break
    return all_results

def main():
    class="hl-string">"""Main function to extract, transform, and save the data."""
    access_token = get_access_token()
    if not access_token or access_token == class="hl-string">"[Your_Generated_Access_Token]":
        print(class="hl-string">"Could not obtain access token. Please check your configuration and assertion logic.")
        return

    headers = {
        class="hl-string">"Authorization": fclass="hl-string">"Bearer {access_token}",
        class="hl-string">"Accept": class="hl-string">"application/json"
    }

    class=class="hl-string">"hl-comment"># 1. Fetch Job Requisition Data for class="hl-string">'Created' and class="hl-string">'Posted' events
    print(class="hl-string">"Fetching Job Requisition data...")
    req_filter = fclass="hl-string">"createdDate ge datetime'{START_DATE}T00:00:00Z' and createdDate le datetime'{END_DATE}T23:59:59Z'"
    req_url = fclass="hl-string">"{SF_API_CENTER_URL}/odata/v2/JobRequisition?$format=json&$filter={req_filter}&$select=jobReqId,createdDateTime,jobTitle,department,recruiter/userId,recruiter/defaultFullName,hiringManager/userId,hiringManager/defaultFullName,status&$expand=recruiter,hiringManager&$top={PAGE_SIZE}"
    requisitions_data = fetch_all_pages(req_url, headers)
    
    req_events = []
    for req in requisitions_data:
        class=class="hl-string">"hl-comment"># Event: Job Requisition Created
        req_events.append({
            class="hl-string">'JobApplication': fclass="hl-string">"REQ-{req['jobReqId']}",  class=class="hl-string">"hl-comment"># Use req id as case for these events
            class="hl-string">'ActivityName': class="hl-string">'Job Requisition Created',
            class="hl-string">'EventTimestamp': req[class="hl-string">'createdDateTime'],
            class="hl-string">'JobRequisitionId': req[class="hl-string">'jobReqId'],
            class="hl-string">'CandidateId': None,
            class="hl-string">'JobTitle': req[class="hl-string">'jobTitle'],
            class="hl-string">'Department': req.get(class="hl-string">'department'),
            class="hl-string">'Recruiter': req.get(class="hl-string">'recruiter', {}).get(class="hl-string">'defaultFullName'),
            class="hl-string">'HiringManager': req.get(class="hl-string">'hiringManager', {}).get(class="hl-string">'defaultFullName'),
            class="hl-string">'ApplicationStatus': req[class="hl-string">'status'],
            class="hl-string">'ApplicationSource': None
        })
        class=class="hl-string">"hl-comment"># Event: Job Posted (inferred from status, this may need adjustment)
        if req[class="hl-string">'status'] == class="hl-string">'Posted': class=class="hl-string">"hl-comment"># This status name is an assumption
            req_events.append({
                class="hl-string">'JobApplication': fclass="hl-string">"REQ-{req['jobReqId']}",
                class="hl-string">'ActivityName': class="hl-string">'Job Posted',
                 class=class="hl-string">"hl-comment"># Using createdDateTime as a proxy; lastModifiedDateTime would be better if available
                class="hl-string">'EventTimestamp': req[class="hl-string">'createdDateTime'], 
                class="hl-string">'JobRequisitionId': req[class="hl-string">'jobReqId'],
                class="hl-string">'CandidateId': None,
                class="hl-string">'JobTitle': req[class="hl-string">'jobTitle'],
                class="hl-string">'Department': req.get(class="hl-string">'department'),
                class="hl-string">'Recruiter': req.get(class="hl-string">'recruiter', {}).get(class="hl-string">'defaultFullName'),
                class="hl-string">'HiringManager': req.get(class="hl-string">'hiringManager', {}).get(class="hl-string">'defaultFullName'),
                class="hl-string">'ApplicationStatus': req[class="hl-string">'status'],
                class="hl-string">'ApplicationSource': None
            })

    df_req_events = pd.DataFrame(req_events)
    print(fclass="hl-string">"Processed {len(df_req_events)} job requisition events.")

    class=class="hl-string">"hl-comment"># 2. Fetch Job Application Status Audit Trail Data
    print(class="hl-string">"\nFetching Job Application status audit trail data...")
    audit_filter = fclass="hl-string">"createdDate ge datetime'{START_DATE}T00:00:00Z' and createdDate le datetime'{END_DATE}T23:59:59Z'"
    audit_select = class="hl-string">"jobApplication/appId,jobApplication/jobReqId,jobApplication/candidate/candidateId,jobApplication/source,jobApplication/status,jobApplication/jobRequisition/jobTitle,jobApplication/jobRequisition/department,jobApplication/jobRequisition/recruiter/defaultFullName,jobApplication/jobRequisition/hiringManager/defaultFullName,status,createdDate"
    audit_expand = class="hl-string">"jobApplication,jobApplication/candidate,jobApplication/jobRequisition,jobApplication/jobRequisition/recruiter,jobApplication/jobRequisition/hiringManager"
    audit_url = fclass="hl-string">"{SF_API_CENTER_URL}/odata/v2/JobApplicationStatusAuditTrail?$format=json&$filter={audit_filter}&$select={audit_select}&$expand={audit_expand}&$top={PAGE_SIZE}"
    
    audit_data = fetch_all_pages(audit_url, headers)
    
    app_events = []
    for item in audit_data:
        app_info = item.get(class="hl-string">'jobApplication')
        if not app_info: continue

        activity_name = STATUS_TO_ACTIVITY_MAPPING.get(item.get(class="hl-string">'status'), None)
        if not activity_name: continue class=class="hl-string">"hl-comment"># Skip statuses not in our mapping

        app_events.append({
            class="hl-string">'JobApplication': app_info.get(class="hl-string">'appId'),
            class="hl-string">'ActivityName': activity_name,
            class="hl-string">'EventTimestamp': item.get(class="hl-string">'createdDate'),
            class="hl-string">'JobRequisitionId': app_info.get(class="hl-string">'jobReqId'),
            class="hl-string">'CandidateId': app_info.get(class="hl-string">'candidate', {}).get(class="hl-string">'candidateId'),
            class="hl-string">'JobTitle': app_info.get(class="hl-string">'jobRequisition', {}).get(class="hl-string">'jobTitle'),
            class="hl-string">'Department': app_info.get(class="hl-string">'jobRequisition', {}).get(class="hl-string">'department'),
            class="hl-string">'Recruiter': app_info.get(class="hl-string">'jobRequisition', {}).get(class="hl-string">'recruiter', {}).get(class="hl-string">'defaultFullName'),
            class="hl-string">'HiringManager': app_info.get(class="hl-string">'jobRequisition', {}).get(class="hl-string">'hiringManager', {}).get(class="hl-string">'defaultFullName'),
            class="hl-string">'ApplicationStatus': app_info.get(class="hl-string">'status'),
            class="hl-string">'ApplicationSource': app_info.get(class="hl-string">'source')
        })

    df_app_events = pd.DataFrame(app_events)
    print(fclass="hl-string">"Processed {len(df_app_events)} application status events.")

    class=class="hl-string">"hl-comment"># 3. Combine, Clean, and Export
    if df_app_events.empty and df_req_events.empty:
        print(class="hl-string">"No data extracted. Please check your date range and API permissions.")
        return

    final_df = pd.concat([df_req_events, df_app_events], ignore_index=True)
    final_df = final_df.sort_values(by=[class="hl-string">'JobApplication', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    
    class=class="hl-string">"hl-comment"># Convert timestamp string to datetime object and format it
    class=class="hl-string">"hl-comment"># Example SF format: /Date(1672531200000+0000)/
    final_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(final_df[class="hl-string">'EventTimestamp'].str.extract(rclass="hl-string">'(\d+)')[0], unit=class="hl-string">'ms')
    final_df[class="hl-string">'EventTimestamp'] = final_df[class="hl-string">'EventTimestamp'].dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')

    class=class="hl-string">"hl-comment"># Rename columns for ProcessMind
    final_df.rename(columns={class="hl-string">'JobRequisitionId': class="hl-string">'Job Requisition ID'}, inplace=True)

    output_filename = class="hl-string">'sfsf_recruiting_event_log.csv'
    final_df.to_csv(output_filename, index=False, encoding=class="hl-string">'utf-8')
    print(fclass="hl-string">"\nExtraction complete. Event log saved to {output_filename}")

if __name__ == class="hl-string">"__main__":
    main()

始める準備はできていますか？

このテンプレートを使ってデータを準備し、今日から採用プロセスの改善に取り組みましょう。インサイトを得て、採用業務の効率化につなげられます。

改善ガイドに戻る

テンプレートをダウンロード

SAP SuccessFactorsの採用プロセスを今すぐ改善

非効率を特定してボトルネックを解消し、採用サイクルタイムを30％短縮します。

無料トライアルを開始しましょう

クレジットカードは不要です。14日間無料でお試しいただけます。

採用・人材獲得のデータテンプレート

採用・人材獲得のデータテンプレート

採用・人材獲得の属性

採用・人材獲得のアクティビティ

データ抽出ガイド

SAP SuccessFactors Integration Centerでの求人データのエクスポート

ステップ

設定

クエリの例 sql

応募データを取得するSAP SuccessFactors OData APIクエリ

ステップ

設定

クエリの例 graphql

OData APIを使ったPythonスクリプトによる全データ抽出

ステップ

設定

クエリの例 python

始める準備はできていますか？

SAP SuccessFactorsの採用プロセスを今すぐ改善