> 継続的なプロセス改善 > 採用から退職まで：ポジション管理 > Workday HCM > データテンプレート

採用から退職まで：ポジション管理のデータテンプレート

Workday HCM

採用から退職までのポジション管理の属性 (21) 採用から退職までのポジション管理のアクティビティ (13) 抽出ガイド (3)

採用から退職まで：ポジション管理のデータテンプレート

このテンプレートでは、採用から退職まで：ポジション管理プロセスを分析するために必要なデータを収集する手順を示します。収集すべき重要な属性、追跡する主要なアクティビティ、Workday HCMからデータを抽出するための具体的なガイダンスをまとめています。このリソースを使ってイベントログを整え、プロセスマイニングによる詳細な分析を始められる状態にしてください。

収集を推奨する属性
追跡する主要なアクティビティ
抽出ガイド

イベントログを初めて扱いますか。学ぶプロセスマイニングのイベントログを作成する方法.

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

採用から退職までのポジション管理の属性

採用から退職までのポジション管理を詳細に分析するため、イベントログに含めることを推奨するデータ項目です。

3 必須 7 推奨 11 任意

	名前	説明
	ポジションID PositionId	組織内の特定のポジションを識別する一意のIDです。Position Managementプロセスの主なケース識別子として機能します。
説明 Position IDは、Position Managementプロセス分析の基盤となる項目です。各IDは、初回の申請と作成から、変更、再分類、最終的な無効化または終了まで、1つのポジションのライフサイクルを表します。プロセスマイニングでは、この属性を使って、承認、データ変更、ステータス更新など、関連するすべてのアクティビティを特定のケースに関連付けます。これにより、ポジションの経緯をエンドツーエンドで把握でき、ポジションごとの処理時間、プロセスバリエーション、コンプライアンスを分析できます。重要な理由ポジションのライフサイクル全体を追跡するうえで欠かせません。エンドツーエンドのプロセス分析を可能にし、特定のケースにおけるボトルネックや逸脱の特定に役立ちます。入手先 Workday HCMの主要な識別子であり、通常はStaffingおよびPosition Managementに関するレポートやビジネスプロセスデータで利用できます。例 POS-0012345POS-0067890POS-0112233
	アクティビティ名 ActivityName	発生した特定のビジネスプロセスのステップまたはイベントの名称です。例として「Position Created」や「Budget Approved」があります。
説明アクティビティ名は、Position Managementのライフサイクルにおける個々のステップを示します。これらのイベントがプロセスマップの構成要素となり、各ポジションで実行された操作の順序を示します。アクティビティを分析すると、プロセスフローを可視化し、一般的な経路とまれな経路を特定し、主要なマイルストーン間の所要時間を測定できます。「Position Request Initiated」、「Position Attributes Modified」、「Position Closed」などの例を組み合わせることで、業務の流れを把握できます。重要な理由プロセスマップの作成とプロセスフローの可視化に欠かせない属性です。遅延や手戻りの原因となる特定のイベントも特定できます。入手先 Workdayのビジネスプロセスフレームワークのトランザクションログから抽出します。ビジネスプロセス定義の各ステップで、イベントレコードが生成されます。例ポジション申請を開始マネージャー承認を提出ポジションを作成ポジションを無効化
	イベント時刻 EventTime	特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプです。
説明イベント時刻は、プロセス内の各アクティビティの日時を記録する正確なタイムスタンプです。処理時間、待機時間、所要時間の計算など、時間に基づく分析に欠かせません。プロセスマイニングでは、このタイムスタンプを使ってイベントを時系列に並べ、プロセスフローを構成するアクティビティの順序を作成します。パフォーマンス診断の基盤となり、ボトルネックの特定、処理量の分析、SLAのモニタリングを可能にします。重要な理由イベントの順序付け、処理時間や所要時間など時間に基づく指標の計算、プロセスのボトルネック診断に欠かせません。入手先このタイムスタンプは、Workday HCMのすべてのビジネスプロセストランザクションで自動的に記録されます。例 2023-04-15T09:00:00Z2023-04-15T14:35:10Z2023-04-18T11:21:05Z
	コストセンター CostCenter	ポジションに関連付けられた財務上のコストセンターです。予算管理や財務レポーティングに使用されます。
説明 Cost Centerは、ポジションを特定の予算に関連付ける財務ディメンションです。コストを追跡し、人員配置が財務計画に沿っていることを確認するうえで欠かせません。プロセスマイニングでは、予算承認や財務への影響に関する分析で重要な属性です。コストセンターごとの予算承認時間の違いを把握したり、ポジション管理のアクティビティと財務上の結果を関連付けたりできます。また、同様の財務単位間で役割属性を標準化する際にも役立ちます。重要な理由分析に財務上の視点を加え、予算単位ごとのプロセス表示や、予算関連のボトルネック分析を可能にします。入手先 Workday HCMでポジションに割り当てられる財務情報、つまり「Worktags」の一部です。例 CC4010_MARKETINGCC2050_RD_SOFTWARECC7000_ADMIN
	ポジションステータス PositionStatus	「Open」、「Filled」、「Frozen」、「Closed」など、ポジションの現在または過去のステータスです。
説明ポジションステータスは、特定の時点におけるポジションの状態を示します。この属性は、ポジションの現在の募集状況とライフサイクルの段階を把握するうえで重要です。分析では、ステータスでフィルタリングすることで、プロセスの特定の部分に焦点を当てられます。たとえば、「Frozen」ステータスのポジションを分析すると、リソースがどのくらいの期間拘束されているかを確認する滞留期間レポートを作成できます。ステータス間の遷移を追跡することは、プロセスフローを理解するうえで重要です。重要な理由ポジションの状態に関する重要なコンテキストを提供し、凍結されたポジションの経過期間の分析や、ライフサイクル全体における進捗の追跡を可能にします。入手先 Workday HCMのポジションオブジェクトに標準フィールドとして用意されています。例募集中：承認済み充足済み凍結終了
	ユーザー User	アクティビティを実行した担当者のユーザーIDまたは氏名です。
説明承認の提出やポジション属性の変更など、プロセス内の特定のタスクを完了した従業員またはシステムユーザーを識別する属性です。マネージャー、人事パートナー、財務アナリストなどが該当します。ユーザー別にデータを分析すると、トレーニングの機会、業務量の偏り、個人ごとのパフォーマンスの違いを特定できます。たとえば、手戻りに最も頻繁に関与しているユーザーを特定し、より明確な手順やシステム改善の必要性を判断できます。重要な理由業務量の配分、ユーザーごとの行動、トレーニングの必要性、高い成果を上げている担当者を分析できます。入手先 Workdayのビジネスプロセストランザクションログで利用できます。各ステップの開始者または実行者が記録されています。例 jsmithdavis_janehr_admin_svc
	変更理由 ReasonForChange	ポジションの再分類、変更、クローズなど、変更イベントの理由です。
説明この属性には、ポジションに特定の変更を加えた業務上の根拠が記録されます。Workdayでは、一貫性を保つため、理由をあらかじめ定義されたリストから選択することが一般的です。たとえば、「組織再編」「新規プロジェクト」「予算調整」などがあります。この属性を分析すると、プロセスフローの背景にある事情を把握できます。「何が起きたか」だけでなく、その「なぜ」を明らかにできます。たとえば、再分類イベントと具体的な理由を関連付けることで、組織再編や役割の変化に関する傾向を特定できます。重要な理由変更や再分類などのアクティビティの背景にある業務上の事情を明らかにし、プロセスのばらつきが生じる根本原因の分析に役立ちます。入手先 Workdayの「ポジション制限の編集」や「ポジションのクローズ」など、多くの業務プロセストランザクションで必須となるフィールドです。例新しい部門の設立組織再編データの修正プロジェクト完了
	終了時刻 EndTime	アクティビティが完了した時刻を示すタイムスタンプです。個々のアクティビティの所要時間を計算するために使用します。
説明終了時刻は、特定のアクティビティが完了した時刻を示します。開始時刻がイベントの発生時点を示すのに対し、開始時刻と終了時刻を組み合わせることで、そのイベントの処理時間を計算できます。コンプライアンスレビューのように、瞬時には完了しないアクティビティで特に役立ちます。あるアクティビティの終了時刻と次のアクティビティの開始時刻を比較することで、処理時間と待機時間を正確に測定し、プロセス効率を詳しく把握できます。重要な理由アクティビティの正確な所要時間を計算するために必要です。実際の処理時間と、何も行われていない待機時間を区別できます。入手先 Workdayの一部のビジネスプロセスステップには、明示的な開始時刻と終了時刻があります。ない場合は、同じケースにおける次のイベントの開始時刻から算出できます。例 2023-04-15T09:05:12Z2023-04-15T17:00:00Z2023-04-18T11:21:55Z
	職種ファミリー JobFamily	「エンジニアリング」や「人事」など、特性、スキル、業務内容が似ている職種をまとめたグループです。
説明 Job Familyは、関連するJob Profileをまとめる分類です。たとえば、「ソフトウェアエンジニア」と「シニアソフトウェアエンジニア」のJob Profileは、どちらも「エンジニアリング」のJob Familyに属する場合があります。これにより、役割をより上位のレベルで分類し、分析できます。この属性は、再分類の監視やポジション属性の標準化に役立ちます。職種ファミリー内または職種ファミリー間の変更を分析することで、キャリアパス、役割定義の一貫性、人員構成の傾向を把握できます。重要な理由役割を上位レベルで分析でき、標準化の取り組みや、関連する職種カテゴリー間の再分類分析を支援します。入手先 Workday HCMの職種カタログ構造の一部で、ポジションのJob Profileに関連付けられます。例情報技術財務・会計営業担当者
	部門 Department	ポジションが所属する部門または監督組織です。
説明 Department属性は、Workdayの用語では「Supervisory Organization」と呼ばれることが多く、ポジションの組織上の位置付けを示します。ポジションが所属するチームや事業領域を定義します。さまざまな部門のパフォーマンスを比較できるため、分析に欠かせないディメンションです。たとえば、エンジニアリング部門とマーケティング部門で新規ポジションの承認サイクル時間を比較し、ベストプラクティスや部門固有のボトルネックを特定できます。重要な理由異なる組織単位のプロセスパフォーマンスを絞り込み、比較できます。部門固有のボトルネックや効率性を明らかにします。入手先 Workday HCMでSupervisory Organizationに割り当てられることで、ポジションに関連付けられます。例営業：北米エンジニアリング：プラットフォーム開発財務：全社FP&A
	コンプライアンスステータス ComplianceStatus	「コンプライアンス」や「非コンプライアンス」など、コンプライアンスレビューの結果を示します。
説明この属性には、正式な「ポジションのコンプライアンスレビュー完了」アクティビティの結果が記録されます。ポジションの属性、承認履歴、設定理由が社内ポリシーや外部規制を満たしているかを確認できます。「ポジションアクションのコンプライアンス概要」ダッシュボードに欠かせない属性です。コンプライアンス率を直接監視でき、監査担当者や人事チームは、非準拠としてフラグが付いたポジションをすばやく特定して調査できます。これにより、是正措置やリスク低減につなげられます。重要な理由コンプライアンスチェックの結果を直接測定し、ポリシー遵守状況の監視や、レビューが必要な高リスクケースの特定を可能にします。入手先通常は、Workdayの設定済み業務プロセス内にある特定のステップの出力です。コメントやカスタムフィールドとして保存される場合があります。例コンプライアンス適合コンプライアンス不適合フォローアップが必要
	コンプライアンスレビュー済みかどうか IsComplianceReviewed	ケース内で「ポジションのコンプライアンスレビュー完了」アクティビティが発生している場合にtrueとなるブール型フラグです。
説明このフラグは、ポジションがライフサイクルのいずれかの時点で正式なコンプライアンスレビューを受けたかどうかを示します。特定のPosition IDについて、「ポジションのコンプライアンスレビュー完了」アクティビティの有無を確認して判定します。この属性により、コンプライアンスの監視やKPIの計算が簡単になります。レビュー済みまたは未レビューのケースを簡単に絞り込めます。また、「ポジションアクションのコンプライアンス率」KPIの計算で、準拠している対象を容易に集計できます。重要な理由コンプライアンス率の測定を簡単にし、必要なレビューを受けていないポジションを絞り込んで分析できます。入手先ケース単位で計算される派生フラグです。ケースログに「ポジションのコンプライアンスレビュー完了」アクティビティが存在する場合にtrueを設定します。例 truefalse
	ソースシステム SourceSystem	データの生成元となるシステムです。この場合はWorkday HCMです。
説明 Position Managementプロセスのデータが生成されたソースアプリケーションを識別する属性です。この分析ではソースは一貫してWorkday HCMですが、複数のシステムからデータを統合するエンタープライズ環境では重要な項目です。この属性を含めることで、データの系譜を明確にし、異なるプラットフォームにまたがる可能性のあるプロセスを区別できます。背景情報を提供し、データガバナンスのベストプラクティスにもつながります。重要な理由データの生成元に関する重要な背景情報を提供し、複数システムの環境での明確性を確保するとともに、データガバナンス基準を支えます。入手先通常は、データの抽出・変換処理で追加される静的な値（「Workday HCM」）です。例 Workday HCMWorkdayHCM_Prod
	ポジション名 PositionTitle	「シニア財務アナリスト」や「リードソフトウェアエンジニア」など、ポジションの具体的な名称です。
説明 Position Titleは、利用者に表示される正式な役割名です。Job FamilyやJob Profileよりも詳細な名称で、通常は求人票や組織図に表示されます。この属性を分析すると、ポジション変更の詳細を把握できます。たとえば、再分類の分析では、名称が大きく変わったかどうかを確認できます。また、標準化用のダッシュボードで、異なる部門にある類似の役割について、名称が一貫しているかを確認する際にも使用します。重要な理由役割の詳細を把握でき、再分類や役割の標準化を分析するうえで欠かせません。入手先 Workday HCMのポジションオブジェクトに標準フィールドとして用意されています。例シニアプロダクトマネージャーHRビジネスパートナーIIアソシエイト会計士
	ポジション種別 PositionType	正社員、パートタイム、契約社員など、雇用条件に基づいてポジションを分類します。
説明 Position Typeは、Workdayでは「Worker Type」または「Time Type」と呼ばれることが多く、ポジションに関連する雇用形態を分類します。人員計画や人員管理の基本となる属性です。プロセスマイニングでは、異なる雇用形態のワーカーについて、ポジション管理プロセスを比較できます。たとえば、契約社員の承認プロセスが正社員より速いか、複雑でないかを調べることで、プロセスを改善できる箇所を見つけられます。重要な理由正社員と契約社員など、異なるワーカー区分のポジション管理プロセスを比較し、改善できる箇所を見つけられます。入手先ポジション定義の一部として利用でき、通常は「Worker Type」または「Time Type」として設定されます。例正社員（フルタイム）正社員（パートタイム）有期契約社員
	事業部門 BusinessUnit	「コンシューマープロダクツ」や「エンタープライズソリューション」など、ポジションが所属する上位レベルの事業部門または事業単位です。
説明 Business Unitは、部門よりも組織階層の上位に位置する会社の主要な事業セグメントです。経営レベルの戦略・財務レポーティングに使用されます。 Business Unitごとにポジション管理プロセスを分析すると、人員構成の変化を戦略的な視点から把握できます。主要な事業部門間で、採用のスピード、再分類率、プロセス効率にどのような違いがあるかを明らかにし、経営層が全社レベルの業務上の差異を把握するのに役立ちます。重要な理由主要な事業部門間のプロセスパフォーマンスを経営・戦略レベルで分析し、経営層の意思決定を支援します。入手先通常、Workdayでは「Worktag」として実装され、ポジションまたは関連するコストセンターに割り当てられます。例消費者向け製品エンタープライズソリューション全社サービス
	最終データ更新日時 LastDataUpdate	ソースシステムからデータが最後に抽出され、プロセスマイニングツールで更新された日時を示すタイムスタンプです。
説明最新のデータ更新日時を示すタイムスタンプを提供する属性です。プロセスデータそのものではなく、データセットの鮮度に関するメタデータです。分析を利用するすべてのユーザーにとって重要な項目です。データがどの程度最新であるかを確認できるため、分析結果が最新の業務状況を反映しているのか、少し古いスナップショットに基づいているのかを判断し、結果の適時性に関する認識を合わせられます。重要な理由データの鮮度をユーザーに伝え、プロセス分析と分析結果がどの程度最新であるかを理解できるようにします。入手先データ読み込み処理の完了時に、データパイプラインまたはETLツールによって生成されるタイムスタンプです。例 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	勤務地 Location	ポジションに関連付けられた物理的または論理的な勤務場所です。
説明 Location属性は、ポジションが置かれている地理的な拠点やオフィスを示します。特定の建物の住所から国や地域まで指定でき、「リモート」を値として設定することもできます。勤務地別に分析すると、承認時間やコンプライアンス率の違いなど、地域ごとのプロセスパフォーマンスの差を明らかにできます。プロセスがグローバルに標準化されているか、現地の運用によって差異が生じているかを把握するのにも役立ちます。重要な理由地理的な分析を可能にし、地域ごとのプロセスの違い、コンプライアンスの差異、勤務地固有のボトルネックを特定できます。入手先 Workday HCMでポジションに割り当てられる標準属性です。例ニューヨーク、米国ロンドン、英国リモート（ドイツ）
	手戻りかどうか IsRework	ポジション属性を複数回変更するなど、アクティビティが手戻りと見なされる場合にtrueとなるブール型フラグです。
説明 Is Reworkフラグは、修正や繰り返し作業に該当するアクティビティを特定します。こうしたアクティビティは、プロセスの非効率や品質上の問題を示すことがよくあります。通常は、作成直後に発生した「ポジション属性の変更」や、同じシーケンス内で複数回発生したイベントにtrueを設定します。この計算属性は、「ポジションデータの手戻り分析」ダッシュボードに欠かせません。手戻り率を簡単に定量化し、フラグが付いたイベントの状況を分析して根本原因を特定できます。また、「ポジションデータ手戻り率」などのKPIにも利用できます。重要な理由非効率な手戻りアクティビティを直接特定できるため、無駄を減らす改善活動の対象を定量化、分析、絞り込みできます。入手先アクティビティの順序と発生頻度に基づいて計算される派生フラグです。たとえば、同じケースで「ポジション属性の変更」が複数回発生した場合にtrueを設定します。例 truefalse
	新規ポジション承認時間 NewPositionApprovalCycleTime	ポジションの申請を開始してから、システム上で作成されるまでにかかった合計時間です。
説明この属性は、新規ポジション承認プロセスのエンドツーエンドのサイクル時間を測定します。特定のPosition IDについて、「ポジション申請開始」イベントから「ポジション作成」イベントまでの期間として計算します。「新規ポジション承認サイクル時間の平均」KPIや関連するダッシュボードを直接支援します。ケース単位で計算することで、サイクル時間の分布や外れ値を分析できます。また、部門やポジション種別など、承認時間の長短と関連する要因も調査できます。重要な理由重要なKPIを直接測定し、承認効率の分析や遅延の原因となる要因の特定を可能にします。入手先特定の開始アクティビティと終了アクティビティの時間差を求め、プロセスマイニングツール内でケース単位に計算します。例 P5DT6HP12DP2DT12H30M
	職務プロファイル JobProfile	責任や資格など、職種の基本的な特性を定義する標準化された職種テンプレートです。
説明 Job Profileは、Workdayの職種アーキテクチャを構成する基本要素です。標準の名称、資格、報酬等級などを定義する職種テンプレートとして機能します。ポジションは、特定の部門におけるJob Profileのインスタンスです。この属性は、プロセスの標準化を把握するうえで重要です。Job Profileごとにプロセスを分析すると、特定の役割で承認サイクルが長くなっていないか、手戻りが発生しやすくないかを確認できます。また、ポジションがあるJob Profileから別のJob Profileへ移る再分類の追跡にも欠かせません。重要な理由ポジションを標準的な職種テンプレートに関連付け、標準化された役割特性に基づくプロセスのばらつきを分析できます。入手先 Workday HCMのすべてのポジションで必須となるフィールドです。Staffingデータモデルの中核を構成します。例 JP-FIN-Analyst3JP-ENG-Dev5JP-HR-Generalist2

必須推奨任意

採用から退職までのポジション管理のアクティビティ

採用から退職までのポジション管理で正確にプロセスを発見するため、イベントログに記録する主要なプロセス手順とマイルストーンです。

6 推奨 7 任意

	アクティビティ	説明
	ポジションを作成	Workdayシステムでポジションが正常に作成され、正式に存在するようになったことを示します。「Create Position」ビジネスプロセスが正常に完了した時点で記録されます。
重要な理由承認フェーズの終了と、ポジションが人員配置可能になったことを示す重要なマイルストーンです。承認サイクル全体のKPIを測定するうえで欠かせません。入手先 Workdayのイベントログまたは監査証跡に記録された「Create Position」ビジネスプロセスの完了タイムスタンプから取得します。取得「Create Position」ビジネスプロセスが正常に完了した時点で記録されるイベントです。イベントタイプ explicit
	ポジションを無効化	ポジションがアクティブではなくなり、充足できない状態になったことを示します。正式な終了に先立つ準備段階として行われることが多く、「Inactivate Position」ビジネスプロセスの完了時に明示的なイベントとして記録されます。
重要な理由無効化はポジションのライフサイクルにおける重要なマイルストーンであり、最終的な終了とは異なります。無効化から終了までの時間は、組織構造を整理する管理業務の効率を示します。入手先「Inactivate Position」ビジネスプロセスが正常に完了した時点で、Workdayの監査ログに記録されます。取得「Inactivate Position」ビジネスプロセスが正常に完了した時点で記録されるイベントです。イベントタイプ explicit
	ポジションを終了	ライフサイクルの最終アクティビティであり、組織からポジションを恒久的に削除することを示します。Workdayでは、「Close Position」ビジネスプロセスが正常に完了した時点で記録されます。
重要な理由ほとんどのケースで終端イベントとなるこのアクティビティは、ポジションのライフサイクルの終了を示します。プロセス全体の所要時間を把握し、正確な人員数データを維持するうえで重要です。入手先 Workdayの監査証跡またはビジネスプロセスログに記録された「Close Position」ビジネスプロセスの完了タイムスタンプから取得します。取得「Close Position」ビジネスプロセスの完了時に記録されるイベントです。イベントタイプ explicit
	ポジション属性を変更	既存ポジションのタイトルや部門など、1つ以上の属性が変更されたことを示します。ユーザーが「Edit Position Restrictions」ビジネスプロセスを正常に完了した時点で明示的に記録されます。
重要な理由変更が頻繁に発生する場合、入力ミス、職務内容の変化、プロセスの非効率などが考えられます。このアクティビティを分析することは、「Position Data Rework Analysis」ダッシュボードやデータ品質の改善に役立ちます。入手先 Workdayの「Edit Position Restrictions」または同様のビジネスプロセスの完了ログから取得します。監査証跡で変更されたフィールドを確認できます。取得「Edit Position Restrictions」ビジネスプロセスが正常に完了した時点で記録されるイベントです。イベントタイプ explicit
	ポジション申請を開始	ポジション管理のライフサイクルが始まる段階です。新規ポジションの作成申請が正式に提出されます。Workdayでユーザーが「Create Position」ビジネスプロセスを開始した時点で、明示的なイベントとして記録されます。
重要な理由このアクティビティは、プロセスの主な開始イベントです。このイベントから後続の承認までにかかる時間を分析することは、ポジション作成サイクル全体の効率を測定するうえで重要です。入手先このイベントは、Workdayのビジネスプロセスイベントログに記録されます。対象のPosition IDについて、「Create Position」ビジネスプロセストランザクションの開始タイムスタンプを確認します。取得「Create Position」ビジネスプロセスの開始時に記録されるイベントです。イベントタイプ explicit
	予算承認済み	財務部門または予算管理者が、新規ポジションの資金を確保できることを確認する重要なマイルストーンです。指定された承認者がビジネスプロセスフローの予算承認ステップを完了した時点で記録されます。
重要な理由予算承認は、大きなボトルネックになることがよくあります。このアクティビティの処理時間を測定すると、財務レビューを効率化し、採用を迅速化できます。入手先 Workdayの「Create Position」ビジネスプロセスの監査履歴に記録されます。予算承認ステップの完了イベントに対応します。取得ビジネスプロセスログに記録された財務または予算承認ステップの完了タイムスタンプです。イベントタイプ explicit
	ポジションのコンプライアンスレビューを完了	ポジションが、社内ポリシーや外部規制などに照らして正式なコンプライアンスチェックを受けたことを示します。親ビジネスプロセス内の特定の「To Do」または「Checklist」ステップとして記録される可能性があります。
重要な理由コンプライアンスレビューを追跡することは、リスクを抑え、組織の基準を守るうえで欠かせません。このアクティビティは、「Position Action Compliance Rate」KPIを直接支えます。入手先ビジネスプロセス内で完了した「To Do」ステップ、または「Create Position」や「Edit Position」などのビジネスプロセス内の特定の承認ステップとして記録される可能性があります。正確な仕組みを確認するには、システム分析が必要です。取得ビジネスプロセスログに記録された、コンプライアンス関連の承認または「To Do」ステップの完了タイムスタンプです。イベントタイプ explicit
	ポジションの凍結を解除	凍結の反対にあたる操作です。一時停止されていたポジションを再び有効にし、人員配置できる状態に戻します。通常は、ポジションのステータスフィールドが「Frozen」から「Active」に変わったことから推定します。
重要な理由凍結されたポジションが解消されたことを示すイベントです。「Position Frozen」からこのイベントまでの時間を測定することは、「Frozen Position Resolution Time」KPIに欠かせません。入手先ポジションの履歴または監査ログにある、有効日付きのステータス変更から推定できます。構成によっては、明示的な「Unfreeze」ビジネスプロセスイベントとして記録される場合もあります。取得有効日付きの履歴に基づき、ポジションのステータスが「Frozen」から「Active」に変わったことを検出します。イベントタイプ inferred
	ポジションを再分類	ポジションに関連付けられた職務プロファイルまたは分類が正式に変更されたことを示します。特定のポジションに対して「Change Job」ビジネスプロセスが正常に完了した時点で記録されます。
重要な理由組織再編や職務責任の大きな変化を把握するのに役立つアクティビティです。再分類を追跡することで、人員構成の変化と職務体系の安定性を分析できます。入手先ポジションに適用された「Change Job」ビジネスプロセスの完了ログから取得します。ワーカーに適用された場合とは区別します。取得ポジションに対する「Change Job」ビジネスプロセスが正常に完了した時点で記録されるイベントです。イベントタイプ explicit
	ポジションを凍結	ポジションを一時停止し、充足できない状態にする操作を示します。Workdayでユーザーが「Freeze Position」ビジネスプロセスを正常に完了した時点で記録されます。
重要な理由人員数と予算を管理するうえで重要なアクティビティです。ポジションが凍結されたままの期間を分析すると、判断の停滞を特定し、リソース計画を改善できます。入手先「Freeze Position」ビジネスプロセスの完了時点から取得します。このイベントの結果として、通常はポジションのステータスフィールドが更新されます。取得「Freeze Position」ビジネスプロセスの完了時に記録されるイベントです。イベントタイプ explicit
	ポジション申請を却下	ポジション作成申請が承認者によって却下され、正常に完了しなかったことを示します。Workdayでは、「Create Position」ビジネスプロセスの終端ステータス「Denied」として記録されます。
重要な理由却下された申請を分析すると、予算上の制約やポリシーとの不整合など、却下の主な理由を特定できます。これにより、プロセスを改善し、申請者への案内を充実させられます。入手先「Create Position」ビジネスプロセスインスタンスの最終ステータスから取得します。イベントのタイムスタンプは、却下操作が行われた時刻です。取得承認者がビジネスプロセスのステップで「Deny」操作を選択した時点で記録されるイベントです。イベントタイプ explicit
	マネージャー承認を提出	採用マネージャーまたは上長組織のマネージャーが、レビューと承認のステップを完了したことを示します。Workdayでは、「Create Position」ビジネスプロセス内の承認ステップが完了したイベントとして個別に記録されます。
重要な理由初期段階における一般的なマイルストーンであり、ボトルネックになる可能性があります。この承認にかかった時間を追跡すると、ポジション作成ワークフローの初期段階における遅延を特定できます。入手先「Create Position」ビジネスプロセスの監査証跡から取得します。「Manager Approval」ステップの完了に対応するイベントです。取得ビジネスプロセスログに記録されたマネージャー承認ステップの完了タイムスタンプです。イベントタイプ explicit
	人事承認を提出	人事パートナーまたは担当者がポジション申請をレビューし、承認したことを示します。Workdayのビジネスプロセスで、人事承認者が割り当てられたステップを完了した時点で明示的に記録されます。
重要な理由この承認は、ポジションが会社のポリシーと職務体系に適合していることを確認する重要なチェックポイントです。ここでの遅延は、全体の処理時間に大きく影響する可能性があります。入手先該当するビジネスプロセスのWorkday監査証跡から取得します。「HR Approval」ステップの完了がこのイベントに該当します。取得ビジネスプロセスログに記録された人事承認ステップの完了タイムスタンプです。イベントタイプ explicit

推奨任意

抽出ガイド

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

ステップ

Workdayにログイン：カスタムレポートを作成し、必要なHuman Capital Management（HCM）データドメインにアクセスできる権限を持つユーザーアカウントで、Workdayテナントにサインインします。
カスタムレポートを作成：検索バーで「Create Custom Report」タスクを検索して開きます。
レポート種別とデータソースを選択：レポート名を「ProcessMind Position Management Events」などに設定します。レポート種別には「Advanced」を選択します。データソースには「Business Process Transactions」を選択します。このデータソースから、業務プロセスの各ステップに関する詳細なイベントレベルの情報を取得できます。
レポート列を定義：「Columns」タブで、イベントログの列となるフィールドを追加します。Workdayのオブジェクトとフィールドを、必要な属性に対応付けます。たとえば、次のように設定します。
- PositionId：業務プロセスのコンテキストから「Position ID」に対応付けます。
- EventTime：各ステップの「Completed Date」または「Corrected Completed Moment」に対応付けます。
- User：トランザクションの「Completed By」に対応付けます。
- PositionStatus、Department、CostCenter、JobFamily：Positionビジネスオブジェクトの対応するフィールドに対応付けます。
アクティビティ名用の計算フィールドを作成：この抽出で中心となるのは、業務プロセスのステップを標準化されたアクティビティ名に変換することです。「Related Business Objects」メニューを開き、「Calculated Field」を作成します。「Evaluate Expression」タイプを使って、ロジックツリーを作成します。たとえば、次のように設定します。
- 「Business Process Type」が「Create Position」で、「Transaction Status」が「Successfully Completed」の場合、テキスト「Position Created」を返します。
- 「Business Process Type」が「Create Position」、「Step」が「［貴社のマネージャー承認ステップ名］」、「Status」が「Completed」の場合、テキスト「Manager Approval Submitted」を返します。
- 必須となる13のアクティビティそれぞれに条件を作成します。
レポートフィルターを設定：「Filter」タブで、データ範囲を指定するプロンプトとフィルターを追加します。「Completed Date」のプロンプトを作成し、日付範囲を選択できるようにします。「Create Position」「Edit Position Restrictions」「Change Job」「Freeze Position」「Inactivate Position」「Close Position」など、関連する「Business Process Types」のみを含めるフィルターを追加します。
並べ替えと出力を調整：「Sort」タブで、まずPositionId、次にEventTimeの順に結果を並べ替えます。これにより、各ケースを時系列順に並べられます。
Web Service（RaaS）として有効化：ユーザーインターフェースでレポートが正しく実行されることを確認したら、「Actions」＞「Web Service」＞「Enable as Web Service」の順に選択します。オプションで「Content Type」に「JSON」を設定すると、連携しやすくなります。
エンドポイントを保護してテスト：Webサービスのセキュリティを設定し、アクセスできるユーザーまたはシステムを定義します。生成されたJSONまたはWSDLのURLを控えます。Postmanなどのツールや簡単なスクリプトでエンドポイントをテストし、データを受信できることを確認します。
抽出を自動化：連携プラットフォームまたはスクリプトを使い、スケジュールに従ってRaaS URLを呼び出します。リクエストのパラメーターとして、対象の日付範囲を渡します。
ProcessMind用に整形：スクリプトでWorkdayからのJSONレスポンスを解析し、フラットなCSVファイルに変換します。CSVの列見出しが、PositionId、ActivityName、EventTime、Userなど、必要な属性名と一致していることを確認します。
ProcessMindにアップロード：整形済みのCSVファイルをProcessMindにアップロードして分析を開始できます。

設定

レポートタイプ：Advanced。このタイプは、計算フィールドの作成や異なるビジネスオブジェクトのデータ結合に必要です。
主なデータソース：「Business Process Transactions」。このデータソースはイベント指向で、ビジネスプロセスの各ステップにおけるステータス、タイムスタンプ、担当者などの必要な詳細情報を含みます。
主なフィルター：
- ビジネスプロセスタイプ：「Create Position」、「Close Position」、「Freeze Position」、「Change Job」、「Edit Position Restrictions」、「Inactivate Position」など、対象となるプロセスだけをレポートに含めるように設定します。パフォーマンスを確保するうえで重要です。
- 完了日：このフィールドには入力を求めるフィルターを使用し、ユーザーが抽出期間を指定できるようにします。初回ロードでは、3～6か月分のデータを推奨します。
計算フィールド：標準化されたActivityNameを生成し、コアの「Position」オブジェクトからイベントストリームに属性を取り込むため、「Evaluate Expression」と「Lookup Related Value」の計算フィールドを多用します。
Webサービス出力：RaaSの出力形式はJSONに設定します。XMLも利用できますが、一般的にJSONのほうが最新のアプリケーションで解析しやすい形式です。
権限：レポートを作成するユーザーには、「Business Process Transactions」、「Position Management」、「Worker Data」などのデータドメインに対するセキュリティ権限が必要です。RaaS呼び出しで返されるデータは、これらの権限によって制限されます。

a サンプルクエリ sql

/*
 This is a logical representation of the Workday Advanced Report configuration.
 It is built using the Workday Report Writer UI, not by writing code.
 Each 'SELECT' block represents a set of conditions within a single 'Evaluate Expression' calculated field for the 'ActivityName' column.
 The report's primary data source is 'Business Process Transactions'.
*/

// Calculated Field for ActivityName: 'cf_ActivityName'
// Type: Evaluate Expression

// Condition 1: Position Request Initiated
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process Transaction'.Is First Step = true)
THEN 'Position Request Initiated'
// Column Mapping for this condition:
// PositionId: 'Position' From Business Process -> Position ID
// ActivityName: 'cf_ActivityName' (this calculated field)
// EventTime: 'Business Process' -> Initiation Moment
// User: 'Business Process' -> Initiator

// Condition 2: Manager Approval Submitted
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process Step'.Name CONTAINS 'Manager Approval' AND 'Business Process Transaction'.Status = 'Completed')
THEN 'Manager Approval Submitted'
// Column Mapping for this condition:
// EventTime: 'Business Process Transaction' -> Completed Moment
// User: 'Business Process Transaction' -> Completed By

// Condition 3: HR Approval Submitted
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process Step'.Name CONTAINS 'HR Approval' AND 'Business Process Transaction'.Status = 'Completed')
THEN 'HR Approval Submitted'
// Column Mapping for this condition:
// EventTime: 'Business Process Transaction' -> Completed Moment
// User: 'Business Process Transaction' -> Completed By

// Condition 4: Budget Approved
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process Step'.Name CONTAINS 'Budget Approval' AND 'Business Process Transaction'.Status = 'Completed')
THEN 'Budget Approved'
// Column Mapping for this condition:
// EventTime: 'Business Process Transaction' -> Completed Moment
// User: 'Business Process Transaction' -> Completed By

// Condition 5: Position Request Denied
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process'.Status = 'Denied')
THEN 'Position Request Denied'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process Transaction' -> Completed By (on the denial step)

// Condition 6: Position Created
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Created'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business process' -> Initiator

// Condition 7: Position Attributes Modified
WHEN ('Business Process'.Type = 'Edit Position Restrictions' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Attributes Modified'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 8: Position Reclassified
WHEN ('Business Process'.Type = 'Change Job' AND 'Business Process'.Context.Is Position = true AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Reclassified'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 9: Position Compliance Reviewed
WHEN ('Business Process Step'.Name CONTAINS 'Compliance Review' AND 'Business Process Transaction'.Status = 'Completed')
THEN 'Position Compliance Reviewed'
// Column Mapping for this condition:
// EventTime: 'Business Process Transaction' -> Completed Moment
// User: 'Business Process Transaction' -> Completed By

// Condition 10: Position Frozen
WHEN ('Business Process'.Type = 'Freeze Position' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Frozen'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 11: Position Unfrozen
// Note: This often relies on a different data source, 'Position History', to track status changes.
// If using 'Business Process Transactions', this assumes an 'Unfreeze' BP exists or is part of another BP.
// The example below assumes an 'Edit Position' BP is used to change the status.
WHEN ('Business Process'.Type = 'Edit Position Restrictions' AND 'Position'.Is Frozen (Prior) = true AND 'Position'.Is Frozen = false AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Unfrozen'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 12: Position Deactivated
WHEN ('Business Process'.Type = 'Inactivate Position' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Deactivated'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 13: Position Closed
WHEN ('Business Process'.Type = 'Close Position' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Closed'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Default case for the calculated field
ELSE 'Other Activity'

/*
Final Report Structure:
- Data Source: Business Process Transactions
- Columns:
  - Position ID (from Position)
  - cf_ActivityName
  - Event Time (Calculated field to pick correct timestamp based on activity)
  - User (Calculated field to pick correct user)
  - End Time (same as Event Time for discrete events)
  - Position Status (from Position)
  - Reason For Change (from Business Process -> Reason)
  - Department (Supervisory Organization from Position)
  - Cost Center (from Position)
  - Job Family (from Job Profile)
- Filter:
  - Business Process Type IN ('Create Position', 'Edit Position Restrictions', 'Change Job', 'Freeze Position', 'Inactivate Position', 'Close Position', ...)
  - Completed Date IS IN [Prompted Date Range]
  - cf_ActivityName IS NOT 'Other Activity'
*/

ステップ

前提条件：Workdayカスタムレポートを作成します。 スクリプトを実行する前に、必要なデータを提供するカスタムレポートをWorkdayで作成します。「Business Process Transactions」データソースを使用してください。Position ID、Business Process Type、Step Name、Status、Effective Date、Completed Date、Initiatorなど、イベントログに必要なフィールドを公開します。「Advanced」タブで「Enable as Web Service」を選択してレポートをWebサービスとして有効にし、Integration System User（ISU）に必要な権限を設定します。
前提条件：Workday統合ユーザーを設定します。 前の手順で作成したカスタムレポートにアクセスできる権限を持つIntegration System User（ISU）を用意します。ユーザー名、パスワード、レポート用に生成されたRaaS（Reports-as-a-Service）のJSONエンドポイントURLを控えておきます。
Python環境を設定します。 抽出を実行するマシンにPythonをインストールします。pipを使用して必要なライブラリをインストールします：pip install requests pandas。
Pythonスクリプトを設定します。 提供されたPythonスクリプトをダウンロードします。テキストエディターでファイルを開き、スクリプト冒頭のプレースホルダー変数を更新します。WorkdayのRaaS URL、ユーザー名、パスワードを指定してください。また、抽出期間のSTART_DATEとEND_DATEを設定します。
スクリプトの処理内容を確認します。 スクリプトはWorkdayで認証を行い、カスタムレポートのWebサービスを呼び出して、日付範囲をパラメーターとして渡します。WorkdayはデータをJSON形式で返します。レポート結果が複数ページにわたる場合、スクリプトがページネーションを自動的に処理します。
スクリプトを実行します。 ターミナルまたはコマンドプロンプトを開き、スクリプトを保存したディレクトリに移動して、次のコマンドを実行します：python workday_extraction.py。
アクティビティマッピング：スクリプトには、Workdayのビジネスプロセスとステップのステータスの組み合わせを、ProcessMindで必要な標準アクティビティ名に変換するマッピング辞書（activity_map）が含まれています。Workdayテナントで設定されている正確なビジネスプロセス名に合わせて、この辞書のキーを調整する必要がある場合があります。
データ変換：スクリプトはWorkdayレポートから返された各レコードを順に処理します。アクティビティマッピングを適用し、必要な属性を抽出して、タイムスタンプを正しい形式に整えます。有効なイベントはリストに追加されます。
出力の生成：すべてのデータの処理が完了すると、スクリプトはイベントのリストをpandas DataFrameに変換します。これにより、必要な列名（PositionId、ActivityName、EventTime、Userなど）を持つ表形式のデータが作成されます。
ProcessMind用CSVを出力します。 スクリプトは最終的なDataFrameをposition_management_event_log.csvというCSVファイルに保存します。このファイルはUTF-8でエンコードされ、追加の変更なしでProcessMindにアップロードできます。

設定

Workdayカスタムレポート（RaaS）：主なデータソースは、Webサービスとして有効化したWorkdayのカスタムレポートです。このレポートは「Business Process Transactions」データソースを基に作成する必要があります。
レポートフィールド：レポートには、Position ID、Business Process Definition、Business Process Step、Transaction Status、Effective Timestamp、Completion Timestamp、Initiatorのほか、Cost CenterやSupervisory Organizationなど、必要な属性を含める必要があります。
Integration System User（ISU）：認証には、ユーザー名とパスワードを持つISUが必要です。このユーザーは、カスタムレポートのWebサービスエンドポイントへのアクセス権を持つセキュリティグループに所属している必要があります。
日付範囲：スクリプトではSTART_DATEとEND_DATEのパラメーターを使用します。初回抽出では、データ量を管理しやすく、処理を速くするため、3～6か月の期間を推奨します。2回目以降の抽出では、より短い差分期間を指定できます。
APIエンドポイント：スクリプトには、カスタムレポートのJSONエンドポイントURLが必要です。このURLは、Workdayのカスタムレポート定義にある「Web Service」タブで確認できます。
アクティビティマッピング：スクリプトは、Workdayのプロセス名とステータスを最終的なアクティビティ名に変換する設定可能なマッピングに基づいて処理します。Workdayのビジネスプロセス設定に応じて、カスタマイズが必要になる場合があります。

a サンプルクエリ python

import requests
import pandas as pd
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your Workday RaaS endpoint, username, and password
WORKDAY_RAAS_URL = class="hl-string">'[Your_Workday_RaaS_JSON_Endpoint_URL]'
WORKDAY_USERNAME = class="hl-string">'[Your_ISU_Username]'
WORKDAY_PASSWORD = class="hl-string">'[Your_ISU_Password]'

class=class="hl-string">"hl-comment"># Set the 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"># --- Activity Mapping --- #
class=class="hl-string">"hl-comment"># This dictionary maps Workday processes and statuses to standardized activity names.
class=class="hl-string">"hl-comment"># The keys are tuples: (class="hl-string">'Business Process Name', class="hl-string">'Step Name / Status').
class=class="hl-string">"hl-comment"># You MAY need to adjust the class="hl-string">'Business Process Name' to match your Workday configuration.
activity_map = {
    (class="hl-string">'Create Position', class="hl-string">'Initiation Step'): class="hl-string">'Position Request Initiated',
    (class="hl-string">'Create Position', class="hl-string">'Manager Approval'): class="hl-string">'Manager Approval Submitted',
    (class="hl-string">'Create Position', class="hl-string">'HR Approval'): class="hl-string">'HR Approval Submitted',
    (class="hl-string">'Create Position', class="hl-string">'Budget Approval'): class="hl-string">'Budget Approved',
    (class="hl-string">'Create Position', class="hl-string">'Denied'): class="hl-string">'Position Request Denied',
    (class="hl-string">'Create Position', class="hl-string">'Successfully Completed'): class="hl-string">'Position Created',
    (class="hl-string">'Edit Position Restrictions', class="hl-string">'Successfully Completed'): class="hl-string">'Position Attributes Modified',
    (class="hl-string">'Change Job', class="hl-string">'Successfully Completed'): class="hl-string">'Position Reclassified',
    (class="hl-string">'Freeze Position', class="hl-string">'Successfully Completed'): class="hl-string">'Position Frozen',
    class=class="hl-string">"hl-comment"># Assuming a business process exists for this. If not, this requires a different approach.
    (class="hl-string">'Unfreeze Position', class="hl-string">'Successfully Completed'): class="hl-string">'Position Unfrozen',
    (class="hl-string">'Inactivate Position', class="hl-string">'Successfully Completed'): class="hl-string">'Position Deactivated',
    (class="hl-string">'Close Position', class="hl-string">'Successfully Completed'): class="hl-string">'Position Closed',
    class=class="hl-string">"hl-comment"># Mapping a class="hl-string">'To Do' step within a parent process for compliance review
    (class="hl-string">'Create Position', class="hl-string">'Compliance Review To Do'): class="hl-string">'Position Compliance Reviewed',
    (class="hl-string">'Edit Position Restrictions', class="hl-string">'Compliance Review To Do'): class="hl-string">'Position Compliance Reviewed'
}

def get_activity_name(process, step, status):
    class="hl-string">"""Determines the activity name based on the mapping."""
    class=class="hl-string">"hl-comment"># Denied and successful completion are based on the overall process status
    if status == class="hl-string">'Denied':
        return activity_map.get((process, class="hl-string">'Denied'))
    if status == class="hl-string">'Successfully Completed':
        return activity_map.get((process, class="hl-string">'Successfully Completed'))

    class=class="hl-string">"hl-comment"># Other activities are based on specific steps
    return activity_map.get((process, step))

def fetch_workday_data():
    class="hl-string">"""Fetches data from the Workday RaaS endpoint with pagination."""
    all_entries = []
    page = 1
    while True:
        params = {
            class="hl-string">'format': class="hl-string">'json',
            class="hl-string">'page': page,
            class="hl-string">'StartDate': fclass="hl-string">'{START_DATE}T00:00:00Z',
            class="hl-string">'EndDate': fclass="hl-string">'{END_DATE}T23:59:59Z'
        }
        print(fclass="hl-string">"Fetching page {page}...")
        try:
            response = requests.get(
                WORKDAY_RAAS_URL,
                auth=(WORKDAY_USERNAME, WORKDAY_PASSWORD),
                params=params
            )
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
            data = response.json()
            entries = data.get(class="hl-string">'Report_Entry', [])
            if not entries:
                print(class="hl-string">"No more entries found. Concluding fetch.")
                break
            all_entries.extend(entries)
            class=class="hl-string">"hl-comment"># Check if this is the last page
            if len(entries) < data.get(class="hl-string">'Report_Data', {}).get(class="hl-string">'Page_Size', 1000):
                 break
            page += 1
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from Workday: {e}")
            break
        except ValueError:
            print(class="hl-string">"Error parsing JSON response. Check the URL and credentials.")
            print(class="hl-string">"Response text:", response.text)
            break

    print(fclass="hl-string">"Total entries fetched: {len(all_entries)}")
    return all_entries

def main():
    class="hl-string">"""Main function to extract, transform, and save data."""
    report_entries = fetch_workday_data()
    if not report_entries:
        print(class="hl-string">"No data extracted. Exiting.")
        return

    event_log = []
    for entry in report_entries:
        class=class="hl-string">"hl-comment"># Assuming your RaaS report column names are aliased for clarity
        process_name = entry.get(class="hl-string">'BusinessProcessType')
        step_name = entry.get(class="hl-string">'BusinessProcessStep')
        status = entry.get(class="hl-string">'TransactionStatus')
        position_id = entry.get(class="hl-string">'PositionID')
        
        activity = get_activity_name(process_name, step_name, status)
        
        if not activity or not position_id:
            continue class=class="hl-string">"hl-comment"># Skip records that don't map to a required activity or have no Position ID

        event_log.append({
            class="hl-string">'PositionId': position_id,
            class="hl-string">'ActivityName': activity,
            class="hl-string">'EventTime': entry.get(class="hl-string">'CompletedDateTime', entry.get(class="hl-string">'EffectiveDateTime')),
            class="hl-string">'EndTime': entry.get(class="hl-string">'CompletedDateTime'),
            class="hl-string">'User': entry.get(class="hl-string">'InitiatorName'),
            class="hl-string">'PositionStatus': entry.get(class="hl-string">'PositionStatus'), class=class="hl-string">"hl-comment"># Assumes this field is in the report
            class="hl-string">'ReasonForChange': entry.get(class="hl-string">'Reason'),
            class="hl-string">'Department': entry.get(class="hl-string">'SupervisoryOrganization'),
            class="hl-string">'CostCenter': entry.get(class="hl-string">'CostCenter'),
            class="hl-string">'JobFamily': entry.get(class="hl-string">'JobFamily')
        })

    if not event_log:
        print(class="hl-string">"No processable events found after mapping. Exiting.")
        return

    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Data Cleaning and Formatting
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'], errors=class="hl-string">'coerce')
    df.dropna(subset=[class="hl-string">'PositionId', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    df.sort_values(by=[class="hl-string">'PositionId', class="hl-string">'EventTime'], inplace=True)

    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    final_columns = [
        class="hl-string">'PositionId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'User', class="hl-string">'EndTime', 
        class="hl-string">'PositionStatus', class="hl-string">'ReasonForChange', class="hl-string">'Department', class="hl-string">'CostCenter', class="hl-string">'JobFamily'
    ]
    df = df.reindex(columns=final_columns)

    output_filename = class="hl-string">'position_management_event_log.csv'
    df.to_csv(output_filename, index=False, encoding=class="hl-string">'utf-8')
    print(fclass="hl-string">"Successfully created event log: {output_filename}")

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

ステップ

MuleSoft、Boomi、Informaticaなど、選択したミドルウェアまたはETLプラットフォームにライセンス済みのWorkdayコネクタがあり、統合ランタイムからWorkdayに接続できることを確認します。必要なWorkday統合システムユーザーの認証情報、セキュリティグループの割り当て、レポートまたはAPI権限、テナントエンドポイントの設定をWorkday管理者から取得します。
Workdayで、業務プロセス履歴、承認ステップの完了、ポジション属性、ステータス変更、ワーカーまたはユーザー参照、適用日時を公開する承認済みのソースレポートまたはAPIを特定します。正確なレポート名またはAPI名はテナント設定によって異なるため、[Configure based on your system]を使用します。ソースにPosition IDと、必要なすべてのアクティビティを区別できる十分な業務プロセスのコンテキストが含まれていることを確認します。
ミドルウェアプラットフォームでコネクタを設定し、Workdayテナント接続、認証方式、リクエストタイムアウト、ページネーション、再試行ポリシー、増分抽出パラメーターを指定します。日付パラメーターには[Your start date]と[Your end date]を使用し、承認済みの会社または監督組織のフィルターを適用します。
ソースデータセットをミドルウェアプラットフォームのステージングオブジェクトに抽出します。ソース識別子、イベント日時、完了日時、実行者識別子、ポジションステータス、理由、部門、コストセンター、職種ファミリー、業務プロセス名、ステップ名、ステップステータス、適用日付きポジション属性を保持します。ProcessMindがイベントを推測すると考えないでください。
ステージングしたデータを変換し、明示的に対応する各アクティビティにつき1つのイベント行を作成します。ソースの業務プロセス開始をPosition Request Initiatedに、マネージャー、HR、予算の承認ステップ完了を対応するアクティビティに、拒否の終了ステータスをPosition Request Deniedに、Create Positionの正常完了をPosition Createdに、指定されたポジション変更プロセスの正常完了を対応するアクティビティにマッピングします。コンプライアンスレビューは、完了済みのTo DoまたはChecklistステップが明示的に存在する場合にのみマッピングします。Position Unfrozenは、抽出変換中にソースがFrozenからActiveへのステータス遷移を明示的に記録している場合にのみマッピングします。
ステージングしたソースビューに対して、クエリフィールド内の完全なSQL変換を実行します。接続、認証情報、日付、会社固有のプレースホルダーだけを置き換えます。クエリ内のソースビュー名とソース列名は専門的なプレースホルダーであり、設定したWorkdayコネクタが公開する実際のオブジェクトとフィールドに置き換える必要があります。
すべての出力行でPositionId、ActivityName、EventTimeが入力されていること、タイムスタンプが合意した1つのタイムゾーンに統一されていること、ソースイベント識別子または文書化された複合キーで重複ソースレコードが除去されていることを検証します。利用できる場合は、User、EndTime、PositionStatus、ReasonForChange、Department、CostCenter、JobFamilyを保持します。
結果をUTF-8のCSVまたはProcessMindが対応する別のイベントログ形式でエクスポートします。ケース識別子にはPositionId、アクティビティ列にはActivityName、イベントタイムスタンプにはEventTimeを使用します。推奨属性を追加列として含め、イベント1件につき1行を保持したうえで、欠落したアクティビティが自動的に作成されることを期待せず、ファイルをProcessMindにアップロードします。

設定

コネクター：MuleSoft、Boomi、Informatica、または選択したETLプラットフォームで、承認済みのWorkdayコネクターを設定します。正確なコネクター操作、レポート名、APIリソースは、テナントとコネクターのバージョンによって異なります。
ソース設定：ビジネスプロセスイベント、承認ステップ、ポジションステータス履歴、有効日付きポジション属性を公開するWorkdayレポートまたはAPIには、[Configure based on your system]を使用します。
日付範囲：まず、完了済みイベントの3～6か月分を対象にします。実行時間、ページネーション、ソースの保持期間、ProcessMindの取り込み上限を検証してから、期間を延長します。
差分ロード：EventTimeまたはソースイベントの更新タイムスタンプをウォーターマークとして使用します。実行間に短い重複期間を設け、ソースイベント識別子または文書化した複合キーで重複排除します。
必須出力列：PositionId、ActivityName、EventTimeを必ず含め、値を設定します。PositionIdがケース識別子です。
推奨出力列：User、EndTime、PositionStatus、ReasonForChange、Department、CostCenter、JobFamily。
アクティビティフィルター：設定したCreate Position、Edit Position Restrictions、Change Job、Freeze Position、Inactivate Position、Close Positionのビジネスプロセス名と、設定したコンプライアンスのTo DoまたはChecklistステップでフィルターします。想定したラベルではなく、テナントで設定された正確な値を使用します。
ステータス処理：Position Unfrozenは、明示的に取得できるFrozenからActiveへのステータス遷移からのみ抽出します。現在のステータスがActiveであるという理由だけでイベントを作成しないでください。
パフォーマンス：コネクターのページネーション、範囲を限定した日付フィルター、ソース側のフィルタリング、対応している場合のみ並列抽出、段階的な差分処理を有効にします。テナント全体を無制限に抽出しないでください。
セキュリティ：統合ユーザーには、ビジネスプロセス履歴、承認ステップ、ポジションデータ、ステータス履歴、組織属性、ユーザー参照情報を読み取る権限が必要です。セキュリティドメインとレポートへのアクセスは、Workday管理者の承認を受けてください。
前提条件：Workdayコネクターのライセンス、ミドルウェアランタイム、安全な認証情報の保管、ネットワークアクセス、ソースレポートまたはAPIの利用可否、ProcessMindへのインポート権限を確認します。

a サンプルクエリ sql

WITH source_events AS (
    SELECT
        [Position ID] AS PositionId,
        [Business Process Name] AS BusinessProcessName,
        [Step Name] AS StepName,
        [Step Status] AS StepStatus,
        [Event Type] AS EventType,
        [Event Timestamp] AS SourceEventTime,
        [Completion Timestamp] AS SourceEndTime,
        [Performed By] AS SourceUser,
        [Position Status] AS SourcePositionStatus,
        [Reason] AS SourceReasonForChange,
        [Department] AS SourceDepartment,
        [Cost Center] AS SourceCostCenter,
        [Job Family] AS SourceJobFamily,
        [Previous Position Status] AS PreviousPositionStatus,
        [Source Event ID] AS SourceEventId
    FROM [Your Workday staged event source]
    WHERE [Event Timestamp] >= CAST('[Your start date]' AS TIMESTAMP)
      AND [Event Timestamp] < CAST('[Your end date]' AS TIMESTAMP)
      AND [Position ID] IS NOT NULL
),
position_attributes AS (
    SELECT
        [Position ID] AS PositionId,
        [Position Status] AS PositionStatus,
        [Reason] AS ReasonForChange,
        [Department] AS Department,
        [Cost Center] AS CostCenter,
        [Job Family] AS JobFamily
    FROM [Your Workday staged position attribute source]
),
normalized_events AS (
    SELECT
        s.PositionId,
        'Position Request Initiated' AS ActivityName,
        s.SourceEventTime AS EventTime,
        s.SourceEndTime AS EndTime,
        s.SourceUser AS User,
        COALESCE(s.SourcePositionStatus, p.PositionStatus) AS PositionStatus,
        s.SourceReasonForChange AS ReasonForChange,
        COALESCE(s.SourceDepartment, p.Department) AS Department,
        COALESCE(s.SourceCostCenter, p.CostCenter) AS CostCenter,
        COALESCE(s.SourceJobFamily, p.JobFamily) AS JobFamily,
        s.SourceEventId AS SourceEventId
    FROM source_events s
    LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Create Position'
      AND (s.EventType = 'Initiated' OR s.StepName = 'Create Position')
    UNION ALL
    SELECT s.PositionId, 'Manager Approval Submitted', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Create Position' AND s.StepName = 'Manager Approval' AND s.StepStatus = 'Completed'
    UNION ALL
    SELECT s.PositionId, 'HR Approval Submitted', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Create Position' AND s.StepName = 'HR Approval' AND s.StepStatus = 'Completed'
    UNION ALL
    SELECT s.PositionId, 'Budget Approved', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Create Position' AND s.StepName = 'Budget Approval' AND s.StepStatus = 'Completed'
    UNION ALL
    SELECT s.PositionId, 'Position Request Denied', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Create Position' AND (s.StepStatus = 'Denied' OR s.EventType = 'Denied')
    UNION ALL
    SELECT s.PositionId, 'Position Created', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Create Position' AND s.StepStatus = 'Completed' AND s.EventType = 'Completed'
    UNION ALL
    SELECT s.PositionId, 'Position Attributes Modified', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Edit Position Restrictions' AND s.StepStatus = 'Completed'
    UNION ALL
    SELECT s.PositionId, 'Position Reclassified', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Change Job' AND s.StepStatus = 'Completed'
    UNION ALL
    SELECT s.PositionId, 'Position Compliance Reviewed', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.StepStatus = 'Completed' AND (s.StepName = 'Compliance Review' OR s.StepName = 'Compliance Checklist' OR s.StepName = 'Compliance To Do')
    UNION ALL
    SELECT s.PositionId, 'Position Frozen', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Freeze Position' AND s.StepStatus = 'Completed'
    UNION ALL
    SELECT s.PositionId, 'Position Unfrozen', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.PreviousPositionStatus = 'Frozen' AND s.SourcePositionStatus = 'Active'
    UNION ALL
    SELECT s.PositionId, 'Position Deactivated', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Inactivate Position' AND s.StepStatus = 'Completed'
    UNION ALL
    SELECT s.PositionId, 'Position Closed', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Close Position' AND s.StepStatus = 'Completed'
),
deduplicated_events AS (
    SELECT
        PositionId,
        ActivityName,
        EventTime,
        EndTime,
        User,
        PositionStatus,
        ReasonForChange,
        Department,
        CostCenter,
        JobFamily,
        ROW_NUMBER() OVER (
            PARTITION BY PositionId, ActivityName, EventTime, COALESCE(SourceEventId, '')
            ORDER BY EndTime DESC NULLS LAST
        ) AS duplicate_rank
    FROM normalized_events
)
SELECT
    PositionId,
    ActivityName,
    EventTime,
    EndTime,
    User,
    PositionStatus,
    ReasonForChange,
    Department,
    CostCenter,
    JobFamily
FROM deduplicated_events
WHERE duplicate_rank = 1
  AND PositionId IS NOT NULL
  AND ActivityName IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY PositionId, EventTime, ActivityName;

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

このデータテンプレートがあれば、ポジション管理プロセスの改善を始めるために必要な準備が整います。今すぐWorkday HCMのデータを使い、プロセスをより明確に把握して効率を高めてください。

改善ガイドに戻るテンプレートをダウンロード

今すぐWorkday HCMの採用から退職まで：ポジション管理を最適化

非効率な箇所を特定し、ポジション管理のサイクル時間を30％短縮します。

無料トライアルを開始

クレジットカードは不要です。14日間の無料トライアルを今すぐ始められます。

採用から退職まで：ポジション管理のデータテンプレート

採用から退職まで：ポジション管理のデータテンプレート

採用から退職までのポジション管理の属性

採用から退職までのポジション管理のアクティビティ

抽出ガイド

Workdayカスタムレポート・アズ・ア・サービス（RaaS）による抽出

ステップ

設定

a サンプルクエリ sql

Workday Web Services（WWS）APIを使用したPythonスクリプト

ステップ

設定

a サンプルクエリ python

Workdayコネクターを備えたミドルウェアまたはETLプラットフォーム

ステップ

設定

a サンプルクエリ sql

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

今すぐWorkday HCMの採用から退職まで：ポジション管理を最適化

採用から退職まで：ポジション管理のデータテンプレート

採用から退職まで：ポジション管理のデータテンプレート

採用から退職までのポジション管理の属性

採用から退職までのポジション管理のアクティビティ

抽出ガイド

Workdayカスタムレポート・アズ・ア・サービス（RaaS）による抽出

ステップ

設定

a サンプルクエリ sql

Workday Web Services（WWS）APIを使用したPythonスクリプト

ステップ

設定

a サンプルクエリ python

Workdayコネクターを備えたミドルウェアまたはETLプラットフォーム

ステップ

設定

a サンプルクエリ sql

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

今すぐWorkday HCMの採用から退職まで：ポジション管理を最適化

プライバシーを大切にしています