> 継続的なプロセス改善 > 採用から退職までの従業員ライフサイクル > Workday Onboarding > データテンプレート

採用から退職まで：従業員ライフサイクルのデータテンプレート

Workday Onboarding

採用から退職まで：従業員ライフサイクルの属性(21) 採用から退職まで：従業員ライフサイクルのアクティビティ(15) データ抽出ガイド(2)

採用から退職まで：従業員ライフサイクルのデータテンプレート

このテンプレートでは、採用から退職までのプロセスを効果的に分析するために必要なデータ属性とアクティビティを確認できます。イベントログの作成に必要な情報を特定し、従業員ライフサイクルを正確に分析するのに役立ちます。また、Workdayのオンボーディングからデータを抽出する方法もご案内します。

詳細な分析に必要な属性
従業員ライフサイクルを通じて記録する主要なアクティビティ
Workdayのオンボーディングからデータを抽出する方法

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

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

採用から退職まで：従業員ライフサイクルの属性

採用から退職までの従業員ライフサイクルを詳しく分析するには、これらのデータ項目をイベントログに含めることをおすすめします。

3 必須 5 推奨 13 任意

	名前	説明
	アクティビティ名 ActivityName	社員のライフサイクルのある時点で発生した、特定のイベントまたはタスクの名前です。
説明アクティビティ名は、「Offer Accepted」「Background Check Completed」「Promotion Approved」など、採用から退職までのプロセスにおける具体的な手順を表します。これらのアクティビティがプロセスマップのノードとなり、社員の一連の流れを構成するイベントの順序を示します。アクティビティを分析すると、組織はプロセスの流れを把握し、頻度の高い経路やまれな経路を特定して、遅延や手戻りが発生する段階を見つけられます。正確でわかりやすいプロセスモデルを作成するには、アクティビティ名を一貫性のある明確な表記にすることが重要です。重要な理由プロセスマップの手順を定義する項目であり、プロセスマイニングの分析と可視化の基盤となります。入手先 WorkdayのトランザクションログにあるBusiness Process StepまたはEvent Nameから取得します。例オファーレターの作成オンボーディングタスクの完了退職手続きの開始
	イベントのタイムスタンプ EventTimestamp	アクティビティまたはイベントが記録された正確な日時です。
説明この属性は、各アクティビティがいつ発生したかを記録し、時間に関するコンテキストを示します。タイムスタンプの順序と時刻を使ってプロセスの流れを組み立て、サイクルタイムや所要時間など、時間に基づく指標を計算します。分析では、イベントのタイムスタンプがプロセスのパフォーマンスを把握する基礎となります。手順間の時間を計算し、遅延を特定できるほか、四半期ごとの採用速度の比較など、期間ごとのプロセスの動きを分析できます。重要な理由イベントを正しい順序に並べ、サイクルタイムやボトルネックなどのパフォーマンス指標を計算するうえで欠かせない属性です。入手先 Workdayのビジネスプロセスのトランザクションログに標準的に含まれる項目で、「Effective Date」や「Completed Moment」と呼ばれることがあります。例 2023-10-26T10:00:00Z2023-11-01T14:35:10Z2024-01-15T09:12:00Z
	社員ID EmployeeId	組織内での社員のライフサイクル全体を追跡するための、一意の識別子です。主なケースIDとして使用されます。
説明社員IDは、採用から退職までのプロセス分析の基盤となります。最初の求人応募から最終的な退職まで、関連するすべてのイベントを1つの一貫した流れとして結び付けます。このIDを追跡することで、役割変更、パフォーマンス評価、オンボーディングの手順など、社員の在籍期間全体を記録できます。プロセスマイニングでは、すべてのアクティビティが社員IDに関連付けられるため、個々の社員と社員全体のライフサイクルを把握できます。これにより、プロセス所要時間の分析、一般的な経路の特定、キャリアの各段階で社員に影響するボトルネックの発見が可能になります。重要な理由 1人の社員に関するライフサイクルイベントをすべて結び付け、プロセス全体を一貫して把握するために欠かせない属性です。入手先 Workday HCMの主要項目で、通常は社員プロフィールやビジネスプロセスのトランザクションに記録されています。例 100234510087651011212
	イベント実行者 EventPerformer	アクティビティを実行したユーザーまたは自動化されたシステムエージェントです。
説明この属性は、タスクの完了を担った個人、役割、またはシステムを特定します。オファーを承認する採用マネージャー、オンボーディングを開始する人事担当者、通知を作成するシステムプロセスなどが該当します。イベント実行者を分析すると、リソースの割り当て、作業負荷の分布、ユーザーによる利用状況を把握できます。負荷が集中しているチームを特定し、手作業で繰り返しタスクを行っている箇所から自動化の機会を見つけたり、個人や部門間のパフォーマンスの違いを分析したりできます。重要な理由作業負荷の分布やユーザーのパフォーマンスを分析し、プロセスに関与する担当者を特定できます。対象を絞った改善に役立ちます。入手先 Workdayのビジネスプロセスのトランザクションログから取得できます。多くの場合、手順を完了したユーザーに関連付けられています。例 jsmith@example.comr.davisシステムプロセス
	イベント終了時刻 EventEndTime	アクティビティの完了時刻を示すタイムスタンプです。特に、所要時間を測定できるタスクで使用します。
説明 StartTimeがアクティビティの開始時刻を示すのに対し、イベント終了時刻は完了時刻を示します。2つの時刻の差がアクティビティの処理時間です。「Background Check」や「Performance Review」のように、瞬時に終わらないタスクで特に役立ちます。分析では、この属性を使って処理時間の指標を計算します。アクティビティ間の待ち時間と、実際にアクティビティに取り組んだ時間を区別できるため、プロセスのどこに時間がかかっているかをより正確に把握できます。重要な理由アクティビティの実際の処理時間を計算し、作業時間と待機時間を区別できます。入手先 Workdayの一部のビジネスプロセスでは、開始と完了の両方のタイムスタンプが記録されます。その場合、イベントの結合が必要になることがあります。例 2023-10-26T18:30:00Z2023-11-05T11:00:15Z2024-01-15T17:20:00Z
	ライフサイクルイベントの種類 LifecycleEventType	オンボーディング、昇進、退職手続きなど、プロセスを主なライフサイクルの種類に分類します。
説明この属性は、採用から退職までのプロセス全体に含まれるさまざまな流れを大まかに分類します。各ケースに「Onboarding」「Internal Mobility」「Termination」などのタグを付けると、プロセスマップを簡単に絞り込み、それぞれのサブプロセスを個別に分析できます。たとえば、「社内異動・昇進にかかる時間」のダッシュボードを分析する場合は、ライフサイクルイベントの種類が「Internal Mobility」または「Promotion」のケースに絞り込みます。この分類は、特定の業務上の問いに答える分析やダッシュボードを作成するうえで重要です。重要な理由社員のライフサイクル全体を個別のサブプロセスに分け、オンボーディング、退職手続き、昇進に焦点を当てた分析ができます。入手先通常、データ変換時にWorkdayの特定のビジネスプロセス名（「Hire」「Change Job」「Terminate」など）を各カテゴリに対応付けて設定します。例オンボーディング社内異動退職手続きパフォーマンス管理
	求人申請ID JobRequisitionId	採用プロセスの起点となった求人申請を特定する一意の識別子です。
説明求人申請IDは、求人の掲載、候補者の審査、オファーの作成など、採用初期のアクティビティを特定の人員ニーズに結び付けます。社員ライフサイクルの採用段階で、補助的なケースIDとして機能します。求人申請IDで分析すると、職種や部門ごとの採用プロセスの効率に関するインサイトを得られます。求人申請の作成からオファーの承諾までの流れを追跡し、「採用所要時間の平均」などの重要業績評価指標（KPI）を支援します。重要な理由入社前のアクティビティを1つの識別子にまとめ、採用段階を詳しく分析できます。入手先 WorkdayのRecruitingモジュールにあります。候補者の応募情報と、その後の採用イベントに関連付けられています。例 REQ-2023-05-101REQ-2024-01-230REQ-2023-11-087
	部門 Department	社員が所属する組織内の部門です。
説明この属性は、社員が所属する「Sales」「Engineering」「Human Resources」などの部門を示します。組織内の部門ごとにプロセスのパフォーマンスを分類して比較するための重要な切り口です。プロセス分析で部門を指定すると、「Engineering部門の採用所要時間はSales部門より長いか」「オンボーディングの逸脱率が最も高い部門はどこか」といった問いに答えられます。部門固有の問題を特定し、状況に応じた改善につなげることができます。重要な理由部門間の比較分析に役立ち、特定の業務領域に非効率が集中しているかどうかを特定できます。入手先 Workday HCMに登録される社員の基本的な職務・組織データの一部で、社員のポジションに関連付けられています。例エンジニアリング営業・マーケティング財務
	SLA目標日 SlaTargetDate	人事評価など、特定のアクティビティを完了する目標日です。
説明この属性は、特定のタスクに対するサービスレベル契約（SLA）の期限を定義します。プロセスにかける時間の目安となり、パフォーマンスを測定する基準として使われます。「人事評価の期限遵守率」などの重要業績評価指標（KPI）や、SLAの遵守状況を確認するダッシュボードに欠かせない項目です。実際の完了日（EventTimestamp）とSlaTargetDateを比較することで、違反の自動検出、期限内の完了状況の測定、遅延への先回りした対応が可能になります。重要な理由期限内の完了状況を測る明確な基準となり、SLA遵守状況の重要業績評価指標（KPI）の算出に欠かせません。入手先 Workdayの人事評価などのプロセスでは、期限日が設定されていることがよくあります。このデータは、プロセスイベントとあわせて抽出する必要があります。例 2023-12-31T23:59:59Z2024-06-30T23:59:59Z
	SLA違反あり IsSlaViolated	アクティビティがSLAの目標日を過ぎて完了したかどうかを示す真偽値です。
説明この計算属性は、プロセスの手順がサービスレベル契約を満たしたかどうかを、真偽値で示します。アクティビティの完了タイムスタンプ（EventTimestamp）と期限（SlaTargetDate）を比較して算出します。このフラグは、SLA違反の件数を簡単に集計して可視化できるため、ダッシュボードやレポートに役立ちます。「人事評価の期限遵守率」などの重要業績評価指標（KPI）に利用でき、期限超過タスクのアラートやレポートも作成しやすくなります。チームが特に対応を要する遅延に集中するのに役立ちます。重要な理由合意した期限を守れなかったケースを明確に特定できるため、パフォーマンスの監視が容易になります。入手先計算フィールド：EventTimestamp > SlaTargetDateの場合はtrue、それ以外はfalseです。例 truefalse
	オンボーディングプラン名 OnboardingPlanName	新入社員に割り当てられたオンボーディングのテンプレートまたはプランの名称です。
説明 Workdayでは、役割、勤務地、職位に応じた複数のオンボーディングプランを作成できます。この属性から、新入社員にどのプランが適用されたかを確認できます。オンボーディングプラン名ごとに分析すると、各オンボーディング施策の効果と効率を評価できます。たとえば、「役員向けオンボーディングプラン」と「標準従業員向けオンボーディングプラン」を直接比較し、タスク完了率やサイクルタイムにどのような違いがあるかを確認できます。重要な理由オンボーディングプログラムごとの成果を評価し、効果的な取り組みや改善点を見つけるのに役立ちます。入手先この情報は、Workdayのオンボーディングモジュールで、採用ビジネスプロセスに関連付けられていると考えられます。例標準的な全社オンボーディング営業チーム向けオンボーディング役員向けオンボーディングプラン
	コンプライアンス対象アクティビティ IsComplianceActivity	アクティビティがコンプライアンスまたは規制上必須の手順かどうかを示す真偽値です。
説明このフラグは、ポリシーへの同意や必須研修の受講など、法律、規制、社内方針の遵守に欠かせないアクティビティを識別します。こうした重要なタスクを通常の事務作業と区別できます。分析では、この属性を使ってコンプライアンスに特化したダッシュボードや重要業績評価指標（KPI）を作成できます。たとえば、「重大なコンプライアンス対象アクティビティの実施率」を確認できます。全従業員が重要な規制上の手順を期限内に完了しているかを監視し、組織のリスク低減に役立てられます。重要な理由コンプライアンス上重要な手順を重点的に監視し、規制の遵守とリスクの低減に役立ちます。入手先これは派生属性です。通常、データ変換時に、コンプライアンス関連の既知のアクティビティ名を真偽値に対応付けて作成します。例 truefalse
	ソースシステム SourceSystem	イベントデータの抽出元となるシステムです。この場合はWorkday Onboardingを指します。
説明この属性はデータの取得元を示します。この画面ではWorkday Onboardingを対象としていますが、採用から退職までのプロセス全体を分析する場合は、応募者追跡システム（ATS）や別の給与システムなど、他のシステムのデータも含まれることがあります。データガバナンスを確保し、イベントのコンテキストを把握するには、ソースシステムの指定が重要です。複数のシステムを対象とする分析では、この項目を使って特定のシステムのイベントに絞り込んだり、システム間の引き継ぎを分析したりできます。重要な理由データの取得元に関する重要なコンテキストを示します。データの検証や複数システムのデータを組み合わせた分析に欠かせません。入手先通常は「Workday Onboarding」という固定値で、データの抽出・変換時に追加されます。例 Workday OnboardingWorkday HCM
	ポジションID PositionId	従業員が就いている特定のポジションまたは職務を識別する一意のIDです。
説明ポジションIDは、組織構造の中で従業員が就いている具体的な役割を識別します。各ポジションには、職務プロフィール、勤務地、レポートラインなどの属性が定義されています。同じ役職名を複数のポジションで共有できるため、役職名よりも詳細に識別できます。ポジションIDごとに分析すると、特定の役割に関連するプロセスを把握できます。たとえば、「シニアソフトウェアエンジニア」のポジションに就く従業員全員のオンボーディングを分析し、その役割に特有の共通パターンや遅延がないかを確認できます。重要な理由特定の役割に基づく詳細な分析が可能になり、社内のポジションごとにプロセスがどう異なるかを把握できます。入手先 Workday HCMで従業員の職務に関連付けられる標準項目です。例 POS-1001POS-2345POS-8762
	最終データ更新日時 LastDataUpdate	イベントのデータがソースシステムから最後に更新された日時を示すタイムスタンプです。
説明この属性は、データセットが最後に更新された日時を示します。分析対象のデータがどの程度新しいかを把握できるため、プロセスマイニングのインサイトに基づいて、適切なタイミングで関連性の高い業務判断を行ううえで重要です。ダッシュボードや継続的なモニタリングでは、利用可能な最新データを表示しているかどうかを確認できます。データの整合性を保ち、分析への信頼を確保するための重要なメタデータです。重要な理由データの新しさを利用者が把握できるようにします。プロセス分析の関連性と正確性を保つうえで重要です。入手先データの取り込みまたはETL（抽出、変換、読み込み）処理中に生成され、データセットに記録されるメタデータ項目です。例 2024-03-15T02:00:00Z2024-03-16T02:00:00Z
	勤務地 Location	社員のポジションに関連付けられた地理的な勤務地またはオフィスです。
説明勤務地属性は、社員が勤務する国、州、または都市を示します。地域ごとのプロセスのパフォーマンスやコンプライアンスを比較するうえで欠かせない地理的な切り口です。勤務地を使った分析では、地域ごとの採用期間、オンボーディングの効率、退職手続きの違いを明らかにできます。「ドイツでは米国よりバックグラウンドチェックに時間がかかるか」といった問いに答えられるほか、地域固有の規制への準拠状況のモニタリングにも役立ちます。重要な理由地域ごとのプロセスの違いを分析し、地域の管理体制、規制、文化などが与える影響を特定できます。入手先 Workday HCMに登録される社員のポジションおよび組織上の所属情報の一部です。例米国－ニューヨークドイツ－ベルリンインド－バンガロール
	手戻りあり IsRework	同じケース内で、アクティビティが前の手順の繰り返しかどうかを示す真偽値です。
説明この属性は、同じ従業員に対してタスクを複数回実施する手戻りを識別します。誤った書類の再提出や、失敗したバックグラウンドチェックの再実施などが該当します。通常、ケースのイベントログ内に同じアクティビティ名が複数回現れることで特定できます。手戻りの分析は、プロセスの効率と品質を高めるうえで重要です。「IsRework」フラグを使うと、手戻りの量を把握し、根本原因を特定して、初回で正しく完了させるための改善効果を測定できます。「手戻りと繰り返しの分析」ダッシュボードにも利用できます。重要な理由繰り返し実施されているアクティビティを特定して、プロセスの非効率や無駄を把握できます。品質やコミュニケーション上の問題を見つける手がかりになります。入手先これは計算フラグです。プロセスマイニングの分析で、同じケース内のアクティビティの繰り返しを検出して判定します。例 truefalse
	採用所要日数 TimeToHire	求人申請の作成から候補者が内定を承諾するまでの合計日数です。
説明採用所要日数は、採用プロセス全体の効率を測る重要な採用指標です。同じ従業員または求人申請について、「求人申請の作成」イベントから「内定承諾」イベントまでの期間を算出します。この計算属性は、「平均採用所要日数」の重要業績評価指標（KPI）や関連するダッシュボードの基礎となります。経時的に追跡することで、人事部門はプロセス改善の効果を測定し、候補者の募集や面接におけるボトルネックを特定できます。また、採用担当者が現実的な採用スケジュールを設定する際にも役立ちます。重要な理由採用プロセスの効率を直接測定でき、人事組織にとって重要な業績指標となります。入手先ケース単位で、「求人申請の作成」アクティビティと「内定承諾」アクティビティのタイムスタンプ間の期間を算出します。例 35日62日28日
	退職理由 TerminationReason	従業員が組織を離れる理由です。
説明この属性には、「本人都合の退職」「業績不振による解雇」「定年退職」など、従業員の在籍が終了した理由が記録されます。離職や退職手続きを分析するうえで重要な情報です。プロセスマイニングでは、退職理由から退職手続きの背景を把握できます。退職の種類によって手順や所要時間が異なるかを分析できます。従業員の離職状況を理解し、それぞれの状況に応じて適切に退職手続きを進めるために役立ちます。重要な理由退職手続きの分析に必要な背景情報を提供し、プロセス上の問題と離職理由との関連を把握するのに役立ちます。入手先 Workdayの「従業員の退職」ビジネスプロセスで記録されます。例本人都合の退職会社都合の退職定年退職
	雇用形態 EmploymentType	従業員がフルタイム、パートタイム、契約社員、インターンのいずれに該当するかを示します。
説明この属性は、雇用契約の種類を分類します。雇用形態によって、オンボーディング、給与、福利厚生の設定に異なるプロセスのバリアントが適用されることがあります。この属性で絞り込むと、従業員の区分ごとにライフサイクルのプロセスを比較できます。たとえば、契約社員のオンボーディングがフルタイム従業員より大幅に速いか、コンプライアンス上の問題が多いかを確認し、対象を絞ったプロセスの見直しにつなげられます。重要な理由フルタイム従業員と契約社員など、従業員の区分によるプロセスの違いを比較できます。それぞれ異なる手順に従う場合の分析に役立ちます。入手先 Workday HCMの従業員の職務詳細にある標準項目です。例フルタイムパートタイム契約社員インターン
	雇用状況 EmploymentStatus	従業員の現在の雇用状況です。たとえば、アクティブ、退職、休職などがあります。
説明この属性は、組織における従業員の現在の状況を示します。従業員のライフサイクルに応じて変化する項目です。たとえば、新入社員は「入社前」または「オンボーディング」の状態から始まり、手続きが完了すると「アクティブ」になります。プロセスマイニングでは、この属性から現在の状態を把握できます。たとえば、給与設定の対象が「アクティブ」な従業員に限られているかなど、プロセスのコンプライアンス確認に利用できます。また、「退職」した従業員全員の退職手続きを分析するなど、対象を絞り込む際にも役立ちます。重要な理由従業員の現在の状態を把握できるため、プロセスのロジックを検証したり、特定の従業員グループに絞って分析したりする際に役立ちます。入手先 Workday HCMの従業員プロフィールにある基本項目です。例アクティブ退職休職入社前

必須推奨任意

採用から退職まで：従業員ライフサイクルのアクティビティ

従業員ライフサイクルを正確に把握して分析するために、これらの主要なプロセスステップと節目をイベントログに記録してください。

7 推奨 8 任意

	アクティビティ	説明
	オファーの承諾	候補者が正式に採用オファーを承諾した時点で発生します。多くの場合、Workday内でオファーレターに電子署名します。オファー手続きの「Review and Sign」手順を候補者が完了すると、この重要な節目が記録されます。
重要な理由この節目をもって採用の主要段階が終了し、入社前の手続きとオンボーディングが始まります。採用所要時間の重要業績評価指標（KPI）を測定するうえで重要な項目です。入手先候補者が「Job Application」ビジネスプロセス内でオファーの承諾手順を完了すると、明示的なイベントとして記録されます。記録候補者がオファーを承諾した操作は、Job Application BPの完了済み手順として記録されます。イベントタイプ explicit
	オンボーディングタスクの完了	新入社員に割り当てられたオンボーディングタスクがすべて完了したことを示します。通常、社員のオンボーディングビジネスプロセス全体のステータスが「Successfully Completed」になった時点で推定されます。
重要な理由新入社員のオンボーディングが完了したことを示す重要な節目です。オンボーディング期間の重要業績評価指標（KPI）を測定する終点となり、オンボーディングの手順が守られているかを分析する際にも役立ちます。入手先必要な手順とタスクがすべて完了した後に発生する、親の「Onboarding」ビジネスプロセスの完了タイムスタンプから推定されます。記録社員のOnboardingビジネスプロセス全体の完了タイムスタンプから推定されます。イベントタイプ inferred
	オンボーディングの開始	Workday Onboardingモジュールで、新入社員のオンボーディングが始まったことを示します。通常、「Hire」プロセスの完了をきっかけに、新入社員にオンボーディングのタスクとワークフローが割り当てられた時点で記録されます。
重要な理由オンボーディングの効率を分析する起点です。オンボーディングタスクの完了率を測定し、プロセス逸脱を特定するのに役立ちます。入手先新入社員に対して「Onboarding」ビジネスプロセス、または同様のワークフローが開始された時点で、開始イベントとして記録されます。記録新入社員に対してOnboardingビジネスプロセスが開始された時点で記録されるイベントです。イベントタイプ explicit
	採用プロセスの完了	候補者のレコードがWorkday HCMの社員レコードに正式に変換される重要なアクティビティです。「Hire」ビジネスプロセスが正常に完了した時点で明示的に記録されます。
重要な理由候補者から社員への移行を正式に示すイベントで、オンボーディング期間を追跡する重要な節目です。社員がHCMシステムに正式に登録されたことを表します。入手先社員の「Hire」ビジネスプロセスの完了イベントとして明示的に記録されます。ビジネスプロセスのログから正確なタイムスタンプを取得できます。記録「Hire」ビジネスプロセスが正常に完了した時点で記録されるイベントです。イベントタイプ explicit
	求人申請の作成	Workdayで新しい求人申請が作成され、承認されると、採用プロセスが正式に始まります。「Create Job Requisition」ビジネスプロセスが正常に完了した時点で、このアクティビティが明示的に記録されます。
重要な理由採用ライフサイクル全体の主な開始イベントです。このアクティビティから「Offer Accepted」までの時間を分析することは、採用所要時間の重要業績評価指標（KPI）を測定するうえで重要です。入手先 Workday Recruitingで「Create Job Requisition」ビジネスプロセスが正常に完了すると、このイベントが記録されます。タイムスタンプは、このビジネスプロセスのイベントログから取得できます。記録「Create Job Requisition」ビジネスプロセスの完了時に記録されるイベントです。イベントタイプ explicit
	社員の退職	社員ライフサイクルの最後のアクティビティで、システム上の雇用関係が正式に終了したことを示します。「Terminate Employee」ビジネスプロセスが正常に完了した時点で記録されます。
重要な理由採用から退職までのプロセスにおける最終イベントです。退職手続き期間を測定する終点となり、プロセスが完了したことを確認できます。入手先「Terminate Employee」ビジネスプロセスの完了イベントとして明示的に記録されます。この時点以降、社員のレコードは非アクティブになります。記録「Terminate Employee」ビジネスプロセスが正常に完了した時点で記録されるイベントです。イベントタイプ explicit
	退職手続きの開始	退職する社員の退職手続きが始まったことを示します。マネージャーまたは人事担当者がWorkdayで「Terminate Employee」ビジネスプロセスを開始した時点で明示的に記録されます。
重要な理由退職手続き全体の主な開始イベントです。退職手続き期間の平均に関する重要業績評価指標（KPI）を測定する起点となります。入手先 Workday HCMで「Terminate Employee」ビジネスプロセスが開始された時点で、明示的なイベントとして記録されます。記録「Terminate Employee」ビジネスプロセスが開始された時点で記録されるイベントです。イベントタイプ explicit
	オファーレターの作成	候補者に正式な採用オファーが作成された時点を示します。通常、Workdayの「Job Application」ビジネスプロセスに含まれる明示的な手順です。
重要な理由面接終了後、オファーを正式に提示するまでにかかる時間を把握できます。この段階で遅延が生じると、候補者が選考を辞退する可能性があります。入手先「Job Application」ビジネスプロセスのイベントログから取得します。具体的には、「Generate Document」の完了時点、またはオファーに関する同様の手順を記録します。記録 Job Application BPの「Generate Offer」手順の完了時に記録されるイベントです。イベントタイプ explicit
	バックグラウンドチェックの完了	採用前審査の完了を示します。バックグラウンドチェックのステータスが手動または連携によって完了に更新された時点で記録されます。
重要な理由バックグラウンドチェック所要時間の重要業績評価指標（KPI）を測定する終点です。このアクティビティの遅延は、新入社員の入社日に直接影響します。入手先「Background Check」ビジネスプロセスまたは関連オブジェクトのステータス変更から取得します。「Completed」や「Passed」などの最終ステータスを示します。記録バックグラウンドチェックのステータス項目が最終状態に変わった時刻から推定されます。イベントタイプ inferred
	バックグラウンドチェックの開始	オファーを承諾した候補者の採用前審査が始まったことを示します。バックグラウンドチェックの手順が開始されると記録され、多くの場合、外部ベンダーとの連携も開始されます。
重要な理由バックグラウンドチェックにかかる時間は、採用プロセスのボトルネックになることがよくあります。このアクティビティは、バックグラウンドチェック所要時間の重要業績評価指標（KPI）を測定する起点です。入手先採用ワークフロー全体の一部として実施される「Background Check」などのビジネスプロセス内の手順として記録されます。開始時刻も記録されます。記録「Background Check」ビジネスプロセス、または関連する手順の開始時に記録されるイベントです。イベントタイプ explicit
	パフォーマンス評価の完了	社員の正式なパフォーマンス評価サイクルが完了したことを示します。「Performance Review」ビジネスプロセスが最終承認状態に達した時点で記録されます。
重要な理由これらのイベントを追跡することで、パフォーマンス管理の実施時期や頻度を分析できます。パフォーマンス評価の適時性に関する重要業績評価指標（KPI）を直接支えます。入手先社員の「Start Performance Review」ビジネスプロセスが正常に完了したイベントとして記録されます。記録「Performance Review」ビジネスプロセスが正常に完了した時点で記録されるイベントです。イベントタイプ explicit
	役割変更の開始	異動や昇進など、社内での人事異動の開始を示します。マネージャーまたは人事担当者が社員の「Change Job」ビジネスプロセスを開始した時点で記録されます。
重要な理由社内異動の効率と承認期間を測定する起点です。社員のキャリア形成におけるボトルネックの特定に役立ちます。入手先 Workday HCMで「Change Job」ビジネスプロセスが開始された時点で、明示的なイベントとして記録されます。記録社員の「Change Job」ビジネスプロセスが開始された時点で記録されるイベントです。イベントタイプ explicit
	昇進の承認	社員の昇進が最終承認されたことを示します。「Change Job」または関連する報酬ビジネスプロセスが完全に承認され、完了した時点で記録されます。
重要な理由社内異動の承認期間に関する重要業績評価指標（KPI）を測定する終点です。キャリア形成における重要な節目が正常に完了したことを確認できます。入手先変更理由が昇進である「Change Job」ビジネスプロセスの正常な完了イベントとして記録されます。記録変更理由が「Promotion」である「Change Job」ビジネスプロセスの完了時に記録されるイベントです。イベントタイプ explicit
	給与設定の完了	新入社員の給与計算に必要な情報がすべて入力され、確認されたことを示します。OnboardingまたはHireビジネスプロセス内の特定の手順が完了した時点で記録される場合があります。
重要な理由初回の給与から、社員に正確な金額を期限どおりに支給できるようにします。このアクティビティは給与設定所要時間の重要業績評価指標（KPI）の終点となり、給与支給開始の遅れを把握できます。入手先 Onboardingビジネスプロセス内で、「Enter Payment Elections」などのチェックリスト項目または特定の手順が完了した時点で記録されます。記録ビジネスプロセス内の給与関連タスクまたは手順の完了です。イベントタイプ explicit
	退職手続きタスクの完了	備品の返却や知識の引き継ぎなど、退職に必要なタスクがすべて完了したことを示します。退職チェックリストまたはビジネスプロセスのステータスが完了に変わった時点で推定されます。
重要な理由これらのタスクの完了を追跡することは、安全でコンプライアンスに準拠した退職手続きに欠かせません。遅延はセキュリティリスクや、社員にとって望ましくない体験につながる可能性があります。入手先「Offboarding」ビジネスプロセスの完了タイムスタンプ、または社員に割り当てられた退職手続きタスクがすべて完了になった時点から推定されます。記録退職チェックリストまたは関連するビジネスプロセスの完了から推定されます。イベントタイプ inferred

推奨任意

データ抽出ガイド

Workdayのオンボーディングからデータを取得する方法

ステップ

Workdayにログインします： カスタムレポートの作成（Report Writer）と必要なデータドメイン（例：人員配置、Core HCM、オンボーディング、パフォーマンス管理）へのアクセス権を持つユーザーアカウントで、Workdayにログインします。
新しいカスタムレポートを作成します： 「Create Custom Report」タスクを開きます。レポート種別に「Advanced」を選択します。複数のデータソースを使う複雑なレポートを作成するには、この種別が必要です。
主要なビジネスオブジェクトを定義します： 主要な「Data Source」に「Business Process Transactions」を設定します。このオブジェクトにはすべてのビジネスプロセスイベントが含まれるため、イベントログの作成に欠かせません。最初からイベントが除外されないよう、「All Business Process Transactions」を選択します。
最初の列を追加します： 「Columns」タブで、イベントログの基礎となるフィールドを追加します。まず、次の項目を設定します。
- Worker（Business Process Transactionから）> Employee IDをEmployeeIdに設定します。
- Overall Process（Business Process Transactionから）をActivityNameの判定に使います。
- Effective DateまたはCompletion Date（Business Process Transactionから）をEventTimestampに設定します。
- InitiatorをEventPerformerに設定します。
- Worker > Supervisory Organization > DepartmentをDepartmentに設定します。
アクティビティ用の計算フィールドを作成します： この抽出の要点は、Workdayのビジネスプロセスのステップを個別のアクティビティ名に対応付けることです。「Evaluate Expression」の計算フィールドを複数作成します。各フィールドでビジネスプロセスの種別とステータスを確認し、適切なActivityNameを出力します。たとえば、CF_ActivityName_Hireという計算フィールドでは、「Business Process Type = 'Hire' AND Step = 'Successfully Completed'」を条件とし、「Hire Process Completed」というテキストを返します。必要な15種類のアクティビティすべてについて、同様のフィールドを作成します。
マスター計算フィールドを作成します： 最後に「Lookup Related Value」または「Evaluate Expression」の計算フィールドを作成し、ActivityNameと名付けます。このフィールドで前のステップで作成した各アクティビティ用フィールドをつなぎ、各行につき1つのアクティビティ名だけが返されるようにします。
ユニオン形式のレポートを構成します： 異なるビジネスプロセスのイベントをまとめるには、レポートを「Composite」形式に変更し、サブレポート種別に「Union」を選択します。ライフサイクルの主要なプロセス（例：「Hire」「Onboarding」「Change Job」「Terminate」）ごとにデータソースを作成します。各サブレポートでは、該当するビジネスプロセス種別で絞り込み、関連するステップを標準の出力列（EmployeeId、ActivityName、EventTimestampなど）に対応付けます。
プロンプトとフィルターを設定します： ユーザーが抽出期間を指定できるよう、日付範囲のプロンプトを追加します。必要に応じて、特定の会社や上司組織にデータを絞り込むフィルターも追加します。処理性能を保つうえで重要な設定です。
Webサービスとして有効にします： レポート定義の「Advanced」タブを開き、「Enable as Web Service」にチェックを入れます。これにより、レポートをReport-as-a-Service（RaaS）のエンドポイントとして公開できます。
APIオプションを設定します： 「Web Service API Options」で、後続システムが解析しやすいJSONを出力形式に選択します。「Namespace」と「Report Name」はAPI URLの一部となるため、控えておきます。
公開してテストします： レポートを保存し、Workdayの画面から実行してデータを検証します。問題がなければ、ブラウザーまたはPostmanなどのAPIクライアントからRaaS URLにアクセスし、Webサービスのエンドポイントをテストします。URLの形式は通常、https://[Your Workday Host]/ccx/service/[Your Tenant]/Report_Service/[Report Owner]/[Report Name]です。
抽出をスケジュールします： 連携ツールまたはETLツールを使ってRaaS URLへの定期的なリクエストを設定し、必要な日付範囲のパラメーターを渡してイベントログのデータをプロセスマイニングツールに取り込みます。

設定

レポート種別： Advancedを選択します。計算フィールドとユニオン形式のサブレポートを使うために必要です。
主要なデータソース／ビジネスオブジェクト： 「Business Process Transactions」を選択します。このオブジェクトには、Workday全体のプロセス開始、ステップ、完了の記録が含まれます。
計算フィールド： 生のビジネスプロセスイベント（例：「Hire BP, Step: Propose Compensation, Status: Completed」）を、わかりやすいアクティビティ名（例：「Hire Process Completed」）に変換するには、「Evaluate Expression」の計算フィールドを複数作成する必要があります。
プロンプト： 「Completion Date」フィールドを基準に、「Start Date」と「End Date」のプロンプトを設定します。これにより、期間を指定した抽出や増分抽出が可能になります。
フィルタリング： データ量を調整し、組織内の関連する範囲に分析対象を絞るため、「Company」または「Supervisory Organization」での絞り込みを強くおすすめします。従業員ライフサイクルに関係のないビジネスプロセスも除外してください。
Webサービスのオプション： レポートをWebサービス（「RaaS」）として有効にする必要があります。幅広いシステムとの互換性を確保するため、出力形式はJSONに設定します。
セキュリティと権限： レポートの作成と実行には、関連するすべてのイベントと属性を参照できるよう、次のデータドメインへのアクセス権が必要です。「Business Process Transactions」「Worker Data (Core HCM)」「Staffing」「Onboarding」に加え、「Compensation」や「Performance Management」へのアクセス権も必要になる場合があります。

クエリの例 sql

/*
 This is a logical representation of a Workday Advanced Composite Report configuration.
 It is not executable code but a blueprint for a Workday Report Writer.
 The report unions data from different business processes to form a single event log.
*/

REPORT_TYPE: Composite
COMPOSITE_TYPE: Union

// =======================================================
// SUB-REPORT 1: RECRUITMENT AND HIRE EVENTS
// =======================================================

SUB_REPORT_NAME: SR_RecruitHire
DATA_SOURCE: Business Process Transactions

COLUMNS:
  1. Field: Worker > Employee ID | Alias: EmployeeId
  2. Calculated Field: CF_ActivityName_RecruitHire | Alias: ActivityName
  3. Field: Completion Date | Alias: EventTimestamp
  4. Field: Initiator | Alias: EventPerformer
  5. Field: Worker > Supervisory Organization | Alias: Department
  6. Field: Job Application > Job Requisition > Requisition ID | Alias: JobRequisitionId
  7. Calculated Field: CF_LifecycleType_Onboarding | Alias: LifecycleEventType

CALCULATED_FIELDS:
  - Name: CF_ActivityName_RecruitHire
    Type: Evaluate Expression
    Logic:
      IF (Business Process Type = 'Create Job Requisition' AND Status = 'Successfully Completed') THEN 'Job Requisition Created'
      ELSE IF (Business Process Type = 'Job Application' AND Last Step Completed = 'Generate Offer') THEN 'Offer Letter Generated'
      ELSE IF (Business process Type = 'Job Application' AND Last Step Completed = 'Candidate Accepts Offer') THEN 'Offer Accepted'
      ELSE IF (Business Process Type = 'Job Application' AND Last Step Completed = 'Background Check') THEN 'Background Check Initiated'
      ELSE IF (Business Process Type = 'Job Application' AND Last Step Completed = 'Background Check Complete') THEN 'Background Check Completed'
      ELSE IF (Business Process Type = 'Hire' AND Status = 'Successfully Completed') THEN 'Hire Process Completed'
      ELSE ''

  - Name: CF_LifecycleType_Onboarding
    Type: Evaluate Expression
    Logic:
      IF (True) THEN 'Onboarding'

FILTERS:
  - Business Process Type IN ('Create Job Requisition', 'Job Application', 'Hire')
  - Completion Date BETWEEN [Prompt: Start Date] AND [Prompt: End Date]


// =======================================================
// SUB-REPORT 2: ONBOARDING EVENTS
// =======================================================

SUB_REPORT_NAME: SR_Onboarding
DATA_SOURCE: Business Process Transactions

COLUMNS: (Same structure as SUB-REPORT 1)

CALCULATED_FIELDS:
  - Name: CF_ActivityName_Onboarding
    Type: Evaluate Expression
    Logic:
      IF (Business Process Type = 'Onboarding' AND Status = 'In Progress' AND First Step Initiated = 'True') THEN 'Onboarding Initiated'
      ELSE IF (Business Process Type = 'Onboarding' AND Last Step Completed = 'Complete Payroll Forms') THEN 'Payroll Setup Completed'
      ELSE IF (Business Process Type = 'Onboarding' AND Status = 'Successfully Completed') THEN 'Onboarding Tasks Completed'
      ELSE ''

  - Name: CF_LifecycleType_Onboarding
    Type: Evaluate Expression
    Logic:
      IF (True) THEN 'Onboarding'

FILTERS:
  - Business Process Type = 'Onboarding'
  - Completion Date BETWEEN [Prompt: Start Date] AND [Prompt: End Date]


// =======================================================
// SUB-REPORT 3: PERFORMANCE AND CAREER EVENTS
// =======================================================

SUB_REPORT_NAME: SR_PerformanceCareer
DATA_SOURCE: Business Process Transactions

COLUMNS: (Same structure as SUB-REPORT 1, JobRequisitionId may be null)

CALCULATED_FIELDS:
  - Name: CF_ActivityName_PerfCareer
    Type: Evaluate Expression
    Logic:
      IF (Business Process Type = 'Start Performance Review' AND Status = 'Successfully Completed') THEN 'Performance Review Completed'
      ELSE IF (Business Process Type = 'Change Job' AND Status = 'In Progress' AND First Step Initiated = 'True') THEN 'Role Change Initiated'
      ELSE IF (Business Process Type = 'Change Job' AND Last Step Completed = 'Approval' AND (Reason Category = 'Promotion')) THEN 'Promotion Approved'
      ELSE ''

  - Name: CF_LifecycleType_CareerDev
    Type: Evaluate Expression
    Logic:
      IF (True) THEN 'Career Development'

FILTERS:
  - Business Process Type IN ('Start Performance Review', 'Change Job')
  - Completion Date BETWEEN [Prompt: Start Date] AND [Prompt: End Date]


// =======================================================
// SUB-REPORT 4: OFFBOARDING EVENTS
// =======================================================

SUB_REPORT_NAME: SR_Offboarding
DATA_SOURCE: Business Process Transactions

COLUMNS: (Same structure as SUB-REPORT 1, JobRequisitionId will be null)

CALCULATED_FIELDS:
  - Name: CF_ActivityName_Offboarding
    Type: Evaluate Expression
    Logic:
      IF (Business Process Type = 'Terminate Employee' AND Status = 'In Progress' AND First Step Initiated = 'True') THEN 'Termination Initiated'
      ELSE IF (Business Process Type = 'Offboarding' AND Status = 'Successfully Completed') THEN 'Offboarding Tasks Completed'
      ELSE IF (Business Process Type = 'Terminate Employee' AND Status = 'Successfully Completed') THEN 'Employee Terminated'
      ELSE ''

  - Name: CF_LifecycleType_Offboarding
    Type: Evaluate Expression
    Logic:
      IF (True) THEN 'Offboarding'

FILTERS:
  - Business Process Type IN ('Terminate Employee', 'Offboarding')
  - Completion Date BETWEEN [Prompt: Start Date] AND [Prompt: End Date]

ステップ

前提条件：Workday APIへのアクセスを設定します。
- WorkdayでIntegration System User（ISU）を作成し、安全なパスワードを設定します。
- 専用のIntegration Security Groupを新規作成し、ISUを割り当てます。
- Security Groupに、次のドメインへの「Get」アクセス権を含むドメインセキュリティポリシーの権限を付与します。「Business Process Transactions」「Worker Data: Public Worker Reports」、および照会するビジネスプロセスに関連するその他のドメイン（例：「Job Requisition Data」）。
- Workdayで保留中のセキュリティポリシーの変更を有効にします。
Python環境を設定します。
- スクリプトを実行するマシンにPython 3.6以降がインストールされていることを確認します。
- pipを使って必要なPythonライブラリをインストールします：pip install zeep pandas。
- zeepはWorkday APIとの連携に使うSOAPクライアントです。pandasはデータの加工とCSVへの出力に使います。
Workday WSDL URLを取得します。
- Workdayのテナントで「Public Web Services」レポートを検索します。
- 「Human Capital Management」Webサービスを見つけ、WSDL URLを確認します。URLの形式は、https://[Your_Workday_Tenant_URL]/ccx/service/[Your_Tenant_Name]/Human_Resources/vXX.X?wsdlのようになります。
Pythonスクリプトを設定します。
- 提供されたPythonスクリプトを、たとえばextract_h2r.pyというファイルに保存します。
- スクリプトの先頭にあるプレースホルダー変数を、Workday WSDL URL、テナントのユーザー名（例：ISU_user@tenant_name）、パスワードに置き換えます。
抽出範囲を定義します。
- スクリプト内のBUSINESS_PROCESS_TYPESリストを確認し、採用から退職までのサイクルに関連するビジネスプロセス定義がすべて含まれていることを確かめます。Workdayの設定に応じて、名前の追加や変更が必要な場合があります。
- START_DATEとEND_DATEの変数を設定し、データの抽出期間を指定します。
抽出スクリプトを実行します。
- ターミナルまたはコマンドプロンプトを開き、スクリプトを保存したディレクトリに移動して、python extract_h2r.pyを実行します。
- スクリプトはWorkday APIに接続し、指定された各ビジネスプロセス種別を順に処理して、ページごとにデータを取得します。進行状況はコンソールに表示されます。
APIレスポンスを処理して対応付けます。
- スクリプトはWorkday APIから返される複雑なXMLレスポンスを内部で解析します。
- ビジネスプロセスのステータス（「Successfully Completed」「Initiated」）や特定のステップ名、完了ステータスを確認して、主要なイベントを特定します。
- この処理でWorkdayの生データを、EmployeeId、ActivityName、EventTimestampなどの列を持つ標準的なイベントログ形式に変換します。
出力ファイルを確認します。
- スクリプトの実行が完了すると、同じディレクトリにworkday_h2r_event_log.csvというCSVファイルが作成されます。
- 表計算ソフトでファイルを開き、データが正しい形式になっていることを確認します。
ProcessMindへのアップロードを準備します。
- 作成されたCSVファイルは、ProcessMindにそのまま取り込める形式です。列見出し（EmployeeId、ActivityName、EventTimestampなど）がプロジェクトで想定されるスキーマと一致していることを確認します。
- CSVファイルをProcessMindの環境にアップロードして、分析を開始します。

設定

APIエンドポイント： スクリプトの実行には、Workday Human Capital Management（HCM）WebサービスのWSDL URLが必要です。このURLはテナントごとに異なり、Workdayの「Public Web Services」レポートで確認できます。
認証： スクリプトはIntegration System User（ISU）とパスワードによる基本認証を使います。このユーザーに、必要なAPIドメインへのセキュリティ権限が付与されていることを確認してください。
ビジネスプロセス種別： 抽出処理の中心となるのは、照会対象のビジネスプロセス定義のリストです。Workday環境で使われている名前（例：Hire、Onboarding、Change Job、Terminate Employee、Create Job Requisition）に合わせて、スクリプト内のリストを設定してください。
日付範囲： スクリプトにはSTART_DATEとEND_DATEのパラメーターがあります。初回の実行では、データ量とAPIの応答時間を調整するため、3～6か月など短い期間を指定することをおすすめします。本番環境では、期間を広げるか、増分読み込みを定期実行するよう設定できます。
ページネーション： スクリプトはページ単位でAPIを呼び出し、大規模なデータセットにも対応します。ページサイズは一般的でタイムアウトを避けやすい100に設定されていますが、必要に応じて変更できます。

クエリの例 python

import os
import pandas as pd
from zeep import Client, Settings, Transport
from zeep.wsse.username import UsernameToken
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your Workday tenant's WSDL URL for Human Resources
WSDL_URL = class="hl-string">'https://[Your_Workday_Tenant_URL]/ccx/service/[Your_Tenant_Name]/Human_Resources/v38.0?wsdl'

class=class="hl-string">"hl-comment"># Replace with your Integration System User (ISU) credentials
TENANT_USERNAME = class="hl-string">'user@tenant'
TENANT_PASSWORD = os.environ.get(class="hl-string">'WORKDAY_PASSWORD') class=class="hl-string">"hl-comment"># Best practice: use environment variables for passwords

class=class="hl-string">"hl-comment"># Define the date range for the extraction
START_DATE = class="hl-string">'2023-01-01T00:00:00Z'
END_DATE = class="hl-string">'2023-12-31T23:59:59Z'

class=class="hl-string">"hl-comment"># List of Business Processes to extract data from. Names must match your Workday configuration.
BUSINESS_PROCESS_TYPES = [
    class="hl-string">'Create Job Requisition', 
    class="hl-string">'Job Application', 
    class="hl-string">'Hire', 
    class="hl-string">'Onboarding', 
    class="hl-string">'Performance Review', 
    class="hl-string">'Change Job', 
    class="hl-string">'Terminate Employee'
]

class=class="hl-string">"hl-comment"># --- Main Extraction Logic --- #
def get_workday_client(wsdl, user, password):
    class="hl-string">"""Initializes the Zeep SOAP client with WS-Security."""
    session = requests.Session()
    session.verify = True class=class="hl-string">"hl-comment"># Or path to your cert bundle
    transport = Transport(session=session)
    settings = Settings(strict=False, xml_huge_tree=True)
    client = Client(wsdl, wsse=UsernameToken(user, password), transport=transport, settings=settings)
    return client

def map_transaction_to_events(transaction):
    class="hl-string">"""Maps a single Workday business process transaction to one or more event log records."""
    events = []
    process_data = transaction.Business_Process_Data
    process_type = process_data.Business_Process.Business_Process_Definition_Name
    process_status = process_data.Status.value
    case_id = process_data.Business_Process.Initiating_Person_Reference.Employee_ID if process_data.Business_Process.Initiating_Person_Reference else None
    subject_employee_id = None
    if process_data.Business_Process.Business_Process_Target_Reference and hasattr(process_data.Business_Process.Business_Process_Target_Reference, class="hl-string">'Employee_ID'):
        subject_employee_id = process_data.Business_Process.Business_Process_Target_Reference.Employee_ID

    class=class="hl-string">"hl-comment"># Default to subject employee, fallback to initiator for processes like Job Requisition
    employee_id = subject_employee_id or case_id
    if not employee_id:
        return [] class=class="hl-string">"hl-comment"># Skip transactions without a clear employee context

    performer = case_id
    department = None class=class="hl-string">"hl-comment"># Placeholder, would require additional API calls to enrich

    class=class="hl-string">"hl-comment"># General process completion events
    if process_status == class="hl-string">'Successfully Completed':
        completion_time = process_data.Status_Date.isoformat()
        activity_map = {
            class="hl-string">'Create Job Requisition': class="hl-string">'Job Requisition Created',
            class="hl-string">'Hire': class="hl-string">'Hire Process Completed',
            class="hl-string">'Onboarding': class="hl-string">'Onboarding Tasks Completed',
            class="hl-string">'Performance Review': class="hl-string">'Performance Review Completed',
            class="hl-string">'Change Job': class="hl-string">'Promotion Approved', class=class="hl-string">"hl-comment"># Assumption: Change Job completion means approval
            class="hl-string">'Terminate Employee': class="hl-string">'Employee Terminated'
        }
        if process_type in activity_map:
            events.append({
                class="hl-string">'EmployeeId': employee_id,
                class="hl-string">'ActivityName': activity_map[process_type],
                class="hl-string">'EventTimestamp': completion_time,
                class="hl-string">'EventEndTime': completion_time,
                class="hl-string">'EventPerformer': performer,
                class="hl-string">'Department': department,
                class="hl-string">'JobRequisitionId': None, class=class="hl-string">"hl-comment"># Requires enrichment
                class="hl-string">'LifecycleEventType': process_type
            })

    class=class="hl-string">"hl-comment"># Step-specific events from the transaction history
    if transaction.Business_Process_Step_Data:
        for step in transaction.Business_Process_Step_Data:
            step_name = step.Step
            step_completion_time = step.Completed_Date.isoformat() if step.Completed_Date else None
            if not step_completion_time: continue

            activity_name = None
            if process_type == class="hl-string">'Job Application' and class="hl-string">'Offer' in step_name and not class="hl-string">'Accept' in step_name:
                activity_name = class="hl-string">'Offer Letter Generated'
            elif process_type == class="hl-string">'Job Application' and class="hl-string">'Accept' in step_name and class="hl-string">'Offer' in step_name:
                activity_name = class="hl-string">'Offer Accepted'
            elif class="hl-string">'Background Check' in step_name and class="hl-string">'Initiate' in step_name:
                activity_name = class="hl-string">'Background Check Initiated'
            elif class="hl-string">'Background Check' in step_name and class="hl-string">'Complete' in step_name:
                activity_name = class="hl-string">'Background Check Completed'
            elif process_type == class="hl-string">'Hire' and class="hl-string">'Initiation' in step.Status.value:
                 class=class="hl-string">"hl-comment"># Onboarding is typically a sub-process or triggered by Hire completion
                events.append({
                    class="hl-string">'EmployeeId': employee_id,
                    class="hl-string">'ActivityName': class="hl-string">'Onboarding Initiated',
                    class="hl-string">'EventTimestamp': step_completion_time,
                    class="hl-string">'EventEndTime': step_completion_time,
                    class="hl-string">'EventPerformer': performer,
                    class="hl-string">'Department': department, class="hl-string">'JobRequisitionId': None, class="hl-string">'LifecycleEventType': class="hl-string">'Onboarding'
                })
            elif process_type == class="hl-string">'Onboarding' and class="hl-string">'Payroll' in step_name and step.Status.value == class="hl-string">'Successfully Completed':
                activity_name = class="hl-string">'Payroll Setup Completed'
            elif process_type == class="hl-string">'Change Job' and class="hl-string">'Initiation' in step.Status.value:
                activity_name = class="hl-string">'Role Change Initiated'
            elif process_type == class="hl-string">'Terminate Employee' and class="hl-string">'Initiation' in step.Status.value:
                activity_name = class="hl-string">'Termination Initiated'
            elif process_type == class="hl-string">'Terminate Employee' and class="hl-string">'Offboarding' in step_name and step.Status.value == class="hl-string">'Successfully Completed':
                activity_name = class="hl-string">'Offboarding Tasks Completed'

            if activity_name:
                events.append({
                    class="hl-string">'EmployeeId': employee_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTimestamp': step_completion_time,
                    class="hl-string">'EventEndTime': step_completion_time,
                    class="hl-string">'EventPerformer': performer,
                    class="hl-string">'Department': department, class="hl-string">'JobRequisitionId': None, class="hl-string">'LifecycleEventType': process_type
                })
    return events

def main():
    class="hl-string">"""Main function to run the extraction process."""
    if not TENANT_PASSWORD:
        print(class="hl-string">"Error: WORKDAY_PASSWORD environment variable not set.")
        return

    print(class="hl-string">"Initializing Workday SOAP client...")
    client = get_workday_client(WSDL_URL, TENANT_USERNAME, TENANT_PASSWORD)
    factory = client.type_factory(class="hl-string">'ns0')

    all_events = []
    for bp_type_name in BUSINESS_PROCESS_TYPES:
        print(fclass="hl-string">"\nFetching data for business process: {bp_type_name}")
        page = 1
        while True:
            print(fclass="hl-string">"  - Requesting page {page}...")
            request_data = factory.Get_Business_Process_Transactions_RequestType(
                Request_Criteria=factory.Business_Process_Transaction_Request_CriteriaType(
                    Transaction_Date_Range_Data=factory.Transaction_Date_Range_DataType(
                        Effective_From=START_DATE,
                        Effective_To=END_DATE
                    ),
                    Business_Process_Type_Reference=[factory.Business_Process_Type_ReferenceType(
                        Business_Process_Type_Name=bp_type_name
                    )]
                ),
                Response_Filter=factory.Response_FilterType(
                    Page=page,
                    Count=100  class=class="hl-string">"hl-comment"># Page size
                )
            )
            
            try:
                response = client.service.Get_Business_Process_Transactions(request_data)

                if response.Response_Results.Total_Results == 0:
                    print(class="hl-string">"  - No results found for this process type.")
                    break

                if not response.Response_Data or not response.Response_Data.Business_Process_Transactions:
                    print(class="hl-string">"  - Reached end of data.")
                    break
                
                transactions = response.Response_Data.Business_Process_Transactions
                print(fclass="hl-string">"  - Received {len(transactions)} transactions on this page.")

                for trans in transactions:
                    events = map_transaction_to_events(trans)
                    all_events.extend(events)

                if len(transactions) < 100:
                    print(class="hl-string">"  - Last page processed.")
                    break

                page += 1

            except Exception as e:
                print(fclass="hl-string">"An error occurred: {e}")
                break

    if not all_events:
        print(class="hl-string">"\nExtraction complete. No events were generated.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_events)}")
    df = pd.DataFrame(all_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [class="hl-string">'EmployeeId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'EventPerformer', 
            class="hl-string">'Department', class="hl-string">'JobRequisitionId', class="hl-string">'LifecycleEventType']
    df = df[cols]

    class=class="hl-string">"hl-comment"># Sort by employee and timestamp to create a chronological log
    df.sort_values(by=[class="hl-string">'EmployeeId', class="hl-string">'EventTimestamp'], inplace=True)

    output_filename = class="hl-string">'workday_h2r_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(fclass="hl-string">"Successfully exported event log to {output_filename}")

if __name__ == class="hl-string">'__main__':
    import requests class=class="hl-string">"hl-comment"># Add requests for the session object
    main()

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

このデータテンプレートを使って、採用から退職までのプロセスを詳しく把握しましょう。従業員ライフサイクルの改善を今すぐ始められます。

改善ガイドに戻る

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

採用から退職までの従業員ライフサイクルを今すぐ改善

改善につながるインサイトを得て、Workday HRのサイクルタイムを30％短縮しましょう。

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

クレジットカードは不要です。数分で設定できます。

採用から退職まで：従業員ライフサイクルのデータテンプレート

採用から退職まで：従業員ライフサイクルのデータテンプレート

採用から退職まで：従業員ライフサイクルの属性

採用から退職まで：従業員ライフサイクルのアクティビティ

データ抽出ガイド

WorkdayカスタムレポートとReport-as-a-Service（RaaS）

ステップ

設定

クエリの例 sql

Workday Web Services APIを使ったPythonスクリプトによるデータ抽出

ステップ

設定

クエリの例 python

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

採用から退職までの従業員ライフサイクルを今すぐ改善