Datenvorlage: Mitarbeiterlebenszyklus – vom Eintritt bis zum Austritt
Ihr Einstellung-bis-Austritt – Datentemplate für den Mitarbeiterlebenszyklus
- Empfohlene Attribute für eine gründliche Analyse
- Wichtige Aktivitäten, die im gesamten Mitarbeiter-Lebenszyklus verfolgt werden sollen
- Praktische Anleitung zur Datenextraktion aus Workday Onboarding
Vom Eintritt bis zum Austritt - Attribute des Mitarbeiter-Lebenszyklus
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivitätsname
ActivityName
|
Der Name des spezifischen Events oder der Task, das/die zu einem bestimmten Zeitpunkt im Mitarbeiterlebenszyklus aufgetreten ist. | ||
|
Beschreibung
Der Aktivitätsname beschreibt einen spezifischen Schritt im Hire-to-Retire-Prozess, wie zum Beispiel „Angebot angenommen‟, „Hintergrundprüfung abgeschlossen‟ oder „Beförderung genehmigt‟. Diese Aktivitäten bilden die Knotenpunkte der Process Map und zeigen die Abfolge der Events, die den Mitarbeiterweg ausmachen. Die Analyse dieser Aktivitäten hilft Unternehmen, den Process Flow zu verstehen, häufige und seltene Pfade zu identifizieren und die Phasen zu lokalisieren, in denen Verzögerungen oder Nacharbeiten auftreten. Eine konsistente und klare Benennung der Aktivitäten ist entscheidend für den Aufbau eines präzisen und verständlichen Process Models.
Warum es wichtig ist
Es definiert die Schritte in der Prozesslandkarte, welche die Grundlage jeder Process Mining Analyse und Visualisierung bildet.
Woher erhalten
Abgeleitet vom Business Process-Schritt oder Event Name innerhalb der Workday Transaktionsprotokolle.
Beispiele
Angebotsanschreiben erstelltOnboarding-Aufgaben abgeschlossenKündigung eingeleitet
|
|||
|
Ereignis-Timestamp
EventTimestamp
|
Das präzise Datum und die Uhrzeit, wann die Aktivität oder das Event aufgezeichnet wurde. | ||
|
Beschreibung
Dieses Attribut liefert den zeitlichen Kontext für jede Aktivität und hält fest, wann sie stattgefunden hat. Die Abfolge und der Zeitpunkt dieser Timestamps werden verwendet, um den Prozessfluss zu rekonstruieren und alle zeitbasierten Kennzahlen, wie Zykluszeiten und Dauern, zu berechnen. In der Analyse ist der Event Timestamp grundlegend für das Verständnis der Prozessperformance. Er ermöglicht die Berechnung der Zeit zwischen den Schritten, die Identifizierung von Verzögerungen und die Analyse des Prozessverhaltens über verschiedene Zeiträume hinweg, wie zum Beispiel den Vergleich der Einstellungsgeschwindigkeit von Quartal zu Quartal.
Warum es wichtig ist
Dieses Attribut ist entscheidend für die korrekte Reihenfolge der Events und die Berechnung aller Leistungsmetriken wie Cycle Time und Bottlenecks.
Woher erhalten
Dies ist ein Standardbestandteil jedes Geschäftsprozess-Transaktionsprotokolls in Workday, oft als „Gültigkeitsdatum“ oder „Abschlusszeitpunkt“ bezeichnet.
Beispiele
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2024-01-15T09:12:00Z
|
|||
|
Mitarbeiter-ID
EmployeeId
|
Die eindeutige Kennung für einen Mitarbeiter, die als primäre Case ID für dessen gesamten Lebenszyklus innerhalb der Organisation dient. | ||
|
Beschreibung
Die Employee ID ist der Eckpfeiler der Hire-to-Retire-Process Analysis. Sie verknüpft alle zugehörigen Events, von der ersten Bewerbung bis zur endgültigen Kündigung, zu einer einzigen, kohärenten Journey. Durch die Verfolgung dieser ID können Unternehmen eine vollständige Historie der Anstellungszeit eines Mitarbeiters erstellen, einschließlich Rollenwechseln, Leistungsbeurteilungen und Onboarding-Schritten. Im Process Mining ist jede Aktivität mit einer Employee ID verknüpft, was eine umfassende Ansicht individueller und aggregierter Mitarbeiterlebenszyklen ermöglicht. Dies erlaubt die Analyse von Process Durations, die Identifizierung gemeinsamer Pathways und die Entdeckung von Bottlenecks, die Mitarbeiter in verschiedenen Phasen ihrer Karriere betreffen.
Warum es wichtig ist
Dieses Attribut ist unerlässlich, um alle Lifecycle Events eines einzelnen Mitarbeiters zu einem vollständigen End-to-End-Prozessbild zusammenzufügen.
Woher erhalten
Dies ist ein Kernfeld in Workday HCM, typischerweise zu finden in Mitarbeiterprofilen und Geschäftsprozess-Transaktionen.
Beispiele
100234510087651011212
|
|||
|
Abteilung
Department
|
Die Organisationsabteilung, der der Mitarbeiter angehört. | ||
|
Beschreibung
Dieses Attribut repräsentiert die zugewiesene Abteilung eines Mitarbeiters, wie zum Beispiel „Vertrieb“, „Entwicklung“ oder „Personalwesen“. Es ist eine kritische Dimension, um die Prozessperformance über verschiedene Bereiche der Organisation hinweg zu segmentieren und zu vergleichen. In der Prozessanalyse ermöglicht das Filtern nach Abteilung die Beantwortung von Fragen wie: „Ist die Time-to-Hire für die Entwicklungsabteilung länger als für den Vertrieb?“ oder „Welche Abteilungen weisen die höchste Rate an Onboarding-Abweichungen auf?“. Dies hilft, lokalisierte Probleme zu identifizieren und Prozessverbesserungen maßzuschneidern.
Warum es wichtig ist
Es ermöglicht eine leistungsstarke vergleichende Analyse und hilft dabei festzustellen, ob Prozessineffizienzen in bestimmten Geschäftsbereichen konzentriert sind.
Woher erhalten
Dies ist Teil der zentralen Job- und Organisationsdaten eines Mitarbeiters in Workday HCM, die mit seiner Position verknüpft sind.
Beispiele
EngineeringVertrieb und MarketingFinanzen
|
|||
|
Endzeit des Events
EventEndTime
|
Der Timestamp, der den Abschluss einer Aktivität markiert, insbesondere für Aufgaben mit messbarer Dauer. | ||
|
Beschreibung
Während StartTime den Beginn einer Activity anzeigt, markiert Event End Time deren Abschluss. Die Differenz zwischen beiden stellt die Verarbeitungszeit (Processing Time) der Activity dar. Dies ist besonders nützlich für Aufgaben, die nicht sofort abgeschlossen sind, wie beispielsweise „Hintergrundüberprüfung“ oder „Leistungsbeurteilung“. In der Analyse ist dieses Attribut entscheidend für die Berechnung der ProcessingTime-Metrik. Es hilft, zwischen der Wartezeit zwischen Activities und der tatsächlich auf eine Activity verwendete Arbeitszeit zu unterscheiden, was zu einem präziseren Verständnis der Zeitaufwendungen im Prozess führt.
Warum es wichtig ist
Es ermöglicht die Berechnung der tatsächlichen Bearbeitungszeit einer Aktivität und hilft dabei, aktive Arbeitszeit von unproduktiven Wartezeiten zu unterscheiden.
Woher erhalten
Für einige Business Processes in Workday werden sowohl Initiierungs- als auch Completion Timestamps protokolliert. Dies kann das Verknüpfen von Events erfordern.
Beispiele
2023-10-26T18:30:00Z2023-11-05T11:00:15Z2024-01-15T17:20:00Z
|
|||
|
Event Performer
EventPerformer
|
Der Benutzer oder automatisierte Systemagent, der die Aktivität ausgeführt hat. | ||
|
Beschreibung
Dieses Attribut identifiziert die Person, Rolle oder das System, das für die Erledigung einer Aufgabe verantwortlich ist. Dies könnte ein Einstellungsmanager sein, der ein Angebot genehmigt, ein HR-Spezialist, der das Onboarding initiiert, oder ein Systemprozess, der eine Benachrichtigung generiert. Die Analyse des Event Performers ist entscheidend, um die Ressourcenallokation, die Arbeitslastverteilung und die Benutzerakzeptanz zu verstehen. Sie kann helfen, überlastete Teams zu identifizieren, Automatisierungsmöglichkeiten aufzuzeigen, wo manuelle Benutzer repetitive Aufgaben ausführen, und Leistungsunterschiede zwischen Einzelpersonen oder Abteilungen zu analysieren.
Warum es wichtig ist
Dieses Attribut hilft bei der Analyse der Arbeitslastverteilung, der Benutzerleistung und identifiziert, wer am Prozess beteiligt ist, was entscheidend für gezielte Verbesserungen ist.
Woher erhalten
Verfügbar in den Transaktionsprotokollen der Workday Geschäftsprozesse, oft dem Benutzer zugeordnet, der einen Schritt abgeschlossen hat.
Beispiele
jsmith@example.comr.davisSystemprozess
|
|||
|
Lebenszyklus-Ereignistyp
LifecycleEventType
|
Kategorisiert den Prozess in wichtige Lebenszyklustypen wie Onboarding, Beförderung oder Offboarding. | ||
|
Beschreibung
Dieses Attribut bietet eine übergeordnete Klassifizierung für verschiedene Verläufe innerhalb des gesamten Mitarbeiterlebenszyklus-Prozesses (vom Eintritt bis zum Austritt). Indem jeder Case als 'Onboarding', 'Interne Mobilität' oder 'Kündigung' markiert wird, wird es wesentlich einfacher, die Prozesslandkarte zu filtern und diese unterschiedlichen Teilprozesse isoliert zu analysieren. Um beispielsweise das Dashboard 'Interne Mobilität & Beförderungszeit' zu analysieren, würde man nach Cases filtern, bei denen der Lifecycle Event Type 'Interne Mobilität' oder 'Beförderung' ist. Diese Segmentierung ist entscheidend für die Erstellung gezielter Analysen und Dashboards, die spezifische Geschäftsfragen beantworten.
Warum es wichtig ist
Es ermöglicht die Segmentierung der gesamten Mitarbeiterreise in verschiedene Teilprozesse, was eine fokussierte Analyse von Onboarding, Offboarding oder Beförderungen ermöglicht.
Woher erhalten
Dies wird typischerweise abgeleitet, indem spezifische Workday Geschäftsprozessnamen (z.B. „Einstellung“ (Hire), „Stellenwechsel“ (Change Job), „Kündigung“ (Terminate)) während der Datentransformation diesen Kategorien zugeordnet werden.
Beispiele
OnboardingInterne MobilitätOffboardingPerformance Management
|
|||
|
Stellenanfrage-ID
JobRequisitionId
|
Die eindeutige Kennung für die Stellenanforderung, die den Einstellungsprozess initiiert hat. | ||
|
Beschreibung
Die Job Requisition ID verknüpft alle frühen Einstellungsaktivitäten, wie das Ausschreiben einer Stelle, die Kandidatenauswahl und die Angebotserstellung, mit einem spezifischen Geschäftsanliegen. Sie dient als sekundäre Case ID für die Rekrutierungsphase des Mitarbeiterlebenszyklus. Die Analyse mittels Job Requisition ID kann Insights in die Effizienz des Einstellungsprozesses für verschiedene Rollen oder Abteilungen liefern. Sie hilft, den gesamten Funnel von der Ausschreibungserstellung bis zur Angebotsannahme zu verfolgen und unterstützt KPIs wie die „Durchschnittliche Einstellungsdauer‟ (Average Time-to-Hire).
Warum es wichtig ist
Es gruppiert alle Pre-Hire-Aktivitäten unter einem einzigen Bezeichner und ermöglicht so eine detaillierte Analyse des Rekrutierungsteils des Prozesses.
Woher erhalten
Im Recruiting-Modul von Workday zu finden. Es ist mit der Bewerbung des Kandidaten und dem nachfolgenden Einstellungs-Event verbunden.
Beispiele
REQ-2023-05-101REQ-2024-01-230REQ-2023-11-087
|
|||
|
Bearbeitungszeit
ProcessingTime
|
Die Dauer der Zeit, die aktiv an einem Event gearbeitet wurde. | ||
|
Beschreibung
Diese Kennzahl berechnet die verstrichene Zeit zwischen dem Start und Ende einer Aktivität (EventEndTime - StartTime). Sie stellt die tatsächliche Arbeitsdauer dar, im Gegensatz zur Wartezeit zwischen Aktivitäten. Zum Beispiel könnte sie messen, wie lange eine Hintergrundüberprüfung aktiv bearbeitet wurde. Die Analyse der Bearbeitungszeit hilft zu identifizieren, welche spezifischen Aufgaben den größten Aufwand erfordern, anstatt nur zu zeigen, welche Prozessphasen die längsten Verzögerungen aufweisen. Dies ermöglicht gezieltere Verbesserungen, die darauf abzielen, die Arbeit effizienter zu gestalten.
Warum es wichtig ist
Es isoliert die für wertschöpfende Arbeit aufgewendete Zeit von Leerlaufzeiten und bietet ein klares Ziel für Effizienzverbesserungen auf Aufgabenebene.
Woher erhalten
Berechnetes Feld: EventEndTime minus EventTimestamp.
Beispiele
2 Stunden5 Tage30 Minuten
|
|||
|
Beschäftigungsart
EmploymentType
|
Zeigt an, ob der Mitarbeiter Vollzeit, Teilzeit, ein externer Mitarbeiter oder ein Praktikant ist. | ||
|
Beschreibung
Dieses Attribut klassifiziert die Art des Arbeitsverhältnisses. Unterschiedliche Beschäftigungsarten folgen oft verschiedenen Prozessvarianten für Onboarding, Gehaltsabrechnung und Einrichtung von Leistungen. Durch die Verwendung dieses Attributs als Filter können Organisationen die Lifecycle-Prozesse für verschiedene Mitarbeiterkategorien vergleichen. Dies kann aufzeigen, ob beispielsweise der Onboarding-Prozess für Auftragnehmer deutlich schneller oder weniger compliant ist als der für Vollzeitmitarbeiter, was gezielte Prozessanpassungen ermöglicht.
Warum es wichtig ist
Ermöglicht den Vergleich von Prozessvarianten zwischen verschiedenen Mitarbeiterkategorien, wie z.B. Vollzeitangestellten und externen Mitarbeitern, die unterschiedlichen Abläufen folgen können.
Woher erhalten
Ein Standardfeld in den Jobdetails des Mitarbeiters in Workday HCM.
Beispiele
VollzeitTeilzeitAuftragnehmerPraktikant
|
|||
|
Beschäftigungsstatus
EmploymentStatus
|
Der aktuelle Beschäftigungsstatus des Mitarbeiters, wie zum Beispiel aktiv, gekündigt oder beurlaubt. | ||
|
Beschreibung
Dieses Attribut gibt den aktuellen Status des Mitarbeiters innerhalb der Organisation an. Es ist ein dynamisches Feld, das sich ändert, während der Mitarbeiter seinen Lebenszyklus durchläuft. Zum Beispiel beginnt ein neuer Mitarbeiter als 'Pre-Hire' oder 'Onboarding' und wird nach Abschluss 'Aktiv'. Im Process Mining liefert dieses Attribut wertvolle Statusinformationen. Es kann verwendet werden, um die Process Compliance zu überprüfen, z.B. um sicherzustellen, dass die Gehaltsabrechnung nur für 'Aktive' Mitarbeiter eingerichtet wird. Es hilft auch beim Filtern nach spezifischen Populationen, wie der Analyse des Offboarding-Prozesses für alle 'Ausgeschiedenen' Mitarbeiter.
Warum es wichtig ist
Bietet einen Snapshot des aktuellen Mitarbeiterstatus, was nützlich ist für die Validierung der Prozesslogik und das Filtern von Analysen nach spezifischen Mitarbeiterpopulationen.
Woher erhalten
Ein Kernfeld im Profil des Mitarbeiters in Workday HCM.
Beispiele
AktivBeendetBeurlaubtPre-Hire
|
|||
|
Ist Compliance-Aktivität
IsComplianceActivity
|
Ein boolesches Flag, das anzeigt, ob es sich bei einer Aktivität um einen erforderlichen Compliance- oder Regulierungsschritt handelt. | ||
|
Beschreibung
Dieses Flag kennzeichnet Aktivitäten, die für die Einhaltung von Gesetzen, Vorschriften oder Richtlinien entscheidend sind, wie das Unterzeichnen einer Richtlinienbestätigung oder das Absolvieren einer Pflichtschulung. Es hilft, diese kritischen Aufgaben von regulären administrativen zu trennen. In der Analyse ermöglicht dieses Attribut die Erstellung von Dashboards und KPIs, die sich speziell auf Compliance konzentrieren, wie die „Rate kritischer Compliance-Aktivitäten“. Es hilft Organisationen dabei, zu überwachen und sicherzustellen, dass die wichtigsten regulatorischen Schritte für alle Mitarbeiter pünktlich abgeschlossen werden, wodurch das Organisationsrisiko reduziert wird.
Warum es wichtig ist
Ermöglicht eine fokussierte Überwachung kritischer Compliance-Schritte, um die Einhaltung gesetzlicher Vorschriften sicherzustellen und Risiken zu mindern.
Woher erhalten
Dies ist ein abgeleitetes Attribut, typischerweise erstellt während der Datentransformation, indem eine Liste bekannter Compliance-bezogener Aktivitätsnamen auf ein Wahr/Falsch-Flag abgebildet wird.
Beispiele
truefalsch
|
|||
|
Ist Nacharbeit
IsRework
|
Ein boolesches Flag, das anzeigt, ob es sich bei einer Aktivität um die Wiederholung eines vorherigen Schritts im selben Case handelt. | ||
|
Beschreibung
Dieses Attribut identifiziert Fälle von Nacharbeit, bei denen eine Aufgabe für denselben Mitarbeiter mehr als einmal ausgeführt werden muss. Beispiele hierfür sind die erneute Einreichung fehlerhafter Unterlagen oder die wiederholte Durchführung einer fehlgeschlagenen Hintergrundprüfung. Sie wird typischerweise durch das mehrmalige Erscheinen desselben Aktivitätsnamens innerhalb des Event Logs eines Cases identifiziert. Die Analyse von Nacharbeit ist entscheidend für die Verbesserung der Prozesseffizienz und -qualität. Das 'IsRework'-Flag erleichtert die Quantifizierung der Nacharbeitsmenge, die Identifizierung ihrer Grundursachen und die Messung der Auswirkungen von Verbesserungen, die darauf abzielen, Fehler von vornherein zu vermeiden. Es unterstützt direkt das Dashboard für die 'Analyse von Nacharbeit und Wiederholungen'.
Warum es wichtig ist
Es hilft, Prozessineffizienz und Verschwendung zu quantifizieren, indem wiederholte Aktivitäten hervorgehoben werden, die auf Qualitäts- oder Kommunikationsprobleme hindeuten.
Woher erhalten
Dies ist ein berechnetes Flag. Die Logik wird während der Process-Mining-Analyse angewendet, indem wiederholte Aktivitäten innerhalb desselben Case erkannt werden.
Beispiele
truefalsch
|
|||
|
Kündigungsgrund
TerminationReason
|
Der angegebene Grund für den Austritt eines Mitarbeiters aus dem Unternehmen. | ||
|
Beschreibung
Dieses Attribut erfasst, warum die Anstellung eines Mitarbeiters beendet wurde, z.B. 'Freiwillige Kündigung', 'Unfreiwillig - Leistung' oder 'Rente'. Diese Information ist entscheidend für die Analyse von Personalfluktuation und des Offboarding-Prozesses. Im Process Mining liefert der Kündigungsgrund (Termination Reason) Kontext für den Offboarding-Verlauf. Er kann verwendet werden, um zu analysieren, ob unterschiedliche Kündigungsarten verschiedenen Offboarding-Verfahren folgen oder unterschiedlich viel Zeit in Anspruch nehmen. Dies hilft, die Mitarbeiterfluktuation zu verstehen und sicherzustellen, dass der Offboarding-Prozess für jede Situation angemessen gehandhabt wird.
Warum es wichtig ist
Bietet entscheidenden Kontext für die Analyse des Offboarding-Prozesses und hilft, Prozessprobleme mit Gründen für die Fluktuation zu korrelieren.
Woher erhalten
Erfasst während des Geschäftsprozesses 'Mitarbeiter entlassen' in Workday.
Beispiele
Kündigung, FreiwilligKündigung, unfreiwilligRentenantritt
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, der den Zeitpunkt der letzten Aktualisierung der Daten dieses Events aus dem Quellsystem angibt. | ||
|
Beschreibung
Dieses Attribut markiert den Zeitpunkt der letzten Aktualisierung des Datensatzes. Es schafft Transparenz über die Aktualität der analysierten Daten, was entscheidend für zeitnahe und relevante Geschäftsentscheidungen auf Basis der Process Mining Erkenntnisse ist. Für Dashboards und die fortlaufende Überwachung hilft dieser Timestamp den Benutzern zu verstehen, ob sie die aktuellsten verfügbaren Daten betrachten. Es ist ein zentrales Metadatum zur Aufrechterhaltung der Datenintegrität und des Benutzervertrauens in die Analyse.
Warum es wichtig ist
Stellt sicher, dass Nutzende über die Aktualität der Daten informiert sind, was entscheidend für die Relevanz und Genauigkeit der Prozessanalyse ist.
Woher erhalten
Dies ist ein Metadatenfeld, das während des Datenimports oder des ETL (Extract, Transform, Load)-Prozesses generiert und dem Datensatz hinzugefügt wird.
Beispiele
2024-03-15T02:00:00Z2024-03-16T02:00:00Z
|
|||
|
Name des Onboarding-Plans
OnboardingPlanName
|
Der Name des spezifischen Onboarding Templates oder Plans, der dem neuen Mitarbeiter zugewiesen wurde. | ||
|
Beschreibung
Workday ermöglicht die Erstellung verschiedener Onboarding-Pläne, die auf unterschiedliche Rollen, Standorte oder Hierarchieebenen zugeschnitten sind. Dieses Attribut identifiziert, welcher spezifische Plan für einen neuen Mitarbeiter verwendet wurde. Eine Analyse nach Onboarding-Plan-Name hilft, die Effektivität und Effizienz verschiedener Onboarding-Strategien zu bewerten. Sie ermöglicht einen direkten Vergleich, beispielsweise zwischen einem „Executive Onboarding Plan“ und einem „Standard Employee Onboarding Plan“, um festzustellen, welcher bessere Aufgabenabschlussraten oder schnellere cycle times aufweist.
Warum es wichtig ist
Dies hilft, die Performance verschiedener Onboarding-Programme zu bewerten, um Best Practices und Verbesserungspotenziale zu identifizieren.
Woher erhalten
Diese Information ist wahrscheinlich im Onboarding-Modul von Workday verfügbar und mit dem Geschäftsprozess „Einstellung“ (Hire) verknüpft.
Beispiele
Standardisiertes Unternehmens-OnboardingOnboarding des VertriebsteamsOnboarding-Plan für Führungskräfte
|
|||
|
Ort
Location
|
Der geografische Standort oder das Büro, das der Position des Mitarbeiters zugeordnet ist. | ||
|
Beschreibung
Das Location-Attribut spezifiziert das Land, den Bundesstaat oder die Stadt, in der der Mitarbeiter ansässig ist. Diese geografische Dimension ist essenziell für den Vergleich der Process Performance und Compliance über verschiedene Regionen hinweg. Die Analyse mittels Location kann regionale Unterschiede bei Einstellungszeiten, Onboarding-Effizienz oder Kündigungsverfahren aufdecken. Sie hilft bei der Beantwortung von Fragen wie: „Dauern Hintergrundprüfungen in Deutschland länger als in den Vereinigten Staaten?‟ und unterstützt das Compliance Monitoring für regionalspezifische Vorschriften.
Warum es wichtig ist
Ermöglicht geografische Analysen, um regionale Prozessabweichungen zu identifizieren, die durch lokales Management, Vorschriften oder Kultur beeinflusst werden können.
Woher erhalten
Teil der Positions- und Organisationszuordnungsdaten des Mitarbeiters innerhalb von Workday HCM.
Beispiele
USA - New YorkDeutschland - BerlinIndia - Bangalore
|
|||
|
Positions-ID
PositionId
|
Die eindeutige Kennung für die spezifische Position oder Rolle, die der Mitarbeiter innehat. | ||
|
Beschreibung
Die Position ID identifiziert die spezifische Rolle, die ein Mitarbeiter innerhalb der Organisationsstruktur einnimmt. Jede Position hat definierte Attribute, wie Stellenprofil, Location und Berichtslinie. Sie ist spezifischer als eine Stellenbezeichnung, da mehrere Positions denselben Titel teilen können. Die Analyse mittels Position ID hilft, Prozesse zu verstehen, die mit spezifischen Rollen verbunden sind. Man könnte zum Beispiel die Onboarding Journey für alle Senior Software Engineer-Positionen analysieren, um zu sehen, ob es gemeinsame Muster oder Verzögerungen gibt, die für diese Rolle einzigartig sind.
Warum es wichtig ist
Ermöglicht eine granulare Analyse basierend auf spezifischen Rollen, um zu verstehen, wie sich Prozesse für verschiedene Positionen innerhalb des Unternehmens unterscheiden.
Woher erhalten
Ein Standardfeld, das der Jobzuweisung des Mitarbeiters in Workday HCM zugeordnet ist.
Beispiele
POS-1001POS-2345POS-8762
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem die Event Data extrahiert wurde, in diesem Fall Workday Onboarding. | ||
|
Beschreibung
Dieses Attribut identifiziert den Ursprung der Daten. Während wir uns in dieser Ansicht auf das Workday Onboarding konzentrieren, kann ein vollständiger Mitarbeiterlebenszyklus-Prozess (vom Eintritt bis zum Austritt) Daten aus anderen Systemen wie einem Applicant Tracking System (ATS) oder einem separaten Lohn- und Gehaltsabrechnungsanbieter (Payroll Provider) umfassen. Die Angabe des Quellsystems ist entscheidend für die Data Governance und das Verständnis des Event-Kontexts. Bei einer Multi-System-Analyse ermöglicht dieses Feld das Filtern der Prozessansicht nach Events aus einem spezifischen System oder die Analyse der Übergaben zwischen verschiedenen Systemen.
Warum es wichtig ist
Es liefert entscheidenden Kontext zum Datenursprung, was für die Datenvalidierung und für Analysen, die Daten aus mehreren Systemen kombinieren, unerlässlich ist.
Woher erhalten
Dies ist typischerweise ein statischer Wert („Workday Onboarding“), der während des Datenextraktions- und Transformationsprozesses hinzugefügt wird.
Beispiele
Workday OnboardingWorkday HCM
|
|||
|
SLA verletzt?
IsSlaViolated
|
Ein boolesches Flag, das angibt, ob eine Aktivität nach dem festgelegten SLA-Zieldatum abgeschlossen wurde. | ||
|
Beschreibung
Dieses berechnete Attribut liefert einen einfachen Wahr/Falsch-Indikator dafür, ob ein Prozessschritt sein Service Level Agreement (SLA) erfüllt hat. Es wird abgeleitet durch den Vergleich des Abschluss-Timestamps der Aktivität (EventTimestamp) mit ihrer Frist (SlaTargetDate). Dieses Flag ist äußerst nützlich für Dashboards und das Reporting, da es das einfache Zählen und Visualisieren von SLA-Verstößen ermöglicht. Es ist die Grundlage für KPIs wie „Pünktlichkeit von Leistungsbeurteilungen“ und vereinfacht die Erstellung von Warnungen oder Berichten über überfällige Aufgaben, wodurch Teams sich auf die kritischsten Verzögerungen konzentrieren können.
Warum es wichtig ist
Vereinfacht das Performance Monitoring, indem alle Fälle, in denen vereinbarte Fristen nicht eingehalten wurden, klar gekennzeichnet werden.
Woher erhalten
Berechnetes Feld: true, wenn EventTimestamp > SlaTargetDate, andernfalls false.
Beispiele
truefalsch
|
|||
|
SLA-Zieldatum
SlaTargetDate
|
Das Zieldatum, bis zu dem eine bestimmte Aktivität, wie eine Leistungsbeurteilung, abgeschlossen sein sollte. | ||
|
Beschreibung
Dieses Attribut definiert die SLA-Frist (Service Level Agreement) für eine bestimmte Aufgabe. Es legt die Erwartung fest, wie lange bestimmte Prozesse dauern sollten, und dient als Referenzwert für die Leistungsmessung. Dies ist unerlässlich für KPIs wie die 'Pünktlichkeit der Leistungsbeurteilung' und Dashboards, die sich auf die SLA-Einhaltung konzentrieren. Durch den Vergleich des tatsächlichen Abschlussdatums (EventTimestamp) mit dem SlaTargetDate können Verstöße automatisch identifiziert, die Pünktlichkeit gemessen und Verzögerungen proaktiv gemanagt werden.
Warum es wichtig ist
Bietet einen klaren Benchmark zur Messung der Pünktlichkeit und ist unerlässlich für die Berechnung von KPIs zur SLA-Einhaltung.
Woher erhalten
Für Prozesse wie Performance Reviews in Workday wird oft ein Fälligkeitsdatum konfiguriert. Diese Daten müssten zusammen mit den Process Events extrahiert werden.
Beispiele
2023-12-31T23:59:59Z2024-06-30T23:59:59Z
|
|||
|
Time to Hire
TimeToHire
|
Die Gesamtzeit von der Erstellung einer Stellenanforderung bis zur Annahme des Angebots durch den Kandidaten. | ||
|
Beschreibung
Time to Hire ist ein kritischer Rekrutierungs-KPI, der die Effizienz des gesamten Einstellungs-Funnel misst. Er wird als Dauer zwischen dem Event „Stellenanforderung erstellt“ und dem Event „Angebot angenommen“ für denselben Mitarbeiter oder dieselbe Stellenanforderung berechnet. Dieses berechnete Attribut ist die Grundlage für den KPI „Durchschnittliche Time-to-Hire“ und zugehörige Dashboards. Die Verfolgung über die Zeit ermöglicht es Personalabteilungen, die Auswirkungen von Prozessverbesserungen zu messen, Engpässe im Sourcing oder bei Interviews zu identifizieren und realistische Einstellungsfristen für Manager festzulegen.
Warum es wichtig ist
Misst direkt die Effizienz des Einstellungsprozesses, ein wichtiger Leistungsindikator für jede HR-Organisation.
Woher erhalten
Berechnet auf der Case-Ebene durch Ermittlung der Dauer zwischen dem Timestamp der Aktivität 'Stellenanforderung erstellt' und der Aktivität 'Angebot angenommen'.
Beispiele
35 Tage62 Tage28 Tage
|
|||
Vom Eintritt bis zum Austritt - Aktivitäten im Mitarbeiter-Lebenszyklus
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Angebot angenommen
|
Diese Aktivität tritt ein, wenn ein Kandidat das Stellenangebot formell annimmt, oft durch elektronische Unterzeichnung des Angebotsbriefes innerhalb von Workday. Dies ist ein kritischer Meilenstein, der erfasst wird, sobald der Kandidat den Schritt 'Prüfen und Unterzeichnen' im Angebotsprozess abgeschlossen hat. | ||
|
Warum es wichtig ist
Dieser Meilenstein schließt die Kernphase der Rekrutierung ab und löst Pre-Hire- und Onboarding-Aktivitäten aus. Er ist eine Schlüsselkomponente zur Messung des Time-to-Hire-KPI.
Woher erhalten
Dies ist ein explizites Event, das protokolliert wird, wenn der Kandidat den Annahmeschritt des Stellenangebots innerhalb des Geschäftsprozesses „Stellenbewerbung“ abschließt.
Erfassen
Die Aktion des Kandidaten, das Angebot anzunehmen, wird als abgeschlossener Schritt im Geschäftsprozess Bewerbung (Job Application BP) protokolliert.
Ereignistyp
explicit
|
|||
|
Einstellungsprozess abgeschlossen
|
Dies ist eine zentrale Aktivität, bei der ein Kandidatendatensatz offiziell in einen Mitarbeiterdatensatz in Workday HCM umgewandelt wird. Dieses Event wird explizit bei erfolgreichem Abschluss des Geschäftsprozesses „Einstellung“ (Hire) erfasst. | ||
|
Warum es wichtig ist
Dieses Event markiert formell den Übergang vom Kandidaten zum Mitarbeiter und ist ein kritischer Meilenstein zur Verfolgung der Onboarding-Zykluszeit. Es zeigt an, dass der Mitarbeiter offiziell im HCM-System erfasst ist.
Woher erhalten
Explizit als Completion Event für den 'Hire' Business Process für den Mitarbeitenden protokolliert. Das Business Process Log enthält den genauen Timestamp.
Erfassen
Event protokolliert bei erfolgreichem Abschluss des 'Hire' Business Process.
Ereignistyp
explicit
|
|||
|
Kündigung eingeleitet
|
Diese Aktivität markiert den Beginn des Offboarding-Prozesses für einen ausscheidenden Mitarbeiter. Sie wird explizit erfasst, wenn ein Vorgesetzter oder ein HR-Benutzer den Geschäftsprozess 'Mitarbeiter kündigen' in Workday initiiert. | ||
|
Warum es wichtig ist
Dies ist das primäre Start-Event für den gesamten Offboarding Lifecycle. Es ist der Ausgangspunkt für die Messung des KPI für die durchschnittliche Offboarding-Zykluszeit.
Woher erhalten
Dies ist ein explizites Event, das bei der Initiierung des Geschäftsprozesses „Mitarbeiter kündigen“ (Terminate Employee) in Workday HCM protokolliert wird.
Erfassen
Event protokolliert, wenn der 'Terminate Employee' Business Process initiiert wird.
Ereignistyp
explicit
|
|||
|
Mitarbeiter gekündigt
|
Dies ist die finale Aktivität im Mitarbeiter-Lebenszyklus, die das offizielle Ende der Beschäftigung im System markiert. Dieses Event wird erfasst, wenn der Geschäftsprozess „Mitarbeiter kündigen“ (Terminate Employee) erfolgreich abgeschlossen wird. | ||
|
Warum es wichtig ist
Dies ist das definitive End-Event für den Hire-to-Retire-Prozess. Es ist der Endpunkt zur Messung der Offboarding-Zykluszeit und bestätigt, dass der Prozess abgeschlossen ist.
Woher erhalten
Explizit als Completion Event für den 'Terminate Employee' Business Process protokolliert. Der Datensatz des Mitarbeitenden wird danach inaktiv.
Erfassen
Event protokolliert bei erfolgreichem Abschluss des 'Terminate Employee' Business Process.
Ereignistyp
explicit
|
|||
|
Onboarding initiiert
|
Markiert den Beginn der Onboarding-Reise des neuen Mitarbeiters innerhalb des Workday Onboarding-Moduls. Dies wird erfasst, wenn die zugewiesenen Onboarding-Aufgaben und Workflows dem neuen Mitarbeiter zugewiesen werden, typischerweise ausgelöst durch den Abschluss des Einstellungsprozesses. | ||
|
Warum es wichtig ist
Dies ist der Startpunkt für die Analyse der Effizienz des Onboarding-Prozesses. Es hilft, die Abschlussquoten von Onboarding-Aufgaben zu messen und Prozessabweichungen zu identifizieren.
Woher erhalten
Als Initiierungsereignis protokolliert, wenn der 'Onboarding'-Geschäftsprozess oder ein ähnlicher Workflow für den neuen Mitarbeiter ausgelöst wird.
Erfassen
Event protokolliert, wenn der Onboarding Business Process für die neue Einstellung ausgelöst wird.
Ereignistyp
explicit
|
|||
|
Onboarding-Aufgaben abgeschlossen
|
Stellt den Abschluss aller zugewiesenen Onboarding-Aufgaben für einen neuen Mitarbeiter dar. Dieses Event wird typischerweise abgeleitet, wenn der Gesamtstatus des Onboarding Business Process für den Mitarbeiter auf 'Successfully Completed' wechselt. | ||
|
Warum es wichtig ist
Dies ist ein wichtiger Meilenstein, der anzeigt, dass ein neuer Mitarbeiter vollständig eingegliedert wurde. Er dient als Endpunkt zur Messung des KPI für die Onboarding-Zykluszeit und zur Analyse der Einhaltung des Onboarding-Prozesses.
Woher erhalten
Abgeleitet vom Timestamp des Abschlusses des übergeordneten 'Onboarding'-Geschäftsprozesses, der nach Abschluss aller erforderlichen Schritte und Aufgaben erfolgt.
Erfassen
Abgeleitet vom Timestamp des Abschlusses des gesamten Onboarding-Geschäftsprozesses für den Mitarbeiter.
Ereignistyp
inferred
|
|||
|
Stellenanfrage erstellt
|
Diese Aktivität markiert den offiziellen Start des Rekrutierungsprozesses, wenn eine neue Stellenanforderung in Workday erstellt und genehmigt wird. Dieses Event wird explizit erfasst, sobald der Geschäftsprozess 'Stellenanforderung erstellen' erfolgreich abgeschlossen ist. | ||
|
Warum es wichtig ist
Dies ist das primäre Start-Event für den gesamten Hiring Lifecycle. Die Analyse der Zeit von dieser Aktivität bis „Angebot angenommen“ ist entscheidend für die Messung des Time-to-Hire-KPI.
Woher erhalten
Dieses Event wird bei erfolgreichem Abschluss des Geschäftsprozesses „Stellenanforderung erstellen“ in Workday Recruiting protokolliert. Der Event Log für diesen Geschäftsprozess liefert den Timestamp.
Erfassen
Event protokolliert bei Abschluss des 'Create Job Requisition' Business Process.
Ereignistyp
explicit
|
|||
|
Angebotsanschreiben erstellt
|
Stellt den Zeitpunkt dar, zu dem ein formelles Stellenangebot für einen Kandidaten generiert wird. Dies ist typischerweise ein expliziter Schritt innerhalb des Job Application Business Process in Workday. | ||
|
Warum es wichtig ist
Diese Nachverfolgung hilft zu verstehen, wie lange es dauert, ein Angebot zu formalisieren, nachdem die Interviews abgeschlossen sind. Verzögerungen an dieser Stelle können dazu führen, dass Kandidaten abspringen.
Woher erhalten
Erfasst aus dem Event Log für den Geschäftsprozess 'Bewerbung', speziell dem Abschluss des Schrittes 'Dokument generieren' oder eines ähnlichen Angebotsschrittes.
Erfassen
Event protokolliert bei Abschluss des 'Generate Offer' Schritts im Job Application BP.
Ereignistyp
explicit
|
|||
|
Beförderung genehmigt
|
Markiert die endgültige Genehmigung einer Beförderung eines Mitarbeiters. Diese Aktivität wird erfasst, wenn der 'Change Job'- oder ein verwandter Vergütungs-Geschäftsprozess vollständig genehmigt und abgeschlossen ist. | ||
|
Warum es wichtig ist
Dies ist der Endpunkt zur Messung des KPI für die Genehmigungszeit interner Mobilität. Es bestätigt den erfolgreichen Abschluss eines wichtigen Karrieremeilensteins.
Woher erhalten
Als erfolgreicher Abschluss des 'Change Job'-Geschäftsprozesses protokolliert, wobei der Grund für die Änderung eine Beförderung ist.
Erfassen
Event protokolliert bei Abschluss des 'Change Job' Business Process mit dem Grund 'Beförderung'.
Ereignistyp
explicit
|
|||
|
Einrichtung der Gehaltsabrechnung abgeschlossen
|
Diese Aktivität signalisiert, dass alle notwendigen Informationen für die Gehaltsabrechnung des neuen Mitarbeiters eingegeben und verifiziert wurden. Dies kann als Abschluss eines spezifischen Schrittes innerhalb des Onboarding- oder Einstellungsprozesses erfasst werden. | ||
|
Warum es wichtig ist
Stellt sicher, dass Mitarbeitende ab dem ersten Gehaltsscheck korrekt und pünktlich bezahlt werden. Diese Activity ist der Endpunkt für den Payroll Setup Time KPI und hebt Verzögerungen bei der Vergütungsaktivierung hervor.
Woher erhalten
Erfasst als abgeschlossener Checklistenpunkt oder als spezifischer Schritt, z.B. 'Zahlungsoptionen eingeben', innerhalb des Onboarding-Geschäftsprozesses.
Erfassen
Abschluss einer spezifischen gehaltsbezogenen Aufgabe oder eines Schrittes innerhalb eines Geschäftsprozesses.
Ereignistyp
explicit
|
|||
|
Hintergrundprüfung abgeschlossen
|
Stellt den Abschluss des Pre-Employment Screening-Prozesses dar. Dies wird erfasst, wenn der Background Check-Status auf 'Complete' aktualisiert wird, entweder manuell oder über eine Integration. | ||
|
Warum es wichtig ist
Diese Aktivität bildet den Endpunkt zur Messung des KPIs für die Dauer der Hintergrundprüfung. Verzögerungen bei dieser Aktivität wirken sich direkt auf das Startdatum des neuen Mitarbeiters aus.
Woher erhalten
Erfasst aus einer Statusänderung im Geschäftsprozess 'Hintergrundprüfung' oder einem zugehörigen Objekt, die einen Endstatus wie 'Abgeschlossen' oder 'Bestanden' anzeigt.
Erfassen
Abgeleitet vom Timestamp, zu dem sich das Statusfeld der Hintergrundüberprüfung in einen finalen Zustand ändert.
Ereignistyp
inferred
|
|||
|
Hintergrundprüfung initiiert
|
Dies markiert den Beginn des Vorab-Screening-Prozesses (Einstellungsüberprüfung) für einen Kandidaten, der ein Angebot angenommen hat. Das Event wird erfasst, wenn der Schritt der Hintergrundüberprüfung initiiert wird, was oft eine Integration mit einem Drittanbieter auslöst. | ||
|
Warum es wichtig ist
Die Dauer von Hintergrundprüfungen stellt oft einen Bottleneck im Einstellungsprozess dar. Diese Aktivität ist der Ausgangspunkt für die Messung des KPI „Dauer der Hintergrundprüfung‟.
Woher erhalten
Als Schritt innerhalb eines Geschäftsprozesses protokolliert, wie z.B. die 'Hintergrundüberprüfung', die oft Teil des gesamten Einstellungsworkflows ist. Der Timestamp der Initiierung wird erfasst.
Erfassen
Event protokolliert bei Initiierung des 'Background Check' Business Process oder eines verwandten Schritts.
Ereignistyp
explicit
|
|||
|
Leistungsbeurteilung abgeschlossen
|
Diese Aktivität markiert den Abschluss eines formellen Leistungsbeurteilungszyklus für einen Mitarbeiter. Sie wird erfasst, wenn der Geschäftsprozess 'Leistungsbeurteilung' seinen endgültigen, genehmigten Zustand erreicht. | ||
|
Warum es wichtig ist
Die Nachverfolgung dieser Events ist unerlässlich, um die Aktualität und Häufigkeit des Performance Managements zu analysieren. Sie unterstützt direkt den Performance Review Timeliness KPI.
Woher erhalten
Als erfolgreicher Abschluss des 'Start Performance Review'-Geschäftsprozesses für den Mitarbeiter protokolliert.
Erfassen
Event protokolliert bei erfolgreichem Abschluss des 'Performance Review' Business Process.
Ereignistyp
explicit
|
|||
|
Offboarding-Aufgaben abgeschlossen
|
Stellt den Abschluss aller erforderlichen Offboarding-Aufgaben dar, wie z.B. Asset Return und Knowledge Transfer. Dieses Event wird abgeleitet, wenn die Offboarding-Checkliste oder der Business Process in einen abgeschlossenen Status übergeht. | ||
|
Warum es wichtig ist
Die Nachverfolgung des Abschlusses dieser Aufgaben ist entscheidend, um ein sicheres und compliance-konformes Offboarding zu gewährleisten. Verzögerungen können Sicherheitsrisiken mit sich bringen und zu einer schlechten Erfahrung führen.
Woher erhalten
Abgeleitet vom Timestamp des Abschlusses des 'Offboarding'-Geschäftsprozesses oder wenn alle zugewiesenen Offboarding-Aufgaben für den Mitarbeiter als abgeschlossen markiert sind.
Erfassen
Abgeleitet vom Abschluss einer Offboarding-Checkliste oder einem verwandten Geschäftsprozess.
Ereignistyp
inferred
|
|||
|
Rollenwechsel initiiert
|
Stellt den Beginn eines internen Mobilitätsereignisses dar, wie z.B. eine Versetzung oder Beförderung. Dies wird erfasst, wenn ein Manager oder HR Partner den Change Job Business Process für einen Mitarbeiter initiiert. | ||
|
Warum es wichtig ist
Diese Aktivität ist der Startpunkt zur Messung der Effizienz interner Mobilität und der Genehmigungszeiten. Sie hilft, Bottlenecks in der Karriereentwicklung von Mitarbeitern zu identifizieren.
Woher erhalten
Dies ist ein explizites Event, das bei der Initiierung des Geschäftsprozesses „Stellenwechsel“ (Change Job) in Workday HCM protokolliert wird.
Erfassen
Event protokolliert, wenn der 'Change Job' Business Process für einen Mitarbeitenden initiiert wird.
Ereignistyp
explicit
|
|||