The event log is the specification, not the workshop diagram

Ask a team to draw their purchase-to-pay process and you will have a diagram inside forty minutes: nine to fourteen boxes, one decision diamond, no loops. Then extract twelve months of change documents for the same process and count the distinct end-to-end paths. Several hundred is ordinary.

Both are honest. The diagram is the process people believe they run. The timestamps are what the organisation did to a customer’s order. Where they disagree the timestamps win — not because they are more virtuous, but because they are what the customer experienced.

The workshop reliably produces the variant everyone likes best

Process mining dates to Wil van der Aalst’s group at TU Eindhoven around 1999; Gartner counted roughly 40 commercial tools in 2025. The finding that made the tooling worth building is consistent and unflattering: in a healthy process the top five variants cover 60–80% of case volume, behind them a tail of hundreds of paths that each occur a handful of times.

The tail is not noise. It is where exception handling and month-end firefighting live, and where naive RPA dies: you automate the workshop’s path and find a quarter of volume falling through to a queue nobody staffed.

The other routine finding is a re-ranking: the candidate everyone arrived wanting is often a small share of volume, while a rework loop nobody mentioned — because it feels normal — costs more than the headline. And if the distribution comes back flat, that is its own answer: there is no process there yet, only habits.

Four fields, and the fourth is optional until you need to explain queue time

The minimum viable event log is three columns — case ID, activity, timestamp — formalised as IEEE 1849 (XES). Resource is the fourth, and each field fails in a specific way.

Case ID ties events into one instance, and choosing it wrongly invalidates everything downstream rather than degrading gracefully. Order-to-cash is the standard trap: one order becomes three deliveries and two invoices, and forcing a single case ID produces the convergence and divergence artefacts that make classic mining misreport rework and cycle time alike. OCEL 2.0 exists for exactly that shape. Ask before extraction, not after the first chart looks strange.

Activity is a naming decision disguised as a data field. Too granular and you get 400 names and an unreadable model; too coarse and the rework loop vanishes inside one box called “Processing”. Workable rule: an activity is a state change somebody could be held accountable for.

Timestamp carries two hidden requirements: timezone, and enough resolution to order events within a day. Date-only stamps are the commonest reason a log cannot be mined at all — durations survive, sequence does not, and most tools will silently order same-day events by row ID and hand you a model built on insertion order.

Resource — who or what performed the step — turns a duration into an explanation. Without it you see that a case waited nine days; with it you see it crossed four handovers, which is where waiting accumulates.

The extract lives in the audit tables, not the reporting layer

Reporting views hold current state. A log needs transitions, which means the audit trail.

In SAP that is change documents — CDHDR and CDPOS — joined to the header and item tables for the process: EKKO/EKPO/EKBE for purchasing, BKPF/BSEG/RSEG for finance, VBAK/VBAP/LIKP for sales and delivery. The constraint to raise in the first meeting is that change documents only capture fields flagged for change logging in the data dictionary. If a field was never flagged, its history does not exist and no extraction recovers it retroactively — a hard limit on what any baseline can cover, better found in week one than in the steering committee.

The equivalents elsewhere: Business Events and the Data Management Framework in Dynamics 365 F&O, system notes via saved searches or SuiteTalk in NetSuite, mail_tracking_value over XML-RPC in Odoo. In the Bulgarian mid-market — Microinvest Delta Pro, Ажур L, Плюс Минус — the extract is a database schema and a report export rather than an API. A scoping fact, not an obstacle, but it belongs in the estimate.

Ticketing systems carry their own defect. Jira’s issue changelog gives real status transitions rather than current status, ServiceNow has sys_audit and task_sla, Zendesk has audits — but all stamp the moment the record was updated, not the moment the work happened. A clerk closing six tickets at 17:40 produces six events at 17:40, and the log then describes recording behaviour rather than operations. Plot event times against the working day before trusting a ticketing extract.

Below roughly 80% completeness, repair the instrument before touching the process

The gate on every mining engagement is a readiness score: the share of cases with complete timestamps, resolvable IDs and no step living only in a spreadsheet or a mailbox. Below about 80% the result is unsafe in a specific way — a variant appearing in 4% of cases is indistinguishable from a 4% extraction gap, and the two demand opposite responses.

The same ambiguity hits conformance checking. Fitness under roughly 0.8 is read as “the documented process is fiction”, and often it is — but fitness collapses identically when the log is missing events, and token-based replay points at the same places either way. Establish which you have before anyone redesigns anything.

Saying the first month is measurement repair rather than automation is unpopular at kickoff, and it is what makes every later benefit number defensible. Finance discounts a baseline it cannot trace to system timestamps to zero, and it is right to.

Rework hides inside the mean, and the mean is what gets reported

Report p50 and p90 separately, always. A mean throughput time averages a fast path with a slow one and describes neither; the problem an ops director has is the p90.

Rework rate — the share of cases where one activity fires more than once — is what the aggregate hides. On price and payment-term fields, 20–40% is a commonly published range, and every touch is legitimate: the price genuinely changed, so somebody genuinely re-approved it. The order closes, nothing is flagged, and the cost appears nowhere, because no single case looks abnormal and the average absorbs the difference.

Put touch time beside elapsed time. Nine days elapsed with 14 minutes of touch time is a queue problem; nine days with four hours of touch is a work-design problem. Automating the second when you have the first buys nothing.

The resource column makes this a works-council conversation

Resource-level analysis is employee performance monitoring, whatever the charter calls it. The EU AI Act’s Annex III lists monitoring of worker performance and behaviour-based task allocation as high-risk — bulk of obligations from 2 August 2026, Article 6(1) classification from 2 August 2027 — and GDPR Article 22 constrains anything that becomes a decision about a person.

The answer costs nothing analytically: pseudonymise resource to role or team at extraction, keep the individual mapping out of the analysis dataset, and put in writing that the log is not an input to appraisal. Handover analysis works fine at role level. And the moment a log reads on the floor as a stopwatch, people batch their status updates and you have paid for a worse instrument.

Where this stops applying

If the process runs mostly outside systems — on the phone, on the shop floor, in a mailbox — the log will be honestly sparse and mining will confidently describe the 20% that touched the ERP. That is a task-mining problem, and no extraction effort converts it. There is also a volume floor: a few hundred cases a year will not give a variant distribution worth analysing. Read them all; it is cheaper and more accurate.

One boundary about us. Palamed has four deliverable engagements: a European car marketplace with over 300,000 listings, the Ministry of Education and Science dictionary at beron.mon.bg, email-marketing automation for a beauty brand, where roughly a 60% reduction in outreach time is the client’s own number by their own method, and an NLP module that reads, classifies and answers trading questions across email and Instagram from the product and pricing data the team already maintains, where roughly 85% less manual typing on repeat questions is again the client’s own count and a person approves every reply before it sends. We have not run a mining engagement against an SAP estate. The above is the published pattern, the standards under it, and the checks we would run first. If someone tells you they have mined fifty processes, ask which tables they pulled, what their readiness score was, and which shortlist item the log killed.