Why CDHDR and CDPOS aren't ideal for process mining
Anyone setting up process mining on SAP runs into the change documents early: CDHDR (header) and CDPOS (items). The appeal is obvious — everything an event log needs seems to be right there: object, timestamp, user, changed fields, centralized in two tables. Many mining projects build their activities on exactly that.
The problem: change documents were built as an audit trail, not as a process record. Making them the backbone of process analysis means inheriting four structural weaknesses.
1. They record changes — not process steps
In SAP, a process consists of documents: purchase order, goods receipt, invoice, payment. Each of these steps is a document of its own — not a field change on an existing object. Which is why it doesn’t appear in CDHDR/CDPOS at all, or only indirectly.
What you find there is the opposite: the retroactive price change, the shifted delivery date, the blocking indicator that was set. That is valuable material for rework analysis — but reconstructing the process flow from changes means tracing the exceptions while missing the flow itself.
2. Their completeness depends on customizing
A field only produces a change document if its data element carries the corresponding flag — and logging is active for the object. In practice that means: some changes are recorded, others aren’t; during mass maintenance, logging is often switched off for performance reasons; and archiving clears old entries away.
An event log whose coverage depends on system settings is not a neutral record. The gaps are invisible in the result — the analysis looks complete and isn’t.
3. Field changes become activities — through interpretation
Between “field LIFDT changed” and the process activity “delivery date moved” sits a translation someone has to maintain: which field change counts as which activity? Which ones are ignored? What about Z-fields?
These mapping tables differ per system, grow with every release and are never fully documented themselves. The project ends up building a second, interpreted truth about the system — exactly what a data-driven analysis is supposed to avoid.
4. Volume and distortion
In grown systems, CDPOS ranks among the largest tables there are; extracting via object class and object ID is correspondingly expensive. And the entries are unevenly distributed: a single batch job or mass change produces thousands of “events” under one technical user — in the mining result that looks like frantic process activity, but it’s a single administrative act.
What carries the weight instead: the document flow
The good news: SAP already documents the process itself — in its document flows. Purchase order history, sales document flow, invoice and payment references chain together the documents the process actually consists of. Every step there is a real document with quantity, value and timestamp — not an interpreted field change.
Change documents tell you what was corrected on a document. The document flow tells you how a purchase order became a paid invoice. For process mining, the second one is the story that counts.
CDHDR/CDPOS still have their legitimate place — as a supplement: wherever the flow shows a striking amount of after-the-fact correction, the changes are worth a look. As the backbone of the event log, they are the wrong foundation.
That is exactly why Conjola builds on document flows: Process Discovery reconstructs end-to-end processes deterministically from the document links in your extract — with variants, frequencies and automation rates, traceable down to the individual document. No mapping maintenance, no live connection into your system.