DSAG-Personaltage 2026 in Heidelberg – besuchen Sie uns an unserem Stand
(Level 1, Saal 2, Stand 27)

Am 17. und 18. Juni 2026 trifft sich die HR- und SAP-Community erneut zu einem der wichtigsten Branchenevents: den DSAG-Personaltagen in Heidelberg, veranstaltet von der Deutschsprachige SAP-Anwendergruppe.

Auch wir sind in diesem Jahr wieder mit dabei und freuen uns auf den persönlichen Austausch, neue Impulse und spannende Gespräche.

ㅤㅤㅤ

Das Dino-Dilemma: Survival of the Skilled

Unter dem Leitthema „Das Dino-Dilemma: Survival of the Skilled“ stehen zentrale Zukunftsfragen im Fokus:
Wie können Unternehmen ihre HR- und IT-Strategien so aufstellen, dass sie auch in einem dynamischen, technologiegetriebenen Umfeld bestehen?

Die Veranstaltung bietet praxisnahe Einblicke in:

• Cloud-Transformation im HR-Umfeld
• KI-gestützte Anwendungen und Automatisierung
• moderne Szenarien rund um SAP SuccessFactors
• Best Practices für nachhaltige HR- und IT-Transformationen

ㅤㅤㅤ

Unsere Perspektive: HR-Transformation ganzheitlich denken

Als spezialisierter SAP-Beratungspartner begleiten wir Unternehmen täglich genau bei diesen Fragestellungen.

LM Consulting steht für fundierte Expertise in:

• SAP SuccessFactors
• SAP HCM im Kontext von SAP S/4HANA 
• Umsetzung der EU DSGVO in SuccsessFactors und SAP HCM
• ganzheitlicher digitaler HR-Transformation

Mit tiefem Prozess- und Systemverständnis unterstützen wir unsere Kunden entlang der gesamten Wertschöpfungskette, von der strategischen Konzeption über die Implementierung bis hin zum laufenden Betrieb.

Unser Anspruch dabei: Lösungen zu schaffen, die nicht nur technisch funktionieren, sondern auch im Alltag der Organisation echten Mehrwert liefern.

ㅤㅤㅤㅤ

Treffen Sie uns vor Ort

Sie sind ebenfalls auf den DSAG-Personaltagen unterwegs?
Dann kommen Sie gerne vorbei:

Level 1, Stand 27 – Heidelberg

Nutzen Sie die Gelegenheit für den direkten Austausch mit unserem Team – sei es zu konkreten Projekten, aktuellen Herausforderungen oder einfach für einen offenen Dialog rund um HR und SAP.

Wir freuen uns darauf, bekannte und neue Gesichter zu treffen, Erfahrungen zu teilen und gemeinsam neue Perspektiven zu entwickeln.

Haben Sie Fragen oder möchten Sie mit uns ins Gespräch kommen? Nutzen Sie gerne das Kontaktformular.
Wir freuen uns auf Ihre Nachricht.

SAP SuccessFactors als führendes HR-System – Vergleich mit SAP HCM

Aufgrund der digitalen Transformation hat sich das Personalwesen grundlegend verändert.

Dadurch stehen Unternehmen heute vor der großen Herausforderung ihre HR-Prozesse effizient, flexibel und zukunftssicher zu gestalten.

Um dies gewährleisten zu können stehen im SAP-Umfeld zwei zentrale Lösungen im Fokus:

• SAP HCM (Human Capital Management)
• SAP SuccessFactors

SAP HCM war lange Zeit der Standard in der klassischen On-Premise-Welt und bietet hohe Datenkontrolle.

Parallel dazu entwickelt sich SAP SuccessFactors zunehmend weiter und gilt als führendes, flexibles und modernes HR-System in der cloudbasierten Welt.

Dadurch stellen sich die Fragen, worin eigentlich die Unterschiede liegen und warum die Unternehmen immer mehr auf SAP SuccessFactors setzen.

Um diese Fragen beantworten zu können, benötigt man wie folgt einen Überblick der beiden Systeme:

ㅤㅤㅤㅤㅤ

SAP HCM:

• Das SAP HCM System ist ein traditionelles On-Premise HR-System, welches Kernprozesse wie z.B. Personaladministration, Entgeltabrechnung und Zeitwirtschaft zuverlässig abdeckt.
• SAP HCM wird seit Jahrzehnten als stabile Basis der HR-IT von vielen Unternehmen genutzt.

SAP SuccessFactors:

• SAP SuccessFactors hingegen wurde speziell für moderne Anforderungen als Cloud-Lösung entwickelt.
• Es bietet neben den klassischen HR-Funktionen auch innovative Tools für zukunftsorientierte, sicherheitsorientierte und flexible Unternehmen.

ㅤㅤㅤㅤㅤ

Technische Unterschiede:

Der größte Unterschied zwischen den beiden Systemen liegt in der Architektur.

Das SAP HCM ist ein On-Premise-System, welches starke individuelle Anpassungen ermöglicht.

Jedoch wird es dadurch auch deutlich wartungsintensiver.

Das SAP SuccessFactors ist eine cloudbasierte Lösung mit regelmäßigen Updates seitens SAP.

Dadurch ist der allgemeine Wartungsaufwand deutlich geringer.

Aufgrund der vorhandenen Cloud-Technologie profitieren Unternehmen, welche SAP SuccessFactors nutzen, von automatischen Updates und den daraus resultierenden neuen Funktionen, welche ohne aufwendige Implementierungsprojekte nutzbar sind.

Im Gegensatz dazu erfordert das SAP HCM manuelle Upgrades, welche meist sehr umfassende Tests benötigen.

ㅤㅤㅤㅤㅤ

Funktionsumfang und Innovation:

SAP HCM ist stark auf administrative Prozesse ausgerichtet, während SAP SuccessFactors einen deutlich erweiterten Funktionsumfang bietet wie z. B.:

• Employee Experience und Feedback-Tools (Erfahrungen, Eindrücke und Emotionen der Mitarbeiter)
• People Analytics (datengestützte Analyse von Mitarbeiterdaten)
• Learning & Development
• Talentmanagement (Recruiting, Performance, Nachfolgeplanung)

SAP SuccessFactors verfolgt einen ganzheitlichen Ansatz welcher besagt, dass Mitarbeitende im Mittelpunkt stehen und nicht nur die Prozesse. Es gibt moderne Features wie z.B. eine KI-gestützte Empfehlung oder ein kontinuierliches Feedback, welche eine agile Unternehmenskultur unterstützen.

ㅤㅤㅤㅤㅤ

Benutzerfreundlichkeit:

Ein weiterer Faktor welcher nicht zu unterschätzen ist, ist die User Experience.

• Als funktional und weniger intuitiv gilt SAP HCM
• SuccessFactors überzeugt hingegen mit einer modernen, webbasierten Oberfläche, welche ebenso intuitiv aufgebaut ist.

Die einfache Bedienbarkeit ist gerade für Mitarbeitende und Führungskräfte ohne HR-Hintergrundwissen ein klarer Vorteil.

Zudem steigern die mobilen Nutzungsmöglichkeiten die Attraktivität von SuccessFactors.

Zukunftssicherheit:

Aufgrund der klaren Kommunikation seitens SAP, wird die Zukunft im Cloud-Bereich liegen.

SuccessFactors wird kontinuierlich weiterentwickelt und ist ein zentraler Bestandteil der SAP-Strategie.

ㅤㅤㅤㅤㅤ

Hingegen gilt für SAP HCM:

• Langfristig wird es eine Einschränkung der Wartung geben
• Es besteht ein klarer Fokus auf die Integration in neue Cloud-Lösungen

Wenn Unternehmen zum derzeitigen Zeitpunkt in ihre HR-Systemlandschaft investieren, sollten sie daher die langfristigen Perspektiven berücksichtigen.

Integration und Erweiterbarkeit:

Aufgrund des Systemaufbaus von SAP SuccessFactors lässt es sich nahtlos in andere Cloud-Lösungen integrieren.

Durch die Anbindungsmöglichkeit diverser APIs und standardisierten Schnittstellen ermöglicht es eine flexible Systemlandschaft.

SAP HCM bietet im Gegenzug ebenfalls Integrationsmöglichkeiten, diese sind jedoch häufig komplexer und weniger flexibel.

ㅤㅤㅤㅤㅤ

Fazit:

Als führendes HR-System etabliert sich SAP SuccessFactors zunehmend. Besonders interessant ist dieses für Unternehmen die auf Innovation, Flexibilität und Zukunftssicherheit setzen. Aufgrund dessen stellt sich für viele Unternehmen daher nicht die Frage ob, sondern wann der Wechsel in das Cloud-System erfolgen soll. SuccessFactors bietet hierfür eine leistungsstarke und zukunftsorientierte Plattform, welche aufgrund ihrer Flexibilität weit über klassische HR-Funktionalitäten hinausgeht.

ㅤㅤㅤㅤㅤ

Zeitwirtschaft im EC Payroll Kontext

Nutzung des RPTIME00 ist in einer EC Payroll Umgebung möglich!

Employee Central Payroll (ECP) ist die SAP-basierte Payroll-Lösung innerhalb der SAP SuccessFactors Suite. Sie kombiniert die Stärken von SAP HCM Payroll mit der Cloud-Plattform von SuccessFactors. Die Technologie der Payroll ist dabei weitgehend die altbekannte.

Der Knackpunkt war in der Vergangenheit häufig, dass die Zeitwirtschaft nicht in dem oben genannten Szenario genutzt werden durfte.

Employee Central Payroll – Überblick

• Datenfluss: Stamm- und Bewegungsdaten (z. B. Eintritte, Gehaltsänderungen) werden aus SuccessFactors EC über die Replikation in die EC Payroll übertragen
• Abrechnungslogik: Basiert auf dem klassischen SAP-Payroll-Schema (z B RPCALCD0/ D000 für Deutschland), inklusive aller gesetzlichen Anforderungen wie Steuer, SV, etc.
• Betrieb: Gehostet in der SAP-Cloud
• Läuft üblicherweise täglich oder vor dem Abrechnungslauf
• Regulatorische Compliance: Länderspezifische Rechtspakete (Legal Change Packages) werden regelmäßig eingespielt. Updates folgen dem aus der on premise Welt bekannten Patch Zyklus

RPTIME00 ist ein ABAP-Reportprogramm, das für die Zeitauswertung (Time Evaluation) genutzt wird – Überblick• Aufruf des Zeitauswertungsschemas (z.B. TM00 für Deutschland) zur Berechnung von Zeitsalden, Überstunden, Zeitlohnarten etc.

• Aufruf des Zeitauswertungsschemas (z. B. TM00 für Deutschland) zur Berechnung
  von Zeitsalden, Überstunden, Zeitlohnarten etc.
• Verarbeitung von Zeitdaten aus den Infotypen 2002 (Zeiterfassung), 2001 (Abwesenheiten) etc.
• Befüllung der Zeitkonten (Cluster B2) als Grundlage für die Entgeltabrechnung
• Wird per Transaktion PT60 aufgerufen (oder direkt als Report)
• Läuft üblicherweise täglich oder vor dem Abrechnungslauf
• Verbindung zur Abrechnung: Nach erfolgreicher Zeitauswertung stehen Zeitergebnisse (z. B. Stundenlohngrundlagen, Überstundenzuschläge) über Lohnarten in der Payroll zur Verfügung.

Ursprünglich war die Nutzung des RPTIME00 nicht für EC Payroll Umgebungen vorgesehen. Dies ist nun anders. Die Details entnehmen Sie bitte der folgenden SAP Dokumentation: https://help.sap.com/docs/successfactors-employee-central-payroll/employee-central-payroll-product-description/time-management?version=2511&locale=de-DE

Weiterhin nicht „nutzbar“ sind die folgenden Funktionalitäten im EC Payroll Deployment Modell:

• Es ist nicht möglich, das API Employee Central CompoundEmployee zum Replizieren von Mitarbeiterzeitdaten zu verwenden. Sie können keine MDF-Objekte für Bewegungsdaten registrieren
• Kein Manager Self-Service (MSS) in Employee Central Payroll
• Kein Employee Self-Service (ESS) in Employee Central Payroll
• Keine Workflows und Genehmigungen in Employee Central Payroll
• Kein Organisationsmanagement in Employee Central Payroll
• Der Zugriff und die Pflege aller Abrechnungs- oder Zeitinfotypen erfolgt in Employee Central Payroll und nur von berechtigten Sachbearbeitern. Im Klartext bedeutet dies, ESS / MSS Szenarien, Workflows und das zugrunde liegende OrgChart sind im Employee Central abzubilden. Die Resultate der EC Prozesse werden ins EC Payroll repliziert und in den dafür vorgesehenen „Time“ Infotypen gespeichert.

Weitere Informationen können Sie sich in unseren Webinaren zu den Themen ansehen:

SuccessFactors EC Payroll – Die Point to Point Integration; Fokus Payroll

https://lmconsulting.de/successfactors-ec-payroll-point-to-point-integration-webinar/

SuccessFactors EC Payroll – Die Point to Point Integration; Fokus Time

https://lmconsulting.de/successfactors-ec-payroll-die-point-to-point-integration-fokus-time/

Die Herausforderung globaler HRIS-Implementierungen 

Internationale Unternehmen stehen bei der Implementierung von HR-Systemen vor einem strukturellen Spannungsfeld: Einerseits erfordert die globale Organisation ein harmonisiertes, einheitliches Datenmodell. Andererseits unterliegen Personalstammdaten in jedem Land spezifischen gesetzlichen Anforderungen hinsichtlich Pflichtfeldern, Datenformaten und Sichtbarkeitslogiken. 

In SAP SuccessFactors Employee Central basiert die Architektur auf einem globalen Datenmodell. Länderspezifische Anforderungen werden über das Country-Specific Fields (CSF)-Datenmodell integriert.

Dieses ermöglicht landesspezifische Konfigurationen für zentrale Elemente wie:

• globalInfo
• homeAddress
• nationalIdCard
• jobInfo
• compInfo
• employmentInfo

Für über 100 Länder stellt SAP vorkonfigurierte Inhalte bereit – etwa Ausweisnummernformate oder landestypische Adressstrukturen. So lassen sich lokale Anforderungen strukturiert in ein globales Template einbetten.

Steuerung über die Business Configuration UI

Die Business Configuration UI (BCUI) bildet die technische Grundlage. Globale Felder bleiben optional, während länderspezifische Konfigurationen Pflichtstatus und Sichtbarkeit gezielt übersteuern.

Bei identischen Feld-IDs können Mandatory und Visibility pro Land individuell definiert werden, während Feldattribute wie Auswahllisten oder Freitextfelder für eine Feld-ID länderübergreifend harmonisiert bleiben müssen. Die Steuerung erfolgt automatisiert über die Rechtseinheit des Mitarbeiters – relevante Felder werden systemseitig angezeigt und gegebenenfalls verpflichtend gesetzt.

 Business Rules als zentrale Steuerungsebene

Business Rules ergänzen die BCUI und sind insbesondere dann entscheidend, wenn:

• komplexe Mehrfachbedingungen gelten
• zusätzliche Attribute wie Mitarbeiterklasse oder Beschäftigungsart berücksichtigt werden müssen
• keine Country-Specific Fields konfigurierbar sind

Sie ermöglichen dynamische Pflichtfeldlogiken und kontextabhängige Validierungen – etwa, wenn ein Feld nur verpflichtend wird, sobald mehrere Kriterien gleichzeitig erfüllt sind.

Damit bilden Business Rules eine eigenständige und unverzichtbare Komponente jeder Multi-Country-Architektur.

Person Types für differenzierte Szenarien

Für Onboardees, Contingent Worker oder andere spezielle Gruppen lassen sich Person Types definieren. Diese übernehmen Basiselemente, erlauben typenspezifische Pflicht- und Sichtbarkeitsregeln und können ebenfalls länderspezifisch konfiguriert werden.

Country/Region-Specific Person Types überschreiben globale Konfigurationen und schaffen eine klare Hierarchie innerhalb komplexer Systemlandschaften.

Berechtigungsmanagement berücksichtigen

Länderspezifische Felder erzeugen eigenständige Role-Based Permission (RBP)-Einträge, die explizit freigegeben werden müssen.

Berechtigungen sollten daher immer parallel zur Konfiguration getestet und validiert werden.

Strukturierte Implementierung

Eine nachhaltige Multi-Country-Umsetzung umfasst:

1. Analyse der vorhandenen CSF-Standards
2. BCUI-Konfiguration nach dem Prinzip „global optional, lokal gesteuert“
3. Einsatz von Business Rules für komplexe Logiken
4. Definition von Person Types für Sonderfälle
5. Anpassung der RBP für länderspezifische Felder – unter Berücksichtigung, dass Role-Based Permissions in der Neueinstellungsmaßnahme (Add New Employee) nicht greifen. In diesen Fällen muss die Steuerung von Sichtbarkeit oder Pflichtlogiken ergänzend über onInit Rules erfolgen.
6. End-to-End-Tests über alle Länder und Rollen

Ergebnis

Die Kombination aus CSF-Datenmodell, BCUI, Business Rules und Person Types ermöglicht:

• Optimierte User Experience durch kontextbezogene Feldsteuerung  
• Skalierbarkeit für neue Länder durch Nutzung von SAP-Standards  
• Hohe Flexibilität durch dynamische Business Rules  
• Automatisierte Steuerung über Attribute wie legale Einheit, Länder, Standorte, etc. 

So entsteht ein global konsistentes HR-System mit lokaler Präzision – wartbar, erweiterbar und regulatorisch belastbar.

Data Retention Management im SAP SuccessFactors Recruiting

Im Zuge der EU-DSGVO müssen Unternehmen rechtliche und geschäftliche Aspekte gegen die Anforderungen des Datenschutzes ablegen, um Daten zu löschen, wenn sie für den Geschäftszweck nicht mehr benötigt werden. Es ist interessant zu sehen, wie diese Anforderungen innerhalb von SAP SuccessFactors Recruiting mit DPCS 2.0 erfüllt werden können, angefangen mit der Datenschutzerklärung zum Start des Bewerbungsprozesses. Aber unter welchen Voraussetzungen wird, neben den technischen Einstellungen, eine Bewerbung und ein Kandidatenprofil letztlich anonymisiert? Wie ist das Verhalten von SAP SF Recruiting und wie funktioniert das Data Retention Management im SAP SuccessFactors Recruiting?

Die Antworten auf diese Fragen erfahren Sie in diesem Blogbeitrag!

Grundlegendes zum Data Retention Management im SAP SuccessFactors Recruiting

Wann gilt eine Bewerbung als inaktiv?

Eine inaktive Bewerbung ist eine „geschlossene“ Bewerbung, die in den Status „Withdrawn“ oder „Disqualified“ liegt. Bewerbungen werden nur anonymisiert, wenn der Job „Purge Inactive Applications“ eingeplant wurde.

Bewerbungen in den Status „Hired on other Requisition“ und „Requisition Closed“ gelten als aktive Bewerbungen. Wenn eine Anonymisierung zusätzlich in einer dieser beiden Status ausgeführt werden soll, muss dies unter Recruiting-Einstellungen verwalten separat aktiviert werden.

Welches Startdatum kann gewählt werden, um die Löschfrist für die Anonymisierung der Bewerbung zu triggern?

Es gibt 3 Möglichkeiten, wann das System das Startdatum für zu anonymisierende Bewerbungen berechnet.

1. Datum der letzten Änderung (jede Aktualisierung durch einen Kandidaten oder Recruiter, setzt die Uhr zurück; der Zeitstempel kann über einen Report generiert werden)
2. Datum der Verschiebung in einen Dispositionsstatus durch das System (empfohlen)
3. Datum der Schließung einer Stelle

Wann wird das Kandidatenprofil gelöscht?

Das Kandidatenprofil wird gelöscht, wenn folgende Kriterien erfüllt sind:

• Einstellung des DRTM Inactive Candidate Profile Jobs
  • Der Kandidat hat sich innerhalb eines vom Unternehmen definierten Zeitraumes nicht in seinem Kandidatenprofil angemeldet
  • Der Kandidat hat die Datenschutzerklärung in einem definierten Zeitraum nicht akzeptiert
• Beantragung der Löschung
  • Das Kandidatenprofil wurde vom Kandidaten oder von einem Admin gelöscht

-> sollten noch aktive Bewerbungen existieren, werden diese vom System in den Status „Deleted on Demand by Candidate“ oder „Deleted on Demand by Admin“ geschoben. Die Daten werden markiert und mit dem nächsten Löschlauf anonymisiert

• Zurückziehen der Datenschutzerklärung
  • Der Kandidat oder ein Admin haben die Datenschutzerklärung zurückgezogen

-> sollten noch aktive Bewerbungen existieren, werden diese vom System in den Status „Declined DPCS“ geschoben. Die Daten werden markiert und mit dem nächsten Löschlauf anonymisiert

• Einstellungen in Recruiting-Einstellungen verwalten
  • Wenn der Punkt Kandidatenprofil nicht löschen, falls es für den Kandidaten Bewerbungen im System gibt nicht aktiviert ist (nicht empfohlen), wird das Kandidatenprofil nach Ablauf der definierten Löschfrist gelöscht, selbst wenn noch aktive Bewerbungen existieren. Das Kandidatenprofil wird demnach unabhängig vom Status der Bewerbung gelöscht.
  • Wenn der Punkt Kandidatenprofil nicht löschen, falls es für den Kandidaten Bewerbungen im System gibt aktiviert ist (empfohlen), wird das Kandidatenprofil abhängig vom Status gelöscht, in der sich die Bewerbung des Kandidaten befindet:

Bewerbungsstatus	Kandidatenprofil
In Progress	Wird nicht gelöscht
Draft, Closed, Withdrawn, Disqualified	Wird gelöscht
Requisition closed	Wird gelöscht, wenn die Einstellung hierfür aktiviert wurde
Hired on other Requisition	Wird gelöscht, wenn die Einstellung hierfür aktiviert wurde

Wann wird eine Bewerbung gelöscht?

Die Löschung einer Bewerbung ist unter anderem abhängig vom Bewerbungs-Status, in dem sich ein Kandidat befindet. Bewerbungen, die in einem Status der Gruppe „Withdrawn“, „Disqualified“ oder in gewissen System-Status liegen, werden gelöscht.

Withdrawn-Status sind:
Deleted on Demand by Candidate
Deleted on Demand by Admin
Declined DPCS
Withdrawn by Candidate

Bewerbungen in den ersten drei genannten Status werden dabei über den RCM Entity Anonymization Job gelöscht. Die Löschung erfolgt dann in 1-60 Minuten. Bewerbungen im Status Withdrawn by Candidate werden mit der Löschfrist gelöscht, die im DRTM Job Application Objekt angegeben ist.

System-Status, in denen eine Löschung erfolgt, sind:
Requisition Closed (muss separat aktiviert werden, um die Löschung zu triggern)
Hired on Other Requisition (muss separat aktiviert werden, um die Löschung zu triggern)
Auto Disqualified.

Zur besseren Übersicht hier nochmal in tabellarischer Form dargestellt:

Status-Gruppe	Status Name	Verhalten
Withdrawn-Status	Deleted on Demand by Candidate	Das Profil wird gelöscht und die Bewerbung wird beim nächsten Entity Anonymization Job markiert
	Deleted in Demand by Admin	Das Profil wird gelöscht und die Bewerbung wird beim nächsten Entity Anonymization Job markiert
	Declined DPCS	Das Profil wird gelöscht und die Bewerbung wird beim nächsten Entity Anonymization Job markiert
	Withdrawn by Candidate	Die Bewerbungen werden von den DRTM Löschjobs für inaktive Anwendungen gemäß der Aufbewahrungsfrist bereinigt.
In Progress -Status	Jeder	Die Bewerbungen werden nicht anonymisiert
Forwarded Status	Forwarded	Die Bewerbungen werden nicht anonymisiert
	Invited to Apply	Die Bewerbungen werden nicht anonymisiert
System Status	Default	Die Bewerbungen werden nicht anonymisiert
	Requisition Closed	Die Bewerbungen werden gelöscht, wenn die Einstellung hierfür aktiviert wurde
	Hired on Other Requisition	Die Bewerbungen werden gelöscht, wenn die Einstellung hierfür aktiviert wurde
	Auto Disqualified	Die Bewerbungen werden von den DRTM Löschjobs für inaktive Anwendungen gemäß der Aufbewahrungsfrist bereinigt.
Onboard-Status	Jeder	Die Bewerbungen werden von den DRTM Löschjobs für inaktive Anwendungen gemäß der Aufbewahrungsfrist bereinigt.
Disqualified	Jeder	Die Bewerbungen werden von den DRTM Löschjobs für inaktive Anwendungen gemäß der Aufbewahrungsfrist bereinigt.

Was passiert, wenn das Kandidatenprofil gelöscht wurde und die Bewerbung in einem Disqualified-Status ist?

Wenn dies der Fall ist, wird das Kandidatenprofil innerhalb von 1-60 Minuten anonymisiert und die Bewerbung zur Anonymisierung markiert. Die Bewerbung bleibt allerdings bis zum Ablauf der Löschfrist vorhanden und wird nicht anonymisiert. Dies hat einen rechtlichen Hintergrund und ist erwartetes Systemverhalten.

Welche Möglichkeiten gibt es, wenn der Kandidat umgehend keine Bewerbungsdaten und Profildaten mehr im System haben möchte?

Wenn ein Kandidat darauf besteht, sowohl die Bewerbung als auch das Profil umgehend gelöscht haben zu wollen, können Sie einen Workaround gehen, wenn folgende Bedingungen erfüllt sind: Die Bewerbung ist in einem Disqualified-Status und das Kandidatenprofil ist noch nicht anonymisiert. Schieben Sie den Kandidaten wieder in einen In-Progress-Status. Stellen Sie sicher, dass keine automatische E-Mail an den Kandidaten oder das Recruiting Team ausgelöst wird. Es kann auch ein Dummy Status für so einen Fall angelegt werden. Nach Verschieben der Bewerbung kann das Kandidatenprofil über die Funktion Kandidaten löschen gelöscht werden und sowohl das Profil als auch die Bewerbung werden mit dem nächsten RCM Entity Anonymization Job gelöscht.

Manuell hinzugefügte Bewerbungen und nicht akzeptierte Datenschutzerklärung

Wird ein Kandidat manuell hinzugefügt und hat bis Ablauf der vom Unternehmen definierten Zeit die Datenschutzerklärung noch nicht bestätigt, werden Bewerbungen, die im Status „Weitergeleitet“, „Zur Bewerbungen eingeladen“ oder anderen In-Progress-Status sind, nicht gelöscht. Dies hat zur Folge, dass die Bewerbung ewig im System hängt. Die Bewerbung lässt sich danach nur noch mit einem Ticket an die SAP löschen.

Haben Sie Fragen zum Data Retention Management im SAP SuccessFactors Recruiting oder brauchen Sie weitere Hilfe? Kontaktieren Sie uns über das Kontaktformular und senden Sie uns eine Nachricht.

SAP HCM EU DSGVO im Application Management

Ausgangssituation

Leistungsbestandteile SAP HCM Application Management

​

 

Haben Sie Fragen oder brauchen Sie ein auf Sie zugeschnittenes Angebot? Kontaktieren Sie uns über das Kontaktformular und senden Sie uns eine Nachricht.

 

EU DSGVO im SAP HCM: ILM – Löschen der Tabelle TEVEN

Ausgangssituation

Problem

Einer unserer Kunden arbeitet im 3-Schichtsystem, 24 Stunden am Tag. Alle 30 Minuten werden die aufgetretenen Kommen-/Gehen- Zeiten der Mitarbeiter in das SAP-System importiert. Zu der Zeit, wo das ILM-Objekt HRTIM_TEV ausgeführt wird, kommt es dabei immer wieder zu Abbrüchen bzw. fehlerhafter Verarbeitung, da sich die beiden Prozesse gegenseitig die Personalnummern sperren.

Das ILM-Objekt HRTIM_TEV sperrt die Personalnummern nacheinander und gibt sie jeweils nach der Verarbeitung wieder frei. Somit werden beim Datenimport der Kommen-/Gehen- Zeiten teilweise Personalnummern verarbeitet und teilweise nicht. Ebenso sperrt der Datenimport die Personalnummern der Reihe nach und verhindert somit die Verarbeitung durch das ILM-Objekt.

Lösung

Um das Problem zu umgehen, wurde ein kundeneigenes Lösch-Programm entwickelt, welches alle Personalnummern zu Beginn sperrt und erst am Ende wieder komplett freigibt. Der Datenimport läuft weiterhin auf Fehler. Da allerdings beim Import keine Daten verarbeitet werden, können nach Freigabe der Personalnummern alle bis dahin aufgelaufenen Kommen-/Gehen- Zeiten im Gesamten importiert werden.

Das ILM-Objekt HRTIM_TEV besteht aus drei einzelnen Programmen (Vorlauf, Schreiblauf, Löschlauf), welche nacheinander ausgeführt werden. Das neu entwickelte Lösch-Programm prüft und löscht in einem. Dabei werden die Funktionen des Standard ILM-Objektes beachtet. Dazu gehört das Prüfen der Vernichtungssperre im Infotyp 3246, das Anlegen und Aktualisieren des Infotypen 0283 und 0003 und die Prüfung der Löschfristen auf Basis des bzw. der Regelwerke des Standard ILM-Objektes.

Ebenso wird ein detailliertes SLG-Log geschrieben, allerdings in einem eigenen Log-Objekt.

Im Selektionsbild des Lösch-Reports lassen sich die gleichen Einstellungen vornehmen wie im Vorlaufprogramm des Standard ILM-Objektes. Ein Testlauf ermöglicht die komplette Simulation ohne, dass tatsächlich Daten gelöscht werden.

Mit Ausführen des Reports findet eine Vorprüfung statt. Zum Beispiel wird geprüft, ob es eine Vernichtungssperre zur Personalnummer gibt und bis wann es möglich ist, grundsätzlich Daten zu löschen (Rückrechnungsgrenze). Ebenso wird die Anzahl an Datensätzen zur jeweiligen Personalnummer ermittelt. Die Ausgabe des Ergebnisses erfolgt in einem ALV.

Mit dem Markieren einzelner oder aller Daten und betätigen des Buttons „Löschen“, wird der Löschvorgang gestartet. Im Ergebnis sieht man wie viele Datensätze je Personalnummer gelöscht wurden. Ebenso einen Meldungstext mit Hinweis auf Fehler.

Während des Löschvorgangs wird das Regelwerk durchlaufen und ein Protokoll analog den Meldungen aus dem Standard ILM-Objekt komprimiert in ein eigenes Log-Objekt geschrieben. Mit Klick auf den Button „Logdaten“ lässt sich das Protokoll einsehen.

Wenn der Report im Hintergrund ausgeführt wird, wird die ALV Ausgabe übersprungen und der Löschvorgang direkt gestartet.

Haben Sie Fragen wie Sie die Tabelle TEVEN löschen können oder brauchen Sie weitere Hilfe? Kontaktieren Sie uns über das Kontaktformular und senden Sie uns eine Nachricht.

 

Kombinierte Prüfung von Zeitbezügen bei ausgetretenen Mitarbeitern

Ausgangssituation

Im Zuge der Einführung von SAP Information Lifecycle Management im HCM stellt unter anderem die Frage der Löschlogik für Daten von ausgetretenen Mitarbeitern. Hinsichtlich des Bezugsdatums von den zu löschenden Daten bei ausgetretenen Mitarbeitern gibt es nach unseren Erfahrungen unterschiedliche Anforderungen sowie Lösungswege.

Auch die SAP ist bemüht, den Anforderungen gerecht zu werden und hat vor diesem Hintergrund erst kürzlich den Hinweis 2783754 ausgeliefert, der es ermöglichen soll, für ausgetretene Mitarbeiter sowohl High-End-Datensätze als auch abgegrenzte Datensätze gemeinsam in einem Regelwerk zu verarbeiten.

Dies funktioniert prinzipiell, deckt aber nicht alle Anforderungen ab, die von den Unternehmen gestellt werden.

Wir möchten Ihnen im Folgenden verschiedene Lösungsvarianten vorstellen:

Herausforderungen & Lösungsmöglichkeiten

Von den angelegten Regeln innerhalb eines Regelwerks kann immer nur eine einzige Regel pro Lauf angewendet werden. Standardmäßig wird die Regel gewählt, nach der der Datensatz am längsten aufbewahrt werden würde. Dies führt aber nicht immer zum gewünschten Ergebnis. Anhand eines Beispiels soll das Problem verdeutlicht werden.

In einem Regelwerk werden folgende Regeln angelegt:

Mit der ersten Regel soll erreicht werden, dass alle Datensätze gelöscht werden, sobald deren Enddatum 5 Jahre zurückliegt. Dies soll sowohl für ausgetretene als auch für aktive Mitarbeiter geschehen.

Darüber hinaus sollen die Daten ausgetretener Mitarbeiter aber auch dann vernichtet werden, wenn der Austritt des Mitarbeiters 10 Jahre zurückliegt.

Für die Daten ausgetretener Mitarbeiter handelt es sich hiermit um eine kombinierte Anforderung. Im Grunde möchte man erreichen, dass die Daten vernichtet werden, sobald ENTWEDER das Datensatzende 5 Jahre ODER das Austrittsdatum 10 Jahre zurückliegt.

Leider werden die Regeln aber nicht so verarbeitet, wie es gewünscht ist:

Da die beiden Datensätze mit Ende-Datum 01.05.2012 schon 5 Jahre zurückliegen, wird erwartet, dass diese gelöscht werden. Auf High-End-Datensätze nimmt die erste Regel keinen Einfluss, da solche nur bei einer Prüfung auf Austritt berücksichtigt werden. Da der Austritt aber noch keine 10 Jahre zurückliegt, darf der High-End-Datensatz nicht vernichtet werden.

Leider wird ausschließlich der 1. Datensatz für den aktiven Mitarbeiter vernichtet.

Das liegt daran, dass die beiden Regeln miteinander konkurrieren und nur eine von ihnen tatsächlich ausgeführt wird. Konkurrieren mehrere Regeln miteinander, wird geprüft, nach welcher Regel die Datensätze am längsten aufbewahrt werden würden. Nach der ersten Regel wäre das Löschdatum am 01.05.2017; nach der zweiten Regel am 31.12.2023. Somit wird die zweite Regel angewendet und der Datensatz nicht vernichtet.

Dies ist jedoch nicht das gewünschte Ergebnis, sodass eine Lösung gefunden werden muss.

Die SAP hat mittlerweile einen Hinweis ausgeliefert, mit dem sowohl auf Datensatzende als auch auf Austritt geprüft werden kann. Jedoch können die oben genannten Anforderungen auch mit dem Hinweis nicht erfüllt werden:

Der Hinweis „2783754: Use of HCM_TERMN_DATE and HCM_END_OF_RECORD“ bringt ein neues Bedingungsfeld mit sich, mit dem zwischen High-End- und Nicht-High-End-Datensätzen unterschieden werden kann. Es handelt sich dabei um ein Feld des Typs BOOLEAN. In diesem wird entweder ein Y für High-End-Datensätze oder ein N für Nicht-High-End-Datensätze eingetragen.

Somit ist es nun möglich, die oben aufgeführten Regeln jeweils um dieses Bedingungsfeld zu erweitern:

Um den Hinweis einzuspielen, muss das Bedingungsfeld manuell bei jedem Objekt angelegt werden, für das das Bedingungsfeld benötigt wird. Dies schließt auch die Pflege der objektkategoriespezifischen Einstellungen (SM34) ein, in denen die Felder zur Wertermittlung eingetragen werden müssen. Somit fällt ein hoher zusätzlicher Aufwand an, um diesen Hinweis einspielen zu können.

Nach Einspielen des Hinweises ergibt sich folgende Situation:

Das tatsächliche Ergebnis entspricht nun den Erwartungen. Da für den 1. Infotypsatz des ausgetretenen Mitarbeiters nun nicht mehr auf das Austrittsdatum, sondern auf das Datensatzende geprüft wird, wird er mitvernichtet.

Für die High-End-Datensätze gilt dann ausschließlich die zweite Regel, welche auf das Austrittsdatum prüft.

In diesem Fall entspricht das Ergebnis den Erwartungen. Es gibt jedoch auch Daten-Konstellationen, bei denen dies nicht der Fall ist.

Annahme: Es sollen generell alle Daten 10 Jahre nach Datensatzende gelöscht werden. Für ausgetretene soll zusätzlich noch 10 Jahre nach Austritt gelöscht werden.

Der ausgetretene Mitarbeiter ist nun seit dem 31.12.2005 nicht mehr aktiv. Somit ergibt sich folgende Erwartung:

Da das Datensatzende der beiden 1. Infotypsätze noch keine 10 Jahre zurückliegt, dürfen sie nicht vernichtetet. Für den ausgetretenen Mitarbeiter soll aber zusätzlich gelten, dass trotzdem gelöscht wird, sobald der Austritt 10 Jahre zurückliegt. Dies ist der Fall. Somit müssten beide Datensätze von ihm gelöscht werden.

Mit dem Hinweis ist es allerdings nur möglich zwischen High-End- und Nicht-High-Datensätzen zu unterscheiden. Dies hilft in diesem Fall nicht weiter, da nun beim ersten Datensatz ebenfalls auf den Austritt geprüft werden müsste.

Mit dem Hinweis könnten folgende Regeln gebildet werden:

Auf diese Weise wird jedoch nicht korrekt gelöscht, da der Nicht-High-End-Datensatz des ausgetretenen Mitarbeiters noch nicht alt genug ist.

Der Hinweis eignet sich tatsächlich nur dafür, für Nicht-High-End-Datensätze einen anderen Zeitbezug einzustellen als für High-End-Datensätze. Ein kombinierter Zeitbezug, also dass beispielsweise sowohl auf Datensatzende als auch auf das Austrittsdatum geprüft wird, lässt sich damit nicht realisieren.

Es gibt zwei Möglichkeiten, die oben genannten Anforderungen trotzdem zu erfüllen:

Das erste prüft für alle Mitarbeiter auf das Datensatzende; das zweite prüft nur für ausgetretene Mitarbeiter alle Daten nochmals auf das Austrittsdatum.
Wichtig ist hierbei, dass die Regelwerke abwechselnd „produktiv“ und „nicht-produktiv“ geschaltet werden müssen. Dies bedeutet einen erhöhten Aufwand im späteren Betrieb, da für jedes Objekt somit zwei Vor-, Schreib- und Löschläufe sowie eine manuelle Status-Umschaltung der Regelwerke erfolgen müssen.
Die Anforderungen würden auf diese Weise allerdings vollständig abgedeckt werden:

Da es allerdings doch sehr aufwendig ist, die Regelwerke jedes Mal umzuschalten, empfehlen wir

die zweite Möglichkeit:

2. Möglichkeit – einen kundeneigenen Zeitbezug

Die zweite – und wesentlich elegantere – Variante besteht in der Implementierung eines kundeneigenen Zeitbezugs. Der Vorteil liegt hier darin, dass die Logik genauso realisiert werden kann, wie sie benötigt wird. Der Aufwand fällt nur ein Mal zu Beginn während der Implementierung an und ein manuelles Umschalten der Regelwerke entfällt. Zudem ist es auf diese Weise möglich, die Anforderung mithilfe eines einzigen Regelwerks umzusetzen.

Für einen kombinierten Zeitbezug, der sowohl auf Datensatzende als auch auf Austritt prüft, sähe die Logik folgendermaßen aus:

Sobald entweder das Datensatzende oder der Austritt 10 Jahre zurückliegt, wird der Datensatz gelöscht.
Die Regeln würden folgendermaßen aussehen:

Diese Lösung ist allerdings nur dann möglich, wenn die Aufbewahrungsfrist für Austritt und Datensatzende identisch ist.

Lautet die Anforderung jedoch…

…lösche die Daten ausgetretener Mitarbeiter, wenn entweder das Datensatzende 5 oder aber der Austritt 10 Jahre zurückliegt…

… ist ein kombinierter Zeitbezug nicht möglich. In diesem Fall sollte die erste Lösung mit den zwei verschiedenen Regelwerken priorisiert werden.

Zusammenfassung / Empfehlung

Bevor Sie sich für eine Lösung entscheiden, sollten Sie Ihre Anforderungen genauestens prüfen. Je nach Anforderung ist eine andere Lösung empfehlenswert:

Anforderung A:

Alle Daten sollen generell x Jahre nach Datensatzende gelöscht werden.

Problem A:

High-End-Datensätze bleiben stehen

Lösung A:

ENTWEDER:

High-End-Datensätze werden in den einzelnen Regelwerken nicht betrachtet und später im Zuge der Komplettlöschung (HRPA_PERNR) mitvernichtet

ODER:

Einspielen des Hinweises “2783754: Use of HCM_TERMN_DATE and HCM_END_OF_RECORD”, um für High-End-Datensätze eine eigene Prüfung auf Austritt zu realisieren.

Anforderung B:

Daten aller Mitarbeiter sollen x Jahre nach Datensatzende gelöscht werden.

Daten ausgetretener Mitarbeiter sollen y Jahre nach Austritt gelöscht werden.

Problem B:

Es konkurrieren zwei Regeln für die ausgetretenen Mitarbeiter. Die Fristen für Datensatzende und Austritt sind unterschiedlich.

Lösung B:

Zwei Regelwerke mit jeweils einer Regel (siehe 1. Möglichkeit)

Anforderung C:

Daten aller Mitarbeiter sollen x Jahre nach Datensatzende gelöscht werden.

Daten ausgetretener Mitarbeiter sollen x Jahre nach Austritt gelöscht werden.

Problem C:

Es konkurrieren zwei Regeln für die ausgetretenen Mitarbeiter. Die Fristen für Datensatzende und Austritt sind allerdings identisch.

Lösung C:

Implementierung eines kundeneigenen Zeitbezugs, der die beiden benötigten Zeitbezüge in sich vereint (siehe 2. Möglichkeit)

Ein Beitrag von Sanja Pierdziwol

 

SAP ILM: Kundeneigene Zeitbezüge SAP ILM analog zu HCM_TERMN_DATE verarbeiten

Ausgangssituation und Problemstellung:

Bei der Verwendung/Verarbeitung des kundeneigenen Zeitbezuges HCM_TERMN_DATE (Austrittsdatum) im SAP Standard findet eine harte Prüfung auf diesen Zeitbezug statt. Die Intention dieser Prüfung ist, auch die Highdate-Datensätze (31.12.9999) verarbeiten und loggen zu können.

Wenn ein kundeneigener Zeitbezug definiert wird, werden diese Highdate-Datensätze jedoch nicht korrekt verarbeitet/geloggt. Wir haben für Sie in einem konkreten Beispiel einen kundeneigenen Zeitbezug zum Renteneintritt angelegt. Dieser liefert das Datum des Renteneintritts des Mitarbeiters. Da allerdings nur hart auf das Austrittsdatum (HCM_TERMN_DATE) geprüft wird, konnten zu dem kundeneigenen Zeitbezug die Highdate-Datensätze nicht korrekt verarbeitet/geloggt werden.

Lösung:

Da es kein passendes BAdI hierfür gibt wurde für die Methode „MODIFY_EXCEEDS_LIMIT_FLAG“ eine Erweiterungsimplementierung angelegt in welcher analog zum HCM_TERMN_DATE nun auch das Z_TERMN_R2 geprüft wird.

Betrifft:

Klasse: CL_HRARCH_DESTRUCTION_LOG

Methoden: WRITE_DESTRUCTION_LOG und MODIFY_EXCEEDS_LIMIT_FLAG

Derzeitige Verarbeitung:

In der Klasse CL_HRARCH_DESTRUCTION_LOG Methode MODIFY_EXCEEDS_LIMIT_FLAG wird hart auf HCM_TERMN_DATE geprüft und das Flag von cv exceeds_limit_date entfernt. Das Flag steht auf X wenn es sich um einen Highend Datensatz handelt.

Das Vernichtungslog wird pro Datensatz über Methode WRITE_DESTRUCTION_LOG aufgerufen. Hier findet eine generelle Prüfung auf die Vernichtung (GET_RETENTION_RULES) und die Prüfung auf das Austrittsdatum (MODIFY_EXCEEDS_LIMIT_FLAG) statt.

Nur wenn beide Variablen (lv_destructible, lv_endda_adjusted) leer sind wird ein korrekter Logeintrag geschrieben.

Haben Sie Fragen zum Thema  „Kundeneigene Zeitbezüge SAP ILM“ oder brauchen Sie weitere Hilfe? Kontaktieren Sie uns über das Kontaktformular und senden Sie uns eine Nachricht.

 

Personaldaten in SAP HCM mit ILM löschen und die EU DSGVO unter Berücksichtigung der gesetzlichen Aufbewahrungsfristen in SAP HCM umsetzen

Der Bedarf

• Sie möchten Personaldaten in SAP HCM EU DSGVO konform löschen?
• Aktuelle Anforderung des BDSG Bundesdatenschutzgesetztes § 35 Anspruch auf Löschung.
• Ab April 2018 tritt die EU-Datenschutz-Grundverordnung (EU-DSGVO) in Kraft und ist geltendes
  Recht in allen EU Mitgliedstaaten.
• Zukünftige Verstöße gegen die EU-Datenschutz-Grundverordnung können mit bis zu 4 % des
  Jahresumsatzes eines Unternehmens geahndet werden.
• Vermeidung wachsender Komplexität der Systemlandschaft durch Datenreduzierung.

Voraussetzungen

• ERP 6.0 Enhancement Package 4 oder höher
• Details im Hinweis 1559133
• Auslieferung als Supportpackages im Juni 2011 und Juni 2012
• Einmalige Aktivierung Business Function ILM

Leistungsumfang des ILM

• Zusatztool LM Consulting zur Analyse personenbezogener Daten im SAP System
  o Customizing-Tabelle zur Erweiterung von Aufbewahrungsfristen
  o Selektion nach Standard bzw. Kundeninfotypen
  o Eine Filterfunktion ermöglicht eine Spezifikation der anzuzeigenden Datensätze
  o Ein Ampelsystem erleichtert die Datenanalyse
  o Ausgabe vorhandener Archivierungsobjekte
• Unterstützung bei der Datenanalyse
• Unterstützung Customizing ILM

Ihr Nutzen

• Einfaches, schnelles und komfortables Erstellen eines Löschkonzeptes
• Generisches Konzept um kundeneigene Infotypen zu integrieren
• Schneller ILM Projekterfolg
• EU DSGVO mit Hilfe von ILM im SAP HCM umgesetzt

Projektpreis: 9.900,00 Euro

Projektleistungen:

• Erstellung eines ILM Konzeptes
• Überlassung und Einsatz des ILM Tools (Einzelpreis ohne Projekt: 2.900,00 Euro)
• Unterstützung ILM Customizing

Individuelle Leistungen werden nach Aufwand berechnet.

Toolbeschreibung als PDF

Haben Sie Fragen zum Thema Personaldaten mit Hilfe von ILM im SAP HCM löschen oder brauchen Sie weitere Hilfe? Kontaktieren Sie uns über das Kontaktformular und senden Sie uns eine Nachricht.