採用から退職まで:ポジション管理のデータテンプレート
採用から退職まで:ポジション管理のデータテンプレート
- 詳細な分析に向けて収集を推奨する属性
- 正確なプロセスディスカバリーに向けて追跡すべき主要なプロセスアクティビティ
- Microsoft Dynamics 365 Human Resources向けのデータ抽出ガイド
採用から退職まで:ポジション管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | ポジション管理プロセスで発生した特定のイベントまたはタスクの名前です。 | ||
| 説明 この属性は、「Position Request Initiated」、「Position Created In HR System」、「Position Deactivated」など、ポジションのライフサイクルにおける1つのステップを示します。イベントの順序を示すプロセスマップの基盤となる項目です。 アクティビティ名を分析することで、プロセスフローを可視化し、標準プロセスからの逸脱を特定し、各ステップ間の遷移時間を計算できます。何が起き、どのような順序で進んだかを理解するための基本的な項目です。 重要な理由 プロセスの各ステップを定義し、プロセスマップの可視化とプロセスフローおよびばらつきの分析を可能にします。 入手先 Microsoft Dynamics 365 Human Resourcesの業務イベント、ステータス変更、ワークフロー履歴から導出されます。単一のフィールドではなく、データの内容に基づいて構成されます。 例 ポジション依頼を開始マネージャーがポジション依頼を承認人事システムでポジションを作成ポジション属性を変更ポジションをクローズ | |||
| イベント時刻 EventTime | アクティビティが発生した時点を示すタイムスタンプです。 | ||
| 説明 イベント時刻、つまりタイムスタンプは、アクティビティが完了した正確な日時を記録します。イベントを時系列に並べ、期間やサイクルタイムを計算するために欠かせません。 この属性は、プロセスマップの作成から「ポジション承認の平均サイクルタイム」などのパフォーマンスKPIの計算まで、ほぼすべてのプロセスマイニング分析で使用します。遅延が発生した時点と、各プロセスステップにかかった時間を特定できます。 重要な理由 このタイムスタンプは、イベントの順序付け、時間に基づくすべての指標の計算、プロセスのボトルネックの発見に欠かせません。 入手先 通常は、システムログテーブル、またはDynamics 365 HRのポジションレコードやワークフローレコードに関連付けられた「CreatedDateTime」や「ModifiedDateTime」フィールドに記録されています。 例 2023-04-15T09:00:00Z2023-04-15T14:35:10Z2023-04-18T11:21:05Z2023-05-02T16:45:00Z2024-01-10T10:00:00Z | |||
| ポジションID PositionId | 組織内の特定のポジションを一意に識別するIDです。 | ||
| 説明 Position IDは主要なケース識別子として機能し、1つのポジションに関連するすべてのアクティビティとデータ項目を紐付けます。これにより、ポジションの作成や変更から、最終的な非アクティブ化またはクローズまで、ライフサイクル全体を追跡できます。 プロセス分析では、このIDが各ポジションの経路を再構築するために欠かせません。サイクルタイムを監視し、承認のボトルネックを特定し、依頼からクローズまでのプロセスバリアントを分析するダッシュボードを作成できます。 重要な理由 関連するすべてのイベントを1つのプロセスケースに結び付ける中核識別子です。ポジションのライフサイクル全体を分析できます。 入手先 通常は、Microsoft Dynamics 365 Human ResourcesのHcmPosition.PositionIdフィールドです。HcmPositionV2Entityなどのデータエンティティで確認できます。 例 POS001234MKT-0056FIN-SR-ANALYST-02HRBP-EAST-01IT-DEV-9876 | |||
| ポジションのステータス PositionStatus | ポジションの現在または過去のステータスです。 | ||
| 説明 この属性は、特定の時点におけるポジションの状態を示します。例として、「Proposed」、「Active」、「Frozen」、「Closed」などがあります。ステータスの変更は、プロセス内のアクティビティに対応することがよくあります。 ステータスを追跡すると、ポジションの進捗を把握し、「Position Compliance Review Status」や「Stale and Underutilized Positions」などのダッシュボードを確認できます。ポジションの現在の状態を示すスナップショットとして、プロセスフローの検証にも役立ちます。 重要な理由 各ポジションの状態を明確に示せるため、ケースのフィルタリングや結果の把握に欠かせません。 入手先 Microsoft Dynamics 365 Human Resourcesのドキュメントを参照してください。中核となるPositionレコードのステータスフィールドから導出される可能性があります。 例 提案中審査中有効凍結終了 | |||
| ユーザー名 UserName | アクティビティを実行したユーザーの名前またはIDです。 | ||
| 説明 この属性は、特定のプロセスステップを担当した従業員またはシステムユーザーを識別します。たとえば、申請を承認したマネージャーや、システムにポジションを登録した人事担当者を特定できます。 ユーザー別に分析すると、トレーニングの必要性を把握し、チームメンバー間のパフォーマンスを比較して、業務量の分布を確認できます。また、職務分掌が適切に行われているかを確認するコンプライアンスチェックにも役立ちます。 重要な理由 個人またはチーム単位で責任の所在を明確にし、パフォーマンスを分析できます。リソース管理やトレーニングにも欠かせません。 入手先 Dynamics 365 HRのワークフロー履歴または監査証跡レコードに関連付けられます。HcmWorkerエンティティのUser IDを介してリンクされる場合があります。 例 John SmithJane DoeSYSTEMHRAdmin01MGR-FINANCE | |||
| 原価センター CostCenter | ポジションにかかる費用が割り当てられる財務上の原価センターです。 | ||
| 説明 原価センターは、ポジションを特定の予算または財務責任領域に結び付ける重要な財務ディメンションです。この属性の変更を監視する必要があります。 この属性は、作成後の主要属性の変更を分析する「Position Data Consistency Check」ダッシュボードに欠かせません。また、財務単位別にポジション関連の費用や予算を分析する際にも使われます。 重要な理由 ポジションを財務データに結び付け、費用に関するプロセス分析とデータ整合性の監視を可能にします。 入手先 通常は、ポジションレコードの財務ディメンションとして設定されます。Dynamics 365の財務ディメンション設定を参照してください。 例 CC-1001-FINCC-2500-ITCC-4510-SALESCC-7000-OPSCC-9002-HR | |||
| 終了時刻 EndTime | アクティビティが完了した時点を示すタイムスタンプです。 | ||
| 説明 EndTimeは、アクティビティの終了を示します。StartTimeとEndTimeの間に経過した時間が、そのアクティビティの処理時間です。 この属性は、アクティビティ単位の所要時間を計算し、プロセス内のどこで時間が費やされているかを把握するために欠かせません。たとえば、ポジション申請が割り当てられてから、マネージャーが承認するまでにかかる時間を確認できます。 重要な理由 アクティビティの処理時間を計算できるため、詳細なパフォーマンス分析やボトルネック分析の基盤となります。 入手先 後続イベントのタイムスタンプ、またはDynamics 365 HRのワークフローログに記録された特定の「完了」フィールドから導出できます。多くの場合、推定が必要です。 例 2023-04-15T09:05:12Z2023-04-15T15:00:00Z2023-04-19T09:00:00Z2023-05-03T10:00:00Z2024-01-10T10:05:00Z | |||
| 職種名 JobTitle | ポジションに関連付けられた職種名です。例として、「Senior Accountant」などがあります。 | ||
| 説明 職種名は、ポジションの役割や責任を理解するための重要な情報です。Position IDとは異なり、複数のポジションが同じ職種名を持つ場合があります。 分析では、この属性を使って役割の種類ごとにグループ化やフィルタリングができます。「Position Reclassification Trends」ダッシュボードでは、どの職種が最も頻繁に再分類されているかを確認できます。 重要な理由 職務、レベル、機能に基づく分析が可能になり、業務上の重要な背景情報を加えられます。 入手先 Positionに関連付けられた「Job」レコードからリンクされます。HcmPositionV2Entityなどのエンティティで確認するか、HcmJobEntityと結合してください。 例 上級財務アナリストソフトウェアエンジニアIIHRビジネスパートナーマーケティングコーディネーター物流マネージャー | |||
| 部門 DepartmentName | ポジションが所属する部門です。 | ||
| 説明 この属性は、ポジションに関連付けられた組織上の部門を示します。例として、「Finance」、「Marketing」、「IT」などがあります。プロセスデータのフィルタリングや集計に使う主要な軸です。 部門別の分析は、「Departmental Position Throughput」ダッシュボードに欠かせません。部門間のプロセスパフォーマンスを比較し、部門固有のボトルネックを特定して、事業の各領域における採用傾向を把握できます。 重要な理由 事業部門ごとにプロセスを分けて分析できるため、部門固有の問題を特定し、パフォーマンスを比較できます。 入手先 この情報はポジションの詳細情報の一部であり、通常はHcmPositionDetailエンティティに保存され、運用単位のディメンションにリンクされます。 例 財務情報技術営業・マーケティング人事業務運営 | |||
| ソースシステム SourceSystem | データを抽出したシステムです。 | ||
| 説明 この属性は、プロセスデータの取得元を示します。このビューでは、通常「Microsoft Dynamics 365 Human Resources」です。 複数のシステムが存在する環境では、データの系譜を追跡し、問題を解決するために欠かせない項目です。想定したソースからデータが取得されていることを確認でき、特定のシステムに絞って分析する際にも利用できます。 重要な理由 データの取得元に関するコンテキストを提供します。データガバナンスや、複数の業務システムにまたがる分析で重要です。 入手先 データの抽出および変換処理の際に追加され、データセットの取得元を示す固定値です。 例 Microsoft Dynamics 365 Human ResourcesD365 HRDynamicsHR | |||
| ポジション種別 PositionType | フルタイム、パートタイム、臨時など、ポジションを分類します。 | ||
| 説明 この属性は、雇用条件に基づいてポジションを分類します。人員分析や計画に必要な追加情報となります。 プロセス分析では、ポジション種別でフィルタリングすると、雇用形態によってプロセス経路やサイクルタイムが異なるかを確認できます。たとえば、臨時ポジションは、常勤のフルタイムポジションよりも承認プロセスが速く、簡略化されている場合があります。 重要な理由 雇用形態ごとのプロセスの違いを分析できるため、人員計画やプロセスの改善に役立ちます。 入手先 通常は、Dynamics 365 HRのポジションレコードで確認できます。HcmPositionV2Entityなどのエンティティで該当するフィールドを確認してください。 例 フルタイムパートタイム契約社員インターン臨時 | |||
| 予算承認済みかどうか IsBudgetApproved | ポジションの予算が承認されているかどうかを示すフラグです。 | ||
| 説明 特定のポジションケースで「Position Budget Approved」アクティビティが発生している場合、このブール型属性はtrueになります。プロセスフローを分析し、予算待ちで停滞しているポジションを特定できます。 この属性を使ってプロセスをフィルタリングすると、「Position Budget Approval Cycle Time」KPIをより効果的に分析できます。予算承認を通過したポジションと、まだ通過していないポジションを区別できるため、ボトルネック分析に役立ちます。 重要な理由 重要なマイルストーンを明確なフラグで示すため、分析を簡単にし、予算承認段階を切り分けて測定できます。 入手先 ケース履歴に「Position Budget Approved」アクティビティが存在するかを確認し、データ変換時に導出されます。 例 truefalse | |||
| 最終データ更新 LastDataUpdate | ソースシステムからデータが最後に更新された時点のタイムスタンプです。 | ||
| 説明 この属性は、Microsoft Dynamics 365 Human Resourcesからデータが最後に抽出された日時を示します。分析対象データの鮮度を把握するための情報です。 この情報をダッシュボードに表示することで、最新の情報を確認していることを利用者が把握できます。プロセスマイニングプロジェクトにおける重要なメタデータです。 重要な理由 データがどの時点のものかを利用者に伝えます。分析結果に基づいて意思決定を行ううえで欠かせない情報です。 入手先 このタイムスタンプは、データの抽出、変換、ロード(ETL)処理の際に生成され、保存されます。 例 2024-05-21T02:00:00Z2024-05-20T02:00:00Z2024-05-19T02:00:00Z | |||
| 却下理由 RejectionReason | ポジション申請が却下された際に記録される理由です。 | ||
| 説明 ポジション申請がマネージャーまたは人事部門によって却下されると、通常は理由が記録されます。予算上の制約、情報の誤り、戦略の変更などが考えられます。 この属性は、「Position Request Rejection Rate」KPIの計算と、手戻りが発生する理由の把握に欠かせません。却下理由を分析すると、申請品質の低さやガイドラインの不明確さなど、改善できる上流の問題を特定できます。 重要な理由 申請が失敗する理由を直接把握できるため、手戻りや却下率を減らすための改善策を絞り込めます。 入手先 Microsoft Dynamics 365 Human Resourcesのドキュメントを参照してください。却下時のワークフローコメントまたは専用の理由コードフィールドに記録されることがよくあります。 例 予算なし重複した依頼誤った職務プロファイル採用凍結戦略的な再編 | |||
| 所在地 Location | ポジションの物理的または地理的な所在地です。 | ||
| 説明 この属性は、ポジションの勤務地を示します。オフィス、都市、国などが該当します。プロセスデータのフィルタリングやセグメント化に使う重要な別の軸です。 所在地は、「Departmental Position Throughput」ダッシュボードで、地域別の人員配置の傾向やプロセスパフォーマンスを分析するために直接使われます。特定の所在地で、ポジションの作成や承認に時間がかかっているかを確認できます。 重要な理由 地理的な背景情報を加え、所在地ごとのプロセスパフォーマンスや傾向を分析できます。 入手先 Microsoft Dynamics 365 Human Resourcesのドキュメントを参照してください。ポジションの詳細情報の一部であるか、部門または法人を介してリンクされている可能性があります。 例 ニューヨーク、米国ロンドン、英国ベルリン、ドイツシンガポールリモート | |||
| 手戻りかどうか IsRework | アクティビティが手戻りループの一部かどうかを示すフラグです。 | ||
| 説明 このブール型フラグは、属性の変更後に再承認する場合など、プロセス内で繰り返されるステップをアクティビティが表すときにtrueになります。非効率なプロセスループを定量化できます。 この属性は、「Position Rework Analysis」ダッシュボードと「Rework Rate on Position Creation」KPIを直接支えます。手戻りを示すことで、プロセスの非効率性の頻度や影響を簡単にフィルタリングして測定できます。 重要な理由 プロセスの手戻りを明確に特定して定量化できるため、プロセス改善の主要な対象を把握できます。 入手先 ケース内のアクティビティの順序に基づいて計算されます。たとえば、「Position Attributes Modified」の後に「Position Request Approved By Manager」が発生した場合、手戻りとしてフラグを付けられます。 例 truefalse | |||
| 承認サイクルタイム ApprovalCycleTime | ポジション申請の開始から最終承認までにかかる合計時間です。 | ||
| 説明 この計算指標は、「Position Request Initiated」アクティビティから最終承認アクティビティまでの所要時間を測定します。最終承認は「Position Request Approved By HR」などです。ポジション管理プロセスの前半を評価する主要なパフォーマンス指標です。 この属性は、「Position Approval Cycle Time」ダッシュボードとKPIに直接反映されます。承認プロセスの効率を上位レベルで測定し、改善施策の効果を継続的に追跡できます。 重要な理由 承認プロセス全体の効率を測定する重要なKPIです。ポジションを作成できる状態にするまでの遅延を直接把握できます。 入手先 ケース単位で、承認フェーズの開始アクティビティと終了アクティビティのタイムスタンプを取得し、その差分を計算します。 例 P3DT2H15MP10DP1DT12HP5DT6HP2W | |||
| 申請マネージャー RequestingManager | ポジションの申請を開始したマネージャーです。 | ||
| 説明 この属性は、新規ポジションまたは補充ポジションを申請してプロセスを開始した採用マネージャーまたは部門責任者を識別します。ポジションの需要がどこから生じているかを把握できます。 申請マネージャー別に分析すると、申請件数、承認率、申請品質の傾向を確認できます。業務量やプロセスの遵守状況を把握するための、追加の詳細情報となります。 重要な理由 ポジション需要の発生源を追跡し、採用マネージャーの視点からプロセス指標を分析できます。 入手先 Microsoft Dynamics 365 Human Resourcesのドキュメントを参照してください。この情報は、通常、ワークフローの開始データに記録されます。 例 Robert JonesSusan MillerDavid ChenMaria GarciaPaul Williams | |||
| 職種ファミリー JobFamily | 「Engineering」や「Finance」など、機能が類似する職種のグループです。 | ||
| 説明 職種ファミリーは、関連する職種名をまとめる分類です。たとえば、「Software Engineer」と「QA Engineer」は、どちらも「Engineering」職種ファミリーに含まれる場合があります。 この属性は「Position Reclassification Trends」ダッシュボードに欠かせません。どの職種カテゴリーが最も頻繁に変更されているかを、より上位の視点で分析できます。個々の職種名を見るよりも、広い範囲を把握できます。 重要な理由 ポジションをカテゴリー単位で幅広く分析できるため、戦略的な人員計画や傾向分析に役立ちます。 入手先 Dynamics 365 HRの職種設定の一部です。HcmJobEntityで「Job family」または「Job function」に関連するフィールドを確認してください。 例 エンジニアリング財務・会計営業人事プロダクトマネジメント | |||
採用から退職まで:ポジション管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| ポジションをアクティブ化 | ポジションが正式にオープンになり、採用を開始できる状態になったことを示します。通常は、ポジションレコードのステータスフィールドが「Active」または同様の状態に変更されたことから推定します。 | ||
| 重要な理由 要員配置の準備状況と最終設定段階の効率を測定する重要なマイルストーンです。ポジションのアクティブ化までの平均時間KPIの測定に欠かせません。 入手先 ポジションレコードの「PositionStatus」などのステータスフィールドが「Active」または「Open」に更新された時点のタイムスタンプを追跡して推定します。 取得 ポジションのActivationDateフィールドに日付が入力された日、またはステータスフィールドが「Active」に変更された日を基にします。 イベントタイプ inferred | |||
| ポジションをクローズ | ポジションレコードが最終的にアーカイブされ、ライフサイクルが完全に終了したことを示します。ステータスが「Closed」または同様の終了状態に変更されたことから推定します。 | ||
| 重要な理由 プロセスの終端イベントです。ライフサイクル全体を最初から最後まで分析でき、クローズすべき長期間未使用のポジションを特定するのに役立ちます。 入手先 ポジションレコードのステータスフィールドが「Closed」に変更されたことから推定します。履歴を残すため、非アクティブ化よりも発生頻度は低い傾向があります。 取得 ステータスフィールドが「Closed」に更新された時点のタイムスタンプから推定します。 イベントタイプ inferred | |||
| ポジションを非アクティブ化 | ポジションがアクティブではなくなり、通常は充足後にアクティブな組織構造から外されたことを示します。ステータスが「Inactive」または同様の状態に変更されたことから推定します。 | ||
| 重要な理由 ポジションのアクティブな期間の終わりにおける重要なステップです。ポジションの非アクティブ化までの平均時間を分析し、在籍人数を正確に管理するうえで欠かせません。 入手先 「RetirementDate」フィールドに日付が入力された時点、またはポジションレコードのステータスフィールドが「Inactive」に変更された時点のタイムスタンプから推定します。 取得 ポジションのRetirementDateが設定された日、またはステータスフィールドが「Inactive」に変更された日を基にします。 イベントタイプ inferred | |||
| ポジション依頼を開始 | ポジション管理のライフサイクルが正式に始まったことを示します。通常は、ユーザーがDynamics 365 HRの専用フォームまたはワークフローから新しいポジション依頼を送信した時点で記録されます。 | ||
| 重要な理由 ポジションのライフサイクル全体を測定する起点です。ポジション承認サイクルタイムやポジション作成リードタイムなど、重要なKPIの測定にも使用します。 入手先 ポジション依頼レコードの作成タイムスタンプ、またはWorkflowTrackingStatusTableなどのワークフロー履歴テーブルにある開始レコードから取得します。 取得 新しいポジション依頼ワークフローの送信時にイベントが記録されます。 イベントタイプ explicit | |||
| 人事システムでポジションを作成 | Dynamics 365 HR内でポジションレコードが正式に作成されたことを示します。ポジションの主要レコード自体に記録された作成タイムスタンプから取得します。 | ||
| 重要な理由 依頼から実際の組織上のポジションへ移行したことを示す基本的なマイルストーンです。ポジション作成リードタイムKPIの終点になります。 入手先 HcmPositionなど、メインのポジションテーブルにある「CreatedDateTime」システムフィールドから取得します。 取得 HcmPositionテーブルのCreatedDateTimeシステムフィールドから抽出します。 イベントタイプ explicit | |||
| 人事部がポジション依頼を承認 | ポジションを正式に作成する前に、人事部による最終承認が行われたことを示します。ワークフローシステムで人事承認タスクが完了した時点に、明示的なイベントとして記録されます。 | ||
| 重要な理由 承認フェーズの終了を示し、ポジション承認の平均サイクルタイム全体を測定する重要なマイルストーンです。 入手先 人事担当者が承認タスクを完了した時点で、WorkflowTrackingTableなどのワークフロー履歴テーブルに記録されます。 取得 人事承認ステップの完了時に、タイムスタンプ付きのイベントとしてワークフロー履歴に記録されます。 イベントタイプ explicit | |||
| ポジションのコンプライアンスレビューを実施 | ポジションが正式なコンプライアンスチェックを受けたことを示します。ステータスの変更、チェックリストタスクの完了、カスタムフィールドの更新などから取得できます。 | ||
| 重要な理由 規制および社内ポリシーの遵守状況を監視するうえで欠かせません。ポジションのコンプライアンス遵守率KPIを直接支えます。 入手先 ポジションレコードの「ComplianceReviewStatus」のようなタイムスタンプ付きステータスフィールド、または「IsComplianceReviewed」ブールフィールドから推定します。 取得 コンプライアンスステータスフィールドが「Completed」または「Reviewed」に更新された時点のタイムスタンプから推定します。 イベントタイプ inferred | |||
| ポジションを再分類 | 職種ファミリーやレベルなど、ポジションの基本的な分類が変更されたことを示す重要な更新です。通常は、ポジションレコードの「Job」フィールドの変更から推定します。 | ||
| 重要な理由 組織構造の変更と職務定義の安定性を分析するのに役立ちます。ポジション再分類率KPIの中心となるアクティビティです。 入手先 HcmPositionテーブルの「JobId」フィールドの変更を、データベースログまたはレコードバージョンの経時比較によって取得し、推定します。 取得 ポジションレコードの職務分類フィールドに記録された変更から推定します。 イベントタイプ inferred | |||
| ポジションを凍結 | ポジションが一時的に保留され、採用活動が停止されたことを示します。ポジションレコードのステータスが「Frozen」または「On Hold」に変更されたことから推定します。 | ||
| 重要な理由 ポジションのライフサイクルにおける中断を追跡し、人員計画や予算への影響を分析できます。採用遅延の理由を特定するのにも役立ちます。 入手先 ポジションレコードのステータスフィールドが「Frozen」または同様の値に更新された時点のタイムスタンプを追跡して推定します。 取得 ステータスが「Frozen」または「On Hold」に変更された時点のタイムスタンプから推定します。 イベントタイプ inferred | |||
| ポジション予算を承認 | 新しいポジションに必要な予算が割り当てられたことを確認する、重要な承認マイルストーンです。通常は、ポジション作成ワークフロー内の独立した承認ステップとして記録されます。 | ||
| 重要な理由 財務承認の段階を切り分け、予算配分に関する遅延を分析できるようにします。また、ポジション予算承認サイクルタイムKPIにも利用できます。 入手先 WorkflowTrackingTableなどのワークフロー履歴テーブルで、通常は財務担当者に割り当てられた完了済みの承認タスクとして記録されます。 取得 ワークフローログにある予算承認タスクの完了タイムスタンプから取得します。 イベントタイプ explicit | |||
| ポジション依頼を却下 | 承認段階のいずれかでポジション依頼が否認されたことを示します。承認者が「Reject」アクションを選択した時点で、ワークフロー履歴に明示的に記録されます。 | ||
| 重要な理由 プロセスの失敗や手戻りのループを明らかにします。却下理由を分析することで、初回依頼の品質を高め、ポジション依頼却下率KPIの改善につなげられます。 入手先 対象のポジション依頼について、WorkflowTrackingStatusTableなどのワークフロー履歴テーブルに「Rejection」ステータスとして記録されます。 取得 承認者が却下アクションを実行した時点で、ワークフローログから取得します。 イベントタイプ explicit | |||
| ポジション属性を変更 | ポジションの初回作成後に、職位名や部門などの主要属性が変更されたことを示します。通常は、システムのデータベースログで変更を追跡して推定します。 | ||
| 重要な理由 このアクティビティの頻度が高い場合、データ品質の低さやプロセスの手戻りを示している可能性があります。ポジション属性変更頻度KPIと手戻り率KPIの測定に欠かせません。 入手先 ポジションテーブルで変更追跡が有効になっている場合は、SysDatabaseLogテーブルから推定します。それ以外の場合は、ポジションデータの過去のスナップショットを比較する必要があります。 取得 データベースログを通じてHcmPositionテーブルの主要フィールドに対する更新操作を検出し、推定します。 イベントタイプ inferred | |||
| マネージャーがポジション依頼を承認 | 採用マネージャーによる一次承認が完了したことを示します。マネージャーが割り当てられた承認タスクを完了した時点で、ワークフロー履歴に明示的に記録されます。 | ||
| 重要な理由 初回承認ステップにかかった時間を特定し、特定のマネージャーや部門に起因するボトルネックを見つけるのに役立ちます。 入手先 ポジション依頼に関連するWorkflowTrackingTableなどのワークフロー履歴テーブルで、完了したステップとして記録されます。 取得 ワークフローログにあるマネージャー承認ステップの完了タイムスタンプから取得します。 イベントタイプ explicit | |||
| 採用プロセスを開始 | ポジション管理から採用への引き継ぎを示します。対象のPosition IDに紐付く新しい求人または採用プロジェクトが作成された時点で推定します。 | ||
| 重要な理由 ポジション管理プロセスとその成果をつなぎ、ポジションのアクティブ化から実際の採用活動開始までの時間を分析できるようにします。 入手先 Position IDを参照するHcmRecruitingRequestなど、採用または求人テーブルのレコード作成日を特定して推定します。 取得 PositionIdを、採用モジュールで対応するレコードが作成された時点と紐付けて推定します。 イベントタイプ inferred | |||
抽出ガイド
ステップ
- データ管理ワークスペースへ移動:Microsoft Dynamics 365 Human Resourcesにログインします。メインの検索バーから「Data management」ワークスペースへ移動します。
- 新しいエクスポートプロジェクトを作成:ワークスペースで「Export」タイルを選択します。「Export」プロジェクトページで「New」をクリックし、新しいプロジェクトを作成します。「PositionManagement_EventLog_Export」などの分かりやすい名前を付け、データ形式を選択します。変換を行う場合は「CSV」を推奨します。
- プロジェクトにデータエンティティを追加:新しいプロジェクトで「Add entity」をクリックします。ポジションのライフサイクル全体を記録するには、複数のエンティティを追加する必要があります。次の主要エンティティを1つずつ追加します:「HcmPositionV2」、「WorkflowTrackingStatusTable」、「HcmRecruitingRequest」。ポジション変更のデータベースログが有効な場合は、「SysDatabaseLog」も追加します。
- エンティティのフィルターを設定:各エンティティには、対象データを絞り込むフィルターを必ず設定してください。エンティティを選択し、「Filter」をクリックします。「HcmPositionV2」では、「CreatedDateTime」または「ModifiedDateTime」フィールドを使って特定の期間で絞り込みます。「WorkflowTrackingStatusTable」では、「CONTEXTTABLENAME」をポジション関連のワークフローだけに限定します。
- 各エンティティのフィールドを選択:後の変換に必要なすべてのフィールドをエクスポートします。「HcmPositionV2」には、「PositionId」、「CreatedDateTime」、「ActivationDate」、「RetirementDate」、「ModifiedDateTime」、「JobId」、「DepartmentNumber」を含めます。「WorkflowTrackingStatusTable」には、「ContextRecId」、「WorkflowTrackingStatus」、「CreatedDateTime」、「UserId」を含めます。
- エクスポートジョブを実行:すべてのエンティティ、フィールド、フィルターを設定したら、メインのプロジェクトページで「Export」をクリックします。システムによって、エンティティごとに分かれたファイルを含むデータパッケージが作成されます。
- データパッケージを監視してダウンロード:「Job history」セクションでジョブの進行状況を確認できます。ジョブが正常に完了したら、圧縮されたデータパッケージをダウンロードします。
- データを展開して変換:ダウンロードしたパッケージを解凍します。エンティティごとに分かれたCSVファイルが見つかります。これらは最終的なイベントログではなく、生のデータです。外部スクリプト(pandasを使うPythonやPowerShellなど)で処理する必要があります。
- 変換ロジックを実装:スクリプトでは、次の処理を行います。
- 「HcmPositionV2.csv」を読み込みます。「PositionId」と「CreatedDateTime」を使って、「Position Created In HR System」イベントを生成します。
- 「HcmPositionV2.csv」のステータスフィールドや「ActivationDate」、「RetirementDate」などの日付フィールドを解釈し、「Position Activated」、「Position Frozen」、「Position Deactivated」、「Position Closed」のステータス変更イベントを生成します。
- 「WorkflowTrackingStatusTable.csv」を読み込みます。レコードIDを使ってポジションデータと結合し、ワークフローイベント「Position Request Initiated」、「Position Request Approved By Manager」、「Position Budget Approved」、「Position Request Approved By HR」、「Position Request Rejected」を生成します。ワークフローのステータスとステップのコンテキストを、正しいActivity Nameにマッピングする必要があります。
- 「SysDatabaseLog.csv」をエクスポートした場合は、このファイルを解析し、「HcmPosition」テーブルの特定フィールドの変更に基づいて「Position Attributes Modified」と「Position Reclassified」イベントを生成します。
- 「HcmRecruitingRequest.csv」を読み込み、特定のポジションに対する採用依頼が作成された時点を特定して、「Hiring Process Started」イベントを生成します。
- 最終イベントログを作成:各データソースから生成したイベントを、1つのCSVファイルにまとめます。このファイルには、「PositionId」、「ActivityName」、「EventTime」と、マッピングできた推奨属性を含める必要があります。
- アップロード用に整形:最終CSVファイルのヘッダーが必要な属性名と一致し、「EventTime」列が一貫したタイムスタンプ形式になっていることを確認します。これで、プロセスマイニングツールへアップロードできます。
設定
- 主要なデータエンティティ:この抽出に必要な主なエンティティは次のとおりです。
HcmPositionV2:各ポジションの基本情報を保持します。作成日、アクティベーション日、職務や部門などの属性が含まれます。WorkflowTrackingStatusTable:ワークフローインスタンスの履歴を提供します。申請、承認、却下が含まれ、承認プロセスの追跡に欠かせません。HcmRecruitingRequest:採用依頼がポジションに紐付いている場合に、「Hiring Process Started」アクティビティを推定するために使います。SysDatabaseLog:任意ですが、「Position Attributes Modified」や「Position Reclassified」などの詳細な変更を記録できます。利用できるかどうかは、「HcmPosition」テーブルでデータベースログが事前設定されているかによります。
- 期間によるフィルタリング:「HcmPositionV2」エンティティでは、「CreatedDateTime」フィールドに期間フィルターを設定することを強く推奨します。データ量を管理しやすくするため、まずは6~12か月の範囲から始めるとよいでしょう。
- 増分エクスポート:継続的に分析する場合は、増分エクスポートを設定してください。前回の実行以降に変更されたレコードだけを抽出できるため、処理時間を大幅に短縮できます。
- 前提条件:エクスポートを実行するユーザーには、「Data management」ワークスペースへのアクセス権限と、指定したすべてのデータエンティティへの読み取り権限を持つセキュリティロールが必要です。通常は、「Data management administrator」などのロール、または必要なエンティティ権限を付与したカスタムロールが必要になります。
a サンプルクエリ sql
/*
This extraction uses the Dynamics 365 Data Management Framework. The 'query' is defined by configuring an export project via the user interface, not by running a script directly against the database.
A post-processing script is required to transform the output of this configuration into a final event log.
*/
-- Data Export Project Configuration --
Project Name: PositionManagement_EventLog_Export
Data Format: CSV
-- Entity 1: Positions --
Source Entity: HcmPositionV2
Fields to Export:
- PositionId
- CreatedDateTime (Used for 'Position Created In HR System' event)
- ActivationDate (Used for 'Position Activated' event)
- RetirementDate (Used for 'Position Deactivated' / 'Position Closed' event)
- ModifiedDateTime (Can be used for 'Position Attributes Modified' if SysDatabaseLog is not available)
- JobId (Used for 'Position Reclassified' event and 'JobTitle' attribute)
- DepartmentNumber (Used for 'DepartmentName' attribute)
- [Other fields for attributes like CostCenter, PositionStatus]
-- Entity 2: Workflow History --
Source Entity: WorkflowTrackingStatusTable
Fields to Export:
- ContextRecId (The record ID, used to link back to the HcmPosition record)
- ContextTableName (Filter this for 'HcmPosition')
- WorkflowTrackingStatus (Values like 'Submitted', 'Approved', 'Rejected')
- CreatedDateTime (Timestamp for the workflow event)
- UserId (The user who performed the action)
- [Workflow step name or ID field if available, to differentiate approval types]
-- Entity 3: Recruitment Requests --
Source Entity: HcmRecruitingRequest
Fields to Export:
- PositionId
- CreatedDateTime (Used for 'Hiring Process Started' event)
- RecruitingId
-- Entity 4: Database Change Log (Optional) --
Source Entity: SysDatabaseLog
Fields to Export:
- RefRecId (The record ID of the changed record)
- RefTableId (The table ID, filter for HcmPosition)
- CreatedDateTime (Timestamp of the change)
- [Fields indicating the old and new values, if available] ステップ
- 前提条件の確認:開始前に、Microsoft Dynamics 365 Human Resourcesのインスタンスで「Bring Your Own Database」(BYOD)が設定されていることを確認します。必要なデータエンティティがAzure SQL Databaseへエクスポートされていることも確認してください。主要なエンティティには、
HcmPositionV2、HcmPositionDetail、WorkflowTrackingStatusTable、HcmJob、OMOperatingUnit、HcmRecruitingRequestが含まれます。 - Azure SQL Databaseに接続:SQL Server Management Studio(SSMS)やAzure Data StudioなどのSQLクライアントツールを使い、BYODの保存先であるAzure SQL Databaseに接続します。
- データベーススキーマを確認:接続したら、データベーススキーマを確認します。D365 HRのデータエンティティはテーブルとして複製されています。BYODデータベース内のテーブル名はエンティティ名と完全には一致しない場合がありますが、通常はよく似た名前です。
- SQLクエリを読み込む:SQLクライアントで新しいクエリウィンドウを開き、このドキュメントの「query」セクションに記載されたSQLスクリプト全体を貼り付けます。
- パラメーターをカスタマイズ:クエリ内のプレースホルダー変数を変更します。分析対象の法人(例:「USMF」)を
@[YourCompanyId]に設定します。WHERE句の日付範囲(例:CREATEDDATETIME >= '2023-01-01')も、必要な期間に合わせて調整します。 - クエリを実行:BYODデータベースに対してSQLクエリ全体を実行します。実行時間は、データ量と指定した期間によって異なります。
- 結果を確認:クエリが完了したら、SQLクライアントの結果ペインで出力を確認します。
PositionId、ActivityName、EventTimeなどの列に、想定どおり値が入っていることを確認してください。 - CSVにエクスポート:結果セット全体をCSVファイルにエクスポートします。多くのSQLクライアントには、結果を直接CSVファイルに保存する機能があります。たとえばSSMSでは、結果グリッドを右クリックして「Save Results As...」を選択できます。
- アップロードの準備:エクスポートしたCSVファイルがUTF-8エンコーディングになっていることを確認します。プロセスマイニングツールへスムーズにアップロードできるよう、列ヘッダーが必要な属性(
PositionId、ActivityName、EventTimeなど)と完全に一致していることを確認してください。
設定
- BYODデータエンティティ:必要なすべてのデータエンティティがDynamics 365 HRからBYODインスタンスへ公開されていることを確認してください。このプロセスで重要なエンティティには、ポジション、ポジション詳細、ワークフロー履歴、職務、部門、採用依頼に関するものが含まれます。
- データの遅延:BYODは即時ではなく、ほぼリアルタイムの複製です。D365 HRでトランザクションが発生してからAzure SQL Databaseにデータが表示されるまで、数分から1時間程度の遅延が生じる場合があります。
- 期間によるフィルタリング:パフォーマンスとデータ量を管理するため、クエリには必ず日付フィルターを設定してください。まずは3~6か月程度の範囲から始めるのが一般的です。各
UNION ALLブロック内で、作成日時またはイベント日時にフィルターを適用します。 - 会社フィルター:正しい組織単位のデータを分析できるよう、必ず
DATAREAID(法人または会社ID)で絞り込んでください。提供されているクエリには、そのためのプレースホルダー@[YourCompanyId]が含まれています。 - 前提条件:この方法には、有効なAzureサブスクリプション、設定済みのBYODインスタンス、対象のAzure SQL Databaseへの読み取り権限、クエリ実行に適したSQLクライアントツールが必要です。
- カスタムワークフローステップ:このクエリでは、「Approve position request」など、一般的なワークフローステップ名を使用しています。組織で異なる名前を使っている場合は、該当する
WHERE句のCONTEXT値を更新してください。
a サンプルクエリ sql
SELECT
p.POSITIONID AS PositionId,
'Position Request Initiated' AS ActivityName,
w.CREATEDDATETIME AS EventTime,
w.CREATEDDATETIME AS EndTime,
w.USERID AS UserName,
dept.NAME AS DepartmentName,
pd.DESCRIPTION AS JobTitle,
'Initiated' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM WorkflowTrackingStatusTable w
JOIN HcmPositionV2 p ON w.REFRECID = p.RECID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE w.TRACKINGSTATUS = 1 -- Submitted
AND w.CONTEXT LIKE '%Create position request%'
AND p.DATAREAID = '[YourCompanyId]'
AND w.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Request Approved By Manager' AS ActivityName,
w.CREATEDDATETIME AS EventTime,
w.CREATEDDATETIME AS EndTime,
w.USERID AS UserName,
dept.NAME AS DepartmentName,
pd.DESCRIPTION AS JobTitle,
'Pending Budget' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM WorkflowTrackingStatusTable w
JOIN HcmPositionV2 p ON w.REFRECID = p.RECID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE w.TRACKINGSTATUS = 5 -- Approval
AND w.CONTEXT LIKE '%Manager approval%'
AND p.DATAREAID = '[YourCompanyId]'
AND w.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Budget Approved' AS ActivityName,
w.CREATEDDATETIME AS EventTime,
w.CREATEDDATETIME AS EndTime,
w.USERID AS UserName,
dept.NAME AS DepartmentName,
pd.DESCRIPTION AS JobTitle,
'Pending HR' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM WorkflowTrackingStatusTable w
JOIN HcmPositionV2 p ON w.REFRECID = p.RECID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE w.TRACKINGSTATUS = 5 -- Approval
AND w.CONTEXT LIKE '%Budget approval%'
AND p.DATAREAID = '[YourCompanyId]'
AND w.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Request Approved By HR' AS ActivityName,
w.CREATEDDATETIME AS EventTime,
w.CREATEDDATETIME AS EndTime,
w.USERID AS UserName,
dept.NAME AS DepartmentName,
pd.DESCRIPTION AS JobTitle,
'Approved' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM WorkflowTrackingStatusTable w
JOIN HcmPositionV2 p ON w.REFRECID = p.RECID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE w.TRACKINGSTATUS = 5 -- Approval
AND w.CONTEXT LIKE '%HR approval%'
AND p.DATAREAID = '[YourCompanyId]'
AND w.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Request Rejected' AS ActivityName,
w.CREATEDDATETIME AS EventTime,
w.CREATEDDATETIME AS EndTime,
w.USERID AS UserName,
dept.NAME AS DepartmentName,
pd.DESCRIPTION AS JobTitle,
'Rejected' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM WorkflowTrackingStatusTable w
JOIN HcmPositionV2 p ON w.REFRECID = p.RECID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE w.TRACKINGSTATUS = 3 -- Rejection
AND p.DATAREAID = '[YourCompanyId]'
AND w.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Created In HR System' AS ActivityName,
p.CREATEDDATETIME AS EventTime,
p.CREATEDDATETIME AS EndTime,
p.CREATEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Created' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE p.DATAREAID = '[YourCompanyId]'
AND p.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Attributes Modified' AS ActivityName,
p.MODIFIEDDATETIME AS EventTime,
p.MODIFIEDDATETIME AS EndTime,
p.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Modified' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE p.MODIFIEDDATETIME > p.CREATEDDATETIME
AND p.DATAREAID = '[YourCompanyId]'
AND p.MODIFIEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Reviewed For Compliance' AS ActivityName,
pd.MODIFIEDDATETIME AS EventTime,
pd.MODIFIEDDATETIME AS EndTime,
pd.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Compliance Reviewed' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE pd.[YourComplianceStatusField] = 'Reviewed' -- This requires a custom field indicating compliance review
AND p.DATAREAID = '[YourCompanyId]'
AND pd.MODIFIEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Reclassified' AS ActivityName,
p.MODIFIEDDATETIME AS EventTime,
p.MODIFIEDDATETIME AS EndTime,
p.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Reclassified' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE p.MODIFIEDDATETIME > p.CREATEDDATETIME -- This is an inference. See known limitations.
AND p.DATAREAID = '[YourCompanyId]'
AND p.MODIFIEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Activated' AS ActivityName,
pd.VALIDFROM AS EventTime,
pd.VALIDFROM AS EndTime,
pd.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Active' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE pd.VALIDFROM >= '[StartDate]'
AND p.DATAREAID = '[YourCompanyId]'
UNION ALL
SELECT
hr.POSITIONID AS PositionId,
'Hiring Process Started' AS ActivityName,
hr.CREATEDDATETIME AS EventTime,
hr.CREATEDDATETIME AS EndTime,
hr.CREATEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Recruiting' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmRecruitingRequest hr
JOIN HcmPositionV2 p ON hr.POSITIONID = p.POSITIONID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE hr.DATAREAID = '[YourCompanyId]'
AND hr.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Frozen' AS ActivityName,
pd.MODIFIEDDATETIME AS EventTime, -- Assuming a status change triggers modification time
pd.MODIFIEDDATETIME AS EndTime,
pd.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Frozen' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE p.[YourPositionStatusField] = 'Frozen' -- Requires a dedicated status field on the position
AND p.DATAREAID = '[YourCompanyId]'
AND pd.MODIFIEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Deactivated' AS ActivityName,
pd.VALIDTO AS EventTime,
pd.VALIDTO AS EndTime,
pd.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Inactive' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE pd.VALIDTO < '2154-12-31' -- D365 often uses this far-future date for 'never expires'
AND pd.VALIDTO >= '[StartDate]'
AND p.DATAREAID = '[YourCompanyId]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Closed' AS ActivityName,
pd.MODIFIEDDATETIME AS EventTime, -- Assuming a status change triggers modification time
pd.MODIFIEDDATETIME AS EndTime,
pd.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Closed' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE p.[YourPositionStatusField] = 'Closed' -- Requires a dedicated status field on the position
AND p.DATAREAID = '[YourCompanyId]'
AND pd.MODIFIEDDATETIME >= '[StartDate]' 準備はできましたか?
このテンプレートを使ってデータ収集を効率化し、採用から退職までのポジション管理プロセスを詳しく把握してください。効率化とコンプライアンスの実現に向けた取り組みを、今日から始められます。
採用から退職までのポジション管理をすぐに最適化
プロセスのサイクルタイムを30%短縮し、ボトルネックを解消します。
クレジットカードは不要です。数分で設定できます。