What is task mining, and how is it different from process mining?

Where each one gets its evidence

The difference is not the analysis. It is where the evidence comes from, and that decides what each approach can and cannot tell you.

Process mining reads the event logs that transactional systems write as a by-product of doing their job: an order created here, an approval recorded there, a status changed at a particular time by a particular user. Given enough of those events with a shared case identifier, you can reconstruct the path each case took through the system and count how often each variant occurred.

Task mining takes its evidence from the desktop instead. It observes the actions a person performs while doing the work: the applications they open, the fields they fill, the copying between one screen and another, the spreadsheet that sits between two systems that were never integrated.

What each one is good at

They answer different questions, and the honest way to choose is to work out which question you actually have.

• Process mining is strong when the process genuinely lives inside one or two systems, the logs carry a reliable case identifier, and you want to know how long each step takes across thousands of cases. It measures at a scale no observation can reach.
• Task mining is strong when the work happens between systems rather than inside them, when the interesting variation is in how individuals do the job, or when nobody can tell you what the current process even is. It sees the workarounds.
• Neither tells you why. A log shows an approval took nine days; it does not know that the approver was waiting on a document that lives in someone’s inbox. That still comes from asking.

What each one misses

Process mining misses everything that leaves no event. If a step happens in a spreadsheet, an email thread, a chat message or a conversation, the log has no record of it, and the reconstructed process quietly omits it. That matters most in exactly the processes people find hardest to explain, because the reason they are hard to explain is that they are held together by work no system saw.

It also depends on data quality that is often assumed rather than checked. Logs without a consistent case identifier, timestamps written at batch time rather than event time, and steps performed by a service account on behalf of several people all distort the picture, and the distortion is not obvious from the result.

Task mining has the opposite blind spot. It sees one person, or a sample of people, over a limited period. Extrapolating from that sample to the whole population is a judgement, not a measurement, and it is easy to mistake one person’s habits for the process. It also raises a real question of consent and surveillance that has to be answered before anyone records anything.

The prerequisite people discover late

Both approaches assume the systems in question are the ones the work runs on. For a large share of the processes that cause organisations pain, that assumption does not hold: the process runs on documents, shared drives, meetings, and the knowledge of the two people who have always done it.

When that is the situation, an event-log project can spend months on data engineering before it produces a diagram that everyone recognises as incomplete. It is worth establishing early whether the process you care about actually writes the events you would need, because the answer decides whether the approach is viable at all rather than merely slow.

A third option that is easy to overlook

There is a middle path that neither term describes well: building the picture from what the organisation has already written down. Procedures, runbooks, wiki pages, meeting transcripts and training material describe how work is supposed to happen, and they exist for most processes long before any logging does.

That material is usually out of date in parts and contradictory in others, which is why it tends to be dismissed. It is still evidence, and reconciling it against one recorded run of the job is often faster than instrumenting anything. This is the approach Valstra takes with Omni: the model is generated from documents, transcripts and wiki pages, plus a single consented recording of someone doing the job, rather than from system event logs.

How to choose

Ask what evidence already exists before choosing a method, rather than choosing a method and then hunting for evidence to feed it.

• If the process runs end to end inside a system that logs reliably, and your question is about duration and variation at scale, process mining fits.
• If the process runs between systems and your question is what people actually do, observation fits, with consent settled first.
• If nobody can describe the process and the systems barely touch it, start from the documents and one recorded run, then check what you build against the people who do the work.