Votre modèle de données pour la gestion des postes, de l’embauche au départ
Votre modèle de données pour la gestion des postes, de l’embauche au départ
- Attributs recommandés pour une analyse approfondie
- Activités clés du processus à suivre pour une découverte précise
- Conseils d’extraction adaptés à Microsoft Dynamics 365 Human Resources
Attributs de gestion des postes, de l’embauche au départ
| Nom | Description | ||
|---|---|---|---|
| Heure de l’événement EventTime | Horodatage indiquant le moment où l’activité a eu lieu. | ||
| Description L’heure de l’événement, ou son horodatage, indique la date et l’heure exactes auxquelles une activité a été terminée. Elle est essentielle pour classer les événements par ordre chronologique et calculer les durées et les temps de cycle. Cet attribut intervient dans presque toutes les analyses de Process Mining, de la création de la cartographie du processus au calcul des KPI de performance, comme le temps moyen de cycle d’approbation des postes. Il aide à repérer les retards et à mesurer la durée de chaque étape du processus. Pourquoi est-ce important ? Cet horodatage est indispensable pour ordonner les événements, calculer toutes les métriques temporelles et repérer les goulots d’étranglement du processus. Où trouver ces données Cette information se trouve généralement dans les tables de journaux système ou dans les champs « CreatedDateTime » et « ModifiedDateTime » associés aux enregistrements de postes et de flux de travail 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 | |||
| Identifiant du poste PositionId | Identifiant unique d’un poste précis au sein de l’organisation. | ||
| Description L’identifiant du poste sert d’identifiant de cas principal et relie toutes les activités et données associées à un même poste de l’organisation. Il permet de suivre le cycle de vie complet d’un poste, de sa création et de ses modifications à sa désactivation ou à sa clôture. Dans l’analyse des processus, cet identifiant est indispensable pour reconstituer le parcours de chaque poste. Il permet de créer des Dashboards qui suivent les temps de cycle, repèrent les goulots d’étranglement dans les approbations et analysent les variantes du processus, de la demande à la clôture. Pourquoi est-ce important ? Cet identifiant central relie tous les événements associés à un même cas de processus et permet d’analyser le cycle de vie complet du poste. Où trouver ces données Il s’agit généralement du champ HcmPosition.PositionId dans Microsoft Dynamics 365 Human Resources. On le trouve dans des entités de données comme HcmPositionV2Entity. Exemples POS001234MKT-0056FIN-SR-ANALYST-02HRBP-EAST-01IT-DEV-9876 | |||
| Nom de l’activité ActivityName | Nom de l’événement ou de la tâche qui s’est produit dans le processus de gestion des postes. | ||
| Description Cet attribut décrit une étape du cycle de vie du poste, par exemple « Demande de poste lancée », « Poste créé dans le système RH » ou « Poste désactivé ». Il constitue la base de la cartographie du processus et en montre l’enchaînement des événements. L’analyse du nom de l’activité permet de visualiser les flux du processus, de repérer les écarts par rapport au processus standard et de calculer les délais entre les étapes. Elle est essentielle pour comprendre ce qui s’est passé et dans quel ordre. Pourquoi est-ce important ? Il définit les étapes du processus et permet de visualiser sa cartographie, son déroulement et ses variantes. Où trouver ces données Cet attribut est dérivé des événements métier, des changements de statut ou de l’historique du flux de travail dans Microsoft Dynamics 365 Human Resources. Il ne correspond pas à un champ unique, mais est construit à partir du contexte des données. Exemples Demande de poste lancéeDemande de poste approuvée par le responsablePoste créé dans le système RHAttributs du poste modifiésPoste clôturé | |||
| Centre de coûts CostCenter | Centre de coûts auquel sont imputées les dépenses liées au poste. | ||
| Description Le centre de coûts est une dimension financière essentielle qui rattache un poste à un budget précis ou à un domaine de responsabilité financière. Il est important d’en suivre les modifications. Cet attribut est essentiel au Dashboard « Vérification de la cohérence des données des postes », qui analyse les changements apportés aux attributs clés après la création. Il sert également à analyser les coûts et les budgets liés aux postes selon différentes unités financières. Pourquoi est-ce important ? Il relie le poste aux données financières, ce qui permet d’analyser les coûts du processus et de vérifier la cohérence des données. Où trouver ces données Il est généralement configuré comme dimension financière dans l’enregistrement du poste. Consultez la configuration des dimensions financières dans Dynamics 365. Exemples CC-1001-FINCC-2500-ITCC-4510-SALESCC-7000-OPSCC-9002-HR | |||
| Département DepartmentName | Département auquel le poste est rattaché. | ||
| Description Cet attribut précise le département de l’organisation auquel le poste est rattaché, par exemple « Finance », « Marketing » ou « Informatique ». Il constitue une dimension essentielle pour filtrer et regrouper les données du processus. L’analyse par département est indispensable au Dashboard « Débit des postes par département ». Elle permet de comparer les performances du processus, de repérer les goulots d’étranglement propres à chaque département et de comprendre les tendances de recrutement dans les différentes parties de l’entreprise. Pourquoi est-ce important ? Il permet de segmenter l’analyse du processus par unité opérationnelle, afin de repérer les problèmes propres à chaque département et de comparer les performances. Où trouver ces données Cette information figure dans les détails du poste, généralement dans l’entité HcmPositionDetail, et est liée à la dimension de l’unité opérationnelle. Exemples FinanceInformatiqueVentes et marketingRessources humainesOpérations | |||
| Heure de fin EndTime | Horodatage indiquant la fin de l’activité. | ||
| Description EndTime marque la fin d’une activité. Le temps écoulé entre StartTime et EndTime correspond à la durée de traitement de cette activité. Cet attribut est essentiel pour calculer la durée de chaque activité et comprendre où le temps est consacré dans le processus. Il permet, par exemple, de déterminer combien de temps un responsable met à approuver une demande de poste qui lui a été attribuée. Pourquoi est-ce important ? Il permet de calculer la durée de traitement des activités, une mesure fondamentale pour analyser en détail les performances et les goulots d’étranglement. Où trouver ces données Cette valeur peut être déduite des horodatages des événements suivants ou de champs de fin spécifiques dans les journaux de flux de travail de Dynamics 365 HR. Elle doit souvent être estimée. Exemples 2023-04-15T09:05:12Z2023-04-15T15:00:00Z2023-04-19T09:00:00Z2023-05-03T10:00:00Z2024-01-10T10:05:00Z | |||
| Intitulé du poste JobTitle | Intitulé de l’emploi associé au poste, par exemple « Comptable principal ». | ||
| Description L’intitulé du poste précise le rôle et les responsabilités associés au poste. Il diffère de l’identifiant du poste, car plusieurs postes peuvent avoir le même intitulé. Dans les analyses, cet attribut permet de regrouper et de filtrer les postes par type de rôle. Il est utile dans le Dashboard « Tendances de reclassification des postes » pour repérer les types d’emplois les plus souvent reclassifiés. Pourquoi est-ce important ? Il apporte un contexte métier essentiel et permet d’analyser les postes selon le rôle, le niveau ou la fonction. Où trouver ces données Cette information est liée à l’enregistrement « Job » associé au poste. Recherchez-la dans des entités telles que HcmPositionV2Entity ou en établissant une jointure avec HcmJobEntity. Exemples Analyste financier principalIngénieur logiciel IIPartenaire d’affaires RHCoordinateur marketingResponsable logistique | |||
| Nom d’utilisateur UserName | Nom ou identifiant de l’utilisateur qui a effectué l’activité. | ||
| Description Cet attribut identifie l’employé ou l’utilisateur système responsable d’une étape du processus, par exemple le responsable qui a approuvé une demande ou le spécialiste RH qui a créé le poste dans le système. L’analyse par utilisateur permet de repérer les besoins de formation, de comparer les performances des membres d’une équipe et de comprendre la répartition de la charge de travail. Elle est également essentielle aux contrôles de conformité, qui vérifient la bonne séparation des tâches. Pourquoi est-ce important ? Il permet d’identifier les responsabilités et d’analyser les performances par personne ou par équipe, ce qui est important pour la gestion des ressources et la formation. Où trouver ces données Associé à l’historique du flux de travail ou aux enregistrements de piste d’audit dans Dynamics 365 HR. Il peut être relié au moyen d’un User ID de l’entité HcmWorker. Exemples John SmithJane DoeSYSTEMHRAdmin01MGR-FINANCE | |||
| Statut du poste PositionStatus | Statut actuel ou historique du poste. | ||
| Description Cet attribut indique l’état du poste à un moment donné, par exemple « Proposé », « Actif », « Gelé » ou « Fermé ». Les changements de statut correspondent souvent à des activités du processus. Le suivi du statut est essentiel pour comprendre le parcours du poste et alimenter des Dashboards tels que « État de l’examen de conformité des postes » et « Postes inactifs et sous-utilisés ». Il donne un aperçu de l’état actuel du poste et aide à vérifier le déroulement du processus. Pourquoi est-ce important ? Il indique clairement l’état de chaque poste, ce qui est essentiel pour filtrer les cas et comprendre leurs résultats. Où trouver ces données Consultez la documentation de Microsoft Dynamics 365 Human Resources. Cette information provient probablement des champs de statut de l’enregistrement principal du poste. Exemples ProposéEn cours d’examenActifGeléFermé | |||
| Budget approuvé IsBudgetApproved | Indicateur précisant si le budget du poste a été approuvé. | ||
| Description Cet attribut booléen prend la valeur true si l’activité « Budget du poste approuvé » a eu lieu pour un cas de poste donné. Il aide à analyser le déroulement du processus et à repérer les postes en attente d’approbation budgétaire. Cet attribut permet de filtrer les processus et d’analyser plus efficacement l’indicateur « Temps de cycle d’approbation du budget des postes ». Il distingue les postes dont le budget a été approuvé de ceux qui ne le sont pas, ce qui facilite l’analyse des goulots d’étranglement. Pourquoi est-ce important ? Il simplifie l’analyse en signalant clairement une étape clé et permet ainsi d’isoler et de mesurer la phase d’approbation budgétaire. Où trouver ces données Cette valeur est calculée lors de la transformation des données en vérifiant si l’activité « Budget du poste approuvé » figure dans l’historique du cas. Exemples truefalse | |||
| Dernière mise à jour des données LastDataUpdate | Date et heure de la dernière actualisation des données depuis le système source. | ||
| Description Cet attribut indique la date de la dernière extraction des données depuis Microsoft Dynamics 365 Human Resources. Il permet de savoir si les analyses reposent sur des données récentes. L’affichage de cette information dans les Dashboards confirme aux utilisateurs qu’ils consultent des données à jour. Il s’agit d’une métadonnée essentielle pour tout projet de Process Mining. Pourquoi est-ce important ? Il renseigne les utilisateurs sur l’actualité des données, un élément important pour prendre des décisions à partir des analyses. Où trouver ces données Cet horodatage est généré et enregistré lors du processus d’extraction, de transformation et de chargement des données (ETL). Exemples 2024-05-21T02:00:00Z2024-05-20T02:00:00Z2024-05-19T02:00:00Z | |||
| Est une reprise IsRework | Indicateur précisant si une activité fait partie d’une boucle de reprise. | ||
| Description Cet indicateur booléen prend la valeur true lorsqu’une étape du processus est répétée, par exemple une nouvelle approbation après la modification d’attributs. Il permet de quantifier les boucles inefficaces du processus. Cet attribut alimente directement le Dashboard « Analyse des reprises de postes » et l’indicateur « Taux de reprise lors de la création d’un poste ». En signalant les reprises, les analystes peuvent facilement filtrer les données et mesurer la fréquence et les effets des inefficacités du processus. Pourquoi est-ce important ? Il repère et quantifie explicitement les reprises dans le processus, une cible prioritaire des initiatives d’amélioration. Où trouver ces données Cette valeur est calculée à partir de la séquence des activités d’un cas. Par exemple, si l’activité « Demande de poste approuvée par le responsable » survient après « Attributs du poste modifiés », elle peut être signalée comme une reprise. Exemples truefalse | |||
| Famille d’emplois JobFamily | Regroupement d’emplois aux fonctions similaires, comme « Ingénierie » ou « Finance ». | ||
| Description La famille d’emplois regroupe des intitulés de poste apparentés. Par exemple, « Ingénieur logiciel » et « Ingénieur assurance qualité » peuvent appartenir à la famille « Ingénierie ». Cet attribut est essentiel au Dashboard « Tendances de reclassification des postes », car il permet d’analyser à un niveau plus général les catégories d’emplois qui évoluent le plus souvent. Il offre une vue d’ensemble plus large que l’analyse des seuls intitulés de poste. Pourquoi est-ce important ? Il permet d’analyser les postes par grandes catégories, ce qui est utile pour la planification stratégique des effectifs et l’étude des tendances. Où trouver ces données Cette information fait partie de la configuration des emplois dans Dynamics 365 HR. Recherchez les champs liés à « Job family » ou « Job function » dans HcmJobEntity. Exemples IngénierieFinance et comptabilitéVentesRessources humainesGestion de produit | |||
| Lieu Location | Lieu physique ou géographique du poste. | ||
| Description Cet attribut indique le lieu d’affectation du poste, qui peut être un bureau, une ville ou un pays. Il constitue une autre dimension importante pour filtrer et segmenter les données du processus. Le lieu est utilisé directement dans le Dashboard « Débit des postes par département » pour analyser les tendances en matière d’effectifs et les performances du processus dans différentes régions. Il peut aider à repérer les lieux où la création ou l’approbation des postes prend plus de temps. Pourquoi est-ce important ? Il apporte un contexte géographique et permet d’analyser les performances et les tendances du processus selon les lieux. Où trouver ces données Consultez la documentation de Microsoft Dynamics 365 Human Resources. Cette information peut figurer dans les détails du poste ou être liée au département ou à l’entité juridique. Exemples New York, États-UnisLondres, Royaume-UniBerlin, AllemagneSingapourÀ distance | |||
| Motif du rejet RejectionReason | Motif indiqué lors du rejet d’une demande de poste. | ||
| Description Lorsqu’un responsable ou les RH rejettent une demande de poste, un motif est souvent consigné. Il peut s’agir de contraintes budgétaires, d’informations incorrectes ou d’un changement de stratégie. Cet attribut est essentiel pour calculer l’indicateur du taux de rejet des demandes de poste et comprendre les causes des reprises. L’analyse des motifs de rejet les plus fréquents permet de repérer les problèmes en amont, comme des demandes de mauvaise qualité ou des consignes peu claires, et d’améliorer le processus. Pourquoi est-ce important ? Il indique directement pourquoi les demandes échouent et permet de cibler les améliorations du processus afin de réduire les reprises et les rejets. Où trouver ces données Consultez la documentation de Microsoft Dynamics 365 Human Resources. Le motif est souvent consigné dans les commentaires du flux de travail ou dans un champ dédié au code de motif lors du rejet. Exemples Budget indisponibleDemande en doubleProfil d’emploi incorrectGel des recrutementsRéorientation stratégique | |||
| Responsable demandeur RequestingManager | Responsable à l’origine de la demande de création du poste. | ||
| Description Cet attribut identifie le responsable du recrutement ou le chef de département qui a lancé le processus en demandant la création ou le remplacement d’un poste. Il indique l’origine de la demande de poste. L’analyse par responsable demandeur peut révéler des tendances concernant le volume et la qualité des demandes, ainsi que leur taux d’approbation. Elle apporte un niveau de détail supplémentaire pour comprendre la charge de travail et le respect du processus. Pourquoi est-ce important ? Il permet de retracer l’origine des demandes de poste et d’analyser les indicateurs du processus du point de vue du responsable du recrutement. Où trouver ces données Consultez la documentation de Microsoft Dynamics 365 Human Resources. Cette information devrait figurer dans les données de lancement du flux de travail. Exemples Robert JonesSusan MillerDavid ChenMaria GarciaPaul Williams | |||
| Système source SourceSystem | Système à partir duquel les données ont été extraites. | ||
| Description Cet attribut indique l’origine des données du processus. Dans cette vue, il s’agit généralement de « Microsoft Dynamics 365 Human Resources ». Dans un environnement composé de plusieurs systèmes, ce champ est essentiel pour suivre la provenance des données et résoudre les problèmes. Il permet de vérifier que les données proviennent de la source attendue et de filtrer les analyses par système. Pourquoi est-ce important ? Il précise l’origine des données, une information importante pour leur gouvernance et pour les analyses couvrant plusieurs systèmes d’entreprise. Où trouver ces données Valeur statique ajoutée lors de l’extraction et de la transformation des données pour indiquer l’origine du jeu de données. Exemples Microsoft Dynamics 365 Human ResourcesD365 HRDynamicsHR | |||
| Temps de cycle d’approbation ApprovalCycleTime | Durée totale entre le lancement d’une demande de poste et son approbation définitive. | ||
| Description Cet indicateur calculé mesure la durée entre l’activité « Demande de poste lancée » et l’activité d’approbation finale, qui peut être « Demande de poste approuvée par les RH ». Il mesure les performances de la première étape du processus de gestion des postes. Cet attribut alimente directement le Dashboard et l’indicateur « Temps de cycle d’approbation des postes ». Il donne une mesure globale de l’efficacité du processus d’approbation et permet de suivre l’effet des initiatives d’amélioration au fil du temps. Pourquoi est-ce important ? Cet indicateur clé mesure l’efficacité de l’ensemble du processus d’approbation et met directement en évidence les retards dans la préparation des postes à créer. Où trouver ces données Cette valeur est calculée au niveau du cas en repérant les horodatages des activités de début et de fin de la phase d’approbation, puis en calculant leur différence. Exemples P3DT2H15MP10DP1DT12HP5DT6HP2W | |||
| Type de poste PositionType | Indique si le poste est à temps plein, à temps partiel, temporaire, etc. | ||
| Description Cet attribut classe le poste selon ses conditions d’emploi. Il apporte un contexte supplémentaire pour l’analyse et la planification des effectifs. Dans l’analyse du processus, le filtrage par type de poste peut révéler des parcours différents ou des temps de cycle plus longs selon les postes. Par exemple, l’approbation d’un poste temporaire peut suivre un parcours plus rapide et simplifié que celle d’un poste permanent à temps plein. Pourquoi est-ce important ? Il permet d’analyser les différences de déroulement du processus selon les types d’emploi, ce qui contribue à la planification des effectifs et à l’optimisation du processus. Où trouver ces données Cette information figure généralement dans l’enregistrement du poste dans Dynamics 365 HR. Recherchez le champ correspondant dans des entités telles que HcmPositionV2Entity. Exemples Temps pleinTemps partielPrestataireStagiaireTemporaire | |||
Activités de gestion des postes, de l’embauche au départ
| Activité | Description | ||
|---|---|---|---|
| Demande de poste approuvée par les RH | Indique que le service des ressources humaines a donné son approbation finale avant la création officielle du poste. Cet événement est consigné explicitement dans le système de flux de travail lorsque la tâche d’approbation des RH est terminée. | ||
| Pourquoi est-ce important ? Cette étape marque la fin de la phase d’approbation et constitue un jalon important pour mesurer le temps moyen de cycle d’approbation des postes. Où trouver ces données L’événement est consigné dans les tables d’historique du flux de travail, par exemple WorkflowTrackingTable, lorsque le représentant des RH termine sa tâche d’approbation. Données à recueillir L’événement et son horodatage sont consignés dans l’historique du flux de travail à la fin de l’étape d’approbation des RH. Type d’événement explicit | |||
| Demande de poste lancée | Marque le début officiel du cycle de vie de la gestion d’un poste. Cet événement est généralement enregistré lorsqu’un utilisateur soumet une nouvelle demande de poste au moyen d’un formulaire dédié ou d’un flux de travail dans Dynamics 365 HR. | ||
| Pourquoi est-ce important ? Ce point de départ permet de mesurer l’ensemble du cycle de vie du poste, notamment des KPI essentiels comme le temps de cycle d’approbation du poste et le délai de création du poste. Où trouver ces données L’événement est extrait de l’horodatage de création de la demande de poste ou de l’enregistrement de lancement dans la table d’historique du flux de travail, par exemple WorkflowTrackingStatusTable. Données à recueillir L’événement est enregistré lors de la soumission d’un nouveau flux de travail de demande de poste. Type d’événement explicit | |||
| Poste activé | Marque le moment où un poste est officiellement ouvert et où le recrutement peut commencer. Cet événement est déduit du passage du champ de statut de l’enregistrement du poste à « Active » ou à un état équivalent. | ||
| Pourquoi est-ce important ? Ce jalon est important pour mesurer la disponibilité du poste pour le recrutement et l’efficacité des dernières étapes de préparation. Il est essentiel au KPI du temps moyen d’activation d’un poste. Où trouver ces données L’activité est déduite du suivi de l’horodatage auquel le champ de statut de l’enregistrement du poste, par exemple « PositionStatus », est mis à jour à « Active » ou « Open ». Données à recueillir L’événement est déterminé à partir de la date de renseignement du champ ActivationDate du poste ou du passage d’un champ de statut à « Active ». Type d’événement inferred | |||
| Poste clôturé | Correspond à l’archivage définitif de l’enregistrement du poste et marque la fin de son cycle de vie. Cet événement est déduit du passage du statut à « Closed » ou à un état final équivalent. | ||
| Pourquoi est-ce important ? Cet événement marque la fin du processus. Il permet d’analyser l’ensemble du cycle de vie et de repérer les postes obsolètes qui devraient être clôturés. Où trouver ces données L’activité est déduite du passage d’un champ de statut de l’enregistrement du poste à « Closed ». Elle est moins fréquente que la désactivation, car les enregistrements sont souvent conservés à des fins d’historique. Données à recueillir L’activité est déduite de l’horodatage auquel un champ de statut est mis à jour à « Closed ». 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 dans Dynamics 365 HR. Il est extrait de l’horodatage de création de l’enregistrement principal du poste. | ||
| Pourquoi est-ce important ? Ce jalon fondamental marque le passage de la demande à la création effective d’un poste dans l’organisation. Il correspond au point final du KPI de délai de création du poste. Où trouver ces données À partir du champ système « CreatedDateTime » de la table principale des postes, par exemple HcmPosition. Données à recueillir 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. Cet événement est déduit du passage du statut à « Inactive » ou à un état équivalent. | ||
| Pourquoi est-ce important ? Marque une étape importante à la fin de la période d’activité du poste. Cet événement est essentiel pour analyser le temps moyen avant désactivation d’un poste et gérer précisément les effectifs. Où trouver ces données L’activité est déduite de l’horodatage auquel le champ « RetirementDate » est renseigné ou du passage d’un champ de statut de l’enregistrement du poste à « Inactive ». Données à recueillir L’événement est déterminé à partir de la date de renseignement de RetirementDate pour le poste ou du passage d’un champ de statut à « Inactive ». Type d’événement inferred | |||
| Attributs du poste modifiés | Correspond à toute modification apportée aux attributs essentiels d’un poste, comme son intitulé ou son service, après sa création initiale. Cette activité est généralement déduite du suivi des modifications dans le journal de la base de données du système. | ||
| Pourquoi est-ce important ? Une fréquence élevée de cette activité peut révéler une mauvaise qualité des données ou des reprises dans le processus. Elle est essentielle au suivi des KPI de fréquence de modification des attributs du poste et de taux de reprise. Où trouver ces données L’activité est déduite de la table SysDatabaseLog si le suivi des modifications est activé pour la table des postes. Il est également possible de comparer des instantanés historiques des données sur les postes. Données à recueillir L’activité est déduite de la détection des opérations de mise à jour des champs essentiels de la table HcmPosition dans le journal de la base de données. Type d’événement inferred | |||
| Budget du poste approuvé | Cette étape d’approbation confirme que les fonds nécessaires au nouveau poste sont alloués. Elle est généralement enregistrée comme une étape distincte du flux de travail de création du poste. | ||
| Pourquoi est-ce important ? Permet d’isoler l’étape d’approbation financière, d’analyser les retards liés à l’allocation budgétaire et de suivre le KPI du temps de cycle d’approbation du budget du poste. Où trouver ces données L’approbation terminée est consignée dans les tables d’historique du flux de travail, par exemple WorkflowTrackingTable, souvent sous la forme d’une tâche attribuée à un rôle financier. Données à recueillir L’événement est extrait de l’horodatage de fin de la tâche d’approbation budgétaire dans le journal du flux de travail. Type d’événement explicit | |||
| Conformité du poste vérifiée | Indique qu’un poste a fait l’objet d’un contrôle formel de conformité. Cet événement peut être enregistré à la suite d’un changement de statut, de la réalisation d’une tâche de vérification ou de la mise à jour d’un champ personnalisé. | ||
| Pourquoi est-ce important ? Cette activité est essentielle au suivi du respect des réglementations et des politiques internes. Elle contribue directement au KPI du taux de conformité des postes. Où trouver ces données L’activité peut être déduite d’un champ de statut horodaté, comme « ComplianceReviewStatus », ou d’un champ booléen « IsComplianceReviewed » dans l’enregistrement du poste. Données à recueillir L’activité est déduite de l’horodatage de mise à jour du champ de statut de conformité à « Completed » ou « Reviewed ». Type d’événement inferred | |||
| Demande de poste approuvée par le responsable | Indique que le responsable du recrutement a terminé la première étape d’approbation. Cet événement est consigné explicitement dans l’historique du flux de travail lorsque le responsable termine la tâche d’approbation qui lui a été attribuée. | ||
| Pourquoi est-ce important ? Permet de mesurer la durée de la première étape d’approbation et de repérer les goulots d’étranglement liés à certains responsables ou services. Où trouver ces données L’étape terminée est consignée dans les tables d’historique du flux de travail, par exemple WorkflowTrackingTable, et associée à la demande de poste. Données à recueillir L’événement est extrait de l’horodatage de fin de l’étape d’approbation du responsable dans le journal du flux de travail. 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 consigné explicitement dans l’historique du flux de travail lorsqu’un approbateur sélectionne l’action « Reject ». | ||
| Pourquoi est-ce important ? Met en évidence les échecs du processus et les boucles de reprise. L’analyse des motifs de rejet aide à améliorer la qualité des demandes initiales et à suivre le KPI du taux de rejet des demandes de poste. Où trouver ces données Le statut « Rejection » est consigné dans les tables d’historique du flux de travail, par exemple WorkflowTrackingStatusTable, pour la demande de poste concernée. Données à recueillir L’événement est extrait du journal du flux de travail lorsqu’un approbateur effectue l’action de rejet. Type d’événement explicit | |||
| Poste gelé | Indique qu’un poste a été temporairement suspendu, ce qui empêche toute activité de recrutement. Cet événement est déduit du passage du statut de l’enregistrement du poste à « Frozen » ou « On Hold ». | ||
| Pourquoi est-ce important ? Suit les interruptions du cycle de vie du poste, qui peuvent avoir des conséquences sur les plans de recrutement et les budgets. Cette activité aide à repérer les causes des retards de recrutement. Où trouver ces données L’activité est déduite du suivi de l’horodatage auquel le champ de statut de l’enregistrement du poste est mis à jour à « Frozen » ou à une valeur équivalente. Données à recueillir L’activité est déduite de l’horodatage du passage du statut à « Frozen » ou « On Hold ». Type d’événement inferred | |||
| Poste reclassé | Cette mise à jour importante modifie la classification fondamentale du poste, par exemple sa famille d’emplois ou son niveau. Elle est généralement déduite d’une modification du champ « Job » dans l’enregistrement du poste. | ||
| Pourquoi est-ce important ? Cette activité aide à analyser les changements de structure de l’organisation et la stabilité des définitions de poste. Elle est essentielle au KPI du taux de reclassement des postes. Où trouver ces données L’activité est déduite d’une modification du champ « JobId » dans la table HcmPosition, relevée dans le journal de la base de données ou par comparaison des versions de l’enregistrement au fil du temps. Données à recueillir L’activité est déduite d’une modification consignée du champ de classification de l’emploi dans l’enregistrement du poste. Type d’événement inferred | |||
| Processus de recrutement lancé | Indique le transfert de la gestion du poste vers le recrutement. Cet événement est déduit de la création d’une nouvelle offre d’emploi ou d’un projet de recrutement associé à l’identifiant de ce poste. | ||
| Pourquoi est-ce important ? Relie le processus de gestion du poste à son résultat et permet d’analyser le délai entre l’activation du poste et le début des activités de recrutement. Où trouver ces données L’activité est déduite de la date de création d’un enregistrement dans les tables de recrutement ou de postes vacants, par exemple HcmRecruitingRequest, qui fait référence à l’identifiant du poste. Données à recueillir L’activité est déduite de l’association de PositionId à la création d’un enregistrement correspondant dans le module de recrutement. Type d’événement inferred | |||
Guides d’extraction
Étapes
- Accédez à l’espace de travail Gestion des données : Connectez-vous à Microsoft Dynamics 365 Human Resources. Utilisez la barre de recherche principale pour accéder à l’espace de travail « Data management ».
- Créez un projet d’exportation : Dans cet espace de travail, sélectionnez la vignette « Export ». Sur la page du projet « Export », cliquez sur « New » pour créer un projet. Donnez-lui un nom explicite, par exemple « PositionManagement_EventLog_Export », puis choisissez un format de données. Le format « CSV » est recommandé pour les transformations.
- Ajoutez des entités de données au projet : Dans votre nouveau projet, cliquez sur « Add entity ». Pour couvrir l’ensemble du cycle de vie d’un poste, ajoutez plusieurs entités. Ajoutez les entités suivantes, une par une : « HcmPositionV2 », « WorkflowTrackingStatusTable » et « HcmRecruitingRequest ». Si la journalisation de la base de données est activée pour les changements de poste, ajoutez également « SysDatabaseLog ».
- Configurez les filtres des entités : Il est important d’appliquer des filtres à chaque entité pour limiter le périmètre des données. Sélectionnez une entité, puis cliquez sur « Filter ». Pour « HcmPositionV2 », définissez une période à l’aide des champs « CreatedDateTime » ou « ModifiedDateTime ». Pour « WorkflowTrackingStatusTable », filtrez le champ « CONTEXTTABLENAME » afin de ne conserver que les flux de travail liés aux postes.
- Sélectionnez les champs de chaque entité : Veillez à exporter tous les champs nécessaires aux transformations ultérieures. Pour « HcmPositionV2 », incluez « PositionId », « CreatedDateTime », « ActivationDate », « RetirementDate », « ModifiedDateTime », « JobId » et « DepartmentNumber ». Pour « WorkflowTrackingStatusTable », incluez « ContextRecId », « WorkflowTrackingStatus », « CreatedDateTime » et « UserId ».
- Lancez l’exportation : Une fois les entités, les champs et les filtres configurés, cliquez sur « Export » sur la page principale du projet. Le système crée un package de données contenant un fichier distinct pour chaque entité.
- Suivez et téléchargez le package de données : Vous pouvez suivre l’avancement du traitement dans la section « Job history ». Une fois le traitement terminé, téléchargez le package de données compressé.
- Extrayez et transformez les données : Décompressez le package téléchargé. Vous trouverez un fichier CSV distinct pour chaque entité. Ces fichiers contiennent les données brutes, et non le journal d’événements final. Vous devez les traiter à l’aide d’un script externe, par exemple avec Python et pandas ou avec PowerShell.
- Mettez en œuvre la logique de transformation : Votre script doit effectuer les opérations suivantes :
- Chargez le fichier « HcmPositionV2.csv ». À partir de celui-ci, générez l’événement « Poste créé dans le système RH » à l’aide de « 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 tels que « ActivationDate » et « RetirementDate » dans « HcmPositionV2.csv ».
- Chargez le fichier « WorkflowTrackingStatusTable.csv ». Reliez ces données à celles des postes à l’aide de l’identifiant d’enregistrement. Générez ensuite les événements de flux de travail suivants : « Demande de poste initiée », « Demande de poste approuvée par le responsable », « Budget du poste approuvé », « Demande de poste approuvée par les RH » et « Demande de poste rejetée ». Vous devrez associer le statut du flux de travail et le contexte de l’étape au nom d’activité correspondant.
- Si vous avez exporté « SysDatabaseLog.csv », analysez ce fichier pour générer les événements « Attributs du poste modifiés » et « Poste reclassé », en fonction des changements apportés à des champs précis de la table HcmPosition.
- Chargez « HcmRecruitingRequest.csv » pour générer l’événement « Processus de recrutement lancé », en repérant la date de création d’une demande de recrutement associée à un poste.
- Assemblez le journal d’événements final : Le script doit réunir dans un seul fichier CSV tous les événements générés à partir des différentes sources. Ce fichier doit contenir les colonnes requises : « PositionId », « ActivityName » et « EventTime », ainsi que les attributs recommandés que vous avez pu associer.
- Préparez le fichier à l’importation : Vérifiez que le fichier CSV final comporte des en-têtes correspondant aux noms d’attributs requis et que la colonne « EventTime » utilise un format d’horodatage cohérent. Le fichier est alors prêt à être importé dans l’outil de Process Mining.
Configuration
- Principales entités de données : Les principales entités nécessaires à cette extraction sont les suivantes :
HcmPositionV2: contient les informations essentielles sur chaque poste, notamment les dates de création et d’activation, ainsi que des attributs tels que le poste et le service.WorkflowTrackingStatusTable: fournit l’historique des instances de flux de travail, notamment les soumissions, les approbations et les rejets. Cette entité est indispensable pour suivre le processus d’approbation.HcmRecruitingRequest: permet de déduire l’activité « Processus de recrutement lancé » lorsqu’une demande de recrutement est associée à un poste.SysDatabaseLog: entité facultative, mais utile pour enregistrer des changements détaillés tels que « Attributs du poste modifiés » et « Poste reclassé ». Son utilisation dépend de la configuration préalable de la journalisation de la base de données pour la table HcmPosition.
- Filtrage par période : Il est vivement recommandé de filtrer l’entité « HcmPositionV2 » par période à partir du champ « CreatedDateTime ». Une période de 6 à 12 mois constitue souvent un bon point de départ pour conserver un volume de données gérable.
- Exportations incrémentielles : Pour effectuer des analyses régulières, vous pouvez configurer le projet d’exportation afin qu’il réalise des exportations incrémentielles. Seuls les enregistrements modifiés depuis la dernière exécution seront alors extraits, ce qui réduit considérablement le temps de traitement.
- Prérequis : La personne qui lance l’exportation doit disposer d’un rôle de sécurité lui donnant les autorisations nécessaires pour accéder à l’espace de travail « Data management » et lire toutes les entités de données indiquées. Le rôle « Data management administrator » ou un rôle personnalisé doté des autorisations requises sur les entités est généralement nécessaire.
Exemple de requête 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]Étapes
- Vérifiez les 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 principales entités sont :
HcmPositionV2,HcmPositionDetail,WorkflowTrackingStatusTable,HcmJob,OMOperatingUnitetHcmRecruitingRequest. - Connectez-vous à Azure SQL Database : Utilisez un outil client SQL, tel que SQL Server Management Studio (SSMS) ou Azure Data Studio, pour vous connecter à la base de données Azure SQL qui sert de destination BYOD.
- Repérez 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 D365 HR sont répliquées sous forme de tables. Notez que les noms des tables dans la base BYOD peuvent différer légèrement de ceux des entités, mais leur ressembleront généralement.
- Chargez 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.
- Personnalisez les paramètres : Modifiez les variables de remplacement dans la requête. Définissez
@[YourCompanyId]sur l’entité juridique à analyser, par exemple « USMF ». Ajustez la période dans les clausesWHERE, par exempleCREATEDDATETIME >= '2023-01-01', pour limiter l’extraction à la période souhaitée. - Exécutez la requête : Lancez la requête SQL complète sur la base de données BYOD. La durée d’exécution dépendra du volume de données et de la période sélectionnée.
- Vérifiez les résultats : Une fois la requête terminée, examinez les résultats dans le volet correspondant de votre client SQL. Vérifiez que les colonnes
PositionId,ActivityName,EventTimeet les autres sont renseignées comme prévu. - Exportez les résultats au format CSV : Exportez l’ensemble des résultats dans un fichier CSV. La plupart des clients SQL permettent d’enregistrer directement les résultats au format CSV. Dans SSMS, par exemple, faites un clic droit sur la grille de résultats et sélectionnez « Save Results As... ».
- Préparez le fichier à l’importation : Vérifiez que le fichier CSV exporté est encodé en UTF-8. Assurez-vous que les en-têtes de colonnes correspondent exactement aux attributs requis (
PositionId,ActivityName,EventTime, etc.) pour importer facilement le fichier dans l’outil de Process Mining.
Configuration
- Entités de données BYOD : Vérifiez que toutes les entités de données nécessaires sont publiées depuis Dynamics 365 HR vers votre instance BYOD. Les entités essentielles pour ce processus concernent les postes, les détails des postes, l’historique des flux de travail, les emplois, les services et les demandes de recrutement.
- Latence des données : BYOD assure une réplication presque en temps réel, mais pas instantanée. Un léger délai, de quelques minutes à une heure, peut s’écouler entre une transaction dans D365 HR et l’apparition des données dans la base Azure SQL.
- Filtrage par période : Il est essentiel d’appliquer des filtres de date à votre requête pour maîtriser les performances et le volume de données. Une période de 3 à 6 mois constitue un point de départ courant. Appliquez des filtres sur les dates de création ou les horodatages d’événements dans chaque bloc
UNION ALL. - Filtre par entreprise : Filtrez toujours par
DATAREAID(identifiant de l’entité juridique ou de l’entreprise) afin d’analyser les données de la bonne unité organisationnelle. La requête fournie contient la variable de remplacement@[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 Azure SQL cible et un client SQL adapté à l’exécution des requêtes.
- Étapes de flux de travail personnalisées : La requête utilise des noms courants pour les étapes d’approbation, comme « Approve position request ». Si votre organisation utilise des noms personnalisés, vous devrez modifier les valeurs
CONTEXTdans les clausesWHEREcorrespondantes.
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]'Prêt à commencer ?
Utilisez ce modèle pour simplifier la collecte de vos données et obtenir des analyses détaillées de votre processus de gestion des postes, de l’embauche au départ. Commencez dès aujourd’hui à améliorer l’efficacité et la conformité.
Optimisez dès maintenant la gestion des postes, de l’embauche au départ
Réduisez de 30 % le temps de cycle de vos processus et éliminez les goulots d’étranglement.
Aucune carte bancaire requise. Configuration en quelques minutes.