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 pour une analyse approfondie
- Activités clés du processus à suivre pour une découverte précise
- Instructions d’extraction spécifiques à Microsoft Dynamics 365 Human Resources
Hire to Retire, attributs de la gestion des postes
| Nom | Description | ||
|---|---|---|---|
| Heure de l’événement EventTime | Horodatage indiquant le moment où l’activité s’est produite. | ||
| Description L’heure de l’événement, ou horodatage, enregistre la date et l’heure exactes auxquelles une activité a été terminée. Elle est essentielle pour classer les événements dans l’ordre chronologique et calculer les durées ainsi que les temps de cycle. Cet attribut est utilisé dans presque toutes les analyses de Process Mining, de la création de la carte de processus au calcul des KPI de performance tels que la durée moyenne du cycle d’approbation des postes. Il aide à déterminer quand les retards surviennent et combien de temps dure chaque étape du processus. Pourquoi c’est important Cet horodatage est indispensable pour ordonner les événements, calculer toutes les métriques temporelles et détecter les goulots d’étranglement du processus. Où les obtenir Ces informations se trouvent généralement dans les tables de journaux système ou dans des champs « CreatedDateTime » ou « 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 Le Position ID sert d’identifiant de cas principal et relie toutes les activités et tous les éléments de données associés à un même poste. Il permet de suivre de bout en bout l’ensemble du cycle de vie d’un poste, de sa création et de ses modifications jusqu’à 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 durées de cycle, identifient les goulots d’étranglement dans les approbations et analysent les variantes du processus, de la demande à la clôture. Pourquoi c’est important Il s’agit de l’identifiant central qui relie tous les événements associés à un même cas de processus et permet d’analyser le cycle de vie du poste de bout en bout. Où les obtenir Il s’agit généralement du champ HcmPosition.PositionId dans Microsoft Dynamics 365 Human Resources. Il peut être présent dans des entités de données telles que 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 spécifique survenu dans le processus de gestion du poste. | ||
| Description Cet attribut décrit une étape précise du cycle de vie du poste, comme « Position Request Initiated », « Position Created In HR System » ou « Position Deactivated ». Il constitue la base de la cartographie du processus en présentant la séquence des événements. L’analyse du nom de l’activité permet de visualiser les flux de processus, d’identifier les écarts par rapport au processus standard et de calculer les délais de transition entre les différentes étapes. Elle est fondamentale pour comprendre ce qui s’est passé et dans quel ordre. Pourquoi c’est important Il définit les étapes du processus et permet de visualiser les cartes de processus ainsi que d’analyser les flux et les variations du processus. Où les obtenir Cet attribut est dérivé d’événements métier, de 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 initié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 | Le centre de coûts financier auquel sont affectées les dépenses liées au poste. | ||
| Description Le centre de coûts est une dimension financière clé qui relie un poste à un budget précis ou à un domaine de responsabilité financière. Il est important d’en surveiller les modifications. Cet attribut est essentiel au Dashboard « Position Data Consistency Check », 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 les différentes unités financières. Pourquoi c’est important Il relie le poste aux données financières, ce qui permet d’analyser les processus liés aux coûts et de contrôler la cohérence des données. Où les obtenir 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 | Le département auquel le poste est rattaché. | ||
| Description Cet attribut indique le service organisationnel, tel que « Finance », « Marketing » ou « IT », associé au poste. Il constitue une dimension principale pour filtrer et agréger les données de processus. L’analyse par service est essentielle au Dashboard « Débit des postes par service ». Elle permet de comparer la performance des processus, d’identifier les goulots d’étranglement propres à chaque service et de comprendre les tendances de recrutement dans les différentes composantes de l’entreprise. Pourquoi c’est important Il permet de segmenter l’analyse du processus par unité opérationnelle, afin d’identifier les problèmes propres à chaque département et de comparer les performances. Où les obtenir Ces informations font partie des détails du poste. Elles sont généralement stockées dans l’entité HcmPositionDetail et liées à la dimension de l’unité opérationnelle. Exemples FinanceTechnologies de l'informationVentes et marketingRessources humainesOpérations | |||
| Heure de fin EndTime | Horodatage indiquant le moment où l’activité a été terminée. | ||
| Description EndTime marque la fin d’une activité. Le temps écoulé entre StartTime et EndTime correspond au temps 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 notamment de déterminer combien de temps un responsable met à approuver une demande de poste après qu’elle lui a été attribuée. Pourquoi c’est important Il permet de calculer les durées de traitement des activités, ce qui est essentiel pour analyser en détail la performance et les goulots d’étranglement. Où les obtenir Cet attribut peut être dérivé des horodatages d’événements ultérieurs ou de champs « completion » spécifiques dans les journaux de flux de travail de Dynamics 365 HR. Il doit souvent ê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 | |||
| Intitulé du poste JobTitle | L’intitulé du poste associé à la position, par exemple « Senior Accountant ». | ||
| Description L’intitulé du poste fournit un contexte important sur le rôle et les responsabilités associés à la position. Il se distingue du Position ID, car plusieurs positions peuvent avoir le même intitulé. Dans l’analyse, cet attribut permet de regrouper et de filtrer les positions par type de rôle. Il est utile au Dashboard « Position Reclassification Trends » pour déterminer quels types de postes sont le plus souvent reclassifiés. Pourquoi c’est important Il apporte un contexte métier essentiel et permet d’analyser les données selon le rôle, le niveau ou la fonction. Où les obtenir Ces informations sont issues de l’enregistrement « Job » associé à la Position. Recherchez-les dans des entités telles que HcmPositionV2Entity ou en effectuant une jointure avec HcmJobEntity. Exemples Analyste financier seniorIngénieur logiciel IIPartenaire RHCoordinateur marketingResponsable logistique | |||
| Nom d’utilisateur UserName | Le nom ou l’identifiant de l’utilisateur qui a effectué l’activité. | ||
| Description Cet attribut identifie le salarié ou l’utilisateur système responsable d’une étape donnée 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 d’identifier les besoins de formation, de comparer les performances des membres de l’équipe et de comprendre la répartition de la charge de travail. Elle est également essentielle aux contrôles de Conformité, afin de garantir une séparation appropriée des tâches. Pourquoi c’est important Il garantit la traçabilité et permet d’analyser les performances par personne ou par équipe, ce qui est essentiel à la gestion des Ressources et à la formation. Où les obtenir Il est associé aux enregistrements de l’historique du flux de travail ou de la piste d’audit dans Dynamics 365 HR. Il peut être relié au moyen d’un identifiant utilisateur provenant 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é, par exemple « Proposed », « Active », « Frozen » ou « Closed ». 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 « Position Compliance Review Status » et « Stale and Underutilized Positions ». Il fournit un aperçu de l’état actuel du poste et aide à valider le flux du 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ù les obtenir Consultez la documentation de Microsoft Dynamics 365 Human Resources. Cette information est probablement dérivée des champs de statut de l’enregistrement Position principal. Exemples ProposéEn cours d'examenActifGeléClôturé | |||
| Budget approuvé IsBudgetApproved | Un indicateur précisant 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 du processus et à identifier les postes bloqués dans l’attente d’un budget. Cet attribut peut servir à filtrer les processus et à analyser plus efficacement le KPI « Temps de cycle d’approbation du budget du poste ». Il permet de distinguer les postes ayant franchi l’étape budgétaire de ceux qui ne l’ont pas encore franchie, 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 une étape clé et en permettant d’isoler et de mesurer la phase d’approbation budgétaire. Où les obtenir Cette information est dérivée lors de la transformation des données, en vérifiant la présence de l’activité « Position Budget Approved » dans l’historique du cas. Exemples truefalse | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage de l’actualisation la plus récente des données provenant du système source. | ||
| Description Cet attribut indique la date de la dernière extraction des données depuis Microsoft Dynamics 365 Human Resources. Il fournit un contexte sur leur actualité. L’affichage de cette information dans les Dashboards garantit aux utilisateurs qu’ils consultent des informations à jour. Il s’agit d’un élément de métadonnées essentiel pour tout projet de Process Mining. Pourquoi c’est important Il informe les utilisateurs de l’actualité des données, un élément important pour prendre des décisions fondées sur l’analyse. Où les obtenir 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 | |||
| Durée du cycle d’approbation ApprovalCycleTime | Le temps total écoulé entre l’initiation d’une demande de poste et son approbation finale. | ||
| Description Cette mesure calculée évalue la durée entre l’activité « Position Request Initiated » et l’activité d’approbation finale, qui peut être « Position Request Approved By HR ». Il s’agit d’un indicateur clé de performance pour la phase initiale du processus de gestion des postes. Cet attribut alimente directement le Dashboard et le KPI « Position Approval Cycle Time ». Il fournit une mesure globale de l’efficacité du processus d’approbation et permet de suivre dans le temps l’impact des initiatives d’amélioration. Pourquoi c’est important Il s’agit d’un KPI essentiel pour mesurer l’efficacité de l’ensemble du processus d’approbation et mettre directement en évidence les retards qui empêchent de préparer les postes à leur création. Où les obtenir Cette durée est calculée au niveau du cas en recherchant les horodatages des activités de début et de fin de la phase d’approbation, puis en calculant l’écart entre les deux. Exemples P3DT2H15MP10DP1DT12HP5DT6HP2W | |||
| Est une reprise IsRework | Un indicateur précisant si une activité fait partie d’une boucle de reprise. | ||
| Description Cet indicateur booléen prend la valeur true lorsqu’une activité correspond à une étape répétée du processus, 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 « Position Rework Analysis » et le KPI « Rework Rate on Position Creation ». En identifiant les reprises, les analystes peuvent facilement filtrer et mesurer la fréquence ainsi que l’impact des inefficacités du processus. Pourquoi c’est important Il identifie et quantifie explicitement les reprises dans le processus, qui constituent une cible prioritaire des initiatives d’amélioration. Où les obtenir Cette information est calculée à partir de la séquence des activités d’un cas. Par exemple, si « Position Request Approved By Manager » intervient après « Position Attributes Modified », l’activité peut être identifiée comme une reprise. Exemples truefalse | |||
| Famille de métiers JobFamily | Un regroupement de métiers ayant des fonctions similaires, comme « Engineering » ou « Finance ». | ||
| Description La famille de métiers est une classification qui regroupe des intitulés de postes apparentés. Par exemple, « Software Engineer » et « QA Engineer » peuvent appartenir à la famille de métiers « Engineering ». Cet attribut est essentiel au Dashboard « Position Reclassification Trends », car il permet d’analyser à un niveau plus global les catégories de métiers qui évoluent le plus souvent. Il offre une vision plus large que l’analyse des seuls intitulés de postes. Pourquoi c’est important Il permet d’analyser les postes par catégorie à un niveau plus global, ce qui est utile à la planification stratégique des effectifs et à l’analyse des tendances. Où les obtenir Cette information fait partie de la configuration des métiers dans Dynamics 365 HR. Recherchez les champs associés à « Job family » ou « Job function » dans HcmJobEntity. Exemples IngénierieFinance et comptabilitéVentesRessources humainesGestion produit | |||
| Lieu Location | Le lieu physique ou géographique du poste. | ||
| Description Cet attribut précise 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 « Departmental Position Throughput » pour analyser les tendances d’effectifs et les performances du processus dans différentes régions. Il peut aider à déterminer si les processus de création ou d’approbation des postes sont plus lents dans certains lieux. Pourquoi c’est important Il fournit un contexte géographique et permet d’analyser les performances et les tendances du processus dans différents lieux. Où les obtenir Consultez la documentation de Microsoft Dynamics 365 Human Resources. Cette information peut faire partie des 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 | Le motif indiqué lorsqu’une demande de poste est rejetée. | ||
| Description Lorsqu’une demande de poste est rejetée par un responsable ou les RH, un motif est souvent enregistré. Il peut s’agir de contraintes budgétaires, d’informations incorrectes ou d’un changement de stratégie. Cet attribut est essentiel pour calculer le KPI « Position Request Rejection Rate » et comprendre les causes des reprises. L’analyse des motifs de rejet les plus fréquents permet d’identifier les problèmes en amont, comme la mauvaise qualité des demandes ou des consignes peu claires, afin d’améliorer le processus. Pourquoi c’est 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 taux de rejet. Où les obtenir Consultez la documentation de Microsoft Dynamics 365 Human Resources. Ces informations sont souvent enregistrées dans les commentaires du flux de travail ou dans un champ dédié de code motif lors du rejet. Exemples Budget indisponibleDemande en doubleProfil de poste incorrectGel des recrutementsRéorientation stratégique | |||
| Responsable demandeur RequestingManager | Le responsable qui a lancé la demande de création du poste. | ||
| Description Cet attribut identifie le responsable du recrutement ou le responsable de département qui a lancé le processus en demandant la création d’un nouveau poste ou le remplacement d’un poste vacant. Il indique l’origine du besoin en personnel. L’analyse par responsable demandeur peut faire apparaître des tendances concernant le volume des demandes, les taux d’approbation et la qualité des demandes. Elle apporte un niveau de détail supplémentaire pour comprendre la charge de travail et le respect du processus. Pourquoi c’est important Il permet de retracer l’origine de la demande de poste et d’analyser les indicateurs du processus du point de vue du responsable du recrutement. Où les obtenir Consultez la documentation de Microsoft Dynamics 365 Human Resources. Ces informations devraient probablement être enregistrées dans les données d’initiation 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 identifie l’origine des données du processus. Dans cette vue, il s’agirait généralement de « Microsoft Dynamics 365 Human Resources ». Dans les environnements qui utilisent plusieurs systèmes, ce champ est essentiel pour assurer la traçabilité des données et faciliter le dépannage. Il permet de confirmer que les données proviennent de la source attendue et peut servir à filtrer les analyses par système. Pourquoi c’est important Il fournit le contexte sur l’origine des données, ce qui est important pour la gouvernance des données et les analyses couvrant plusieurs systèmes d’entreprise. Où les obtenir Il s’agit d’une valeur statique ajoutée lors de l’extraction et de la transformation des données afin d’indiquer l’origine du jeu de données. Exemples Microsoft Dynamics 365 Human ResourcesD365 HRDynamicsHR | |||
| Type de poste PositionType | Classe le poste comme étant à temps plein, à temps partiel, temporaire, etc. | ||
| Description Cet attribut catégorise le poste selon ses conditions d’emploi. Il apporte un contexte supplémentaire à l’analyse et à la planification des effectifs. Dans l’analyse des processus, le filtrage par type de poste peut révéler que certains types de postes suivent des parcours différents ou présentent des délais de traitement plus longs. Par exemple, les postes temporaires peuvent suivre un processus d’approbation plus rapide et simplifié que les postes permanents à temps plein. Pourquoi c’est important Il permet d’analyser les différences du processus selon les types d’emploi, ce qui contribue à la planification des effectifs et à l’optimisation des processus. Où les obtenir Ces informations sont généralement disponibles dans l’enregistrement du poste de Dynamics 365 HR. Vérifiez la présence d’un champ approprié dans des entités telles que HcmPositionV2Entity. Exemples Temps pleinTemps partielPrestataireStagiaireTemporaire | |||
Hire to Retire, activités de la gestion des postes
| Activité | Description | ||
|---|---|---|---|
| Demande de poste approuvée par les RH | Signifie que l’approbation finale du service des ressources humaines a été obtenue avant la création officielle du poste. Il s’agit d’un événement explicite enregistré à l’achèvement de la tâche d’approbation RH dans le système de flux de travail. | ||
| Pourquoi c’est important Marque la fin de la phase d’approbation et constitue un jalon essentiel pour mesurer la durée moyenne globale du cycle d’approbation des postes. Où les obtenir Est enregistré dans les tables d’historique du flux de travail, telles que WorkflowTrackingTable, lorsque le représentant RH termine sa tâche d’approbation. Collecte L’événement est enregistré dans l’historique du flux de travail 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 officiel du cycle de vie de la gestion des postes. 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 c’est important Il s’agit du point de départ pour mesurer l’ensemble du cycle de vie du poste, notamment des KPI tels que la durée du cycle d’approbation du poste et le délai de création du poste. Où les obtenir Est 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 flux de travail, telle que WorkflowTrackingStatusTable. Collecte L’événement est enregistré lors de l’envoi d’un nouveau flux de travail 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 de la modification d’un champ de statut de l’enregistrement du poste, qui passe à « Active » ou à un état similaire. | ||
| Pourquoi c’est important Il s’agit d’un jalon essentiel pour mesurer la préparation au recrutement et l’efficacité des dernières étapes de configuration. Il est indispensable au KPI de délai moyen d’activation des postes. Où les obtenir Déduit du suivi de l’horodatage auquel le champ de statut, tel que « PositionStatus », de l’enregistrement du poste est mis à jour avec la valeur « Active » ou « Open ». Collecte Fondé sur la date à laquelle le champ ActivationDate du poste est renseigné ou à laquelle un champ de statut passe à « Active ». Type d’événement inferred | |||
| Poste clôturé | Représente l’archivage final de l’enregistrement du poste et marque la fin définitive de son cycle de vie. Cet événement est déduit d’une modification du statut vers « Closed » ou un état terminal similaire. | ||
| Pourquoi c’est important Il s’agit de l’événement terminal du processus. Il permet d’analyser l’ensemble du cycle de vie de bout en bout et d’identifier les postes obsolètes qui devraient être clôturés. Où les obtenir Déduit d’une modification d’un champ de statut vers « Closed » dans l’enregistrement du poste. Cet événement est moins fréquent que la désactivation, car les enregistrements sont souvent conservés à des fins historiques. Collecte Déduit de l’horodatage auquel un champ de statut est mis à jour avec la valeur « 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 capturé à partir de l’horodatage de création de l’enregistrement principal du poste. | ||
| Pourquoi c’est important Jalon fondamental, il signale le passage de la demande à une entité organisationnelle réelle. Il constitue le point final du KPI de délai de création du poste. Où les obtenir À partir du champ système « CreatedDateTime » de la table principale des postes, telle que HcmPosition. Collecte 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 d’une modification du statut vers « Inactive » ou un état similaire. | ||
| Pourquoi c’est important Marque une étape importante à la fin de la période d’activité du poste. Elle est essentielle pour analyser le délai moyen de désactivation des postes et gérer précisément les effectifs. Où les obtenir Déduit de l’horodatage auquel le champ « RetirementDate » est renseigné ou auquel un champ de statut de l’enregistrement du poste passe à « Inactive ». Collecte Fondé sur la date à laquelle le champ RetirementDate du poste est renseigné ou à laquelle un champ de statut passe à « Inactive ». 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 l’intitulé ou le service, après sa création initiale. Cette activité est généralement déduite du suivi des 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 révéler une mauvaise qualité des données ou des reprises dans le processus. Elle est essentielle pour les KPI de fréquence de modification des attributs des postes et de taux de reprise. Où les obtenir Déduit de la table SysDatabaseLog si le suivi des modifications est activé pour la table des postes. À défaut, il faut comparer des instantanés historiques des données des postes. Collecte Déduit de la détection des opérations de mise à jour sur les champs clés de la table HcmPosition au moyen du journal de la base de données. Type d’événement inferred | |||
| Budget du poste approuvé | Constitue une étape importante de l’approbation, confirmant que les fonds nécessaires sont affectés au nouveau poste. Cet événement est généralement enregistré comme une étape d’approbation distincte dans le flux de travail de création du poste. | ||
| Pourquoi c’est important Isole l’étape d’approbation financière, ce qui permet d’analyser les retards liés à l’allocation budgétaire et d’alimenter le KPI de durée du cycle d’approbation du budget du poste. Où les obtenir Est enregistré dans les tables d’historique du flux de travail, telles que WorkflowTrackingTable, comme une tâche d’approbation terminée, souvent attribuée à une fonction financière. Collecte Est capturé à partir de l’horodatage d’achèvement de la tâche d’approbation budgétaire dans le journal du flux de travail. Type d’événement explicit | |||
| Demande de poste approuvée par le responsable | Représente l’achèvement de la première ligne d’approbation par le responsable du recrutement. Cet événement est explicitement enregistré dans l’historique du flux de travail lorsque le responsable termine la tâche d’approbation qui lui a été attribuée. | ||
| Pourquoi c’est important Permet de mesurer la durée de l’étape d’approbation initiale et d’identifier les goulots d’étranglement associés à certains responsables ou services. Où les obtenir Est enregistré comme une étape terminée dans les tables d’historique du flux de travail, telles que WorkflowTrackingTable, associées à la demande de poste. Collecte Est capturé à partir de l’horodatage d’achèvement 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 explicitement enregistré dans l’historique du flux de travail lorsqu’un approbateur sélectionne l’action « Rejeter ». | ||
| Pourquoi c’est important Met en évidence les défaillances du processus et les boucles de reprise. L’analyse des motifs de rejet contribue à améliorer la qualité des demandes initiales et alimente le KPI du taux de rejet des demandes de poste. Où les obtenir Est enregistré avec le statut « Rejet » dans les tables d’historique du flux de travail, telles que WorkflowTrackingStatusTable, pour la demande de poste concernée. Collecte Est capturé dans le journal du flux de travail lorsqu’un approbateur exécute l’action de rejet. Type d’événement explicit | |||
| Poste contrôlé au regard de la Conformité | Indique qu’un poste a fait l’objet d’un contrôle formel de Conformité. Cet événement peut être capturé par une modification de statut, l’achèvement d’une tâche de checklist ou la mise à jour d’un champ personnalisé. | ||
| Pourquoi c’est important Essentiel pour suivre le respect des politiques réglementaires et internes, cet événement alimente directement le KPI du taux de respect des exigences de Conformité des postes. Où les obtenir Probablement déduit d’un champ de statut horodaté tel que « ComplianceReviewStatus » ou d’un champ booléen « IsComplianceReviewed » dans l’enregistrement du poste. Collecte Déduit de l’horodatage auquel un champ de statut de Conformité est mis à jour avec la valeur « Completed » ou « Reviewed ». Type d’événement inferred | |||
| Poste gelé | Indique qu’un poste a été temporairement suspendu, ce qui empêche toute activité de recrutement. Cet événement est capturé en déduisant une modification du statut de l’enregistrement du poste vers l’état « Frozen » ou « On Hold ». | ||
| Pourquoi c’est important Suit les interruptions du cycle de vie du poste, qui peuvent avoir une incidence sur les plans d’effectifs et les budgets. Il aide à identifier les causes des retards de recrutement. Où les obtenir Déduit du suivi de l’horodatage auquel un champ de statut de l’enregistrement du poste est mis à jour avec la valeur « Frozen » ou une valeur similaire. Collecte Déduit de l’horodatage d’une modification du statut vers « Frozen » ou « On Hold ». Type d’événement inferred | |||
| Poste reclassifié | Mise à jour importante au cours de laquelle la classification fondamentale du poste, comme sa famille d’emplois ou son niveau, est modifiée. Cet événement est généralement déduit d’une modification du champ « Job » dans l’enregistrement du poste. | ||
| Pourquoi c’est important Aide à analyser les changements de structure organisationnelle et la stabilité des définitions de postes. Il s’agit de l’activité clé du KPI de taux de reclassification des postes. Où les obtenir Déduit d’une modification du champ « JobId » dans la table HcmPosition, capturée par le journal de la base de données ou par la comparaison des versions de l’enregistrement au fil du temps. Collecte Déduit d’une modification enregistrée du champ de classification de l’emploi dans l’enregistrement du poste. Type d’événement inferred | |||
| Processus de recrutement démarré | Signale le transfert de la gestion du poste vers le recrutement. Cet événement est déduit lorsqu’un nouveau poste vacant ou un projet de recrutement est créé et associé à l’identifiant de ce poste. | ||
| Pourquoi c’est 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ù les obtenir Déduit de la date de création d’un enregistrement dans les tables de recrutement ou de postes vacants, telles que HcmRecruitingRequest, qui fait référence au Position ID. Collecte Déduit de l’association du PositionId avec 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 « Gestion des données ».
- Créez un nouveau projet d’exportation : Dans cet espace de travail, sélectionnez la vignette « Exportation ». Sur la page du projet « Exportation », cliquez sur « Nouveau » pour créer un projet. Saisissez un nom explicite, par exemple « PositionManagement_EventLog_Export », puis sélectionnez un format de données. Pour la transformation, le format « CSV » est recommandé.
- Ajoutez les entités de données au projet : Dans votre nouveau projet, cliquez sur « Ajouter une entité ». Vous devez ajouter plusieurs entités afin de couvrir l’ensemble du cycle de vie du poste. Ajoutez successivement les entités clés suivantes : « HcmPositionV2 », « WorkflowTrackingStatusTable » et « HcmRecruitingRequest ». Si la journalisation des modifications de poste est activée dans la base de données, ajoutez également « SysDatabaseLog ».
- Configurez les filtres des entités : Pour chaque entité, il est essentiel d’appliquer des filtres afin de limiter le périmètre des données. Sélectionnez une entité, puis cliquez sur « Filtrer ». Pour « HcmPositionV2 », filtrez selon une période donnée à l’aide des champs « CreatedDateTime » ou « ModifiedDateTime ». Pour « WorkflowTrackingStatusTable », filtrez « CONTEXTTABLENAME » afin d’inclure uniquement les flux de travail liés aux postes.
- Sélectionnez les champs de chaque entité : Vérifiez que vous exportez tous les champs nécessaires à la transformation ultérieure. Pour « HcmPositionV2 », incluez « PositionId », « CreatedDateTime », « ActivationDate », « RetirementDate », « ModifiedDateTime », « JobId » et « DepartmentNumber ». Pour « WorkflowTrackingStatusTable », incluez « ContextRecId », « WorkflowTrackingStatus », « CreatedDateTime » et « UserId ».
- Exécutez la tâche d’exportation : Une fois toutes les entités, tous les champs et tous les filtres configurés, cliquez sur « Exporter » sur la page principale du projet. Le système crée un package de données contenant un fichier distinct pour chaque entité.
- Suivez l’avancement et téléchargez le package de données : Vous pouvez suivre l’avancement 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 se présente sous la forme d’un fichier 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 utiliser un script externe, par exemple en Python avec pandas ou PowerShell, pour traiter ces fichiers.
- Mettez en œuvre la logique de transformation : Votre script doit effectuer les opérations suivantes :
- Chargez le fichier « HcmPositionV2.csv ». À partir de ce fichier, 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 clôturé ») en interprétant les champs de statut ou les champs de date tels que « ActivationDate » et « RetirementDate » de « HcmPositionV2.csv ».
- Chargez le fichier « WorkflowTrackingStatusTable.csv ». Associez ces données aux données des postes à l’aide de l’identifiant de l’enregistrement. Générez ensuite les événements du flux de travail : « 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 devez associer le statut du flux de travail et le contexte de l’étape au nom d’activité approprié.
- Si vous avez exporté « SysDatabaseLog.csv », analysez ce fichier pour générer les événements « Attributs du poste modifiés » et « Poste reclassifié » à partir des modifications apportées à certains champs de la table HcmPosition.
- Chargez « HcmRecruitingRequest.csv » pour générer l’événement « Processus de recrutement démarré » en identifiant la date de création d’une demande de recrutement pour un poste donné.
- Assemblez le journal d’événements final : Le script doit regrouper tous les événements générés à partir des différentes sources dans un seul fichier CSV. Ce fichier doit contenir les colonnes obligatoires « PositionId », « ActivityName » et « EventTime », ainsi que tous les attributs recommandés que vous avez pu associer.
- Préparez le fichier pour 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 maintenant prêt à être importé dans l’outil de Process Mining.
Configuration
- Entités de données clés : 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 démarré » lorsqu’une demande de recrutement est associée à un poste.SysDatabaseLog: entité facultative, mais utile pour enregistrer des modifications détaillées telles que « 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 période : Il est vivement recommandé d’appliquer un filtre de période à l’entité « HcmPositionV2 » à 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 maîtrisable.
- Exportations incrémentielles : Pour une analyse continue, envisagez de configurer le projet d’exportation afin d’effectuer 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 : L’utilisateur qui exécute l’exportation doit disposer d’un rôle de sécurité lui accordant 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 indiquées. Des rôles tels que « Administrateur de la gestion des données » ou un rôle personnalisé doté de privilèges spécifiques sur les entités sont généralement nécessaires.
a 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 de 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 les suivantes :
HcmPositionV2,HcmPositionDetail,WorkflowTrackingStatusTable,HcmJob,OMOperatingUnitetHcmRecruitingRequest. - Connectez-vous à la base de données Azure SQL : 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.
- Identifiez 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 de la base BYOD peuvent ne pas correspondre exactement aux noms des entités, même s’ils sont généralement très proches.
- 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 précise, par exemple « USMF », que vous souhaitez analyser. Ajustez la période dans les clausesWHERE, par exempleCREATEDDATETIME >= '2023-01-01', afin de limiter l’extraction à la période souhaitée. - Exécutez la requête : Lancez la requête SQL complète sur la base BYOD. La durée d’exécution varie selon le volume de données et la période sélectionnée.
- Examinez 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 champs sont renseignées comme prévu. - Exportez au format CSV : Exportez l’ensemble des résultats dans un fichier CSV. La plupart des clients SQL proposent une fonction intégrée permettant d’enregistrer directement les résultats au format CSV. Dans SSMS, par exemple, cliquez avec le bouton droit de la souris sur la grille de résultats, puis sélectionnez « Save Results As... ».
- Préparez l’importation : Vérifiez que le fichier CSV exporté utilise l’encodage UTF-8. Confirmez que les en-têtes de colonnes correspondent exactement aux attributs requis (
PositionId,ActivityName,EventTime, etc.) afin de faciliter l’importation 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 de Dynamics 365 HR vers votre instance BYOD. Les entités essentielles pour ce processus couvrent notamment 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 : Gardez à l’esprit que BYOD assure une réplication quasi temps réel, et non instantanée. Un léger délai, de quelques minutes à une heure, peut s’écouler entre une transaction effectuée dans D365 HR et l’apparition des données dans la base de données Azure SQL.
- Filtrage par période : Il est essentiel d’appliquer des filtres de date à votre requête afin de maîtriser les performances et le volume de données. Une période de 3 à 6 mois constitue généralement un bon point de départ. Appliquez les filtres aux horodatages de création ou d’événement dans chaque bloc
UNION ALL. - Filtre par entreprise : Filtrez toujours selon « DATAREAID », c’est-à-dire l’identifiant de l’entité juridique ou de l’entreprise, afin de vous assurer que vous analysez les données de la bonne unité organisationnelle. La requête fournie contient l’espace réservé
@[YourCompanyId]à cette fin. - 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é à 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, tels que « Approve position request ». Si votre organisation utilise des noms personnalisés pour ces étapes, 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]'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 Hire to Retire, gestion des postes. Commencez dès aujourd’hui à améliorer votre efficacité et votre conformité.
Optimisez instantanément la gestion des postes Hire to Retire
Réduisez de 30 % la durée de votre processus et éliminez les goulots d’étranglement.
Aucune carte bancaire requise. Configuration en quelques minutes.