> Kontinuierliche Prozessverbesserung > Hire to Retire – Positionsverwaltung > Workday HCM > Daten Template

Ihr Daten-Template für Hire to Retire: Positionsmanagement

Workday HCM

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für Hire to Retire: Positionsmanagement (21) Aktivitäten für Hire to Retire: Positionsmanagement (13) Anleitungen zur Datenextraktion (3)

Ihr Daten-Template für Hire to Retire: Positionsmanagement

Dieses Template zeigt Ihnen, welche Daten Sie für die Analyse Ihres Hire-to-Retire-Prozesses im Bereich Positionsmanagement benötigen. Es beschreibt die wichtigen Attribute, die Sie erfassen sollten, die zentralen Aktivitäten, die Sie nachverfolgen sollten, und wie Sie diese Informationen aus Workday HCM extrahieren. So stellen Sie sicher, dass Ihr Event Log vollständig und für aussagekräftige Process-Mining-Erkenntnisse bereit ist.

Empfohlene Attribute für die Erfassung
Wichtige Aktivitäten für die Nachverfolgung
Anleitung zur Datenextraktion

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute für Hire to Retire: Positionsmanagement

Diese Datenfelder sollten Sie für eine umfassende Analyse von Hire to Retire: Positionsmanagement in Ihr Event Log aufnehmen.

3 Erforderlich 7 Empfohlen 11 Optional

	Name	Beschreibung
	Positions-ID PositionId	Die eindeutige Kennung einer bestimmten Position innerhalb der Organisation. Sie dient als primäre Case-ID für den Positionsmanagementprozess.
Beschreibung Die Positions-ID ist der zentrale Bezugspunkt für die Analyse des Positionsmanagements. Jede ID steht für den gesamten Lebenszyklus einer einzelnen Position, von der ersten Anfrage und Anlage über Änderungen und Neubewertungen bis zur Deaktivierung oder Schließung. Beim Process Mining dient dieses Attribut dazu, alle zugehörigen Aktivitäten wie Genehmigungen, Datenänderungen und Statusaktualisierungen einem bestimmten Case zuzuordnen. So lässt sich der gesamte Verlauf einer Position nachvollziehen. Dadurch können Sie Zykluszeiten analysieren, Prozessvarianten erkennen und die Compliance für jede einzelne Position überwachen. Warum das wichtig ist Das Attribut ist wichtig, um den gesamten Lebenszyklus einer Position nachzuverfolgen, den Prozess durchgängig zu analysieren und Engpässe oder Abweichungen in einzelnen Cases zu erkennen. Woher beziehen Diese zentrale Kennung wird in Workday HCM verwendet und ist in der Regel in Berichten und Geschäftsdaten zu Personalbesetzung und Positionsmanagement verfügbar. Beispiele POS-0012345POS-0067890POS-0112233
	Aktivitätsname ActivityName	Der Name des jeweiligen Geschäftsvorgangs oder Ereignisses, zum Beispiel „Position angelegt“ oder „Budget genehmigt“.
Beschreibung Der Aktivitätsname bezeichnet einen einzelnen Schritt im Lebenszyklus des Positionsmanagements. Diese Ereignisse bilden die Grundlage der Prozesslandkarte und zeigen die Abfolge der Aktionen für jede Position. Durch die Analyse dieser Aktivitäten lassen sich Prozessabläufe visualisieren, häufige und seltene Pfade erkennen und die Zeit zwischen wichtigen Meilensteinen messen. Beispiele sind „Positionsanfrage eingeleitet“, „Positionsattribute geändert“ und „Position geschlossen“. Zusammen geben sie Aufschluss über den operativen Ablauf. Warum das wichtig ist Dieses Attribut ist grundlegend für den Aufbau der Prozesslandkarte, die Visualisierung des Prozessablaufs und die Ermittlung von Ereignissen, die Verzögerungen oder Nacharbeit verursachen. Woher beziehen Die Daten stammen aus den Transaktionsprotokollen des Workday-Geschäftsprozess-Frameworks. Jeder Schritt einer Geschäftsprozessdefinition erzeugt einen Ereigniseintrag. Beispiele Positionsanfrage gestartetFreigabe durch Führungskraft eingereichtPosition angelegtPosition deaktiviert
	Ereigniszeit EventTime	Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung Die Ereigniszeit ist ein genauer Timestamp, der Datum und Uhrzeit jeder Aktivität im Prozess festhält. Diese Daten sind für zeitbezogene Analysen unverzichtbar, etwa zur Berechnung von Zyklus-, Warte- und Durchlaufzeiten. Beim Process Mining ordnet dieser Timestamp die Ereignisse chronologisch und bildet so die Abfolge der Aktivitäten im Prozessablauf. Er ist die Grundlage für Leistungsanalysen: Damit lassen sich Engpässe erkennen, Durchsatzzeiten untersuchen und SLAs überwachen. Warum das wichtig ist Der Timestamp ist erforderlich, um Ereignisse zu ordnen, zeitbezogene Kennzahlen wie Zyklus- und Durchlaufzeiten zu berechnen und Engpässe im Prozess zu untersuchen. Woher beziehen Workday HCM protokolliert diesen Timestamp automatisch für jede Geschäftstransaktion. Beispiele 2023-04-15T09:00:00Z2023-04-15T14:35:10Z2023-04-18T11:21:05Z
	Abteilung Department	Die Abteilung oder die übergeordnete Organisation, zu der die Position gehört.
Beschreibung Das Attribut „Abteilung“, in der Workday-Terminologie häufig „Supervisory Organization“ genannt, liefert den organisatorischen Kontext einer Position. Es bezeichnet das Team oder den Geschäftsbereich, dem die Position zugeordnet ist. Diese wichtige Analysedimension ermöglicht Leistungsvergleiche zwischen verschiedenen Unternehmensbereichen. So können Sie etwa die Genehmigungszeiten neuer Positionen in den Abteilungen Engineering und Marketing vergleichen und bewährte Vorgehensweisen oder lokale Engpässe erkennen. Warum das wichtig ist Ermöglicht es, die Prozessleistung verschiedener Organisationseinheiten zu filtern und zu vergleichen sowie abteilungsspezifische Engpässe und Effizienzpotenziale zu erkennen. Woher beziehen Die Position ist in Workday HCM einer Supervisory Organization zugeordnet, über die dieses Attribut verknüpft wird. Beispiele Vertrieb - NordamerikaEngineering - PlattformentwicklungFinanzen - Konzern-FP&A
	Änderungsgrund ReasonForChange	Der angegebene Grund für ein Änderungsereignis, etwa eine Neubewertung, Änderung oder Schließung einer Position.
Beschreibung Dieses Attribut erfasst die geschäftliche Begründung für eine Änderung an einer Position. In Workday werden die Gründe häufig aus einer vordefinierten Liste ausgewählt, um einheitliche Angaben sicherzustellen. Beispiele sind „Umstrukturierung“, „Neues Projekt“ oder „Budgetanpassung“. Die Analyse dieses Attributs liefert wichtigen Kontext zu den Prozessabläufen. Sie hilft, das Warum hinter dem Was zu verstehen. So können Sie beispielsweise Neubewertungen mit den jeweiligen Gründen verknüpfen und Trends bei organisatorischen Umstrukturierungen oder der Weiterentwicklung von Rollen erkennen. Warum das wichtig ist Das Attribut erklärt den geschäftlichen Hintergrund von Aktivitäten wie Änderungen und Neubewertungen und hilft, die Ursachen für Prozessabweichungen zu untersuchen. Woher beziehen Bei vielen Workday-Geschäftstransaktionen ist dieses Feld erforderlich, etwa bei „Positionsbeschränkungen bearbeiten“ oder „Position schließen“. Beispiele Neue Abteilung eingerichtetUmstrukturierungDatenkorrekturProjektabschluss
	Benutzer User	Die Benutzer-ID oder der Name der Person, die die Aktivität ausgeführt hat.
Beschreibung Dieses Attribut kennzeichnet den Mitarbeitenden oder Systembenutzer, der eine bestimmte Aufgabe im Prozess ausgeführt hat, etwa eine Genehmigung eingereicht oder Positionsattribute geändert hat. Dabei kann es sich um eine Führungskraft, einen HR-Partner oder einen Finanzanalysten handeln. Eine Auswertung nach Benutzer kann Schulungsbedarf, eine ungleiche Arbeitsverteilung und Unterschiede bei der individuellen Leistung sichtbar machen. So lässt sich beispielsweise feststellen, welche Benutzer besonders häufig an Nacharbeiten beteiligt sind. Das kann auf einen Bedarf an klareren Anweisungen oder Systemverbesserungen hindeuten. Warum das wichtig ist Ermöglicht die Analyse der Arbeitsverteilung und benutzerspezifischer Verhaltensmuster sowie die Ermittlung von Schulungsbedarf und besonders leistungsstarken Mitarbeitenden. Woher beziehen In den Workday-Geschäftsprozessprotokollen verfügbar. Sie erfassen für jeden Schritt die auslösende oder ausführende Person. Beispiele jsmithdavis_janehr_admin_svc
	Berufsfamilie JobFamily	Eine Gruppe von Berufen mit ähnlichen Merkmalen, Kompetenzen und Aufgaben, zum Beispiel „Engineering“ oder „Personalwesen“.
Beschreibung Eine Berufsfamilie fasst verwandte Jobprofile zusammen. So können die Jobprofile „Software Engineer“ und „Senior Software Engineer“ beide zur Berufsfamilie „Engineering“ gehören. Damit lassen sich Rollen auf einer übergeordneten Ebene einordnen und analysieren. Dieses Attribut unterstützt beispielsweise die Überwachung von Neubewertungen und die Standardisierung von Positionsattributen. Durch die Analyse von Änderungen innerhalb einer Berufsfamilie oder zwischen verschiedenen Berufsfamilien kann ein Unternehmen Erkenntnisse zu Karrierewegen, einheitlichen Rollendefinitionen und Entwicklungen der Belegschaft gewinnen. Warum das wichtig ist Ermöglicht eine übergeordnete Analyse von Rollen und unterstützt die Standardisierung sowie die Untersuchung von Neubewertungen zwischen verwandten Berufskategorien. Woher beziehen Dieses Attribut ist Teil der Jobkatalogstruktur in Workday HCM und dem Jobprofil einer Position zugeordnet. Beispiele InformationstechnologieFinanzen und RechnungswesenVertriebsfachkräfte
	Endzeit EndTime	Der Timestamp, der angibt, wann eine Aktivität abgeschlossen wurde. Er dient zur Berechnung der Dauer einzelner Aktivitäten.
Beschreibung Die Endzeit kennzeichnet den Abschluss einer bestimmten Aktivität. Während die Startzeit angibt, wann ein Ereignis begonnen hat, lässt sich aus Start- und Endzeit die Verarbeitungszeit dieses Ereignisses berechnen. Das ist besonders bei Aktivitäten hilfreich, die nicht unmittelbar abgeschlossen sind, etwa bei einer Compliance-Prüfung. Vergleichen Sie die Endzeit einer Aktivität mit der Startzeit der nächsten, lassen sich sowohl die Verarbeitungszeit als auch die Wartezeit genau bestimmen. So erhalten Sie weitere Erkenntnisse zur Prozesseffizienz. Warum das wichtig ist Sie ist erforderlich, um die Dauer von Aktivitäten genau zu berechnen und aktive Verarbeitungszeit von Wartezeit zu unterscheiden. Woher beziehen Für einige Workday-Geschäftsprozessschritte sind Start- und Endzeiten ausdrücklich erfasst. Andernfalls lässt sich die Endzeit aus der Startzeit des nächsten Ereignisses im selben Case ableiten. Beispiele 2023-04-15T09:05:12Z2023-04-15T17:00:00Z2023-04-18T11:21:55Z
	Kostenstelle CostCenter	Die der Position zugeordnete finanzielle Kostenstelle. Sie dient der Budgetierung und Finanzberichterstattung.
Beschreibung Die Kostenstelle ist eine finanzielle Dimension, die eine Position mit einem bestimmten Budget verknüpft. Sie ist wichtig, um Kosten nachzuverfolgen und sicherzustellen, dass die Personalplanung mit den Finanzplänen übereinstimmt. Beim Process Mining ist dieses Attribut für Analysen zu Budgetgenehmigungen und finanziellen Auswirkungen relevant. Damit lässt sich untersuchen, wie sich Genehmigungszeiten zwischen Kostenstellen unterscheiden und wie Aktivitäten im Positionsmanagement mit finanziellen Ergebnissen zusammenhängen. Außerdem unterstützt es die Standardisierung von Rollenattributen über vergleichbare Finanzbereiche hinweg. Warum das wichtig ist Das Attribut ergänzt die Analyse um eine finanzielle Dimension. So können Sie Prozesse nach Budgeteinheit auswerten und Engpässe bei der Budgetierung untersuchen. Woher beziehen Dieses Attribut gehört zu den Finanzinformationen, den sogenannten „Worktags“, die einer Position in Workday HCM zugewiesen werden. Beispiele CC4010_MARKETINGCC2050_RD_SOFTWARECC7000_ADMIN
	Positionsstatus PositionStatus	Der aktuelle oder historische Status der Position, zum Beispiel „Offen“, „Besetzt“, „Eingefroren“ oder „Geschlossen“.
Beschreibung Der Positionsstatus zeigt den Zustand einer Position zu einem bestimmten Zeitpunkt an. Dieses Attribut ist wichtig, um die aktuelle Verfügbarkeit und die Phase im Lebenszyklus der Position zu verstehen. Eine Filterung nach Status kann die Analyse auf bestimmte Prozessabschnitte eingrenzen. So können Sie beispielsweise Positionen mit dem Status „Eingefroren“ untersuchen und in Alterungsberichten nachvollziehen, wie lange Ressourcen gebunden sind. Auch die Statuswechsel sind wichtig, um den Prozessablauf zu verstehen. Warum das wichtig ist Das Attribut liefert wichtigen Kontext zum Zustand einer Position. Damit können Sie untersuchen, wie lange Positionen eingefroren bleiben, und ihre Entwicklung im Lebenszyklus nachverfolgen. Woher beziehen Als Standardfeld des Positionsobjekts in Workday HCM verfügbar. Beispiele Offen - GenehmigtBesetztEingefrorenGeschlossen
	Beschäftigungsart PositionType	Ordnet die Position anhand der Beschäftigungsbedingungen ein, zum Beispiel als Vollzeit, Teilzeit oder befristete Beschäftigung.
Beschreibung Die Beschäftigungsart, in Workday häufig als „Worker Type“ oder „Time Type“ bezeichnet, beschreibt die Art des Beschäftigungsverhältnisses für eine Position. Sie ist eine grundlegende Dimension der Personalplanung und -verwaltung. Beim Process Mining können Sie damit die Abläufe im Positionsmanagement für verschiedene Beschäftigtengruppen vergleichen. So lässt sich beispielsweise untersuchen, ob Genehmigungen für Auftragnehmende schneller oder mit weniger Schritten ablaufen als für Vollzeitbeschäftigte. Daraus können sich Ansatzpunkte für Prozessverbesserungen ergeben. Warum das wichtig ist Ermöglicht den Vergleich der Abläufe im Positionsmanagement für verschiedene Beschäftigtengruppen, etwa Vollzeitbeschäftigte und Auftragnehmende, und zeigt mögliche Prozessverbesserungen auf. Woher beziehen Als Teil der Positionsdefinition verfügbar, häufig unter „Worker Type“ oder „Time Type“. Beispiele Reguläre VollzeitbeschäftigungReguläre TeilzeitbeschäftigungBefristete Beschäftigung auf Vertragsbasis
	Compliance-Prüfung erfolgt IsComplianceReviewed	Ein boolesches Kennzeichen, das den Wert „wahr“ hat, wenn die Aktivität „Positions-Compliance geprüft“ für einen Case stattgefunden hat.
Beschreibung Dieses Kennzeichen zeigt an, ob eine Position im Laufe ihres Lebenszyklus formell auf Compliance geprüft wurde. Dazu wird für die jeweilige Positions-ID geprüft, ob die Aktivität „Positions-Compliance geprüft“ vorliegt. Das Attribut vereinfacht die Compliance-Überwachung und die Berechnung von Kennzahlen. Sie können alle geprüften und ungeprüften Cases einfach filtern. Außerdem unterstützt es direkt die Kennzahl „Compliance-Quote bei Positionsmaßnahmen“, da sich die konforme Grundgesamtheit damit leicht ermitteln lässt. Warum das wichtig ist Vereinfacht die Messung der Compliance-Quoten und ermöglicht es, Positionen, bei denen vorgeschriebene Prüfungen umgangen wurden, gezielt zu filtern und zu untersuchen. Woher beziehen Dieses abgeleitete Kennzeichen wird auf Case-Ebene berechnet. Es wird auf „wahr“ gesetzt, wenn die Aktivität „Positions-Compliance geprüft“ im Case-Protokoll vorhanden ist. Beispiele truefalse
	Compliance-Status ComplianceStatus	Gibt das Ergebnis einer Compliance-Prüfung an, zum Beispiel „Konform“ oder „Nicht konform“.
Beschreibung Dieses Attribut erfasst das Ergebnis der formellen Aktivität „Positions-Compliance geprüft“. Es zeigt, ob die Positionsattribute, der Genehmigungsverlauf oder die Begründung den internen Richtlinien und externen Vorschriften entsprechen. Das Attribut ist wichtig für das Dashboard „Übersicht zur Compliance bei Positionsmaßnahmen“. Es ermöglicht die direkte Überwachung der Compliance-Quoten. Auditoren und HR-Teams können damit Positionen, die als nicht konform gekennzeichnet wurden, schnell erkennen und untersuchen. So lassen sich Korrekturmaßnahmen einleiten und Risiken mindern. Warum das wichtig ist Misst direkt das Ergebnis von Compliance-Prüfungen. So können Sie die Einhaltung von Richtlinien überwachen und risikoreiche Cases zur Prüfung kennzeichnen. Woher beziehen Dieser Wert wird wahrscheinlich von einem eigens konfigurierten Schritt in einem Workday-Geschäftsprozess ausgegeben. Er kann als Kommentar oder benutzerdefiniertes Feld gespeichert sein. Beispiele KonformNicht konformNachverfolgung erforderlich
	Genehmigungszeit für neue Positionen NewPositionApprovalCycleTime	Die Gesamtzeit vom Beginn einer Positionsanfrage bis zur Anlage der Position im System.
Beschreibung Dieses Attribut misst die durchgängige Zykluszeit des Genehmigungsprozesses für neue Positionen. Sie wird für eine bestimmte Positions-ID als Zeitspanne zwischen den Ereignissen „Positionsanfrage eingeleitet“ und „Position angelegt“ berechnet. Das Attribut unterstützt direkt die Kennzahl „Durchschnittliche Genehmigungszykluszeit für neue Positionen“ und zugehörige Dashboards. Wenn Sie die Zykluszeit auf Case-Ebene berechnen, können Sie ihre Verteilung analysieren, Ausreißer erkennen und Faktoren untersuchen, die mit längeren oder kürzeren Genehmigungszeiten zusammenhängen, etwa Abteilung oder Beschäftigungsart. Warum das wichtig ist Misst direkt eine wichtige Leistungskennzahl. Damit können Sie die Effizienz von Genehmigungen analysieren und Faktoren ermitteln, die Verzögerungen verursachen. Woher beziehen Wird im Process-Mining-Tool auf Case-Ebene berechnet, indem die Zeit zwischen bestimmten Start- und Endaktivitäten ermittelt wird. Beispiele P5DT6HP12DP2DT12H30M
	Geschäftseinheit BusinessUnit	Der übergeordnete Geschäftsbereich, zu dem die Position gehört, zum Beispiel „Konsumgüter“ oder „Enterprise-Lösungen“.
Beschreibung Die Geschäftseinheit bezeichnet einen großen Unternehmensbereich, der in der Organisationshierarchie über einer Abteilung angesiedelt ist. Sie dient der strategischen Berichterstattung und Finanzberichterstattung auf hoher Ebene. Eine Analyse des Positionsmanagements nach Geschäftseinheit bietet einen strategischen Überblick über die Personalentwicklung. Sie kann Unterschiede bei der Besetzungsgeschwindigkeit, den Neubewertungsquoten oder der Prozesseffizienz zwischen großen Unternehmensbereichen aufzeigen und der Unternehmensleitung einen Überblick über operative Unterschiede geben. Warum das wichtig ist Ermöglicht eine strategische Analyse der Prozessleistung über große Unternehmensbereiche hinweg und unterstützt Entscheidungen auf Führungsebene. Woher beziehen In Workday wird dies üblicherweise als „Worktag“ umgesetzt. Ein solcher Worktag kann Positionen oder den zugehörigen Kostenstellen zugewiesen werden. Beispiele KonsumgüterEnterprise-LösungenKonzernservices
	Ist Nacharbeit IsRework	Ein boolesches Kennzeichen, das den Wert „wahr“ hat, wenn eine Aktivität als Nacharbeit gilt, etwa wenn Positionsattribute mehrfach geändert werden.
Beschreibung Das Kennzeichen „Ist Nacharbeit“ identifiziert Aktivitäten, bei denen Korrekturen oder wiederholte Arbeit anfallen. Solche Aktivitäten weisen häufig auf Ineffizienzen oder Qualitätsprobleme hin. Das Kennzeichen wird üblicherweise für Ereignisse wie „Positionsattribute geändert“ auf „wahr“ gesetzt, wenn sie kurz nach der Anlage oder mehrfach hintereinander auftreten. Dieses berechnete Attribut ist wichtig für das Dashboard „Nacharbeitsanalyse für Positionsdaten“. Es erleichtert die Ermittlung der Nacharbeitsquote, hilft bei der Ursachenanalyse anhand des Kontexts gekennzeichneter Ereignisse und unterstützt Kennzahlen wie die „Nacharbeitsquote für Positionsdaten“. Warum das wichtig ist Kennzeichnet ineffiziente Nacharbeit direkt. So können Sie deren Umfang ermitteln, Ursachen untersuchen und gezielt Verbesserungen einleiten, um Verschwendung zu reduzieren. Woher beziehen Dieses abgeleitete Kennzeichen wird anhand der Abfolge und Häufigkeit von Aktivitäten berechnet. Es wird beispielsweise auf „wahr“ gesetzt, wenn „Positionsattribute geändert“ mehr als einmal im selben Case auftritt. Beispiele truefalse
	Jobprofil JobProfile	Die standardisierte Vorlage für eine Stelle. Sie legt grundlegende Merkmale wie Aufgaben und Qualifikationen fest.
Beschreibung Das Jobprofil ist ein grundlegender Bestandteil der Jobarchitektur von Workday. Es dient als Vorlage für eine Stelle und definiert unter anderem die Standardbezeichnung, Qualifikationen und Vergütungsstufe. Eine Position ist eine konkrete Ausprägung eines Jobprofils in einer bestimmten Abteilung. Dieses Attribut ist wichtig, um die Standardisierung von Prozessen zu untersuchen. Eine Auswertung nach Jobprofil kann zeigen, ob bestimmte Rollen längere Genehmigungszyklen haben oder häufiger Nacharbeit erfordern. Auch bei Neubewertungen, bei denen eine Position von einem Jobprofil in ein anderes wechselt, ist das Attribut entscheidend. Warum das wichtig ist Verknüpft eine Position mit einer standardisierten Stellenvorlage und ermöglicht die Analyse von Prozessabweichungen anhand einheitlicher Rollenmerkmale. Woher beziehen Ein Pflichtfeld für jede Position in Workday HCM und ein zentraler Bestandteil des Datenmodells für die Personalbesetzung. Beispiele JP-FIN-Analyst3JP-ENG-Dev5JP-HR-Generalist2
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, der angibt, wann die Daten zuletzt aus dem Quellsystem extrahiert und im Process-Mining-Tool aktualisiert wurden.
Beschreibung Dieses Attribut enthält den Timestamp der letzten Datenaktualisierung. Es gehört nicht zu den Prozessdaten selbst, sondern ist Metadatum zur Aktualität des Datensatzes. Diese Information ist für alle Benutzer der Analyse wichtig, denn sie zeigt, wie aktuell die Daten sind. So lässt sich einschätzen, ob die Erkenntnisse den jüngsten Betriebsstand widerspiegeln oder auf einem etwas älteren Datenstand beruhen. Warum das wichtig ist Das Attribut informiert über die Aktualität der Daten, damit Benutzer einschätzen können, wie aktuell die Prozessanalyse und die daraus gewonnenen Erkenntnisse sind. Woher beziehen Dieser Timestamp wird am Ende des Ladevorgangs von der Datenpipeline oder dem ETL-Tool erzeugt. Beispiele 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	Positionsbezeichnung PositionTitle	Die konkrete Bezeichnung der Position, zum Beispiel „Senior Financial Analyst“ oder „Lead Software Engineer“.
Beschreibung Die Positionsbezeichnung ist der offizielle, für Benutzer sichtbare Name einer Rolle. Sie beschreibt die Position genauer als die Berufsfamilie oder das Jobprofil und erscheint üblicherweise in Stellenausschreibungen und Organigrammen. Die Analyse dieses Attributs hilft, Änderungen an Positionen genauer zu verstehen. Bei einer Analyse von Neubewertungen können Sie beispielsweise feststellen, ob sich die Bezeichnung deutlich geändert hat. In Dashboards zur Standardisierung lässt sich außerdem prüfen, ob vergleichbare Rollen in verschiedenen Abteilungen einheitlich benannt sind. Warum das wichtig ist Das Attribut liefert detaillierte Angaben zur Rolle und ist wichtig für die Analyse von Neubewertungen und die Standardisierung von Rollen. Woher beziehen Ein Standardfeld des Positionsobjekts in Workday HCM. Beispiele Senior Product ManagerHR Business Partner IIBuchhaltungsassistent
	Quellsystem SourceSystem	Das System, aus dem die Daten stammen. In diesem Fall ist es Workday HCM.
Beschreibung Dieses Attribut kennzeichnet die Quellanwendung, in der die Daten zum Positionsmanagement erzeugt wurden. In dieser Analyse stammt die Quelle durchgängig aus Workday HCM. In Unternehmen, die Daten aus mehreren Systemen zusammenführen, ist das Feld jedoch besonders wichtig. Mit diesem Attribut bleibt die Datenherkunft nachvollziehbar. Außerdem hilft es, Prozesse zu unterscheiden, die sich über mehrere Plattformen erstrecken. Es liefert wichtigen Kontext und gehört zu einer guten Data Governance. Warum das wichtig ist Das Attribut gibt Aufschluss über die Herkunft der Daten, schafft Klarheit in Umgebungen mit mehreren Systemen und unterstützt die Data-Governance-Standards. Woher beziehen In der Regel wird während der Datenextraktion und -transformation ein statischer Wert wie „Workday HCM“ hinzugefügt. Beispiele Workday HCMWorkdayHCM_Prod
	Standort Location	Der physische oder organisatorische Arbeitsort, der der Position zugeordnet ist.
Beschreibung Das Standortattribut gibt an, an welchem geografischen Standort oder in welchem Büro die Position angesiedelt ist. Die Angabe kann von einer konkreten Gebäudeadresse bis hin zu einem Land oder einer Region reichen. Auch „Remote“ kann als Wert verwendet werden. Eine Auswertung nach Standort kann regionale Unterschiede bei der Prozessleistung aufdecken, etwa bei Genehmigungszeiten oder Compliance-Quoten. So lässt sich feststellen, ob Prozesse weltweit einheitlich ablaufen oder lokale Vorgehensweisen zu Abweichungen führen. Warum das wichtig ist Ermöglicht geografische Auswertungen, mit denen sich regionale Prozessunterschiede, Abweichungen bei der Compliance und standortspezifische Engpässe erkennen lassen. Woher beziehen Ein Standardattribut, das einer Position in Workday HCM zugewiesen werden kann. Beispiele New York, USALondon, Vereinigtes KönigreichRemote (Deutschland)

Erforderlich Empfohlen Optional

Aktivitäten für Hire to Retire: Positionsmanagement

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um den Prozess Hire to Retire: Positionsmanagement präzise zu entdecken.

6 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Budget freigegeben	Ein wichtiger Meilenstein: Die Finanzabteilung oder eine für das Budget zuständige Person bestätigt, dass Mittel für die neue Position verfügbar sind. Workday erfasst dieses Ereignis, wenn die zuständige freigebende Person den Budgetfreigabeschritt im Geschäftsprozess abschließt.
Warum das wichtig ist Die Budgetfreigabe ist häufig ein wesentlicher Engpass. Wenn Sie die Zykluszeit dieser Aktivität messen, können Sie Finanzprüfungen vereinfachen und Einstellungen beschleunigen. Woher beziehen Das Ereignis wird im Audit-Verlauf des Workday-Geschäftsprozesses „Position anlegen“ protokolliert. Es entspricht dem Abschluss der Budgetfreigabe. Erfassung Abschluss-Timestamp des finanziellen Freigabe- oder Budgetfreigabeschritts im Geschäftsprozessprotokoll. Ereignistyp explicit
	Position angelegt	Diese Aktivität kennzeichnet die erfolgreiche Anlage und offizielle Existenz der Position im Workday-System. Sie wird erfasst, wenn der Geschäftsprozess „Position anlegen“ erfolgreich abgeschlossen wurde.
Warum das wichtig ist Dieser wichtige Meilenstein markiert das Ende der Freigabephase und zeigt an, dass die Position besetzt werden kann. Er ist entscheidend für die Messung der gesamten Freigabezykluszeit als KPI. Woher beziehen Das Ereignis wird anhand des Abschluss-Timestamps des Geschäftsprozesses „Position anlegen“ in den Workday-Ereignisprotokollen oder im Audit-Trail erfasst. Erfassung Ereignis, das nach erfolgreichem Abschluss des Geschäftsprozesses „Position anlegen“ protokolliert wird. Ereignistyp explicit
	Position deaktiviert	Dieses Ereignis zeigt an, dass eine Position nicht mehr aktiv ist und nicht besetzt werden kann. Häufig ist dies ein vorbereitender Schritt vor der endgültigen Schließung. Workday erfasst es ausdrücklich nach Abschluss des Geschäftsprozesses „Position deaktivieren“.
Warum das wichtig ist Die Deaktivierung ist ein wichtiger Meilenstein im Lebenszyklus einer Position und von ihrer endgültigen Schließung zu unterscheiden. Die Zeit zwischen Deaktivierung und Schließung zeigt, wie effizient die Organisationsstruktur administrativ bereinigt wird. Woher beziehen Dieses Ereignis wird nach erfolgreichem Abschluss des Geschäftsprozesses „Position deaktivieren“ in den Workday-Audit-Protokollen erfasst. Erfassung Ereignis, das nach erfolgreichem Abschluss des Geschäftsprozesses „Position deaktivieren“ protokolliert wird. Ereignistyp explicit
	Position geschlossen	Dies ist die letzte Aktivität im Lebenszyklus einer Position. Sie steht für die dauerhafte Entfernung der Position aus der Organisation. Workday erfasst das Ereignis nach erfolgreichem Abschluss des Geschäftsprozesses „Position schließen“.
Warum das wichtig ist Als abschließendes Ereignis der meisten Cases markiert diese Aktivität das Ende des Lebenszyklus einer Position. Sie ist wichtig, um die gesamte Prozessdauer zu verstehen und korrekte Personalbestandsdaten zu führen. Woher beziehen Das Ereignis wird anhand des Abschluss-Timestamps des Geschäftsprozesses „Position schließen“ im Workday-Audit-Trail oder in den Geschäftsprozessprotokollen erfasst. Erfassung Ereignis, das nach Abschluss des Geschäftsprozesses „Position schließen“ protokolliert wird. Ereignistyp explicit
	Positionsanfrage gestartet	Damit beginnt der Lebenszyklus des Positionsmanagements: Eine Anfrage zur Anlage einer neuen Position wird offiziell eingereicht. Workday erfasst dies als explizites Ereignis, wenn ein Benutzer den Geschäftsprozess „Position anlegen“ startet.
Warum das wichtig ist Diese Aktivität ist das zentrale Startereignis des Prozesses. Die Zeitspanne zwischen diesem Ereignis und den anschließenden Freigaben ist entscheidend, um die Effizienz des gesamten Zyklus zur Anlage einer Position zu messen. Woher beziehen Dieses Ereignis wird in den Ereignisprotokollen der Workday-Geschäftsprozesse erfasst. Suchen Sie für die betreffende Positions-ID nach dem Start-Timestamp des Geschäftsvorgangs „Position anlegen“. Erfassung Ereignis, das beim Start des Geschäftsprozesses „Position anlegen“ protokolliert wird. Ereignistyp explicit
	Positionsattribute geändert	Dieses Ereignis zeigt an, dass ein oder mehrere Attribute einer bestehenden Position, etwa Stellenbezeichnung oder Abteilung, geändert wurden. Workday protokolliert es ausdrücklich, wenn ein Benutzer den Geschäftsprozess „Positionsbeschränkungen bearbeiten“ erfolgreich abschließt.
Warum das wichtig ist Häufige Änderungen können auf Eingabefehler, veränderte Rollen oder ineffiziente Prozesse hindeuten. Die Analyse dieser Aktivität ist wichtig für das Dashboard „Nacharbeitsanalyse von Positionsdaten“ und für die Verbesserung der Datenqualität. Woher beziehen Das Ereignis stammt aus dem Abschlussprotokoll des Geschäftsprozesses „Positionsbeschränkungen bearbeiten“ oder eines ähnlichen Workday-Prozesses. Der Audit-Trail zeigt, welche Felder geändert wurden. Erfassung Ereignis, das nach erfolgreichem Abschluss des Geschäftsprozesses „Positionsbeschränkungen bearbeiten“ protokolliert wird. Ereignistyp explicit
	Compliance-Prüfung der Position abgeschlossen	Dieses Ereignis zeigt an, dass eine Position formell auf die Einhaltung von Vorgaben geprüft wurde, etwa internen Richtlinien oder externen Vorschriften. Es wird wahrscheinlich als eigener Schritt „Aufgabe“ oder „Checkliste“ innerhalb eines übergeordneten Geschäftsprozesses erfasst.
Warum das wichtig ist Die Erfassung von Compliance-Prüfungen ist wichtig, um Risiken zu mindern und die Einhaltung organisatorischer Standards sicherzustellen. Diese Aktivität unterstützt direkt die KPI „Compliance-Rate bei Positionsvorgängen“. Woher beziehen Das Ereignis wird wahrscheinlich als abgeschlossener Schritt „Aufgabe“ oder als eigener Freigabeschritt in einem Geschäftsprozess wie „Position anlegen“ oder „Position bearbeiten“ erfasst. Eine Systemanalyse ist erforderlich, um den genauen Mechanismus zu bestätigen. Erfassung Abschluss-Timestamp einer Compliance-bezogenen Freigabe oder eines Schritts „Aufgabe“ im Geschäftsprozessprotokoll. Ereignistyp explicit
	Freigabe durch Führungskraft eingereicht	Dieses Ereignis zeigt an, dass die Führungskraft, die die Einstellung verantwortet, oder die Leitung der vorgesetzten Organisation die Prüfung und Freigabe abgeschlossen hat. Workday erfasst den Abschluss einer Freigabe im Geschäftsprozess „Position anlegen“ als separates Ereignis.
Warum das wichtig ist Dies ist ein häufiger früher Meilenstein und ein möglicher Engpass. Wenn Sie die Dauer dieser Freigabe verfolgen, erkennen Sie Verzögerungen in den ersten Phasen des Workflows zur Anlage einer Position. Woher beziehen Das Ereignis stammt aus dem Audit-Trail des Geschäftsprozesses „Position anlegen“. Es entspricht dem Abschluss des konkreten Schritts „Freigabe durch Führungskraft“. Erfassung Abschluss-Timestamp des Freigabeschritts durch die Führungskraft im Geschäftsprozessprotokoll. Ereignistyp explicit
	Freigabe durch Personalabteilung eingereicht	Dieses Ereignis zeigt an, dass ein HR-Partner oder ein anderer Vertreter der Personalabteilung die Positionsanfrage geprüft und freigegeben hat. Workday protokolliert es ausdrücklich, wenn die freigebende Person ihren zugewiesenen Schritt im Geschäftsprozess abschließt.
Warum das wichtig ist Diese Freigabe ist ein wichtiger Kontrollpunkt, um sicherzustellen, dass die Position mit den Unternehmensrichtlinien und der Jobarchitektur übereinstimmt. Verzögerungen an dieser Stelle können die gesamte Zykluszeit deutlich verlängern. Woher beziehen Das Ereignis stammt aus dem Workday-Audit-Trail des betreffenden Geschäftsprozesses und entspricht dem Abschluss des Schritts „Freigabe durch Personalabteilung“. Erfassung Abschluss-Timestamp des Freigabeschritts durch die Personalabteilung im Geschäftsprozessprotokoll. Ereignistyp explicit
	Position eingefroren	Dieses Ereignis steht für die vorübergehende Aussetzung einer Position, sodass sie nicht besetzt werden kann. Es wird erfasst, wenn ein Benutzer den Geschäftsprozess „Position einfrieren“ in Workday erfolgreich abschließt.
Warum das wichtig ist Diese Aktivität ist wichtig für die Steuerung von Personalbestand und Budgets. Wenn Sie erfassen, wie lange eine Position eingefroren bleibt, erkennen Sie ausstehende Entscheidungen und können die Ressourcenplanung verbessern. Woher beziehen Das Ereignis wird beim Abschluss des Geschäftsprozesses „Position einfrieren“ erfasst. In der Regel wird dadurch auch das Statusfeld der Position aktualisiert. Erfassung Ereignis, das nach Abschluss des Geschäftsprozesses „Position einfrieren“ protokolliert wird. Ereignistyp explicit
	Position umklassifiziert	Dieses Ereignis steht für eine formelle Änderung des Jobprofils oder der Klassifizierung einer Position. Es wird erfasst, wenn der Geschäftsprozess „Job ändern“ für eine bestimmte Position erfolgreich abgeschlossen wurde.
Warum das wichtig ist Diese Aktivität hilft dabei, Umstrukturierungen oder wesentliche Änderungen der Aufgaben einer Position nachzuvollziehen. Die Erfassung von Umklassifizierungen unterstützt die Analyse der Personalentwicklung und der Stabilität der Jobarchitektur. Woher beziehen Das Ereignis stammt aus den Abschlussprotokollen des Geschäftsprozesses „Job ändern“, wenn dieser auf eine Position und nicht auf einen Mitarbeitenden angewendet wird. Erfassung Ereignis, das nach erfolgreichem Abschluss des Geschäftsprozesses „Job ändern“ für eine Position protokolliert wird. Ereignistyp explicit
	Position wieder freigegeben	Dies ist die Umkehrung des Einfrierens: Eine ausgesetzte Position wird wieder aktiviert und kann erneut besetzt werden. Das Ereignis wird in der Regel anhand einer Änderung des Positionsstatus von „Eingefroren“ zu „Aktiv“ ermittelt.
Warum das wichtig ist Dieses Ereignis markiert die Klärung einer eingefrorenen Position. Für die KPI „Dauer bis zur Klärung eingefrorener Positionen“ ist die Zeitspanne zwischen „Position eingefroren“ und diesem Ereignis entscheidend. Woher beziehen Das Ereignis lässt sich möglicherweise anhand datumsabhängiger Änderungen des Positionsstatus im Verlauf oder Audit-Protokoll ermitteln. In manchen Konfigurationen wird es auch als explizites Ereignis des Geschäftsprozesses „Einfrieren aufheben“ erfasst. Erfassung Änderung des Positionsstatus von „Eingefroren“ zu „Aktiv“ anhand des datumsabhängigen Verlaufs erkennen. Ereignistyp inferred
	Positionsanfrage abgelehnt	Diese Aktivität kennzeichnet das erfolglose Ende einer Anfrage zur Anlage einer Position: Eine freigebende Person hat die Anfrage abgelehnt. Workday erfasst dies als abschließenden Status „Abgelehnt“ des Geschäftsprozesses „Position anlegen“.
Warum das wichtig ist Die Analyse abgelehnter Anfragen zeigt häufige Ablehnungsgründe auf, etwa Budgetbeschränkungen oder Abweichungen von Richtlinien. So können Sie den Prozess verbessern und Antragstellende besser unterstützen. Woher beziehen Das Ereignis wird anhand des abschließenden Status der Instanz des Geschäftsprozesses „Position anlegen“ erfasst. Der Ereignis-Timestamp entspricht dem Zeitpunkt der Ablehnung. Erfassung Ereignis, das protokolliert wird, wenn eine freigebende Person in einem Schritt des Geschäftsprozesses die Aktion „Ablehnen“ auswählt. Ereignistyp explicit

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Workday HCM

Schritte

Bei Workday anmelden: Melden Sie sich mit einem Benutzerkonto bei Ihrem Workday-Mandanten an, das über die Berechtigungen zum Erstellen benutzerdefinierter Berichte und zum Zugriff auf die erforderlichen Human-Capital-Management-Datenbereiche (HCM) verfügt.
Benutzerdefinierten Bericht erstellen: Suchen Sie über die Suchleiste nach der Aufgabe „Create Custom Report“ und öffnen Sie sie.
Berichtstyp und Datenquelle auswählen: Geben Sie Ihrem Bericht einen Namen, zum Beispiel „ProcessMind Position Management Events“. Wählen Sie als Berichtstyp „Advanced“. Wählen Sie als Datenquelle „Business Process Transactions“. Diese Quelle enthält detaillierte Informationen zu einzelnen Ereignissen und Prozessschritten.
Berichtsspalten festlegen: Fügen Sie im Tab „Columns“ die Felder hinzu, die als Spalten in Ihrem Event Log erscheinen sollen. Ordnen Sie die Workday-Objekte und -Felder den erforderlichen Attributen zu. Zum Beispiel:
- PositionId: Ordnen Sie dieses Feld der „Position ID“ aus dem Kontext des Geschäftsprozesses zu.
- EventTime: Ordnen Sie dieses Feld für jeden Schritt dem „Completed Date“ oder „Corrected Completed Moment“ zu.
- User: Ordnen Sie dieses Feld für die Transaktion „Completed By“ zu.
- PositionStatus, Department, CostCenter, JobFamily: Ordnen Sie diese Felder den entsprechenden Feldern des Geschäftsobjekts „Position“ zu.
Berechnete Felder für Aktivitätsnamen erstellen: Für diese Extraktion müssen die Schritte des Geschäftsprozesses in standardisierte Aktivitätsnamen übersetzt werden. Öffnen Sie das Menü „Related Business Objects“ und erstellen Sie ein „Calculated Field“. Wählen Sie den Typ „Evaluate Expression“, um eine Logik mit Bedingungen aufzubauen. Zum Beispiel:
- Wenn „Business Process Type“ den Wert „Create Position“ und „Transaction Status“ den Wert „Successfully Completed“ hat, geben Sie den Text „Position Created“ zurück.
- Wenn „Business Process Type“ den Wert „Create Position“, „Step“ den Wert „[Name Ihres Genehmigungsschritts durch die Führungskraft]“ und „Status“ den Wert „Completed“ hat, geben Sie den Text „Manager Approval Submitted“ zurück.
- Erstellen Sie für jede der 13 erforderlichen Aktivitäten eine Bedingung.
Berichtsfilter konfigurieren: Fügen Sie im Tab „Filter“ Eingabeaufforderungen und Filter hinzu, um den Datenumfang festzulegen. Erstellen Sie eine Eingabeaufforderung für „Completed Date“, damit sich ein Datumsbereich auswählen lässt. Filtern Sie nach relevanten „Business Process Types“, zum Beispiel „Create Position“, „Edit Position Restrictions“, „Change Job“, „Freeze Position“, „Inactivate Position“ und „Close Position“.
Sortierung und Ausgabe festlegen: Sortieren Sie die Ergebnisse im Tab „Sort“ zuerst nach PositionId und anschließend nach EventTime. So werden die Ereignisse jedes Cases chronologisch angeordnet.
Als Webservice bereitstellen (RaaS): Sobald der Bericht in der Benutzeroberfläche korrekt ausgeführt wird, wählen Sie „Actions“ > „Web Service“ > „Enable as Web Service“. Legen Sie in den Optionen für „Content Type“ den Wert „JSON“ fest, um die Integration zu vereinfachen.
Endpunkt absichern und testen: Legen Sie in den Sicherheitseinstellungen des Webservice fest, welche Benutzer oder Systeme darauf zugreifen dürfen. Notieren Sie sich die generierte JSON- oder WSDL-URL. Testen Sie den Endpunkt mit einem Tool wie Postman oder einem einfachen Skript und prüfen Sie, ob Daten zurückgegeben werden.
Extraktion automatisieren: Rufen Sie die RaaS-URL mithilfe Ihrer Integrationsplattform oder eines Skripts nach einem Zeitplan auf. Das Skript sollte den gewünschten Datumsbereich als Parameter übergeben.
Daten für ProcessMind formatieren: Das Skript sollte die JSON-Antwort von Workday einlesen und in eine flache CSV-Datei umwandeln. Achten Sie darauf, dass die Spaltenüberschriften in der CSV den erforderlichen Attributnamen entsprechen, zum Beispiel PositionId, ActivityName, EventTime, User.
In ProcessMind hochladen: Die fertige CSV-Datei kann nun zur Analyse in ProcessMind hochgeladen werden.

Konfiguration

Berichtstyp: Advanced. Dieser Typ ist erforderlich, um berechnete Felder zu erstellen und Daten aus verschiedenen Geschäftsobjekten zu verknüpfen.
Primäre Datenquelle: „Business Process Transactions“. Diese ereignisorientierte Datenquelle enthält wichtige Angaben wie Status, Timestamps und Beteiligte für jeden Schritt eines Geschäftsprozesses.
Wichtige Filter:
- Business Process Type: Begrenzen Sie den Bericht auf relevante Prozesse wie „Create Position“, „Close Position“, „Freeze Position“, „Change Job“, „Edit Position Restrictions“ und „Inactivate Position“. Das ist entscheidend für die Leistung.
- Completed Date: Verwenden Sie für dieses Feld einen Filter mit Eingabeaufforderung, damit Benutzer den Datumsbereich der Extraktion angeben können. Für den ersten Datenabruf empfehlen wir einen Zeitraum von 3 bis 6 Monaten.
Berechnete Felder: Verwenden Sie umfangreich berechnete Felder vom Typ „Evaluate Expression“ und „Lookup Related Value“, um den standardisierten Wert für ActivityName abzuleiten und Attribute aus dem zentralen Objekt „Position“ in den Ereignisstrom zu übernehmen.
Webservice-Ausgabe: Legen Sie für die RaaS-Ausgabe das Format JSON fest. XML ist ebenfalls verfügbar, JSON lässt sich von modernen Anwendungen jedoch in der Regel einfacher verarbeiten.
Berechtigungen: Der Benutzer, der den Bericht erstellt, benötigt Sicherheitsberechtigungen für Datenbereiche wie „Business Process Transactions“, „Position Management“ und „Worker Data“. Welche Daten der RaaS-Aufruf zurückgibt, hängt von diesen Berechtigungen ab.

a Beispielabfrage sql

/*
 This is a logical representation of the Workday Advanced Report configuration.
 It is built using the Workday Report Writer UI, not by writing code.
 Each 'SELECT' block represents a set of conditions within a single 'Evaluate Expression' calculated field for the 'ActivityName' column.
 The report's primary data source is 'Business Process Transactions'.
*/

// Calculated Field for ActivityName: 'cf_ActivityName'
// Type: Evaluate Expression

// Condition 1: Position Request Initiated
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process Transaction'.Is First Step = true)
THEN 'Position Request Initiated'
// Column Mapping for this condition:
// PositionId: 'Position' From Business Process -> Position ID
// ActivityName: 'cf_ActivityName' (this calculated field)
// EventTime: 'Business Process' -> Initiation Moment
// User: 'Business Process' -> Initiator

// Condition 2: Manager Approval Submitted
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process Step'.Name CONTAINS 'Manager Approval' AND 'Business Process Transaction'.Status = 'Completed')
THEN 'Manager Approval Submitted'
// Column Mapping for this condition:
// EventTime: 'Business Process Transaction' -> Completed Moment
// User: 'Business Process Transaction' -> Completed By

// Condition 3: HR Approval Submitted
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process Step'.Name CONTAINS 'HR Approval' AND 'Business Process Transaction'.Status = 'Completed')
THEN 'HR Approval Submitted'
// Column Mapping for this condition:
// EventTime: 'Business Process Transaction' -> Completed Moment
// User: 'Business Process Transaction' -> Completed By

// Condition 4: Budget Approved
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process Step'.Name CONTAINS 'Budget Approval' AND 'Business Process Transaction'.Status = 'Completed')
THEN 'Budget Approved'
// Column Mapping for this condition:
// EventTime: 'Business Process Transaction' -> Completed Moment
// User: 'Business Process Transaction' -> Completed By

// Condition 5: Position Request Denied
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process'.Status = 'Denied')
THEN 'Position Request Denied'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process Transaction' -> Completed By (on the denial step)

// Condition 6: Position Created
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Created'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business process' -> Initiator

// Condition 7: Position Attributes Modified
WHEN ('Business Process'.Type = 'Edit Position Restrictions' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Attributes Modified'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 8: Position Reclassified
WHEN ('Business Process'.Type = 'Change Job' AND 'Business Process'.Context.Is Position = true AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Reclassified'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 9: Position Compliance Reviewed
WHEN ('Business Process Step'.Name CONTAINS 'Compliance Review' AND 'Business Process Transaction'.Status = 'Completed')
THEN 'Position Compliance Reviewed'
// Column Mapping for this condition:
// EventTime: 'Business Process Transaction' -> Completed Moment
// User: 'Business Process Transaction' -> Completed By

// Condition 10: Position Frozen
WHEN ('Business Process'.Type = 'Freeze Position' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Frozen'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 11: Position Unfrozen
// Note: This often relies on a different data source, 'Position History', to track status changes.
// If using 'Business Process Transactions', this assumes an 'Unfreeze' BP exists or is part of another BP.
// The example below assumes an 'Edit Position' BP is used to change the status.
WHEN ('Business Process'.Type = 'Edit Position Restrictions' AND 'Position'.Is Frozen (Prior) = true AND 'Position'.Is Frozen = false AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Unfrozen'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 12: Position Deactivated
WHEN ('Business Process'.Type = 'Inactivate Position' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Deactivated'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 13: Position Closed
WHEN ('Business Process'.Type = 'Close Position' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Closed'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Default case for the calculated field
ELSE 'Other Activity'

/*
Final Report Structure:
- Data Source: Business Process Transactions
- Columns:
  - Position ID (from Position)
  - cf_ActivityName
  - Event Time (Calculated field to pick correct timestamp based on activity)
  - User (Calculated field to pick correct user)
  - End Time (same as Event Time for discrete events)
  - Position Status (from Position)
  - Reason For Change (from Business Process -> Reason)
  - Department (Supervisory Organization from Position)
  - Cost Center (from Position)
  - Job Family (from Job Profile)
- Filter:
  - Business Process Type IN ('Create Position', 'Edit Position Restrictions', 'Change Job', 'Freeze Position', 'Inactivate Position', 'Close Position', ...)
  - Completed Date IS IN [Prompted Date Range]
  - cf_ActivityName IS NOT 'Other Activity'
*/

Schritte

Voraussetzung: Workday Custom Report erstellen. Erstellen Sie vor der Ausführung des Skripts in Workday einen benutzerdefinierten Bericht, der die erforderlichen Daten bereitstellt. Verwenden Sie die Datenquelle „Business Process Transactions“. Stellen Sie die für das Event Log erforderlichen Felder bereit, darunter Position ID, Business Process Type, Step Name, Status, Effective Date, Completed Date und Initiator. Aktivieren Sie den Bericht als Webservice, indem Sie auf dem Tab „Advanced“ die Option „Enable as Web Service“ auswählen. Richten Sie außerdem die erforderlichen Berechtigungen für Ihren Integration System User (ISU) ein.
Voraussetzung: Workday-Integrationsbenutzer konfigurieren. Stellen Sie sicher, dass Sie über einen Integration System User (ISU) mit Berechtigungen für den im vorherigen Schritt erstellten benutzerdefinierten Bericht verfügen. Notieren Sie sich Benutzername, Passwort und die generierte JSON-Endpunkt-URL des Berichts für RaaS (Reports-as-a-Service).
Python-Umgebung einrichten. Installieren Sie Python auf dem Rechner, auf dem die Extraktion ausgeführt wird. Installieren Sie die erforderlichen Bibliotheken mit pip: pip install requests pandas.
Python-Skript konfigurieren. Laden Sie das bereitgestellte Python-Skript herunter. Öffnen Sie die Datei in einem Texteditor und passen Sie die Platzhaltervariablen am Anfang des Skripts an. Geben Sie Ihre Workday-RaaS-URL, Ihren Benutzernamen und Ihr Passwort an. Legen Sie außerdem mit START_DATE und END_DATE den gewünschten Extraktionszeitraum fest.
Skriptlogik verstehen. Das Skript authentifiziert sich bei Workday, ruft den Webservice des benutzerdefinierten Berichts auf und übergibt den Datumsbereich als Parameter. Workday gibt die Daten im JSON-Format zurück. Wenn der Bericht mehr als eine Ergebnisseite zurückgibt, verarbeitet das Skript die Seiten automatisch.
Skript ausführen. Öffnen Sie ein Terminal oder eine Eingabeaufforderung, wechseln Sie in das Verzeichnis, in dem Sie das Skript gespeichert haben, und führen Sie den folgenden Befehl aus: python workday_extraction.py.
Aktivitäten zuordnen. Das Skript enthält ein Zuordnungswörterbuch (activity_map), das Kombinationen aus Workday-Geschäftsprozessen und Schrittstatus den von ProcessMind benötigten standardisierten Aktivitätsnamen zuordnet. Möglicherweise müssen Sie die Schlüssel in diesem Wörterbuch an die genauen Namen der Geschäftsprozesse in Ihrem Workday-Mandanten anpassen.
Daten umwandeln. Das Skript verarbeitet jeden Datensatz aus dem Workday-Bericht. Es wendet die Aktivitätszuordnung an, extrahiert die erforderlichen Attribute und formatiert die Timestamps korrekt. Jedes gültige Ereignis wird einer Liste hinzugefügt.
Ausgabe erstellen. Nach der Verarbeitung aller Daten wandelt das Skript die Ereignisliste in einen pandas-DataFrame um. Dadurch werden die Daten tabellarisch mit den erforderlichen Spaltennamen strukturiert: PositionId, ActivityName, EventTime, User und weitere.
CSV-Datei für ProcessMind exportieren. Das Skript speichert den fertigen DataFrame in einer CSV-Datei namens position_management_event_log.csv. Die Datei wird mit UTF-8 codiert und kann ohne weitere Änderungen in ProcessMind hochgeladen werden.

Konfiguration

Workday Custom Report (RaaS): Die primäre Datenquelle ist ein benutzerdefinierter Workday-Bericht, der als Webservice bereitgestellt wird. Dieser Bericht muss auf der Datenquelle „Business Process Transactions“ basieren.
Berichtsfelder: Der Bericht muss unter anderem Position ID, Business Process Definition, Business Process Step, Transaction Status, Effective Timestamp, Completion Timestamp und Initiator enthalten. Ergänzen Sie weitere erforderliche Attribute wie Cost Center oder Supervisory Organization.
Integration System User (ISU): Für die Authentifizierung benötigen Sie einen ISU mit Benutzername und Passwort. Dieser Benutzer muss einer Sicherheitsgruppe angehören, die auf den Webservice-Endpunkt des benutzerdefinierten Berichts zugreifen darf.
Datumsbereich: Das Skript verwendet die Parameter START_DATE und END_DATE. Für die erste Extraktion empfehlen wir einen Zeitraum von 3 bis 6 Monaten, damit das Datenvolumen überschaubar bleibt und die Ausführung nicht zu lange dauert. Für spätere Extraktionen kann ein kürzerer Zeitraum für Änderungen verwendet werden.
API-Endpunkt: Das Skript benötigt die JSON-Endpunkt-URL des benutzerdefinierten Berichts. Sie finden diese URL auf dem Tab „Web Service“ der Berichtsdefinition in Workday.
Aktivitätszuordnung: Die Skriptlogik verwendet eine konfigurierbare Zuordnung von Workday-Prozessnamen und Statuswerten zu den endgültigen Aktivitätsnamen. Passen Sie diese Zuordnung gegebenenfalls an die Konfiguration Ihrer Workday-Geschäftsprozesse an.

a Beispielabfrage python

import requests
import pandas as pd
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your Workday RaaS endpoint, username, and password
WORKDAY_RAAS_URL = class="hl-string">'[Your_Workday_RaaS_JSON_Endpoint_URL]'
WORKDAY_USERNAME = class="hl-string">'[Your_ISU_Username]'
WORKDAY_PASSWORD = class="hl-string">'[Your_ISU_Password]'

class=class="hl-string">"hl-comment"># Set the date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">'2023-01-01'
END_DATE = class="hl-string">'2023-12-31'

class=class="hl-string">"hl-comment"># --- Activity Mapping --- #
class=class="hl-string">"hl-comment"># This dictionary maps Workday processes and statuses to standardized activity names.
class=class="hl-string">"hl-comment"># The keys are tuples: (class="hl-string">'Business Process Name', class="hl-string">'Step Name / Status').
class=class="hl-string">"hl-comment"># You MAY need to adjust the class="hl-string">'Business Process Name' to match your Workday configuration.
activity_map = {
    (class="hl-string">'Create Position', class="hl-string">'Initiation Step'): class="hl-string">'Position Request Initiated',
    (class="hl-string">'Create Position', class="hl-string">'Manager Approval'): class="hl-string">'Manager Approval Submitted',
    (class="hl-string">'Create Position', class="hl-string">'HR Approval'): class="hl-string">'HR Approval Submitted',
    (class="hl-string">'Create Position', class="hl-string">'Budget Approval'): class="hl-string">'Budget Approved',
    (class="hl-string">'Create Position', class="hl-string">'Denied'): class="hl-string">'Position Request Denied',
    (class="hl-string">'Create Position', class="hl-string">'Successfully Completed'): class="hl-string">'Position Created',
    (class="hl-string">'Edit Position Restrictions', class="hl-string">'Successfully Completed'): class="hl-string">'Position Attributes Modified',
    (class="hl-string">'Change Job', class="hl-string">'Successfully Completed'): class="hl-string">'Position Reclassified',
    (class="hl-string">'Freeze Position', class="hl-string">'Successfully Completed'): class="hl-string">'Position Frozen',
    class=class="hl-string">"hl-comment"># Assuming a business process exists for this. If not, this requires a different approach.
    (class="hl-string">'Unfreeze Position', class="hl-string">'Successfully Completed'): class="hl-string">'Position Unfrozen',
    (class="hl-string">'Inactivate Position', class="hl-string">'Successfully Completed'): class="hl-string">'Position Deactivated',
    (class="hl-string">'Close Position', class="hl-string">'Successfully Completed'): class="hl-string">'Position Closed',
    class=class="hl-string">"hl-comment"># Mapping a class="hl-string">'To Do' step within a parent process for compliance review
    (class="hl-string">'Create Position', class="hl-string">'Compliance Review To Do'): class="hl-string">'Position Compliance Reviewed',
    (class="hl-string">'Edit Position Restrictions', class="hl-string">'Compliance Review To Do'): class="hl-string">'Position Compliance Reviewed'
}

def get_activity_name(process, step, status):
    class="hl-string">"""Determines the activity name based on the mapping."""
    class=class="hl-string">"hl-comment"># Denied and successful completion are based on the overall process status
    if status == class="hl-string">'Denied':
        return activity_map.get((process, class="hl-string">'Denied'))
    if status == class="hl-string">'Successfully Completed':
        return activity_map.get((process, class="hl-string">'Successfully Completed'))

    class=class="hl-string">"hl-comment"># Other activities are based on specific steps
    return activity_map.get((process, step))

def fetch_workday_data():
    class="hl-string">"""Fetches data from the Workday RaaS endpoint with pagination."""
    all_entries = []
    page = 1
    while True:
        params = {
            class="hl-string">'format': class="hl-string">'json',
            class="hl-string">'page': page,
            class="hl-string">'StartDate': fclass="hl-string">'{START_DATE}T00:00:00Z',
            class="hl-string">'EndDate': fclass="hl-string">'{END_DATE}T23:59:59Z'
        }
        print(fclass="hl-string">"Fetching page {page}...")
        try:
            response = requests.get(
                WORKDAY_RAAS_URL,
                auth=(WORKDAY_USERNAME, WORKDAY_PASSWORD),
                params=params
            )
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
            data = response.json()
            entries = data.get(class="hl-string">'Report_Entry', [])
            if not entries:
                print(class="hl-string">"No more entries found. Concluding fetch.")
                break
            all_entries.extend(entries)
            class=class="hl-string">"hl-comment"># Check if this is the last page
            if len(entries) < data.get(class="hl-string">'Report_Data', {}).get(class="hl-string">'Page_Size', 1000):
                 break
            page += 1
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from Workday: {e}")
            break
        except ValueError:
            print(class="hl-string">"Error parsing JSON response. Check the URL and credentials.")
            print(class="hl-string">"Response text:", response.text)
            break

    print(fclass="hl-string">"Total entries fetched: {len(all_entries)}")
    return all_entries

def main():
    class="hl-string">"""Main function to extract, transform, and save data."""
    report_entries = fetch_workday_data()
    if not report_entries:
        print(class="hl-string">"No data extracted. Exiting.")
        return

    event_log = []
    for entry in report_entries:
        class=class="hl-string">"hl-comment"># Assuming your RaaS report column names are aliased for clarity
        process_name = entry.get(class="hl-string">'BusinessProcessType')
        step_name = entry.get(class="hl-string">'BusinessProcessStep')
        status = entry.get(class="hl-string">'TransactionStatus')
        position_id = entry.get(class="hl-string">'PositionID')
        
        activity = get_activity_name(process_name, step_name, status)
        
        if not activity or not position_id:
            continue class=class="hl-string">"hl-comment"># Skip records that don't map to a required activity or have no Position ID

        event_log.append({
            class="hl-string">'PositionId': position_id,
            class="hl-string">'ActivityName': activity,
            class="hl-string">'EventTime': entry.get(class="hl-string">'CompletedDateTime', entry.get(class="hl-string">'EffectiveDateTime')),
            class="hl-string">'EndTime': entry.get(class="hl-string">'CompletedDateTime'),
            class="hl-string">'User': entry.get(class="hl-string">'InitiatorName'),
            class="hl-string">'PositionStatus': entry.get(class="hl-string">'PositionStatus'), class=class="hl-string">"hl-comment"># Assumes this field is in the report
            class="hl-string">'ReasonForChange': entry.get(class="hl-string">'Reason'),
            class="hl-string">'Department': entry.get(class="hl-string">'SupervisoryOrganization'),
            class="hl-string">'CostCenter': entry.get(class="hl-string">'CostCenter'),
            class="hl-string">'JobFamily': entry.get(class="hl-string">'JobFamily')
        })

    if not event_log:
        print(class="hl-string">"No processable events found after mapping. Exiting.")
        return

    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Data Cleaning and Formatting
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'], errors=class="hl-string">'coerce')
    df.dropna(subset=[class="hl-string">'PositionId', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    df.sort_values(by=[class="hl-string">'PositionId', class="hl-string">'EventTime'], inplace=True)

    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    final_columns = [
        class="hl-string">'PositionId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'User', class="hl-string">'EndTime', 
        class="hl-string">'PositionStatus', class="hl-string">'ReasonForChange', class="hl-string">'Department', class="hl-string">'CostCenter', class="hl-string">'JobFamily'
    ]
    df = df.reindex(columns=final_columns)

    output_filename = class="hl-string">'position_management_event_log.csv'
    df.to_csv(output_filename, index=False, encoding=class="hl-string">'utf-8')
    print(fclass="hl-string">"Successfully created event log: {output_filename}")

if __name__ == class="hl-string">'__main__':
    main()

Schritte

Prüfen Sie, ob für die gewählte Middleware- oder ETL-Plattform, beispielsweise MuleSoft, Boomi oder Informatica, eine lizenzierte Workday-Konnektor-Funktion verfügbar ist und die Integrationslaufzeit Workday erreichen kann. Lassen Sie sich von der Workday-Administration die erforderlichen Zugangsdaten für den Workday-Integrationssystembenutzer, Sicherheitsgruppenzuweisungen, Berichts- oder API-Berechtigungen und die Mandanten-Endpunktkonfiguration geben.
Ermitteln Sie in Workday die freigegebenen Quellberichte oder APIs für Geschäftsprozessverläufe, abgeschlossene Genehmigungsschritte, Positionsattribute, Statusänderungen, Mitarbeiter- oder Benutzerreferenzen und Gültigkeits-Timestamps. Verwenden Sie für die genauen Berichts- oder API-Namen den Platzhalter [An Ihr System anpassen], da diese je nach Mandantenkonfiguration variieren. Stellen Sie sicher, dass die Quelle Position ID und genügend Kontext zum Geschäftsprozess bereitstellt, um alle erforderlichen Aktivitäten zu unterscheiden.
Konfigurieren Sie den Konnektor in der Middleware-Plattform mit der Workday-Mandantenverbindung, der Authentifizierungsmethode, dem Anforderungs-Timeout, der Seitennavigation, der Wiederholungsrichtlinie und den Parametern für die inkrementelle Extraktion. Verwenden Sie [Ihr Startdatum] und [Ihr Enddatum] als Datumsparameter und wenden Sie genehmigte Filter für Unternehmen oder Führungsorganisationen an.
Extrahieren Sie die Quelldatensätze in Staging-Objekte der Middleware-Plattform. Bewahren Sie Quellkennungen, Ereignis- und Abschluss-Timestamps, Akteurskennungen, Positionsstatus, Grund, Abteilung, Kostenstelle, Jobfamilie, Geschäftsprozessname, Schrittname, Schrittstatus und datumsabhängige Positionsattribute auf. Überlassen Sie es nicht ProcessMind, Ereignisse abzuleiten.
Wandeln Sie die Staging-Daten in eine Ereigniszeile für jede ausdrücklich unterstützte Aktivität um. Ordnen Sie den Start des Quellgeschäftsprozesses Position Request Initiated zu, abgeschlossene Genehmigungsschritte durch Führungskräfte, HR und Budget den jeweiligen Aktivitäten, einen abschließenden Ablehnungsstatus Position Request Denied, den erfolgreichen Abschluss von Create Position Position Created und den erfolgreichen Abschluss der festgelegten Positionsänderungsprozesse den jeweiligen Aktivitäten. Ordnen Sie eine Compliance-Prüfung nur dann zu, wenn ein ausdrücklich abgeschlossener To Do- oder Checklistenschritt vorliegt. Ordnen Sie Position Unfrozen nur zu, wenn die Umwandlung ausdrücklich einen Statuswechsel von Frozen zu Active erfasst.
Führen Sie die vollständige SQL-Umwandlung im Abfragefeld für die bereitgestellten Quellansichten aus. Ersetzen Sie dabei ausschließlich Platzhalter für Verbindungen, Zugangsdaten, Datumsangaben und unternehmensspezifische Werte. Die Quellansichts- und Spaltennamen in der Abfrage sind fachliche Platzhalter und müssen durch die tatsächlichen Objekte und Felder des konfigurierten Workday-Konnektors ersetzt werden.
Prüfen Sie, ob PositionId, ActivityName und EventTime für jede Ausgabezeile ausgefüllt sind, die Timestamps auf eine vereinbarte Zeitzone normiert wurden und doppelte Quelldatensätze anhand der Quellereigniskennung oder eines dokumentierten zusammengesetzten Schlüssels entfernt wurden. Übernehmen Sie User, EndTime, PositionStatus, ReasonForChange, Department, CostCenter und JobFamily, sofern verfügbar.
Exportieren Sie das Ergebnis als UTF-8-kodierte CSV-Datei oder in einem anderen von ProcessMind unterstützten Event-Log-Format. Verwenden Sie PositionId als Case-ID, ActivityName als Aktivitätsspalte und EventTime als Ereignis-Timestamp. Fügen Sie empfohlene Attribute als zusätzliche Spalten hinzu, behalten Sie eine Zeile pro Ereignis bei und laden Sie die Datei in ProcessMind hoch. Gehen Sie nicht davon aus, dass fehlende Aktivitäten dort abgeleitet werden.

Konfiguration

Konnektor: Konfigurieren Sie den freigegebenen Workday-Konnektor in MuleSoft, Boomi, Informatica oder der ausgewählten ETL-Plattform. Die verfügbaren Konnektoraktionen, Berichtsnamen und API-Ressourcen hängen vom Mandanten und der Konnektorversion ab.
Quellkonfiguration: Verwenden Sie [An Ihr System anpassen] für die Workday-Berichte oder APIs, die Geschäftsprozessereignisse, Genehmigungsschritte, Positionsstatusverläufe und datumsabhängige Positionsattribute bereitstellen.
Datumsbereich: Beginnen Sie mit 3 bis 6 Monaten abgeschlossener Ereignisse. Erweitern Sie den Zeitraum erst, nachdem Sie Laufzeit, Seitennavigation, Aufbewahrungsdauer der Quelle und ProcessMind-Importgrenzen geprüft haben.
Inkrementelles Laden: Verwenden Sie EventTime oder den Änderungs-Timestamp des Quellereignisses als Wasserzeichen. Planen Sie zwischen den Läufen einen kurzen Überlappungszeitraum ein und entfernen Sie Duplikate anhand der Quellereigniskennung oder eines dokumentierten zusammengesetzten Schlüssels.
Erforderliche Ausgabespalten: PositionId, ActivityName und EventTime müssen vorhanden und ausgefüllt sein. PositionId ist die Case-ID.
Empfohlene Ausgabespalten: User, EndTime, PositionStatus, ReasonForChange, Department, CostCenter und JobFamily.
Aktivitätsfilter: Filtern Sie nach den konfigurierten Geschäftsprozessnamen Create Position, Edit Position Restrictions, Change Job, Freeze Position, Inactivate Position und Close Position sowie nach dem konfigurierten Compliance-To-Do- oder Checklistenschritt. Verwenden Sie die genauen Werte des Mandanten statt angenommener Bezeichnungen.
Statusverarbeitung: Extrahieren Sie Position Unfrozen nur bei einem ausdrücklich verfügbaren Statuswechsel von Frozen zu Active. Erstellen Sie kein Ereignis allein deshalb, weil der aktuelle Status Active ist.
Leistung: Aktivieren Sie die Seitennavigation des Konnektors, begrenzen Sie Datumsfilter, filtern Sie bereits an der Quelle, verwenden Sie parallele Extraktionen nur, wenn diese unterstützt werden, und verarbeiten Sie Daten schrittweise in einer Staging-Umgebung. Vermeiden Sie uneingeschränkte Extraktionen des gesamten Mandanten.
Sicherheit: Der Integrationsbenutzer benötigt Leseberechtigungen für Geschäftsprozessverläufe, Genehmigungsschritte, Positionsdaten, Statusverläufe, Organisationsattribute und Benutzerreferenzen. Die Workday-Administration muss Sicherheitsbereiche und Berichtszugriff freigeben.
Voraussetzungen: Prüfen Sie die Lizenz für den Workday-Konnektor, die Middleware-Laufzeit, die sichere Speicherung von Zugangsdaten, den Netzwerkzugriff, die Verfügbarkeit des Quellberichts oder der API sowie die ProcessMind-Importberechtigungen.

a Beispielabfrage sql

WITH source_events AS (
    SELECT
        [Position ID] AS PositionId,
        [Business Process Name] AS BusinessProcessName,
        [Step Name] AS StepName,
        [Step Status] AS StepStatus,
        [Event Type] AS EventType,
        [Event Timestamp] AS SourceEventTime,
        [Completion Timestamp] AS SourceEndTime,
        [Performed By] AS SourceUser,
        [Position Status] AS SourcePositionStatus,
        [Reason] AS SourceReasonForChange,
        [Department] AS SourceDepartment,
        [Cost Center] AS SourceCostCenter,
        [Job Family] AS SourceJobFamily,
        [Previous Position Status] AS PreviousPositionStatus,
        [Source Event ID] AS SourceEventId
    FROM [Your Workday staged event source]
    WHERE [Event Timestamp] >= CAST('[Your start date]' AS TIMESTAMP)
      AND [Event Timestamp] < CAST('[Your end date]' AS TIMESTAMP)
      AND [Position ID] IS NOT NULL
),
position_attributes AS (
    SELECT
        [Position ID] AS PositionId,
        [Position Status] AS PositionStatus,
        [Reason] AS ReasonForChange,
        [Department] AS Department,
        [Cost Center] AS CostCenter,
        [Job Family] AS JobFamily
    FROM [Your Workday staged position attribute source]
),
normalized_events AS (
    SELECT
        s.PositionId,
        'Position Request Initiated' AS ActivityName,
        s.SourceEventTime AS EventTime,
        s.SourceEndTime AS EndTime,
        s.SourceUser AS User,
        COALESCE(s.SourcePositionStatus, p.PositionStatus) AS PositionStatus,
        s.SourceReasonForChange AS ReasonForChange,
        COALESCE(s.SourceDepartment, p.Department) AS Department,
        COALESCE(s.SourceCostCenter, p.CostCenter) AS CostCenter,
        COALESCE(s.SourceJobFamily, p.JobFamily) AS JobFamily,
        s.SourceEventId AS SourceEventId
    FROM source_events s
    LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Create Position'
      AND (s.EventType = 'Initiated' OR s.StepName = 'Create Position')
    UNION ALL
    SELECT s.PositionId, 'Manager Approval Submitted', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Create Position' AND s.StepName = 'Manager Approval' AND s.StepStatus = 'Completed'
    UNION ALL
    SELECT s.PositionId, 'HR Approval Submitted', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Create Position' AND s.StepName = 'HR Approval' AND s.StepStatus = 'Completed'
    UNION ALL
    SELECT s.PositionId, 'Budget Approved', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Create Position' AND s.StepName = 'Budget Approval' AND s.StepStatus = 'Completed'
    UNION ALL
    SELECT s.PositionId, 'Position Request Denied', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Create Position' AND (s.StepStatus = 'Denied' OR s.EventType = 'Denied')
    UNION ALL
    SELECT s.PositionId, 'Position Created', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Create Position' AND s.StepStatus = 'Completed' AND s.EventType = 'Completed'
    UNION ALL
    SELECT s.PositionId, 'Position Attributes Modified', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Edit Position Restrictions' AND s.StepStatus = 'Completed'
    UNION ALL
    SELECT s.PositionId, 'Position Reclassified', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Change Job' AND s.StepStatus = 'Completed'
    UNION ALL
    SELECT s.PositionId, 'Position Compliance Reviewed', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.StepStatus = 'Completed' AND (s.StepName = 'Compliance Review' OR s.StepName = 'Compliance Checklist' OR s.StepName = 'Compliance To Do')
    UNION ALL
    SELECT s.PositionId, 'Position Frozen', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Freeze Position' AND s.StepStatus = 'Completed'
    UNION ALL
    SELECT s.PositionId, 'Position Unfrozen', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.PreviousPositionStatus = 'Frozen' AND s.SourcePositionStatus = 'Active'
    UNION ALL
    SELECT s.PositionId, 'Position Deactivated', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Inactivate Position' AND s.StepStatus = 'Completed'
    UNION ALL
    SELECT s.PositionId, 'Position Closed', s.SourceEventTime, s.SourceEndTime, s.SourceUser, COALESCE(s.SourcePositionStatus, p.PositionStatus), s.SourceReasonForChange, COALESCE(s.SourceDepartment, p.Department), COALESCE(s.SourceCostCenter, p.CostCenter), COALESCE(s.SourceJobFamily, p.JobFamily), s.SourceEventId
    FROM source_events s LEFT JOIN position_attributes p ON p.PositionId = s.PositionId
    WHERE s.BusinessProcessName = 'Close Position' AND s.StepStatus = 'Completed'
),
deduplicated_events AS (
    SELECT
        PositionId,
        ActivityName,
        EventTime,
        EndTime,
        User,
        PositionStatus,
        ReasonForChange,
        Department,
        CostCenter,
        JobFamily,
        ROW_NUMBER() OVER (
            PARTITION BY PositionId, ActivityName, EventTime, COALESCE(SourceEventId, '')
            ORDER BY EndTime DESC NULLS LAST
        ) AS duplicate_rank
    FROM normalized_events
)
SELECT
    PositionId,
    ActivityName,
    EventTime,
    EndTime,
    User,
    PositionStatus,
    ReasonForChange,
    Department,
    CostCenter,
    JobFamily
FROM deduplicated_events
WHERE duplicate_rank = 1
  AND PositionId IS NOT NULL
  AND ActivityName IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY PositionId, EventTime, ActivityName;

Möchten Sie loslegen?

Mit diesem Daten-Template haben Sie alles, was Sie benötigen, um Ihr Positionsmanagement zu verbessern. Verwenden Sie Ihre Workday-HCM-Daten, um noch heute klarere Erkenntnisse zu gewinnen und die Effizienz zu steigern.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Optimieren Sie jetzt das Positionsmanagement in Workday HCM für Hire to Retire

Erkennen Sie Ineffizienzen und verkürzen Sie die Durchlaufzeit Ihres Positionsmanagements um 30 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Starten Sie Ihre kostenlose 14-tägige Testphase.

Ihr Daten-Template für Hire to Retire: Positionsmanagement

Ihr Daten-Template für Hire to Retire: Positionsmanagement

Attribute für Hire to Retire: Positionsmanagement

Aktivitäten für Hire to Retire: Positionsmanagement

Anleitungen zur Datenextraktion

Datenextraktion über Workday Custom Report as a Service (RaaS)

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit der Workday-Web-Services-API (WWS)

Schritte

Konfiguration

a Beispielabfrage python

Middleware- oder ETL-Plattform mit Workday-Konnektor

Schritte

Konfiguration

a Beispielabfrage sql

Möchten Sie loslegen?

Optimieren Sie jetzt das Positionsmanagement in Workday HCM für Hire to Retire

Ihr Daten-Template für Hire to Retire: Positionsmanagement

Ihr Daten-Template für Hire to Retire: Positionsmanagement

Attribute für Hire to Retire: Positionsmanagement

Aktivitäten für Hire to Retire: Positionsmanagement

Anleitungen zur Datenextraktion

Datenextraktion über Workday Custom Report as a Service (RaaS)

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit der Workday-Web-Services-API (WWS)

Schritte

Konfiguration

a Beispielabfrage python

Middleware- oder ETL-Plattform mit Workday-Konnektor

Schritte

Konfiguration

a Beispielabfrage sql

Möchten Sie loslegen?

Optimieren Sie jetzt das Positionsmanagement in Workday HCM für Hire to Retire

Der Schutz Ihrer Daten ist uns wichtig