SAP HCM & ILM: Warum Datenlöschung eine Frage der richtigen Reihenfolge ist

Ein produktiver ILM-Vernichtungslauf meldet Erfolg: Millionen Datensätze wurden DSGVO-konform gelöscht. Und trotzdem bleiben am Ende einige Tausend Sätze übrig – mit kryptischen Fehlermeldungen, die niemand auf Anhieb einordnen kann. Wer schon einmal einen Löschlauf in SAP HCM begleitet hat, kennt dieses Bild.

Der Grund ist fast nie ein technischer Defekt. Der Grund sind Abhängigkeiten: Personaldaten in SAP HCM sind über Stammdaten, Zeitwirtschaft und Abrechnung hinweg eng miteinander verwoben. Ein Datensatz lässt sich nur dann vernichten, wenn die von ihm abhängigen Daten bereits gelöscht wurden – oder wenn bestimmte „Anker“-Daten bewusst erhalten bleiben. Dieser Beitrag ordnet die wichtigsten Abhängigkeiten in fünf klare Muster.

Was ein ILM-Löschlauf tatsächlich prüft

SAP HCM geht regelbasiert vor – der eigentliche Knackpunkt steckt aber im Vorlauf. Neben dem Löschtrigger führen gerade die SAP-Standard-ILM-Objekte zahlreiche fachbezogene Plausibilitätsprüfungen durch. Genau dort werden die Abhängigkeiten geprüft:

1. Aufbewahrungsregel je ILM-Objekt: In der Retention-Policy (IRMPOL) ist pro ILM-Objekt eine Regel mit Zeitbezug – dem Löschtrigger, z. B. Austrittsdatum oder Ende des Datensatzes – und Aufbewahrungsdauer hinterlegt, ggf. mit Bedingungen (z. B. MOLGA).
2. Vorlauf mit fachlichen Plausibilitätsprüfungen: Vor jeder Löschung prüft das Vorlaufprogramm nicht nur den Löschtrigger, sondern – besonders bei den SAP-Standard-Objekten – eine Vielzahl fachbezogener Plausibilitäten. Genau hier greifen die Abhängigkeiten; scheitert eine Prüfung, bleibt der Satz erhalten.
3. Vernichtung: Erst wenn Löschtrigger und alle Plausibilitätsprüfungen bestanden sind, wird der Satz über das ILM-Vernichtungsobjekt physisch gelöscht.

Genau in diesen Vorlaufprüfungen greifen die Abhängigkeiten – und sie erklären auch, warum ein kundeneigenes ILM-Objekt (das ohne diese Standardprüfungen löscht) die zu Unrecht blockierten Sätze bereinigen kann.

Und die Sperrung? In SAP HCM reines Berechtigungswesen

Ein häufiges Missverständnis: Das ILM-Blocking, bei dem personenbezogene Daten nach Ende des Zwecks zunächst gesperrt im System verbleiben, ist eine Funktionalität aus dem Financials-Umfeld – nicht aus SAP HCM. In SAP HCM gibt es keine solche technische Sperrstufe. Eine „Sperrung“ von Personaldaten wird hier ausschließlich über das Berechtigungskonzept abgebildet: Die Anzeige der Daten wird verweigert, die Daten selbst bleiben unverändert bestehen – bis sie regulär vernichtet werden.

Die fünf Typen von Abhängigkeiten

1. Sequenzielle Abhängigkeiten (die Reihenfolge)

Ein wichtiger Grundsatz vorab: Für die meisten ILM-Objekte der Personaladministration und -abrechnung ist keine feste Löschreihenfolge erforderlich – der Ablauf ist frei wählbar. Es gibt jedoch klar definierte Ausnahmen, die durch die Vorlaufprogramme der Vernichtungsobjekte erzwungen werden.

Am ausgeprägtesten ist das in der Zeitwirtschaft, deren Objekte einer strengen Kaskade nach der Entstehung der Datenart folgen (siehe unten). Aber auch quer über einzelne Infotypen hinweg: Die Terminverfolgung (IT0019 / HRPA_TASK) muss vor Behinderung (IT0004 / HRPA_CHLLN) und Vertragsbestandteilen (IT0016 / HRPA_CTRCT) gelöscht werden; die Zeitkontingente (IT2006 / HRTIM_QUOT) müssen vor der Behinderung (IT0004) vernichtet werden – wegen des Bezugs zum Schwerbehinderten-Zusatzurlaub. Das umfassende Vernichtungsobjekt der Personalnummer (HRPA_PERNR), das die gesamte Personalnummer auf einmal löscht und den früheren Report RPUDELPN/RPUDELPP ablöst, wird dagegen bewusst zuerst als Grobreinigung eingeplant.

2. Subtyp- und Teilmengen-Ausnahmen (die Anker-Daten)

Nicht alle Daten eines Objekts dürfen zum selben Zeitpunkt verschwinden. Einzelne „Anker“-Sätze müssen erhalten bleiben, bis die Personalnummer final gelöscht wird. Bei den Anschriften (IT0006) bleibt der letzte gültige Wohnsitz (Subtyp 0001, Endedatum 31.12.9999) erhalten; bei der Kommunikation (IT0105) der Systembenutzer. Diese Anker-Sätze bleiben bei den objektspezifischen Löschläufen bestehen und werden ausschließlich durch die vollständige Personalnummer-Vernichtung (HRPA_PERNR) entfernt – solange die Person aus rechtlichen Gründen noch geführt werden muss, bleiben sie erhalten.

3. Länder- und MOLGA-spezifische Abhängigkeiten

Viele HCM-ILM-Objekte gelten nur für eine bestimmte Ländergruppierung (MOLGA). Ein Objekt für deutsche Steuerdaten greift nur bei Mitarbeitern mit MOLGA „Deutschland“. Hinzu kommen landesspezifische Sonderprüfungen: In Deutschland etwa werden Betriebsinterne Daten (IT0032) gegen die Steuerdaten (IT0012) im selben Zeitraum geprüft. Existiert dort ein Satz – Stichwort Dienstwagen und geldwerter Vorteil – bleibt IT0032 erhalten.

4. Customizing-Abhängigkeiten (die Plausibilitätsprüfungen)

Beim Vernichten prüft SAP, ob das zum Datensatz gehörende Customizing noch existiert. Wurde ein Subtyp oder eine Kontingentart (Tabelle T533) zwischenzeitlich aus dem Customizing entfernt, schlägt die Löschung fehl – mit Meldungen wie „Kein Subtyp zur Zeichenfolge vorhanden“. Das ist das vielleicht kontraintuitivste Muster: Gerade weil im Customizing aufgeräumt wurde, lassen sich die zugehörigen Altdaten nicht mehr löschen.

5. Modulübergreifende und technische Vorbedingungen

Manche Blockaden stammen aus einem ganz anderen Bereich als die zu löschenden Daten:

• Abrechnungsstatus (IT0003) – das häufigste Hindernis: Beim Löschen setzt ILM im IT0003 die „persönlich tiefste Rückrechnung“ (für Payroll und Zeitmanagement) auf das Ende des Löschzeitraums plus einen Tag. Liegt jedoch ein bereits eingestelltes Rückrechnungsdatum – Feld RRDAT (früheste Stammdatenänderung) bzw. BDERR (Rückrechnung Zeitwirtschaft) – im Löschzeitraum, bricht die Vernichtung ab. Zu Recht: In einen Zeitraum, der gelöscht wird, darf nicht mehr zurückgerechnet werden. Seltener blockieren „Abrechnen bis“ oder „Korrektur der Abrechnung“. In der Praxis betrifft das 20–30 % der löschrelevanten Personalnummern – also kein Randproblem, sondern das zentrale Hindernis. Bereinigt wird nach Freigabe durch die Abrechnung mit dem SAP-Standardreport RPUTRBK0.
• Archivierungsprotokolle (IT0283): Alte Protokolle verweisen auf Archivdateien, die längst gelöscht sind. Das System hält sie für vorhanden und blockiert damit die Vernichtung der Abrechnungsergebnisse (Objekt PA_CALC).
• Vernichtungssperre / Legal Hold: Eine aktive Sperre – etwa wegen laufender Rechtsstreitigkeiten – verhindert jede Vernichtung, bis sie aufgehoben wird.

Die empfohlene Löschreihenfolge

Übergeordnet ergibt sich diese Sequenz: Vorprüfung & Bereinigung (Löschtrigger erfüllt, keine Legal Holds, IT0003 und IT0283 sauber, Customizing konsistent) → HRPA_PERNR als Grobreinigung zuerst → dann die dedizierten Objekte, wobei nur die genannten Vorränge und die Zeitwirtschaft eine feste Reihenfolge verlangen.

Die Zeitwirtschaft ist dabei die wichtigste Ausnahme. Ihre Objekte müssen streng nach der Entstehung der Datenart gelöscht werden – vom Antrag bis zu den Clusterdaten:

1. Abwesenheitsanträge – HRTIM_REQ
2. Zeitereignisse & Zeiterfassungsinformationen – HRTIM_TEV, HRTIM_REC
3. An-, Abwesenheiten und Sonderfälle – HRTIM_ABS (Abwesenheiten), HRTIM_ATT (Anwesenheiten), HRTIM_MAT (Mutterschutz), HRTIM_MIL (Wehrdienst), HRTIM_SUBS (Vertretungen), HRTIM_AVAL (Bereitschaften), HRTIM_OVER (Mehrarbeiten)
4. Zeitkontingente – HRTIM_QUOT
5. Sollarbeitszeit – HRTIM_PWS
6. Clusterdaten der Zeitwirtschaft – PA_TIME (zum Abschluss)

Der Merksatz dahinter: Die Reihenfolge folgt der Entstehung der Daten – Antrag → Ereignis → An-/Abwesenheit → Kontingent → Sollzeit → Cluster. Übergeordnet gilt: HRPA_PERNR zuerst, HRPA_TASK vor IT0004/IT0016 – und: Vorprüfung schlägt Nacharbeit.

Aus der Praxis: die häufigsten Löschhindernisse

In realen Löschläufen lassen sich die zurückbleibenden Sätze fast immer fünf Fehlertypen zuordnen:

• A – Gesperrte Personalnummern: kein Handlungsbedarf, der Wiederholungslauf verarbeitet automatisch nach.
• B – Rückrechnung im Löschzeitraum (IT0003): Ein eingestelltes Rückrechnungsdatum (RRDAT / BDERR) liegt im Löschzeitraum; nach Freigabe der Abrechnung mit Report RPUTRBK0 bereinigen. (Seltener: „Abrechnen bis“.)
• C – Fehlende Subtypen / Customizing-Einträge: Customizing wiederherstellen oder kontrollierten Sonderweg nutzen.
• D – Kontingent-Inkonsistenzen in der Zeitwirtschaft: Kontingentdaten bereinigen.
• E – Verwaiste IT0283-Protokolle: blockieren PA_CALC und müssen bereinigt werden.

Für Sätze, die nachweislich die Löschkriterien erfüllen, aber an technischen Plausibilitätsprüfungen scheitern (Typen C–E), hat sich ein kundeneigenes ILM-Vernichtungsobjekt bewährt. Es löscht die betroffenen Datensätze kontrolliert, ohne die fehlschlagenden Standardprüfungen – wiederverwendbar und ohne riskante, temporäre Customizing-Änderungen im Produktivsystem.

Fazit

DSGVO-konforme Datenlöschung in SAP HCM gelingt nicht durch das bloße Aktivieren von Aufbewahrungsregeln. Sie gelingt, wenn die Abhängigkeiten zwischen den Vernichtungsobjekten verstanden, die Reihenfolge geplant und die Datenqualität vor dem Lauf gesichert ist. Die fünf beschriebenen Muster sind der rote Faden für ein belastbares Löschkonzept – und der Unterschied zwischen einem erfolgreichen Lauf und einer langen Fehlerliste.

Kostenloser Leitfaden: Abhängigkeiten HCM-relevanter ILM-Objekte

Die wichtigsten Abhängigkeiten, die konkrete Löschreihenfolge und die häufigsten Fehlerbilder aus der Praxis haben wir in einem kompakten, 8-seitigen Leitfaden zusammengefasst. Jetzt kostenlos als PDF herunterladen →

hoelterhoff.consulting begleitet SAP-HCM-Kunden im gesamten D-A-CH-Raum von der ILM-Konzeption über das Customizing der Aufbewahrungsregeln bis zum sauber dokumentierten Vernichtungslauf. Jetzt Erstgespräch vereinbaren.