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 we build Conjola on document flows. Process Discovery reconstructs the flows deterministically from the document links in your extract — in the first version for Order-to-Cash, with variants, frequencies and cycle times, traceable down to the individual document. No mapping maintenance, no live connection into your system.