Ihr Daten-Template für Hire to Retire: Stellenverwaltung
Ihr Daten-Template für Hire to Retire: Stellenverwaltung
- Empfohlene Attribute für eine umfassende Analyse
- Wichtige Prozessaktivitäten für eine präzise Analyse
- Hinweise zum Datenexport aus Microsoft Dynamics 365 Human Resources
Hire to Retire: Attribute der Stellenverwaltung
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der Name des konkreten Events oder der Aufgabe im Prozess des Stellenmanagements. | ||
| Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt im Lebenszyklus einer Stelle, zum Beispiel „Stellenantrag eingeleitet“, „Stelle im HR-System erstellt“ oder „Stelle deaktiviert“. Es bildet die Grundlage der Prozesslandkarte und zeigt die Reihenfolge der Events. Anhand des Aktivitätsnamens lassen sich Prozessabläufe visualisieren, Abweichungen vom Standardprozess erkennen und Übergangszeiten zwischen den einzelnen Schritten berechnen. Das Attribut ist entscheidend, um zu verstehen, was geschehen ist und in welcher Reihenfolge. Warum das wichtig ist Das Attribut definiert die Prozessschritte. So lassen sich Prozesslandkarten visualisieren und Prozessabläufe sowie Varianten analysieren. Woher beziehen Dieses Attribut wird aus Geschäftsevents, Statusänderungen oder dem Workflow-Verlauf in Microsoft Dynamics 365 Human Resources abgeleitet. Es entspricht keinem einzelnen Feld, sondern wird aus dem jeweiligen Datenkontext gebildet. Beispiele Stellenantrag eingeleitetStellenantrag von der Führungskraft freigegebenStelle im HR-System erstelltStellenattribute geändertStelle geschlossen | |||
| Event-Zeitpunkt EventTime | Der Zeitstempel, der angibt, wann die Aktivität stattgefunden hat. | ||
| Beschreibung Der Event-Zeitpunkt, also der Zeitstempel, erfasst das genaue Datum und die Uhrzeit, zu denen eine Aktivität abgeschlossen wurde. Er ist entscheidend, um Events chronologisch zu ordnen und Dauer sowie Zykluszeiten zu berechnen. Dieses Attribut kommt in nahezu jeder Process-Mining-Analyse zum Einsatz, von der Erstellung der Prozesslandkarte bis zur Berechnung von Leistungs-KPIs wie der „durchschnittlichen Freigabezykluszeit für Stellen“. Es zeigt, wann Verzögerungen auftreten und wie lange die einzelnen Prozessschritte dauern. Warum das wichtig ist Dieser Zeitstempel ist unverzichtbar, um Events zu ordnen, alle zeitbasierten Kennzahlen zu berechnen und Prozessengpässe aufzudecken. Woher beziehen Diese Information findet sich üblicherweise in Systemprotokolltabellen oder in den Feldern „CreatedDateTime“ und „ModifiedDateTime“ der Stellen- und Workflow-Datensätze in Dynamics 365 HR. Beispiele 2023-04-15T09:00:00Z2023-04-15T14:35:10Z2023-04-18T11:21:05Z2023-05-02T16:45:00Z2024-01-10T10:00:00Z | |||
| Stellen-ID PositionId | Die eindeutige Kennung einer bestimmten Stelle innerhalb der Organisation. | ||
| Beschreibung Die Stellen-ID dient als primäre Case-ID und verknüpft alle Aktivitäten und Datenpunkte zu einer einzelnen Stelle in der Organisation. Damit lässt sich der gesamte Lebenszyklus einer Stelle von der Erstellung und Änderung bis zur Deaktivierung oder Schließung verfolgen. Für die Prozessanalyse ist diese ID unverzichtbar, um den Ablauf jeder Stelle zu rekonstruieren. Sie ermöglicht Dashboards zur Überwachung von Zykluszeiten, zur Erkennung von Engpässen bei Freigaben und zur Analyse von Prozessvarianten vom Antrag bis zur Schließung. Warum das wichtig ist Diese zentrale Kennung verknüpft alle zugehörigen Events zu einem einzelnen Prozess-Case. So lässt sich der Lebenszyklus einer Stelle von Anfang bis Ende analysieren. Woher beziehen In Microsoft Dynamics 365 Human Resources ist dies üblicherweise das Feld HcmPosition.PositionId. Es ist in Datenentitäten wie HcmPositionV2Entity zu finden. Beispiele POS001234MKT-0056FIN-SR-ANALYST-02HRBP-EAST-01IT-DEV-9876 | |||
| Abteilung DepartmentName | Die Abteilung, der die Position zugeordnet ist. | ||
| Beschreibung Dieses Attribut gibt die organisatorische Abteilung an, der die Position zugeordnet ist, zum Beispiel „Finanzen“, „Marketing“ oder „IT“. Es ist eine zentrale Dimension, um Prozessdaten zu filtern und zusammenzufassen. Die Analyse nach Abteilungen ist für das Dashboard „Durchsatz von Positionen nach Abteilung“ unverzichtbar. Sie ermöglicht den Vergleich der Prozessleistung, zeigt abteilungsspezifische Engpässe auf und macht Einstellungstrends in verschiedenen Unternehmensbereichen sichtbar. Warum das wichtig ist Damit lässt sich der Prozess nach Geschäftseinheit analysieren. So können Sie abteilungsspezifische Probleme erkennen und die Leistung vergleichen. Woher beziehen Diese Information ist Teil der Positionsdetails. Sie wird in der Regel in der Entität HcmPositionDetail gespeichert und mit der Dimension der operativen Einheit verknüpft. Beispiele FinanzenInformationstechnologieVertrieb und MarketingPersonalwesenBetrieb | |||
| Benutzername UserName | Der Name oder die ID des Benutzers, der die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut gibt an, welcher Mitarbeiter oder Systembenutzer für einen Prozessschritt verantwortlich war, etwa der Manager, der eine Anforderung genehmigt hat, oder der HR-Spezialist, der die Position im System angelegt hat. Die Analyse nach Benutzern hilft dabei, Schulungsbedarf zu erkennen, die Leistung von Teammitgliedern zu vergleichen und die Arbeitslast zu verstehen. Sie ist außerdem wichtig für Compliance-Prüfungen, bei denen die ordnungsgemäße Funktionstrennung sichergestellt werden soll. Warum das wichtig ist Das Attribut schafft Verantwortlichkeit und ermöglicht Leistungsanalysen für einzelne Personen oder Teams. Beides ist für Ressourcenplanung und Schulungen wichtig. Woher beziehen Das Attribut ist mit dem Workflow-Verlauf oder Audit-Trail-Einträgen in Dynamics 365 HR verknüpft. Die Zuordnung kann über eine User ID aus der Entität HcmWorker erfolgen. Beispiele John SmithJane DoeSYSTEMHRAdmin01MGR-FINANCE | |||
| Endzeit EndTime | Der Zeitstempel, der angibt, wann die Aktivität abgeschlossen wurde. | ||
| Beschreibung EndTime kennzeichnet den Abschluss einer Aktivität. Die Zeitspanne zwischen StartTime und EndTime entspricht der Verarbeitungszeit dieser Aktivität. Dieses Attribut ist wichtig, um die Dauer einzelner Aktivitäten zu berechnen und zu erkennen, wofür im Prozess Zeit aufgewendet wird. So lässt sich beispielsweise ermitteln, wie lange ein Manager für die Genehmigung einer Positionsanforderung benötigt, nachdem sie ihm zugewiesen wurde. Warum das wichtig ist Damit lassen sich die Verarbeitungszeiten einzelner Aktivitäten berechnen. Das ist eine wichtige Grundlage für detaillierte Leistungs- und Engpassanalysen. Woher beziehen Dieser Wert lässt sich aus den Zeitstempeln nachfolgender Ereignisse oder aus bestimmten Abschlussfeldern in den Workflow-Protokollen von Dynamics 365 HR ableiten. Häufig muss er jedoch erschlossen werden. Beispiele 2023-04-15T09:05:12Z2023-04-15T15:00:00Z2023-04-19T09:00:00Z2023-05-03T10:00:00Z2024-01-10T10:05:00Z | |||
| Kostenstelle CostCenter | Die finanzielle Kostenstelle, der die Ausgaben für die Position zugeordnet werden. | ||
| Beschreibung Die Kostenstelle ist eine wichtige Finanzdimension, die eine Position einem bestimmten Budget oder Verantwortungsbereich zuordnet. Änderungen an diesem Attribut sollten überwacht werden. Das Attribut ist entscheidend für das Dashboard „Konsistenzprüfung von Positionsdaten“, das Änderungen an wichtigen Attributen nach dem Anlegen der Position analysiert. Außerdem dient es dazu, positionsbezogene Kosten und Budgets nach verschiedenen Finanzbereichen auszuwerten. Warum das wichtig ist Das Attribut verknüpft die Position mit Finanzdaten. So können Sie kostenbezogene Prozesse analysieren und die Datenkonsistenz überwachen. Woher beziehen Dieses Attribut wird in der Regel als Finanzdimension im Positionsdatensatz konfiguriert. Prüfen Sie die Einrichtung der Finanzdimensionen in Dynamics 365. Beispiele CC-1001-FINCC-2500-ITCC-4510-SALESCC-7000-OPSCC-9002-HR | |||
| Positionsstatus PositionStatus | Der aktuelle oder historische Status der Position. | ||
| Beschreibung Dieses Attribut gibt den Status der Position zu einem bestimmten Zeitpunkt an, zum Beispiel „Vorgeschlagen“, „Aktiv“, „Eingefroren“ oder „Geschlossen“. Statusänderungen entsprechen häufig Aktivitäten im Prozess. Die Statusverfolgung ist wichtig, um den Verlauf einer Position nachzuvollziehen und Dashboards wie „Prüfstatus der Positions-Compliance“ und „Veraltete und nicht ausgelastete Positionen“ auszuwerten. Sie zeigt den aktuellen Status der Position und hilft, den Prozessablauf zu überprüfen. Warum das wichtig ist Das Attribut zeigt den Status jeder Position eindeutig an. So lassen sich Cases filtern und Ergebnisse nachvollziehen. Woher beziehen Lesen Sie die Dokumentation zu Microsoft Dynamics 365 Human Resources. Der Wert wird wahrscheinlich aus Statusfeldern des zentralen Position-Datensatzes abgeleitet. Beispiele VorgeschlagenIn PrüfungAktivEingefrorenGeschlossen | |||
| Stellenbezeichnung JobTitle | Die Bezeichnung der Stelle, die der Position zugeordnet ist, zum Beispiel „Senior Accountant“. | ||
| Beschreibung Die Stellenbezeichnung liefert wichtige Informationen zu Rolle und Aufgaben der Position. Sie unterscheidet sich von der Positions-ID, da mehrere Positionen dieselbe Stellenbezeichnung haben können. In Analysen können Sie mit diesem Attribut nach Rollentyp gruppieren und filtern. Im Dashboard „Trends bei Positionsneuzuordnungen“ lässt sich damit beispielsweise erkennen, welche Stellen am häufigsten neu zugeordnet werden. Warum das wichtig ist Das Attribut liefert wichtigen geschäftlichen Kontext und ermöglicht Analysen nach Rolle, Ebene oder Funktion. Woher beziehen Diese Information wird aus dem mit der Position verknüpften Datensatz „Job“ übernommen. Suchen Sie in Entitäten wie HcmPositionV2Entity danach oder verknüpfen Sie die Daten mit HcmJobEntity. Beispiele Senior-FinanzanalystSoftwareentwickler IIHR Business PartnerMarketingkoordinatorLogistikmanager | |||
| Ablehnungsgrund RejectionReason | Der angegebene Grund für die Ablehnung einer Positionsanforderung. | ||
| Beschreibung Wenn ein Manager oder die Personalabteilung eine Positionsanforderung ablehnt, wird häufig ein Grund erfasst. Mögliche Gründe sind Budgetbeschränkungen, fehlerhafte Angaben oder eine geänderte Strategie. Dieses Attribut ist wichtig, um die KPI „Ablehnungsquote von Positionsanforderungen“ zu berechnen und die Ursachen für Nacharbeit zu verstehen. Die häufigsten Ablehnungsgründe können auf vorgelagerte Probleme hinweisen, etwa auf unzureichende Angaben in der Anforderung oder unklare Richtlinien. Diese Probleme lassen sich gezielt angehen, um den Prozess zu verbessern. Warum das wichtig ist Das Attribut zeigt direkt, warum Anforderungen scheitern. So können Sie gezielte Prozessverbesserungen umsetzen und Nacharbeit sowie Ablehnungen reduzieren. Woher beziehen Lesen Sie die Dokumentation zu Microsoft Dynamics 365 Human Resources. Der Grund wird häufig in Workflow-Kommentaren oder bei der Ablehnung in einem eigenen Feld für den Ablehnungscode erfasst. Beispiele Budget nicht verfügbarDoppelte AnforderungFalsches StellenprofilEinstellungsstoppStrategische Neuausrichtung | |||
| Anfordernder Manager RequestingManager | Der Manager, der die Anforderung für die Position gestellt hat. | ||
| Beschreibung Dieses Attribut gibt an, welcher Einstellungsmanager oder Abteilungsleiter den Prozess mit der Anforderung einer neuen oder nachzubesetzenden Position gestartet hat. So wird sichtbar, woher der Bedarf an Positionen kommt. Die Analyse nach anforderndem Manager kann Muster beim Anforderungsvolumen, bei Genehmigungsquoten und bei der Qualität der Anforderungen aufzeigen. Sie liefert zusätzliche Details zur Arbeitslast und zur Einhaltung des Prozesses. Warum das wichtig ist Damit lässt sich nachvollziehen, woher der Bedarf an Positionen kommt, und es können Prozesskennzahlen aus Sicht des Einstellungsmanagers analysiert werden. Woher beziehen Lesen Sie die Dokumentation zu Microsoft Dynamics 365 Human Resources. Diese Information wird wahrscheinlich in den Daten zur Workflow-Initialisierung erfasst. Beispiele Robert JonesSusan MillerDavid ChenMaria GarciaPaul Williams | |||
| Berufsfamilie JobFamily | Eine Gruppe von Berufen mit ähnlichen Aufgaben, zum Beispiel „Ingenieurwesen“ oder „Finanzen“. | ||
| Beschreibung Eine Berufsfamilie fasst verwandte Stellenbezeichnungen zusammen. So können beispielsweise „Softwareentwickler“ und „QA Engineer“ zur Berufsfamilie „Ingenieurwesen“ gehören. Dieses Attribut ist für das Dashboard „Trends bei Positionsneuzuordnungen“ wichtig, da es eine übergeordnete Analyse ermöglicht: Welche Berufskategorien ändern sich am häufigsten? So erhalten Sie einen umfassenderen Überblick als bei der Betrachtung einzelner Stellenbezeichnungen. Warum das wichtig ist Das Attribut ermöglicht eine übergeordnete Analyse von Positionen nach Kategorien. Das ist für die strategische Personalplanung und die Trendanalyse hilfreich. Woher beziehen Die Berufsfamilie ist Teil der Jobeinrichtung in Dynamics 365 HR. Suchen Sie in HcmJobEntity nach Feldern wie „Job family“ oder „Job function“. Beispiele IngenieurwesenFinanzen und RechnungswesenVertriebPersonalwesenProduktmanagement | |||
| Beschäftigungsart PositionType | Ordnet die Position als Vollzeit, Teilzeit, befristet und Ähnliches ein. | ||
| Beschreibung Dieses Attribut kategorisiert die Position nach den Beschäftigungsbedingungen. Es liefert zusätzlichen Kontext für Personalanalysen und die Personalplanung. In der Prozessanalyse kann die Filterung nach Beschäftigungsart zeigen, ob bestimmte Positionen andere Prozesspfade oder längere Zykluszeiten haben. Für befristete Positionen kann beispielsweise ein schnellerer, vereinfachter Genehmigungsprozess gelten als für unbefristete Vollzeitstellen. Warum das wichtig ist Damit können Sie analysieren, wie sich der Prozess je nach Beschäftigungsart unterscheidet. Das unterstützt die Personalplanung und Prozessoptimierung. Woher beziehen Diese Information ist in der Regel im Positionsdatensatz in Dynamics 365 HR verfügbar. Prüfen Sie, ob Entitäten wie HcmPositionV2Entity ein entsprechendes Feld enthalten. Beispiele VollzeitTeilzeitAuftragnehmerPraktikantBefristet | |||
| Budget genehmigt IsBudgetApproved | Kennzeichen dafür, ob das Budget für die Position genehmigt wurde. | ||
| Beschreibung Dieses boolesche Attribut ist „true“, wenn die Aktivität „Positionsbudget genehmigt“ für einen Positions-Case stattgefunden hat. Es hilft bei der Analyse des Prozessablaufs und zeigt Positionen, die auf eine Budgetfreigabe warten. Mit diesem Attribut können Sie Prozesse filtern und die KPI „Genehmigungszykluszeit für Positionsbudgets“ gezielter analysieren. Es unterscheidet Positionen, deren Budget genehmigt wurde, von solchen, bei denen die Genehmigung noch aussteht. Das ist für die Engpassanalyse hilfreich. Warum das wichtig ist Das Attribut kennzeichnet einen wichtigen Meilenstein eindeutig und vereinfacht so die Analyse der Budgetgenehmigungsphase. Woher beziehen Der Wert wird bei der Datentransformation abgeleitet, indem geprüft wird, ob die Aktivität „Positionsbudget genehmigt“ im Verlauf des Cases vorkommt. Beispiele truefalse | |||
| Genehmigungszykluszeit ApprovalCycleTime | Die Gesamtzeit vom Start einer Positionsanforderung bis zu ihrer endgültigen Genehmigung. | ||
| Beschreibung Diese berechnete Kennzahl misst die Zeitspanne zwischen der Aktivität „Positionsanforderung gestartet“ und der abschließenden Genehmigungsaktivität, zum Beispiel „Positionsanforderung von der Personalabteilung genehmigt“. Sie ist eine wichtige Leistungskennzahl für die Anfangsphase des Positionsmanagements. Dieses Attribut fließt direkt in das Dashboard und die KPI „Genehmigungszykluszeit für Positionen“ ein. Es misst die Effizienz des Genehmigungsprozesses auf übergeordneter Ebene und zeigt, wie sich Verbesserungsmaßnahmen im Zeitverlauf auswirken. Warum das wichtig ist Diese wichtige KPI misst die Effizienz des gesamten Genehmigungsprozesses und macht Verzögerungen sichtbar, bevor Positionen angelegt werden können. Woher beziehen Die Berechnung erfolgt auf Case-Ebene. Dazu werden die Zeitstempel der Start- und Endaktivitäten der Genehmigungsphase ermittelt und voneinander abgezogen. Beispiele P3DT2H15MP10DP1DT12HP5DT6HP2W | |||
| Ist Nacharbeit IsRework | Kennzeichen dafür, ob eine Aktivität Teil einer Nacharbeitsschleife ist. | ||
| Beschreibung Dieses boolesche Kennzeichen wird auf „true“ gesetzt, wenn ein Prozessschritt wiederholt wird, zum Beispiel eine erneute Genehmigung nach einer Änderung von Attributen. So lässt sich die Ineffizienz wiederholter Prozessschritte quantifizieren. Das Attribut unterstützt direkt das Dashboard „Nacharbeitsanalyse für Positionen“ und die KPI „Nacharbeitsquote bei der Erstellung von Positionen“. Wenn Nacharbeit gekennzeichnet ist, können Analysten die Häufigkeit und Auswirkungen ineffizienter Prozessabläufe einfach filtern und messen. Warum das wichtig ist Das Attribut kennzeichnet und quantifiziert Nacharbeit im Prozess. Damit wird ein zentrales Ziel von Prozessverbesserungsinitiativen messbar. Woher beziehen Der Wert wird anhand der Aktivitätsfolge eines Cases berechnet. Tritt beispielsweise „Positionsanforderung vom Manager genehmigt“ nach „Positionsattribute geändert“ auf, kann dies als Nacharbeit gekennzeichnet werden. Beispiele truefalse | |||
| Letzte Datenaktualisierung LastDataUpdate | Zeitstempel der letzten Datenaktualisierung aus dem Quellsystem. | ||
| Beschreibung Dieses Attribut gibt an, wann die Daten zuletzt aus Microsoft Dynamics 365 Human Resources extrahiert wurden. So lässt sich die Aktualität der Analyse einordnen. Wer diese Information in Dashboards anzeigt, kann sicherstellen, dass Benutzer aktuelle Daten sehen. Sie gehört zu den wichtigsten Metadaten eines Process-Mining-Projekts. Warum das wichtig ist Die Information zeigt Benutzern, wie aktuell die Daten sind. Das ist entscheidend, wenn Entscheidungen auf Grundlage der Analyse getroffen werden. Woher beziehen Dieser Zeitstempel wird während des ETL-Prozesses (Extraktion, Transformation und Laden) erzeugt und gespeichert. Beispiele 2024-05-21T02:00:00Z2024-05-20T02:00:00Z2024-05-19T02:00:00Z | |||
| Quellsystem SourceSystem | Das System, aus dem die Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut gibt an, woher die Prozessdaten stammen. In dieser Ansicht ist dies üblicherweise „Microsoft Dynamics 365 Human Resources“. In Umgebungen mit mehreren Systemen ist dieses Feld wichtig für die Datenherkunft und die Fehlerbehebung. Es hilft zu bestätigen, dass die Daten aus der erwarteten Quelle stammen, und ermöglicht es, Analysen auf bestimmte Systeme zu beschränken. Warum das wichtig ist Das Attribut gibt Aufschluss über die Herkunft der Daten. Das ist wichtig für die Data Governance und für Analysen, die mehrere Unternehmenssysteme umfassen. Woher beziehen Dies ist ein statischer Wert, der während der Datenextraktion und -transformation hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Microsoft Dynamics 365 Human ResourcesD365 HRDynamicsHR | |||
| Standort Location | Der physische oder geografische Standort der Position. | ||
| Beschreibung Dieses Attribut gibt an, wo die Position angesiedelt ist, zum Beispiel in einem Büro, einer Stadt oder einem Land. Es ist eine weitere wichtige Dimension, um Prozessdaten zu filtern und aufzuschlüsseln. Das Dashboard „Durchsatz von Positionen nach Abteilung“ verwendet den Standort, um Personaltrends und Prozessleistung in verschiedenen Regionen zu analysieren. So lässt sich feststellen, ob das Anlegen oder Genehmigen von Positionen an bestimmten Standorten länger dauert. Warum das wichtig ist Das Attribut liefert geografischen Kontext und ermöglicht Analysen der Prozessleistung und Trends an verschiedenen Standorten. Woher beziehen Lesen Sie die Dokumentation zu Microsoft Dynamics 365 Human Resources. Der Standort kann Teil der Positionsdetails sein oder über die Abteilung beziehungsweise die juristische Person verknüpft werden. Beispiele New York, USALondon, Vereinigtes KönigreichBerlin, DeutschlandSingapurRemote | |||
Hire to Retire: Aktivitäten der Stellenverwaltung
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Stelle aktiviert | Kennzeichnet den Zeitpunkt, zu dem eine Stelle offiziell ausgeschrieben werden kann und die Personalsuche beginnt. Dieses Event wird aus einer Änderung des Statusfelds im Stellendatensatz auf „Aktiv“ oder einen ähnlichen Status abgeleitet. | ||
| Warum das wichtig ist Ein wichtiger Meilenstein zur Messung der Besetzungsbereitschaft und der Effizienz der abschließenden Einrichtungsschritte. Er ist für die KPI zur durchschnittlichen Zeit bis zur Stellenaktivierung erforderlich. Woher beziehen Wird abgeleitet, indem der Zeitstempel erfasst wird, zu dem das Statusfeld im Stellendatensatz, zum Beispiel „PositionStatus“, auf „Aktiv“ oder „Offen“ gesetzt wird. Erfassung Basiert auf dem Datum, an dem das Feld ActivationDate der Stelle ausgefüllt wird oder sich ein Statusfeld auf „Aktiv“ ändert. Ereignistyp inferred | |||
| Stelle deaktiviert | Die Stelle ist nicht mehr aktiv und wird aus der aktiven Organisationsstruktur entfernt, häufig nachdem sie besetzt wurde. Dies wird anhand einer Statusänderung auf „Inaktiv“ oder einen ähnlichen Status abgeleitet. | ||
| Warum das wichtig ist Kennzeichnet einen wichtigen Schritt am Ende der aktiven Phase einer Stelle. Das Event ist entscheidend für die Analyse der durchschnittlichen Zeit bis zur Deaktivierung und eine genaue Verwaltung des Personalbestands. Woher beziehen Wird anhand des Zeitstempels abgeleitet, zu dem das Feld „RetirementDate“ ausgefüllt wird oder sich ein Statusfeld im Stellendatensatz auf „Inaktiv“ ändert. Erfassung Basiert auf dem Datum, an dem das Feld RetirementDate der Stelle gesetzt wird oder sich ein Statusfeld auf „Inaktiv“ ändert. Ereignistyp inferred | |||
| Stelle geschlossen | Kennzeichnet die endgültige Archivierung des Stellendatensatzes und damit das vollständige Ende seines Lebenszyklus. Dieses Event wird anhand einer Statusänderung auf „Geschlossen“ oder einen ähnlichen Endstatus abgeleitet. | ||
| Warum das wichtig ist Dies ist das abschließende Event des Prozesses. Es ermöglicht eine vollständige Analyse des Lebenszyklus von Anfang bis Ende und hilft, veraltete Stellen zu erkennen, die geschlossen werden sollten. Woher beziehen Wird anhand einer Änderung des Statusfelds im Stellendatensatz auf „Geschlossen“ abgeleitet. Das kommt seltener vor als eine Deaktivierung, da Datensätze häufig aus historischen Gründen aufbewahrt werden. Erfassung Wird anhand des Zeitstempels abgeleitet, zu dem ein Statusfeld auf „Geschlossen“ gesetzt wird. Ereignistyp inferred | |||
| Stelle im HR-System erstellt | Dieses Event kennzeichnet die offizielle Erstellung des Stellendatensatzes in Dynamics 365 HR. Es wird anhand des Erstellungszeitstempels des primären Stellendatensatzes erfasst. | ||
| Warum das wichtig ist Ein grundlegender Meilenstein, der den Übergang vom Antrag zu einer tatsächlichen Stelle in der Organisation kennzeichnet. Er bildet den Endpunkt für die KPI zur Durchlaufzeit der Stellenerstellung. Woher beziehen Aus dem Systemfeld „CreatedDateTime“ in der Haupttabelle für Stellen, zum Beispiel HcmPosition. Erfassung Aus dem Systemfeld CreatedDateTime in der Tabelle HcmPosition. Ereignistyp explicit | |||
| Stellenantrag eingeleitet | Kennzeichnet den formellen Beginn des Lebenszyklus einer Stelle. Dieses Event wird üblicherweise erfasst, wenn ein Benutzer über ein dafür vorgesehenes Formular oder einen Workflow in Dynamics 365 HR einen neuen Stellenantrag einreicht. | ||
| Warum das wichtig ist Dies ist der Ausgangspunkt für die Messung des gesamten Lebenszyklus einer Stelle, einschließlich wichtiger KPIs wie der Freigabezykluszeit und der Durchlaufzeit der Stellenerstellung. Woher beziehen Erfasst anhand des Erstellungszeitstempels eines Stellenantrags oder des Einleitungsdatensatzes in der Workflow-Verlaufstabelle, zum Beispiel WorkflowTrackingStatusTable. Erfassung Das Event wird bei der Übermittlung eines neuen Workflows für einen Stellenantrag erfasst. Ereignistyp explicit | |||
| Stellenantrag von der Personalabteilung freigegeben | Kennzeichnet die abschließende Freigabe durch die Personalabteilung, bevor die Stelle offiziell erstellt werden kann. Dieses Event wird im Workflow-System ausdrücklich erfasst, sobald die Freigabeaufgabe der Personalabteilung abgeschlossen ist. | ||
| Warum das wichtig ist Damit endet die Freigabephase. Dieser wichtige Meilenstein dient zur Messung der durchschnittlichen Freigabezykluszeit für Stellen. Woher beziehen Wird in den Workflow-Verlaufstabellen, zum Beispiel in WorkflowTrackingTable, erfasst, sobald der zuständige Mitarbeitende der Personalabteilung die Freigabeaufgabe abschließt. Erfassung Das Event wird nach Abschluss der Freigabe durch die Personalabteilung mit einem Zeitstempel im Workflow-Verlauf erfasst. Ereignistyp explicit | |||
| Compliance-Prüfung der Stelle durchgeführt | Zeigt an, dass eine Stelle einer formellen Compliance-Prüfung unterzogen wurde. Erfasst werden kann dies durch eine Statusänderung, eine abgeschlossene Checklistenaufgabe oder die Aktualisierung eines benutzerdefinierten Feldes. | ||
| Warum das wichtig ist Wichtig für die Überwachung der Einhaltung gesetzlicher und interner Vorgaben. Diese Aktivität fließt direkt in die KPI zur Compliance-Einhaltung bei Stellen ein. Woher beziehen Wird wahrscheinlich aus einem mit Zeitstempel versehenen Statusfeld wie „ComplianceReviewStatus“ oder einem booleschen Feld „IsComplianceReviewed“ im Stellendatensatz abgeleitet. Erfassung Wird anhand des Zeitstempels abgeleitet, zu dem ein Compliance-Statusfeld auf „Abgeschlossen“ oder „Geprüft“ gesetzt wird. Ereignistyp inferred | |||
| Personalsuche gestartet | Kennzeichnet die Übergabe vom Stellenmanagement an die Personalgewinnung. Dieses Event wird abgeleitet, wenn eine neue Vakanz oder ein neues Recruiting-Projekt erstellt und mit der betreffenden Stellen-ID verknüpft wird. | ||
| Warum das wichtig ist Verknüpft den Prozess des Stellenmanagements mit seinem Ergebnis. So lässt sich die Zeit zwischen der Aktivierung einer Stelle und dem Beginn der tatsächlichen Personalgewinnung analysieren. Woher beziehen Wird abgeleitet, indem das Erstellungsdatum eines Datensatzes in den Tabellen für Personalgewinnung oder Vakanzen ermittelt wird, zum Beispiel in HcmRecruitingRequest, der auf die Stellen-ID verweist. Erfassung Wird abgeleitet, indem die PositionId mit der Erstellung eines zugehörigen Datensatzes im Recruiting-Modul verknüpft wird. Ereignistyp inferred | |||
| Stelle eingefroren | Zeigt an, dass eine Stelle vorübergehend zurückgestellt wurde und keine Personalgewinnung stattfinden kann. Dies wird anhand einer Statusänderung des Stellendatensatzes auf „Eingefroren“ oder „Zurückgestellt“ abgeleitet. | ||
| Warum das wichtig ist Erfasst Unterbrechungen im Lebenszyklus einer Stelle, die sich auf Personalplanung und Budgets auswirken können. So lassen sich Gründe für Verzögerungen bei der Personalgewinnung erkennen. Woher beziehen Wird abgeleitet, indem der Zeitstempel erfasst wird, zu dem ein Statusfeld im Stellendatensatz auf „Eingefroren“ oder einen ähnlichen Wert gesetzt wird. Erfassung Wird anhand des Zeitstempels einer Statusänderung auf „Eingefroren“ oder „Zurückgestellt“ abgeleitet. Ereignistyp inferred | |||
| Stelle neu zugeordnet | Eine wesentliche Änderung, bei der die grundlegende Einstufung einer Stelle, etwa die Jobfamilie oder Ebene, angepasst wird. Dies wird üblicherweise anhand einer Änderung des Feldes „Job“ im Stellendatensatz abgeleitet. | ||
| Warum das wichtig ist Hilft, Änderungen an der Organisationsstruktur und die Stabilität von Stellenbeschreibungen zu analysieren. Diese Aktivität ist zentral für die KPI zur Neuzuordnungsquote von Stellen. Woher beziehen Wird anhand einer Änderung des Feldes „JobId“ in der Tabelle HcmPosition abgeleitet. Die Änderung wird über das Datenbankprotokoll erfasst oder durch den Vergleich von Datensatzversionen im Zeitverlauf erkannt. Erfassung Wird anhand einer protokollierten Änderung des Feldes zur Jobklassifizierung im Stellendatensatz abgeleitet. Ereignistyp inferred | |||
| Stellenantrag abgelehnt | Zeigt an, dass ein Stellenantrag in einer der Freigabestufen abgelehnt wurde. Dieses Event wird ausdrücklich im Workflow-Verlauf erfasst, wenn eine freigabeberechtigte Person die Aktion „Ablehnen“ auswählt. | ||
| Warum das wichtig ist Macht Prozessfehler und Schleifen mit Nacharbeit sichtbar. Die Analyse der Ablehnungsgründe hilft, die Qualität der ursprünglichen Anträge zu verbessern und die KPI zur Ablehnungsquote von Stellenanträgen zu berechnen. Woher beziehen Wird für den jeweiligen Stellenantrag in den Workflow-Verlaufstabellen, zum Beispiel in WorkflowTrackingStatusTable, mit dem Status „Abgelehnt“ erfasst. Erfassung Wird im Workflow-Protokoll erfasst, wenn eine freigabeberechtigte Person den Antrag ablehnt. Ereignistyp explicit | |||
| Stellenantrag von der Führungskraft freigegeben | Kennzeichnet den Abschluss der ersten Freigabestufe durch die einstellende Führungskraft. Dieses Event wird ausdrücklich im Workflow-Verlauf erfasst, wenn die Führungskraft die zugewiesene Freigabeaufgabe abschließt. | ||
| Warum das wichtig ist Damit lässt sich die Dauer der ersten Freigabestufe bestimmen und feststellen, ob bestimmte Führungskräfte oder Abteilungen Engpässe verursachen. Woher beziehen Wird als abgeschlossener Schritt in den Workflow-Verlaufstabellen erfasst, zum Beispiel in WorkflowTrackingTable, und dem Stellenantrag zugeordnet. Erfassung Erfasst anhand des Abschlusszeitstempels der Freigabe durch die Führungskraft im Workflow-Protokoll. Ereignistyp explicit | |||
| Stellenattribute geändert | Kennzeichnet jede Änderung an wichtigen Stellenattributen, etwa an der Stellenbezeichnung oder Abteilung, nach der ursprünglichen Erstellung. Diese Aktivität wird üblicherweise anhand von Änderungen im Datenbankprotokoll des Systems abgeleitet. | ||
| Warum das wichtig ist Eine hohe Häufigkeit dieser Aktivität kann auf eine geringe Datenqualität oder Nacharbeit im Prozess hindeuten. Sie ist wichtig für die KPIs zur Häufigkeit von Änderungen an Stellenattributen und zur Nacharbeitsquote. Woher beziehen Wird aus der Tabelle SysDatabaseLog abgeleitet, sofern die Änderungsverfolgung für die Stellentabelle aktiviert ist. Alternativ müssen historische Stände der Stellendaten miteinander verglichen werden. Erfassung Wird anhand von Aktualisierungen wichtiger Felder in der Tabelle HcmPosition abgeleitet, die im Datenbankprotokoll erfasst sind. Ereignistyp inferred | |||
| Stellenbudget freigegeben | Ein wichtiger Freigabeschritt, der bestätigt, dass die erforderlichen Mittel für die neue Stelle bereitgestellt wurden. Dieses Event wird üblicherweise als eigener Freigabeschritt im Workflow zur Stellenerstellung erfasst. | ||
| Warum das wichtig ist Der finanzielle Freigabeschritt lässt sich so gesondert analysieren. Dadurch werden Verzögerungen bei der Budgetzuweisung sichtbar und die KPI zur Freigabezykluszeit des Stellenbudgets kann berechnet werden. Woher beziehen Wird in den Workflow-Verlaufstabellen, zum Beispiel in WorkflowTrackingTable, als abgeschlossene Freigabeaufgabe erfasst, die häufig einer Finanzrolle zugewiesen ist. Erfassung Erfasst anhand des Abschlusszeitstempels der Budgetfreigabeaufgabe im Workflow-Protokoll. Ereignistyp explicit | |||
Anleitungen zum Datenexport
Schritte
- Zum Arbeitsbereich „Datenverwaltung“ wechseln: Melden Sie sich bei Microsoft Dynamics 365 Human Resources an. Suchen Sie über die Hauptsuchleiste den Arbeitsbereich „Datenverwaltung“.
- Neues Exportprojekt erstellen: Wählen Sie im Arbeitsbereich die Kachel „Export“ aus. Klicken Sie auf der Seite des Exportprojekts auf „Neu“, um ein Projekt anzulegen. Geben Sie einen aussagekräftigen Namen ein, zum Beispiel „PositionManagement_EventLog_Export“, und wählen Sie ein Datenformat. Für die weitere Verarbeitung empfiehlt sich „CSV“.
- Datenentitäten zum Projekt hinzufügen: Klicken Sie im neuen Projekt auf „Entität hinzufügen“. Für den gesamten Lebenszyklus einer Stelle müssen Sie mehrere Entitäten hinzufügen. Fügen Sie nacheinander die folgenden wichtigen Entitäten hinzu: „HcmPositionV2“, „WorkflowTrackingStatusTable“ und „HcmRecruitingRequest“. Wenn die Datenbankprotokollierung für Stellenänderungen aktiviert ist, fügen Sie auch „SysDatabaseLog“ hinzu.
- Filter für Entitäten festlegen: Begrenzen Sie den Datenumfang unbedingt durch Filter für jede Entität. Wählen Sie eine Entität aus und klicken Sie auf „Filter“. Filtern Sie „HcmPositionV2“ anhand eines bestimmten Zeitraums über die Felder „CreatedDateTime“ oder „ModifiedDateTime“. Filtern Sie bei „WorkflowTrackingStatusTable“ das Feld „CONTEXTTABLENAME“, sodass nur Workflows zu Stellen berücksichtigt werden.
- Felder für jede Entität auswählen: Achten Sie darauf, alle Felder zu exportieren, die Sie für die spätere Verarbeitung benötigen. Nehmen Sie für „HcmPositionV2“ die Felder „PositionId“, „CreatedDateTime“, „ActivationDate“, „RetirementDate“, „ModifiedDateTime“, „JobId“ und „DepartmentNumber“ auf. Für „WorkflowTrackingStatusTable“ benötigen Sie „ContextRecId“, „WorkflowTrackingStatus“, „CreatedDateTime“ und „UserId“.
- Export ausführen: Wenn Sie alle Entitäten, Felder und Filter eingerichtet haben, klicken Sie auf der Hauptseite des Projekts auf „Export“. Das System erstellt ein Datenpaket mit separaten Dateien für jede Entität.
- Datenpaket überwachen und herunterladen: Den Fortschritt des Auftrags sehen Sie im Bereich „Auftragsverlauf“. Sobald der Auftrag erfolgreich abgeschlossen ist, laden Sie das komprimierte Datenpaket herunter.
- Daten entpacken und umwandeln: Entpacken Sie das heruntergeladene Paket. Darin finden Sie separate CSV-Dateien für jede Entität. Diese Dateien enthalten Rohdaten, nicht das fertige Event Log. Verarbeiten Sie die Dateien mit einem externen Skript, zum Beispiel mit Python und pandas oder mit PowerShell.
- Umwandlungslogik implementieren: Ihr Skript muss folgende Schritte ausführen:
- Laden Sie die Datei „HcmPositionV2.csv“. Erstellen Sie daraus mithilfe von „PositionId“ und „CreatedDateTime“ das Ereignis „Stelle im HR-System angelegt“.
- Erstellen Sie Ereignisse für Statusänderungen („Stelle aktiviert“, „Stelle eingefroren“, „Stelle deaktiviert“, „Stelle geschlossen“), indem Sie Status- oder Datumsfelder wie „ActivationDate“ und „RetirementDate“ aus „HcmPositionV2.csv“ auswerten.
- Laden Sie die Datei „WorkflowTrackingStatusTable.csv“. Verknüpfen Sie die Daten anhand der Datensatz-ID mit den Stellendaten. Erstellen Sie daraus die Workflow-Ereignisse „Stellenanforderung eingeleitet“, „Stellenanforderung von der Führungskraft genehmigt“, „Stellenbudget genehmigt“, „Stellenanforderung von der Personalabteilung genehmigt“ und „Stellenanforderung abgelehnt“. Ordnen Sie den Workflowstatus und den jeweiligen Schritt der passenden Aktivitätsbezeichnung zu.
- Wenn Sie „SysDatabaseLog.csv“ exportiert haben, werten Sie die Datei aus, um anhand von Änderungen an bestimmten Feldern der Tabelle „HcmPosition“ die Ereignisse „Stellenattribute geändert“ und „Stelle neu eingestuft“ zu erstellen.
- Laden Sie „HcmRecruitingRequest.csv“, um das Ereignis „Einstellungsprozess gestartet“ zu erstellen. Ermitteln Sie dazu, wann eine Recruiting-Anforderung für eine bestimmte Stelle angelegt wurde.
- Abschließendes Event Log zusammenstellen: Das Skript sollte alle erstellten Ereignisse aus den verschiedenen Quellen in einer CSV-Datei zusammenführen. Diese Datei muss die erforderlichen Spalten „PositionId“, „ActivityName“ und „EventTime“ sowie alle empfohlenen Attribute enthalten, die Sie zuordnen konnten.
- Datei für den Upload formatieren: Achten Sie darauf, dass die endgültige CSV-Datei die erforderlichen Attributnamen als Spaltenüberschriften verwendet und die Spalte „EventTime“ ein einheitliches Timestamp-Format aufweist. Die Datei kann nun in das Process-Mining-Tool hochgeladen werden.
Konfiguration
- Wichtige Datenentitäten: Für diesen Export werden hauptsächlich folgende Entitäten benötigt:
HcmPositionV2: Enthält grundlegende Angaben zu jeder Stelle, darunter Anlegedatum, Aktivierungsdatum sowie Attribute wie Beruf und Abteilung.WorkflowTrackingStatusTable: Enthält den Verlauf der Workflow-Instanzen, einschließlich Einreichungen, Genehmigungen und Ablehnungen. Diese Entität ist wichtig, um den Genehmigungsprozess nachzuverfolgen.HcmRecruitingRequest: Dient dazu, die Aktivität „Einstellungsprozess gestartet“ abzuleiten, wenn eine Recruiting-Anforderung mit einer Stelle verknüpft ist.SysDatabaseLog: Eine optionale, aber hilfreiche Entität, um detaillierte Änderungen wie „Stellenattribute geändert“ und „Stelle neu eingestuft“ zu erfassen. Sie können sie verwenden, wenn die Datenbankprotokollierung für die Tabelle „HcmPosition“ eingerichtet ist.
- Filter für den Zeitraum: Es empfiehlt sich dringend, die Entität „HcmPositionV2“ anhand des Felds „CreatedDateTime“ nach einem Zeitraum zu filtern. Ein Zeitraum von 6 bis 12 Monaten ist oft ein guter Ausgangspunkt, um das Datenvolumen überschaubar zu halten.
- Inkrementelle Exporte: Für laufende Analysen können Sie das Exportprojekt für inkrementelle Exporte konfigurieren. Dabei werden nur Datensätze exportiert, die seit dem letzten Durchlauf geändert wurden. Das verkürzt die Verarbeitungszeit erheblich.
- Voraussetzungen: Das Benutzerkonto für den Export benötigt eine Sicherheitsrolle mit ausreichenden Berechtigungen für den Arbeitsbereich „Datenverwaltung“ und Lesezugriff auf alle angegebenen Datenentitäten. In der Regel ist dafür die Rolle „Datenverwaltungsadministrator“ oder eine benutzerdefinierte Rolle mit den entsprechenden Berechtigungen für die Entitäten erforderlich.
Beispielabfrage 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] Schritte
- Voraussetzungen prüfen: Vergewissern Sie sich vor dem Start, dass die Funktion „Bring Your Own Database“ (BYOD) für Ihre Microsoft-Dynamics-365-Human-Resources-Instanz eingerichtet ist. Prüfen Sie, ob die erforderlichen Datenentitäten in Ihre Azure-SQL-Datenbank exportiert werden. Dazu gehören unter anderem
HcmPositionV2,HcmPositionDetail,WorkflowTrackingStatusTable,HcmJob,OMOperatingUnitundHcmRecruitingRequest. - Mit der Azure-SQL-Datenbank verbinden: Stellen Sie mit einem SQL-Client wie SQL Server Management Studio (SSMS) oder Azure Data Studio eine Verbindung zur Azure-SQL-Datenbank her, die als BYOD-Ziel dient.
- Datenbankschema ermitteln: Machen Sie sich nach dem Verbindungsaufbau mit dem Datenbankschema vertraut. Die D365-HR-Datenentitäten werden als Tabellen repliziert. Beachten Sie, dass die Tabellennamen in der BYOD-Datenbank möglicherweise nicht genau den Entitätsnamen entsprechen, ihnen aber in der Regel sehr ähnlich sind.
- SQL-Abfrage laden: Öffnen Sie in Ihrem SQL-Client ein neues Abfragefenster und fügen Sie das vollständige SQL-Skript aus dem Abschnitt „query“ dieses Dokuments ein.
- Parameter anpassen: Ändern Sie die Platzhaltervariablen in der Abfrage. Setzen Sie
@[YourCompanyId]auf die gewünschte juristische Person, zum Beispiel „USMF“. Passen Sie den Zeitraum in denWHERE-Klauseln an, etwa mitCREATEDDATETIME >= '2023-01-01', um den Export auf den gewünschten Zeitraum zu begrenzen. - Abfrage ausführen: Führen Sie die vollständige SQL-Abfrage für die BYOD-Datenbank aus. Die Ausführungszeit hängt vom Datenvolumen und dem gewählten Zeitraum ab.
- Ergebnisse prüfen: Prüfen Sie nach Abschluss der Abfrage die Ausgabe im Ergebnisbereich Ihres SQL-Clients. Vergewissern Sie sich, dass die Spalten
PositionId,ActivityName,EventTimeund weitere erwartete Spalten gefüllt sind. - Als CSV exportieren: Exportieren Sie das gesamte Ergebnis in eine CSV-Datei. Die meisten SQL-Clients bieten eine integrierte Funktion, um Ergebnisse direkt als CSV-Datei zu speichern. In SSMS können Sie beispielsweise mit der rechten Maustaste auf das Ergebnisraster klicken und „Ergebnisse speichern unter …“ auswählen.
- Für den Upload vorbereiten: Achten Sie darauf, dass die exportierte CSV-Datei UTF-8-kodiert ist. Prüfen Sie, ob die Spaltenüberschriften genau den erforderlichen Attributen entsprechen (
PositionId,ActivityName,EventTimeusw.), damit der Upload in das Process-Mining-Tool reibungslos funktioniert.
Konfiguration
- BYOD-Datenentitäten: Vergewissern Sie sich, dass alle erforderlichen Datenentitäten aus Dynamics 365 HR in Ihrer BYOD-Instanz veröffentlicht sind. Für diesen Prozess sind insbesondere Entitäten zu Stellen, Stellendetails, Workflowverlauf, Berufen, Abteilungen und Recruiting-Anforderungen erforderlich.
- Datenverzögerung: BYOD repliziert Daten nahezu in Echtzeit, jedoch nicht sofort. Zwischen einer Transaktion in D365 HR und dem Erscheinen der Daten in der Azure-SQL-Datenbank kann es zu einer Verzögerung von wenigen Minuten bis zu einer Stunde kommen.
- Filter für den Zeitraum: Filtern Sie Ihre Abfrage unbedingt nach Datum, um Leistung und Datenvolumen zu steuern. Ein Zeitraum von 3 bis 6 Monaten ist ein sinnvoller Ausgangspunkt. Wenden Sie in jedem
UNION ALL-Block Filter auf Erstellungs- oder Ereigniszeitstempel an. - Unternehmensfilter: Filtern Sie immer nach
DATAREAID(juristische Person oder Unternehmens-ID), damit Sie Daten der richtigen Organisationseinheit analysieren. Die bereitgestellte Abfrage enthält dafür den Platzhalter@[YourCompanyId]. - Voraussetzungen: Für diese Methode benötigen Sie ein aktives Azure-Abonnement, eine eingerichtete BYOD-Instanz, Leseberechtigungen für die betreffende Azure-SQL-Datenbank und einen geeigneten SQL-Client zum Ausführen der Abfrage.
- Benutzerdefinierte Workflow-Schritte: Die Abfrage verwendet gängige Bezeichnungen für Genehmigungsschritte, zum Beispiel „Stellenanforderung genehmigen“. Wenn Ihre Organisation eigene Bezeichnungen verwendet, müssen Sie die Werte von
CONTEXTin den entsprechendenWHERE-Klauseln anpassen.
Beispielabfrage 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]' Möchten Sie loslegen?
Verwenden Sie dieses Template, um die Datenerfassung zu vereinfachen und fundierte Erkenntnisse über Ihren Hire-to-Retire-Prozess in der Stellenverwaltung zu gewinnen. Beginnen Sie noch heute damit, Effizienz und Compliance zu verbessern.
Stellenverwaltung im Hire-to-Retire-Prozess sofort optimieren
Verkürzen Sie die Zykluszeit Ihres Prozesses um 30 % und beseitigen Sie Engpässe.
Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.