The process is what the log says, not what the diagram says
A process everyone describes in one diagram usually runs in dozens of distinct paths. Fifty-one notes on building an event log that means something, reading the result sceptically, and the obligations that attach the moment capture moves to the desktop.
All 51 notes
Grouped by section, each appearing once. Open a section for descriptions.
Foundations
6 notesTwo techniques, frequently sold together, using different data and carrying very different obligations. Plus the question that should be written down before any extraction.
The event log
7 notesMost of the difficulty in this field is producing a correct log. The case identifier and the activity vocabulary are the two decisions that determine what questions you can ask.
Discovery and analysis
9 notesThe discovered picture reflects the algorithm as much as the process. What each analysis shows, where it misleads, and how to report it so it survives challenge.
Task mining
7 notesCapture on individual machines is surveillance of named people, with obligations attached. The bounded-study arrangement that makes it defensible, and the alternatives to try first.
From insight to change
6 notesMost analyses end as a report. The sequence that converts one into a modified process, and the honest test for an automation candidate.
Running it
5 notesA small part of an analysis is worth a schedule. Plus simulation, which is bundled with every tool and produces the least reliable output any of them offers.
The programme
7 notesChoosing the first process badly costs the programme its credibility before it has any. Plus what you can do with SQL and a pivot table before any licence.
Reference
4 notesCompliance frameworks and data protection pull in opposite directions and both apply. Plus the boundary: questions the log cannot answer, and what to use for each instead.
What this is
Fifty-one notes on process mining and task mining, written for the people who have to produce a usable event log and get a finding acted on.
No vendor material, no product recommendations, no sponsored content.
Four things that hold across deployments
The log is the work. Extraction, case identifiers and activity naming take most of the effort, and every disputed finding traces back to one of them.
The variant count is always higher than expected. A process described in one diagram typically runs in dozens of paths, and that number alone usually justifies the exercise.
Waiting dominates. Where start and end timestamps exist, working time is frequently a small share of elapsed time.
Task mining is a different activity. Reading system records and capturing keystrokes on named people's machines are not the same thing, and treating them as one produces a consultation problem before any value.
Where to start
New to this: the foundations, particularly which questions each technique answers.
A tool and no usable log: the event data section, which is the most common situation.
Desktop capture proposed: the task mining section, before anything about technology.
A stalled deployment: the note on common failures.
What this is not
This is not legal advice. Descriptions of monitoring obligations, consultation requirements and retention limits are general and vary substantially by jurisdiction.
It does not describe how to capture desktop activity covertly, or how to work around the notice and consultation obligations that attach to it.