お客様のHire to Retire - ポジション管理データテンプレート
お客様のHire to Retire - ポジション管理データテンプレート
- 徹底的な分析のために収集すべき推奨`属性`
- 正確な発見のために追跡すべき主要なプロセスアクティビティ
- Microsoft Dynamics 365 Human Resourcesに特化した抽出ガイド
採用から退職まで - 役職管理属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | ポジション管理プロセスで発生した特定のイベントまたはタスクの名前。 | ||
| 説明 この属性は、「Position Request Initiated(ポジション申請開始)」、「Position Created In HR System(人事システムでポジション作成済み)」、または「Position Deactivated(ポジション非有効化)」など、ポジションのライフサイクルにおける単一のステップを記述します。これはプロセスマップの根幹をなし、イベントの順序を示します。 アクティビティ名を分析することで、プロセスフローの可視化、標準プロセスからの逸脱の特定、および異なるステップ間の移行時間の計算が可能になります。何がどのような順序で発生したかを理解するために不可欠です。 その重要性 プロセスのステップを定義し、プロセスマップの可視化とプロセスフローおよびバリエーションの分析を可能にします。 取得元 この属性は、Microsoft Dynamics 365 Human Resources内のビジネスイベント、ステータス変更、またはワークフロー履歴から派生します。これは単一のフィールドではなく、データのコンテキストに基づいて構築されます。 例 ポジション申請開始マネージャーによるポジション申請承認済み人事システムでポジション作成済みポジション属性変更済みポジションクローズ済み | |||
| イベント日時 EventTime | アクティビティの発生時刻を示すタイムスタンプです。 | ||
| 説明 イベント時間、すなわちタイムスタンプは、アクティビティが完了した正確な日時を記録します。これは、イベントを時系列で並べ、期間やサイクルタイムを計算するために不可欠です。 この属性は、プロセスマップの構築から「Average Position Approval Cycle Time(平均ポジション承認サイクルタイム)」のようなパフォーマンス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は、単一の組織ポジションに関連するすべての活動とデータポイントをリンクする主要なケース識別子として機能します。これにより、ポジションの作成と変更から、最終的な非有効化またはクローズまでの、ポジションのライフサイクル全体のエンドツーエンドの追跡が可能になります。 プロセス分析において、このIDは各ポジションの経路を再構築するために不可欠です。これにより、サイクルタイムを監視し、承認におけるボトルネックを特定し、申請からクローズまでのプロセスバリアントを分析するダッシュボードが可能になります。 その重要性 これは、関連するすべてのイベントを単一のプロセスケースに接続するコア識別子であり、エンドツーエンドのポジションライフサイクルを分析することを可能にします。 取得元 これは通常、Microsoft Dynamics 365 Human ResourcesのHcmPosition.PositionIdフィールドです。HcmPositionV2Entityのようなデータエンティティで見つけることができます。 例 POS001234MKT-0056FIN-SR-ANALYST-02HRBP-EAST-01IT-DEV-9876 | |||
| コストセンター CostCenter | ポジションの費用が配分される財務コストセンター。 | ||
| 説明 コストセンターは、ポジションを特定の予算または財務責任領域にリンクする主要な財務ディメンションです。この属性の変更は監視が重要です。 この属性は、「Position Data Consistency Check(ポジションデータ一貫性チェック)」ダッシュボードにとって重要であり、作成後の主要属性の変更を分析します。また、異なる財務単位ごとのポジション関連コストと予算を分析するためにも使用されます。 その重要性 役職を財務データに接続し、コスト関連のプロセス分析とデータ整合性の監視を可能にします。 取得元 これは通常、ポジションレコード上の財務ディメンションとして構成されます。Dynamics 365の財務ディメンション設定を参照してください。 例 CC-1001-FINCC-2500-ITCC-4510-SALESCC-7000-OPSCC-9002-HR | |||
| ポジションステータス PositionStatus | ポジションの現在の、または履歴上のステータス。 | ||
| 説明 この属性は、ある時点におけるポジションの状態を、「Proposed(提案済み)」、「Active(有効)」、「Frozen(凍結)」、「Closed(クローズ済み)」などで示します。ステータスの変更は、しばしばプロセス内の活動に対応します。 ステータス追跡は、ポジションの経路を理解し、「Position Compliance Review Status(ポジションコンプライアンスレビュー状況)」や「Stale and Underutilized Positions(停滞し、活用されていないポジション)」のようなダッシュボードにとって重要です。これは、ポジションの現在の状態のスナップショットを提供し、プロセスフローの検証に役立ちます。 その重要性 各役職の明確な状態を提供し、ケースのフィルタリングと結果の理解に不可欠です。 取得元 Microsoft Dynamics 365 Human Resourcesのドキュメントを参照してください。これは、コアとなる役職レコードのステータスフィールドから派生している可能性が高いです。 例 提案済み審査中アクティブ凍結クローズ | |||
| ユーザー名 UserName | `アクティビティ`を実行した`ユーザー`名または`ID`。 | ||
| 説明 この属性は、要求を承認したマネージャーやシステム内でポジションを作成した人事スペシャリストなど、特定のプロセスステップを担当する従業員またはシステムユーザーを識別します。 ユーザーごとに分析することで、トレーニングニーズを特定し、チームメンバー間のパフォーマンスを比較し、ワークロードの配分を理解するのに役立ちます。また、職務分掌の適切性を確保するためのコンプライアンスチェックにとっても重要です。 その重要性 説明責任を提供し、個人またはチームごとのパフォーマンス分析を可能にします。これはリソース管理とトレーニングにとって重要です。 取得元 Dynamics 365 HRのワークフロー履歴または監査証跡レコードに関連付けられています。HcmWorkerエンティティのユーザーIDを介してリンクされる場合があります。 例 John Smithジェーン・ドウSYSTEMHRAdmin01MGR-FINANCE | |||
| 役職 JobTitle | ポジションに関連付けられた職務タイトル(例:「シニア会計士」)。 | ||
| 説明 職務タイトルは、ポジションの役割と責任に関する重要なコンテキストを提供します。複数のポジションが同じ職務タイトルを共有できるため、ポジションIDとは異なります。 分析において、この属性は職務タイプによるグループ化とフィルタリングを可能にします。これは、「Position Reclassification Trends(ポジション再分類トレンド)」ダッシュボードで、どのタイプの職務が最も頻繁に再分類されているかを確認するのに役立ちます。 その重要性 重要なビジネスコンテキストを追加し、ジョブロール、レベル、または機能に基づいた分析を可能にします。 取得元 この情報は、ポジションに関連付けられた「職務」レコードからリンクされます。HcmPositionV2Entityのようなエンティティで検索するか、HcmJobEntityに結合して見つけてください。 例 `シニア``ファイナンシャルアナリスト``ソフトウェアエンジニア` II`HRビジネスパートナー`マーケティングコーディネーターロジスティクス マネージャー | |||
| 終了日時 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 | |||
| 部署 DepartmentName | ポジションが所属する部署。 | ||
| 説明 この属性は、「財務」、「マーケティング」、「IT」など、ポジションに関連付けられた組織部門を指定します。これは、プロセスデータをフィルタリングおよび集計するための主要なディメンションです。 部門ごとの分析は、「Departmental Position Throughput(部門別ポジションスループット)」ダッシュボードにとって不可欠です。これにより、プロセスパフォーマンスを比較し、部門固有のボトルネックを特定し、ビジネスの様々な部門における採用トレンドを理解するのに役立ちます。 その重要性 プロセス分析を事業単位でセグメント化することができ、部門固有の問題の特定やパフォーマンスの比較に役立ちます。 取得元 この情報はポジション詳細の一部であり、通常HcmPositionDetailエンティティに保存され、運用単位ディメンションにリンクされています。 例 財務情報技術`セールス`&`マーケティング`人事運用 | |||
| ジョブファミリー JobFamily | 「エンジニアリング」や「財務」など、類似した機能を持つジョブのグループ化です。 | ||
| 説明 ジョブファミリーは、関連する役職名をグループ化する分類です。例えば、「ソフトウェアエンジニア」と「QAエンジニア」はどちらも「エンジニアリング」ジョブファミリーに属する可能性があります。 この属性は、「役職再分類トレンド」ダッシュボードにとって不可欠です。これにより、どのジョブカテゴリが最も頻繁に変更されているかを高レベルで分析できます。個々の役職名を見るよりも広範な視点を提供します。 その重要性 役職のより広範なカテゴリベースの分析を可能にし、戦略的な人員計画やトレンド分析に役立ちます。 取得元 これはDynamics 365 HRの職務設定の一部です。HcmJobEntityで「職務ファミリー」または「職務機能」に関連するフィールドを探してください。 例 エンジニアリング財務・会計営業人事プロダクトマネジメント | |||
| ソースシステム 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 | |||
| 処理時間 ProcessingTime | アクティビティに実作業として費やした時間。 | ||
| 説明 処理時間とは、アクティビティの開始時間 (StartTime) と終了時間 (EndTime) の間に計算される期間です。待ち時間を除いた、タスクに実際に費やされた時間を表します。 このメトリックはパフォーマンス分析の基本であり、「Position Creation Bottleneck Monitor(ポジション作成ボトルネックモニター)」のようなダッシュボードで使用されます。すべてのアクティビティの処理時間を合計することで、ポジションのライフサイクルにおける総実作業時間 (タッチタイム) を把握でき、これは効率分析の重要な要素となります。 その重要性 アクティビティの実際の作業期間を測定し、ボトルネック分析において実際の作業時間とアイドル待機時間を区別するのに役立ちます。 取得元 これは 例 PT5M12SPT1H30MP2DT4H15MP0DPT8H | |||
| 却下理由 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のドキュメントを参照してください。この情報はワークフロー開始データに記録されている可能性があります。 例 ロバート・ジョーンズSusan MillerDavid ChenMaria GarciaPaul Williams | |||
採用から退職まで - 役職管理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| ポジションクローズ済み | ポジションレコードの最終アーカイブを表し、そのライフサイクルの絶対的な終わりを示します。このイベントは、「クローズ済み」または同様の最終状態へのステータス変更によって推測されます。 | ||
| その重要性 これはプロセスの終端イベントであり、完全なエンドツーエンドのライフサイクル分析を可能にし、クローズすべき停滞したポジションを特定するのに役立ちます。 取得元 役職レコードのステータスフィールドが「Closed」に変更されたことから推測されます。履歴のためにレコードが保持されることが多いため、無効化よりも一般的ではありません。 取得 ステータスフィールドが「Closed」に更新されたタイムスタンプから推測されます。 イベントタイプ inferred | |||
| ポジション有効化 | 役職が正式にオープンになり、採用を開始できる時点を示します。このイベントは、役職レコードのステータスフィールドが「Active」または同様の状態に変更されたことから推測されます。 | ||
| その重要性 これは、人員配置の準備状況と最終セットアップ段階の効率を測定するための重要なマイルストーンです。これは「Average Time to Position Activation(平均ポジション有効化までの時間)」KPIに不可欠です。 取得元 役職レコードの「PositionStatus」などのステータスフィールドが「Active」または「Open」に更新されたタイムスタンプを追跡することにより推測されます。 取得 役職の イベントタイプ inferred | |||
| ポジション申請開始 | 役職管理ライフサイクルの正式な開始を示します。このイベントは通常、ユーザーがDynamics 365 HRの専用フォームまたはワークフローを介して新しい役職リクエストを提出したときに取得されます。 | ||
| その重要性 これは、ポジション承認サイクルタイムやポジション作成リードタイムといった重要なKPIを含む、ポジションライフサイクル全体を測定するための出発点です。 取得元 役職リクエストレコードの作成タイムスタンプ、または 取得 新規役職リクエストワークフロー提出時にイベントが記録されます。 イベントタイプ explicit | |||
| ポジション非有効化 | ポジションはもはや有効ではなく、多くの場合、人員が充足された後に、有効な組織構造から削除されます。これは、「非有効」または同様の状態へのステータス変更から推測されます。 | ||
| その重要性 役職の活動期間の終わりにおける主要なステップを示します。「役職無効化までの平均時間」を分析し、正確な人員数を管理するために不可欠です。 取得元 「RetirementDate」フィールドが入力されたタイムスタンプ、または役職レコードのステータスフィールドが「Inactive」に変更されたタイムスタンプから推測されます。 取得 役職の イベントタイプ inferred | |||
| 人事システムでポジション作成済み | このイベントは、Dynamics 365 HR内でのポジションレコードの正式な作成を示します。これは、主要なポジションレコード自体の作成タイムスタンプから取得されます。 | ||
| その重要性 リクエストから実際の組織エンティティへの移行を示す基本的なマイルストーンです。これは「役職作成リードタイムKPI」の終点となります。 取得元 HcmPositionなどの主要な役職テーブルにある 取得 HcmPositionテーブルの イベントタイプ explicit | |||
| 人事部によるポジション申請承認済み | ポジションが正式に作成される前の、人事部からの最終承認を示します。これは、ワークフローシステムで人事承認タスクが完了した際に明示的にログに記録されるイベントです。 | ||
| その重要性 これは承認フェーズの終了を示し、全体の平均ポジション承認サイクルタイムを測定するための重要なマイルストーンです。 取得元 人事担当者が承認タスクを完了した際に、 取得 HR承認ステップ完了時に、タイムスタンプとともにワークフロー履歴にイベントが記録されます。 イベントタイプ explicit | |||
| コンプライアンスレビュー済みポジション | 役職が正式なコンプライアンスチェックを受けたことを示します。これは、ステータスの変更、完了したチェックリストタスク、またはカスタムフィールドの更新によって取得できます。 | ||
| その重要性 規制および社内ポリシーへの準拠状況を監視するために重要です。このアクティビティは、「役職コンプライアンス遵守率KPI」を直接サポートします。 取得元 役職レコードの「ComplianceReviewStatus」のようなタイムスタンプ付きステータスフィールド、またはブーリアン型の「IsComplianceReviewed」フィールドから推測される可能性が高いです。 取得 コンプライアンスステータスフィールドが「Completed」または「Reviewed」に更新されたタイムスタンプから推測されます。 イベントタイプ inferred | |||
| ポジション予算承認済み | 新規役職に必要な資金が割り当てられたことを確認する重要な承認マイルストーンです。これは通常、役職作成ワークフロー内の明確な承認ステップとして取得されます。 | ||
| その重要性 財務承認段階を分離し、予算配分に関連する遅延の分析を可能にし、「役職予算承認サイクルタイムKPI」をサポートします。 取得元 WorkflowTrackingTableなどのワークフロー履歴テーブルに、完了した承認タスクとして記録されます。このタスクはしばしば財務担当者に割り当てられます。 取得 ワークフローログ内の予算承認タスク完了時のタイムスタンプから取得されます。 イベントタイプ explicit | |||
| ポジション再分類済み | 役職のジョブファミリーやレベルといった基本的な分類が変更される重要な更新です。これは通常、役職レコードの「ジョブ」フィールドの変更から推測されます。 | ||
| その重要性 組織構造の変更やジョブ定義の安定性を分析するのに役立ちます。「役職再分類率KPI」の主要なアクティビティです。 取得元 HcmPositionテーブルの「JobId」フィールドの変更から推測されます。これはデータベースログを介して取得されるか、時間の経過とともにレコードバージョンを比較することで特定されます。 取得 役職レコードのジョブ分類フィールドへの記録された変更から推測されます。 イベントタイプ inferred | |||
| ポジション凍結済み | 役職が一時的に保留され、採用活動が停止されていることを示します。これは、役職レコードのステータスが「凍結済み」または「保留中」状態に変更されたことを推測することで取得されます。 | ||
| その重要性 ポジションライフサイクルにおける中断を追跡し、人員計画や予算に影響を与える可能性があります。これにより、採用の遅延理由を特定するのに役立ちます。 取得元 役職レコードのステータスフィールドが「Frozen」または類似の値に更新されたタイムスタンプを追跡することにより推測されます。 取得 ステータスが「Frozen」または「On Hold」に変更されたタイムスタンプから推測されます。 イベントタイプ inferred | |||
| ポジション属性変更済み | ポジションの初回作成後に、職位や部署など、主要な属性に加えられた変更を表します。この活動は通常、システムのデータベースログの変更を追跡することで推測されます。 | ||
| その重要性 このアクティビティの頻度が高い場合、データ品質の低さやプロセスにおける手戻りを示唆する可能性があります。「役職属性変更頻度KPI」と「手戻り率KPI」に不可欠です。 取得元 役職テーブルで変更追跡が有効な場合、SysDatabaseLogテーブルから推測されます。あるいは、役職データの履歴スナップショットを比較する必要があります。 取得 データベースログを介してHcmPositionテーブルのキーフィールドに対する更新操作を検出することにより推測されます。 イベントタイプ inferred | |||
| ポジション申請却下済み | 役職リクエストがいずれかの承認段階で却下されたことを示します。このイベントは、承認者が「却下」アクションを選択したときにワークフロー履歴に明示的に記録されます。 | ||
| その重要性 プロセス障害と手戻りループを浮き彫りにします。却下理由を分析することで、初期リクエストの品質向上を支援し、「役職リクエスト却下率KPI」をサポートします。 取得元 特定のポジション申請について、WorkflowTrackingStatusTableなどのワークフロー履歴テーブルに「却下」ステータスとして記録されます。 取得 承認者が却下アクションを実行した際に、ワークフローログから取得されます。 イベントタイプ explicit | |||
| マネージャーによるポジション申請承認済み | 採用マネージャーによる一次承認の完了を表します。このイベントは、マネージャーが割り当てられた承認タスクを完了した際に、ワークフロー履歴に明示的に記録されます。 | ||
| その重要性 初期承認ステップにかかる時間を特定し、特定の管理者や部署におけるボトルネックの特定に役立ちます。 取得元 役職リクエストに関連付けられたワークフロー履歴テーブル(例: 取得 ワークフローログ内のマネージャー承認ステップ完了時のタイムスタンプから取得されます。 イベントタイプ explicit | |||
| 採用プロセス開始済み | ポジション管理から採用活動への引継ぎを示します。このイベントは、新しい欠員または採用プロジェクトが作成され、この特定のポジションIDにリンクされたときに推測されます。 | ||
| その重要性 役職管理プロセスとその結果を結びつけ、役職の有効化から実際の採用活動開始までの時間を分析できるようにします。 取得元 役職IDを参照する採用または空席テーブル(例:HcmRecruitingRequest)内のレコードの作成日を特定することにより推測されます。 取得
イベントタイプ inferred | |||
抽出ガイド
ステップ
- データ管理ワークスペースへの移動: Microsoft Dynamics 365 Human Resourcesにログインします。メインの検索バーを使用して、「データ管理」ワークスペースに移動します。
- 新規エクスポートプロジェクトの作成: ワークスペース内で、「エクスポート」タイルを選択します。「エクスポート」プロジェクトページで、「新規」をクリックして新しいプロジェクトを作成します。「PositionManagement_EventLog_Export」のような説明的な名前を付け、データ形式を選択します。変換目的には「CSV」が推奨されます。
- プロジェクトへのデータエンティティの追加: 新しいプロジェクトで、「エンティティの追加」をクリックします。役職の完全なライフサイクルをキャプチャするために、いくつかのエンティティを追加する必要があります。以下の主要エンティティを一つずつ追加します:「HcmPositionV2」、「WorkflowTrackingStatusTable」、「HcmRecruitingRequest」。役職変更のデータベースロギングが有効になっている場合は、「SysDatabaseLog」も追加します。
- エンティティフィルターの設定: 各エンティティについて、データスコープを制限するためにフィルターを適用することが不可欠です。エンティティを選択し、「フィルター」をクリックします。「HcmPositionV2」の場合、「CreatedDateTime」または「ModifiedDateTime」フィールドを使用して特定の日付範囲でフィルターします。「WorkflowTrackingStatusTable」の場合、「CONTEXTTABLENAME」を役職関連のワークフローのみを含むようにフィルターします。
- 各エンティティのフィールド選択: 後で変換するために必要なすべてのフィールドがエクスポートされることを確認します。「HcmPositionV2」の場合、「PositionId」、「CreatedDateTime」、「ActivationDate」、「RetirementDate」、「ModifiedDateTime」、「JobId」、「DepartmentNumber」を含めます。「WorkflowTrackingStatusTable」の場合、「ContextRecId」、「WorkflowTrackingStatus」、「CreatedDateTime」、「UserId」を含めます。
- エクスポートジョブの実行: すべてのエンティティ、フィールド、フィルターが設定されたら、メインのプロジェクトページで「エクスポート」をクリックします。システムは各エンティティの個別のファイルを含むデータパッケージを作成します。
- データパッケージの監視とダウンロード: 「ジョブ履歴」セクションでジョブの進捗状況を監視できます。ジョブが正常に完了したら、データパッケージ(圧縮ファイル)をダウンロードします。
- データの抽出と変換: ダウンロードしたパッケージを解凍します。各エンティティの個別のCSVファイルが見つかります。これらのファイルは生データであり、最終的なイベントログではありません。これらのファイルを処理するには、外部スクリプト(例:Python(pandas使用)やPowerShell)を使用する必要があります。
- 変換ロジックの実装: スクリプトは以下の操作を実行する必要があります。
- 「HcmPositionV2.csv」ファイルをロードします。このファイルから、「PositionId」と「CreatedDateTime」を使用して「HRシステムで役職作成済み」イベントを生成します。
- 「HcmPositionV2.csv」のステータスフィールドや「ActivationDate」および「RetirementDate」のような日付フィールドを解釈して、ステータス変更イベント(「役職有効化済み」、「役職凍結済み」、「役職無効化済み」、「役職クローズ済み」)を生成します。
- 「WorkflowTrackingStatusTable.csv」ファイルをロードします。このデータをレコードIDを使用して役職データと結合します。このデータから、ワークフローイベント(「役職リクエスト開始済み」、「マネージャーにより役職リクエスト承認済み」、「役職予算承認済み」、「HRにより役職リクエスト承認済み」、「役職リクエスト却下済み」)を生成します。ワークフローステータスとステップコンテキストを正しいアクティビティ名にマッピングする必要があります。
- 「SysDatabaseLog.csv」をエクスポートしている場合、このファイルを解析して、HcmPositionテーブルの特定のフィールドの変更に基づいて「役職属性変更済み」および「役職再分類済み」イベントを生成します。
- 「HcmRecruitingRequest.csv」をロードして、特定の役職に対して採用リクエストがいつ作成されたかを特定することで、「採用プロセス開始済み」イベントを生成します。
- 最終イベントログの組み立て: スクリプトは、異なるソースから生成されたすべてのイベントを単一のCSVファイルに結合する必要があります。このファイルには、必要な列(「PositionId」、「ActivityName」、「EventTime」)と、マッピングできた推奨属性が含まれている必要があります。
- アップロードのための形式設定: 最終的なCSVファイルのヘッダーが必須属性名と正確に一致し、「EventTime」列が一貫したタイムスタンプ形式であることを確認します。これで、ファイルはプロセスマイニングツールにアップロードする準備が整いました。
設定
- 主要データエンティティ: この抽出に必要となる主要エンティティは以下のとおりです。
HcmPositionV2: 各役職の核となる詳細情報(作成日、有効化日、ジョブや部署などの属性を含む)が含まれます。WorkflowTrackingStatusTable: 提出、承認、却下を含むワークフローインスタンスの履歴を提供します。これは承認プロセスを追跡するために不可欠です。HcmRecruitingRequest: 採用リクエストが役職にリンクされた場合に、「採用プロセス開始済み」アクティビティを推測するために使用されます。SysDatabaseLog: 「役職属性変更済み」や「役職再分類済み」のような詳細な変更をキャプチャするためのオプションですが強力なエンティティです。その使用は、HcmPositionテーブルに対してデータベースロギングが事前に設定されているかどうかに依存します。
- 日付範囲フィルター: 「HcmPositionV2」エンティティに対し、「CreatedDateTime」フィールドに基づいて日付範囲フィルターを適用することを強く推奨します。管理しやすいデータ量を確保するためには、6〜12ヶ月の範囲が良い出発点となることがよくあります。
- 増分エクスポート: 継続的な分析のためには、増分エクスポートのためにエクスポートプロジェクトを設定することを検討してください。これにより、前回の実行以降に変更されたレコードのみが抽出され、処理時間が大幅に短縮されます。
- 前提条件: エクスポートを実行するユーザーは、「データ管理」ワークスペースへのアクセス権限と、指定されたすべてのデータエンティティへの読み取りアクセス権限を持つ十分なセキュリティロールが必要です。「データ管理管理者」のようなロール、または特定のエンティティ特権を持つカスタムロールが通常必要とされます。
a クエリ例 config
/*
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クライアントで新しいクエリウィンドウを開き、このドキュメントの「クエリ」セクションに記載されている完全なSQLスクリプトを貼り付けます。
- パラメーターのカスタマイズ: クエリ内のプレースホルダー変数を変更します。分析したい特定の法人(例:「USMF」)に
@[YourCompanyId]を設定します。WHERE句の日付範囲(例:CREATEDDATETIME >= '2023-01-01')を調整して、抽出を希望の期間に限定します。 - クエリの実行: BYODデータベースに対して完全なSQLクエリを実行します。実行時間は、データ量と選択された日付範囲によって異なります。
- 結果の確認: クエリが完了した後、SQLクライアントの結果ペインで出力を確認します。
PositionId、ActivityName、EventTimeなどの列が期待どおりに表示されていることを確認します。 - CSVへのエクスポート: 結果セット全体をCSVファイルにエクスポートします。ほとんどのSQLクライアントには、結果を直接CSVファイルに保存する組み込み機能があります。例えば、SSMSでは、結果グリッドを右クリックして「名前を付けて結果を保存…」を選択できます。
- アップロードの準備: エクスポートされた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クライアントツールが必要です。
- カスタムワークフロー手順: このクエリは、「役職リクエストの承認」のような一般的な承認のワークフローのステップ名を使用しています。貴社がこれらのワークフロー手順にカスタム名を使用している場合は、対応する
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]'