Warum CDHDR und CDPOS für Process Mining nicht optimal sind
Wer Process Mining auf SAP aufsetzt, stößt früh auf die Änderungsbelege: CDHDR (Kopf) und CDPOS (Positionen). Der Reiz ist verständlich — hier liegt scheinbar alles, was ein Event-Log braucht: Objekt, Zeitstempel, Benutzer, geänderte Felder, zentral in zwei Tabellen. Viele Mining-Projekte bauen ihre Aktivitäten deshalb genau darauf.
Das Problem: Änderungsbelege wurden als Audit-Trail gebaut, nicht als Prozessprotokoll. Wer sie zum Rückgrat der Prozessanalyse macht, erbt vier strukturelle Schwächen.
1. Sie protokollieren Änderungen — nicht Prozessschritte
Ein Prozess besteht in SAP aus Belegen: Bestellung, Wareneingang, Rechnung, Zahlung. Jeder dieser Schritte ist ein eigener Beleg — keine Feldänderung an einem bestehenden Objekt. In CDHDR/CDPOS taucht er deshalb gar nicht oder nur indirekt auf.
Was dort steht, ist das Gegenteil: die nachträgliche Preisänderung, der verschobene Liefertermin, das gesetzte Sperrkennzeichen. Das ist wertvolles Material für Rework-Analysen — aber wer den Prozessfluss aus Änderungen rekonstruiert, zeichnet die Ausnahmen nach und verpasst den Fluss selbst.
2. Ihre Vollständigkeit hängt am Customizing
Ein Feld erzeugt nur dann einen Änderungsbeleg, wenn sein Datenelement das entsprechende Kennzeichen trägt — und das Logging für das Objekt aktiv ist. In der Praxis heißt das: Manche Änderungen werden protokolliert, andere nicht; bei Massenpflege wird das Logging aus Performance-Gründen gern abgeschaltet; und die Archivierung räumt alte Einträge weg.
Ein Event-Log, dessen Abdeckung von Systemeinstellungen abhängt, ist keine neutrale Aufzeichnung. Die Lücken sieht man dem Ergebnis später nicht an — die Analyse wirkt vollständig und ist es nicht.
3. Aus Feldänderungen werden Aktivitäten — per Interpretation
Zwischen „Feld LIFDT geändert” und der Prozessaktivität „Liefertermin verschoben” liegt eine Übersetzung, die jemand pflegen muss: Welche Feldänderung zählt als welche Aktivität? Welche werden ignoriert? Was ist mit Z-Feldern?
Diese Mapping-Tabellen sind je System verschieden, wachsen mit jedem Release und sind selbst nie fertig dokumentiert. Das Projekt baut damit eine zweite, interpretierte Wahrheit über das System — genau das, was eine datenbasierte Analyse eigentlich vermeiden will.
4. Volumen und Verzerrung
CDPOS gehört in gewachsenen Systemen zu den größten Tabellen überhaupt; die Extraktion über Objektklasse und Objekt-ID ist entsprechend teuer. Und die Einträge sind ungleich verteilt: Ein einziger Batchjob oder eine Massenänderung erzeugt tausende „Events” unter einem technischen Benutzer — im Mining-Ergebnis sieht das aus wie hektische Prozessaktivität, ist aber ein einzelner Verwaltungsakt.
Was stattdessen trägt: der Belegfluss
Die gute Nachricht: SAP dokumentiert den Prozess bereits selbst — in den Belegflüssen. Bestellhistorie, Vertriebsbelegfluss, Rechnungs- und Zahlungsreferenzen verketten die Belege, aus denen der Prozess wirklich besteht. Jeder Schritt ist dort ein echter Beleg mit Menge, Wert und Zeitpunkt — keine interpretierte Feldänderung.
Änderungsbelege erzählen, was an einem Beleg korrigiert wurde. Der Belegfluss erzählt, wie aus einer Bestellung eine bezahlte Rechnung wurde. Für Process Mining ist das zweite die Geschichte, die zählt.
CDHDR/CDPOS haben dabei ihren legitimen Platz — als Ergänzung: Wo im Fluss auffällig viel nachträglich korrigiert wird, lohnt der Blick in die Änderungen. Als Rückgrat des Event-Logs sind sie das falsche Fundament.
Conjola setzt genau deshalb auf die Belegflüsse: Process Discovery rekonstruiert die End-to-End-Prozesse deterministisch aus den Belegverknüpfungen Ihres Extrakts — mit Varianten, Häufigkeiten und Automatisierungsgraden, nachvollziehbar bis in den einzelnen Beleg. Ohne Mapping-Pflege, ohne Live-Verbindung ins System.