Votre modèle de données Hire to Retire - Gestion des Postes
Votre modèle de données Hire to Retire - Gestion des Postes
- `Attributs` recommandés à collecter pour une analyse approfondie
- Activités clés à suivre pour une découverte précise des processus
- Guide d'extraction spécifiquement pour Microsoft Dynamics 365 Human Resources
Attributs de gestion des postes de l'embauche au départ
| Nom | Description | ||
|---|---|---|---|
| Heure de l'événement EventTime | Le `timestamp` indiquant quand l'activité a eu lieu. | ||
| Description L'Heure de l'événement, ou timestamp, enregistre la date et l'heure exactes de l'achèvement d'une activité. Il est essentiel pour ordonner les événements chronologiquement et pour calculer les durées et les temps de cycle. Cet attribut est utilisé dans presque toutes les analyses de Process Mining, de la construction de la carte des processus au calcul des KPI de performance comme le 'Temps de cycle moyen d'approbation des postes'. Il aide à identifier quand les retards se produisent et combien de temps chaque étape du processus prend. Pourquoi c'est important Ce timestamp est essentiel pour ordonner les événements, calculer toutes les métriques basées sur le temps et découvrir les goulots d'étranglement du processus. Où obtenir Cette information se trouve généralement dans les tables de journal système ou comme champs 'CreatedDateTime' ou 'ModifiedDateTime' associés aux enregistrements de poste et de workflow dans Dynamics 365 HR. Exemples 2023-04-15T09:00:00Z2023-04-15T14:35:10Z2023-04-18T11:21:05Z2023-05-02T16:45:00Z2024-01-10T10:00:00Z | |||
| ID de poste PositionId | L'identifiant unique pour un poste spécifique au sein de l'organisation. | ||
| Description L'ID de poste sert d'identifiant de cas principal, reliant toutes les activités et données liées à un seul poste organisationnel. Cela permet un suivi de bout en bout du cycle de vie complet d'un poste, de sa création et de ses modifications à sa désactivation ou clôture éventuelle. En analyse de processus, cet ID est essentiel pour reconstituer le parcours de chaque poste. Il permet des dashboards qui surveillent les temps de cycle, identifient les goulots d'étranglement dans les approbations et analysent les variantes de processus de la demande à la clôture. Pourquoi c'est important C'est l'identifiant central qui relie tous les événements connexes en un seul cas de processus, rendant possible l'analyse de bout en bout du cycle de vie du poste. Où obtenir C'est généralement le champ HcmPosition.PositionId dans Microsoft Dynamics 365 Human Resources. Il peut être trouvé dans des entités de données comme HcmPositionV2Entity. Exemples POS001234MKT-0056FIN-SR-ANALYST-02HRBP-EAST-01IT-DEV-9876 | |||
| Nom de l'activité ActivityName | Le nom de l'événement ou de la tâche spécifique qui s'est produit dans le processus de gestion des postes. | ||
| Description Cet attribut décrit une seule étape du cycle de vie du poste, tel que 'Demande de poste initiée', 'Poste créé dans le système RH' ou 'Poste désactivé'. Il constitue l'épine dorsale de la carte de processus, montrant la séquence des événements. L'analyse du Nom de l'Activité permet la visualisation des flux de processus, l'identification des déviations par rapport au processus standard et le calcul des temps de transition entre les différentes étapes. Il est fondamental pour comprendre ce qui s'est passé et dans quel ordre. Pourquoi c'est important Il définit les étapes du processus, permettant la visualisation des cartes de processus et l'analyse du flux et des variations du processus. Où obtenir Cet attribut est dérivé des événements métier, des changements de statut ou de l'historique du workflow au sein de Microsoft Dynamics 365 Human Resources. Ce n'est pas un champ unique, mais il est construit en fonction du contexte des données. Exemples Demande de poste initiéeDemande de poste approuvée par le managerPoste créé dans le système RHAttributs du poste modifiésPoste Fermé | |||
| Centre de coûts CostCenter | Le centre de coûts financier auquel les dépenses du poste sont allouées. | ||
| Description Le Centre de Coût est une dimension financière clé qui lie un poste à un budget spécifique ou à un domaine de responsabilité financière. Les changements apportés à cet attribut sont importants à surveiller. Cet attribut est essentiel pour le dashboard 'Vérification de la cohérence des données de poste', qui analyse les changements apportés aux attributs clés après la création. Il est également utilisé pour analyser les coûts et les budgets liés aux postes par différentes unités financières. Pourquoi c'est important Il connecte le poste aux données financières, permettant l'analyse des processus liés aux coûts et le suivi de la cohérence des données. Où obtenir Ceci est généralement configuré comme une dimension financière sur l'enregistrement du poste. Consultez la configuration de la dimension financière dans Dynamics 365. Exemples CC-1001-FINCC-2500-ITCC-4510-SALESCC-7000-OPSCC-9002-HR | |||
| Département DepartmentName | Le département auquel le poste appartient. | ||
| Description Cet attribut spécifie le département organisationnel, tel que 'Finance', 'Marketing' ou 'IT', associé au poste. C'est une dimension primaire pour le filtrage et l'agrégation des données de processus. L'analyse par département est essentielle pour le dashboard 'Débit des postes par département'. Elle aide à comparer les performances des processus, à identifier les goulots d'étranglement spécifiques aux départements et à comprendre les tendances de recrutement dans différentes parties de l'entreprise. Pourquoi c'est important Il permet de segmenter l'analyse des processus par unité commerciale, aidant à identifier les problèmes spécifiques aux départements et à comparer les performances. Où obtenir Cette information fait partie des détails du poste, généralement stockée sur l'entité HcmPositionDetail et liée à la dimension de l'unité opérationnelle. Exemples FinanceTechnologies de l'InformationVentes et MarketingRessources HumainesOpérations | |||
| Heure de fin EndTime | Le `timestamp` indiquant la date et l'heure à laquelle l'`activité` a été achevée. | ||
| Description EndTime marque la conclusion d'une activité. Le temps écoulé entre StartTime et EndTime est le temps de traitement de cette activité spécifique. Cet attribut est essentiel pour calculer les durées au niveau des activités et comprendre où le temps est passé dans le processus. Par exemple, il aide à déterminer combien de temps un manager prend pour approuver une demande de poste après qu'elle lui a été assignée. Pourquoi c'est important Il permet le calcul des temps de traitement des activités, ce qui est fondamental pour une analyse détaillée des performances et des goulots d'étranglement. Où obtenir Cela peut être dérivé des timestamps d'événements subséquents ou de champs 'achèvement' spécifiques dans les journaux de workflow au sein de Dynamics 365 HR. Souvent, cela doit être déduit. Exemples 2023-04-15T09:05:12Z2023-04-15T15:00:00Z2023-04-19T09:00:00Z2023-05-03T10:00:00Z2024-01-10T10:05:00Z | |||
| Nom d'utilisateur UserName | Le nom ou l'`ID` de l'`utilisateur` qui a effectué l'`activité`. | ||
| Description Cet attribut identifie l'employé ou l'utilisateur du système responsable d'une étape de processus donnée, comme le manager qui a approuvé une demande ou le spécialiste RH qui a créé le poste dans le système. L'analyse par utilisateur aide à identifier les besoins en formation, à comparer les performances entre les membres de l'équipe et à comprendre la répartition de la charge de travail. Elle est également essentielle pour les contrôles de conformité afin d'assurer une bonne séparation des tâches. Pourquoi c'est important Il offre une responsabilisation et permet une analyse des performances par individu ou par équipe, ce qui est crucial pour la gestion des ressources et la formation. Où obtenir Associé à l'historique des workflows ou aux enregistrements de piste d'audit dans Dynamics 365 HR. Il peut être lié via un ID utilisateur de l'entité HcmWorker. Exemples John SmithJane DoeSYSTEMHRAdmin01MGR-FINANCE | |||
| Statut du poste PositionStatus | Le statut actuel ou historique du poste. | ||
| Description Cet attribut indique l'état du poste à un moment donné, tel que 'Proposé', 'Actif', 'Gelé' ou 'Fermé'. Les changements de statut correspondent souvent à des activités dans le processus. Le suivi du statut est crucial pour comprendre le parcours du poste et pour des dashboards tels que 'Statut de révision de la conformité des postes' et 'Postes obsolètes et sous-utilisés'. Il fournit un aperçu de l'état actuel du poste et aide à valider le flux de processus. Pourquoi c'est important Il fournit un état clair pour chaque poste, ce qui est essentiel pour filtrer les cas et comprendre les résultats. Où obtenir Consultez la documentation de Microsoft Dynamics 365 Human Resources. Ceci est probablement dérivé des champs de statut de l'enregistrement de poste principal. Exemples ProposéEn cours de révisionActifGeléClôturé | |||
| Titre du poste JobTitle | Le titre de l'emploi associé au poste, tel que 'Comptable Senior'. | ||
| Description Le Titre de Poste fournit un contexte important concernant le rôle et les responsabilités du poste. Il est différent de l'ID du poste, car plusieurs postes peuvent partager le même titre d'emploi. En analyse, cet attribut permet de regrouper et de filtrer par type de rôle. Il est utile pour le dashboard 'Tendances de reclassification des postes' pour voir quels types d'emplois sont reclassifiés le plus souvent. Pourquoi c'est important Il ajoute un contexte métier crucial, permettant une analyse basée sur le rôle, le niveau ou la fonction de l'emploi. Où obtenir Cette information est liée à l'enregistrement 'Job' associé au poste. Recherchez-la dans des entités comme HcmPositionV2Entity ou en la joignant à HcmJobEntity. Exemples Analyste financier seniorIngénieur logiciel IIPartenaire d'affaires RHCoordinateur marketing.Responsable logistique | |||
| Dernière mise à jour des données LastDataUpdate | L'horodatage de la dernière actualisation des données depuis le système source. | ||
| Description Cet attribut indique la dernière extraction des données de Microsoft Dynamics 365 Human Resources. Il fournit un contexte pour la fraîcheur de l'analyse. L'affichage de cette information dans les dashboards assure aux utilisateurs qu'ils consultent des informations à jour. Il s'agit d'une pièce maîtresse de métadonnées pour tout projet de Process Mining. Pourquoi c'est important Il informe les utilisateurs sur l'actualité des données, ce qui est crucial pour prendre des décisions basées sur l'analyse. Où obtenir Ce timestamp est généré et stocké pendant le processus d'extraction, de transformation et de chargement (ETL) des données. Exemples 2024-05-21T02:00:00Z2024-05-20T02:00:00Z2024-05-19T02:00:00Z | |||
| Durée du cycle d'approbation ApprovalCycleTime | Le temps total entre l'initiation d'une demande de poste et son approbation finale. | ||
| Description Cette métrique calculée mesure la durée entre l'activité 'Demande de poste initiée' et l'activité d'approbation finale, qui pourrait être 'Demande de poste approuvée par les RH'. C'est un indicateur clé de performance pour la phase initiale du processus de gestion des postes. Cet attribut alimente directement le dashboard et le KPI 'Temps de cycle d'approbation des postes'. Il fournit une mesure de haut niveau de l'efficacité du processus d'approbation et aide à suivre l'impact des initiatives d'amélioration au fil du temps. Pourquoi c'est important C'est un KPI critique qui mesure l'efficacité de l'ensemble du processus d'approbation, mettant directement en évidence les retards dans la préparation des postes pour la création. Où obtenir Ceci est calculé au niveau du cas en trouvant les timestamps pour les activités de début et de fin de la phase d'approbation et en calculant la différence. Exemples P3DT2H15MP10DP1DT12HP5DT6HP2W | |||
| Emplacement Location | L'emplacement physique ou géographique du poste. | ||
| Description Cet attribut spécifie l'emplacement du poste, qui pourrait être un bureau, une ville ou un pays. C'est une autre dimension importante pour filtrer et segmenter les données de processus. L'emplacement est utilisé directement dans le dashboard 'Débit des postes par département' pour analyser les tendances d'effectifs et les performances des processus dans différentes régions. Il peut aider à identifier si les processus de création ou d'approbation de postes sont plus lents dans certaines localisations. Pourquoi c'est important Il fournit un contexte géographique, permettant l'analyse des performances et des tendances des processus à travers différentes localisations. Où obtenir Consultez la documentation de Microsoft Dynamics 365 Human Resources. Cela peut faire partie des détails du poste ou être lié via le département ou l'entité juridique. Exemples New York, USALondres, Royaume-UniBerlin, AllemagneSingapourÀ distance | |||
| Est un retravail IsRework | Un indicateur signalant si une activité fait partie d'une boucle de retravail. | ||
| Description Ce flag booléen est défini à vrai si une activité représente une étape qui est répétée dans le processus, comme une nouvelle approbation après la modification d'attributs. Il aide à quantifier les boucles de processus inefficaces. Cet attribut supporte directement le dashboard 'Analyse des retouches de postes' et le KPI 'Taux de retouche sur la création de postes'. En signalant les retouches, les analystes peuvent facilement filtrer et mesurer la fréquence et l'impact des inefficacités du processus. Pourquoi c'est important Il identifie et quantifie explicitement le retravail de processus, qui est une cible principale pour les initiatives d'amélioration des processus. Où obtenir Ceci est calculé en fonction de la séquence des activités pour un cas. Par exemple, si 'Demande de poste approuvée par le manager' se produit après 'Attributs du poste modifiés', cela peut être signalé comme une retouche. Exemples truefaux | |||
| Famille d'emplois JobFamily | Un regroupement d'emplois aux fonctions similaires, tels que 'Ingénierie' ou 'Finance'. | ||
| Description La famille d'emplois est une classification qui regroupe des titres d'emploi liés. Par exemple, 'Ingénieur logiciel' et 'Ingénieur QA' pourraient tous deux relever de la famille d'emplois 'Ingénierie'. Cet attribut est essentiel pour le tableau de bord 'Tendances de reclassification des postes', car il permet une analyse de plus haut niveau des catégories d'emplois qui changent le plus fréquemment. Il offre une vue plus large que la simple observation des titres d'emploi individuels. Pourquoi c'est important Il permet une analyse plus large, basée sur des catégories de postes, ce qui est utile pour la planification stratégique des effectifs et l'analyse des tendances. Où obtenir Cela fait partie de la configuration de l'emploi dans Dynamics 365 HR. Recherchez les champs liés à la 'famille de postes' ou à la 'fonction de poste' sur l'entité HcmJobEntity. Exemples IngénierieFinance et ComptabilitéVentesRessources HumainesGestion de produit | |||
| Le budget est-il approuvé IsBudgetApproved | Un indicateur signalant si le budget du poste a été approuvé. | ||
| Description Cet attribut booléen est vrai si l'activité 'Budget du poste approuvé' a eu lieu pour un cas de poste donné. Il aide à analyser le flux de processus et à identifier les postes en attente de budget. Cet attribut peut être utilisé pour filtrer les processus et analyser plus efficacement le KPI 'Temps de cycle d'approbation du budget du poste'. Il aide à différencier les postes qui ont franchi l'étape du budget de ceux qui ne l'ont pas fait, ce qui est utile pour l'analyse des goulots d'étranglement. Pourquoi c'est important Il simplifie l'analyse en fournissant un indicateur clair pour un jalon critique, aidant à isoler et à mesurer l'étape d'approbation budgétaire. Où obtenir Ceci est dérivé pendant la transformation des données en vérifiant l'existence de l'activité 'Budget du poste approuvé' dans l'historique du cas. Exemples truefaux | |||
| Manager demandeur RequestingManager | Le manager qui a initié la demande de poste. | ||
| Description Cet attribut identifie le responsable du recrutement ou le chef de département qui a lancé le processus en demandant un nouveau poste ou un poste de remplacement. Cette information fournit un contexte sur l'origine de la demande de postes. L'analyse par "Manager demandeur" peut aider à identifier les tendances dans le volume des demandes, les taux d'approbation et la qualité des demandes. Elle fournit une couche de détail supplémentaire pour comprendre la charge de travail et le respect des processus. Pourquoi c'est important Il aide à retracer l'origine de la demande de poste et à analyser les métriques de processus du point de vue du responsable du recrutement. Où obtenir Consultez la documentation de Microsoft Dynamics 365 Human Resources. Cette information serait probablement capturée dans les données d'initiation du workflow. Exemples Robert JonesSusan MillerDavid ChenMaria GarciaPaul Williams | |||
| Motif de refus RejectionReason | La raison fournie lorsqu'une demande de poste est rejetée. | ||
| Description Lorsqu'une demande de poste est rejetée par un manager ou les RH, une raison est souvent enregistrée. Cela peut être dû à des contraintes budgétaires, des informations incorrectes ou un changement de stratégie. Cet attribut est essentiel pour calculer le KPI 'Taux de rejet des demandes de postes' et comprendre pourquoi les retouches se produisent. L'analyse des raisons de rejet les plus courantes aide à identifier les problèmes en amont, tels qu'une faible qualité des demandes ou des directives peu claires, qui peuvent être abordés pour améliorer le processus. Pourquoi c'est important Il fournit un aperçu direct des raisons pour lesquelles les demandes échouent, permettant des améliorations ciblées des processus pour réduire le retravail et les taux de rejet. Où obtenir Consultez la documentation de Microsoft Dynamics 365 Human Resources. Ceci est souvent capturé dans les commentaires du workflow ou un champ de code de motif dédié lors du rejet. Exemples Budget non disponibleDemande en doubleProfil de poste incorrectGel des embauchesRéalignement stratégique | |||
| Système source SourceSystem | Le système d'où les données ont été extraites. | ||
| Description Cet attribut identifie l'origine des données du processus. Pour cette vue, il s'agirait typiquement de 'Microsoft Dynamics 365 Human Resources'. Dans les environnements multi-systèmes, ce champ est crucial pour la lignée des données et le dépannage. Il aide à confirmer que les données proviennent de la source attendue et peut être utilisé pour filtrer les analyses pour des systèmes spécifiques. Pourquoi c'est important Il fournit un contexte sur l'origine des données, ce qui est important pour la gouvernance des données et pour les analyses couvrant plusieurs systèmes d'entreprise. Où obtenir C'est une valeur statique ajoutée pendant le processus d'extraction et de transformation des données pour étiqueter l'origine de l'ensemble de données. Exemples Microsoft Dynamics 365 Human ResourcesD365 HRDynamicsHR | |||
| Temps de traitement ProcessingTime | Le temps passé à travailler activement sur une activité. | ||
| Description Le Temps de Traitement est la durée calculée entre l'heure de début (StartTime) et l'heure de fin (EndTime) d'une activité. Il représente le temps réel passé sur une tâche, à l'exclusion du temps d'attente. Cette métrique est fondamentale pour l'analyse des performances et est utilisée dans des dashboards comme le 'Moniteur des goulots d'étranglement de la création de postes'. En additionnant les temps de traitement de toutes les activités, on peut comprendre le temps de contact total pour le cycle de vie d'un poste, ce qui est un élément clé de l'analyse d'efficacité. Pourquoi c'est important Il mesure la durée réelle du travail des activités, aidant à distinguer le temps de travail actif du temps d'attente inactif dans l'analyse des goulots d'étranglement. Où obtenir Il est calculé lors de la Exemples PT5M12SPT1H30MP2DT4H15MP0DPT8H | |||
| Type de poste PositionType | Classe le poste comme à temps plein, à temps partiel, temporaire, etc. | ||
| Description Cet attribut catégorise le poste en fonction de ses conditions d'emploi. Cela fournit un contexte supplémentaire pour l'analyse et la planification des effectifs. Dans l'analyse de processus, le filtrage par type de poste peut révéler si certains types de postes ont des chemins de processus différents ou des temps de cycle plus longs. Par exemple, les postes temporaires pourraient avoir un processus d'approbation plus rapide et rationalisé par rapport aux postes permanents à temps plein. Pourquoi c'est important Il permet d'analyser comment le processus diffère pour divers types d'emploi, aidant à la planification des effectifs et à l'optimisation des processus. Où obtenir Cette information est généralement disponible sur l'enregistrement du poste dans Dynamics 365 HR. Vérifiez des entités comme HcmPositionV2Entity pour un champ pertinent. Exemples Temps pleinTemps partielContractuelStagiaireTemporaire | |||
Activités de gestion des postes de l'embauche au départ
| Activité | Description | ||
|---|---|---|---|
| Demande de poste approuvée par les RH | Signifie l'approbation finale du département des Ressources Humaines avant que le poste ne puisse être formellement créé. Il s'agit d'un événement explicite enregistré à la fin de la tâche d'approbation RH dans le système de workflow. | ||
| Pourquoi c'est important Ceci marque la fin de la phase d'approbation et est une étape critique pour mesurer le temps de cycle d'approbation moyen global des postes. Où obtenir Enregistré dans les tables d'historique du workflow, telles que WorkflowTrackingTable, lorsque le représentant des RH termine sa tâche d'approbation. Capture L'événement est enregistré dans l'historique du workflow avec un horodatage à l'achèvement de l'étape d'approbation RH. Type d'événement explicit | |||
| Demande de poste initiée | Marque le début formel du cycle de vie de la gestion des postes. Cet événement est généralement capturé lorsqu'un utilisateur soumet une nouvelle demande de poste via un formulaire dédié ou un workflow dans Dynamics 365 HR. | ||
| Pourquoi c'est important C'est le point de départ pour mesurer l'ensemble du cycle de vie du poste, y compris des KPI cruciaux comme le Temps de cycle d'approbation des postes et le Délai de création des postes. Où obtenir Capturé à partir de l'horodatage de création d'un enregistrement de demande de poste ou de l'enregistrement d'initiation dans la table d'historique du workflow, telle que WorkflowTrackingStatusTable. Capture L'événement est enregistré lors de la soumission d'un nouveau workflow de demande de poste. Type d'événement explicit | |||
| Poste Activé | Marque le moment où un poste devient officiellement ouvert et où le recrutement peut commencer. Cet événement est déduit d'un champ de statut sur l'enregistrement du poste passant à 'Actif' ou un état similaire. | ||
| Pourquoi c'est important C'est une étape critique pour mesurer la préparation du personnel et l'efficacité des étapes de configuration finales. Il est essentiel pour le KPI 'Temps moyen d'activation d'un poste'. Où obtenir Déduit en suivant l'horodatage lorsque le champ de statut, tel que 'PositionStatus', de l'enregistrement de poste est mis à jour à 'Actif' ou 'Ouvert'. Capture Basé sur la date à laquelle le champ ActivationDate du poste est rempli ou un champ de statut passe à 'Actif'. Type d'événement inferred | |||
| Poste créé dans le système RH | Cet événement marque la création officielle de l'enregistrement du poste au sein de Dynamics 365 HR. Il est capturé à partir du timestamp de création de l'enregistrement de poste primaire lui-même. | ||
| Pourquoi c'est important Un jalon fondamental qui marque la transition d'une demande à une entité organisationnelle réelle. C'est le point final pour le KPI de délai de création de poste. Où obtenir Du champ système 'CreatedDateTime' de la table principale des postes, telle que HcmPosition. Capture Extrait du champ système CreatedDateTime de la table HcmPosition. Type d'événement explicit | |||
| Poste Désactivé | Le poste n'est plus actif et est retiré de la structure organisationnelle active, souvent après avoir été pourvu. Cela est déduit d'un changement de statut en 'Inactif' ou un état similaire. | ||
| Pourquoi c'est important Marque une étape clé à la fin de la vie active du poste. C'est crucial pour analyser le temps moyen de désactivation du poste et gérer les effectifs avec précision. Où obtenir Déduit de l'horodatage lorsque le champ 'RetirementDate' est rempli ou qu'un champ de statut sur l'enregistrement de poste passe à 'Inactif'. Capture Basé sur la date à laquelle le champ RetirementDate du poste est défini ou un champ de statut passe à 'Inactif'. Type d'événement inferred | |||
| Poste Fermé | Représente l'archivage final de l'enregistrement du poste, signifiant la fin absolue de son cycle de vie. Cet événement est déduit d'un changement de statut en 'Fermé' ou un état terminal similaire. | ||
| Pourquoi c'est important C'est l'événement terminal du processus, permettant une analyse complète du cycle de vie de bout en bout et aidant à identifier les postes obsolètes qui devraient être fermés. Où obtenir Déduit d'un changement dans un champ de statut à 'Fermé' sur l'enregistrement de poste. Ceci est moins courant que la désactivation, car les enregistrements sont souvent conservés pour l'historique. Capture Déduit de l'horodatage lorsqu'un champ de statut est mis à jour à 'Fermé'. Type d'événement inferred | |||
| Attributs du poste modifiés | Représente toute modification apportée aux attributs clés d'un poste, tels que le titre ou le département, après sa création initiale. Cette activité est généralement déduite en suivant les changements dans le journal de la base de données du système. | ||
| Pourquoi c'est important Une fréquence élevée de cette activité peut indiquer une mauvaise qualité des données ou un retravail de processus. C'est essentiel pour les KPI de fréquence de modification des attributs de poste et de taux de retravail. Où obtenir Déduit de la table SysDatabaseLog si le suivi des modifications est activé pour la table des postes. Alternativement, cela nécessite de comparer les instantanés historiques des données de poste. Capture Déduit en détectant les opérations de mise à jour sur les champs clés de la table HcmPosition via le journal de la base de données. Type d'événement inferred | |||
| Budget du poste approuvé | Un jalon d'approbation clé confirmant que les fonds nécessaires sont alloués pour le nouveau poste. Ceci est généralement capturé comme une étape d'approbation distincte au sein du workflow de création de poste. | ||
| Pourquoi c'est important Isole l'étape d'approbation financière, permettant l'analyse des retards liés à l'allocation budgétaire et soutenant le KPI de temps de cycle d'approbation budgétaire des postes. Où obtenir Enregistré dans les tables d'historique du workflow, telles que WorkflowTrackingTable, comme une tâche d'approbation terminée, souvent assignée à un rôle financier. Capture Capturé à partir de l'horodatage de l'achèvement de la tâche d'approbation budgétaire dans le journal du workflow. Type d'événement explicit | |||
| Demande de poste approuvée par le manager | Représente l'achèvement de la première ligne d'approbation par le responsable du recrutement. Cet événement est enregistré explicitement dans l'historique du workflow lorsque le manager complète sa tâche d'approbation assignée. | ||
| Pourquoi c'est important Détermine la durée de l'étape d'approbation initiale, aidant à identifier les goulots d'étranglement avec des responsables ou des départements spécifiques. Où obtenir Enregistré comme une étape terminée dans les tables d'historique du workflow, telles que WorkflowTrackingTable, associée à la demande de poste. Capture Capturé à partir de l'horodatage de l'achèvement de l'étape d'approbation du manager dans le journal du workflow. Type d'événement explicit | |||
| Demande de poste rejetée | Indique qu'une demande de poste a été refusée à l'une des étapes d'approbation. Cet événement est explicitement capturé dans l'historique du workflow lorsqu'un approbateur sélectionne l'action 'Rejeter'. | ||
| Pourquoi c'est important Met en évidence les échecs de processus et les boucles de retravail. L'analyse des motifs de rejet aide à améliorer la qualité des demandes initiales et soutient le KPI de taux de rejet des demandes de postes. Où obtenir Enregistré comme un statut de 'Rejet' dans les tables d'historique du workflow, telles que WorkflowTrackingStatusTable, pour la demande de poste spécifique. Capture Capturé à partir du journal du workflow lorsqu'un approbateur exécute l'action de rejet. Type d'événement explicit | |||
| Poste examiné pour conformité | Indique qu'un poste a fait l'objet d'une vérification formelle de conformité. Ceci peut être capturé par un changement de statut, une tâche de liste de contrôle complétée ou la mise à jour d'un champ personnalisé. | ||
| Pourquoi c'est important Crucial pour surveiller le respect des politiques réglementaires et internes. Cette activité soutient directement le KPI de taux de conformité des postes. Où obtenir Probablement déduit d'un champ de statut horodaté comme 'ComplianceReviewStatus' ou d'un champ booléen 'IsComplianceReviewed' sur l'enregistrement du poste. Capture Déduit de l'horodatage lorsque un champ de statut de conformité est mis à jour à 'Terminé' ou 'Examiné'. Type d'événement inferred | |||
| Poste Gelé | Indique qu'un poste a été temporairement mis en attente, empêchant toute activité de recrutement. Ceci est capturé en déduisant un changement de statut sur l'enregistrement du poste vers un état 'Gelé' ou 'En attente'. | ||
| Pourquoi c'est important Suit les interruptions dans le cycle de vie du poste, ce qui peut impacter les plans d'effectifs et les budgets. Il aide à identifier les raisons des retards de recrutement. Où obtenir Déduit en suivant l'horodatage lorsque le champ de statut d'un enregistrement de poste est mis à jour à 'Gelé' ou une valeur similaire. Capture Déduit de l'horodatage d'un changement de statut à 'Gelé' ou 'En attente'. Type d'événement inferred | |||
| Poste Reclassifié | Une mise à jour significative où la classification fondamentale du poste, comme sa famille d'emplois ou son niveau, est modifiée. Ceci est généralement déduit d'une modification du champ 'Emploi' sur l'enregistrement du poste. | ||
| Pourquoi c'est important Aide à analyser les changements de structure organisationnelle et la stabilité des définitions d'emploi. C'est l'activité clé pour le KPI de taux de reclassification des postes. Où obtenir Déduit d'un changement dans le champ 'JobId' de la table HcmPosition, capturé via le journal de la base de données ou en comparant les versions des enregistrements au fil du temps. Capture Déduit d'un changement enregistré dans le champ de classification de l'emploi sur l'enregistrement du poste. Type d'événement inferred | |||
| Processus d'embauche démarré | Signifie le transfert de la gestion des postes au recrutement. Cet événement est déduit lorsqu'une nouvelle vacance ou un projet de recrutement est créé et lié à cet ID de poste spécifique. | ||
| Pourquoi c'est important Connecte le processus de gestion des postes à son résultat, permettant l'analyse du temps entre l'activation du poste et le début des activités de recrutement réelles. Où obtenir Déduit en identifiant la date de création d'un enregistrement dans les tables de recrutement ou de vacance, telles que HcmRecruitingRequest, qui référence l'ID de poste. Capture Déduit en liant le PositionId à la création d'un enregistrement correspondant dans le module de recrutement. Type d'événement inferred | |||
Guides d'extraction
Étapes
- Accéder à l'espace de travail de gestion des données : Connectez-vous à Microsoft Dynamics 365 Human Resources. Utilisez la barre de recherche principale pour naviguer vers l'espace de travail 'Gestion des données'.
- Créer un nouveau projet d'exportation : Dans l'espace de travail, sélectionnez la tuile 'Exporter'. Sur la page du projet 'Exporter', cliquez sur 'Nouveau' pour créer un nouveau projet. Donnez un nom descriptif, tel que 'PositionManagement_EventLog_Export', et sélectionnez un format de données. Pour les besoins de transformation, le format 'CSV' est recommandé.
- Ajouter des entités de données au projet : Dans votre nouveau projet, cliquez sur 'Ajouter une entité'. Vous devrez ajouter plusieurs entités pour capturer le cycle de vie complet du poste. Ajoutez les entités clés suivantes une par une : 'HcmPositionV2', 'WorkflowTrackingStatusTable' et 'HcmRecruitingRequest'. Si la journalisation de la base de données est activée pour les modifications de poste, ajoutez également 'SysDatabaseLog'.
- Configurer les filtres d'entité : Pour chaque entité, il est crucial d'appliquer des filtres pour limiter la portée des données. Sélectionnez une entité, puis cliquez sur 'Filtre'. Pour 'HcmPositionV2', filtrez par une plage de dates spécifique en utilisant les champs 'CreatedDateTime' ou 'ModifiedDateTime'. Pour 'WorkflowTrackingStatusTable', filtrez le 'CONTEXTTABLENAME' pour n'inclure que les workflows liés aux postes.
- Sélectionner les champs pour chaque entité : Assurez-vous d'exporter tous les champs nécessaires pour une transformation ultérieure. Pour 'HcmPositionV2', incluez 'PositionId', 'CreatedDateTime', 'ActivationDate', 'RetirementDate', 'ModifiedDateTime', 'JobId' et 'DepartmentNumber'. Pour 'WorkflowTrackingStatusTable', incluez 'ContextRecId', 'WorkflowTrackingStatus', 'CreatedDateTime' et 'UserId'.
- Exécuter la tâche d'exportation : Une fois toutes les entités, champs et filtres configurés, cliquez sur 'Exporter' sur la page principale du projet. Le système créera un package de données contenant des fichiers séparés pour chaque entité.
- Surveiller et télécharger le package de données : Vous pouvez suivre la progression de la tâche dans la section 'Historique des tâches'. Une fois la tâche terminée avec succès, téléchargez le package de données, qui sera un fichier compressé.
- Extraire et transformer les données : Décompressez le package téléchargé. Vous y trouverez des fichiers CSV séparés pour chaque entité. Ces fichiers représentent des données brutes, et non le journal d'événements final. Vous devez utiliser un script externe (par exemple, en utilisant Python avec pandas ou PowerShell) pour traiter ces fichiers.
- Implémenter la logique de transformation : Votre script doit effectuer les actions suivantes :
- Chargez le fichier 'HcmPositionV2.csv'. À partir de ce fichier, générez l'événement 'Poste créé dans le système RH' en utilisant 'PositionId' et 'CreatedDateTime'.
- Générez les événements de changement de statut ('Poste activé', 'Poste gelé', 'Poste désactivé', 'Poste fermé') en interprétant les champs de statut ou les champs de date comme 'ActivationDate' et 'RetirementDate' à partir de 'HcmPositionV2.csv'.
- Chargez le fichier 'WorkflowTrackingStatusTable.csv'. Joignez ces données aux données de poste en utilisant l'ID d'enregistrement. À partir de là, générez les événements de workflow : 'Demande de poste initiée', 'Demande de poste approuvée par le manager', 'Budget du poste approuvé', 'Demande de poste approuvée par les RH' et 'Demande de poste rejetée'. Vous devrez mapper le statut du workflow et le contexte de l'étape au nom d'activité correct.
- Si vous avez exporté 'SysDatabaseLog.csv', analysez ce fichier pour générer les événements 'Attributs de poste modifiés' et 'Poste reclassifié' basés sur les changements apportés à des champs spécifiques de la table HcmPosition.
- Chargez le fichier 'HcmRecruitingRequest.csv' pour générer l'événement 'Processus d'embauche démarré' en recherchant la création d'une demande de recrutement pour un poste donné.
- Assembler le journal d'événements final : Le script doit combiner tous les événements générés à partir des différentes sources dans un seul fichier CSV. Ce fichier doit contenir les colonnes requises : 'PositionId', 'ActivityName' et 'EventTime', ainsi que tous les attributs recommandés que vous avez pu mapper.
- Format pour l'upload : Assurez-vous que le fichier CSV final a des en-têtes correspondant aux noms d'attributs requis et que la colonne 'EventTime' est dans un format d'horodatage cohérent. Le fichier est maintenant prêt à être importé dans l'outil de Process Mining.
Configuration
- Principales entités de données : Les entités primaires requises pour cette extraction sont :
HcmPositionV2: Contient les détails essentiels de chaque poste, y compris les dates de création, les dates d'activation et les attributs tels que l'emploi et le département.WorkflowTrackingStatusTable: Fournit l'historique des instances de workflow, y compris les soumissions, les approbations et les rejets. C'est essentiel pour suivre le processus d'approbation.HcmRecruitingRequest: Utilisée pour déduire l'activité 'Processus d'embauche démarré' lorsqu'une demande de recrutement est liée à un poste.SysDatabaseLog: Une entité facultative mais puissante pour capturer les modifications détaillées comme 'Attributs du poste modifiés' et 'Poste reclassifié'. Son utilisation dépend de la configuration préalable de la journalisation de la base de données pour la table HcmPosition.
- Filtrage par plage de dates : Il est fortement recommandé d'appliquer un filtre de plage de dates à l'entité 'HcmPositionV2' basé sur le champ 'CreatedDateTime'. Une plage de 6 à 12 mois est souvent un bon point de départ pour assurer un volume de données gérable.
- Exportations incrémentielles : Pour une analyse continue, envisagez de configurer le projet d'exportation pour des exportations incrémentielles. Cela n'extraira que les enregistrements qui ont changé depuis la dernière exécution, réduisant considérablement le temps de traitement.
- Prérequis : L'utilisateur exécutant l'exportation doit avoir un rôle de sécurité avec des autorisations suffisantes pour accéder à l'espace de travail 'Gestion des données' et un accès en lecture à toutes les entités de données spécifiées. Des rôles comme 'Administrateur de la gestion des données' ou un rôle personnalisé avec des privilèges d'entité spécifiques sont généralement requis.
a Exemple de requête 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]Étapes
- Confirmation des prérequis : Avant de commencer, vérifiez que la fonctionnalité 'Bring Your Own Database' (BYOD) est configurée pour votre instance Microsoft Dynamics 365 Human Resources. Assurez-vous que les entités de données requises sont exportées vers votre base de données Azure SQL. Les entités clés incluent :
HcmPositionV2,HcmPositionDetail,WorkflowTrackingStatusTable,HcmJob,OMOperatingUnitetHcmRecruitingRequest. - Se connecter à la base de données Azure SQL : Utilisez un outil client SQL, tel que SQL Server Management Studio (SSMS) ou Azure Data Studio, pour établir une connexion à la base de données Azure SQL qui sert de destination à votre BYOD.
- Identifier le schéma de la base de données : Une fois connecté, familiarisez-vous avec le schéma de la base de données. Les entités de données de D365 HR sont répliquées sous forme de tables. Notez que les noms de table dans la base de données BYOD peuvent ne pas correspondre exactement aux noms d'entités, mais sont généralement très similaires.
- Charger la requête SQL : Ouvrez une nouvelle fenêtre de requête dans votre client SQL et collez le script SQL complet fourni dans la section 'query' de ce document.
- Personnaliser les paramètres : Modifiez les variables d'espace réservé dans la requête. Définissez
@[YourCompanyId]sur l'entité juridique spécifique (par exemple, 'USMF') que vous souhaitez analyser. Ajustez la plage de dates dans les clausesWHERE(par exemple,CREATEDDATETIME >= '2023-01-01') pour limiter l'extraction à la période souhaitée. - Exécuter la requête : Exécutez la requête SQL complète sur la base de données BYOD. Le temps d'exécution variera en fonction du volume de données et de la plage de dates sélectionnée.
- Examiner les résultats : Une fois la requête terminée, inspectez la sortie dans le panneau des résultats de votre client SQL. Vérifiez que les colonnes
PositionId,ActivityName,EventTimeet les autres sont remplies comme prévu. - Exporter au format CSV : Exportez l'ensemble des résultats vers un fichier CSV. La plupart des clients SQL ont une fonction intégrée pour enregistrer les résultats directement dans un fichier CSV. Par exemple, dans SSMS, vous pouvez faire un clic droit sur la grille de résultats et sélectionner 'Enregistrer les résultats sous...'.
- Préparer pour l'upload : Assurez-vous que le fichier CSV exporté a un encodage UTF-8. Confirmez que les en-têtes de colonne correspondent exactement aux attributs requis (
PositionId,ActivityName,EventTime, etc.) pour un upload fluide dans l'outil de Process Mining.
Configuration
- Entités de données BYOD : Assurez-vous que toutes les entités de données nécessaires sont publiées de Dynamics 365 HR vers votre instance BYOD. Les entités critiques pour ce processus incluent celles pour les postes, les détails des postes, l'historique des workflows, les emplois, les départements et les demandes de recrutement.
- Latence des données : Soyez conscient que le BYOD est une réplication quasi en temps réel, et non instantanée. Il peut y avoir un léger décalage, de quelques minutes à une heure, entre une transaction survenant dans D365 HR et l'apparition des données dans la base de données Azure SQL.
- Filtrage par plage de dates : Il est crucial d'appliquer des filtres de dates à votre requête pour gérer les performances et le volume de données. Un point de départ typique est une plage de 3 à 6 mois. Appliquez des filtres sur les horodatages de création ou d'événement au sein de chaque bloc
UNION ALL. - Filtre d'entreprise : Filtrez toujours par le
DATAREAID(entité juridique ou ID d'entreprise) pour vous assurer d'analyser les données de l'unité organisationnelle correcte. La requête fournie inclut un espace réservé@[YourCompanyId]à cet effet. - Prérequis : Cette méthode nécessite un abonnement Azure actif, une instance BYOD configurée, des autorisations de lecture sur la base de données Azure SQL cible et un outil client SQL adapté pour l'exécution des requêtes.
- Étapes de Workflow Personnalisées : La requête utilise des noms d'étapes de workflow courants pour les approbations comme 'Approuver la demande de poste'. Si votre organisation utilise des noms personnalisés pour ces étapes de workflow, vous devrez mettre à jour les valeurs
CONTEXTdans les clausesWHEREcorrespondantes.
a Exemple de requête 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]'