Process mining vs expertise mining, different substrate, different output

Somebody built a beautiful map of your process. You have seen it. Every enterprise has one now.

It is on a Celonis dashboard, or an IBM one, or a Minit one. Boxes and arrows. Real event log data behind it, pulled from SAP or Salesforce or a claims system. You can watch a case flow through the map. You can spot the loops, the rework, the average cycle time, the delay between step four and step five.

It is a real thing. It is useful. And for a whole class of problems, it is exactly what a COO needs.

Then you sit down with the person who actually runs that process. And within ten minutes you realize the map is telling you what happened but not why any of it happened. Different substrate. Different output.

What process mining actually reads

Process mining reads event logs. Every time a case moves through a system, a claim gets created, an approval gets clicked, a status changes, a field gets updated, the system writes a timestamped record. Process mining ingests those records, reconstructs the flow, and shows you the shape of the work as it moved through your infrastructure.

The output is a process map that matches reality instead of the SOP. You see rework loops the team never mentioned. You see the shortcut path that runs three times faster than the official one. You see where cases pile up and where they slip through.

For work that lives inside systems and produces logs, order to cash, procure to pay, incident tickets, high-volume claims triage, process mining is a real tool. It has changed how operations leaders diagnose bottlenecks. That is why Celonis built a category out of it.

But process mining is bounded by what it reads. And what it reads is a byproduct of the work, not the work itself.

What the event log cannot tell you

Here is the concrete example. A large multi-brand insurance group runs a renewal workflow through a policy system. The event log shows every renewal case: opened, assigned to an underwriter, priced, approved or declined, closed. Process mining draws a beautiful map. The average handling time is six minutes. There is a small cluster of cases that take twenty-five minutes. There is another cluster that gets escalated to a senior underwriter and comes back approved.

Now the question a COO actually needs answered: why did this case get approved and that nearly identical one get declined?

The log will not tell you.

The log knows which button was clicked. It does not know that the underwriter saw a specific pattern in the loss history that told them the risk was mispriced but recoverable with a clause adjustment. It does not know that the escalation happened because the underwriter did not trust one of the fields in the customer record and wanted a senior eye on it. It does not know that the approval came with an unwritten condition that the account manager was supposed to communicate to the broker before month-end.

None of that is in the event log. None of that will ever be in the event log. It lives in the underwriter's head, in the judgment, the exception logic, the trusted sources, the "I always check this field first because the other one is usually stale" reasoning that took years to build.

That is a different substrate.

What expertise mining actually reads

Expertise mining reads people. It sits with an expert in structured conversation and pulls out the decisions, the reasons behind them, the exceptions, the sources they trust, the moments they stop and escalate, and turns all of it into a machine-readable expert profile that another system can use directly.

The substrate is tacit judgment. The output is operating knowledge, the real process, captured in a form that survives the person leaving. Not a transcript. Not a nicer wiki page. A structured expert profile with decision logic, exception handling, escalation conditions, and the trusted-source hierarchy that experienced operators carry in their head.

Where process mining shows you what happened, expertise mining shows you why the person made the call they made. Where process mining shows you the shape of the flow, expertise mining shows you the reasoning that shaped it.

They are not competing tools. They are complementary tools that read from two different sources of truth in the same operation.

Why COOs are now buying both

For a decade, the operations transformation stack looked like process mining plus RPA plus a workflow tool. That stack worked well for repetitive, log-generating, low-judgment work. It still does.

Then AI got good enough that leaders started asking whether an agent could handle the judgment-heavy work too, the underwriting call, the exception, the escalation, the decision that used to sit with a senior operator. That is where the existing stack ran out of substrate. It was missing the knowledge leg of enterprise AI, the layer that carries how the work actually gets done.

The event log tells you a case took twenty-five minutes and got escalated. It cannot tell an agent what to do the next time a case like that comes in. And an agent that only knows the documented process, the SOP path, the checklists, will handle the easy 20% of cases and break on the hard 80%.

That is the gap. Process mining diagnoses the shape of the work. Expertise mining captures the judgment behind it. A COO who wants an AI layer that survives real operations needs both.

That is also why so many pilots die. MIT NANDA found that 95% of enterprise AI investments show no measurable business impact. Gartner projects that 40% of agentic AI projects will be canceled by end of 2027. In our own two years inside real enterprises, the pattern was consistent: the agent was never the hard part. The model was good enough. The failure point was that the company could not tell us how the work actually gets done. The event log said what happened. The documents said what was supposed to happen. Neither one said why the experienced operator made the call they made.

The undocumented half of the real process

Roughly 80% of operational processes are undocumented [Tallyfy]. Process mining recovers part of that gap by showing you the real flow through the systems. That is a real contribution. It closes the distance between the SOP and what actually moved through the software.

But there is a second gap that process mining does not touch. Between the observable flow and the reasoning behind it. Between the click and the "why this click and not the other one." That is the substrate expertise mining reads.

We have seen this concretely. At a maritime chartering firm, an eight-person team now runs with one. The event log for that operation could show you every ship-cargo match that closed and every one that did not. It could not tell you why the experienced broker knew which counterparty to call first, which quote to trust, which cargo to walk away from. That reasoning was the operation. Once we captured it as a machine-readable expert profile, the same work ran with a fraction of the headcount, not because the tool replaced anyone, but because the captured expertise meant the remaining operator could hand routine cases to an agent that had absorbed the judgment.

At a large multi-brand insurance group, the renewal workflow dropped from six minutes to one, an eighty-three percent cut in handling time, about 833 labor hours saved per month per 10,000 renewals. Not because we drew a better process map. Because we captured the underwriter's actual decision logic, ran it as a governed agent operation next to the human, and let the expert focus on the cases that genuinely required their judgment.

Process mining would have shown the six-minute average. It could not have collapsed it.

Different output, different buyer

Here is the split that matters for anyone deciding what to invest in this year.

Process mining outputs a diagnosis of the flow. The buyer is a COO or a Head of Transformation who needs to see where the work is jamming and where the rework is. It is a lens on the operation as it exists in the systems.

Expertise mining outputs a machine-readable version of the expert. The buyer is the same COO or Head of Transformation, but the use case is different, they need the judgment layer to survive an experienced operator leaving, to onboard a new hire in weeks instead of years, or to feed a governed agent operation that handles real cases without hallucinating on the exceptions.

A process mining dashboard tells you the underwriting queue is backing up on Wednesdays. Expertise mining tells you what the senior underwriter does when the queue is backing up on a Wednesday.

Different substrate. Different output. Different question.

The sequence that actually works

The teams that get real ROI from AI on operations tend to do this in an order.

They diagnose the flow first, where the volume is, where the delay is, where the judgment concentrates. Process mining is a natural fit for this step. It surfaces the processes where a small number of experienced people carry a disproportionate share of the decisions. That is the highest-ROI target.

Then they mine the expertise inside that process, not everyone, but the one or two people whose judgment actually holds the operation together. That is the expert everyone calls. Their reasoning gets structured into an expert profile that another system can use.

Then they run a governed agent operation on top of that captured expertise, inside the same systems the team already uses, with a human always in the approval loop for anything that writes back into a real system.

Process mining alone leaves the judgment layer on the table. Retrieval alone reads only what was written. Expertise mining alone, without a process mining lens, can point the extraction effort at the wrong process. Together, diagnose, mine, operate, you get an AI layer that survives real cases and a process that survives the expert leaving.

That is the honest answer to "process mining vs expertise mining." Not versus. In sequence. Different substrate, different output, both needed, and the expertise layer is the one the market has spent a decade skipping.

If you already have a process mining rollout in production, you are not starting from zero. You are one step in. The next step is capturing the reasoning behind the flow, not by writing longer SOPs, but by mining the people who hold the real process. Mine your first process.