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

採用から退職までをカバーするポジション管理データテンプレート

Workday HCM

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

採用から退職までをカバーするポジション管理データテンプレート

このテンプレートは、「Hire to Retire - ポジション管理」プロセスを分析するために必要な不可欠なデータを収集するための明確なロードマップを提供します。収集すべき重要な属性、追跡すべき主要なアクティビティ、およびWorkday HCMからこの情報を抽出するための実用的なガイダンスを概説しています。このリソースを活用して、イベントログが完全であり、強力なプロセスマイニングインサイトに対応できるよう確保してください。

収集を推奨する項目
追跡すべき主要アクティビティ
抽出の手引き

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

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

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

これらは、包括的な「Hire to Retire - ポジション管理」分析のためにイベントログに含めることを推奨するデータフィールドです。

3 必須 7 推奨 12 任意

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

必須推奨任意

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

これらは、「Hire to Retire - ポジション管理」における正確なプロセスディスカバリのために、イベントログで捕捉すべき主要なプロセスステップとマイルストーンです。

6 推奨 7 任意

	アクティビティ	説明
	ポジション作成済み	この活動は、Workdayシステムにおけるポジションの作成成功と正式な存在を示します。これは、「ポジション作成」ビジネスプロセスの完了成功時に記録されます。
その重要性これは、承認フェーズの終了と、ポジションが人員配置の準備が整ったことを示す重要なマイルストーンです。全体の承認サイクルタイムKPIを測定するために不可欠です。取得元このイベントは、Workdayのイベントログまたは監査証跡にある「ポジション作成」ビジネスプロセスの完了タイムスタンプから捕捉されます。取得「ポジション作成」ビジネスプロセスの成功裏の完了時にログに記録されたイベント。イベントタイプ explicit
	ポジション属性変更済み	既存のポジションの1つ以上の属性（役職や部門など）が変更されたことを示します。これは、ユーザーが「ポジション制限編集」ビジネスプロセスを正常に完了したときに明示的にログに記録されます。
その重要性頻繁な変更は、データ入力エラー、変化する職務役割、またはプロセス非効率性を示唆する可能性があります。このアクティビティの分析は、「ポジションデータ手戻り分析」ダッシュボードの鍵となり、データ品質の向上につながります。取得元これは、Workdayの「ポジション制限の編集」または類似のビジネスプロセスの完了ログから捕捉されます。監査証跡には、どのフィールドが変更されたかが示されます。取得「ポジション制限編集」ビジネスプロセスの成功裏の完了時にログに記録されたイベント。イベントタイプ explicit
	ポジション要求開始済み	これは、新規ポジション作成のリクエストが正式に提出されるポジション管理ライフサイクルの始まりを示します。これは、ユーザーがWorkdayで「ポジション作成」ビジネスプロセスを開始する際に明示的なイベントとして捕捉されます。
その重要性この活動は、プロセスの主要な開始イベントです。このイベントからその後の承認までの時間を分析することは、ポジション作成サイクル全体の効率を測定するために不可欠です。取得元このイベントはWorkdayビジネスプロセスイベントログに記録されます。特定のポジションIDに対する「ポジション作成」ビジネスプロセストランザクションの開始タイムスタンプを探してください。取得「ポジション作成」ビジネスプロセスの開始時にログに記録されたイベント。イベントタイプ explicit
	ポジション閉鎖済み	これはライフサイクルにおける最終活動であり、組織からのポジションの恒久的な排除を表します。Workdayは、「ポジション閉鎖」ビジネスプロセスの完了成功時にこのイベントを記録します。
その重要性ほとんどのケースにおける最終イベントとして、このアクティビティはポジションのライフサイクルの終わりを定義します。これは、プロセスの完全な期間を理解し、正確な人員データを維持するために不可欠です。取得元 Workdayの監査証跡またはビジネスプロセスログにある「ポジション終了」ビジネスプロセスの完了タイムスタンプから捕捉されます。取得「ポジション終了」ビジネスプロセスの完了時にログに記録されたイベント。イベントタイプ explicit
	ポジション非アクティブ化済み	ポジションがもはやアクティブではなく、埋めることができないことを示します。これは多くの場合、正式な終了前の予備ステップとして行われます。「ポジション非アクティブ化」ビジネスプロセスの完了時に捕捉される明示的なイベントです。
その重要性非アクティブ化は、最終的な終了とは異なる、ポジションライフサイクルにおける重要なマイルストーンです。非アクティブ化から終了までの時間は、組織構造を整理する上での管理効率の尺度となります。取得元このイベントは、「ポジション非アクティブ化」ビジネスプロセスの完了成功時にWorkdayの監査ログに記録されます。取得「ポジション非アクティブ化」ビジネスプロセスの成功裏の完了時にログに記録されたイベント。イベントタイプ explicit
	予算承認済み	財務部門または予算管理者が、新しいポジションの資金が利用可能であることを確認する重要なマイルストーンです。これは、指定された承認者がビジネスプロセスフロー内の予算承認ステップを完了したときに捕捉されます。
その重要性予算承認はしばしば主要なボトルネックとなります。この特定のアクティビティのサイクルタイムを測定することは、組織が財務レビューを合理化し、採用を加速するのに役立ちます。取得元これは、Workdayの「ポジション作成」ビジネスプロセスの監査履歴に記録されます。予算承認ステップの完了イベントに対応します。取得ビジネスプロセスログにおける財務または予算承認ステップの完了タイムスタンプ。イベントタイプ explicit
	ポジションコンプライアンスレビュー済み	ポジションが正式なコンプライアンスチェックを受けたことを示します。例えば、内部ポリシーや外部規制に照らして行われます。これは、親ビジネスプロセス内の特定の「To Do」または「チェックリスト」ステップとして捕捉される可能性が高いです。
その重要性コンプライアンスレビューを追跡することは、リスクを軽減し、組織の基準への準拠を確保するために不可欠です。この活動は、「ポジションアクションコンプライアンス率」KPIを直接サポートします。取得元これは、「To Do」ステップの完了、または「ポジション作成」や「ポジション編集」のようなビジネスプロセス内の特定の承認ステップとして捕捉される可能性が高いです。正確なメカニズムを確認するには、システム分析が必要です。取得ビジネスプロセスログにおけるコンプライアンス関連の承認または「To Do」ステップの完了タイムスタンプ。イベントタイプ explicit
	ポジション再分類済み	ポジションに関連する職務プロファイルまたは分類の正式な変更を表します。このイベントは、「Change Job」ビジネスプロセスが特定のポジションに対して正常に完了したときに捕捉されます。
その重要性この活動は、組織再編や職務責任における重要な変化を理解するのに役立ちます。再分類を追跡することは、人材構成の進化と職務アーキテクチャの安定性分析をサポートします。取得元ポジションに適用された「Change Job」ビジネスプロセスの完了ログから取得されます（ワーカーに適用される場合とは異なります）。取得ポジションに対する「ジョブ変更」ビジネスプロセスの成功裏の完了時にログに記録されたイベント。イベントタイプ explicit
	ポジション凍結済み	ポジションを一時的に保留し、その補充を防止するアクションを表します。これは、ユーザーがWorkdayで「Freeze Position」ビジネスプロセスを正常に完了したときに捕捉されます。
その重要性この活動は、人員数と予算を管理するために重要です。ポジションが凍結状態に留まる期間を分析することは、停滞した意思決定を特定し、リソース計画を最適化するのに役立ちます。取得元「ポジション凍結」ビジネスプロセスの完了から捕捉されます。ポジションステータスフィールドは通常、このイベントの結果として更新されます。取得「ポジション凍結」ビジネスプロセスの完了時にログに記録されたイベント。イベントタイプ explicit
	ポジション凍結解除	これは凍結の逆アクションであり、一時停止されたポジションが再びアクティブ化され、人員配置に利用可能になることを意味します。これは通常、ポジションのステータスフィールドが「凍結」から「有効」に変更されたことを推測することによって捕捉されます。
その重要性このイベントは、凍結されたポジションの解決を示します。「ポジション凍結済み」からこのイベントまでの時間を測定することは、「凍結ポジション解決時間」KPIにとって重要です。取得元これは、ポジションの履歴または監査ログ内のポジションのステータスフィールドにおける有効日付変更から推測される場合があります。また、一部の構成では明示的な「凍結解除」ビジネスプロセスイベントである可能性もあります。取得有効日履歴に基づき、ポジションステータスが「凍結」から「アクティブ」への変更を検出します。イベントタイプ inferred
	ポジション要求拒否済み	この活動は、承認者が拒否したポジション作成リクエストの不成功な終了を表します。Workdayはこれを、「ポジション作成」ビジネスプロセスの「拒否済み」終端ステータスとして記録します。
その重要性却下された申請を分析することで、予算制約やポリシーの不一致など、却下の一般的な理由を特定でき、プロセス改善や申請者へのより良いガイダンスが可能になります。取得元これは、「ポジション作成」ビジネスプロセスインスタンスの最終ステータスから捕捉されます。イベントタイムスタンプは、拒否アクションが実行された時です。取得承認者がビジネスプロセスステップ内で「拒否」アクションを選択したときにログに記録されたイベント。イベントタイプ explicit
	マネージャー承認提出済み	採用マネージャーまたは管理組織マネージャーによるレビューおよび承認ステップの完了を表します。Workdayはこれを、「Create Position」ビジネスプロセス内の承認ステップの個別の完了イベントとして捕捉します。
その重要性これは一般的な初期のマイルストーンであり、潜在的なボトルネックです。この承認にかかる時間を追跡することは、ポジション作成ワークフローの初期段階における遅延を特定するのに役立ちます。取得元「ポジション作成」ビジネスプロセスの監査証跡から捕捉されます。特定の「マネージャー承認」ステップの完了に対応します。取得ビジネスプロセスログにおけるマネージャー承認ステップの完了タイムスタンプ。イベントタイプ explicit
	人事承認提出済み	人事パートナーまたは担当者がポジション申請をレビューし承認したことを示します。これは、人事承認者がWorkdayビジネスプロセス内の割り当てられたステップを完了したときに明示的にログに記録されます。
その重要性この承認は、ポジションが会社のポリシーと職務アーキテクチャに合致していることを確認するための重要なチェックポイントです。ここでの遅延は、全体のサイクルタイムに大きな影響を与える可能性があります。取得元関連するビジネスプロセスに関するWorkdayの監査証跡から取得されます。イベントは「HR承認」ステップの完了です。取得ビジネスプロセスログにおける人事承認ステップの完了タイムスタンプ。イベントタイプ explicit

推奨任意

抽出ガイド

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

ステップ

Workdayへのログイン: カスタムレポートの作成と必要な人事管理 (HCM) データドメインへのアクセス権を持つユーザーアカウントでWorkdayテナントにサインインします。
カスタムレポートの作成: 検索バーを使用して「カスタムレポートの作成」タスクを検索し、開きます。
レポートタイプとデータソースの選択: レポートに「ProcessMind ポジション管理イベント」などの名前を付けます。レポートタイプとして「Advanced」を選択します。データソースには「ビジネスプロセス取引」を選択します。このソースは、ビジネスプロセスステップに関する詳細なイベントレベルの情報を提供します。
レポート列の定義: 「列」タブで、イベントログの列となるフィールドを追加します。Workdayのオブジェクトとフィールドを必須属性にマッピングする必要があります。例えば：
- PositionId: ビジネスプロセスのコンテキストから「ポジションID」にマッピングします。
- EventTime: 各ステップの「完了日」または「修正完了モーメント」にマッピングします。
- User: トランザクションの「完了者」にマッピングします。
- ポジションステータス、部門、コストセンター、ジョブファミリー: 「ポジション」ビジネスオブジェクトの対応するフィールドにマッピングします。
アクティビティ名のための計算フィールドの作成: この抽出の中核は、ビジネスプロセスステップを標準化されたアクティビティ名に変換することです。「関連ビジネスオブジェクト」メニューに移動し、「計算フィールド」を作成します。「Evaluate Expression」タイプを使用してロジックツリーを作成します。例えば：
- 「ビジネスプロセスタイプ」が「ポジション作成」で、「取引ステータス」が「正常に完了」の場合、「ポジション作成済み」のテキストを返します。
- 「ビジネスプロセスタイプ」が「ポジション作成」で、「ステップ」が「[あなたのマネージャー承認ステップ名]」で、「ステータス」が「完了」の場合、「マネージャー承認済み」のテキストを返します。
- 必要な13のアクティビティそれぞれについて条件を作成します。
レポートフィルターの設定: 「フィルター」タブで、データを絞り込むためのプロンプトとフィルターを追加します。「完了日」にプロンプトを作成し、日付範囲の選択を可能にします。「ポジション作成」「ポジション制限編集」「ジョブ変更」「ポジション凍結」「ポジション非アクティブ化」「ポジション終了」など、関連する「ビジネスプロセスタイプ」のみを含めるフィルターを追加します。
ソートと出力の調整: 「ソート」タブで、PositionIdでソートし、次にEventTimeでソートして、各ケースが時系列順になるようにします。
Webサービスとして有効化 (RaaS): レポートがUIで正しく実行されたら、「アクション」>「Webサービス」>「Webサービスとして有効化」に進みます。オプションで、「コンテンツタイプ」を「JSON」に設定し、統合を容易にします。
エンドポイントの保護とテスト: Webサービスのセキュリティを設定して、どのユーザーまたはシステムがアクセスできるかを定義します。生成されたJSONまたはWSDLのURLを記録しておきます。Postmanなどのツールや簡単なスクリプトを使用してエンドポイントをテストし、データが受信できることを確認します。
抽出の自動化: 統合プラットフォームまたはスクリプトを使用して、スケジュールに従ってRaaS URLを呼び出します。スクリプトは、リクエストで目的の日付範囲をパラメーターとして渡す必要があります。
ProcessMind用のフォーマット: スクリプトはWorkdayからのJSON応答を解析し、それをフラットなCSVファイルに変換する必要があります。CSVの列ヘッダーが、PositionId、アクティビティ名、EventTime、Userなどの必須属性名と一致することを確認します。
ProcessMindへのアップロード: 最終的にフォーマットされたCSVファイルは、ProcessMindにアップロードして分析する準備ができています。

設定

レポートタイプ: Advanced。このタイプは、計算フィールドを作成し、異なるビジネスオブジェクトからデータを結合するために必要です。
主要データソース: 「ビジネスプロセス取引」。このデータソースはイベント指向で、ビジネスプロセスの各ステップにおけるステータス、タイムスタンプ、参加者など、必要な詳細情報を含んでいます。
主要フィルター:
- ビジネスプロセスタイプ: レポートが「ポジション作成」「ポジション終了」「ポジション凍結」「ジョブ変更」「ポジション制限編集」「ポジション非アクティブ化」といった関連プロセスのみを含むようにフィルターします。これはパフォーマンスにとって非常に重要です。
- 完了日: このフィールドにはプロンプト付きフィルターを使用し、ユーザーが抽出期間を指定できるようにします。初回ロードでは3～6ヶ月分のデータを推奨します。
計算フィールド: 標準化されたアクティビティ名を導出し、コアの「ポジション」オブジェクトから属性をイベントストリームに引き出すために、「Evaluate Expression」および「Lookup Related Value」計算フィールドを多用する必要があります。
Webサービス出力: RaaSの出力形式をJSONとして設定します。XMLも利用可能ですが、一般的にJSONの方がモダンなアプリケーションでの解析が容易です。
権限: レポートを作成するユーザーは、「ビジネスプロセス取引」「ポジション管理」「従業員データ」などのデータドメインに対するセキュリティ権限が必要です。RaaSコールによって返されるデータは、これらの権限によって制限されます。

a クエリ例 config

/*
 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カスタムレポートを作成します。「ビジネスプロセス取引」データソースを使用してください。ポジションID、ビジネスプロセスタイプ、ステップ名、ステータス、有効日、完了日、開始者など、イベントログに必要なフィールドを公開します。「Advanced」タブで「Webサービスとして有効化」を選択してレポートをWebサービスとして有効にし、統合システムユーザー (ISU) に必要な権限を設定してください。
前提条件：Workday統合ユーザーの設定。 前のステップで作成したカスタムレポートにアクセスする権限を持つ統合システムユーザー (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、アクティビティ名、EventTime、Userなどの必要な列名を持つ表形式に構造化されます。
ProcessMind用のCSVエクスポート。 スクリプトは、最終的なDataFrameをposition_management_event_log.csvという名前のCSVファイルに保存します。このファイルはUTF-8でエンコードされており、追加の変更なしでProcessMindにアップロードする準備ができています。

設定

Workdayカスタムレポート (RaaS): 主要なデータソースは、Webサービスとして有効化されたWorkdayのカスタムレポートです。このレポートは、「ビジネスプロセス取引」データソースに基づいて構築されている必要があります。
レポートフィールド: レポートには、ポジションID、ビジネスプロセス定義、ビジネスプロセスステップ、取引ステータス、有効タイムスタンプ、完了タイムスタンプ、開始者、およびコストセンターや監督組織などの必要なその他の属性を含める必要があります。
統合システムユーザー (ISU): 認証のためにユーザー名とパスワードを持つISUが必要です。このユーザーは、カスタムレポートのWebサービスエンドポイントにアクセスする権限を持つセキュリティグループに属している必要があります。
日付範囲: スクリプトはSTART_DATEとEND_DATEパラメーターを使用します。初回抽出では、データ量を管理しやすく、実行を高速化するために3〜6ヶ月間の期間を推奨します。その後の抽出では、より短いデルタ期間を使用できます。
APIエンドポイント: スクリプトにはカスタムレポートのJSONエンドポイントURLが必要です。このURLはWorkdayのカスタムレポート定義の「Webサービス」タブにあります。
アクティビティマッピング: スクリプトのロジックは、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()

ステップ

Workdayへのログイン: カスタムレポートの作成と必要な人事管理 (HCM) データドメインへのアクセス権を持つユーザーアカウントでWorkdayテナントにサインインします。
カスタムレポートの作成: 検索バーを使用して「カスタムレポートの作成」タスクを検索し、開きます。
レポートタイプとデータソースの選択: レポートに「ProcessMind ポジション管理イベント」などの名前を付けます。レポートタイプとして「Advanced」を選択します。データソースには「ビジネスプロセス取引」を選択します。このソースは、ビジネスプロセスステップに関する詳細なイベントレベルの情報を提供します。
レポート列の定義: 「列」タブで、イベントログの列となるフィールドを追加します。Workdayのオブジェクトとフィールドを必須属性にマッピングする必要があります。例えば：
- PositionId: ビジネスプロセスのコンテキストから「ポジションID」にマッピングします。
- EventTime: 各ステップの「完了日」または「修正完了モーメント」にマッピングします。
- User: トランザクションの「完了者」にマッピングします。
- ポジションステータス、部門、コストセンター、ジョブファミリー: 「ポジション」ビジネスオブジェクトの対応するフィールドにマッピングします。
アクティビティ名のための計算フィールドの作成: この抽出の中核は、ビジネスプロセスステップを標準化されたアクティビティ名に変換することです。「関連ビジネスオブジェクト」メニューに移動し、「計算フィールド」を作成します。「Evaluate Expression」タイプを使用してロジックツリーを作成します。例えば：
- 「ビジネスプロセスタイプ」が「ポジション作成」で、「取引ステータス」が「正常に完了」の場合、「ポジション作成済み」のテキストを返します。
- 「ビジネスプロセスタイプ」が「ポジション作成」で、「ステップ」が「[あなたのマネージャー承認ステップ名]」で、「ステータス」が「完了」の場合、「マネージャー承認済み」のテキストを返します。
- 必要な13のアクティビティそれぞれについて条件を作成します。
レポートフィルターの設定: 「フィルター」タブで、データを絞り込むためのプロンプトとフィルターを追加します。「完了日」にプロンプトを作成し、日付範囲の選択を可能にします。「ポジション作成」「ポジション制限編集」「ジョブ変更」「ポジション凍結」「ポジション非アクティブ化」「ポジション終了」など、関連する「ビジネスプロセスタイプ」のみを含めるフィルターを追加します。
ソートと出力の調整: 「ソート」タブで、PositionIdでソートし、次にEventTimeでソートして、各ケースが時系列順になるようにします。
Webサービスとして有効化 (RaaS): レポートがUIで正しく実行されたら、「アクション」>「Webサービス」>「Webサービスとして有効化」に進みます。オプションで、「コンテンツタイプ」を「JSON」に設定し、統合を容易にします。
エンドポイントの保護とテスト: Webサービスのセキュリティを設定して、どのユーザーまたはシステムがアクセスできるかを定義します。生成されたJSONまたはWSDLのURLを記録しておきます。Postmanなどのツールや簡単なスクリプトを使用してエンドポイントをテストし、データが受信できることを確認します。
抽出の自動化: 統合プラットフォームまたはスクリプトを使用して、スケジュールに従ってRaaS URLを呼び出します。スクリプトは、リクエストで目的の日付範囲をパラメーターとして渡す必要があります。
ProcessMind用のフォーマット: スクリプトはWorkdayからのJSON応答を解析し、それをフラットなCSVファイルに変換する必要があります。CSVの列ヘッダーが、PositionId、アクティビティ名、EventTime、Userなどの必須属性名と一致することを確認します。
ProcessMindへのアップロード: 最終的にフォーマットされたCSVファイルは、ProcessMindにアップロードして分析する準備ができています。

設定

レポートタイプ: Advanced。このタイプは、計算フィールドを作成し、異なるビジネスオブジェクトからデータを結合するために必要です。
主要データソース: 「ビジネスプロセス取引」。このデータソースはイベント指向で、ビジネスプロセスの各ステップにおけるステータス、タイムスタンプ、参加者など、必要な詳細情報を含んでいます。
主要フィルター:
- ビジネスプロセスタイプ: レポートが「ポジション作成」「ポジション終了」「ポジション凍結」「ジョブ変更」「ポジション制限編集」「ポジション非アクティブ化」といった関連プロセスのみを含むようにフィルターします。これはパフォーマンスにとって非常に重要です。
- 完了日: このフィールドにはプロンプト付きフィルターを使用し、ユーザーが抽出期間を指定できるようにします。初回ロードでは3～6ヶ月分のデータを推奨します。
計算フィールド: 標準化されたアクティビティ名を導出し、コアの「ポジション」オブジェクトから属性をイベントストリームに引き出すために、「Evaluate Expression」および「Lookup Related Value」計算フィールドを多用する必要があります。
Webサービス出力: RaaSの出力形式をJSONとして設定します。XMLも利用可能ですが、一般的にJSONの方がモダンなアプリケーションでの解析が容易です。
権限: レポートを作成するユーザーは、「ビジネスプロセス取引」「ポジション管理」「従業員データ」などのデータドメインに対するセキュリティ権限が必要です。RaaSコールによって返されるデータは、これらの権限によって制限されます。

a クエリ例 config

/*
 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カスタムレポートサービス（RaaS）によるデータ抽出

ステップ

設定

a クエリ例 config

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

ステップ

設定

a クエリ例 python

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

ステップ

設定

a クエリ例 config

今すぐ始めますか？

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

採用から退職までをカバーするポジション管理データテンプレート

採用から退職までをカバーするポジション管理データテンプレート

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

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

抽出ガイド

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

ステップ

設定

a クエリ例 config

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

ステップ

設定

a クエリ例 python

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

ステップ

設定

a クエリ例 config

お客様のプライバシーを大切にしています

今すぐ始めますか？

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