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

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

Workday Onboarding

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

「Hire to Retire」（採用から退職まで）従業員ライフサイクルデータテンプレート

このテンプレートは、Hire to Retire プロセスを効果的に分析するために必要な不可欠なデータ属性とアクティビティに関する明確なガイドを提供します。堅牢なイベントログを構築するために必要な重要な情報を特定するのに役立ち、従業員ライフサイクルに関する正確な洞察を保証します。さらに、Workday Onboarding からこのデータを特に抽出するためのガイダンスも含まれています。

徹底的な分析のために収集すべき推奨属性
従業員ライフサイクル全体で追跡すべき主要アクティビティ
Workday Onboardingからのデータ抽出に関する実践的なガイダンス

イベントログについて初めての方へ：プロセスマイニングのイベントログ作成方法.

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

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

これらは、採用から退職までの従業員ライフサイクルプロセスの包括的分析のためにイベントログに含めることを推奨するデータフィールドです。

3 必須 5 推奨 14 任意

	名前	説明
	アクティビティ名 ActivityName	従業員ライフサイクル内の特定の時点で発生したイベントやタスクの名称です。
説明活動名は、「採用から退職まで」プロセスにおける特定のステップ（例：「オファー受諾」、「バックグラウンドチェック完了」、「昇進承認」など）を表します。これらの活動はプロセスマップのノードを形成し、従業員ジャーニーを構成するイベントの順序を示します。これらの活動を分析することで、組織はプロセスフローを理解し、頻繁なパスと稀なパスを特定し、遅延や手戻りが発生するステージを特定できます。一貫性のある明確な活動名は、正確で理解しやすいプロセスモデルを構築するために不可欠です。その重要性プロセスマップ内のステップを定義します。このステップがすべてのプロセスマイニング分析と可視化の基盤となります。取得元 Workdayトランザクションログ内のビジネスプロセスステップまたはイベント名から派生します。例オファーレター生成済みオンボーディングタスク完了退職処理開始
	イベントのタイムスタンプ EventTimestamp	アクティビティまたはイベントが記録された正確な日付と時刻です。
説明この属性は、各アクティビティの時間的コンテキストを提供し、いつ発生したかを記録します。これらのタイムスタンプの順序とタイミングは、プロセスフローを構築し、サイクルタイムや期間など、すべての時間ベースのメトリクスを計算するために使用されます。分析において、イベントタイムスタンプはプロセスパフォーマンスを理解する上で非常に重要です。これにより、ステップ間の時間を計算したり、遅延を特定したり、四半期ごとの採用スピードの比較など、異なる期間におけるプロセスの挙動を分析したりすることが可能になります。その重要性この属性は、イベントを正しく順序付け、サイクルタイムやボトルネックのようなすべてのパフォーマンス指標を計算するために不可欠です。取得元これは Workday におけるあらゆるビジネスプロセスのトランザクションログの標準的な要素で、しばしば「Effective Date」または「Completed Moment」と呼ばれます。例 2023-10-26T10:00:00Z2023-11-01T14:35:10Z2024-01-15T09:12:00Z
	従業員ID EmployeeId	従業員の一意の識別子です。組織内での全ライフサイクルにおける主要なケースIDとして機能します。
説明従業員IDは、採用から退職までのプロセス分析の要です。このIDによって、最初の求人応募から最終的な退職まで、関連するすべてのイベントが一つのまとまりのあるジャーニーとして紐付けられます。従業員IDを追跡することで、企業は役割変更、パフォーマンスレビュー、オンボーディングの手順など、従業員の在職期間に関する完全な履歴を構築できます。プロセスマイニングにおいて、すべてのアクティビティは従業員IDと関連付けられており、個々の従業員のライフサイクルだけでなく、組織全体の従業員ライフサイクルも包括的に把握できます。これにより、プロセスの期間分析、共通パスの特定、そして従業員のキャリア段階ごとに影響を与えるボトルネックの発見が可能になります。その重要性この属性は、一人の従業員に関するすべてのライフサイクルイベントを連携させ、完全なエンドツーエンドのプロセスビューを実現するために不可欠です。取得元これはWorkday HCMのコアフィールドであり、通常、従業員プロファイルやビジネスプロセストランザクションで確認できます。例 100234510087651011212
	イベントの終了時刻 EventEndTime	アクティビティの完了を示すタイムスタンプです。特に、測定可能な期間を持つタスクに適用されます。
説明 StartTimeはアクティビティの開始を示し、Event End Timeはその終了を示します。両者の差がアクティビティの処理時間を表します。これは、「Background Check」や「Performance Review」のような即時ではないタスクで特に役立ちます。分析において、この属性は ProcessingTime メトリクスを計算するために不可欠です。アクティビティ間の待機時間とアクティビティに実際に費やされた作業時間を区別するのに役立ち、プロセス内で時間がどこで使われているかをより正確に理解できるようになります。その重要性アクティビティの真の処理時間を計算可能にし、実際の作業時間と待機時間を区別するのに役立ちます。取得元 Workdayの一部のビジネスプロセスでは、開始イベントと完了イベントの両方のタイムスタンプがログに記録されます。これにより、イベントの結合が必要になる場合があります。例 2023-10-26T18:30:00Z2023-11-05T11:00:15Z2024-01-15T17:20:00Z
	イベント実行者 EventPerformer	そのアクティビティを実行したユーザー、または自動化されたシステムのエージェントです。
説明この属性は、タスクを完了する責任を持つ個人、ロール、またはシステムを特定します。例えば、オファーを承認する採用マネージャー、オンボーディングを開始する人事スペシャリスト、通知を生成するシステムプロセスなどがこれに当たります。イベント実行者を分析することは、リソースの割り当て、ワークロードの分散、ユーザーの活用状況を理解する上で重要です。これにより、負担過重なチームを特定したり、手作業で反復タスクを行うユーザーがいる場合の自動化の機会を明確にしたり、個人間や部門間のパフォーマンスの違いを分析したりするのに役立ちます。その重要性この属性は、ワークロードの分散、ユーザーパフォーマンスの分析を支援し、プロセスに関与している担当者を特定します。これは、的を絞った改善を行う上で重要です。取得元 Workdayのビジネスプロセスのトランザクションログで利用可能であり、通常、ステップを完了したユーザーに関連付けられています。例 jsmith@example.comr.davisシステムプロセス
	ライフサイクルイベントタイプ LifecycleEventType	プロセスをオンボーディング、昇進、退職手続きといった主要なライフサイクルタイプに分類します。
説明この属性は、全体の「採用から退職まで」のプロセスにおける、多様なジャーニーの高レベルな分類を提供します。各ケースを「オンボーディング」、「組織内異動」、または「退職」としてタグ付けすることで、プロセスマップをフィルタリングし、これらの個別のサブプロセスを単独で分析することがはるかに容易になります。例えば、「組織内異動・昇進時間」ダッシュボードを分析するには、ライフサイクルイベントタイプが「組織内異動」または「昇進」であるケースをフィルターします。このセグメンテーションは、特定のビジネス課題に対応する的を絞った分析やダッシュボードを作成するために不可欠です。その重要性従業員の全体的なジャーニーを個別のサブプロセスにセグメント化し、オンボーディング、オフボーディング、昇進に焦点を当てた分析を可能にします。取得元これは通常、データ変換中に特定の Workday ビジネスプロセス名（例：「Hire」、「Change Job」、「Terminate」）をこれらのカテゴリにマッピングすることで導出されます。例オンボーディング社内異動オフボーディングパフォーマンス管理
	求人リクイジションID JobRequisitionId	採用プロセスを開始させた求人申請の一意の識別子です。
説明求人申請IDは、求人の掲載、候補者のスクリーニング、オファーの発行といった採用初期段階のすべてのアクティビティを、特定の事業ニーズに紐付けます。これは、従業員ライフサイクルの採用フェーズにおける副ケースIDとして機能します。求人申請IDごとに分析することで、異なる役割や部門における採用プロセスの効率性に関するインサイトを得られます。申請の作成からオファーの承諾まで、採用プロセス全体のファネルを追跡するのに役立ち、「平均採用期間」のようなKPIをサポートします。その重要性採用前の全てのアクティビティを単一の識別子でグループ化することで、プロセスの採用部分の詳細な分析を可能にします。取得元 Workdayの採用モジュール内にあります。候補者の応募およびその後の採用イベントに関連付けられています。例 REQ-2023-05-101REQ-2024-01-230REQ-2023-11-087
	部署 Department	従業員が所属する部署です。
説明この属性は、従業員の所属部門（例えば、「営業」、「エンジニアリング」、「人事」など）を表します。これは、組織内の異なる部門間でプロセスパフォーマンスをセグメント化し、比較するための重要なディメンションです。プロセス分析において、部門ごとにフィルターをかけることで、「エンジニアリング部門の採用にかかる時間は営業部門よりも長いのか？」や、「オンボーディングにおける逸脱の発生率が最も高い部門はどこか？」といった疑問に答えることが可能になります。これにより、局所的な問題を特定し、プロセス改善をカスタマイズするのに役立ちます。その重要性強力な比較分析を可能にし、プロセスの非効率が特定のビジネス領域に集中しているかを特定するのに役立ちます。取得元これは、Workday HCM における従業員の主要な職務および組織データの一部であり、そのポジションにリンクされています。例エンジニアリング営業およびマーケティング財務
	SLA目標日 SlaTargetDate	パフォーマンスレビューのような特定のアクティビティを完了すべき目標日付です。
説明この属性は、特定のタスクに対するSLA（サービスレベルアグリーメント）の期限を定義します。これは、特定のプロセスにかかる時間の期待値を設定し、パフォーマンス測定のベンチマークとして機能します。「人事評価の適時性」のようなKPIや、SLA遵守に焦点を当てたダッシュボードにとって、この属性は不可欠です。実際の完了日（EventTimestamp）とSlaTargetDateを比較することで、違反を自動的に特定し、期日内の達成状況を測定し、遅延をプロアクティブに管理することが可能です。その重要性定刻通りのパフォーマンスを測定するための明確なベンチマークを提供し、SLA遵守KPIの算出に不可欠です。取得元 Workdayにおける人事評価のようなプロセスでは、しばしばdue dateが設定されます。このデータは、プロセスイベントとともに抽出する必要があります。例 2023-12-31T23:59:59Z2024-06-30T23:59:59Z
	SLA違反か IsSlaViolated	アクティビティが目標のSLA期限後に完了したかどうかを示すブールフラグです。
説明この計算属性は、プロセスステップがサービスレベルアグリーメント（SLA）を満たしたかどうかを示す真偽値インジケーターです。これは、アクティビティの完了タイムスタンプ（EventTimestamp）とその期限（SlaTargetDate）を比較することによって算出されます。このフラグは、SLA違反のカウントや可視化を容易にするため、ダッシュボードやレポート作成において非常に有用です。「人事評価の適時性」のようなKPIの基礎となり、期日超過タスクに関するアラートやレポートの作成を簡素化し、チームが最も重要な遅延に注力できるよう支援します。その重要性合意された期限が守られなかったすべてのケースを明確にフラグ付けすることで、パフォーマンスモニタリングを簡素化します。取得元計算フィールド: EventTimestampがSlaTargetDateより大きい場合はtrue、それ以外はfalse。例 truefalse
	Time to Hire TimeToHire	求人申請が作成されてから候補者がオファーを承諾するまでの合計時間です。
説明 Time to Hire は、採用プロセス全体の効率性を測定する重要な採用 KPI です。これは、同じ従業員または要員に対する「Job Requisition Created」イベントから「Offer Accepted」イベントまでの期間として計算されます。この計算属性は、「Average Time-to-Hire」KPI および関連するダッシュボードの基礎となります。これを経時的に追跡することで、人事部門はプロセス改善の効果を測定し、ソーシングや面接におけるボトルネックを特定し、マネージャーに対して現実的な採用タイムラインを設定することができます。その重要性採用プロセスの効率性を直接測定し、あらゆる人事組織にとって不可欠なKPIです。取得元「求人票作成」アクティビティのタイムスタンプから「内定受諾」アクティビティのタイムスタンプまでの期間を算出することで、ケースレベルで計算されます。例 35 days62 days28 days
	オンボーディングプラン名 OnboardingPlanName	新入社員に割り当てられた、特定のオンボーディングテンプレートやプランの名称です。
説明 Workdayでは、さまざまな役割、勤務地、役職レベルに合わせて異なるオンボーディングプランを作成できます。この属性は、新入社員にどの特定のプランが適用されたかを特定します。オンボーディングプラン名で分析することで、さまざまなオンボーディング戦略の有効性と効率性を評価できます。これにより、例えば「役員オンボーディングプラン」と「標準従業員オンボーディングプラン」を直接比較し、どちらがより高いタスク完了率や速いサイクルタイムを達成しているかを確認できます。その重要性これは、さまざまなオンボーディングプログラムのパフォーマンスを評価し、ベストプラクティスや改善点を特定するのに役立ちます。取得元この情報は、Workdayのオンボーディングモジュール内、特に採用ビジネスプロセスに関連して利用可能であると考えられます。例標準的な企業オンボーディング営業チームのオンボーディング役員オンボーディングプラン
	コンプライアンス活動か IsComplianceActivity	アクティビティが必須のコンプライアンスまたは規制ステップであるかを示すブールフラグです。
説明このフラグは、法的、規制的、またはポリシーコンプライアンスにとって不可欠なアクティビティを識別します。例えば、ポリシー承諾書への署名や、義務的なトレーニングの完了などが含まれます。これにより、これらの重要なタスクを通常の事務的なものと区別するのに役立ちます。分析においては、この属性を使用することで、「重要コンプライアンスアクティビティ実施率」のようなコンプライアンスに特化したダッシュボードやKPIを作成できます。組織は、すべての従業員に対して最も重要な規制上のステップが期限内に完了しているかをモニタリングし、確認できるようになり、結果として組織リスクを低減します。その重要性重要なコンプライアンスステップに焦点を当てた監視を可能にし、規制順守とリスク軽減を確実にします。取得元これは導出属性であり、通常、データ変換中に、既知のコンプライアンス関連アクティビティ名のリストを真偽値フラグにマッピングすることで作成されます。例 truefalse
	ソースシステム SourceSystem	イベントデータが抽出されたシステムです。このケースではWorkdayオンボーディングが該当します。
説明この属性は、データの発生源を特定します。このビューではWorkday オンボーディングに焦点を当てていますが、完全な「採用から退職まで」のプロセスには、採用管理システム（ATS）や別の給与プロバイダーなど、他のシステムからのデータが関与する場合があります。ソースシステムを明確にすることは、データガバナンスとイベントのコンテキストを理解する上で重要です。マルチシステム分析においては、このフィールドによって、特定のシステムからのイベントにプロセスビューをフィルタリングしたり、異なるシステム間のハンドオフを分析したりすることが可能になります。その重要性データの出所に関する重要なコンテキストを提供し、データの検証や複数のシステムからのデータを組み合わせた分析に不可欠です。取得元これは通常、データ抽出および変換プロセス中に加えられる静的な値（「Workday Onboarding」）です。例 Workday OnboardingWorkday HCM
	最終データ更新 LastDataUpdate	このイベントのデータがソースシステムから最後に更新された日時を示すタイムスタンプ。
説明この属性は、データセットが最後に更新された日時を示します。これにより、分析対象データの鮮度が明確になり、プロセスマイニングの洞察に基づいたタイムリーで的確なビジネス上の意思決定を行う上で非常に重要です。ダッシュボードや継続的なモニタリングにおいて、このタイムスタンプは、ユーザーが最新のデータを閲覧しているかを確認するのに役立ちます。これは、データの整合性を保ち、分析結果に対するユーザーの信頼を維持するための重要なメタデータです。その重要性プロセス分析の関連性と正確性にとって極めて重要であるデータの鮮度を、ユーザーが認識していることを保証します。取得元これは、データインジェストまたは ETL (Extract, Transform, Load) プロセス中にデータセットに生成され、付与されるメタデータフィールドです。例 2024-03-15T02:00:00Z2024-03-16T02:00:00Z
	処理時間 ProcessingTime	イベントに対する実作業に費やされた期間。
説明このメトリクスは、アクティビティの開始から終了までの経過時間（EventEndTime - StartTime）を計算します。これは、アクティビティ間の待機時間ではなく、実際の作業期間を示すものです。例えば、バックグラウンドチェックがどれくらいの期間アクティブに処理されていたかを測定できます。 Processing Timeを分析することで、単にどのプロセス段階で最も長い遅延が発生しているかだけでなく、どの特定のタスクが最も労力を要しているかを特定できます。これにより、作業自体をより効率的にすることを目指した、より的を絞った改善が可能になります。その重要性付加価値のある作業に費やされた時間をアイドル時間から分離し、タスクレベルでの効率改善に向けた明確な目標を提供します。取得元計算フィールド: EventEndTime - EventTimestamp. 例 2 hours5 days30分
	場所 Location	従業員の職務に関連する勤務地またはオフィスを示します。
説明所在地属性は、従業員が拠点とする国、州、または都市を特定します。この地理的な側面は、異なる地域間でプロセスパフォーマンスとコンプライアンスを比較する上で不可欠です。所在地を使用した分析により、採用期間、オンボーディング効率、または退職手続きにおける地域間の差異を発見できます。「ドイツでは米国よりもバックグラウンドチェックに時間がかかるのか？」といった疑問に答えるのに役立ち、地域固有の規制に対するコンプライアンス監視をサポートします。その重要性現地の管理体制、規制、文化などの影響を受ける可能性のある地域的なプロセス変動を特定するため、地理的分析を行うことが可能になります。取得元 Workday HCMにおける従業員のポジションおよび組織への割り当てデータの一部です。例アメリカ - ニューヨークドイツ - ベルリンインド - バンガロール
	役職ID PositionId	従業員が担当する特定のポジションまたは職務役割の一意の識別子です。
説明ポジションIDは、組織の構造内で従業員が占める特定の役割を識別します。各ポジションには、職務プロファイル、所在地、報告体制などの定義済みの属性があります。複数のポジションが同じ役職名を共有する可能性があるため、役職名よりも詳細です。ポジションIDごとに分析することで、特定の役割に関連するプロセスを理解するのに役立ちます。たとえば、すべての「シニアソフトウェアエンジニア」ポジションのオンボーディングジャーニーを分析し、その役割に固有の共通パターンや遅延があるかどうかを確認できます。その重要性特定の役割に基づいた詳細な分析を可能にし、社内の多様な職種でプロセスがどのように異なるかを理解するのに役立ちます。取得元 Workday HCMにおける従業員の職務アサインメントに関連付けられた標準フィールドです。例 POS-1001POS-2345POS-8762
	手戻り IsRework	アクティビティが、同じケース内の以前のステップの繰り返しであるかどうかを示すブールフラグです。
説明この属性は、同じ従業員に対してタスクが複数回実行される手戻りの発生を特定します。例えば、不正確な書類の再提出や、失敗したバックグラウンドチェックの再実行などが含まれます。通常、ケースのイベントログ内で同じアクティビティ名が複数回出現することによって手戻りは識別されます。手戻りの分析は、プロセスの効率と品質を向上させる上で非常に重要です。IsRework フラグを使用することで、手戻りの量を容易に定量化し、その根本原因を特定し、初回での適切な処理を目指した改善策の効果を測定できます。これは、「手戻り・繰り返し分析ダッシュボード」を直接サポートします。その重要性繰り返されているアクティビティにフラグを立てることで、プロセスの非効率性や無駄を定量化し、品質やコミュニケーションの問題を示します。取得元これは計算フラグです。同じケース内で繰り返し発生するアクティビティを検出することで、プロセスマイニング分析中にこのロジックが適用されます。例 truefalse
	退職理由 TerminationReason	従業員の組織からの退職理由です。
説明この属性は、従業員の在籍期間が終了した理由（「自己都合退職」、「会社都合（業績不振など）」、「定年退職」など）を示します。この情報は、離職率分析やオフボーディングプロセスにとって非常に重要です。プロセスマイニングでは、退職理由によってオフボーディングプロセスの背景や意味合いが明確になります。これにより、退職の種類によってオフボーディングの手順が異なるか、または所要時間が異なるかを分析できます。これは、従業員の離職状況を深く理解し、それぞれの状況に合わせた適切なオフボーディングプロセスが運用されていることを確認するのに役立ちます。その重要性退職プロセスの分析のために重要なコンテキストを提供し、プロセス上の問題と離職理由の関連付けを支援します。取得元 Workdayの「従業員解雇」ビジネスプロセス中に捕捉されます。例自己都合退職会社都合退職退職
	雇用ステータス EmploymentStatus	従業員の現在の雇用ステータス（例：Active（在職中）、Terminated（退職済み）、On Leave（休職中）など）
説明この属性は、組織内での従業員の現在のステータスを示します。これは、従業員がライフサイクルを進むにつれて変化する動的なフィールドです。例えば、新規採用者は「Pre-Hire」または「Onboarding」として始まり、完了時に「Active」となります。プロセスマイニングにおいて、この属性は貴重な状態情報を提供します。例えば、給与計算が「Active」な従業員のみに設定されているかを確認するなど、プロセスコンプライアンスのチェックに利用できます。また、「Terminated」状態の全従業員のオフボーディングプロセスを分析するなど、特定の母集団をフィルタリングする際にも役立ちます。その重要性従業員の現在の状況のスナップショットを提供します。これはプロセスロジックの検証や、特定の従業員集団への分析の絞り込みに役立ちます。取得元 Workday HCMにおける従業員プロファイルの主要フィールドです。例アクティブ終了済み休職中採用前
	雇用形態 EmploymentType	従業員が「フルタイム」「パートタイム」「契約社員」「インターン」のいずれであるかを示します。
説明この属性は、雇用契約の性質を分類します。雇用形態が異なると、オンボーディング、給与計算、福利厚生の設定など、それぞれのプロセスが異なることがよくあります。この属性をフィルターとして活用することで、組織はさまざまな従業員区分におけるライフサイクルプロセスを比較できます。例えば、契約社員のオンボーディングプロセスが正社員の場合と比べて著しく速いのか、あるいはコンプライアンス遵守の点で劣るのか、といった点を明らかにすることが可能です。これにより、的を絞ったプロセス改善を行うことができます。その重要性正社員や契約社員など、異なる手順をたどる可能性のある様々な従業員カテゴリ間のプロセス変動を比較するのに役立ちます。取得元 Workday HCMにおける従業員の職務詳細にある標準フィールドです。例フルタイムパートタイム契約社員インターン

必須推奨任意

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

これらは、従業員ライフサイクルの正確な発見と分析のために、イベントログに含めるべき主要なプロセスステップとマイルストーンです。

7 推奨 8 任意

	アクティビティ	説明
	オンボーディングタスク完了	新入社員に割り当てられたすべてのオンボーディングタスクの完了を表します。このイベントは通常、従業員のオンボーディングビジネスプロセス全体のステータスが「正常に完了」になったときに推測されます。
その重要性これは、新入社員が完全にオンボーディングされたことを示す重要なマイルストーンです。Onboarding Cycle Time KPIの測定、およびオンボーディングジャーニーへの順守状況の分析における終点となります。取得元すべての必須ステップとタスクが完了した後に完了する、親オンボーディングビジネスプロセスの完了タイムスタンプから推測されます。取得従業員のオンボーディングビジネスプロセス全体の完了タイムスタンプから推測されます。イベントタイプ inferred
	オンボーディング開始	Workday オンボーディングモジュール内での新入社員のオンボーディングジャーニーの開始を示します。具体的には、オンボーディングタスクとワークフローのセットが新入社員に割り当てられ、通常は採用プロセスの完了によってトリガーされたときに捕捉されます。
その重要性これは、オンボーディングジャーニーの効率性を分析するための開始点です。オンボーディングタスクの完了率を測定し、プロセス逸脱を特定するのに役立ちます。取得元新入社員向けにオンボーディングビジネスプロセスまたは同様のワークフローがトリガーされた際の開始イベントとして記録されます。取得新入社員向けにオンボーディングビジネスプロセスがトリガーされた際にログに記録されるイベント。イベントタイプ explicit
	内定受諾済み	このアクティビティは、候補者が求人オファーを正式に承諾した際に発生します。多くの場合、Workday内でオファーレターに電子署名することで行われます。これは、候補者がオファープロセスにおける「レビューして署名」ステップを完了した際に捕捉される重要なマイルストーンです。
その重要性このマイルストーンは、コア採用フェーズを終了させ、採用前およびオンボーディングアクティビティをトリガーします。Time-to-Hire KPI を測定するための重要な要素です。取得元これは、候補者が「Job Application」ビジネスプロセス内で採用オファーの承諾ステップを完了した際に記録される明示的なイベントです。取得候補者がオファーを受諾するアクションは、求人応募BP内で完了したステップとしてログに記録されます。イベントタイプ explicit
	従業員解雇	これは従業員ライフサイクルにおける最終アクティビティであり、システム上での雇用が正式に終了することを示します。このイベントは、「Terminate Employee」ビジネスプロセスが正常に完了した際に捕捉されます。
その重要性これは、Hire to Retire プロセスの最終的な終了イベントです。オフボーディングサイクルタイムの測定、およびプロセスの完了確認における終点となります。取得元「従業員解雇」ビジネスプロセスの完了イベントとして明示的にログに記録されます。この時点以降、従業員記録は非アクティブになります。取得「従業員解雇」ビジネスプロセスが正常に完了した際にログに記録されるイベント。イベントタイプ explicit
	採用プロセス完了	候補者の記録が Workday HCM において正式に従業員記録に変換される重要なアクティビティです。このイベントは、「Hire」ビジネスプロセスが正常に完了した際に明示的に捕捉されます。
その重要性このイベントは、候補者から従業員への正式な移行を示すものであり、オンボーディングサイクルタイムを追跡するための重要なマイルストーンとなります。これは、従業員がHCMシステムに正式に登録されたことを意味します。取得元従業員の「採用」ビジネスプロセスの完了イベントとして明示的にログに記録されます。ビジネスプロセスログには正確なタイムスタンプが含まれます。取得「採用」ビジネスプロセスが正常に完了した際にログに記録されるイベント。イベントタイプ explicit
	求人票作成済み	このアクティビティは、Workdayで新規求人申請が作成され承認された際の採用プロセスの正式な開始を示します。「求人申請作成」ビジネスプロセスが正常に完了した際に、このイベントが明示的に捕捉されます。
その重要性これは、採用ライフサイクル全体の主要な開始イベントです。このアクティビティから「Offer Accepted」までの時間を分析することは、Time-to-Hire KPI を測定する上で不可欠です。取得元このイベントは、Workday リクルーティングにおける「求人票作成」ビジネスプロセスが正常に完了した際にログに記録されます。このビジネスプロセスのイベントログからタイムスタンプが提供されます。取得「求人票作成」ビジネスプロセスが完了した際にログに記録されるイベント。イベントタイプ explicit
	退職処理開始	このアクティビティは、退職する従業員のオフボーディングプロセスの開始を示します。管理者または人事担当者がWorkdayで「従業員解雇」ビジネスプロセスを開始した際に、明示的に捕捉されます。
その重要性これは、オフボーディングライフサイクル全体の主要な開始イベントです。Average Offboarding Cycle Time KPI を測定するための出発点となります。取得元これは、Workday HCM における「Terminate Employee」ビジネスプロセスの開始時に記録される明示的なイベントです。取得「従業員解雇」ビジネスプロセスが開始された際にログに記録されるイベント。イベントタイプ explicit
	オファーレター生成済み	候補者に対して正式なジョブオファーが生成される時点を表します。これは通常、Workdayの「ジョブアプリケーション」ビジネスプロセス内の明示的なステップです。
その重要性これを追跡することは、面接完了後にオファーを正式化するまでにかかる時間を理解するのに役立ちます。ここでの遅延は、候補者が辞退する原因となる可能性があります。取得元「求人応募」ビジネスプロセスのイベントログから捕捉され、具体的には「ドキュメント生成」または類似のオファーステップの完了を示します。取得「応募BP」の「オファー生成」ステップが完了した際にログに記録されるイベント。イベントタイプ explicit
	オフボーディングタスク完了	資産返却や知識移転など、必要なすべての退職タスクの完了を表します。このイベントは、退職チェックリストまたはビジネスプロセスが完了ステータスになったときに推測されます。
その重要性これらのタスクの完了を追跡することは、安全でコンプライアンスに準拠したオフボーディングを確保するために不可欠です。遅延はセキュリティリスクをもたらし、劣悪な体験を生み出す可能性があります。取得元オフボーディングビジネスプロセスの完了タイムスタンプ、あるいは従業員に割り当てられたすべてのオフボーディングタスクが完了とマークされた時点から推測されます。取得オフボーディングチェックリストまたは関連ビジネスプロセスの完了から推測されます。イベントタイプ inferred
	バックグラウンドチェック完了	採用前スクリーニングプロセスの完了を表します。これは、バックグラウンドチェックのステータスが「完了」に更新されたときに、手動で、またはインテグレーション経由でキャプチャされます。
その重要性このアクティビティは、バックグラウンドチェック期間 KPIを測定するための終点です。このアクティビティの遅延は、新入社員の開始日に直接影響を与えます。取得元「バックグラウンドチェック」ビジネスプロセスまたは関連オブジェクトのステータス変更から捕捉され、「完了」や「合格」のような最終ステータスを示します。取得背景調査のステータスフィールドが最終状態に変わった時点のタイムスタンプから推測されます。イベントタイプ inferred
	バックグラウンドチェック開始	これは、オファーを受け入れた候補者に対する採用前スクリーニングプロセスの開始を示します。イベントは、バックグラウンドチェックステップが開始された際に捕捉され、多くの場合、サードパーティベンダーとの連携をトリガーします。
その重要性バックグラウンドチェックの期間は、採用プロセスにおいてしばしばボトルネックとなります。この活動は、「バックグラウンドチェック期間KPI」を測定するための開始点です。取得元「背景調査」などのビジネスプロセス内のステップとして記録されます。このステップはしばしば全体の採用ワークフローの一部であり、開始タイムスタンプが記録されます。取得「背景調査」ビジネスプロセスまたは関連するステップが開始された際にログに記録されるイベント。イベントタイプ explicit
	人事評価完了	このアクティビティは、従業員の正式なパフォーマンスレビューサイクルが完了したことを示します。「パフォーマンスレビュー」ビジネスプロセスが最終承認状態に達した際に捕捉されます。
その重要性これらのイベントを追跡することは、パフォーマンス管理の適時性と頻度を分析するために不可欠です。これは Performance Review Timeliness KPI を直接サポートします。取得元従業員に対する「パフォーマンスレビュー開始」ビジネスプロセスの成功完了イベントとして記録されます。取得「人事評価」ビジネスプロセスが正常に完了した際にログに記録されるイベント。イベントタイプ explicit
	役割変更開始	異動や昇進などの社内移動イベントの開始を表します。これは、マネージャーまたは人事パートナーが従業員に対して「ジョブ変更」ビジネスプロセスを開始したときにキャプチャされます。
その重要性このアクティビティは、社内異動効率と承認時間を測定するための起点です。従業員のキャリアアップにおけるボトルネックを特定するのに役立ちます。取得元これは、Workday HCM における「Change Job」ビジネスプロセスの開始時に記録される明示的なイベントです。取得従業員に対して「職務変更」ビジネスプロセスが開始された際にログに記録されるイベント。イベントタイプ explicit
	昇進承認済み	従業員の昇進の最終承認を示します。このアクティビティは、「職務変更」または関連する報酬ビジネスプロセスが完全に承認され、完了したときに捕捉されます。
その重要性これは、Internal Mobility Approval Time KPI を測定するための終点です。重要なキャリアマイルストーンの正常な完了を確認します。取得元変更理由が昇進である「職務変更」ビジネスプロセスの成功完了イベントとして記録されます。取得「職務変更」ビジネスプロセスが「昇進」理由で完了した際にログに記録されるイベント。イベントタイプ explicit
	給与設定完了	このアクティビティは、新入社員の給与計算を処理するために必要なすべての情報が入力および確認されたことを示します。これは、オンボーディングプロセスまたは採用ビジネスプロセス内の特定のステップの完了として捕捉される場合があります。
その重要性従業員が初回給与から正確かつ期日通りに支払われることを保証します。このアクティビティは、給与設定時間のKPIの終点であり、報酬開始の遅延を浮き彫りにします。取得元オンボーディングビジネスプロセス内で、完了したチェックリスト項目、または「支払い選択の入力」のような特定のステップとして捕捉されます。取得ビジネスプロセス内での特定の給与関連タスクまたはステップの完了。イベントタイプ explicit

推奨任意

抽出ガイド

Workday Onboardingからデータを取得する方法

ステップ

Workdayへのログイン: カスタムレポート作成権限（Report Writer）と、必要なデータドメイン（例：Staffing、Core HCM、Onboarding、Performance Management）へのアクセス権限を持つユーザーアカウントで、Workdayインスタンスにログインします。
新規カスタムレポートの作成: 「カスタムレポートの作成」タスクに移動します。レポートタイプは「Advanced」を選択してください。このタイプは、複雑なマルチソースレポートを作成する際に必要となります。
プライマリビジネスオブジェクトの定義: プライマリの「Data Source」を「Business Process Transactions」に設定します。このオブジェクトは、すべてのビジネスプロセスイベントの包括的なビューを提供し、イベントログの作成に不可欠です。最初にイベントが除外されないよう、「All Business Process Transactions」を選択してください。
初期カラムの追加: 「Columns」タブで、イベントログの基盤となるフィールドを追加します。以下から開始してください：
- Worker の Employee ID（Business Process Transaction）を 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' であり、かつ Step が 'Successfully Completed' である」という条件を設定し、「Hire Process Completed」というテキストを返します。必要な15のアクティビティすべてに対して、同様のフィールドを作成します。
マスター計算フィールドの作成: 最終的な「Lookup Related Value」または「Evaluate Expression」の計算フィールドをActivityNameという名前で作成します。このフィールドは、前のステップで作成した個々のアクティビティフィールドすべてを連結し、各行に1つのアクティビティ名のみが返されるようにします。
ユニオンレポートとしての構成: 異なるビジネスプロセスからのイベントをスムーズに結合するため、レポートを「Composite」レポートに変換し、「Union」サブレポートタイプを使用します。主要なライフサイクルプロセス（例：「Hire」、「Onboarding」、「Change Job」、「Terminate」）ごとに個別のデータソースを作成します。各サブレポート内で、特定のビジネスプロセスタイプをフィルタリングし、その関連するステップを標準出力カラム（EmployeeId、ActivityName、EventTimestampなど）にマッピングします。
プロンプトとフィルターの設定: データ抽出期間をユーザーが指定できるように、日付範囲のプロンプトを追加します。必要に応じて、特定の会社やSupervisory Organizationにデータを制限するためのフィルターを追加します。これはパフォーマンス管理において非常に重要です。
Webサービスとしての有効化: レポート定義の「Advanced」タブに移動します。「Enable as Web Service」ボックスにチェックを入れます。これにより、レポートはReport-as-a-Service（RaaS）エンドポイントとして公開されます。
APIオプションの設定: 「Web Service API Options」の下で、ダウンストリームシステムでの解析を容易にするために、出力形式としてJSONを選択します。API URLの一部となる「Namespace」と「Report Name」を記録しておいてください。
デプロイとテスト: Workday UIからレポートを保存し、実行してデータを検証します。確認が完了したら、ブラウザまたはAPIクライアント（Postmanなど）を介してRaaS URLにアクセスし、ウェブサービスエンドポイントをテストします。URL形式は通常、https://[Your Workday Host]/ccx/service/[Your Tenant]/Report_Service/[Report Owner]/[Report Name]となります。
抽出のスケジュール設定: 統合ツールまたはETLツールを使用して、RaaS URLへの定期的な呼び出しをスケジュールし、目的の日付範囲パラメーターを渡して、イベントログデータをプロセスマイニングツールに取り込みます。

設定

レポートタイプ: 高度。これは、計算フィールドと結合されたサブレポートをサポートするために必要です。
主要データソース / ビジネスオブジェクト: 「Business Process Transactions」。このオブジェクトは、Workdayにおけるすべてのプロセスの開始、ステップ、完了の記録が含まれており、基盤となります。
計算フィールド: 生のビジネスプロセスイベント（例: 「Hire BP, Step: Propose Compensation, Status: Completed」）をクリーンなアクティビティ名（例: 「Hire Process Completed」）に変換するには、「Evaluate Expression」計算フィールドの広範な使用が不可欠です。
プロンプト: 「完了日」フィールドに基づいて「開始日」と「終了日」のプロンプトを設定します。これにより、段階的または限定的なデータ抽出が可能になります。
フィルタリング: データ量を管理し、組織の関連部分に分析を集中させるため、「会社」または「監督組織」でフィルタリングすることを強くお勧めします。また、従業員のライフサイクルに関連しないビジネスプロセスは除外してください。
ウェブサービスオプション: レポートはウェブサービス（「RaaS」）として有効化が必要です。出力形式は、幅広い互換性のためJSONに設定してください。
セキュリティと権限: レポートを作成および実行するユーザーは、関連するすべてのイベントと属性を表示できるよう、以下のデータドメインへのアクセスが必要です：「Business Process Transactions」、「Worker Data (Core HCM)」、「Staffing」、「Onboarding」、さらに場合によっては「Compensation」と「Performance Management」。

a クエリ例 config

/*
 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」ウェブサービスを見つけ、その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 ヒューマンキャピタルマネジメント (HCM) ウェブサービス用のWSDL URLが必要です。これはテナント固有のもので、Workdayの「Public Web Services」レポートで確認できます。
認証: スクリプトは統合システムユーザー (ISU) とパスワードによる基本認証を使用します。このユーザーが必要なAPIドメインに対するセキュリティ権限があることを確認してください。
ビジネスプロセスタイプ: 抽出ロジックの核となる部分では、クエリ対象のビジネスプロセス定義のリストを利用します。このリストは、Workdayインスタンスで使用されている名称（例: Hire、Onboarding、Change Job、Terminate Employee、Create Job Requisition）と一致するよう、スクリプトで設定が必要です。
日付範囲: スクリプトにはSTART_DATEとEND_DATEパラメーターが設定されています。初回実行時には、データ量やAPI応答時間を考慮し、3～6か月程度の短い期間での使用をお勧めします。本番環境では、期間を延長したり、段階的なロードのためにスケジュールしたりすることが可能です。
ページネーション: スクリプトは、ページ分割されたAPIコールにより、大量のデータセットを処理できるように構築されています。ページサイズはデフォルトで100に設定されており、これはタイムアウト回避のための一般的かつ安全な値ですが、必要に応じて調整できます。

a クエリ例 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()

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

「Hire to Retire」（採用から退職まで）従業員ライフサイクルデータテンプレート

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

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

抽出ガイド

Workday Custom Report with Report-as-a-Service (RaaS)

ステップ

設定

a クエリ例 config

Workday Web Services API経由でのPythonスクリプトによる抽出

ステップ

設定

a クエリ例 python

今すぐ始めますか？

今すぐ従業員の「採用から退職まで」のライフサイクルを最適化