The Log Does Not Know It Is Lying
A regional distribution company spent four months and a meaningful consulting budget mining their warehouse management event logs. The output was a beautiful spaghetti diagram showing forty-seven process variants for a pick-pack-ship sequence that was supposed to have three. The operations director looked at it and said, yes, that is because we have two supervisors who key orders differently depending on which shift they are covering. Her team had known this for two years.
That is not a failure of process mining as a discipline. It is a failure of sequencing. The event log captured every deviation faithfully. It just could not tell you whether the deviation was a workaround, a training gap, a system quirk, or a deliberate local optimization. For that you need a person in the room.
What Event Logs Actually Tell You That People Cannot
There are situations where the log earns its cost immediately and nothing else comes close.
In a mid-size commercial lending operation, the stated process for credit memo approval was five steps and two days. The event log showed the median was eleven days, the variance was enormous, and a specific document type was being re-routed through a senior approver on sixty percent of cases even though policy said it did not require that step. Nobody in the workshop had flagged this because the people doing the re-routing thought it was required. The people receiving it thought the senders were being cautious. The senior approver thought it was a system default. Three groups, three wrong mental models, one log that settled it in an afternoon.
Logs also catch volume patterns that human memory smooths over. People remember the bad week, not the systematic Tuesday morning queue spike that has been compounding for eight months. If your problem involves timing, frequency, or the actual sequence of system touches across a large transaction volume, the log is not optional.
Where logs are genuinely strong: 1. Finding process variants that nobody admits exist 2. Measuring actual cycle time versus stated cycle time 3. Identifying which cases escape the normal path and by how much 4. Catching rework loops that happen silently inside a single system
What a Two Hour Workshop Finds That the Log Never Will
I have run workshops in field operations where the team identified the real constraint in under thirty minutes. A utilities maintenance crew explained that the scheduling system assigns jobs in geographic clusters, but the parts van follows a completely different route because it is managed by a separate dispatcher with different priorities. The job assignments look fine in the system log. The technician wait time looks like traffic or job complexity. The log sees symptoms. The crew sees cause.
Workshops are faster and cheaper when the bottleneck is organizational rather than procedural. If the delay lives between systems, between departments, or in an informal escalation path that was never modeled in software, no amount of log mining will surface it cleanly. The log records what the system saw. It does not record the phone call, the spreadsheet someone maintains locally, or the judgment call a manager makes before the ticket even opens.
Workshops also surface what people have already tried. In a food manufacturing plant, a two-hour session with line supervisors revealed that the changeover time problem the operations team wanted to automate had already been partially solved by a shift lead who had built a paper-based pre-staging checklist. The log showed changeover times improving on one shift and not others. Without the conversation, you would have built automation on top of a problem that was already half solved by someone who would have been happy to share the solution.
How to Combine Them Without Wasting Either
The practical sequencing I use depends on one question. Do you already have a hypothesis about where the work gets stuck, or are you genuinely uncertain?
If you have a hypothesis, run the workshop first. Two hours with the people who do the work will either confirm it, sharpen it, or replace it with something more accurate. You go into the log mining with a specific question, which cuts the analysis time dramatically and keeps you from drowning in variants that do not matter.
If you have no hypothesis and you are operating at scale, run a lightweight log pull first. Not a full mining engagement, just enough to see where time accumulates and where volume concentrates. Use that to design a focused workshop. You walk in knowing which steps to probe and which teams to put in the room together.
The mistake I see most often is running a full process mining engagement as a discovery exercise when a two-day workshop would have produced a better-prioritized backlog at a fraction of the cost. Log mining is powerful but it is not free, and the output requires interpretation that almost always loops back to the humans anyway.
A practical combined approach: 1. Pull a quick cycle time distribution from whatever system of record you have, even if it is imperfect 2. Identify the two or three steps where time variance is highest 3. Run a focused workshop with the people who own those steps 4. Use the workshop output to define the specific questions you want the log to answer 5. Mine the log against those questions, not against the whole process
Where AI Agents Change the Calculus
When you are building an AI agent to operate inside a process rather than just analyze it, the stakes on getting this right go up considerably. An agent that automates the official process and ignores the forty-seven variants is going to fail on a significant percentage of real cases. An agent that is designed around what the team described in a workshop but never validated against actual log behavior is going to be surprised by edge cases that the team normalized so long ago they forgot to mention them.
I have seen both failure modes. In a claims processing context, an agent was trained on documented process steps and immediately started generating exceptions on cases that any experienced handler would have recognized as routine, because the handlers had developed informal triage rules that lived nowhere in the official documentation. In a procurement context, an agent was designed around log-derived process variants and could not handle the approval escalation path because that path was triggered by a phone call, not a system event.
The agents that hold up in production are the ones where the builder used both sources and was honest about the gaps. The log tells you what the system saw. The team tells you what the system missed. You need both before you automate anything at scale.
Honest Limits of Both Methods
Process mining is only as good as the event log, and event logs are frequently incomplete, inconsistently timestamped, or missing entire categories of work that happen outside the primary system. In field operations especially, a significant portion of coordination happens in messaging apps, phone calls, and verbal handoffs that leave no log at all. You can mine what you have and still be looking at sixty percent of the actual process.
Workshops have their own failure modes. People describe the process as it should work or as they wish it worked. They omit steps that feel embarrassing or politically sensitive. They underreport their own workarounds. Senior people in the room shift what junior people say. None of this is dishonest, it is just how human memory and group dynamics work. A facilitator who knows the operational domain can push past some of this, but not all of it.
The honest answer is that neither method gives you the full picture alone. The log gives you precision on what it captured. The workshop gives you context and causality. The combination gives you something close to operational reality, which is what you actually need before you commit to changing anything.
The Practical Takeaway
Before you commission a process mining engagement, write down your hypothesis about where the work gets stuck and why. If you cannot write it down, you are not ready to mine logs yet. Run the workshop first.
Before you trust your workshop output, ask the team to show you the last five times that step caused a problem. If the examples match the pattern they described, you have a reliable signal. If they do not, you need the log.
The goal is not to choose between data and people. The goal is to use each one to sharpen the questions you ask of the other. That is how you get to a real answer in weeks instead of quarters, and it is how you build automation that survives contact with the actual work.